We are using OIDC Authorization Code Flow and have implemented a server-side Token Manager that caches access tokens by user session. It offers a simple getValidAccessToken interface that will check if the user’s session has any tokens cached. If not, it requests /authorize re-direct to see if Okta already has an authenticated session which the Token Manager will then cache. If it has a token in the cache, it verifies the token. If valid, it returns it as a Jwt. Otherwise (e.g., if the token is expired), it will request (and cache) a new access token based on the user’s refresh token, cache the result and return that.
Problem Statement : When the underlying state of the user changes (e.g., add/drop membership in a group, signout), the cached token no longer reflects the user’s state. How do Token Manager’s (that may reside in multiple containers) discover these types of changes?
I’m curious if others have suggestions on best practices here. One simple option is to set very short access token times to force frequent refresh. But we have some cases where almost instant recognition of state changes are required.
So we are currently looking at having Token Manager’s basically subscribe to Okta Event Hooks and invalidate cache entries whenever say, a sign out event or add/drop group membership event happens.
Any other suggestions or experiences would be much appreciated!