oauth2-proxy
More fields in `/oauth2/userinfo`
Expected Behavior
The /oauth2/userinfo endpoint returns the email address (and I think one other field). It would be nice to have this configurable in a way to return more data from the underlying token in a configurable way.
Current Behavior
The /oauth2/userinfo endpoint does not return much info apart from email.
Possible Solution
Make it configurable which fields from the token are passed into this endpoint.
Context
The use case for this would be front-ends where you want custom fields out of the token to be readable by JS. I use Louketo at the moment to protect some front-ends and would like to switch. One of the things I do is read the user's theme settings from their token (theme depends on the group they are in, in keycloak). I do this via a similar endpoint in Louketo where the entire decoded token is available. That might be a bit overkill, but having the ability to add fields to the userinfo endpoint would be useful.
Your Environment
- Version used: v6.1.1
This is a good idea! I think we can potentially expose more data on the userinfo endpoint without needing to add in extra configurations too.
Potentially everything we make an X-Forwarded-* request header to upstreams from our session claims. Once we get support for adhoc IDToken Claims -> Headers support, we can likely make those automatically present on the userinfo endpoint.
That would certainly work for my case; I will use either the headers or the userinfo, but not both and cannot imagine I would need a different config on both. I'm also tracking the custom headers since I need those too. Should not be long now hopefully!
Hi,
I'm looking into the oauth2-proxy for our organization. I'm maintainer of our OIDC provider, and we use microservice infrastructure which uses OAuth2 bearer access tokens.
The oauth2-proxy looks like a nice fit to make it easy for our web app developers to integrate to our OIDC provider and not needing to develop the integration in their different flavours of backends.
We will only pass on access token to upstreams. If upstreams need additional info from user info endpoint, they will call the OIDC provider userinfo endpoint.
So I wonder if it will be required to forward the id token claims as X-Forwarded-* headers, to also expose them in the /userinfo endpoint? That would require us to pass on a lot of redundant headers, that could cause problems in infrastructure, just to being able to expose it to the frontend.
You can control the level of headers you send to the upstream with the various configuration options.
In your scenario, it sounds like you want to disable the X-Forwarded-* headers with the --pass-user-headers option (flip to false). And maybe forward the bearer header with --pass-authorization-header
https://oauth2-proxy.github.io/oauth2-proxy/configuration
@JoelSpeed Tossing you on this one since you are handling the header refactor at the moment.
I think supporting a configurable userinfo is a great idea, though I'd be hesitant to implement this just yet.
We have been discussing reworking the internals of the session storage to make this more configurable, so that users choose what makes up a session after we have a core selection of fields (eg user-id, groups), once that is done, we could easily make these exposed on the userinfo endpoint with some configuration that goes alongside this.
Thanks for your reply! Also, yet another option / possibility is to relay the information from the userinfo endpoint at the OIDC provider. I.e. when calling /userinfo at oauth2-proxy, it extracts the access token and calls the /userinfo endpoint at the OIDC provider. Then there is no need to configure in oauth2-proxy, which information should be exposed. That is already under configuration in the OIDC provider (usually same content that is passed on in id_token, but could also include more (or less) information). It would of course add latency on each such call.
On Mon, Oct 12, 2020 at 6:31 PM Joel Speed [email protected] wrote:
I think supporting a configurable userinfo is a great idea, though I'd be hesitant to implement this just yet.
We have been discussing reworking the internals of the session storage to make this more configurable, so that users choose what makes up a session after we have a core selection of fields (eg user-id, groups), once that is done, we could easily make these exposed on the userinfo endpoint with some configuration that goes alongside this.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/oauth2-proxy/oauth2-proxy/issues/834#issuecomment-707222884, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDRQ2NQLPF4GJIXTCXHKUTSKMVMXANCNFSM4SKFXLYA .
The idea of proxying that request is an interesting one, but would it not be better for the application to go directly to the IDP userinfo?
I think this was wrongfully closed. #850 adds groups and username, but nothing else. I specifically need custom claims in the userinfo. Or am I missing something here?
Looks like #850 went part of the way to resolving this issue, but at the moment, we don't really have a way to map custom claims through our session, so I'm not sure how we can resolve this in the short time short of just mirroring the whole ID Token into the userinfo (which may not be what users want)
Mirroring the whole ID token is what Louketo does and that suits my purposes, but it is a bit crude... Maybe that could be an optional setting? Like; "expose whole token on userinfo on/off"? I have some time to cobble together an MR over the coming week if that is useful.
I think there's a separate issue related to additional claims support and claim to header mapping? I'd need to scrounge it up, its definitely on our minds.
Our goal is to support adhoc claim mapping to an "extra fields" concept in the session. This then could tie to field to header mappings.
I have a PR I'm wrapping up the draft of that makes the OIDC claims logic more global so more providers than just OIDC can use it (Azure, Keycloak, Gitlab). That sets the stage for generalized claim extraction.
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I think we have all existing session fields exposed in the userinfo endpoint.
Adding anything new is blocked until we implement the adhoc claim->session field mapping feature we want.
I want to keep this completely mapped to supported session fields to keep it completely provider agnostic (vs dynamically extracting ID Token claims which would branch functionality only for the OIDC Provider which has an ID Token).
That way various providers can enrich the adhoc session fields in whatever way works for their particular use case, and we expose everything that was set on a session in the userinfo endpoint.
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
Any status update on this? Can we add custom claims to the endpoint now? If so; how?
Any status update on this? Can we add custom claims to the endpoint now? If so; how?
Nope, we still haven't added core support to extract adhoc IDToken claims to user sessions yet. That is a prerequisite for this.
Is there an issue I can track for adhoc claims? I'm running into this limitation now with injectRequestHeaders as well, which seems limited to the handful of things in the session instead of all claims.
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
are there any news on this topic? It would be great to have additional claims on the userinfo.
We are still working towards this, I have some work in flight that will make this easier to implement
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
#re-activate Hello, please do not close / inactivate the issue. It is still relevant and the workaround is more than nasty. (Reloading additional user data)
Thank you
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
This issue has been inactive for 60 days. If the issue is still relevant please comment to re-activate the issue. If no action is taken within 7 days, the issue will be marked closed.
