Token refresh doesn't re-execute issuer.success() to update dynamic user attributes

[Jhinger]

When using the client.refresh() method, the access/refresh tokens are rotated but the content within the token is not refreshed. This prevents dynamic user attributes that are fetched during the initial issuer.success() method from being updated during token refresh operations (without having the user go through the authentication flow again).

Current Behaviour:

• Initial token generation in issuer.success() dynamically fetches user attributes from Redis
• Token refresh via refresh() rotates the token but preserves the original claims

Use Case:

• I'm storing some dynamic user attributes (permissions, roles, profile data) in Redis that can change independently of the authentication session. When tokens are refreshed, I'd like for these updated values to be included in the new access token to maintain accurate auth context.

I've reviewed the client documentation and don't see an existing method/flow to achieve this behaviour. I'm hoping I'm not missing some obvious solution or doing something fundamentally wrong in my approach. Any guidance would be greatly appreciated!

[bodhihawken]

i was very surprised this didn't refresh token data, i believe refreshing token data here is standard practice

[sebaxj]

When using external OAuth providers such as Google or GitHub, it would be nice for the OpenAuth refresh token flow to also refresh the platform-specific access tokens. Similar to your observation, @Jhinger , any information we store in the payload properties on the first authorization success simply is reused on all existing token refreshes.

Proposed behavior:

• Add a "refresh" flow to OAuth providers.
• When an OpenAuth access token is refreshed and the payload contains a valid OAuth provider and provider refresh token, refresh that provider's access token and update the access token payload properties.

[nowlena]

I believe this is the same issue I am having?

• I need a way to allow a customer to auth with an undefined "workspaceID" or "orgID"
• then later update that same session with a "workspaceID" or "orgID" value (without performing auth flow again)

[tunnckoCore]

It's specifically documented in the docs.

But yeah, i agree and I'm for it too.