I have a custom-build OIDC client that normally connects to an identity provider built with IdentityServer3. Now I’m trying to migrate to Auth0.
Apart from some HS256/RS256 confusion, all I had to do was switch provider URL and enter the appropriate client ID and secret, and I could login an existing user using Auth0.
However, when the Auth0 user is new from the point of view of my application, the application needs to download the user’s profile via the userinfo endpoint.
The IdentityServer3-based provider returns claims such as given_name in the returned object, which if I read the OIDC spec correctly is expected:
How can I make Auth0 do the same thing?
Since I don’t really know how to edit the profile data in Auth0, I added given_name to user_metadata. But the result is that the userinfo response object contains user_metadata/given_name, and my client code doesn’t understand user_metadata.
Given you mention that the responses you’re currently obtaining from /userinfo contain user_metadata.given_name it suggests that you’re making use of legacy authentication flows. Although these flows are still available and there’s not yet a definitive sunset date for them if you’re starting out I would recommend going from the start with the new flows that offer additional alignment with the OIDC specification. In particular, with the new flows, both the ID token and /userinfo response will only contain standards claims or custom namespaced claims.
You can signal that your client application wants to make use of the OIDC compliant flows by going into the client advanced settings and enabling the OIDC Conformant toggle in the OAuth section. Have in mind that enabling this toggle won’t present an immediate solution to your problem, in some scenarios it could be argues that it would be worse because now the /userinfo endpoint will likely return less information. However, that’s a good thing because now you have more control about which information is exposed by default.
If you choose the OIDC conformant way and then perform an authentication with scope=openid profile, as given_name is one of the claims the client application will get access to when it includes the profile scope, you would likely not see any given_name information because at this time the claim will be populated either from a property with the same name at the root of the user profile object or from a property with the same name available at app_metadata. Root properties, in general, come directly from the identity provider, for example when you use Google authentication, so if you want to have management control over the given_name you can choose to store it within app_metadata which can be managed through the Management API.
Thanks! I found that by including values for standard claims such as given_name in app_metadata, I get the claims as root properties in the user profile.
Turning on OIDC Conformant causes the user profile endpoint to return less information, as you say. However, standard claims still become root properties, so the excessive information is not really a problem from my point of view.
I will continue to experiment with this. One question - you write “root properties, in general, come directly from the IdP”. I was under the impression that Auth0 can be the IdP. Is that not recommended?
Thanks! I found that by including values for standard claims such as given_name in app_metadata, I get the claims as root properties in the user profile.
Turning on OIDC Conformant causes the user profile endpoint to return less information, as you say. However, standard claims still become root properties, so the excessive information is not really a problem from my point of view.
I will continue to experiment with this. One question - you write “root properties, in general, come directly from the IdP”. I was under the impression that Auth0 can be the IdP. Is that not recommended?
Yes, Auth0 will also be the definitive IdP when you use database connections and if it’s a custom database connection then you even have some control over root properties, however, for something that works across the board, no matter the connection type app_metadata it’s what is currently available.