Since approx 5:30 UTC we are receiving only this response for this api call
https://www.googleapis.com/appsmarket/v2/customerLicense/{appId}/{customer}
{"error":{"errors":[{"domain":"global","reason":"forbidden","message":"Not authorized to access the application ID"}],"code":403,"message":"Not authorized to access the application ID"}}
but there has not been any previous development or changes on our side and this affects all of our marketplace applications.
Any ideas what is going on and how to fix/workaround this issue?
This issue should now be fixed by Google.
If you are still experiencing 403 Forbidden on marketplace API calls make sure you are following these guidelines
Access to these APIs is restricted: only project members of the
Developer Console project associated with your application may use the
API. Specifically, these project members must be in Can Edit or Is
Owner roles. You may also access UserLicense and CustomerLicense as
the logged in user to your app. Refer to
https://cloud.google.com/compute/docs/access/add-remove-change-permissions-for-team-members to learn how to
add members to your project.
For example by doing the API requests using a service account in the Google Cloud Platform Project for you application without using any impersonation/delegation.
Related
We have an application hosted in GCP which uses GSuite APIs to sync users from GSuite to our application and visa-versa using Service Account. It used to work well until recently some of our customers started facing issues.
We started getting
401 unauthorized. "Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
There as been no change in our application and neither in the list of permissions granted. Following are the list of api access granted :-
https://apps-apis.google.com/a/feeds/domain,
https://www.googleapis.com/auth/activity,
https://www.googleapis.com/auth/admin.directory.group,
https://www.googleapis.com/auth/admin.directory.orgunit,
https://www.googleapis.com/auth/admin.directory.user,**
https://www.googleapis.com/auth/admin.directory.user.readonly,
https://www.googleapis.com/auth/drive,
https://www.googleapis.com/auth/drive.appdata,
https://www.googleapis.com/auth/drive.file,
https://www.googleapis.com/auth/drive.metadata,
https://www.googleapis.com/auth/drive.metadata.readonly,
https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly,
https://www.googleapis.com/auth/admin.directory.rolemanagement,
https://www.googleapis.com/auth/admin.directory.device.chromeos.readonly,
https://www.googleapis.com/auth/admin.directory.device.chromeos,
https://www.googleapis.com/auth/drive.apps.readonly,
https://www.googleapis.com/auth/drive.photos.readonly,
https://www.googleapis.com/auth/drive.scripts
The affected GSuite domains were working perfectly until yesterday. Also there are some domains which still work without any problem.
Can somebody please suggest what could the problem be. Is there any change in the APIs recently? Any help will be much appreciated.
"Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
There are several ways to authenticate to Google.
web based applications
native applications
mobile applications
and service accounts
The clients you create for these types is different as is the code to use them. The message you are seeing above means that the code you are using does not match the type of client you have created.
Make sure your code is designed for use with service accounts and make sure that the credentials file you have downloaded from google developer console is in fact credentials for a service accounts.
Why it worked previously and suddenly stopped i cant tell you this is an error you will always get if your code does not match your credential type.
The last option would be to double check that all of those apis are enabled in the Google developer console for your service account project.
Today I've received email from Google, that claims my project uses one scope plus.me from Google+ API which will be shutdown.
I've already implemented Google Drive API usage with new OAuth 2.0 in my app. And was trying to find where it uses that Google+ scope.
The only place where this scope exists is in "OAuth consent screen" in Google APIs console.
But there is no "Delete" button. So I'm wondering how could I remove it? I'm afraid with shutting down Google+ my requests to OAuth 2.0 could be denied :(
Whew! Today got clarification from Google with subject "[Correction] Google+ APIs being shutdown on March 7, 2019".
Earlier this week we sent you an email related to your projects that will be impacted by the Google+ API shutdown, which also affects requests for Google+ OAuth scopes.
The email listed that one or more of your projects are requesting the
“plus.me” scope, and would thus be affected. We would like to clarify
that only projects directly requesting the “plus.me” scope are
affected. This scope may have been listed in some emails, even if not
directly requested by your project. We apologize for any confusion
caused.
If you are directly requesting the “plus.me” scope, any other Google+
OAuth scopes, or making any Google+ API calls, please ensure that you
remove these requests from your project before March 7, 2019.
To see if your project is directly requesting the “plus.me” or any
other Google+ OAuth scopes:
If your project is written in Google Apps Script, you can view which scopes your project is requesting by reviewing your project
properties in App Script Editor.
If your project is not written in Google Apps Script, please check your code for references to “plus.me” in OAuth scope requests. We
recommend that you review projects using any 3rd-party libraries that
support sign-in or social functionality, as these may also be affected
by the shutdown.
So it seems we should not worry about the plus.me item any more. Just remove this scope from the code if we use it.
I received this error when trying to authorize my app with my own account:
Your project is trying to access scopes that need to go through the verification process.
{invalid=https://www.googleapis.com/auth/contacts}
If you need to use one of these scopes, submit a verification request. Learn More
When I use a different account, the error message is different:
This app hasn’t been verified to access:
{invalid=https://www.googleapis.com/auth/contacts}
Are you the developer? If this project needs these scopes, sign in to an account with access to edit your project and try again.
If not, contact the developer for help.
As per the announcement on May 11, 2017, publicly available applications with access to certain user data must pass review. If you see an access error for your app, submit a request using our OAuth Developer Verification form.
For personal-use apps and those you are testing, join the Google group Risky Access Permissions By Unreviewed Apps, which allows you to approve data access for personal and testing accounts. See the Google API Services User Data Policy for more information.
UPDATE: Corrected broken link to form.
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.
We publish an app that use OAuth 2.0 API access on Google Apps Marketplace. It got reviewed by Google and they said our app is invalid because it shows permission screen when a user first runs the app. (The app will be removed from the Google Apps Marketplace if our app is not fixed within 30 days) To solve this issue, we have some problems.
Our app uses OpenID Connect to make users login.
Our app also uses Spreadsheet API and Calendar Resource API (OAuth 2.0 Web Application Flow)
So our questions related above is the followings:
1.
Although our app uses OpenID Connect for login, using OpenID Connect forces our app to show the permission screen. Doesn't it meet the best practice below of Google Apps Marketplace?
https://developers.google.com/apps-marketplace/practices#5_use_one-click_single_sign-on
We followed the OpenID Connect document provided by Google:
https://developers.google.com/accounts/docs/OAuth2Login
2.
Since Spreadsheet API and Calendar Resource API don't currently support the authentication method using Service Account with OAuth 2.0, we chose to use the method of Web Application Flow. Our app get the token when users login, but Google said to us that it fails to meet their SSO requirements. To solve the issue, we are thinking to change our app to authorize AFTER login within the app instead (use Web Application Flow method as it is). Does the way meet the SSO requirements? In other words, is it OK to show permission screen if after login?
We will applicate if anyone can tell us good solution to solve these problems.
Thanks,
If you register your scopes in the Google Apps Marketplace configuration screen, and then only request those scopes in the OpenID Connect flow, then the permissions screen should be automatically skipped. Please ensure the scopes match between these two locations.