How to identify access tokens generated by the same refresh token?

Get Help
,
1

Hello guys,

My use case is precisely as discussed by @larsf96 in a previous thread (persistent-custom-claims-in-access-token-when-using-refresh-tokens/111268). Wasn’t allowed to add the actual link–sorry about that.

@rueben.tiow partially answered (will-access-tokens-received-via-refresh-token-contain-the-custom-claims/131015) but this does not cover the use case mentioned by @larsf96:

[…] we will create an internal couplingID during the first token exchange and we want to store the couplingID in the access token and want to persist it even during refresh token exchanges.

Imagine the couplingID is randomly generated during the first token exchange (e.g. converting the authorization code into access and refresh tokens) and set as a custom claim on the first access token. The goal is to keep setting the same couplingID on all access tokens that are generated by the same refresh token. For this we need to store the couplingID in the app metadata against some unique identifier (ideally the refresh token or its ID). However, I couldn’t find a unique identifier that remains the same across all the token exchanges performed with the same refresh token. I noticed that in post-login there is event.refresh_token.id which could acts as the unique identifier–however this is not available in the first token exchange which is when the couplingID is generated… Therefore, there does not seem to be a way of persisting the couplingID across token refreshes.

Simply running the same action without conditionals on each token exchange (as @rueben.tiow mentioned) is not an option as a different couplingID would be generated for each access token–which defeats the goal.

This seems quite a big limitation as it prevents the API receiving requests authorized with access tokens generated by the same refresh token to be grouped together (via the couplingID custom claim). Is there a way around it?

This is quite urgent for our company so please let me know :slight_smile:

Summary

This text will be hidden

3

Hi @massimoalbarello,

Thanks for your question.

As you discovered, the best approach is to use a post-login action to set the same couplingID as a custom claim in the access token. Once it’s added, the custom claim will persist across every access token request, including the first one.

If you need a unique identifier to help you with saving the couplingID in the app_metadata, you could try using the event.session.id property.

Does that help?

Kind regards,
Rueben

4

Hello @rueben.tiow,

I’m logging event.session every time the post-login action is executed. It seems that event.session is defined when i call the /authorize endpoint but every time I refresh the token it is undefined…

Also, I need an id that is unique per user authorization. I noticed that if the user calls /authorize multiple times without logging out and logging back in in between, event.session.id stays the same in both authorizations, which is a problem as i cannot differentiate between the two.

If the refresh token id were available also when the authorization code is exchanged it would solve my problem but this is not the case unfortunately.

Is there another way?

5

I noticed that there is event.refresh_token.session_id which I could use to map the oauth2-refresh-token actions to the oidc-basic-profile one where event.session.id was first defined. However, it seems that in some refreshes event.refresh_token.session_id is undefined… Why is this the case?

Also, is it normal that the post-login action is not triggered when the authorization code is converted into an access token? I only see it being fired for oidc-basic-profile and oauth2-refresh-token but weirdly not for oauth2-access-token. Is this expected?

Thanks in advance