Quarkus OIDC: automatic token refresh for CodeAuthentication

[mqs24d]

Hi Community,

i experimented with the quarkus oidc plugin in my project where we need to use an internal oidc provider. In the initial Access Token Response the following tokens are included:

• id token
• opaque access token
• oqaque refresh token

In the refresh access token response only

• opaque access token
• oqaque refresh token

are delivered.

When setting quarkus.oidc.token.refresh-expired=true quarkus oidc is running fine until the token refresh is executed. For me it looks like an idtoken is necessary that quarkus can complete the refresh. Because quarkus tries to authenticate the idtoken and get's a nullpointer somewhere because the idtoken is null in my case.

Is it right that quarkus relies on getting an id token in the refresh access token response?

[quarkus-bot[bot]]

/cc @pedroigor, @sberyozkin

[sberyozkin]

Hi @mqs24d
Do you mean you have both quarkus.oidc.token.refresh-expired=true and quarkus.oidc.token.refresh-token-time-skew=some-duration set ?
If you only have quarkus.oidc.token.refresh-expired=true then it does mean that refreshing the tokens will only happen when the ID token has expired, it is really essential the refresh response contains a new ID token in this case since what we really want to do here is to extend the local session life-time and ID token represents it. We can't use the access token lifetime to extend the user session as the access token role is different to keeping the session.

If you have both quarkus.oidc.token.refresh-expired=true and quarkus.oidc.token.refresh-token-time-skew=some-duration set then the idea is that the refresh will happen just before ID token has expired, so in principle, we can continue using the current ID token to keep the current session if it is still valid if no ID token is returned - but it won't make much difference as it will expire anyway in the next few secs so we are back to the first scenario above.

I believe it is best to avoid trying to refresh tokens in your case, and instead try to experiment with a prompt extra code flow property so that the user is not challenged during the redirect to your provider if the session between your provider and the browser is still valid, it can be have a longer life-time than the one represented by IdToken which is about a session between the browser and Quarkus.

Does it help ?

[mqs24d]

Hi @sberyozkin,

thanks for your fast answer. Your explanation helps a lot.

Now i know that beside setting all the necesarry properties, the reason why the refresh is failing is the missing id_token in the refresh token response.

I'm not sure if i understand what you mean by "... prompt extra code flow property ..."? Is there something the quarkus plugin supports or do you mean something like this:

• inside the UI (server rendered or SPA) an API Call inside javascript is done and Quarkus answers with the status 499 (or redirect if the X-Requested-With header is not sent)
• the ui opens a popup where the code flow is triggered
• if the provider session is still valid the code flow is done without user input and the UI can close the popup afterwards

[sberyozkin]

@mqs24d, if SPA manages the code flow then it is totally out of control for Quarkus and it can verify this SPA sending access tokens to Quarkus, SPA is in total control, Quarkus acts as a service only, quarkus.oidc.application-type=service (default). If it is feasible in your case then perhaps you can consider moving to the SPA model.
But if the UI is server rendered, where you deal with quarkus.oidc.application-type=web-app then Quarkus is in control of the code flow and this is where you can try quarkus.oidc.authentication.extra-params.prompt=none, etc, and see how your provider reacts to it, if it supports prompt at all, see https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest.

[mqs24d]

ah now i understand... i will give it a try.

In my setup the SPA is delivered by quarkus und we are using quarkus.oidc.application-type=web-app because of corporate restrictions regarding the SPA managed flow.

[DCCSKrezovic]

Hi @sberyozkin

I'm wondering about it is really essential the refresh response contains a new ID token in this case since what we really want to do here is to extend the local session life-time and ID token represents it.

However, it is not required by the open id spec to return an ID token from the refresh endpoint:

https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens

Upon successful validation of the Refresh Token, the response body is the Token Response of [Section 3.1.3.3](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse) except that it might not contain an id_token.

Due to this, our internal OIDC provider does not provide an ID Token and our internal frameworks depend on the introspection result of the access token to actually determine validity of the session.

I wonder if it's possible to extend Quarkus to support this scenario? I'd be willing to help.

[mqs24d]

what if

• the session length is calculated based on the expires_in attribute (part of both the initial token response and the refresh token response)
• and in CodeAuthenticationMechanism#refreshSecurityIdentity passing the old id_token in the authenticate(..., new IdTokenCredential(...)) call
• or maybe even pass a AccessTokenCredential

But i assume in case of authenticating an AccessTokenCredential the OidcIdentityProvider needs to be adjusted so that it can create the SecurityIdentity based on a opaque AccessToken

[sberyozkin]

Hi @DCCSKrezovic
While it is true the providers are not required to return new IdTokens, it is also the case that access tokens are not really relevant to the OIDC state management, their role if for the Quarkus web-app application which plays the role of the OIDC confidential client to propagate them to access some services on behalf of the user, for example, use the access token to get UserInfo or get something from the downstream Quarkus service application.

The content of the access token is meant to be totally different to that of IdToken. Token refreshment is driven by the ID token's lifetime. RP-initiated, back-channel logout features are based on the presence of IdToken. As you can see, IdToken is a real cornerstone of the Quarkus CodeAuthenticationMechanism.

Note, for some providers like Github which are not really OIDC providers, we synthesize IdToken just to keep CodeAuthenticationMechanism working however the provider must be able to support UserInfo endpoint in such cases to compensate for the lack of the real IDToken.

If, in your case, ID token is only relevant until it expires and afterwards you'd like to start using the access token instead of the id token, then I can suggest to consider doing what Renarde does when working with GitHub/etc - configure quarkus.oidc.authentication.id-token-required=false - but set the user-info-required=true instead - during the 1st call you'll get the real ID token, once the token refresh is done and no id token is returned, userinfo will be fetched instead, etc
If your provider also does not support UserInfo then I can only think of what I've suggested to @mqs24d, just avoid dealing with the token refreshment and let Quarkus redirect the user to re-authenticate once the ID token has expired - your provider may not re-challenge again if its own session cookies are still alive.

[sberyozkin]

You can use the extra config to extend the session when the user is idle, IMHO it makes sense after a certain period to get the users reauthenticated

[sberyozkin]

@mqs24d I'd like to avoid using the information related to the access tokens for the state management which is centered around IdToken (or at the very least UserInfo) which represents a user authentication

[DCCSKrezovic]

Hi @sberyozkin,

You say it's possible to use IdToken until it's expired ... But what about simply keeping the initial one in the SecurityIdentity somewhere? We still need to access the IdToken claims, our userinfo endpoint does not return everything IdToken provides.

[DCCSKrezovic]

OK, did a test on my own

With following config ...

quarkus.oidc.application-type=web-app

quarkus.oidc.authentication.id-token-required=false
quarkus.oidc.authentication.user-info-required=true
quarkus.oidc.authentication.extra-params."acr_value"=gas:standard
quarkus.oidc.authentication.scopes=openid,profile,email,organizational_data,authorization_group,entitlement_group,offline_access

quarkus.oidc.roles.source=userinfo
quarkus.oidc.roles.role-claim-path=entitlement_group

quarkus.oidc.logout.path=/logout
quarkus.oidc.logout.backchannel.path=/user_logged_out
quarkus.oidc.authentication.redirect-path=/login
quarkus.oidc.authentication.restore-path-after-redirect=true

quarkus.oidc.token.refresh-expired=true
quarkus.oidc.token.refresh-token-time-skew=1m

I am able to get the IdToken in the initial authentication request.

But token refresh still does not work. I still see a redirect going on.

[mqs24d]

This is the Code from the CodeAuthenticationMechanism which is called when the token refresh is triggered. As you see currently the IdToken is needed and because idToken is null the authenticate call fails with a NPE.... therefore the redirect

private Uni<SecurityIdentity> refreshSecurityIdentity(TenantConfigContext configContext, String refreshToken,
            RoutingContext context, IdentityProviderManager identityProviderManager, boolean autoRefresh,
            SecurityIdentity fallback) {

        Uni<AuthorizationCodeTokens> refreshedTokensUni = refreshTokensUni(configContext, refreshToken);

        return refreshedTokensUni
                .onItemOrFailure()
                .transformToUni(new BiFunction<AuthorizationCodeTokens, Throwable, Uni<? extends SecurityIdentity>>() {
                    @Override
                    public Uni<SecurityIdentity> apply(final AuthorizationCodeTokens tokens, final Throwable t) {
                        if (t != null) {
                            LOG.debugf("ID token refresh has failed: %s", t.getMessage());
                            if (autoRefresh) {
                                LOG.debug("Using the current SecurityIdentity since the ID token is still valid");
                                return Uni.createFrom().item(((TokenAutoRefreshException) t).getSecurityIdentity());
                            } else {
                                return Uni.createFrom().failure(new AuthenticationFailedException(t));
                            }
                        } else {
                            context.put(OidcConstants.ACCESS_TOKEN_VALUE, tokens.getAccessToken());
                            context.put(AuthorizationCodeTokens.class.getName(), tokens);
                            context.put(REFRESH_TOKEN_GRANT_RESPONSE, Boolean.TRUE);

                            final String idToken = decryptIdTokenIfEncryptedByProvider(configContext, tokens.getIdToken());

                            LOG.debug("Verifying the refreshed ID token");
                            return authenticate(identityProviderManager, context,
                                    new IdTokenCredential(idToken)) // <<<<<<<<<<<<<<<<<<< idToken is null

[DCCSKrezovic]

Yes, that's the problematic line.

From what I see in auth code flow, there is

                        boolean internalIdToken = !configContext.oidcConfig.authentication.isIdTokenRequired().orElse(true);
                        if (tokens.getIdToken() == null) {
                            if (!internalIdToken) {
                                LOG.errorf("ID token is not available in the authorization code grant response");
                                return Uni.createFrom().failure(new AuthenticationCompletionException());
                            } else {
                                tokens.setIdToken(generateInternalIdToken(configContext.oidcConfig, null));
                            }
                        }

but this statement is missing in the refresh block.

[DCCSKrezovic]

Finally, a NPE happens in ....

    private Uni<Void> processSuccessfulAuthentication(RoutingContext context,
            TenantConfigContext configContext,
            AuthorizationCodeTokens tokens,
            String idToken,
            SecurityIdentity securityIdentity)

because

                        JsonObject idTokenJson = OidcUtils.decodeJwtContent(idToken);

                        if (!idTokenJson.containsKey("exp") || !idTokenJson.containsKey("iat")) {
                            LOG.error("ID Token is required to contain 'exp' and 'iat' claims");
                            throw new AuthenticationCompletionException();
                        }
                        long maxAge = idTokenJson.getLong("exp") - idTokenJson.getLong("iat");
                        LOG.debugf("ID token is valid for %d seconds", maxAge);
                        if (configContext.oidcConfig.token.lifespanGrace.isPresent()) {
                            maxAge += configContext.oidcConfig.token.lifespanGrace.getAsInt();
                        }
                        if (configContext.oidcConfig.token.refreshExpired) {
                            maxAge += configContext.oidcConfig.authentication.sessionAgeExtension.getSeconds();
                        }

So, finally, a dummy token with exp and iat can be used ...

[sberyozkin]

@DCCSKrezovic

You say it's possible to use IdToken until it's expired ... But what about simply keeping the initial one in the SecurityIdentity somewhere?

quarkus-oidc is stateless. So only uses cookies by default. The cookie is constrained by the ID token life time plus the extra time which can be configured.

We still need to access the IdToken claims, our userinfo endpoint does not return everything IdToken provides.

I'm sorry, but while quarkus-oidc tries its best to support various custom scenarios, it can't just somehow keep the ID token which has expired and use this expired token for the authentication or RBAC decisions. If you only have IdToken returned once, and UserInfo is not enough, then as I said, the best IMHO to get the user redirected eventually to the provider to get a new IDToken.

Or you can have a custom SecurityIdentityAugmentor where you get the id token (cast SecurityIdentity.getPrincipal to JsonWebToken and save what is needed, example, the raw content, in your own custom cookie) or something like that - quarkus-oidc can't use an expired ID token, if it does, then the whole verification gets compromised, this token may have been around for a year and we will just keep accepting it, hope you appreciate it.

I'll take care though of NPE which happens when the RT grant request returns no ID token to make sure a synthesized ID token can be used

[DCCSKrezovic]

@sberyozkin The NPE fix is sufficient, thanks.

[sberyozkin]

@DCCSKrezovic It might also make sense to store the original id tokens claims in the internally generated one if no ID is returned with the RT grant response, but I'm not sure how easy/feasible it will be. See #29144

[DCCSKrezovic]

@sberyozkin one additional bug I may have found, but not sure if the approach I'm taking is right ...

In the back channel logout handler, the ID Token is once more verified against the JWT provided by the back channel logout initiator.

Is it possible to use dummy token, or to skip verification against ID token altogether? After all, checking the JWT against ID token is optional by OpenID spec.

[sberyozkin]

@DCCSKrezovic, can you open please another discussion related to the back channel logout ? (IMHO it is the right thing to do, verify the logout token and ID token has been issued by the same issuer, etc, spec makes it optional but it is a Back channel callback provider's choice which Quarkus makes - not sure why you call it a bug)

[DCCSKrezovic]

@sberyozkin the backchannel issue is for the case when IdToken is not present, which is what this thread is about. That's why I call it a bug. It will simply throw a NPE, since claims required for verification are not present in the "internal" token.