Invalid or expired refresh token , invalid grant after async service call

[adziri]

Hello,
I'm using quarkus oidc for authentication. Our idp generates tokens with short validity (5min). So I'm using the following configuration to refresh the access token. I can see in the logs that it's refreshed successfully every 3min ( 2min before expiration).

`quarkus.oidc.application-type=web-app
quarkus.oidc.auth-server-url=https://idp.url.com
quarkus.oidc.introspection-path=.well-known/openid-configuration
quarkus.oidc.client-id=[client-id]
quarkus.oidc.credentials.secret=[secret]
quarkus.oidc.authentication.scopes=openid,profile,groups
quarkus.oidc.authentication.redirect-path=/callback
quarkus.oidc.authentication.restore-path-after-redirect=true
quarkus.oidc.authentication.pkce-required=true

quarkus.oidc.authentication.id-token-required=false
quarkus.oidc.authentication.user-info-required=true
quarkus.oidc.token.refresh-expired=true
quarkus.oidc.token.refresh-token-time-skew=2m

quarkus.http.auth.permission.authenticated1.paths=/*
quarkus.http.auth.permission.authenticated1.methods=GET,POST,PUT,DELETE
quarkus.http.auth.permission.authenticated1.policy=authenticated`

However, when I trigger an asynchronous service call , I got the following exception. Even though, the token continue to be refreshed successfully. Any idea please ?

2024-03-07 17:54:59.748 ERROR [vert.x-eventloop-thread-0,] i.q.v.h.r.QuarkusErrorHandler:127 - HTTP Request to /service/api?path=import&async=true failed, error id: 1234: io.quarkus.oidc.OIDCException: {"error_description":"unknown, invalid, or expired refresh token","error":"invalid_grant"}     at io.quarkus.oidc.runtime.OidcProviderClient.responseException(OidcProviderClient.java:204)     at io.quarkus.oidc.runtime.OidcProviderClient.getJsonObject(OidcProviderClient.java:188)     at io.quarkus.oidc.runtime.OidcProviderClient.getAuthorizationCodeTokens(OidcProviderClient.java:168)     at io.quarkus.oidc.runtime.OidcProviderClient.lambda$refreshAuthorizationCodeTokens$4(OidcProviderClient.java:124)     at io.smallrye.context.impl.wrappers.SlowContextualFunction.apply(SlowContextualFunction.java:21)     at io.smallrye.mutiny.operators.uni.UniOnItemTransform$UniOnItemTransformProcessor.onItem(UniOnItemTransform.java:36)     at io.smallrye.mutiny.operators.uni.UniOperatorProcessor.onItem(UniOperatorProcessor.java:47)     at io.smallrye.mutiny.operators.uni.UniOperatorProcessor.onItem(UniOperatorProcessor.java:47)     at io.smallrye.mutiny.vertx.AsyncResultUni.lambda$subscribe$1(AsyncResultUni.java:35)     at io.smallrye.mutiny.vertx.DelegatingHandler.handle(DelegatingHandler.java:25)     at io.vertx.ext.web.client.impl.HttpContext.handleDispatchResponse(HttpContext.java:397)     at io.vertx.ext.web.client.impl.HttpContext.execute(HttpContext.java:384)     at io.vertx.ext.web.client.impl.HttpContext.next(HttpContext.java:362)     at io.vertx.ext.web.client.impl.HttpContext.fire(HttpContext.java:329)     at io.vertx.ext.web.client.impl.HttpContext.dispatchResponse(HttpContext.java:291)     at io.vertx.ext.web.client.impl.HttpContext.lambda$null$7(HttpContext.java:507)     at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:264)     at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:246)     at io.vertx.core.impl.EventLoopContext.lambda$runOnContext$0(EventLoopContext.java:43)     at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)     at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)     at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)     at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566)     at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)     at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)     at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)     at java.base/java.lang.Thread.run(Thread.java:829)

[sberyozkin]

@adziri Hi

Can you check what is sent in the refresh token grant, see:
https://github.com/quarkusio/quarkus/blob/main/extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcProviderClient.java#L196

Also, while it is unlikely to be related, quarkus.oidc.introspection-path=.well-known/openid-configuration does not look correct. Setting this property is only needed if you expect the remote token introspection, the discovery process is done automatically by appending .well-known/openid-configuration to quarkus.oidc.auth-server-url property value.
quarkus.oidc.authentication.id-token-required=false is only relevant if your provider does not return them but it looks like it does in your case.

[adziri]

Hi @sberyozkin , thanks for your reply.
When I append .well-known/openid-configuration to server url and remove quarkus.oidc.introspection-path, it stops working. It doesn't construct the correct url to be sent to IdP.
Here's the out put of OidcProviderClient.java
2024-03-08 20:15:04.644 DEBUG [vert.x-eventloop-thread-1,] i.q.o.r.OidcProviderClient:158 - Get token on: https://idp.com/token.oauth2 params: grant_type=authorization_code code=... redirect_uri=... code_verifier=... headers=... authorization=Basic ....

When I comment these 2 lines, the token doesn't refresh
quarkus.oidc.authentication.id-token-required=false
quarkus.oidc.authentication.user-info-required=true

[sberyozkin]

@adziri

When I append .well-known/openid-configuration to server url and remove quarkus.oidc.introspection-path, it stops working. It doesn't construct the correct url to be sent to IdP.

Sorry, I meant to say Quarkus does itself, you don't need to append it. So just remove the introspection path property.

2024-03-08 20:15:04.644 DEBUG [vert.x-eventloop-thread-1,] i.q.o.r.OidcProviderClient:158 - Get token on: https://idp.com/token.oauth2 params: grant_type=authorization_code code=... redirect_uri=... code_verifier=... headers=... authorization=Basic ....

These are the authorization code flow parameters, but your stacktrace says you have the refresh grant in action

When I comment these 2 lines, the token doesn't refresh
quarkus.oidc.authentication.id-token-required=false
quarkus.oidc.authentication.user-info-required=true

May be because ID token is valid ? Maybe you can create a simple reproducer ?

[adziri]

hi @sberyozkin

Form the logs , I can see that the token refresh failed because it's not valid

2024-03-10 05:57:38.430 DEBUG [vert.x-eventloop-thread-0,] i.q.o.r.OidcIdentityProvider:308 - Token verification has failed: JWT (claims->{"sub":"...","aud":"3...","jti":"....","iss":"...","iat":11111,"exp":1710050257,"auth_time":1710049956,"MudId":"12345","DisplayName":"John Doe","GivenName":"John","groups":"Administrators","email":"[email protected]"}) rejected due to invalid claims or other invalid content. Additional details: [[1] The JWT is no longer valid - the evaluation time NumericDate{1710050258 -> Mar 10, 2024, 5:57:38 AM UTC} is on or after the Expiration Time (exp=NumericDate{1710050257 -> Mar 10, 2024, 5:57:37 AM UTC}) claim value.]

It's complaining about groups claim being sent as String instead of List

2024-03-10 05:57:32.029 WARN [executor-thread-2,1710049856-67] i.s.j.a.principal:87 - SRJWT08001: getGroups failure: : org.jose4j.jwt.MalformedClaimException: The value of the 'groups' claim is not the expected type (Administrators - Cannot cast java.lang.String to java.util.List)

The software that I'm using is based on Quarkus 2.14.2.Final and I thought you merged a fix for the same issue some time ago (#7618)

[sberyozkin]

@adziri Hi, what I'm confused about is that the issue you reported in this discussion is related to the use of quarkus-oidc. Even in your last message OidcIdentityProvider reports the token has expired (this is not related to the error you reported in the discussion - it just says the token has expired which likely leads to the token refresh request which you see failing).

The last warning is not related to the problem of the token refresh at all and it is coming from smallrye-jwt (the case where groups is only a string is tested AFAIK, so I'd like to see a reproducer related to the use of smallrye-jwt), but, quarkus-oidc does not use that smallrye-jwt code for checking the role claims, and, as you can see from https://github.com/quarkusio/quarkus/blob/main/extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcUtils.java#L273, I expect the groups String claim correctly processed.

I think without a reproducer it will be difficult to suggest anything concrete for you to resolve the problem...
I'd also encourage you to try to migrate to the latest versions

[adziri]

@sberyozkin First issue happens with this config

quarkus.oidc.authentication.id-token-required=false quarkus.oidc.authentication.user-info-required=true quarkus.oidc.token.refresh-expired=true quarkus.oidc.token.refresh-token-time-skew=2M

Second issue happens with this one

quarkus.oidc.authentication.id-token-required=true quarkus.oidc.authentication.user-info-required=true quarkus.oidc.token.refresh-expired=true quarkus.oidc.token.refresh-token-time-skew=2M

I'm using a third party platform based on Quarkus 2.14.2.Final. On my side I'm just trying to make sure that the config I'm using to enable SSO between our IdP (PingFederate) and this platform is correct.

Our idP doesn't return the ID token. That's why I used "quarkus.oidc.authentication.id-token-required=false". This is to answer your comment "quarkus.oidc.authentication.id-token-required=false is only relevant if your provider does not return them but it looks like it does in your case."

Do you have an example of a reproducer to follow ?

Thank you!

[sberyozkin]

@adziri Lets see what we can do. First, I think you should give it a try and update the platform to use one of the recent Quarkus versions. Clearly something does not work in the 2.14.2 based solution - but there is no way to get it fixed, there will be no next 2.14.x release.
So, please try to migrate to the later version - there is better logging support, more fixes in later versions. Do it even if you don't plan to migrate the production based application, but at least to see what really works and what does not in the latest version.

For example, the latest stacktrace shows ID token is not refreshed If the refresh token grant does not return an ID token (as would be the case with the OAuth2 providers).
Here is how it is managed in 3.8.2:
https://github.com/quarkusio/quarkus/blob/3.8.2/extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java#L1237
and in 2.14.2:
https://github.com/quarkusio/quarkus/blob/2.14.2.Final/extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/CodeAuthenticationMechanism.java#L974

As you can see, in the 3.8 case, if the ID token is internal (i.e, generated by Quarkus when no ID token is returned by the OAuth provider), Quarkus regenerates it - but it does not happen in the 2.14.2 case.

So please update your provider to the latest Quarkus and then we can see what works and what has to be fixed

[sberyozkin]

My analysis of the difference in behavior related to the token refresh case was not correct, I got confused, but in any case, the code is different.
Updating to the latest version and focusing on one issue at a time will help us move forward