Why does Google OAuth2 re-ask user for permission when i send them to auth url again

Question

With the old google openid, when i sent a user (who had previously opted-in to my app) to the auth url, it would immediately redirect them back to my app.

Now, with

Answer 1

For me it was hd (hosted domain) parameter. After removal from authorization url I was given a list of users to choose for Auth. More info on hd parameter here https://developers.google.com/identity/protocols/OpenIDConnect#hd-param

Answer 2

Just passing an additional parameter in the request 'approval_prompt=auto' worked for me.

Answer 3

There was a slight update, this link can help: https://github.com/googleapis/oauth2client/issues/453

'approval prompt' was replaced by 'prompt' with params: 'none', 'consent' and 'select_account'

Answer 4

Yes as you've noted using the approval_prompt=force URL parameter will force showing the auth dialog to the user every single time. By simply removing this URL parameter the user will not be prompted on subsequent auth flows.

There is a slight difference in the response that you will get if you use the server side flow (response_type=code) and offline access (access_type=offline). The first time the user authorizes you (when he sees the approval screen) or if you force this by using approval_prompt=force then when you exchange the auth code you will be granted an refresh_token and an access_token.

However every time the user is not shown with the approval screen (subsequent auth when not using approval_prompt=force), when exchanging the auth code you will only be granted an access_token, no refresh_token. So if that's the flow you are using and if you want to be able to access the user's data offline you need to make sure that you save the refresh_token locally for future use, when you get it the first time. That is only likely to happen if you request access to other type of data than simply the auth data though (using the OAuth 2 flow you can request access to other data for instance Contacts API data, Calendar API data, Drive data etc...) as usually a regular Open ID flow would not need offline access.