I'm looking for some deep down detailed information on google's use of oauth scopes
My Drive app is working, so I get the simple use of scopes. However I have the following detailed questions/issues..
- I specify scopes twice. Once in my app and then also in the API
Console. What is the respective significance of these two scope
declarations?
- If I remove scopes, must my user re-authorise my app, or is this
only required for adding additional scopes?
- If the answer to 2, is 'I can't silently remove scopes', will the
Google libraries deal gracefully with re-authorising the user, or
will I just get 403 failures? I've read How should an application add/remove scopes to an existing grant? but the accepted answer specifically references adding scopes, whereas my question is about removing scopes.
- Can different modules within my app request different scopes within
the superset specified in the API console? To explain, my app has 3
components: a chrome extension accessing Drive, a web client using
JS to access Drive and YouTube (in online mode), and a server
component which accesses Drive (in offline mode)..
- Can my app. enquire what scopes it has been granted?
A general question, I'm sure I face the same dilemma as many app authors. If I increase functionality (a good thing since it attracts users), I also need to increase permissions/trust a user places in my app (a bad thing since it repels users). Are there any recommendations on how apps should best handle this conflict of interests?
List of scopes in your client code - this is what a user authorizes your app to do
When you request authorization from a user, you need to specify what you would like the user to consent to. This is what the list of scopes is used for - it controls the text the user sees when they authorize your application, and the refresh / access tokens granted by that authorization are limited to making API calls that are allowed by those scopes.
List of enabled services in the API Console - this is what your app authorizes users to do
To my knowledge there is no list of scopes specified in the API Console. There is however a list of Google services that can enabled. Enabling/disabling a service here is more about turning on/off ability to make API calls and managing quota and/or accepting terms of service related to that API, than it is authorization.
When an API call is made - you send along an access token
The access token encapsulates the user making the request, the scopes the user authorized you for, and the client ID used for the authorization (which in turn belongs to your project). At this point you need to have the service that the API call is sent to enabled on the project, and the correct scope for the API request - or you will get a 403.
When your list of required scopes changes - you should expect users to need to re-authorize
At the point you request an access token (typically by sending a refresh token) you need to be prepared for that request not to succeed. Maybe it's because you've added scopes - but maybe a user has chosen to visit https://accounts.google.com/IssuedAuthSubTokens and has revoked your applications access. I'm not sure whether if you request less scopes than was granted by the user initially will trigger this, I would experiment to test - but the point is that regardless your code needs to be able to handle this scenario. I believe the OAuth2DecoratorFromClientSecrets (from the linked question) will handle this gracefully for you but am not certain - it should be easy enough to verify.
Using the same authorization across multiple clients - suggest reading through this doc and see if it covers all of your scenarios: https://developers.google.com/accounts/docs/CrossClientAuth
To see scopes granted to an access token - use the OAuth2 API: https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=yaxxxxxxxxxxxxxxx
