As part of Google's security review of apps that have access newly labeled restricted scopes it was suggested that we update our scopes to a few scopes which are still restricted but are more limited. So, we compiled and submitted an update to our scopes now our app is no longer verified and has to go back through a verification process. In the interim, now our new users when connecting to their Google accounts with our service are presented with very intimidating warnings about the application now being verified.
Does anyone have advice on how to proceed with this? Feels wrong for adjusting to reduced scopes to result in this behavior.
The OAuth Application verification team isn't a support team that can be reached, until they reach out to you. Make sure you've followed the appropriate steps:
You've submitted the verification form.
You or the project owner have received messages from the verification team. Then you can address any questions from there.
Most of the answers regarding the verification process you're looking for can be answered by reading through the FAQ .
Related
I'm developing a webapp which allows users to log in with their Google accounts, using OAuth2.0.
I've created an OAuth2.0 client ID, configured the OAuth consent screen with the Publishing status set to 'Testing', and added a test user.
The frontend of my app is built with React, and I'm using a package (react-google-login) to handle the flow. I can successfully sign in with the Google account I added as a test user, and retrieve the basic profile information needed.
The problem is I can also sign in with other Google accounts, which have not been added to the list of test users. I imagine that Google should simply not issue access tokens for accounts which are not in the list of test users.
I feel like I've misunderstood something about the OAuth process, or I have configured something incorrectly. I would appreciate if anyone had any pointers?
Thanks.
It is indeed bugged.
I was in the same spot as you, assuming I had misunderstood something. After reviewing my code over and over with no luck, I made a Stack Overflow post, in which I was advised to post to Google's bug tracking system. After doing some troubleshooting with Google they confirmed the bug, and they are now working to fix it (for a little while already).
I included this thread as an example when talking to Google. I meant to post an update here after getting in touch with them, but I forgot, sorry!
The buganizer thread with more details:
https://issuetracker.google.com/issues/211370835
Is it possible you're only asking for the email scope?
It appears the test user filter and possibly the whole concept of the 'app' being in test mode exists only inside the consent screen feature.
For some reason, Google doesn't show the consent screen if you only ask for email.
So... maybe that means you don't need a consent screen, and therefore don't need to care what that feature thinks about your app (that your app is in test mode and needs to be verified before going into production).
Or maybe it's a bug? Or maybe just because you can do this doesn't mean it's allowed by Google's terms. Maybe they just haven't implemented preventing that use case.
Anyway, it may help you to know that if you add a more significant scope like the Calendar API then the following things will change:
Non-test users will get a message like "The developer hasn’t given you access to this app." and won't be able to complete oauth
Test users will get a message like "Google hasn't verified this app"
Test users will see a consent screen
Basically, everything starts working as expected.
By the way, just putting "email" or "profile" for scope seems to be an old way of doing things, and all the newer scopes want you to use a full URL for the scope (despite google themselves not using the full URL when you're configuring your scopes).
For example, if you want the email and calendar scopes, you can put this value for your scope field:
email https://www.googleapis.com/auth/calendar
Or you can use this equivalent value:
https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/calendar
Not suggesting you add a scope like email for the sake of it, just that it sheds light on what's happening, and if there's a scope like that that you need anyway, adding it will solve your problem.
I've been unable to access the Dialogflow console. I've tried logging out and logging back in, clearing site data, using different browsers and incognito mode. I even gave myself Dialogflow admin permissions through Google Cloud Console's IAM.
I've submitted a support request, but waiting on a response. Other folks have asked similar questions on stackoverflow without any response so far. I hope someone can share how to solve this.
You can try to reset your account as indicated in this similar issue from the Public Issue Tracker, specifically follow the steps from comment#2.
If the issue persist, you will need to wait the response from support.
While Isaac's answer here is valid and something that was suggested by the support team as well, the reason turned out to be a change in my email address. The fix was done by Dialogflow's team behind the scenes.
If anyone else faces an issue logging into Dialogflow and have made any change to their email address (including domain) recently, that would be something you would want to convey to Dialogflow's support upfront.
I'm developing a login page for my Django application and am using Google login for users to gain access. My question is if they sign on successfully, do I need some way to change the state of their sign on for security purposes?
Might be a silly question but I honestly have no idea and want to be sure.
No, not a silly question but a thoughtful one.
Using Google or other OAuth2 providers for your login is Ok, you request a set of scopes and when your user login and accepts to continue, you can make requests within those scopes. The flow is outlined here for Google https://developers.google.com/identity/protocols/OAuth2.
Generally, you won't have far-reaching access to manipulate users' accounts and for some scopes, your app needs to be verified. For web applications, remember your users will see the scopes you are requesting and can always decline. Because of this, it's generally a good pattern to request the scopes when you need them.
If your public application uses scopes that permit access to certain user data, it must complete a verification process. If you see unverified app on the screen when testing your application, you must submit a verification request to remove it. Find out more about unverified apps and get answers to frequently asked questions about app verification in the Help Center.
https://developers.google.com/identity/protocols/googlescopes
That's Google trying to keep users safe.
By the way, users can always revoke the access they have given your app at any time and for any reason.
I'm struggling with a the new OAuth verification process that Google has introduced. Earlier, my OAuth app was using sensitive scopes, and I made changes to ensure that the sensitive scopes are no longer required, and removed them from the OAuth consent screen configuration.
However, my OAuth consent screen is still being forced to go through the verification process (which is a black box and never seems to complete!)
I noticed the following user-cap being breached. Could the forced verification be because of this? How do I check which users are connected to my app, and also manually disconnect them? I have never bothered about this user-cap in the past, so it is quite possible that a number of these are internal/test users when the app was under active development and was being tested in production. Btw, if app simply deletes a user's refreshToken from the DB, and the user is forced to re-connect, will that count as +2 or +1 while calculating users against this cap?
Possibly related to How can I confirm the user limit of my google cloud/API? -- but that doesn't answer this question in detail.
I noticed the following user-cap being breached. Could the forced verification be because of this?
probably but only google can really anwser that
How do I check which users are connected to my app, and also manually disconnect them?
You cant there is no way for you to know what users where connected to your app and disconnect them unless you have saved a refresh token for these users if you have then you could remove them using the revoke command.
However this is no guarantee that the number google is displaying is going to change as it could be just a running total of users who have consented to your application in the past and not the ones who have currently consented. There is no way of know ing this as google hasnt told use.
if app simply deletes a user's refreshToken from the DB, and the user is forced to re-connect, will that count as +2 or +1 while calculating users against this cap
This may be true but that doesn't mean that the user has revoked your access to their application though their account. The only way to remove access is for the user to remove it in their account or for you to use the revoke endpoint to revoke them by force. Your application not having a refresh token doesn't mean that the user hasn't granted your application access.
Long story short your going to have to go though the verification process and wait for google to remove it when they see that you are no longer using the scopes that would require it.
Update: I have pinged someone on the team to see if this is working as intended or if it could be a bug. I will update this when i know more.
I am building an in-house application which would accumulate the information from several social networks at once. Possibly, the URL of the application will not be known or it will not be allowed anywhere outside localhost.
One of the information pieces I will be accumulating is FQL insights table information: https://developers.facebook.com/docs/reference/fql/insights/ . As you may notice, this information is private, so I just cannot fetch it anonymously.
The application itself is written in a "configure once and use forever" fashion, and possibly the person using the application will not be allowed to the Facebook login credentials at all.
My problem is the Facebook login. As I understand the login with "forever access" is now deprecated and Facebook does not allow API access the same way as Twitter does (creating the forever lasting key and forgetting about it). Question is:
Is there any way to overcome the fact that I need to ask the person for permissions every time I would like to fetch them? What can be the longest period between asking?
My current thoughts about it are:
Creating a dummy user for the 'manager' and giving him read-only
access to FB pages, therefore enabling him to log in to the account.
Then asking him for the permissions every (n) hours when I need them.
Automatic log in to the FB account given that we have the
login/password for the account and obtaining the API key myself.
Which is doable? Did anyone have any experience in doing this kind of things?
What can be the longest period between asking?
You can use Long-lived user access_token which is valid for 60 days.Use below FB call to get extended access token:
https://graph.facebook.com/oauth/access_token?client_id=APP_ID&client_secret=APP_SECRET&grant_type=fb_exchange_token&fb_exchange_token=EXISTING_ACCESS_TOKEN
You can check more details here:
https://developers.facebook.com/roadmap/offline-access-removal/
One more point which is worth to note here:
When a user change his password, deauthorizes an app their OAuth token get expired.
Hope this help !