I am trying to authenticate using OAuth2 with Google Maps Coordinate but I am having an issue when specifying the scope that I want the Auth tokens to be valid for. The URL I am using to request an access code is in this format:
https://accounts.google.com/o/oauth2/auth?response_type=code&client_id={client id}&redirect_uri={App URL}&approval_prompt=force&scope=https://www.googleapis.com/auth/coordinate
The issue I am having is that the consent screen just says "This app would like to: Have offline access". It does not mention granting permissions for interacting with Google Maps Coordinate. I am starting to think this a bug on Google's side, because if i try to get a read only token by adding .readonly to the end of the url, the consent screen shows "This app would like to: View your Google Coordinate Jobs". Similarly, if I replace coordinate with docs or drive, I get the correct consent screen where the app requests permissions to access and modify Google Drive content.
If I get a token using the coordinate scope with the "Have offline access" permissions and then use that token to try and make requests to coordinate, I just get "Insufficient Permissions" errors.
The issue only seems to be happening when trying to get an access code for Maps Coordinate. Has anyone else experienced this issue?
Thanks
This is not a bug, this is just a strange behaviour (and maybe a bug). (so it may be not 100% correct, what I'm telling)
You use in your request url approval_prompt=force, that means, that the user will always be asked to give permission. What follows is, that you get a refresh token (that doesn't expires, unless the user removes explicitly the permission for your app from his account), which you have to exchange for an access token.
That is also the reason, that you always get only "This app would like to: Have offline access". Once you permitted a specific scope, it won't show up anymore in the consent screen.
The docs and drive consent screens are showing the right, because you didn't give the permsission for them.
I see basically two possibilities for you: don't use approval prompt (and thus skip the consent screen after the first authorization, you will be simply redirected as the user clicked allow, but without clicking allow) or exchange the token to a refresh token.
Or try revoking your permission for your account.
I think when it shows Offline Access it means you've already accept these permissions before. This has sometimes happened to me, try revoking the old access and try again to obtain fresh tokens. Go to you Google account page (https://www.google.com/settings/personalinfo) --> Security --> Account Permissions --> View All, then search the Maps access and revoke it, then try again
Related
When I log in with an account which does not belong to the expected domain, this message is shown (which is correct).
I think this message is kind of ugly and not understandable for a non-developer person. Is there a way to modify this message in the Google Cloud Console or inside the OAuth code? I would like to display for example:
The email you used does not belong to the happy.com domain.
I fount this Feature Request In the Public Issue Tracker, and there they suggest to follow the steps of Customize the rejected-app message. Basically it mentions:
Your current account, user#domain.com, doesn't have permission to do these steps. To continue, switch to an administrator account. This will open the Google Admin console.
Switch to administrator account now or Learn more
From the Admin console Home page, go to "" and then Security and then API controls.
Under App access control, go to the Settings section.
Type your custom text in the box under the following message: Show this message if a user tries to use an app that can’t access restricted Google services.
Click SAVE.
If this doesn't make it, I would recommend you to comment on that FR in which they mentioned:
I have filed this feature request internally.
You might also want to ‘star’ the FR to ensure that you receive updates about it. You can also adjust notification settings by clicking the gear icon in the top right corner and selecting settings.
Background:
This is about using a Gmail Addon created using Google App Script.
When the user installs the addon, there is the OAuth Consent Screen where user provides his consent to allow the "Product name shown to users" (as configured in the OAuth Screen) to allow the access specified.
Now, I read : https://developers.google.com/identity/protocols/CrossClientAuth
which states :
When a user grants access to your app for a particular scope, the user
is looking at the user consent screen, which includes project-level
product branding that you set up in the Google API Console. (For
information about setting up the consent screen, see Setting up OAuth
2.0 in the API Console help.) Therefore, Google considers that when a user has granted access to a particular scope to any client ID in a
project, the grant indicates the user's trust in the whole application
for that scope.
Now, I have a server web component (a lambda) (belonging to the same product) that needs access to the user's email same access that the user provided after installing the addon ("Authorized Access" button).
Question(s) :
Is there a way to have cross-client (a backend server and a gmail addon) in my case to have the backend to just get access to user's data without triggering additional (basically whatever the user has provided consent to)?
Note: Using an additional authorization screen triggered manually using the GAS OAuth library I was able to get the "Auth Code" which I pass to the server using which the server now has access to the consented data (we have used the same client id and secret). However, the problem with this approach is :
User gets 2 emails about the permissions granted. Addon and Manually triggered flow.
User has to authorize the gmail addons for first access and then another which I trigger manually.
Even if there was a way I could get the "Auth Code" when the user installs the addon that would also do.
Apologize in advance there is a lot of scattered documentation and though I went through many it is likely I may have missed something.
We only issue one authorization code (refresh token) in exchange for one user authorization/approval. Your app can get new access tokens on android or web without a user approval. But if it needs a refresh token again, user still need to approve the request.
So if the addon can talk to your server, you could give it a short lived access token or will need to user authorization.
I have been developing an extension, which is using the chrome.identity API (chrome.identity.getAuthToken method) in order to receive the OAuth2 token for signing up extension users via Google+.
I would like to push this extension in a company via Google Admin Console, but when chrome.identity.getAuthToken method is being called, our extension users are present with the "Identity API Scope Approval" screen - the consent screen, where users have to authorize extension's access to scopes we want access to.
I am aware, how process of getting OAuth2 access tokens works in general, and that user's approval is normally required in order to receive the OAuth2 token.
However, is it possible to automatically skip & authorize this OAuth2 consent screen only for users, whose extension was deployed via Google Admin Console?
I've found an interesting on Chromium Bugs list, where OP states:
We are working on integrating Quickoffice for Chrome (which is a chrome extension) with the Drive Web UI. In order to handle OAuth we use chrome.identity, which works great.
and also the following:
since our extension is white listed as a first party app, we by pass the user content screen for the OAuth flow (which is what we want for the seamless integration with drive web ui).
I was not able to find any information, how to neither whitelist the extension as a first party app in order to prevent the consent screen from showing up, nor how to automatically authorize extension's access to those API scopes.
Any ideas?
If you include identity.email in the manifest permissions, and it is a force-installed extension or app through the admin console, then you will be able to get the user's identity and also the auth token without user oauth prompt approval.
However this only allows you to get the user's identity, no extended permissions. Any extended permissions (such as gdrive access, etc) need an oauth prompt.
If I specify access_type=offline in the auth url and a user attempts to auth a second time I get a box that says it is asking for offline access.
I would have expected it to be already authorised and so not require additional permissions
Any ideas?
Edit:
A bit more info. The first time around it makes no mention to the user of needing offline access. I would have thought the offline permission to be mentioned in the original auth anyway.
Edit 2:
Some more info on my use case. It is possible in our system for a person to have two accounts but then use the same google drive account. This means that we have no way of knowing that user has already authorized with google and so have to present the authorization again for the second user.
The first time around (for user 1) you are told that the app is asking for :
View and manage Google Drive files that you have opened or created
with this app
View and manage the files and documents in your Google
Drive
The second time around (for user 2) you are told the app is asking to:
Have offline access
This seems wrong to me.
As an aside:
The whole "have offline access" statement is very confusing for a user and also quite misleading. Most people assume this means the app can read the contents of your pc. In fact it means that the app can authenticate with your account with out you being there (i.e. using a refresh token).
I am getting 404's for image thumbnails when I'm signed on multiple accounts and making API calls for changes.list.
The full steps to reproduce the issue are described as below:
Be signed in with two accounts, one a personal gmail account, and one a Google apps account, say User_gmail and User_gapps respectively
Make API calls to get URLs with to get a list of changes in drive.
Load up the thumbnails for images.
Expected behaviour:
Thumbnail images work.
Actual behaviour:
When I am signed in with User_gmail and User_gapps and I pick
User_gmail during the authentication flow, I can see thumbails for
all modified documents.
When I am signed in only with User_gapps or User_gmail, I can see
thumbnails correctly.
However, when signed in as both users, and I pick User_gapps as the user during the authentication flow, I see broken thumbnails.
Update: the easiest way to reproduce this is sign into multiple accounts, one personal and one apps account, and use this api. If you authorize the API with your work account, and execute a request, and click on the "thumbnailLink" URLs, you can see 404s.
https://developers.google.com/apis-explorer/#p/drive/v2/drive.changes.list?includeDeleted=false
There are two ways to see a Google Document's thumbnail. After getting the URL of the thumbnail through the Google Drive API this URL can be viewed using either 'Cookie' authorization or OAuth 2.0 Authorization.
You seem to be using the 'Cookie' authorization (i.e. the user is currently signed in the browser). What happens is that the browser will use one of the two accounts by default and unfortunately it might not use the correct account.
In that specific scenario you can append &authuser=0 or &authuser=1 to the URL of the thumbnail this will force using an account or the other, one of the two values will work.
The issue is that you don't know which value will work (1 or 0) so you would have to test the two URLs programmatically using Javascript to see which one works or fails.
The other way to load a thumbnail is to use OAuth 2 auth. This is more robust. You can do that easily by appending &access_token=<Your_OAuth_2_access_token>. Make sure you use the same OAuth access token (formerly known as Bearer token) that you used in your API requests. This way you are sure that the image will load. this will even work if the user has signed-out of his Google Account. You will need access to the actual file's data. So this won't work if you have authorized the drive.readonly.metadata scope for instance. YOu need to authorize one of the following scopes:
https://www.googleapis.com/auth/drive.file
https://www.googleapis.com/auth/drive
https://www.googleapis.com/auth/drive.readonly
Just beware: access tokens are only valid for 1h.