23

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":"jsmith@example.com", 
 "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?

bjmc
  • 2,970
  • 2
  • 32
  • 46

3 Answers3

17

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.

William Denniss
  • 16,089
  • 7
  • 81
  • 124
  • 3
    In theory this should work, however, the id tokens I receive don't contain any profile info. authorization_uri: https://accounts.google.com/o/oauth2/auth?access_type=offline&client_id=xxxxxx&redirect_uri=xxxxx&response_type=code&scope=profile%20email id token keys: ["azp", "aud", "sub", "email", "email_verified", "at_hash", "iss", "iat", "exp"] – Alexander Popov Mar 28 '17 at 08:11
  • 1
    @Willam Denniss: for some reason during refreshing access token id_token doesn't contain any profile info. – Pablo May 05 '17 at 21:00
  • 1
    With the URL https://www.googleapis.com/oauth2/v4/token it works, Thanks. – Horcrux7 Feb 15 '18 at 08:58
  • 2
    This functionality appears to be broken. ID tokens do not contain picture nor name claims when requested using the endpoints linked in the answer. Nor does it work with the token URL @Horcrux7 suggested using. – dmur Jan 04 '19 at 22:52
  • i just got this to work: 1. https://accounts.google.com/o/oauth2/v2/auth with my client_id, redirect_uri, and state and response_type=code and scope=openid+email+profile. 2. https://oauth2.googleapis.com/token with code returned by the first call, my client_id and client_secret and redirect_uri, and grant_type=authorization_code. Got an id_token with sub, name, given_name, profile, picture, email, email_verified, locale, and hd -- didn't need to hit https://openidconnect.googleapis.com/v1/userinfo – misterhaan Feb 01 '19 at 04:44
  • I still can't get it work, checked everything. What can I do more? Can anybody help? – Maria Efimenko May 04 '21 at 13:23
  • Did you ever figure this out, Maria? Struggling with it myself. – agusterodin Oct 23 '21 at 18:59
7

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.

William Denniss
  • 16,089
  • 7
  • 81
  • 124
Brian Campbell
  • 2,293
  • 12
  • 13
  • I appreciate the confirmation, at least. I don't suppose you know if there's any place to request OpenIDConnect bugfixes/enhancements from Google? – bjmc Aug 24 '15 at 15:31
  • I don't know. But will make a polite inquiry to some folks that might know better than I. – Brian Campbell Aug 24 '15 at 16:57
  • 1
    I'm told that there is not an open bug tracker or anything like that for OpenID Connect but that they are evaluating placing more claims in the id token and will look at the specific response_type=id_token case (where there is no access token) in the course of that. Though they can't commit to if or when that would actually be done. They are at least aware. That's the best I can do on this one. – Brian Campbell Aug 24 '15 at 18:41
  • Thank you, much appreciated! – bjmc Aug 24 '15 at 21:14
  • For people still looking for a fix/workaround, adding openid in scope as suggested in this answer does the trick. The scopes profile and email are actually userinfo scopes and not tokeninfo scopes, a bit different from what the docs say – Jeet Kumar Dec 12 '17 at 12:24
1

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.

nvnagr
  • 2,017
  • 1
  • 14
  • 11
  • Any update? Trying to get this working and I'm seeing the email when I don't ask for the email, but no "profile object" as indicated in the developer docs. – jcolebrand Mar 06 '16 at 04:55
  • See William's answer. We did roll this out. What scopes are you requesting and does the account you use to approve have a public visible name? – nvnagr Mar 07 '16 at 18:26