Replies: 1 comment 1 reply
-
|
Just want to link to an other discussion #8599. This also includes the problem of removing the role claim from the access token by configuration and looking them up internally at Keycloak (similar to 1.: Make an access token "handle token", Use Token Introspection endpoint to get its contents. ). In this discussion we also don't have a conclusion how to achieve it. Option 1 would probably ease solving #8599 if it as flexible as having some claims in the access token and others only at the introspection endpoint. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, as you said, it might be OK to select which claims are included in an access token and token introspection response separately, independently. I've shown the similar idea in FAPI-SIG's 26th meeting but I've not yet put it to keycloak's discussion (FAPI-SIG is an open community whose aim is to support FAPI and its related specification to Keycloak). I do not know how difficult to realize it but I am afraid that it may causes some performance degrade mentioned in page 10 of FAPI-SIG's 26th meeting's agenda above. It may be a solution to both your pointing discussion and this discussion. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Motivation
Current keycloak issues an access token so called "assertion token" because Keycloak puts information onto an access token.
An access token is sent to a client at first and the client sends it to a resource server. Therefore, Keycloak, the client and the resource server can know the information in the access token at least (assume no leakage of the access token).
In some cases, it is preferable that anyone other than Keycloak and the resource server cannot know the information in the access token. For example, consider open banking use case. The bank manages Keycloak as an authorization server and a resource server with APIs providing financial services. The bank put some information in an access token used for access control in the resource server. It is adequate for Keycloak and the resource server to know this information. It is not needed for others to know it.
Proposal
To hide the contents in the access token, there are the following three options.
Option 1 might be difficult because current Keycloak itself does not hold the information in the access token. To support handle token, Keycloak needs to hold the information in the access token. It needs a lot of work to realize it.
There is JIRA ticket for supporting handle token but not yet been resolved.
Option 2 and 3 might be plausible because Keycloak has already supported JWE so that the current access token can be encrypted by JWE.
There is JIRA ticket for access token encryption but not yet been resolved. There are some PRs trying to support it but have not yet been completed.
IMO, option 3 might be easy to realize compared with option 2 because encrypting and decrypting in symmetric-key algorithm might be easy to realize compared with asymmetric-key algorithm. However, on Token Introspection endpoint, Keycloak checks whether the sender of the access token is the one Keycloak issued for.
Are there someone who interested in this topic?
Beta Was this translation helpful? Give feedback.
All reactions