Is there a deep dive in google oauth2 area?

Question

I was looking for detailed information on how to use google oauth areas

My Drive application works , so I get a simple use of areas. However, I have the following detailed questions / concerns.

• I indicate the area twice. Once in my application, and then also in the API Console. What is the relevant meaning of these two areas of the declaration?
• If I delete the scopes, should my user re-authorize my application, or is it only required to add additional scopes?
• If the answer is 2, is it "I cannot silently delete areas", do Google Libraries work gracefully with user reauthorization, or will I just get 403 failures? I read. How should an application add / remove scope to an existing grant? but the accepted answer specifically refers to adding areas , while my question is deleting areas.
• Can different modules in my application request different areas within the superset specified in the API console? To explain, my application has 3 components: chrome, which extends access to Drive, a web client that uses JS to access Drive and YouTube (online) and a server component that accesses Drive (offline).
• Can my application. find out which areas were provided?

The general question, I’m sure that I am facing the same dilemma as many application authors. If I increase the functionality (a good thing, as it attracts users), I also need to increase the user permissions / trust in my application (bad because it repels users). Are there any recommendations on how applications best deal with this conflict of interest?

Answer 1

The list of areas in your client code is what the user allows your application to do.

When you request authorization from a user, you need to specify what you want the user to agree to. This is what the list of scopes is used for: it controls the text that the user sees when authorizing your application, and the update / access tokens provided by this authorization are limited to making API calls allowed by these areas.

The list of allowed services in the API console is what your application allows users to do.

As far as I know, there is no list of areas specified in the API console. However, there is a list of Google services that may be included. Enabling / disabling a service here is more related to the ability to enable / disable API calls and manage quotas and / or accept the terms of service associated with this API than authorization.

When the API call is made , you send an access token

The access token encapsulates the user making the request, the areas that the user has allowed you to, and the client ID used for authorization (which, in turn, belongs to your project). At this point, you need to have a service that the API call will be sent to the project, and the correct scope for the API request - or you will get 403.

When your list of required scopes changes , you should expect users to re-authorize.

When you request an access token (usually by sending an update token), you should be prepared to ensure that this request does not succeed. Perhaps because you added areas - but perhaps the user decided to visit https://accounts.google.com/IssuedAuthSubTokens and revoked access to your applications. I'm not sure if you request fewer areas than the user provided, it will initially cause this, I would experiment to check - but the fact is that despite the fact that your code should handle this scenario. I believe that OAuth2DecoratorFromClientSecrets (from a related question) will handle this gracefully for you, but I'm not sure it should be easy enough to check.

Using the same authorization for multiple clients - suggest reading this document and see if it covers all your scenarios: https://developers.google.com/accounts/docs/CrossClientAuth

To view the areas available for the access token , use the OAuth2 API: https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=yaxxxxxxxxxxxxxxx