I have submitted an app for Verification on google cloud platform.
which has been published successfully on google chrome store.
Google provided feedback regarding verification process:
Below mentioned outstanding item:
The app project client_id in the URL bar of the OAuth Consent Screen/Permissions Page
is not shown.
Issue:
The issue is URL bar is not visible on consent screen i.e Identity API Scope Approval UI.
I had removed all the permissions (from Google account which I used to sign in chrome) and even deleted the cookies still the URL bar was not visible on consent screen i.e Identity API Scope Approval UI.
I am using Version 89.0.4389.90 (Official Build) (64-bit) chrome browser.
Could anyone please explain the root cause behind url not coming on Oauth screen.
You could try to right click the window of the OAuth screen and select "Show as tab" to see the full URL.
Related
I faced with the following problem:
OAuth screen of my application has been verified and in console.cloud.google.com has the Verification Status "Verified", but one of the users gets the OAuth screen "Google hasn't verified this app".
User uses MacOS and Unverified OAuth screen gets in Safari and in Chrome.
Found the problem.
App is verified but when i send the request with the scope which is not added to the scopes.
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 have a web-app built with the AWS Amplify framework. I rely on Cognito Hosted UI w/ identity federation for registration and login. In reviewing the registrations for my app, I noticed that it got 70+ registrations, but of these only 12 went on to create user profiles. I tested creating an account and signing in through each identity provider (Amazon, Google, Facebook) as well as through standard signup with an email and password. I never had any issues.
I started testing more heavily on mobile and eventually I started to encounter the an error. I plugged my mobile device into my laptop, navigated to chrome//:inspect and checked the network tab and JS console. Only when my chosen identity provider required an OTP code, I noted that I was getting invalid_request and invalid_grant errors on after I input the code and continued with sign-in, even though registration seemed to work (I say registration seemed to work because I received AWS credentials in the initial response and amplify-signin-with-hostedUI was set to true in localStorage. Also, when I open the AWS Console and go to Cognito, I can see that I've been added as a user in my User_Pool).
If I refresh the browser at this point, it seems a new request is sent off to /token, but it comes back with a 400 error with the invalid_grant message.
I kept poking around and eventually found something interesting. There are three tabs involved in the login process, and I think this is somehow messing things up. On mobile, when I try to register or login with the Cognito Hosted UI, I am first met with the Federated Identity Provider buttons and email/password page.
First I got to my website (Tab One). Then I click sign-up and the Hosted UI page pops up (Tab Two). I select one of the login methods (Amazon, Google, Facebook, or Email/Password). If the selected method requires no OTP, I'm golden. I'm redirected to my web app and the app works fine. If my selected method requires an OTP, a new tab opens (Tab 3) which asks for the token. At this point, I can see in Chrome devtools that an error occurs on this tab (Tab 3).
After plugging in the OTP code and clicking sign-in, I'm redirected, as expected, back to the my web-app, but this redirect occurs in the original tab (Tab One), however with a query string added to the URL (/?code=). If I click the view tabs button, I see that the Hosted UI tab (Tab Two) is still open and still has the Cognito Hosted UI buttons/username+password page open. Not sure if that's important.
Now on Tab One with my web app, I don't immediately see any errors in Chrome devtools. But I can see that my app is unable to load. If I wait, it just loads and loads forever. If I refresh the page, then at this point I see a new request to /token fire off in the Network Tab of Chrome DevTools and it comes back with the 400 error invalid_grant response.
Has anyone else encountered this issue or found a resolution?
Thanks in advance!
I submitted changes to my OAuth consent screen.
Name change
logo update,
2 new scopes
domain change
Google contacted me to send them a video that show how I would be using the 2 new scopes. I did this and after that they approved everything. The verification status changed to "Published" and all domains and scopes have a green tick next to them.
I can see the logo & name change when I do a normal login. When I request the new scopes on the screen where it is needed I still see the "This app isn't verified".
I have confirmed that I am sending only the scopes in the consent screen.
openid
profile
email
https://www.googleapis.com/auth/calendar.events
https://www.googleapis.com/auth/calendar.readonly
I replied to the emails that google sent me to ask if there is still something that needs to be approved, they just reply and ask for a video. It looks like an automated response, but then I send them another video.
What more needs to be done to get the app verified? I did go through all their documentation.
Problem is that Google was correct and the scopes the app was submitting is incorrect.
What was approved by google:
https://www.googleapis.com/auth/calendar.events
https://www.googleapis.com/auth/calendar.events.readonly
But the app was requesting:
https://www.googleapis.com/auth/calendar.events
https://www.googleapis.com/auth/calendar.readonly
Almost the same, but not. Always triple check that what you are sending is the same as what is allowed.
I'm building an AspNet Core 2.1 website using Azure AD B2C authentication, based on the example code I found here.
I can authenticate against the Google identity provider. But instead of showing a custom page based on the attributes I selected for the signup/signin policy in the Azure AD B2C portal, all I get is the normal Google authentication page asking me which Google account I want to authenticate against.
I was able to display a custom page listing all the attributes I'd defined in an earlier version of my project, which used the deprecated microsoftonline.com domain. But now that I'm using the recommended b2clogin.com domain the page is no longer appearing. I don't know if that change has anything to do with the missing page, but I thought I'd mention it.
My appsettings.json file is:
{
"AzureADB2C": {
"ApiScopes": "https://ridemonitor.onmicrosoft.com/api/user.read",
"ApiUrl": "https://ridemonitor.azurewebsites.net/hello",
"CallbackPath": "/signin-oidc",
"ClientId": "**redacted**",
"Domain": "ridemonitor.onmicrosoft.com",
"EditProfilePolicyId": "b2c_1_ProfileEditing",
"Instance": "https://ridemonitor.b2clogin.com/tfp",
"RedirectUri": "https://localhost:44305/signin-oidc",
"ResetPasswordPolicyId": "b2c_1_PWReset",
"SignUpSignInPolicyId": "b2c_1_SignUpIn"
},
"Logging": {
"LogLevel": {
"Default": "Warning"
}
},
"AllowedHosts": "*"
}
Update
I've configured two identity providers for my app, Google and Microsoft Account. The Microsoft Account provider does, in fact, display a customized page listing all the attributes I set in the Azure AD B2C portal when I authenticate it. It's just the Google route which has stopped displaying the custom attribute page.
The redirect uri in Google Cloud Platform -> Credentials is:
https://ridemonitor.b2clogin.com/ridemonitor.onmicrosoft.com/oauth2/authresp
which is the url I should be sent to, and used to be sent to by the Google identity provider, and is the url the Microsoft Account identity provider sends me to when I try to log in.
It looks like I need to update something in my Google configuration, but I'm not sure what.
Update #2
Using the Chrome developer's console, and Link Redirect Trace, I tried to see how I ended up on the pages I ended up on after clicking both the Google and Microsoft Account signin/signup links.
The Google button lands me on the generic Google login page. The initial redirect (there are several subsequent ones) appears to be:
https://accounts.google.com/signin/oauth?client_id=769952297467-qhqd9brt7pl4sra1hnjhnnqchce2h6f1.apps.googleusercontent.com&as=c-8m6tr-h2tUDpRHqIApkQ&destination=https://ridemonitor.b2clogin.com&approval_state=!ChR4aFltdld5TGNwWUEyUlA1R0R6TRIfczBDdExlN01TRElYa013TWpqbVNUV1h5alREUVloWQ%E2%88%99ANKMe1QAAAAAW7K6uQbexonsHodkbBOebSymUYB1yufO&oauthgdpr=1&xsrfsig=AHgIfE8msp705-PG2II5uHWqjoODqYSLPg
The initial redirect for the Microsoft Account button is:
https://login.live.com/oauth20_authorize.srf?client_id=704398a8-908a-4512-9cc0-4453014b4714&redirect_uri=https%3a%2f%2fridemonitor.b2clogin.com%2fridemonitor.onmicrosoft.com%2foauth2%2fauthresp&response_type=code&scope=openid+profile+email&response_mode=form_post&nonce=TQsICDEyv245x1E4pkQynQ%3d%3d&state=StateProperties%3deyJTSUQiOiJ4LW1zLWNwaW0tcmM6ZjBlYmQ4OTUtNmVjYS00NzBhLWE4ZDYtY2U4NTgyYzFmZmNjIiwiVElEIjoiNzIwZDg5NDEtNmM2Zi00YzIzLWI5MWEtZDMyZjJjODA5Yjk4In0
Comparing the two initial redirects, what's interesting is that the one for Google does not contain a parameter for the redirect_uri. Which I presume is the place the browser should be sent after a successful authentication.
Yet my Google credentials page would appear to be set up correctly:
Or am I maybe not configuring stuff in the right part of the Google ecosystem? I thought I was following some Microsoft directions regarding Google credentials, but...
Do you get any error messages?
Try using your browser's dev tools to check any error logs and identify the CSS styling that took effect in your html elements. It's possible that your custom classes are being those overwritten by the Google default styling.
You can edit the CSS within your browser's dev tools and then update the CSS files in Azure Blob Storage when you are happy with them.
Refer also to this thread and this one to see if these issue might be similar to yours.