Not getting refresh token even though access_type is offline in step1

[noodlebreak]

Hi,

I'm doing some work with Google Search Console API. Before I start using the API, I need to get oauth credentials of the client: authorize my app to get access tokens to call the Search Console API on his behalf and do modifications to his Search Console data.

I'm doing the needed step1 and step2 flow exchange calls, but still I'm not getting any refresh token whatsoever, even though access_type is set to offline in the authorize url generated in step1.

Am I missing something?

Here's my code:

authorize_url = flow.step1_get_authorize_url()

And the url is like:

https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/webmasters&redirect_uri=http://mywebsite.com/google/scapi/callback/&response_type=code&client_id=redacted_client_id&access_type=offline

And then in my callback handler:

credentials = flow.step2_exchange(code)

Here's the json I'm getting from the Credentials object:

{
  "_module": "oauth2client.client",
  "token_expiry": "2016-04-05T12:46:24Z",
  "access_token": "ya29.. -- redacted --",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "invalid": false,
  "token_response": {
    "access_token": "ya29.. -- redacted --",
    "token_type": "Bearer",
    "expires_in": 3419
  },
  "client_id": " -- redacted --",
  "id_token": null,
  "client_secret": " -- redacted --",
  "revoke_uri": "https://accounts.google.com/o/oauth2/revoke",
  "_class": "OAuth2Credentials",
  "refresh_token": null,
  "user_agent": null
}

[theacodes]

This can happen if you've already authorized the app once before. The oauth2 server will only ever mint one refresh token at a time, and if you request another access token via the flow it will operate as if you only asked for an access token.

You can try constructing the flow object with prompt='consent' and see if that fixes it.

Related: googleapis/oauth2client#453

[emilecaron]

Had the exact same problem, and using prompt='consent' worked for me.
Bad surprise though :(

[hobzcalvin]

This is ridiculous. Why is this only documented in a blog post? Am I missing something?

[theacodes]

This is documented here for now: https://developers.google.com/identity/protocols/OpenIDConnect#prompt

We are actively working to improve our auth docs, we are aware that it's difficult to find documentation about both the high-level libraries and the low-level protocol. Stay tuned.

[hobzcalvin]

@jonparrott I would not say that documents this issue: it makes no reference whatsoever to refresh tokens. The access_type description says offline must be specified to get a refresh token, but no mention of prompt there. The Refresh Tokens section says "Be sure to store the refresh token safely and permanently, because you can only obtain a refresh token the first time that you perform the code exchange flow." That kind of sort of describes the situation here, but "the first time" is vague, and makes no mention of the prompt=consent workaround. Anyway, good luck.

[advance512]

Discovering this was painful.

[theferrit32]

@jonparrott does forcing a new login/consent by the user invalidate prior refresh tokens for that user even if the prior refresh token was not used?

In addition are there any plans to either move away from the access_type=offline parameter or add as an alternative the mechanism specified in the OpenID specification, which is adding the scope offline_access to the authorization request? access_type is not part of the OAuth or OpenID specifications as far as I know.

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

[theacodes]

does forcing a new login/consent by the user invalidate prior refresh tokens for that user even if the prior refresh token was not used?

Not sure, but I think not. I think the refresh token is only invalidated if the user revokes access through accounts.google.com

In addition are there any plans to either move away from the access_type=offline parameter or add as an alternative the mechanism specified in the OpenID specification, which is adding the scope offline_access to the authorization request? access_type is not part of the OAuth or OpenID specifications as far as I know.

Not that I'm aware of.

[kbennoune]

does forcing a new login/consent by the user invalidate prior refresh tokens for that user even if the prior refresh token was not used?

I just tested with an old and new token/refresh_token combination and the old pair continues to be valid when refreshing.