I have requested Google to approve sensitive scopes. Until now the application was accessing the basic name and email data. However, the new requested scopes do not show up on the consent screen. Google requires me to share a video with the new OAuth consent screen but I don't have a way to show the new scopes until they update it. What am I doing wrong? I have looked up other questions and resources and did not find any question specific to this problem related to the sensitive scopes.
The scopes that appear on the consent screen are sent by your code in the authorization setup. Adding them to google developer console just tells google you will be using these. Its your code that needs to request them.
If your not seeing them you haven't added the scopes to the authorization request in your code.
Related
TLDR: I've been struggling with the new Sign in with Google functionality and especially the part how I can let the user stay signed in. What I understand from the docs is that Google only tells "this is a user who would like to sign in" but basically I would still need to create my own backend to track that user.
Note this question is about the new Sign in with Google functionality, all the guides/questions I can seem to find are about legacy sign-in and this is quite well described here:
https://developers.google.com/identity/sign-in/web/server-side-flow
What confuses me most is basically already stated in the beginning of the guide:
https://developers.google.com/identity/gsi/web/guides/overview?hl=en#user_sign-in_to_your_site
You'll manage per user session state for sign-in to your site.
User sign-in status to their Google Account and your app are independent of each other, except during the sign-in moment itself when you know that the user has successfully authenticated and is signed into their Google Account. Users may remain signed-in, sign-out, or switch to a different Google Account while maintaining an active, signed-in session on your website.
I understand the basic principle behind OAuth and the part where you have to exchange the authorization code for an access token and you can verify this access token (which is perfectly described in the legacy guide), but this is now only required for OAuth2 in order to access personal data. If I understand correctly this access token can be used as an identifier for a specific session (as alternative to a password or session cookie).
With the new sign in policy you will only get a JWT which identifies the user. Also apparently the only way to get a JWT is as a response when the user clicks the Sign in with Google button and selects the account in the consent screen (which ideally should only occur once).
What I actually want to achieve is that when a user enters the site I want to send a request "Hey Google this user is visiting my site, do you recognize this session and is it still valid".
Maybe I'm thinking way too difficult, but what I just don't understand is how can the new Google Login actually help me remember and validate users?
After some more digging around I found a lead on this page: https://developers.google.com/identity/gsi/web/guides/migration#object_migration_reference_for_user_sign-in
Basically what I am looking for was provided by the depreciated GoogleAuth.isSignedIn.get() function, but the notes clearly show:
Remove. A user's current sign-in status on Google is unavailable. Users must be signed-in to Google for consent and sign-in moments.
Combined with the prior statement:
You'll manage per user session state for sign-in to your site.
To validate the assumption I did some testing with other web services where I logged in using Google, revoked the log-in access for that website from the Google console and when revisiting that website I was still logged in to the website.
My conclusion:
Google login only verifies the initial login
Google basically responds with "Yes this is a valid user"
I have to keep track of the user session using cookies/databases myself
We're implementing Gmail sending in out ASP .NET web application with Gmail .NET SDK.
In order to do this we need all following scopes "email", "profile", "openid",
https://www.googleapis.com/auth/gmail.send" to be granted to us by user.
However, on the consent screen user can untick checkbox "Send email on your behalf" which is not acceptable for us, please see below:
We've seen quite a few examples where there are no enabled checkboxes on the Google consent screen. So, we're truiyng to figure out how to hide/disabled checkboxes in our app, could you please advise?
Probably, this is because of our application is still not verfified, but I'm not sure if this is the reason.
Answer:
These checkboxes are due to the rolling out of a new granular account permission system, they are completely normal, and can not be turned off.
More Information:
After some digging, I discovered this Google Developers blog post from 2018 in which it is discussed that in the new permission system, users will have the ability to grant or deny permissions individually.
From the blog post:
Over the next few months, we'll start rolling out an improvement to our API infrastructure. We will show each permission that an app requests one at a time, within its own dialog, instead of presenting all permissions in a single dialog*. Users will have the ability to grant or deny permissions individually.
*our different login scopes (profile, email, and openid are all combined in the same consent and don't need to be requested separately.
It seems that this is still in the roll-out phase, even though at the time of writing this answer 26 months have passed since the announcement.
Preparing for the change:
The following are guidelines provided by Google as to how to prepare for the changes they are making to the Google Account permission system for OAuth and APIs:
Review the Google API Services: User Data Policy and make sure you are following them.
Before making an API call, check to see if the user has already granted permission to your app. This will help you avoid insufficient permission errors which could lead to unexpected app errors and a bad user experience. Learn more about this by referring to documentation on your platform below:
Documentation for Android
Documentation for the web
Documentation for iOS
Request permissions only when you need them. You'll be able to stage when each permission is requested, and we recommend being thoughtful about doing this in context. You should avoid asking for multiple scopes at sign-in, when users may be using your app for the first time and are unfamiliar with the app's features. Bundling together a request for several scopes makes it hard for users to understand why your app needs the permission and may alarm and deter them from further use of your app.
Provide justification before asking for access. Clearly explain why you need access, what you'll do with a user's data, and how they will benefit from providing access. Our research indicates that these explanations increase user trust and engagement.
You can read the aforelinked blog post for full information about the change.
References:
Google Developers Blog: More granular Google Account permissions with Google OAuth and APIs
Google API Services User Data Policy | Google Developers
GoogleSignIn | Google APIs for Android | Google Developers
Google Sign-In JavaScript client reference
Requesting additional scopes after sign-in | Google Sign-In for iOS
I have a google login in my app when I try to click on sign in with google I do not see the permission it needs to access
My app uses users contacts and so I have added it to scope in consent screen settings but it do not show any permission. Can someone help me if there is anything else that needs to be configured as I need to verify my app from google
I want permission to display like this(sample image)
Scopes that I am using
this is the api
Lets use the Google Oauth Playground to test a little.
test 1 requesting authorization to Oauth2 scopes.
I am going to select Google contacts really there is not much point in selecting this one using google People api is a much better choice.
And everything under Google People API
This is the consent screen shown me
test two authenticating with open id connect
I am going to only request
Now profile and email are special they are related to Open Id connect, which is out side of the Oauth2 because of that i was not actually shown a consent screen. Because i am Authenticating to Google that this is me logging in.
I am not Authorizing any Oauth2 scopes because none were really requested. Now this make confuse you because by requesting profile you are automatically given access to the users profile data which means that you can access the Google people api and do people/me and get the information about the person.
conclusion
Only Oauth2 scopes appear to the user requesting access. not open id scopes.
There's a section in Google Cloud Console > APIs & Services > Credentials > OAuth Consent Screen that lets you edit a list of scopes:
However it seems to have zero bearing on the actual permissions that are asked for in the user prompt, which seem to only be influenced by what I actually pass in from my code when going through the OAuth flow. The list does not seem to update itself to reflect the actual scopes you ask for from your code, and it also does not limit the scopes that you can request from your code.
Is the list of scopes configured in the OAuth Consent Screen used for anything?
In your screenshot on the right side "Scopes for Google APIs", this is a list of scopes that your application has asked for in the past. If your app requires validation, Google will use this list as part of its process to evaluate your app. For most of the items (scopes) in the list, you can click the delete icon to remove the scope from the list.
When you create your credentials (OAuth Tokens), you specify the scopes that you want at that time. The list in your screenshot is not used to specify scopes, just to keep track of the ones that you have used.
As mentioned by #Hanley, this screen shows the list of scopes that your application has asked for in the past. If your application needs to be verified, Google will use the scope list. You can add or delete any scopes that you want. The key point is that the screen is used for verification of your application. Add or delete any scopes that you want. Once approved however, if you use a scope not approved then the approval process needs to be repeated.
When credentials are generated, this specify the scope that is needed at that time. The list updates itself based on the scopes used by the application. However, the update is not immediate.
I'm building an app with Google Sign Up button. Google suggested for me to use Google+ instead, which I did.
I'm asking for users profiles and email address in two different scopes (https://www.googleapis.com/auth/userinfo.email and https://www.googleapis.com/auth/userinfo.profile). However, I noticed that the scope https://www.googleapis.com/auth/plus.login is added automatically in the token request response.
Is there a way to remove it? I'd like only to ask users for the two I've mentioned in order not to have additional permission requests in the dialog box, and this one also causes a confirmation popup for access to users' circles (which I don't need). I've Googled about it a lot, but couldn't find anything related to this problem.
Previously you could not remove the plus.login scope from the Google+ Sign-In button, as profile information for users who had not upgraded to Google+ was not available from the Google+ APIs. Now you can choose whether you want to require a Google+ upgraded user and get access to the users' circles and the ability to write app activites, or just request basic profile information.
For full Google+ Sign-In include email and https://www.googleapis.com/auth/plus.login scopes.
For basic profile information include email and profile scopes. Note that these are just the bare strings profile and email - they are not in URL form.
The user's email address and profile information will be available from the Google+ profile endpoint. You can always allow users to upgrade to https://www.googleapis.com/auth/plus.login later using incremental auth so they can take advantage of access to circles users and writing app activities.
To use the Google+ Sign-In button you must request https://www.googleapis.com/auth/plus.login
plus.login includes a basic set of permissions that a generally useful including a request to read a users circles. Users can easily choose not to grant access to their circles for your app by simply selecting the 'Only you' option that is presented prominently on the consent dialog. However, it is not possible to reduce that set of permissions included in plus.login.