When I'm trying to activate a service account using the gcloud CLI command.
gcloud auth activate-service-account --key-file key.json
I am getting the below error since yesterday. I was able to create a service account with the same command 2 months ago and the service account was created at that time.
ERROR: (gcloud.auth.activate-service-account) There was a problem refreshing your current auth tokens: ('invalid_grant: Invalid JWT Signature.', {'error': 'invalid_grant', 'error_description': 'Invalid JWT Signature.'})
What is the issue here?
I've come across this answer which might be helpful on your case. 2 common causes were:
Your server’s clock is not in sync with NTP.
Solution: Check the server time. If it's incorrect, fix it.
The refresh token limit has been exceeded.
Solution: Nothing you can do - they can't have more refresh tokens in use.
Applications can request multiple refresh tokens. For example, this is useful in situations where a user wants to install an application on multiple machines. In this case, two refresh tokens are required, one for each installation. When the number of refresh tokens exceeds the limit, older tokens become invalid. If the application attempts to use an invalidated refresh token, an invalid_grant error response is returned.
The limit for each unique pair of OAuth 2.0 client and is 50 refresh tokens (note that this limit is subject to change). If the application continues to request refresh tokens for the same Client/Account pair, once the 26th token is issued, the 1st refresh token that was previously issued will become invalid. The 27th requested refresh token would invalidate the 2nd previously issued token and so on.
Just to add, please verify the validity of the service account key and try to setup the environment variable again.
Related
After googling we came to know that invalid_grant which means refresh token is invalid.
Link to google oauth doc
We don't have any of these issues mentioned by google. Is this error related to something else rather than a refresh token.
More Info
We have access to read, write spreadsheet and send gmail
We fetch an access token for each request
Any help would be appreciated.
We're already in production and verified by google
Without seeing the full error message that being
Invalid_grant {Message here}
It is hard to help but from my experience is most often caused by one of the following.
Refresh token expire, app not in production.
There are serval reasons why a refresh token can expire the most common one currently is as follows.
A Google Cloud Platform project with an OAuth consent screen configured for an
external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.
The fix is to go to google developer console on the consent screen and set your application to production, then your refresh token will stop expiring.
invalid_grant: Invalid JWT
{ “error”: “invalid_grant”, “error_description”: “Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values and use a clock with skew to account for clock differences between systems.” }
Your server’s clock is not in sync with NTP. (Solution: check the server time if its incorrect fix it. )
invalid_grant: Code was already redeemed
Means that you are taking an authentication code that has already been used and trying to get another access token / refresh token for it. Authentication code can only be used once and they do expire so they need to be used quickly.
Invalid_grant: bad request
Normally means that the client id and secrete you are using to refresh the access token. Was not the one that was use to create the refresh token you are using.
Always store most recent refresh token.
Remember to always store the most recent refresh token. You can only have 50 out standing refresh tokens for a single user and the oldest one will expire. Depending upon the language you are using a new refresh token may be returned to you upon a refresh of the access token. Also if you request consent of the user more then once you will get a different refresh token.
User revoked access
If the user revoked your access in their google account, your refresh token will no longer work.
user changed password with gmail scope.
If your refresh token was created with a gmail scope and the user changed their password. your refresh token will be expired.
Links
Oauth2 Rfc docs for invalid_grant error rfc6749
invalid_grant
The provided authorization grant (e.g., authorization
code, resource owner credentials) or refresh token is
invalid, expired, revoked, does not match the redirection
URI used in the authorization request, or was issued to
another client.
I'm experiencing a situation where:
I have a Google project, using an OAuth 2.0 Client (for web applications), to get consent for some scopes from users. The authorization parameters used in the redirect to Google uses the following values for the parameters (only including the possibly relevant params):
access_type - offline
response_type - code
include_granted_scopes - true
If a user consents access to the app, the app gets an access token to access the scopes granted.
If the same user consents again (while the previous access token hasn't been revoked yet) to the same app (using the same OAuth 2.0 Client), a new access token gets issued to the project.
The Google project has 2 different tokens now, and both access tokens work for accessing the scopes granted. Oddly though, the user would see only a single entry for the Google project/app in the users Apps with access to your account page.
The issue is that if any of the token gets revoked, all of the active tokens get revoked (attempts to use the access token results in an invalid_grant error, with the Token has been expired or revoked. error description). While I haven't tested beyond having 2 live/valid tokens at the same time, I suspect the behavior would be the same for more than 2.
I've been looking through the Google OAuth 2.0 docs to find some documentation regarding this behavior, or find anything referencing what happens to companion tokens when one gets revoked, but was unable to find anything explaining this behavior.
I, at first, thought that it was maybe due to my usage of incremental authorization, and thought that maybe revoking the latest access token revokes all preceding ones, but after experimenting with include_granted_scopes=false, the behavior was still the same.
For now, I've restricted users to be able to consent only once (unless a token expires), but I'm curious about the explanation for this behavior - where revoking 1 token revokes all of them.
Actually access tokens are independent. An access token by design will work for one hour. In theory even if the user revokes your access the access token will still work for the remainder of the hour it was originally valid for. This is standard Oauth2 functionality they are intended to give access for an hour that is why it is called a bearer token the bearer of that token is granted access for an hour.
What i suspect that you are seeing is the refresh token being revoked as this will cause a invalid_grant error. If you request access of the user using offline access you are granted a refresh token. If you request consent of the user again you get another refresh token. There can be up to fifty outstanding refresh tokens for a single user.
If the user revokes the access via their google account, or if your application revokes the access. Then yes all of the outstanding refresh tokens will be revoked. As your applications access to the users account has been revoked not the single refresh token. Note there are actually serval reasons why a refresh token can expire they can be found here refresh token experation
This is standard Oauth2 behavior not google specific.
Remove third-party account access
If you gave Google Account access to a third-party app or service you no longer trust or want to use, you can remove its access to your Google Account. The app or service won’t be able to access any more info from your Google Account, but you may need to request that they delete the data they already have.
I'm using React Native and Expo. Also using aws-amplify to manage users with Cognito's user pool.
Every so often my users are getting kicked out of the system because of "Refresh Token has expired" error. Those users were in the system in the previous week so their refresh token should still be valid. Any ideas?
I'm using:
aws-amplify 2.2.0
aws-amplify-react-native 2.2.3
react-native 0.59
expo 35
I think this is a misunderstanding of the docs. I was under the impression that the refresh token is being re-issued on every session, thus users should never get to the expiration time while they are active.
Apparently this is not the case, as users are issued a refresh token upon login only and that token is being persistent on the client side storage. No matter if they are active or not, this token is expired after 30 days (or else configured) and then need to re-login again.
(of course I'm aware that this is not an Amplify implementation)
We are integrating on our application the Office 365 functionality throught MSGraph rest api and we are currently getting trouble with the validation of Refresh Tokens, this is the response error code from the server on a invalid petition:
"error":"invalid_grant","error_description":"AADSTS70002: Error
validating credentials. AADSTS70008: The refresh token has expired
due to inactivity.??The token was issued on
2016-04-27T11:44:49.4826901Z and was inactive for 14.00:00:00.
This is annoying because we need the users to aquire their credentials again logging in on Microsoft servers.
Is there any option to avoid Refresh token being invalidated due to inactivity? Or to make longer this expiration?
Refresh tokens have a finite lifetime. If a new token (and refresh token) isn't requested before that time they will expire. Once this happens the user must re-authenticate.
If you need to have perpetual access to the account, you will need to manually refresh the token periodically. You may want to look at this article. It covers the basics of how v2 Endpoint works (and the various token lifetimes).
In most of my implementations I use a queue to handling refreshing tokens. I queue each token to be refreshed at 10 days. If it fails I resubmit to the queue. If it is still failing at day 12 I email the user to inform them there was an issue and they will need to re-authenticate.
UPDATE
Refresh token lifetime was recently changed to until-revoked. You can read about the change here
This is general OAuth (not AAD-specific): obtaining an access token is a 2-step process. The first step is to obtain an auth code which requires the user to authenticate. The second step is to redeem an access token and a refresh token from the auth code. This second step is purely programmatic, i.e. the user need not be present. The app can keep repeating the second step, i.e. redeeming a new access token and a new refresh token from the latest refresh token without the user even know about it.
Your app should schedule frequent 'refreshes' of the refresh token. You can do this at any time while the app is running.
If the user doesn't use the app for an extended period of time, like about 2 weeks (I believe), the refresh token would naturally expire. If you want to avoid that, you'll have to schedule a dedicated job to refresh the token.
Zlatko
Is there any way to use the graph api to find out when a page access token, or application token will expire?
Update: There is a new API endpoint to access information about an access token. You can find info here: Debugging Access Tokens and Handling Errors
https://graph.facebook.com/debug_token?input_token=INPUT_TOKEN&access_token=ACCESS_TOKEN
input_token: the Access Token to debug
access_token: your App Access Token or a valid User Access Token from a developer of the app.
--
You should try to make sure that you store each token's expiration time along with the access token when you get it. For a page access token, that means storing the expiration time of the user access token. If you would like to manually discover expiration times for tokens you have today, you should use Facebook's Access Token Debugger tool. However, you should not be relying on expiration times alone -- in practice, many tokens will expire much earlier than their expiration time.
Application access tokens will never expire, unless the application secret key is reset.
Page access tokens last up to 60 days (5184000 seconds), but more importantly, they last as long as the user access token that was used to acquire them. So they will be invalidated as soon as the user that you got them from:
logs out of FB.
changes password.
deauthorizes your application.
Basically, when you lose the user's token, you will lose the page's token. Instead, you should retrieve page access tokens once per user access token. If you throw out a user access token, throw out the page token. You should not be trying to store page access tokens for any significant period of time. Instead you should get them as needed and forget them when a user's session dies.
To get a new page access token:
https://graph.facebook.com/PAGEID?fields=access_token&access_token=USER_ACCESS_TOKEN
Access Token Debugger
https://developers.facebook.com/tools/debug/access_token
Does not use the Graph API... but a very useful tool for manual debugging.
There is now an API version of the debugger tool.
See https://developers.facebook.com/docs/authentication/access-token-debug/
I would like to repeat this question for the current version of the API since I've come to a situation when Facebook doc clearly does not describe what is happening:
no expiry dates when requesting a new long-lived token with fb_exchange_token
no expiry dates when requesting debug_token information (expires_at = 0)
it does reply with an expiration date when redirecting the user to the auth page for the first time, but that does not help as I cannot extract the long-lived expiration date nor it will reply with this information for the second time
The debug tool here: https://developers.facebook.com/tools/debug/accesstoken says "Expires: Never".
Try this, it worked with me. Get the token with your app and paste it in the graph explorer as the token to be used for queries. Click on the info a see the expiration date.
example image
I hope it works for you too.
https://developers.facebook.com/docs/facebook-login/access-tokens/expiration-and-extension
From the page above:
Access tokens on the web often have a lifetime of about two hours, but
will automatically be refreshed when required. If you want to use
access tokens for longer-lived web apps, especially server side, you
need to generate a long-lived token. A long-lived token generally
lasts about 60 days.