OIDC Client refresh token reuse or initialize with previously saved refresh token

[ayhanap]

So here is my use case, which is very common I assume;

1. I am letting a user authenticate through an oauth2 provider to let my application access his resources. Which is auth code flow.
2. I use the code to get access and refresh tokens. (I set the code to oidc-client parameters dynamically)
3. Everything works ok. I can access resources now. But I want to get refresh token and save it in my db which I think I can do with a filter and injecting Tokens object.
4. So this session ends and at a later time I want to use those tokens to access resources again, presumably my application lifecycle already ended and a new instance started. How can I initialize OIDC Client with the previous refresh token? (If I cannot do this, I have to let the user go through auth flow again which is not possible and unwanted)

So been through every issue and pretty much every source code of oidc-client. How to initialize an OidcClient with a previous refreshToken?

[quarkus-bot[bot]]

/cc @pedroigor (oidc), @sberyozkin (oidc)

[sberyozkin]

@ayhanap If you use OidcClient directly to acquire code flow tokens and would like to use the returned refresh token, then you need to have another OidcClient instance initialized to handle a refresh token grant - and pass the saved RT to this client.

Have you considered using quarkus-oidc (https://quarkus.io/guides/security-oidc-code-flow-authentication) instead of dealing with the code flow directly in the application ?

[ayhanap]

@ayhanap If you use OidcClient directly to acquire code flow tokens and would like to use the returned refresh token, then you need to have another OidcClient instance initialized to handle a refresh token grant - and pass the saved RT to this client.

This is close to what was in my head but it is still hard to visualize. I am also trying to use openapi-generator plugin.

Have you considered using quarkus-oidc (https://quarkus.io/guides/security-oidc-code-flow-authentication) instead of dealing with the code flow directly in the application ?

I am not trying to protect my application. My application already has it's own jwt based auth mechanism. I am just trying to access external APIs which protected by OAuth2, like jira API on behalf of my users. (It's a SaaS app). I think this is is out of scope, if am not mistaken?

[sberyozkin]

@ayhanap This test shows how to use the RT directly if you prefer to avoid quarkus-oidc:

1. RT is coming in as a query parameter - or from DB, etc
   https://github.com/quarkusio/quarkus/blob/main/integration-tests/oidc-client-wiremock/src/test/java/io/quarkus/it/keycloak/OidcClientTest.java#L112
2. This token is used to refresh tokens:
   https://github.com/quarkusio/quarkus/blob/main/integration-tests/oidc-client-wiremock/src/main/java/io/quarkus/it/keycloak/FrontendResource.java#L65
3. Client is configured like this:
   https://github.com/quarkusio/quarkus/blob/main/integration-tests/oidc-client-wiremock/src/main/java/io/quarkus/it/keycloak/FrontendResource.java#L65

In general, quarkus-oidc is recommended, if the reason you can't use is that it can't handle something then please open an enhancement request. Though, managing the code flow directly may give some extra options - but indeed, it will require dealing with the token refreshment etc...

[sberyozkin]

@ayhanap

I am not trying to protect my application. My application already has it's own jwt based auth mechanism. I am just trying to access external APIs which protected by OAuth2, like jira API on behalf of my users.

OK. So your endpoint is protected by the custom JWT mechanism, and after the token is verified, you'd like to propagate it to the external service, right ?

In that case I'm not sure why you would like to use OidClient to support the authorization code flow grant. If you have to propagate the existing token, then OidcClient is f no help, OidcClient is about propagating tokens it has acquired itself.

It sounds like Token Propagation is what you are after:

https://quarkus.io/guides/security-openid-connect-client-reference#token-propagation-reactive

with this feature you just @AccessToken to the rest client (ex, JiraApiRestClient) and it works.
Now, the only catch, if you do not use quarkus-oidc or smallrye-jwt, is that your application needs to provide a TokenCredential producer, like this one: https://github.com/quarkusio/quarkus/blob/2da3206ca8727497680fb578cf78df652c0749e8/extensions/smallrye-jwt/runtime/src/main/java/io/quarkus/smallrye/jwt/runtime/auth/JsonWebTokenCredentialProducer.java

Does it help ?

[ayhanap]

Actually, my application security is out of context atm. It's not related to the 3rd party API I am trying to access.

I am just accessing jira rest api with oidc-client. Jira's authentication has no relation to my application security. And i am using OidcClientRequestReactiveFilter which gets its config from application.properties

quarkus.oidc-client.client-enabled=false
quarkus.oidc-client.OAuth2.auth-server-url=https://auth.atlassian.com/authorize
quarkus.oidc-client.OAuth2.discovery-enabled=false
quarkus.oidc-client.OAuth2.token-path=https://auth.atlassian.com/oauth/token
quarkus.oidc-client.OAuth2.credentials.client-secret.value=.....
quarkus.oidc-client.OAuth2.credentials.client-secret.method=post
quarkus.oidc-client.OAuth2.grant.type=code
quarkus.oidc-client.OAuth2.grant-options.code.code=....

So with this configs, oidc-client can get initial AT and RT with quarkus.oidc-client.OAuth2.grant-options.code.code (Actually this is a 5 min code token which is given after a user manually gives permission through web page, anyway this is not important). After I got AT and RT I don't wan't to use code again which is already expired anyway. I need to use AT and RT and continue using the API with these AT and RT.

But there is no way for me to initialize OidcClientRequestReactiveFilter with tokens. I will try a custom request filter but AbstractTokensProducer and TokensHelper classes are very conservative about their internal private fields for me to set tokens.

I think with a custom request filter I can inject OidcClient and set RT and refresh tokens with Uni<Tokens> refreshTokens(String refreshToken); method but I also would like to set AT because refreshin before AT is expired can cause problems.

What I need basically is way to set initial Tokens object at TokensHelper or AbstractTokensProducer.

I will try to write a custom filter without extending AbstractTokensProducer to see what can be done and let you know.

[sberyozkin]

@ayhanap I see.
Sure, I you need to get hold of the RT returned by OAuth2 named client - then the only way to do it is to use this Oidc Client directly, so you can have named Tokens injected and pass its access token to the Jira client, perhaps as a Bearer + AT value of this Jira client's Authorization header parameter.
And as I said earlier, you need to have another OIDC client configured to use the RT grant only, see the links I provided. So when you need to, you can pick up the refresh token from the Tokens prepared by the OAuh2 client and use this second client to pass this RT.

Something like that should do

[sberyozkin]

Or may be you don't need the 2nd RT client at all, or even use OidcCient directly, since OidcClient injected in the filter will refresh the token itself - if the current access token has expired or nearly expired (set the refresh token skew) - the RT will be used to get a new pair of AT and RT. Sorry, I have to admit I'm not quite following the use case, please experiment more and let me know how it goes

[ayhanap]

Yes as far as I see it can refresh without second client. I was mostly trying to see options without extending anything but that seems not possible. I will try to write a custom filter as I explained above tonight and see how it goes. As for the use case, I found it surprising this looks like an edge case, because this is what you need to do if you call a 3rd party api with oauth2. Actually the real edge use case is the next step after I achieve this, I need to dynamically use same 3rd party api for different users/customers, each having seperate code/tokens etc. Didn’t mention this to complicate things.

…

On 22 Jul 2023 Sat at 23:29 Sergey Beryozkin ***@***.***> wrote: Or may be you don't need the 2nd RT client at all, or even use OidcCient directly, since OidcClient injected in the filter will refresh the token itself - if the current access token has expired or nearly expired (set the refresh token skew) - the RT will be used to get a new pair of AT and RT. Sorry, I have to admit I'm not quite following the use case, please experiment more and let me know how it goes — Reply to this email directly, view it on GitHub <#34932 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJR7V32WAAC4XBXDOU33JTXRQZ2LANCNFSM6AAAAAA2T24TYE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sberyozkin]

@ayhanap

As for the use case, I found it surprising this looks like an edge case,
because this is what you need to do if you call a 3rd party api with
oauth2.

I feel may be we are misunderstanding each other a bit, but sometimes it can take awhile to get shared understanding.
Calling a 3rd party api is straightforward directly via OidcClient or via token propagation in Quarkus, there is nothing edge case like about it - it is used and demoed.

In your case - you have an endpoint attempting to manage the communication with OAuth2 server using an authorization code flow, which is not related to the authentication of this actual endpoint - I have to admit it does not make sense to me - but I know - this is because I'm missing something in what you are trying to achieve. If one does the authorization code flow - it means the users are being authenticated into the current endpoint - but this is not the right grant type to use if the endpoint needs to acquire the token and use to access something downstream without the users being redirected to authenticate etc. It is client credentials or password grants or other grants involving no user interaction have to be used.

If we look at your config:

quarkus.oidc-client.OAuth2.grant.type=code
quarkus.oidc-client.OAuth2.grant-options.code.code=....

It already looks wrong to me, sorry I did not pay attention earlier. code can't be configured - it is a totally dynamic thing, as I said earlier, you use directly with OidcClient only if you would like for the endpoint to manage the code flow itself to authenticate users.

May be this is where the confusion is coming from - looks like you should use another grant type.

Thanks

[sberyozkin]

@ayhanap FYI, see https://quarkus.io/guides/security-openid-connect-client-reference#other-grants about the use of the authorization_code grant. Example:

https://github.com/quarkusio/quarkus/blob/main/integration-tests/oidc-code-flow/src/main/java/io/quarkus/it/keycloak/UnprotectedResource.java#L62
https://github.com/quarkusio/quarkus/blob/main/integration-tests/oidc-code-flow/src/main/java/io/quarkus/it/keycloak/UnprotectedResource.java#L50

This imitates an endpoint managing the code flow itself - if for some reasons, quarkus-oidc does not work.
The client is configured here:
https://github.com/quarkusio/quarkus/blob/main/integration-tests/oidc-code-flow/src/main/resources/application.properties#L17

code can't be configured, it is a one-time use, very short-lived token representing an individual user's authentication.

Hope it clarifies it. I believe you need to use a different grant type.

[ayhanap]

@sberyozkin First of all thanks for trying to understand my problem.

My config had grant-options.code.code=.... statically just for the purpose of testing/dev, it comes from oauth2 redirect dynamically normally.

I will try to explain the flow again.

1. User logins to my application lets say via username/pass.
2. User tries to go a page where he can lets say list his jira issues. But because we don't have his permission we redirect him(or open a popup etc.) to jira oauth2 permission page with required scope etc..
3. User gives permission at that page and jira/atlassian redirects to my url with a code. This url is at my front-end but I pass this to my backend lets say /integrate-jira?code..
4. I use this code with OidcClient to exchange it with a AT/RT pair.
5. With these tokens I can now access to jira api on behalf of user and list his jira issues.
6. AT has 1 hour and RT has 90 days exp time, and I can refresh them indefinitely. So I want to save these tokens at somewhere, lets say it's my db.
7. Next time user goes to the page where he lists his jira issues, my front end calls my service which accesses jira api on behalf of the user. But this time I want to use AT/RT pair which I acquired previously and let it continue to refresh etc if needed. I create a new OidcClient with these tokens and I don't want the user to go give permission each time I access jira api on his behalf which is nonsense anyway.

I think at point 7 I need to initialize OidcClient with refresh_token grant. Which works mostly but only allows for me to get new pair of AT/RT with existing RT. (This would lead basically to throw away AT everytime I call my service) I will also try to create a custom filter to use previous AT until it fails (or check its exp time) then use new refresh_token grant OidcClient.

My confusion was mostly around that point 7 that at first I tought to reuse code grant which now is clear should be a refresh_token grant. I will finish coding today and see, but everything looks ok.

[sberyozkin]

@ayhanap I see, thanks, yeah, at point 7 - since the original OIDC client is about the dynamic code exchange, you likely need to have another one using the RT only (see the links above), but you can support this RT grant client with injected @Tokens from the first client which will give you RT. Something like that...
Give it a try please 👍

[sberyozkin]

@ayhanap sorry, just one more idea to explore, path based authentication, for paths requiring the user permissions one enables oidc. Might not work if at this point user must already be authenticated, but otherwise will replace manual oidc client based code flow management as quarkus oidc will handle everything itself, incl the session management

[ayhanap]

Ended up with these. (Had to do a lot of business coding before really trying complete flow)

• Two quarkus.oidc-client.xxxxx. configs, one for code flow, one for refresh flow. (This is already expected because of how oauth2 works)
• After I complete code flow, I save tokens at db.
• When trying to access the API later my rest-clients have a custom ResteasyReactiveClientRequestFilter where I inject an object holding tokens from db.
• At the custom filter, I first check if AT is expired, if not just add it as Bearer .. to header.
• If the AT is expired, I use injected OidcClient to use Uni<Tokens> refreshTokens(String refreshToken) method with the RT from my custom injected object holding RT. After getting the new tokens, I save them back to db then put AT to header as Bearer again.
• And repeat..

There is no way to use existing filters with refresh flow. (Even if there is, there is no way to init it with previously owned AT)

[sberyozkin]

@ayhanap Hi, missed your last comment:

There is no way to use existing filters with refresh flow. (Even if there is, there is no way to init it with previously owned AT)

I think, given the previous discussion is that we are talking about some specific and fairly involved case/setup.
We have tests confirming the token refreshment works and we've had users confirming it working - this is a key feature which must work.

Can you consider creating a reproducer ? I'll then have a look and we can make sure we are on the same line, as at the moment it feels like we are a bit out of sync :-)

[sberyozkin]

@ayhanap Actually, I have reread it, so the existing filters will refresh the tokens with the current RT they are aware of.

But, you are right, if you have an out of band refresh token saved in a DB, then, indeed, the filters are not aware of it, and therefore a customization is needed.

If you see in your current work that there is something that we can improve in this regard, please open an issue :-)

Thanks