Replies: 3 comments 10 replies
-
|
Hi @mbuchner, thanks for this report,
You could've asked earlier, we are here to help :-) Just a minor comment re your config first:
If it is related to the encrypted session cookie exceeding 4K limit - it should be managed automatically now by Quarkus OIDC in such cases, please try later As far as the ID token refresh is concerned, But you have to allow Quarkus to refresh - this is not done out of the box, because RT can last for a very long time, but the application may not want an unlimited session time for the authenticated users which may happen if the session is constantly refreshed. See https://quarkus.io/guides/security-oidc-code-flow-authentication#session-management, simply enable the refresh and if you'd like, which I recommend, add a refresh skew, which will proactively refresh all tokens once the ID token has nearly expired (ex, within the next 10 minutes). Let me know how it goes |
Beta Was this translation helpful? Give feedback.
-
|
Hi Sergey, Thanks for your quick reply! I think that the refresh call fails - here is an excerpt from my logs:
I will also try to find out more if there are any logs on Netscaler side - which could tell me why we get this HTTP 400 "invalid_request" Thanks in advance Max |
Beta Was this translation helpful? Give feedback.
-
|
And here the well-known info from the OIDC provider - if that helps: |
Beta Was this translation helpful? Give feedback.
-
|
It is also strange that the refresh token call calls: But the error states: so Is the refresh_token flow supported at all based on the well-known info I posted above ... |
Beta Was this translation helpful? Give feedback.
-
|
@mbuchner Hi,
This is a good practice, refresh tokens are recycled. So, if you have parallel SPA requests coming in on behalf of the same authenticated user, there is a race condition, by the time one of Quarkus requests managing the refresh for the corresponding SPA request reaches the provider, this token has been recycled. Quarkus can't control that. I think the SPA should simply coordinate it on its end somehow, I don't know, may be if you initiate N requests, there is some latch waiting for the completion of all of them and then deciding how to react, initiate a reauthentication or just proceed as normal if one of these requests returned 200, something like that. |
Beta Was this translation helpful? Give feedback.
-
|
Please also confirm a single request only works and the RT grant works, and then look at how to handle N of them in parallel |
Beta Was this translation helpful? Give feedback.
-
|
Okay further investigation has been done - but still not really happy. I just got a hack working ... We figured out that the "grant_type=refresh_token" request doesnt return an ID token. Only an access and refresh token. We got the log "ID token is not returned in the refresh token grant response, re-authentication is required" We followed then the chapter in the quarkus documentation (https://quarkus.io/guides/security-oidc-code-flow-authentication#oauth2) - as there is something mentioned about "no ID token in refresh response" - but nothing worked ... quarkus always wanted to refresh after 5 min (end of ID token lifetime) There would actually be a grant_type "id_token" (see above well-known file) which is supported - which could be called if there is no ID token in the "refresh token grant response" - so there would be a possibility to get the ID token but I dont see any implementation in the quarkus source code arround "id_token"grant_type. Finally here is our current hack to avoid quarkus to do a "refresh_token" call. I also have to say that we dont use the UserInfo endpoint - we dont need any data from it. Hoping to find a better solution - waiting for your thoughts ... Thanks Max |
Beta Was this translation helpful? Give feedback.
-
|
So if I understand it correctly, your provider returns ID token in the authorization code flow response, but, when the ID has expired, and the tokens are refreshed, it does not return an ID token ? But if the ID token has become invalid (i.e, expired in this case), and no new ID token is returned, there is no choice but request it via an authorization code flow.
It is not a grant type, but a response type, this is part of the different flows, SPA would use the id_token response type to get the id token returned to it
Do you mean your provider does not return an ID token at all, and you also have |
Beta Was this translation helpful? Give feedback.
-
Yes thats correct! "grant_type=authorization_code" returns ID Token but "grant_type=refresh_token" doesnt return an ID token.
Thats exactly the issue - an "authorization code flow" needs a complete refresh of the page - so all form inputs a user has probably made are lost - and the SPA needs to be completly reloaded. :-( |
Beta Was this translation helpful? Give feedback.
-
|
The session validity is tied to the ID token validity. Quarkus can't use it to assert the session's validity if the ID token is invalid because it has expired. So if your provider does not give a new ID token but you'd like to have a long Quarkus session, then I think you should configure ID token's lifespan, in the provider's dashboard, be equal to the maximum amount of time you'd like the session be active. This is an administrator's decision that you should consider taking. Quarkus OIDC can't make this security sensitive decision itself and use an invalid ID token to extend the session indefinitely and then being challenged with CVEs. The only documented purpose of its Also, no matter what is configured to keep the session uninterrupted, the SPA must expect that the re-authentication will be required now or later, and manage a possible user's input accordingly. Does it clarify it ? Thanks |
Beta Was this translation helpful? Give feedback.
-
|
Sorry if I'm annoying but I still don't understand why only the ID token validity is important. When I call the "grant_type=authorization_code" the first time we get the following info which also includes the refresh token lifetime. When I then constantly refresh the access token with the refresh token -> as explained here: So a full "Authorization Code flow" is only needed when the refresh token expires according to this statement:
This combination is also mentioned here as a valid approach: In the Quarkus implementation it immediately "stops" when the refresh doesn’t return an ID token. |
Beta Was this translation helpful? Give feedback.
-
You are welcome to keep asking/discussing for as long as you like, np at all.
But if the refresh token grant is activated it means the ID token has expired. The refresh token can last for months, but the user may have to be re-authenticated every 4 hours, which is what ID token can help with. RT's goal is to refresh tokens only, and not be used as a very long session activator. If your provider does not want to return new ID tokens then may be this is what it wants, a user re-authentication once the ID token has expired. You set the skew which means ID token is still valid for the next 2 mins or so, so the session should remain active for the remaining 2 mins if the RT grant response does not give a new ID token (as indeed is allowed, https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokenResponse). If that does not work for a single request only then please open a bug (but you said earlier you have parallel requests for the same authenticated user, so given a single time use of the refresh token with your provider, may be this is why you see some errors) So please set ID token's lifespan to last for |
Beta Was this translation helpful? Give feedback.
-
|
@mbuchner FYI, #39556. It will take awhile to fix though, for now, control the ID token lifespan directly |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
We have implemented the Authorization Code Flow with Quarkus. We were forced to as our customer doesn't support Authorization Code Flow in frontend SPA applications. (Netscaler)
https://quarkus.io/guides/security-oidc-code-flow-authentication
We got it running so far after several days of trial and error.
What doesn't work is the refresh. They are not sending a JWT refresh token but only a binary (opaque) refresh token.
(In DEV environment we use Keycloak - and everything is working fine ...)
Here an excerpt of our config:
They pretend to send the following information:
Could it be that quarkus doesnt use the "refresh_token_expires_in" but instead uses "refresh_expires_in".
At least thats the only string I could find in the quarkus sources:
https://github.com/quarkusio/quarkus/blob/main/extensions/oidc-common/runtime/src/main/java/io/quarkus/oidc/common/runtime/OidcConstants.java
Could anybody confirm my suspicion?
Can I overwrite this value somehow so that "refresh_token_expires_in" is used?
Or am I on the wrong track and something else is wrong in our setup ... I am open for any input as I am freaking out now after 2 days :-)
Thanks Max
PS: Is there a way to print the response header / body .. of quarkus OIDC requests ?
Beta Was this translation helpful? Give feedback.
All reactions