External to Internal Token Exchange validation behavior with JWT subject_token_type does not work as described within the documentation
#14.922 aperta il 17 ott 2022
Metriche repository
- Star
- (34.398 stelle)
- Metriche merge PR
- (Merge medio 6g 19h) (384 PR mergiate in 30 g)
Descrizione
Describe the bug
Token exchanges with JWT as subject_token_type always attempt to validate via the userinfo endpoint instead of JWT signature validation, except when the userinfo endpoint is explicitly disabled.
I am wondering if this is working as intended, or has been documented wrong.
Version
19.0.2
Expected behavior
From the Keycloak docs:
For validation, if the token is an access token, the provider’s user info service will be invoked to validate the token. A successful call will mean that the access token is valid. If the subject token is a JWT and if the provider has signature validation enabled, that will be attempted, otherwise, it will default to also invoking on the user info service to validate the token.
Actual behavior
When a token with subject_token_type urn:ietf:params:oauth:token-type:jwt is sent, Keycloak attempts to make a validation with the user info endpoint except for when the user info endpoint is explicitly disabled on the Identity Provider.
How to Reproduce?
- Setup keycloak with token exchanges enabled
- Add an OIDC Identity Provider
- Setup token exchanges
- Perform an External to Internal token exchange
Anything else?
I bumped into this bug because I am using an OIDC Identity Provider that does not completely implement the OIDC specification. Specifically, they do not support calling the user info endpoint with an OAuth 2.0 Access Token. They only support a JWT for some reason.
It seems that Keycloak always calls the user info endpoint with the OAuth 2.0 Access Token, which results in errors when attempting token exchanges (eventhough according to the documentation it should not be attempted).