I have an issue with Google plus access token. It is giving me "Invalid Credentials" error message sometimes, sometimes the same token show as active.
Following are the steps
The user confirms permission to access Google account with selected scopes.
The refresh token and access token is retrieved and saved to long time storage.
Used to refresh the token when ever needed by using stored refresh token
But sometimes I've experienced strange behaviour:
Requests to Google APIs return Invalid Credentials (401) error. Refreshing the access token (using the stored refresh token) does not work.
Access token refresh method
Using googleapis npm module to refresh token
https://www.npmjs.com/package/googleapis
oauth2Client.refreshAccessToken(function (err, tokens) {
if (err) {
console.log('error', err);
}
console.log('access tokens', tokens.access_token); // Access token
console.log('refresh tokens', tokens.refresh_token); // Refresh token
});
Questions:
What can be the reason for this behaviour?
Does this behaviour related to with any google api rate limit? because the same token works sometimes and not other-times.
Is there a way to validate the refresh token?
Every time you refresh your access token using refresh token, you will given by new access token.The refresh token has no expiry. You can use the refresh token as many as possible for refreshing the access token
Related
I have an app that uses the Google Calendar API and I seem to have a corrupt/defunct access token and/or refresh token which is resulting in the following error:
Signet::AuthorizationError
Authorization failed. Server message: { "error": "invalid_grant", "error_description": "Bad Request" }
Code for the authorization:
client_id = Google::Auth::ClientId.new(CLIENT_ID, CLIENT_SECRET)
token_store = EncryptingTokenStore.new(TokenStore.new)
scope = "https://www.googleapis.com/auth/calendar"
authorizer = Google::Auth::UserAuthorizer.new(client_id, scope, token_store, callback_url)
authorizer.get_credentials(CALENDAR_ID)
On investigation the UserRefreshCredentials we get back from authorizer object has an expires_at date in the past (11/01/2021).
I deleted the offending refresh token that we have stored, revoked access via the google account settings, then reauthenticated the user account with the app to reapprove offline access to Google Calendar again. This did not give me a new access and refresh token as expected. The expires_at is still 11/01/2021. We have valid refresh tokens in storage but for some reason Google is still picking up the old details despite that refresh token no longer existing. So I need to find a way to refresh or overwrite the UserRefreshCredentials that the Google API is using.
Other steps I have tried:
I tried to refresh the token from within a production console with some methods that come with the ruby google client gem but this fails with the same invalid_grant/Bad request error that is at the root of this issue.
I also tried to refresh the token with a POST request to the oauth2 endpoint:
https://oauth2.googleapis.com/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN&grant_type=refresh_token
but this also fails with the same invalid_grant/Bad request error.
If anyone can shed any light that would be much appreciated.
There is API on Laravel, which uses Laravel Passport for authentication. All worked well with the default settings. Then we decided to change the lifetime of the access token to 1 day and 1 month accordingly. It caused a problem with the refresh token.
Example: Access token is expired and the app sends the refresh token request to API. Then the app loses internet connection and can't get a new token. (Server sends new tokens but the app is unavailable). After the internet connection returned, the app sends a new refresh request but get 401. So apps need to get new code from API to authenticate the user. I don't think it's a good idea to force the user to login every day.
Any suggestions? Maybe there is some way like "handshake" to solve that problem? I mean refresh token only after confirmation the app got new tokens.
If I correctly understand your question, you're saying that you initially have an Access Token1, Refresh Token1 pair, and when the Access Token1 expired you try to request a new Access Token using the Refresh Token1.
Now, for some reason, you fail to receive this new Access Token2, Refresh Token2 pair, so what does the user do?. Well, you see this from the Consumer's point of view. If you see the same scenario from the Oauth2 Server's point of view.
The Server does not know if you failed to receive the token or you received it and failed to save. The server's job was to generate a new access token based on your valid refresh token. And as soon as it creates a new access token, it invalidates the old refresh token. This is the standard Oauth2 implementation.
You may try to make it so that the Old refresh token is not immediately revoked on new access token generation. But this introduces a possibility of replay attacks.
Hence, The standard practice is to have the User log-in again.
I have a Google OAuth2 client approved by Google, which provides offline access to user's account with required scopes. My backend application stores and uses the refresh token to refresh the access tokens as and when needed.
Lately, we are seeing that our token refresh attempt is met with an error from Google with:
{
"error" : "invalid_grant",
"error_description" : "Token has been expired or revoked."
}
There is no additional information.
Nothing has changed in my Google OAuth client. The user has not changed account password. The user has not revoked access to my client.
What could be the reason for suddenly getting such errors for token refresh? And how do I avoid this in future (if possible)?
Are you inadvertently asking for the refresh token multiple times? There is a limit of approx. 25 refresh tokens that an account can have extant.
I had same issue, because I run my code in 2 different files and what I did remove token.pickle file, re-run it again.
I'm using the VSTS REST API. I use the refresh token, as instructed, to refresh the access token. This morning, the refresh tokens stopped working. Do they expire? If the access token and refresh token have both expired, how do I proceed? I can't find anything on this.
For reference: https://www.visualstudio.com/en-us/docs/integrate/get-started/auth/oauth#refresh-an-expired-access-token
Yes, the refresh token will be expired, you need to send request to re-authorize to get access token and refresh token again (your previous steps to authorize).
The previous access token and refresh token have been expired after get new access token.
I manage the team that implements this flow. The answer from #starain is correct and this flow is described in detail in the OAuth 2 specification. Your observation that the refresh token is invalidated so frequently #scottndecker is not consistent with the implementation. A refresh token in our system has a default lifetime of one year. The token can also be invalidated manually by users. We obviously must honor the user's right to revoke a previously granted authorization. If you want to share some more information we can certainly look into this behavior.
Seems that when the auth.token expires (after one hour), the auth.refreshtoken become invalid too? What is the auth.refreshtoken purpose then? When I decode the auth.refreshtoken on jwt.io, it should expire sometime in 2020. (Now it's 2019).
While the auth.token is valid, I can refresh and get a new token. So is the idea that I should setup a job that refreshes the token within one hour?
The documentation claims:
If a user's access token expires, you can use the refresh token acquired in the authorization flow to get a new access token. This process is similar to the original process for exchanging the authorization code for an access token and refresh token.
I'm using Boxr gem
boxr for my autotests I need to do some manipulation with files and I have created developer token and did some things, after some time developer token was expired.
BUT on documentation I saw that I can do refresh token before runing tests.
If you want Boxr to automatically refresh the tokens once the access token becomes invalid you can supply a refresh token, along with your client_id and client_secret, and a block that will get invoked when the refresh occurs.
token_refresh_callback = lambda {|access, refresh, identifier| some_method_that_saves_them(access, refresh)}
client = Boxr::Client.new('zX3UjFwNerOy5PSWc2WI8aJgMHtAjs8T',
refresh_token: 'dvfzfCQoIcRi7r4Yeuar7mZnaghGWexXlX89sBaRy1hS9e5wFroVVOEM6bs0DwPQ',
client_id: 'kplh54vfeagt6jmi4kddg4xdswwvrw8y',
client_secret: 'sOsm9ZZ8L8svwrn9FsdulLQVwDizKueU',
&token_refresh_callback)
The question is: What the method should be for save refresh token? "some_method_that_saves_them"