We are setting up an "app" in Google Cloud Console for the sole purpose of single sign on - letting users sign into a WordPress site and a Moodle site using their Google accounts.
When setting up the "Oauth Consent Screen" - there is a "Submit for Verification" button which is disabled (grayed out). The verification Status is "not published".
The question: does it need to be verified? The documentation, such as there is, hints darkly at various limitations if it is not. Yet, there appears to be no path to get it verified.
It "works" in testing for allowing log in with Google account, but the organization has a large number of users. Are we going to hit limits if we go live with it?
We haven't added any scopes. Do we need to, just to get the ability to get it verified? It "works" in testing, without having added any scopes.
Any insight is welcome on how to get this app verified - or as whether we need to have it verified (maybe it can't be verified because it doesn't need to be?).
Related
I'm trying to follow the instructions here which tell me to create credentials via the instructions here, which as step 6 tells me 'Click the user type for your app. If you're running a Quickstart, select Internal.'
On the page in question, 'Internal' is greyed out, and tells me I can't select it because I'm not a Google Workspace user. Going to Google Workspace, it tells me I need a domain name for 'my business'. Since I don't have a business, or any domain that would have anything to do with this project (I just want to push some personal data from the command line to a sheet), I don't seem to be able to proceed. Is the Google Sheets API just not available for such use?
If you don't have a Workspace account but you don't want to publish your app publicly (and go through the associated review by Google), you can set the app to External and test the app instead of publishing it.
In order to do that, just add yourself as Test user when setting the OAuth consent screen, and leave the Publishing status on Testing, don't change it to In production:
Testing
Projects configured with a publishing status of Testing are limited to up to 100 test users listed in the OAuth consent screen. A test user consumes a project's test user quota once added to the project.
Google will display a warning message before allowing a specified test user to authorize scopes requested by your project's OAuth clients. The warning message confirms the user has test access to your project but should consider the risks associated with granting access to their data to an unverified app.
Authorizations by a test user will expire seven days from the time of consent. If your OAuth client requests an offline access type and receives a refresh token, that token will also expire.
Reference:
Publishing status: Testing
Unfortunately, that means that the authorization lasts only for 7 days. Which means that I have to keep creating new projects every 7 days, which is untenable. Here is the excerpt from the "Setting up your OAuth consent screen" page on the Google support site.
Authorizations by a test user will expire seven days from the time of consent. If your OAuth client requests an offline access type and receives a refresh token, that token will also expire.
I've created a project on google console.
I need to get access to Drive API, so I need to configure OAuth2 settings.
It's requesting me for three kinds of information:
Credentials: I got it. I need the client ID and client secret in order to google identify my client.
Consent screen: I don't quite figure out what's that for. Is it the screen that appears when a user grants consent to application to act as behalf of him?
Domain verification: What??
When I'm creating consent screen, google is requesting me these fields (some of them are required).
I'm just creating an service for tasting Drive API. I mean, I don't have any authorized domain, homepage, policy or terms of services links. I just want to play around.
Also, google is telling me consent screen has to be verified:
Any lights please?
I just wanted to check my understanding here.
When I log into some applications e.g. Dropbox with my Google account, I get a consent dialog:
I can then revoke access in my Google account as I would expect.
However, when I sign into other apps e.g. SoundCloud, I don't get a consent dialog at all, it just takes me straight in. Neither does SoundCloud appear in my list of revocable apps in my Google account.
I am presuming that this is because SoundCloud does not require any information or rights with respect to my Google Account and therefore no consent is required. That is, all it requires is authentication, which does not require consent (presumably because entering your credentials is considered consent enough for this purpose).
I just wanted to confirm that I am correct in my assumptions.
You have found the answer to your question.
If you check Dropbox's login request, it contains a special scope value https://www.google.com/m8/feeds which stands for Mange your contacts (reference).
Dropbox scope parameter - scope=https://www.google.com/m8/feeds+email+profile
But if you check the same with SoundCloud, you only see profile specific scopes such as email profile openid
Soundcloud scope parameter - scope=email profile openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/plus.me
So yes, you get the consent page because of the special scope present in Dropbox authorization request. And consent page matches with scope value.
Further read this blog on default scopes and special scopes.
p.s - You can monitor these scope values with browser debugger. You must enable debugger for popups and navigations to see them. I used chrome to extract those values.
I privately host a site for my family that uses the Google Spreadsheets API (readonly). I received an email from google looking to "Remove risky access to your data". My site is listed with a warning:
I've gone through the verification process (filling out this form: https://support.google.com/code/contact/oauth_app_verification) but got the response that if the site is used privately "you don't need to go through the verification process". They state this in their FAQ also: OAuth Developer Verification Form FAQ.
However, the site still shows a warning in Google's security check-up. I can ignore this but I think other family members will be worried unnecessarily OR ignore future warnings about other apps assuming it's the family one they normally ignore.
Is there a way to verify myself as a developer of a private site or mark the access as trusted so the warning doesn't recur?
I ended up making my site public and going through the usual verification process.
Not really an answer, but rather to flag that this is an issue my dilemma as well. Although I run time-based Google Script within an organization. I've contacted folks at the Google Cloud Platform and they have opened a case. However, here is something interesting I've stumbled across just now. Go to your Google account and do Security Checkup
After the checkup your screen might be showing something like this
Try clicking "Dismiss" to prevent Google from removing your app.
I'm just testing it myself and if in an hour (that's how long it usually takes Google to remove your own script from the list of self-authorized apps with access to account info) Google won't remove it, I guess it would work for me!
As part of our "off-boarding" process for employees leaving the company, as super admins we use the Google Apps Admin SDK Directory API to change the user's password so that they can no longer access their account. Then we log in to do a Google Takeout, reset passwords for their other accounts, etc.
However, we recently decided to enforce 2-Step Verification for all of our users. So now when we go to log in to their account, it sends a code to their phone.
Since 2-Step is enforced for their SubOrg, we can't even turn it off through the admin console. So all I can do now is to have the API move the user to a different SubOrg where the 2-Step enforcement setting is turned off, and then manually turn off 2-Step.
Is there any way to programmatically turn off 2-Step verification for an account?
I looked in the Google Apps Admin SDK Directory API Users:update documentation, but it doesn't seem to have anything to do with 2-Step.
The Reports API can find out the user's enrollment status, but it's read-only for reporting purposes.
What you are doing is the correct way to remove the 2-Step verification. As you mentioned if it is enforced under a Organization Unit, removing it would get against that rule and that's why you are not able to do it unless you move the user to another OU where this is not enforced.
I was not able to find some way to do this programmatically. However, you could Suspend the user. After that, the user won't be able to access to that account. The account will still be visible in your Admin Console and all the information in the different Google services will remain attached to that account until you finally delete the account.
While the user is suspended, as admin, you can use service account to impersonate that user. By doing so you can act as that user and edit permissions or transfer the ownership of the files contained in Drive to a different account so those files won't get lost.
I hope this helps.
The easiest way to do this is to create a Group for which 2FA is exempt (see here: https://support.google.com/a/answer/2370108). Then add the user to that group, then you can click "Disable 2FA" on the user page in the admin console. I'm assuming you can do the same through the API.
The only downside is that this means you'll have a group through which it is possible to exempt users from the 2FA enforcement option. So that's a risk you'll have to accept and a policy you have to carefully check.