WebSocket Next: enable users to update SecurityIdentity before previous bearer access token expires #47675

michalvavrik · 2025-05-03T12:04:08Z

closes WebSocket-Next - Refresh OIDC AccessToken without reconnection #43434

quarkus-bot · 2025-05-03T12:40:29Z

Status for workflow `Quarkus Documentation CI`

This is the status report for running Quarkus Documentation CI on commit cbcc107.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

github-actions · 2025-05-03T12:45:08Z

🎊 PR Preview bf02409 has been successfully built and deployed to https://quarkus-pr-main-47675-preview.surge.sh/version/main/guides/

Images of blog posts older than 3 months are not available.
Newsletters older than 3 months are not available.

quarkus-bot · 2025-05-03T13:00:22Z

Status for workflow `Quarkus CI`

This is the status report for running Quarkus CI on commit cbcc107.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

Flaky tests - Develocity

⚙️ JVM Tests - JDK 17 Windows

📦 extensions/micrometer-opentelemetry/deployment

✖ io.quarkus.micrometer.opentelemetry.deployment.compatibility.MicrometerTimedInterceptorTest.testTimeMethod_Async - History

Stream has no elements - java.lang.IllegalArgumentException

java.lang.IllegalArgumentException: Stream has no elements
	at io.quarkus.micrometer.opentelemetry.deployment.common.MetricDataFilter.lastReadingDataPoint(MetricDataFilter.java:236)
	at io.quarkus.micrometer.opentelemetry.deployment.compatibility.MicrometerTimedInterceptorTest.testTimeMethod_Async(MicrometerTimedInterceptorTest.java:126)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at io.quarkus.test.QuarkusUnitTest.runExtensionMethod(QuarkusUnitTest.java:521)
	at io.quarkus.test.QuarkusUnitTest.interceptTestMethod(QuarkusUnitTest.java:435)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

✖ io.quarkus.micrometer.opentelemetry.deployment.compatibility.MicrometerTimedInterceptorTest.testTimeMethod_AsyncFailed - History

Stream has no elements - java.lang.IllegalArgumentException

java.lang.IllegalArgumentException: Stream has no elements
	at io.quarkus.micrometer.opentelemetry.deployment.common.MetricDataFilter.lambda$lastReading$2(MetricDataFilter.java:213)
	at java.base/java.util.Optional.orElseThrow(Optional.java:403)
	at io.quarkus.micrometer.opentelemetry.deployment.common.MetricDataFilter.lastReading(MetricDataFilter.java:213)
	at io.quarkus.micrometer.opentelemetry.deployment.common.MetricDataFilter.lastReadingDataPoint(MetricDataFilter.java:231)
	at io.quarkus.micrometer.opentelemetry.deployment.compatibility.MicrometerTimedInterceptorTest.testTimeMethod_AsyncFailed(MicrometerTimedInterceptorTest.java:150)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at io.quarkus.test.QuarkusUnitTest.runExtensionMethod(QuarkusUnitTest.java:521)

sberyozkin · 2025-05-04T18:45:58Z

docs/src/main/asciidoc/websockets-next-reference.adoc

@@ -1073,6 +1073,51 @@ When you plan to use bearer access tokens during the opening WebSocket handshake
 * Use a custom WebSocket ticket system which supplies a random token with the HTML page which hosts the JavaScript WebSockets client which must provide this token during the initial handshake request as a query parameter.
 ====

+Before the bearer access token sent on the initial HTTP request expires, you can send a new bearer access token as part of a message and update current `SecurityIdentity` attached to the WebSocket server connection:


How is this new token can be obtained ? The current one is bound to the connection at the upgrade time.

How did you obtained original token used at the upgrade time? Obtain it the same way. You pass it in a DTO that contains message and optionally metadata. You can pass it into the endpoint or hide that in the decoder (but I prefer the endpoint, hence the example). Tests speak for itself

Can front end client use refresh token stored in a session storage and obtain access token?

@michalvavrik

How did you obtained original token used at the upgrade time?

I'm assuming SPA used the authorization code flow

Obtain it the same way.

I don't think it works the same way for the token refresh.

So the proposal is for SPA to run a background task and check the current access token expiry time and refresh ?
What I don't know if OIDC scripts allow SPA access the access token expiry time - as some of these tokens are binary tokens.
The other thing I don't know, can one do HTTP calls while working with WS API ?

I'm assuming SPA used the authorization code flow

I don't know how to make WS work with authorization code flow on the Backend. I have looked into it before and I also raised it in the linked issue comments. Even if authorization code flow started before the WebSocket was opened, you still don't have a have to link session cookie with opened WebSocket. Anyway, I opened this PR for a bearer token authentication only.

Obtain it the same way.
I don't think it works the same way for the token refresh.

[1]
I need more information to understand why not, I can trust you, but then there is no point continue because this PR just won't do. No point wasting time on a review. My thinking was that:

For client credentials (like server to server websocket communication) you can use client id and secret to obtain token in the background.

For implicit grant flow (if there is still someone using it) SPA can send in the background and gets a token based on valid browser session

For code flow on the SPA side, you store session tokens in the browser session store, you keep refreshing token and you have direct access to the access token. I have personal experience with it, because I was maintaining Angular SPA in production for 2 years that communicated with multiple backends and we wrote interceptor to generated front-end clients that always set authorization header for tokens retrieved from the browser storage. we used https://github.com/manfredsteyer/angular-oauth2-oidc, it was hell to get it right, but then it worked

So the proposal is for SPA to run a background task and check the current access token expiry time and refresh ?

proposal is for SPA to get access token itself in a ways described right above, please see [1] of this comment.

What I don't know if OIDC scripts allow SPA access the access token expiry time - as some of these tokens are binary tokens.

I have no idea about that, but I remember that in our SPA we got tokens from Keycloak and we knew token expiration time (I want to say 30 minutes for access token and 18 hours for the refresh token, but honestly, I am not sure if I am not imaging it). It didn't change for us, maybe they can just check it out before? E.g. they don't exactly need to automate it, just add timed task.

The other thing I don't know, can one do HTTP calls while working with WS API ?

Typescript has multithreading, I think having background tasks like updating feeds on your SPA is a standard (e.g. on the newspage you have breaking news and that can by done by polling and HTTP requests). But I do speak about frameworks like Angular and React, no idea what you do with vanilla JS or node.js etc.

@michalvavrik Sure, SPA can do token refreshes

Can it really work though such that the script that works with the current WS connection can accept a refreshed token and forward this token to Quarkus ?

If we could confirm it then it would be great, IMHO there is no rush with the fix being merged

I'll write an example by the end of the week.

If we could confirm it then it would be great, IMHO there is no rush with the fix being merged

I have more plans for WS Next and while I didn't mention it (no reason to mention it), what I have added to this PR will allow me to easily fix quarkiverse/quarkus-langchain4j#1418 in the follow up. I don't want to keep this PR on hold, but let's wait until I have the example front end application. I'll inform you when I am done.

@michalvavrik Thanks, IMHO it will be worth it because this sample SPA can be used as a base for Step-Up authentication demos.

We can also add some simple example, similar to https://quarkus.io/guides/security-oidc-bearer-token-authentication#single-page-applications, without expecting it to be complete, to give users an idea how a token can be passed over to the existing WS connection

We can also add some simple example, similar to https://quarkus.io/guides/security-oidc-bearer-token-authentication#single-page-applications, without expecting it to be complete, to give users an idea how a token can be passed over to the existing WS connection

ok, I'll look into it, but no promises on the https://quarkus.io/guides/security-oidc-bearer-token-authentication#single-page-applications part because it may require complex stuff, I don't know until I do it

sberyozkin · 2025-05-05T20:37:13Z

@michalvavrik

I have more plans for WS Next and while I didn't mention it (no reason to mention it), what I have added to this PR will allow me to easily fix quarkiverse/quarkus-langchain4j#1418 in the follow up.

If you can see a way to do the work to support Quarkus LangChain4j fix without having to support the token injection, then please consider a dedicated PR - simply because, if that is considered a bug fix, it can be backported to 3.20 LTS, as this PR is unlikely to be backported

sberyozkin · 2025-05-05T20:44:09Z

docs/src/main/asciidoc/websockets-next-reference.adoc

+    WebSocketSecurity webSocketSecurity;
+
+    @OnTextMessage
+    String echo(RequestDto request) {


@michalvavrik

I think this method will have to match the security level of the HTTP upgrade.

For example, if HTTP Upgrade happened at @RolesAllowed("Admin"), then only verifying the validity of the token which would only match @Authenticated level, would raise a risk of decreasing the original security identity strength, for example, the new token which is about to replace an admin level identity may only have a user role.

OK, that's easy to do.

@michalvavrik Sounds good, we do it indirectly in the code flow too when refreshing tokens, since it is done in scope of the request.
In case of this PR, the new token is coming via the front channel so the extra care is needed.
We might end up doing extra checks as well...

I am not sure if I understand what you mean, but my plan is: there is a check that assures principal name is same (so they can't change alice for bob), but for roles and permissions, we just need to reapply standard security annotations (HTTP policies sounds like out of scope to me), which I think is easy. There is a code that prevents repeated security checks, I'll just disable the code when the identity refresh is enabled.

@michalvavrik I was actually thinking about it too, how do you prevent an identity swap, so having the principal name check is good, but a few more checks may be necessary, such as a sub claim - sub is a unique number associated with a given user that did an original login, or even a more thorough identity comparison, but we can think about it later.

IMHO, whatever the security constraints were applied to HTTP upgrade should be reapplied at the token injection time because this is how we do in the code flow refresh. For example, when the ID and access token are refreshed, the refreshed ID token goes through the complete authentication and authorization cycle before the method can be called.

If the token is binary then we can update OidcIdentityProvider to record sub value from the introspection response as an identity attribute, something like that, so that you can easily access this sub

michalvavrik · 2025-05-05T21:28:24Z

If you can see a way to do the work to support Quarkus LangChain4j fix without having to support the token injection, then please consider a dedicated PR - simply because, if that is considered a bug fix, it can be backported to 3.20 LTS, as this PR is unlikely to be backported

My plan is to use the fact that this PR stores security support on the connection. It should fix it inherently, as either LangChain4j uses the same duplicate context where we have the connection, or a new duplicated context created from the original one (there is a hierarchy and this will be parent one).

Anyway, I don't think it is important, the user that reported it didn't bother to add reproducer so I can't prove it is actual fix and fixing it after this get in is ok as this could be very edge case. Also, the way I plan to propose it (it may never get it), it could possibly provide further improvements, but not sort of code changes you want to backport. It is just idea, maybe never gets in.

sberyozkin · 2025-05-07T08:44:10Z

@michalvavrik Once the sample SPA sending a bearer token to HTTP upgrade is available, you can use it as a reproducer for the Quarkus LangChain4j issue too, so overall, it is worth it, not only to check the PR idea works, but also as a base for StepUp authentication and other experiments

feat(ws-next,oidc): support identity update before token expires

cbcc107

quarkus-bot bot added area/documentation area/oidc labels May 3, 2025

quarkus-bot bot added the triage/flaky-test label May 3, 2025

michalvavrik requested review from sberyozkin and mkouba and removed request for sberyozkin May 3, 2025 13:05

sberyozkin reviewed May 4, 2025

View reviewed changes

sberyozkin reviewed May 5, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WebSocket Next: enable users to update SecurityIdentity before previous bearer access token expires #47675

WebSocket Next: enable users to update SecurityIdentity before previous bearer access token expires #47675

michalvavrik commented May 3, 2025

quarkus-bot bot commented May 3, 2025

github-actions bot commented May 3, 2025

quarkus-bot bot commented May 3, 2025 •

edited by github-actions bot

Loading

sberyozkin May 4, 2025

michalvavrik May 4, 2025

michalvavrik May 4, 2025 •

edited

Loading

sberyozkin May 5, 2025

michalvavrik May 5, 2025

sberyozkin May 5, 2025

michalvavrik May 5, 2025

michalvavrik May 5, 2025

sberyozkin May 5, 2025 •

edited

Loading

michalvavrik May 5, 2025

sberyozkin commented May 5, 2025

sberyozkin May 5, 2025

michalvavrik May 5, 2025

sberyozkin May 5, 2025

michalvavrik May 6, 2025

sberyozkin May 6, 2025 •

edited

Loading

sberyozkin May 6, 2025 •

edited

Loading

michalvavrik commented May 5, 2025

sberyozkin commented May 7, 2025

WebSocket Next: enable users to update SecurityIdentity before previous bearer access token expires #47675

Are you sure you want to change the base?

WebSocket Next: enable users to update SecurityIdentity before previous bearer access token expires #47675

Conversation

michalvavrik commented May 3, 2025

quarkus-bot bot commented May 3, 2025

Status for workflow Quarkus Documentation CI

github-actions bot commented May 3, 2025

quarkus-bot bot commented May 3, 2025 • edited by github-actions bot Loading

Status for workflow Quarkus CI

Flaky tests - Develocity

⚙️ JVM Tests - JDK 17 Windows

📦 extensions/micrometer-opentelemetry/deployment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michalvavrik May 4, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sberyozkin May 5, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sberyozkin commented May 5, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sberyozkin May 6, 2025 • edited Loading

Choose a reason for hiding this comment

sberyozkin May 6, 2025 • edited Loading

Choose a reason for hiding this comment

michalvavrik commented May 5, 2025

sberyozkin commented May 7, 2025

Status for workflow `Quarkus Documentation CI`

quarkus-bot bot commented May 3, 2025 •

edited by github-actions bot

Loading

Status for workflow `Quarkus CI`

michalvavrik May 4, 2025 •

edited

Loading

sberyozkin May 5, 2025 •

edited

Loading

sberyozkin May 6, 2025 •

edited

Loading

sberyozkin May 6, 2025 •

edited

Loading