I have received an email from Google Cloud Platform telling me I need to complete the OAuth developer verification process but in my Google Cloud Platform, looking at the OAuth consent screen, my App is already shown as verified - see below.
The email states that I have "not completed the OAuth developer verification process are limited to 100 new user grants.
Your Google Cloud/APIs project XXX (id: XXX-1234) has not completed this process and has reached 60% of this user limit."
Is OAuth developer verification different from being verified? I can't find anything useful in the Google help about this
Any help or further information as to how to comply with the OAuth developer verification process would be very much appreciated
OAuth consent screen
As noted under Publish your app (before you publish), your app is reviewed to determine if it meets the requirements for the relevant store. Additionally, your application may also have to undergo OAuth verification (I think this could be the problem) , and security assessment if it accesses user data, such as Gmail, Drive, Contacts, or Calendar
Related
I have a Google Cloud Project that is using some sensitive scopes and will soon get verified. Currently, there is one OAuth web app client ID, but in the near future, I am planning to add iOS and Android clients. I know that Google's documentation states that the app needs to be re-verified in case there are some additional sensitive scopes added, but I couldn't find what happens if I add new OAuth clients. The new clients will not use any of the sensitive scopes that the web app client uses. Will the app have to be re-verified after adding additional clients? Thank you.
As far as i understand you are verifying the consent screen. For example in the event you are using an api key no consent screen is needed, the same goes for service accounts.
Once you add any type of Oauth2 client you will need to apply for verification. Its the consent screen and the scopes that it is require that is verified.
Adding other clients should not effect your consent screen you have been verified for those scopes already.
OAuth API verification FAQs
Response from Oauth team member.
I have pinged someone on the OAuth team hoping to hear from them for verification.
update:
I am paraphrasing the response I got back from my google contact
Currently if you add a new OAuth client type you do not need to go though the reverification process. However google reserves the right to change that in the future.
We are using Google to enable users to use their Google account to authenticate themselves (using AWS Cognito federated sign in) with our Mobile application (we only have mobile applications, no web). We are only using the non-sensitive scopes, but even with that it seems that we are required to go through the whole verification process.
Scopes used:
OAuth scopes
But when I try and publish the application I get a popup notifying me that the verification is required and even mentions sensitive and restricted scopes:
Google publish popup
Step 1 of the verification process is ok, but the other steps are what baffles me.
When I take a look at the documentation it mentions that only if you are using sensitive or restricted scopes that verification is required.
Is there any way to setup the application so verification is not required or at least not as extensive? Most likely we have configured something wrong, or didn't understand the documentation correctly, so any suggestion would be more than appreciated.
In addition to scopes, there a few more reasons why your consent screen might require verification:
You want to display an icon or display name for your project on the OAuth consent screen.
Your project's OAuth clients request authorization of any sensitive or restricted scopes.
The number of authorized domains for your project exceeds the domain count limit.
There are changes to your project's OAuth consent screen configuration after a previous published, verified configuration.
I'm working on getting a Google app verified, and although I have completed the domain verification, the Oauth consent screen says that it is waiting on me to "comply with domain verification requirements." What does this mean?
1. I've confirmed that I completed domain verification at https://www.google.com/webmasters/verification/home. (With my personal google account, I verified the domain with a DNS TXT record, then delegated it to my work account.)
2. ...and I've set that domain as the sole authorised domain for my app...
3. Nevertheless, the Oauth consent screen says that I still need to comply with the domain verification requirements. Why would this be?
Once you have completed the actions specified under "Pending developer action", you will need to reach back out to the Google verification team to inform them that you've taken action for your app verification to proceed. See https://support.google.com/cloud/answer/10311615#zippy=%2Cpending-developer-action.
I am currently building an Alexa skill backed by Azure Functions (.NET Core/C#) and Azure AD B2C for authentication.
For the initial setup, I used mostly used the instructions found in this arcticle. Since, the article was written a couple of years ago, I had to make a few changes. In the end, I landed on the following configuration:
Azure Active Directory B2C
As I mentioned, we are using AAD B2C for authentication. Users of a related application are able to sign-up and sign-in to a React application. The idea is to provide an alternative interface for said users through Alexa intents + utterances.
I created an application for Alexa in AAD B2C with the following settings:
Properties
Web App / Web API: Yes
Allow implicit flow: Yes
Reply URLs: I entered the values provided by the Alexa skill setup (e.g. https://pitangui.amazon.com/api/skil/link/...); there are three different ones. I also added one for my azure function app (this is something that could be incorrect. It was part of what I did while diagnosing other earlier problems); it's in the format: https://myfuncname.azurewebsites.net/.auth/login/aad/callback (Do I even need this???)
App ID URI: https://myorg.onmicrosoft.com/alexa
Include native client: No
Keys
I generated a single App Key, which I'm using as the Secret in the Account Linking section in the Alexa Developer Console.
Many of the examples online mention setting an explicit expiration date here of 1 or 2 years; however, I am not presented with any options at all (i.e. no expiration option), just the code. Could this be part of the problem???
API Access
In the Published scopes section, the Scope's name is user_impersonation. The description is "Access this app on behalf of the signed-in user". The full scope value is: https://myorgsname.onmicrosoft.com/alexa/user_impersonation.
For API Access, I have to API entries here:
One that uses the user_impersonation scope mentioned above.
The second, titled "Access the user's profile", uses:
Acquire an id_token for users (openid)
Acquire a refresh_token for users (offline_access)
AAD B2C User Flow
The user flow that I'm using allows signing up and signing in, it utilizes the following configuration:
Properties
Misc
Enable JavaScript enforcing page layout (preview): On
Token lifetime
Access & ID token lifetimes (minutes): 60
Refresh token lifetime (days): 14
Refresh token sliding window lifetime: "Bounded".
Lifetime length (days): 90
Token compatibility settings
Issuer (iss) claim: https://<domain>/<b2c-tenant-guid>
Subject (sub) claim: ObjectID
Claim representing user flow: tfp
Session behavior
Web app session lifetime (minutes): 1440
Web app session timeout: Rolling
Single sign-on configuration: Tenant
Require ID Token in logout requests: No
Azure Function Authentication Middleware
For the authentication layer within the Azure Function, I'm utilizing the method described in the article mentioned above.
Alexa Developer Console
On the Alexa side of things, I have a really simple skill setup with the following settings:
Endpoint
My endpoint uses the HTTPS option with the default region set to the fully-qualified HTTPS endpoint of my Azure Function App's handler function.
The certificate set to "My development endpoint is a sub-domain of a domain that has a wildcard ..."
Account Linking
The account linking settings are as outlined below:
Do you allow uses to create an account or link to ...: Toggled On
Allow users to enable skill without account linking: Toggled On
Allow users to link their account to your skill from within your application or website: Toggled Off
Auth Code Grant: On
Authorization URI: https://myorg.b2clogin.com/myorg.onmicrosoft.com/oauth2/v2.0/authorize?p=<sign-in-user-flow-policy-name>
Access Token URI: https://myorg.b2clogin.com/myorg.onmicrosoft.com/oauth2/v2.0/token?p=<sign-in-user-flow-policy-name>
Your Client ID: AAD B2C App GUID
Your Secret: Key generated in App settings in AAD B2C for my Alexa Skill App (mentioned in the AAD B2C setup info above).
Your Authentication Scheme: HTTP Basic
Scope: openid and https://myorg.onmicrosoft.com/alexa/user_impersonation
Domain List: login.microsoftonline.com and myorg.b2clogin.com Note: This is probably wrong as I didn't know what to put here. The article above doesn't mention this setting at all
Default Access Token Expiration Time: 3600
Note: The Alexa Redirect URLS at the bottom are what I put in AAD B2C for the Reply URL section.
The Problem
Now for the most important part, The Problem. Everything seems to work at first...I'm able to go to alexa.amazon.com and utilize Link Account (which redirects me to and from my AAD B2C-driven login screen). Once I link accounts, I'm able to successfully utilize an utterance and receive a reply.
The problems starts when I wait an hour (I believe it's an hour). Attempting to initiate the Intent after an hour yields an error on the Azure Function app side of things when it tries to validate the Auth Token.
Can anyone provide me some guidance as to what I may have setup incorrectly or at least some things that I should look into? As I mentioned at the start of this question, many of the references that I'm finding online are out-of-date and do not cover all of the settings that I'm expected to utilize. Many of them are still using microsoftonline.com authority vs. b2clogin.com.
At a glance, I would assume that the problem is that the Alexa skill is failing to refresh its token after it expires after an hour. What do I need to do to ensure that it refreshes correctly?
I think that I have enough information at this point to go ahead and answer my own question. What I found was that the offline_access scope is necessary for Token Refresh to be possible.
Per Microsoft, "The offline_access scope gives your app access to resources on behalf of the user for an extended time. On the consent page, this scope appears as the "Maintain access to data you have given it access to" permission. When a user approves the offline_access scope, your app can receive refresh tokens from the Microsoft identity platform token endpoint. Refresh tokens are long-lived. Your app can get new access tokens as older ones expire.".
You can read more about it here.
To resolve the issue, I ensured that this scope was available in AAD B2C and added it as a referenced scope in the Alexa developer console.
Thanks for giving insight on offline_access. It took few hours to figure out how to implement offline_access. Interestingly offline_access works only with Azure AD, OAuth 1.0 endpoint and not with 2.0.
While trying with 2.0 it kept failing while account linking when multiple scopes were mentioned in Alexa configurations. The scopes I tried were as follows.
https://samplealexabackendapi/
https://graph.microsoft.com/offline_access
Finally I ended up working with OAuth 1.0 endpoint and using the scope https://samplealexabackendapi/.default which considers all scopes available to the app registered.
Does anyone know why my app would have a 100 user cap, even though the Verification Status is "Published"? It says "the user cap will be in place until the app is verified by Google", but this is already the case. I would appreciate any insight.
The 100 users cap is a quota limit for unverified scope requests, it is applied when the application tries to obtain access to scopes that have not been approved for the project during the app verification process, see this. Since you're seeing this quota being actively used you should check whether the scopes requested by your application match the ones you submitted in the app verification status. In case there is a mismatch you would need to update the requested scopes and go through the verification process once again. Optionally you might also request a OAuth quota increase with this support form, but bear in mind there's no approval guarantee.
Finally, as Pievis pointed out this kind of inquiries would be better handled by Google Cloud Support team as they have the necessary information about your project to address your questions from end to end.