• openid
• email
• https://www.googleapis.com/auth/userinfo.email
• https://www.google.com/accounts/OAuthLogin (this scope does much more than it appears. see update on the bottom for more info)

Shrinking the below, however it’s still somewhat relevant

// API callback
{
 "issued_to": "848232511240-73ri3t7plvk96pj4f85uj8otdat2alem.apps.googleusercontent.com",
 "audience": "848232511240-73ri3t7plvk96pj4f85uj8otdat2alem.apps.googleusercontent.com",
 "scope": "https://www.googleapis.com/auth/plus.me https://www.googleapis.com/auth/userinfo.email https://www.google.com/accounts/OAuthLogin",
 "expires_in": 3472,
 "email": "itme@gmail.com",
 "verified_email": true,
 "access_type": "offline"
}

There is an undocumented flow of being able to exchange a token with the https://www.google.com/accounts/OAuthLogin scope for a session token for google properties. I believe this is a mistake on Google and Niantic’s part, and isn’t being used maliciously in the way that was originally suggested. It appears that using this token in the way that was initially suggested would still be difficult with this grant as the type of use for it is not programmatic (unless there is another hidden api somewhere to grant api tokens). Omitting this scope seemed to make the auth known as “Basic user information” instead of “Full account access”, and is likely what Niantic will do to update the client. The auth flow is confusing, and google should reflect that logging in with this scope can yield a token that can be exchanged for sessions on google properties. IMO, Google shouldn’t be giving out this scope to non-google apps.

Given that Google is going to be retroactivelly re-scoping tokens to remove this possibility, Pokemon Go should be safe to play in the next couple of days on iOS, or even now. Go have fun and play a game 🙂

I spent the night digging to understand why this specific grant is “more permed” than the others, and uncovered some very interesting and undocumented information. There is very little documented about this uberauth mechanism, however it can be used to access more than the initial scope for the oauth grant. It’s the mechanism that chrome uses to auto-log you into google properties.

It appears that only specific projects (including this one by Pokemon Go) can request this specific type of auth.

It IS possible to exchange an accesstoken with https://www.google.com/accounts/OAuthLogin for a specific token called an uberauth. This token can then be used to open a web session with any google property, leading to the “Full Account Access”.

The token that gets generated must be exchanged for one of these “more powerful” tokens to be useful, and the article below by Duo covers how this process can work. While monitoring the app, I did not see any activity from the app’s side to exchange a token for this, and it appears that this level of access is not designed to be used programmatically (via apis), but rather via a web browser. Making use of this access programmatically seems difficult, however there may be additional undocumented APIs that would allow an exchange for an api token of sorts.

The app uses binary blobs to communicate with Niantic’s servers, so I can’t speak as to whether or not they are storing or even seeing these tokens. Given Niantic’s response, it appears that they are most likely going to remove this scope from a new version of the Pokemon Go app.

In summary:

• The direct token that Niantic gets can’t access the gmail api / gcal api
• However, the token could potentially be exchanged through the undocumented mechanism /MergeSession to create a web session logged in as you on any google property
• I haven’t seen the app try to exchange this token for an ubertoken while poking at it
• The app communicates with Niantic with binary blobs and theoretically could send this token to them
• This lines up with Niantic and Google’s statement
• Undocumented parts of auth flow are bad, and can lead to problems like this ambiguity
• This token is overpermed, due to the https://www.google.com/accounts/OAuthLogin scope
• This oauth flow is special, and doesn’t prompt you for confirmation on additional auths. Given that the secret is in the app, this is worrisome

• https://bugs.chromium.org/p/chromium/issues/detail?id=437960
• https://duo.com/blog/beyond-the-vulnerabilities-of-the-application-specific-password-exploiting-google-chrome-s-oauth2-tokens

Requesting an uberauth from the bearer token:

GET /OAuthLogin?source=ChromiumBrowser&issueuberauth=1 HTTP/1.1
Host: accounts.google.com
Authorization: OAuth the.token

Redeeming an uberauth session to a gmail session

https://accounts.google.com/MergeSession?source=chrome&uberauth=APh-3….&continue=https%3A%2F%2Fmail.google.com%2Fmail%2F