Description
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
Activity
NickMeves commentedon Oct 9, 2020
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.gboor commentedon Oct 12, 2020
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!
carabj commentedon Oct 12, 2020
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.
NickMeves commentedon Oct 12, 2020
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-headersoption (flip to false). And maybe forward the bearer header with--pass-authorization-headerhttps://oauth2-proxy.github.io/oauth2-proxy/configuration
NickMeves commentedon Oct 12, 2020
@JoelSpeed Tossing you on this one since you are handling the header refactor at the moment.
JoelSpeed commentedon Oct 12, 2020
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.carabj commentedon Oct 12, 2020
JoelSpeed commentedon Oct 28, 2020
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?
gboor commentedon Nov 28, 2020
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?
45 remaining items