We have an app that over time obtained and worked with Google OAuth2 tokens. Now it got the 'Unverified app' status allowing < 100 installs. We know we have < 100 users with active access tokens but the Google OAuth team tells us there are > 100 outstanding access tokens.
How can we revoke those unused/orphaned tokens that our app does not track anymore? We can't issue the 'revoke' requests because we don't know those tokens. Is there a way for an app to list all outstanding oauth2 tokens or to revoke all its tokens?
Thank you
Such an access token has a lifetime of about an hour - you probably mean app authorizations aka "Third-party sites & apps with access to your account", which last until being revoked by the user. So generally there's not much to do about it, unless suggesting the users to revoke the access manually. Changing the name of the package might be the only option available on your side, to get rid of them.
Authorized users
First off you don't have unused/orphaned tokens not really. What you have is users who have granted your application permission to access their data. There is no way for you to see exactly who these users are. There is no way to remove their granted consent unless you have refresh tokens for each of them saved in your system some place. If you do you could call a revoke on all of those refresh tokens and it should / might release a few of your 100 installs. This is just a guess i have never tried it.
curl -H "Content-type:application/x-www-form-urlencoded" \
https://accounts.google.com/o/oauth2/revoke?token={token}
application verification
The issue you are having is that your application is unverified. Google has placed a limit of 100 installs on unverified applications during the development process this way you can test your application before it goes live. What you should do is go to Google developer console and request that your application be Verified.
An unverified app is an app or Apps Script that requests a sensitive or restricted OAuth scope, but hasn't gone through the Google verification process. Users of unverified apps or your test builds might get warnings based on the OAuth scopes you're using. This is to protect users and their data from deceptive apps.
Once your application has been verified you will no longer be under the 100 installs limitation. You need to go though the verification process.
Related
I have a web app which sends emails (gmail) in name of my users
When a user registers, she supplies gmail account and password. Also she has to enable access for Less Secure Apps (I recommend to create a new account for this)
Then I can open a gmail session
session = Session.getInstance(props, new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(user.getEmail(), user.getPassword());
}
});
and send emails on her behalf.
Unfortunately this is going to stop working next 30th May, when Google will allow only OAUTH2 access
I have followed Java Quickstart for Gmail API and I have code up and running for sending emails with OAUTH2: enable gmail api, create an application on google cloud platform, grant send permission, oauth2 client id credential created...
The problem I have is I can't see a way to automatize this task because when creating an authorized credential, a consent screen displays on browser and you have to select the account to be granted manually (maybe because my app in google cloud platform is still pending to be reviewed)
Is there a way to infer the gmail account you want to access from the credentials file (client_secret.json)? Is there a way to automatize this?
No, or yes. It depends.
The whole point of OAuth2 is to improve security by working with authorization tokens rather than asking for user credentials. To do this the user has to consent to the app's access request, and thus the OAuth consent screen cannot be bypassed. This is
explained in Google's documentation. It's not related to your app's review status but rather it's the way OAuth works.
You can still work in a similar way, though . Instead of asking for username and password upon the user's registration you can redirect them to the OAuth consent screen so they can authorize your app. Make sure that your app is requesting offline access type and then you can retrieve an access_token and a refresh_token. These will essentially work as your credentials and you can use the refresh token to generate new access tokens when needed without having the user go through the consent screen each time.
The refresh token doesn't have a "natural" expiration so you can keep using it indefinitely, but there are a few scenarios where it will become invalid, such as it not being used for six months, the user changing passwords (if using Gmail scopes), the user manually revoking access, etc. In these cases you will need to direct them to the consent screen again to reauthorize your app.
In this sense, your app can still work automatically without user input except the initial setup, which you already had to deal with when they supplied you with their credentials. The refresh token expiration can even be compared to what you had to do when the users changed their passwords in your current workflow.
One exception to this are service accounts. If you and your users are part of a Google Workspace domain you can delegate domain-wide access to it, then the service account will be able to access user data without any manual input. Of course, this is because as the domain administrator you pretty much own all the accounts under it. But if you're working with a publicly available application you will have to deal with the limitations I mentioned above.
Sources:
Google's auth overview
Using OAuth 2.0 to access Google APIs
OAuth 2.0 for web applications
The OAuth consent screen
I've found plenty of information on implementing Oauth2 using a user authorization step, but I'm trying to run a container that automatically scrapes a gmail inbox for attachments transforms them, and exports to prometheus, and I'm having trouble figuring out how to implement this library: https://pkg.go.dev/golang.org/x/oauth2/clientcredentials#Config or any other for that matter to retrieve a token without involving a manual user step.
Will doing this in Go require writing direct API calls since I can't find an existing library to handle this scenario? Would it make more sense to create a Google App password and use generic user/pass SMTP authentication?
First off i understand what you are trying to do.
You have a backend system running in a container which will access a single gmail account and process the emails.
Now you need to understand the limitations of the API you are working with.
There are two types of authorization used to access private user data
service account - server to server interaction only works with workspace domains. No authorization popup required.
Oauth2 - authorize normal user gmail accounts, requires user interaction to authorize the consent screen
If you do not have a workspace account and this is a normal gmail user then you have no choice you must use Oauth2, which will require that a user authorize the application at least once.
Using Oauth2 you can request offline access and receive a refresh token which you can use to request new access tokens when ever you wish. The catch is that your application will need to be in production and verified, because your refresh token will only work for seven days and then it will expire. To fix this and get a refresh token that does not expire means that your application must in production and verified. This means you need to go though Googles verification process with a restricted gmail scope which requires third party security check and costs between 15k - 75k depending upon your application.
I understand that this is a single user system but that does not mean that you still need to go though verification. When google added the need for application verification they did not take into account single user systems like yours.
Option
Have you considered going directly though the SMPT server instead of using the Gmail api? If you use an apps password you should bypass everything by loging in using the login and the apps password.
I've been using the Google API to update one of my Chrome plugins on a weekly basis. This has now happened 3 or 4 times now: The refresh token I acquire will work properly for up to two weeks (only being used once per week), then the third week, returning an error saying that my token has been expired or revoked.
Given that I'm the only user with access to these tokens, I know that there isn't any spamming, and I know that nobody would be authorized to revoke the tokens on my end.
Please advise. Thanks!
There are serval reasons why an access token can expire.
the user revoked your access.
depending upon which scope you are using if the user changes their password it can revoke all out standing refresh tokens (mostly gmail I think)
If your application is still in testing phase refresh tokens only last for two weeks you will need to move your application to production and go though the verification process. (this appears to have been a stealth change i can find no information on it)
you can have a max of 50 outstanding refresh tokens for a users account, if the user is logging in multiple times and you get a new refresh token each time make sure you are always using the newest.
Your application should always be set to request access of the user again in the event that the refresh token has expired.
I have recently worked with Google Ads API and Shopping Content API and experienced detailed behaviour of API authentication mechanics.
What i can tell for sure regarding authentication is the the following:
An Access-Token always have a life time of 60min. and then expires
An refresh-Token makes it easier to obtain a new Access-Token, since
no additional verification is needed
The lifetime of a Refresh-Token varies
it can be a 6 month or more (when the related application publishing status is released)
or just 1 week (when the related application publishing status is testing)
You can find detailed information regarding Token Expiration on the Google API Documentation https://developers.google.com/identity/protocols/oauth2#expiration
Also information regarding publishing status of your API application Token has expired or revoked - Google Ads
I'm developing an application that utilizes Google sign-in and the Gmail API. My test users, once logged in, keep receiving an email like the attached file.
Other applications with similar functionality (basic email access) do not seem to trigger these emails. Any ideas? It makes my app seem less trustworthy.
One possibility is that you are obtaining tokens with offline=true indicating a requirement to use the refresh token to renew expired access tokens. If you only require short-term access, perhaps you should remove the offline parameter in the construction of your auth request link.
In this scenario once the access token expires, then the scope will no longer be usable or renewable and so your end-users should not receive the alert emails.
Users can go to account.google.com and revoke access from my site. How can I accomplish the same thing?
I have a site that uses Google authentication. The site, however, does not have a sign up process. New users are added by the site administrators. This is accomplished by simply adding their email to a list. This works fine in most cases. If a user comes to the site they are requested to authenticate with Google. I get their email if it is on the list I let them in. If it is not I tell them that they are not authorized to use the site.
If the user has multiple Google accounts logged in to their browser everything works fine. If the user has only one account signed in, and that is an authorized account all is well too. The next time they go to the site they are allowed in without authentication. Which is really cool.
However, if the one account they have signed in with on their browser is not authorized they are immideatly taken to the "You are not authorized" page. They are not given the opportunity to sign in with some other account.
If I could revoke the permission they granted to the site in Google (for unauthorized users), the next time they come to the site it would ask them to sign in again and give them the option of signing in with another account. Authorized accounts are typically work accounts. I am afraid that because the sign in process is so quick and easy, if someone accidentally signs in with their personal account on their phone they won't get a second chance to correct the error.
This is done by Revoking the token. Thanks #DalmTo
In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings. It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes or removes an application. In other words, part of the removal process can include an API request to ensure the permissions granted to the application are removed.