Help with forced update of access token

[pvannierop]

@ch4mpy This issue is not so much a bug report, but a request on whether the spring-addons tools are useful in this use-case.

My client uses keycloak IDP and adds roles to a user at some moments. I would like to trigger a refresh of the user principal in the same session when this happens. One way I see would be to manually update the keycloakSecurityContext in the Principal. Another would be to trigger a refresh of the access token with the normal OAuth2 workflow. Do your Authorities addons support any of these situations?

Please be aware that I am not very experienced in Spring Security so after reading the README of the relevant section it is not entirely clear to me what (if at all) your lib can do for my needs.

[ch4mpy]

Stackoverflow would be a better place for such questions (lot more audience).

There are a lot of different solutions depending on your use case (and maybe a little confusion).

• what do you call user principal ? java.security.Principal or the dirty shapeless Object returned by org.springframework.security.core.Authentication::getPrincipal ?
• do you have a clear picture (I mean a real drawing somewhere) of the roles and configurations of OAuth2 actors in your solution : authorization-server (ok, this is a Keycloak instance in your case), resource-server(s), client(s) (user agents such as browser & mobile app, trusted services, ...) and resource-owners (end-users) ?
• what kind of tokens and OAuth2 implementation have you configured? JWT with embedded authorities (authorities are defined on the Keycloak server, put in JWT claim when token is issued and resource servers just read it from the token)? Opaque tokens with introspection (claims are not embedded in the token, resource servers need to contact authorization server to obtain the claims associated with the token)? authorities retrieved by the resource-servers based on on a user identifier from the token (most probably the subject claim) ?
• do you have truly RESTful services (stateless) or do you keep some sort of server-side state (servlet sessions, distributed Redis state, or what so ever) ?

Considering your requirements, I would discourage a widely spread solution: authorities claim in a JWT. A JWT is sealed and self sufficient until its expiry which is programmed. There is no simple way to change the authorities it contains. If you want to change authorities the JWT holder is granted with, you basically have to wait until the token expires and the holder returns to the authorisation-server to get a new access-token.

This leaves you with at least two solutions:

• introspection: authorities management is centralized on the resource server and resource-servers submit the token to the authorization-server for each and every request (unless you setup some caching) to get the authorities.
• decentralized authorities management : each resource-server maintains its own authorities retrieval from a source of its choice (which could be an introspection server but also a relational-database, a key-value store or whatever).

You can find a sample for second option in this repo (samples involving JPA), but if your client requests a centralized authorities management on Keycloak server, this is not what you need and should consider introspection instead.

[pvannierop]

@ch4mpy Thank you for this great explanation! Especially your advise on the specific restrictions on authorities claim in a JWT is an eye opener. I will look further into introspection, since this seems to fit my usecase very well. Again, many thanks for taking the time to inform me.