"This app would like to: Have offline access" when access_type=online

Oauth 2.0Google Oauth

Oauth 2.0 Problem Overview


I have a Google App with OAuth 2.0 authentication. Everything used to work fine but recently I started getting the following "Request for permission" screen:

enter image description here

The strange part is that I get this screen when I pass access_type=online. Again, this used to work until recently.

What can be the cause for this? TIA

Edit:

The requested scopes are:

https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile

I have already tried:

  • with and without access_type=online
  • with and without approval_prompt=auto

Edit #2:

This is the python code I'm using to generate the authentication URL:

encoded_params = urllib.urlencode({
    "response_type" : "code",
    "client_id" : MY_CLIENT_ID,
    "scope" : " ".join(MY_SCOPES),
    "redirect_uri" : MY_REDIRECT_URI,
    "state" : random_security_token,
    "access_type" : "online",
    "approval_prompt" : "auto",
    })

auth_url = "https://accounts.google.com/o/oauth2/auth?" + encoded_params

Update (Oct. 14):

Even with the new scopes, I still get the consent screen. Recently I got it for a new device I was using for the authentication.

Oauth 2.0 Solutions


Solution 1 - Oauth 2.0

I think G does this when your app requests a token and there is still a valid access or refresh token for the user for the scopes in question.

The solution is to revoke tokens when you're done with them (either on user logout or immediately after authenticating the user) by issuing this request:

https://accounts.google.com/o/oauth2/revoke?token={token}

You don't have to provide any app credentials, just the token as a URL argument.

(docs here https://developers.google.com/accounts/docs/OAuth2WebServer#tokenrevoke)

I had the same problem and no combination of access_type or approval_prompt values seemed to solve it. Revoking the token did the trick.

I'm not sure how to revoke all outstanding tokens for your app, unless you happened to store them. To test with your own user account, you can manually revoke the existing token for your app here:

https://security.google.com/settings/security/permissions

Solution 2 - Oauth 2.0

UPDATE:

The Scope for E-mail is now

email

> Legacy Google+ APIs have been shut down as of March 7, 2019. Scopes > previously requested by your apps may now be deprecated or invalid. > Developers should update their code to remove or update references to > Google+, Google+ APIs, and any related OAuth scopes. source: https://developers.google.com/+/scopes-shutdown

-- OLD ANSWER --

Google recently changed the Scope for Email. You should replace

https://www.googleapis.com/auth/userinfo.email

with:

https://www.googleapis.com/auth/plus.profile.emails.read 

and:

https://www.googleapis.com/auth/plus.login

Then the offline access should disappear.

See also:

https://developers.google.com/+/api/oauth#email

> Warning: This scope is deprecated. Google will no longer support this scope after Sept. 1, 2014. For details, see Migrating to Google+ Sign-In.

This also changes the way the email address is received:

> https://developers.google.com/+/api/auth-migration#email

Also keep in mind that you have to activate the Google+ API in your management console in order for this to work.

Solution 3 - Oauth 2.0

Using http://localhost in the redirect_url parameter of the OAuth request will cause the user to be asked to grant offline access the first time they authenticate after each login.

Solution 4 - Oauth 2.0

Tzach. In order to not prompt the consent screen after first login. You may need this to pass the value to the function :

> $client->setApprovalPrompt ("auto");

Solution 5 - Oauth 2.0

I think this has been answered, but I can't find the link right now.

In a nutshell, Google recently made some changes around scopes in order to implement incremental scopes. Part of those changes is that if your app causes a auth prompt, yet the user has already authed, Google has to ask for something, so asks for offline access. Try setting

approval_prompt=auto

to avoid the prompt

Solution 6 - Oauth 2.0

I was having the same issue. Although I was not setting

access_type=online

However, according to my understanding, the default

access_type 

is

online 

From: https://developers.google.com/identity/protocols/OAuth2WebServer: "The default style of access is called online."

What solved this for me was to remove:

prompt=consent

There is still a consent form on the first go of course, just now it is not a consent form asking for offline access, which probably scares away some would-be users.

I believe the prompt parameter is intended as a replacement for the approval_prompt parameter. But it seems like if I set it to "consent", that should just mean I want the normal consent screen shown everytime, not the "offline access" consent screen. The docs here: https://developers.google.com/identity/protocols/OpenIDConnect#prompt don't seem to refute that notion, so I'm not sure why it behaves this way. But at least I was able to get it working the way I want it, for now.

Solution 7 - Oauth 2.0

Well, I don't know if this actually constitutes an answer, but I've found that some users see the:

'Have offline access'

compared to others (who get what I think you want to see):

'View basic information about your account'

Solution 8 - Oauth 2.0

Are you using Google APIs Client Library?

https://developers.google.com/api-client-library/

It sets access_type to 'offline' when refreshing tokens on its own

In Python version, I changed line 1204 of oauth2client/client.py

from

    'access_type': 'offline',

to

    'access_type': 'online',

and it now works correctly.

Solution 9 - Oauth 2.0

I applied everything in this question. In my case, only clearing cookies worked.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionTzachView Question on Stackoverflow
Solution 1 - Oauth 2.0amwinterView Answer on Stackoverflow
Solution 2 - Oauth 2.0dominikView Answer on Stackoverflow
Solution 3 - Oauth 2.0Ian MackinnonView Answer on Stackoverflow
Solution 4 - Oauth 2.0CK TanView Answer on Stackoverflow
Solution 5 - Oauth 2.0pinoyyidView Answer on Stackoverflow
Solution 6 - Oauth 2.0Paul BrackinView Answer on Stackoverflow
Solution 7 - Oauth 2.0jmazinView Answer on Stackoverflow
Solution 8 - Oauth 2.0M MView Answer on Stackoverflow
Solution 9 - Oauth 2.0fatihpenseView Answer on Stackoverflow