CODEWITHSUNDEEP
google-oauth
gjuggler
gjuggler

Reputation: 511

Incremental Google OAuth2 — adding new scopes to old tokens

We're running a web service that's been using OAuth2 Login for Google Accounts for the past 10 months.

I'm wondering if there are any known or potential issues when using the new incremental auth for adding new scopes to old tokens, e.g. tokens that were granted up to several months ago?

We're running into a problem that's been verified by two of our devs, but is hard to reproduce since we only have so many accounts with old refresh tokens in a non-production environment. See below for the full story. I'd be curious to hear from anyone at Google whether this may be a bug, or more likely something we're doing wrong on our side.

We were excited to see the new incremental auth, since we're just about to launch a new feature that involves accessing a user's Google Contacts, but only for a specific use case.

So we added a new OAuth endpoint on our server that includes the include_granted_scopes flag and requests only the Contacts scope:

my $url = URI->new('https://accounts.google.com/o/oauth2/auth');

my $params = {
  state                  => 'code_request_contacts',
  response_type          => 'code',
  client_id              => $config->{oauth_client_id},
  redirect_uri           => $c->host . '/auth/oauth',
  scope                  => 'https://www.google.com/m8/feeds',
  access_type            => 'offline',
  approval_prompt        => 'force',
  include_granted_scopes => 'true'
};

When testing on our local dev machines this worked beautifully: contacts access was granted, and the same token would work for both contacts and the existing scopes (which included userinfo.profile, userinfo.email, and drive.file).

However, when we started testing on our pre-production server which had existing access tokens and Google Accounts connected, we ran into problems: once the contacts authorization completed, the returned tokens would work ONLY for contacts, failing with a "403 insufficientPermissions" when used to make any Drive API requests.

After seeing those errors, we tried (a) revoking access via the Account Permissions page (https://security.google.com/settings/security/permissions), (b) logging out of our app, and (c) logging in again to get a fresh token with the basic scopes. Strangely, at this point the incremental auth for contacts would work like a charm, and the new tokens had all combined scopes as expected.

So this is where are now — we've twice seen a problem that would be a show-stopper for rolling this out to production, but we can't reliably reproduce if its behavior involves old tokens.

Our current workaround is to have the Contacts OAuth request also include all of our initials scopes. This leads to a longer list of warnings when the Contacts popup appears, but it otherwise seems to achieve the desired end result.

Upvotes: 4

Views: 1436

Answers (1)

breno
breno

Reputation: 3306

Could it be that you have another difference in the new code, e.g., using a different client_id from the one used in the old tokens?

Upvotes: 0

Related Questions