20
votes

When using Google's OpenIDConnect authentication system, it's possible to specify email or profile or both in the scope parameter. If you request the email scope, the "email" and "email_verified" claims will be included in the id_token that gets returned as part of a successful OAuth2 authentication session.

Here's an example from Google's documentation:

An ID token's payload

An ID token is a JSON object containing a set of name/value pairs. Here’s an example, formatted for readability:

{"iss":"accounts.google.com", 
 "at_hash":"HK6E_P6Dh8Y93mRNtsDB1Q", 
 "email_verified":"true",
 "sub":"10769150350006150715113082367", 
 "azp":"1234987819200.apps.googleusercontent.com", 
 "email":"[email protected]", 
 "aud":"1234987819200.apps.googleusercontent.com", 
 "iat":1353601026, 
 "exp":1353604926,
 "hd":"example.com" 
}

However, requesting the profile scope seems to have no effect whatsoever on the contents of the id_token. In order to retrieve the profile information, you have to make a separate HTTP request to a distinct endpoint (authenticated with the access_token you just received) to get a document that looks very similar, but with more information:

{
  "kind": "plus#personOpenIdConnect",
  "gender": string,
  "sub": string,
  "name": string,
  "given_name": string,
  "family_name": string,
  "profile": string,
  "picture": string,
  "email": string,
  "email_verified": "true",
  "locale": string,
  "hd": string
}

Ideally, I would prefer to get the profile information (just name, actually) included in the id_token JWT rather than having to make a separate call. Is there any way to specify additional fields and have them included as claims in the id_token? If not, why is email treated specially and returned in the id_token?

3

3 Answers

14
votes

Starting today you will get profile information when exchanging the code at the token endpoint (i.e. using the "code flow").

How to use: add the profile scope to your request, and make sure you are using the OpenID Connect compliant endpoints (the ones listed in https://accounts.google.com/.well-known/openid-configuration).

Look for claims such as name and picture in these ID Token responses. As before, if the email scope is in your request, the ID Token will contain email related claims.

When you refresh your access token, every so often the ID Token that is returned with the fresh access token will also contain these additional claims. You can check these fields, and if present (and different to what you have stored), update your user's profile. This can be useful to detect name or email address changes.

7
votes

When a request is made with response_type=id_token and profile in the scope like scope=openid+profile+email, the resulting id token should contain the profile claims directly in it.

This is per section 5.4 of the OpenID Connect spec, which says "... 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."

However, in a little testing I did with their OAuth 2 Playground, Google doesn't seem to put profile claims in the id token even when response_type=id_token and no access token is issued. I'd argue that this is an implementation defect on Google's part and, short of them fixing that (or adding support for the "claims" Request Parameter), there doesn't seem to be a way to accomplish what you're looking for.

1
votes

Well, this is the right place to request. We are working to support this feature and should be rolling this out soon (in the next few weeks). I'll make an update to this response then.