4

After authentication to OAuth2 authorization server that supports OpenID using response_type=code with scope=openid email, calling token endpoint should return id_token.

What I am missing is whether this id_token should contain email or not - and client should in such case call userInfo endpoint.

The spec says:

http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token.

To my understanding, this means that id_token does not need to contain email if access_token is available as userInfo should be called to get it. However looking at the implementation of oidc client in https://github.com/bitly/oauth2_proxy it seems they do require email claim to be available inside id_token without calling userInfo endpoint.

What is the correct behaviour in OpenID compliant authorization server?

Kaszaq
  • 997
  • 10
  • 16
  • I guess profile scope (claims) will define what to include in the id_token, resource scope (given claims mapping) defines what to include in the access_token – Jay Jun 20 '18 at 05:04

3 Answers3

1

The openid spec is more strict than what Google or Microsoft is doing (probably the rest of the providers as well but I didn't check). I guess oauth2_proxy kept the provider's behavior. Google for example, returning id_token with all the claims in the scope you request when exchanging code for access_token. But if you read their documentation they do specify the userInfo endpoint: https://developers.google.com/identity/protocols/OpenIDConnect

I think as long as you support all the endpoints, the desition whether to return id_token with all of the claims together with the access_token is up to you. It removes one extra call for the userInfo in most cases and it doesn't expose any vulnerability.

Boaz
  • 1,212
  • 11
  • 25
1

OpenID Connect Core says the id_token MAY contain other claims. Attributes are also optional in a SAML assertion. Some SaaS providers may object to the Userinfo API call (i.e. artifact in SAML). In the Gluu Server, we have a server level JSON configuration option for legacyIdTokenClaims. This is disabled by default--presenting code + client_creds at the token endpoint is better for security. If it's set to true, the Gluu Server will include the claims that correspond to the OpenID scopes specified for the client.

Mike Schwartz
  • 623
  • 5
  • 4
0

See also https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter

If not present, the default ID Token Claims are requested, as per the ID Token definition in Section 2 and per the additional per-flow ID Token requirements in Sections 3.1.3.6, 3.2.2.10, 3.3.2.11, and 3.3.3.6.

When using response_type=code, section 2 and 3.1.3.6 apply.

The contents of the ID Token are as described in Section 2. When using the Authorization Code Flow, these additional requirements for the following ID Token Claims apply: at_hash: […]

So as an OpenID Connect 1.0 client, you should not expect other claims than those defined in section 2 and at_hash to be present in the ID Token. I don't believe OpenID Connect 1.0 forbids other claims (such as from the user's profile) in the ID Token, but a generic client should not rely on their presence.

This means oauth2_proxy is not a generic client, as it relies on specific providers' implementation.

Thomas Broyer
  • 64,353
  • 7
  • 91
  • 164