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.
Related
I am carrying out the OAuth verification in Google Cloud Platform, I received an email that said:
"Thanks for your patience while we reviewed your project.
Your project pc-api-XXXXXXXXXXXXXXX-XX has multiple unique domains in the redirect URI and origin URLs, many of which have unrelated applications. This is in direct violation of the Google API Services: User Data Policy, which requires that projects accurately represent their identity and intent to Google and to our users when they request access to Google user data.
Please follow the instructions on the Google API Console to:
Create new projects
Migrate your redirect URIs with distinct brands to different projects, and/or
Ensure that these projects accurately represent their true identity to Google users
You can find more information in the OAuth Application Verification FAQ. To make sure we don't miss your messages, respond directly to this email to continue with the verification process."
I have a web server, which checks the validity (domain-1.com) in-app purchases, and I also have a site with a different domain containing: privacy-policy and terms-of-service (domain-2.com).
My settings are as follows:
OAuth consent screen:
Home page application: https://www.domain-2.com/
Privacy Policy: https://www.domain-2.com/privacy-policy/
Terms of Service: https://www.domain-2.com/terms-of-service/
Authorized domains:
domain-2.com
domain-1.com
ID client OAuth 2.0 -> Authorized Redirect URIs:
https://game.domain-1.com:8443
I have a working service account.
I have successfully verified all 2 domains.
Where is the mistake?
I have found the solution:
I had 2 Google Cloud Platform projects for the same application.
I deleted a Google Cloud Platform.
I implemented all the configurations of the deleted project in the other project, and it worked!
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.
I am using google contacts api to get the contacts but everytime it shows the 'Unverified' consent screen,even though I allowed it many times. I skipped the verification process for the app in google console because I am not using any sensitive scopes and so didn't add any scopes to OAuth consent screen.
N.B. In my another project with the same configuration and no scopes added, everything is working fine with no unverified consent warning.
What you are experiencing is the expected behavior in this situation.
The Unverified app screen appears due to the following reasons:
Your app uses sensitive or restricted scopes and you haven't configured them in your OAuth consent screen configuration page and requested verification.
Your app uses sensitive or restricted scopes that you haven't selected on the OAuth consent screen configuration page.
You selected sensitive or restricted scopes on the OAuth consent screen configuration page and requested verification, but the verification is not yet complete.
Moreover, it's important to note the following as well:
When the scopes requested in your app code differ from the scopes requested in your OAuth consent screen configuration page, your users see an "unverified app" screen. Make sure that scopes you request in your app are the same as what's in your OAuth consent screen.
As for the sensitive scopes, you can determine them by simply looking for the lock icon in the Cloud Console of your project.
Reference
Unverified apps;
OAuth API verification FAQs.
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.
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