External to Internal Token Exchange validation behavior with JWT subject_token_type does not work as described within the documentation

[DenEwout]

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?

1. Setup keycloak with token exchanges enabled
2. Add an OIDC Identity Provider
3. Setup token exchanges
4. 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).

[mposolda]

Thanks for the report, but unfortunately due the amount of other reported issues and other priorities, Keycloak team does not have time to properly triage this bug. So preliminary added to Backlog for now.
It will be helpful if:

• You can verify if still applicable in latest Keycloak released version. If not, then it is welcome to close this issue.
• If you figure that this may not be a valid bug (for example just a mistake in configuration etc), it will be also welcome to close this issue
• If still applicable in latest version, it will be welcome to add the comment as well, that this was still reproduced with latest Keycloak version as it is very valuable info. Anyone is welcome to comment with this or add other relevant comments to this issue.

[keycloak-github-bot]

Due to the amount of issues reported by the community we are not able to prioritise resolving this issue at the moment.

If you are affected by this issue, upvote it by adding a 👍 to the description. We would also welcome a contribution to fix the issue.

[mposolda]

Thanks for the report. We may prioritize this once we work on promoting "token exchange" feature from preview, which can be maybe somewhen in 2025. Until that, anyone is welcome to send the PR with the fix.