UserInfo request fails by using an access token obtained in Hybrid fl…#39183
Merged
ahus1 merged 1 commit intokeycloak:mainfrom Apr 25, 2025
Merged
UserInfo request fails by using an access token obtained in Hybrid fl…#39183ahus1 merged 1 commit intokeycloak:mainfrom
ahus1 merged 1 commit intokeycloak:mainfrom
Conversation
…ow with offline_access scope closes keycloak#39037 Signed-off-by: mposolda <mposolda@gmail.com>
a1f0bd7 to
ef26a17
Compare
Contributor
|
@mposolda Thank you for sending the PR. I wil review it. Also, I would like to run the OIDC conformance tests against the Keycloak including the PR to confirm that the Keycloak can pass the tests. I will notify you of its test results, so please wait for that. |
Contributor
Author
Contributor
|
@mposolda I ran not only OIDC but also FAPI1, FAPI2, FAPI-CIBA, OIDC logout conformance tests against the Keycloak built from the branch of the PR and confirmed that the Keycloak can pass all the conformance tests. |
tnorimat
approved these changes
Apr 25, 2025
ahus1
approved these changes
Apr 25, 2025
Member
ahus1
left a comment
There was a problem hiding this comment.
Approving based on previous reviews.
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…ow with offline_access scope
closes #39037
Problem: When there is hybdrid flow requested (the request sent to OIDC authentication endpoint with something like
response_type=code token) together with offline access requested (thescope=offline_access), there are access-tokens (and possibly ID tokens etc) issued from the OIDC authorization response. When these access-tokens are sent to KEycloak endpoints (like UserInfo endpoint or Introspection endpoint) before thecodefrom authz response is exchanged for another set of tokens (in the code-to-token request),the requests fails.Cause: Before OIDC authentication response is sent back to the client after successful authentication, Keycloak creates only regular "online" user session. Then during code-to-token request (processed by
AuthorizationCodeGrantType), the online session is possibly removed and there is instead offline user session created. So when the request is sent to UserInfo endpoint with the token from OIDC authentication response, before the code-to-token request, the offline user session does not yet exists. With the changes from #37662, Keycloak is now more opinionated as it knows that access-tokens is associated with the offline-session and hence tries to lookup only offline-session (not "online" session). Which fails as offline session does not yet exists.The approach I've used in the PR is to create offline session at the end of the OIDC authorization code flow in case that "hybrid" flow is used. In that case, UserInfo can be successfully invoked even before code-to-token request as offline session already exists.
The alternative approach I was considering was to create offline session still as before in the code-to-token request. But instead possibly introduce another type of
AccessTokenContext.SessionType, which will allow to lookup both offline or online session. In that case, access-token will be able to fallback to lookup online session in case that offline session does not yet exists. Let me know if you prefer this approach. It would have advantage that does not need to create offline session earlier than needed (as it is really needed just when refresh offline token is going to be issued), but it would make a code a little bit more complicated than necessary.