I am currently creating an application for personal/internal use only that will help me upload and manage youtube videos on a number of brand accounts I have. Due to the internal nature of the application, I have listed the User Type on my OAuth consent screen is "Internal". I have set authentication up using OAuth Client ID and this works as expected for my main account.
However, when I attempt to use the same application for a brand account associated with that main account the authentication failed with the error "Error 403: org_internal" stating "This client is restricted to users within its organization.". The brand account I am trying to use is owned by the main account for which the authentication works and so I would expect this brand account to also belong to my organisation and therefore be able to use the application however this doesn't seem to be the case.
Is there something I can do to make my application work with this brand account, or some way I can associate my brand account with my organisation so that this works. I really don't want to have to go through verification for an external user type as this requires websites, privacy policies, terms and conditions and even a video detailing how the data will be used, which is massively overkill for an application I just want to use on my own personal account.
Thanks.
Related
I'm developing integration with Google Ads API using their Ruby gem library.
I have an approved oAuth2 account for the Ads scope with an approved developer token that allows any external user to connect with our API.
I have a Google Ads account that manages our own Ads account and two other accounts.
When I authenticate with the API and approve it, I then grab the account with
graph = get_accounts_graph()
Apps::GoogleAds::Account.get_accounts_map(graph)
This surprisingly returns just ONE Ads account, and one that belongs to a client that we manage. Our own two Ads accounts are missing.
So I tried to compare between our client's account and our own.
Under https://ads.google.com/aw/accountaccess I can clearly see we have admin rights to our two ad accounts, just like we do to the client account.
Am I missing some setting somewhere? Has anyone experienced this before?
I ran into this issue at the beginning. The sample in the API client libraries (which I'm going to assume you are using here), calls the customer service
customer_service.list_accessible_customers()
There's actually two different services for retrieving customer account IDs. The customer service only allows access to accounts that are added as direct admins on each account. This is an important distinction as manager accounts don't fall into this category.
What you need to call is the regular GoogleAdsService (not the customer service!) and put your request in the query itself..
query = "SELECT customer_client_link.client_customer FROM customer_client_link"
This will give you a list of account IDs as resource names, not accessible accounts. And you can iterate over them as usual.
Hope that helps.
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.
I have two applications which access my users' calendars via a service account. Until today everything was working fine and out of a sudden one of the app cannot get a grant token. I read that this may be due to the same service account being used simultaneously (which was the case for a year but never mind) so I decided to
create a second service account
and authorize it to access the calendars
I created the service account in the Google Developers Console -> API Manager -> Credentials.
The console now looks like this:
Service account client 1 is the original service account which was working for both apps and now works for one of them only. The ga... account is the newly created one.
In order to get the ClientID I went (on the same page) to "Manage service accounts" and I get this:
The newly created account does not offer the possibility to check its ClientID. Why?
The ClientID is also available in the JSON file downloaded upon creation. I extracted it from there and tried to authorize the access in my GApps Security console:
As you can see it was refused.
What part did I miss when creating this second account?
Found it:
and after checking the checkbox below both accounts look the same, the ClientID is available and it can be authorized in the GApps console.
I am just getting started with the google classroom api. I signed up for the developer test accounts and have 1 teacher account and 2 student accounts. I created a couple of classes and enrolled the 2 students in the classes. I want to use the api either via .NEt or Javascript. The prerequisuites state that I need a Google Apps for EDU account with Google Classroom enabled. How do I get this? Also, I assume without having the Google Apps for EDU account I cannot perform the first step:
"a) Use this wizard to create or select a project in the Google Developers Console and automatically turn on the API. Click Continue, then Go to credentials."
When I perform this step when logged in under the teacher account I get an error:
Error
"Developers Console has not been activated for your account. Your account may be suspended or disabled. If you are a Google Apps user, ask your domain administrator to enable Apphosting Admin on your account."
To obtain a Google Apps for Education account, you have to register your domain (or buy one), and fill up this form.
When filling the form, you will get information about the requirements needed to get the account.
To create a project in the Developer Console, you can do it even from your gmail account. After you created the project, you can enable the Classroom API so you application can access it.
When you run the code, you will have to login with a valid account (teacher or student). If you try to access the API with an invalid account you will get an error.
You can also use the Classroom API methods in the documentation. For example the resource curses.list has a "try it" section, where you can try the API before creating any project. There you can see how it works.
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.