✨(oidc) add support for generic OIDC IdPs and OIDC clients as users #633
Open
piptouque wants to merge 4 commits into
Open
✨(oidc) add support for generic OIDC IdPs and OIDC clients as users #633piptouque wants to merge 4 commits into
piptouque wants to merge 4 commits into
Conversation
added 4 commits
June 15, 2026 11:23
The 'aud' claim may be a list: https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3 The 'exp' and 'iat' claims are `NumericDate` and may be floats: https://www.rfc-editor.org/rfc/rfc7519#section-2
The server should ignore any OAuth 2 scope that it does not know, instead of returning an error.
The ID token and access token are different and have different purpose. The ID token is always a JWT and contains user claims, but the access token may not be. With this change, we get the user claims using the access token, using the /userinfo OIDC enpoint, allowing us to support providers that return opaque access tokens.
Client applications, as authenticated with the 'client_credentials' flow, do not have a dedicated user. As such, we can't get ID tokens for them, always opaque access tokens. Instead, we authenticate them using their client_id. But first, we need to check whether the access token we got was from a real oauth2 user or a client app. To do that, we query the /introspection endpoint of our IdP. This requires that Ralph be registered s another client app to our IdP, and to have configured its client ID and secret.
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
1 participant
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.
Purpose
This PR contains multiple changes regarding OIDC
Fixes
NumericDateand may be floatsChanges
Support for generic OIDC IdPs
More specifically, support for IdPs that return a token that is not a JWT.
The ID token and access token are different and have different purpose.
The ID token is always a JWT and contains user claims, but the access token may not be.
With this change, we get the user claims using the access token,
using the
/userinfoOIDC endpoint, allowing us to support providers that return opaque access tokens.Support OIDC clients as 'users'
Client applications, as authenticated with the 'client_credentials' flow, do not have a dedicated user.
As such, we can't get ID tokens for them, always opaque access tokens.
Instead, we authenticate them using their
client_id.But first, we need to check whether the access token we got was from a real Oauth2 user or a OIDC client application.
To do that, we query the
/introspectionendpoint of our IdP.This requires that Ralph be registered as another client app to our IdP, and to have configured its client ID and secret.
Proposal
IDTokennot following specs onaud(may be a list),expandiat(may be floats)/introspectionendpoint when receiving an OIDC access token to determine if it comes from a ODIC client application or a user/userinfoendpoint when receiving an OIDC access token if that token represents a userCHANGELOG.md