i'm writing an application which uploads files to the Box-API, for some clients but i'm having a problem i don't understand (I've laready opened a ticket for that but maybe you'll have some answers): The refresh token is expiring in almost one hour and sometimes less time.
I've no idea why this is happening and i though the refresh token was lasting one month, but i've installe the application on my client machine, the client authorized it in his box account, but after only half an hour he was propt to authorize it again cause the refresh token was "invalid".
What should i think?
I'm updating the refresh token everytime i get a new access token, so there shouldn't be problem with that. SHould i do otherwise? ANy idea?
There are two tokens:
the authentication token, which signs the HTTP request, is valid for 1 hour.
the refresh token, which is used to get a new authentication token, is valid for 60 days or until it is used.
Related
I have integrated a Git-Lab OAuth app in my web-app. Users authenticate this OAuth app and give access to their Git-Lab repositories through the Access Token. Once a user connects his repositories with my web-app , my web app saves the refresh token and access token in the DB and a cron job runs every 2 hours to refresh the tokens so that It never loses the connection to the connected repositories. (GitLab access token expires after 2 hours).
Here is the Git-Lab API URL which my cron job hits to refresh the tokens.
https://gitlab.com/oauth/token?client_id={}&client_secret={}&refresh_token={}&grant_type=refresh_token&redirect_uri={}
Now this cron job to refresh the tokens was running perfectly since more than a week, and suddenly it failed to refresh the tokens and hence I have lost the connection to user repositories. The error message received from GitLab API is as follows
The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.
This job was running fine since a week, so all provided parameters to the Git-Lab API URL seems fine to me. e.g. client_id, client_secret, refresh_token ,redirect_uri etc.
What can be the possible reason of these token expiration. I have lost the connection to user repositories and the only choice I am left with is to go back to user and ask them to reconnect their repositories by re authenticating the OAuth App.
Can it be the reason that my cron job was running too often (12 times a day ) and refreshing the tokens at a high frequency Or may be if the Access token was still valid and a try to refresh that token caused this issue. ?
No, I can hit the API to refresh token as many times as I want, I could hit it 100 times in few seconds and got my tokens refreshed 100 times.
I also used the access to token to pull a repository , then updated the tokens and again used the previous access token (expired) to pull the repository, this time it failed to pull the repository for obvious reason (token has expired) , and then I updated my tokens again. I can successfully update my tokens all the time.
That means using an expired token to pull the repository is not the reason for tokens expiration
I need to know the real cause which has expired my tokens.
I need to emphasize on that my Refresh Token has expired and I can no longer refresh my tokens.
I have read through the GitLab API docs and haven't found any clue of the reason why my token got expired.
It seems like you tried to use a token that has been refreshed. That is, between the time you pulled the token value and used it, the refresh occurred, which immediately invalidated the token you were trying to use.
my web app saves the refresh token and access token in the DB and a cron job runs every 2 hours
Don't do this. In general, you should not be periodically refreshing these tokens because you will invalidate the active token, nor is there any real reason you should need to do so.
Just refresh the token at the moment when you actually need to use them if the token is expired. Even though the access token may expire, the refresh token can still be used after the access token itself expires -- that's what the refresh token is for, after all.
Please check that your service waits enough time for a response from GitLab(may be reasonable to increase timeout) and doesn't have retry logic - the refresh token could be used only once.
Depending on the resource owner (Gitlab, etc.), there are various reasons why a refresh_token could have become invalidated.
A few to note:
Your integration was reauthorized, invalidating any existing access_tokens and refresh_tokens
If a new access_token is generated, both the previous access_token and refresh_token will become invalid.
If the integration was deauthorized by an end user or token revoked programmatically (not sure if Gitlab offers this)
You might also find some of the tips in this OAuth Troubleshooting Guide helpful.
My application uses a Google refresh token (to get access_token from Google). I have two questions here:
I know Google refresh token does not expire for 6 months (see the doc here); say I got a refresh token refresh_token_old at 5:00pm on Jan 1st , and my application requests another refresh token refresh_token_new from Google at 5:30pm on Jan 1st (i.e., just 30 minute later), will the old refresh token still be valid (apparently the old one has not been expired)? -- basically, I am asking if the newly issued refresh_token purges the validity of the old refresh_token;
For the access token, access_token_a, which I got from Google using refresh_token_old, is it still valid after my app requested the new fresh token refresh_token_new? -- basically, I am asking if the new refresh_token purges the validity of the access_token obtained by an old refresh_token even if that access_token has not expired;
A refresh token will expire if it has not been used for six months. A soon as it is used the six month timer will reset.
If you request a refresh token, your application then requests another refresh token you technically have two outstanding refresh tokens, both will work. You can keep doing this and have up to fifty out standing refresh tokens as soon as you hit that point the first one will expire.
any access token created with any refresh token is good for an hour. Even if the refresh token that created it has expired during that hour. Once an access tokens is created it will work for an hour not matter what.
We have Google OAuth2 Web client at Google API Console
With the help of Oauth Web Client, we get Refresh token for each Users ( By using web Authentication & Concert Screen )
We store received Refresh Token to database and, System user this user specific Refresh token to create Google Calendar Event automatically on behalf of logged in user ( We have around 1000 Users)
Problem : Since couple of days Refresh Token has been expired automatically and getting following error.
{
"error": "invalid_grant",
"error_description": "Token has been expired or revoked."
}
When user do re-registration System receive new Refresh token and everything again start working, however after some time ( no sure but in less then day or two ) again they start getting Token has been expired or revoked error.
Is there any Limit has been expose on Refresh Token ?
Is there any Limit to get Refresh Token by using Same API Client? ( We have individual 1000 Gsuit or Gmail user who have registered for Refresh Token individually using by using their person Gmail or Gsuit Account)
Is there any API change to get long live Refresh token ?
Regards,
DP
Your Questions
Is there any Limit has been expose on Refresh Token ?
You can authorize a user and get a refresh token, then authorize the same user again and get a second refresh token. The user now has two outstanding refresh tokens and both work. You can do this up to fifty times and have fifty outstanding refresh tokens for this user. Once you do it again the first one will expire.
You can have fifty out standing refresh tokens for a user so if you are re authorizing them make sure that you are replacing the one stored in your database with the newest refresh token.
Is there any Limit to get Refresh Token by using Same API Client? ( We have individual 1000 Gsuit or Gmail user who have registered for Refresh Token individually using by using their person Gmail or Gsuit Account)
Your client can authorize as many users as you like. There is no limit to the number of users you system can have.
Is there any API change to get long live Refresh token ?
Not that i am aware of
The error message
There are a couple of things that could be happening here.
The first being that the user has the power to revoike your access though the their google account. It looks to me like this may be what is happening.
The second issue is the fact that its October and Google daylight savings time is kicking in. Several years ago there was an issue with daylight savings time expiring tokens.
Third issue is that if your refresh token has not been used in the last six months it will be expired by google.
The fact of the matter is that refresh tokens are not perfect due to the above reasons. Your system should be designed to handle this if the refresh token fails then simply set it up to ask the user for access again.
{ "error": "invalid_grant", "error_description": "Token has been expired or revoked." }
I have two accounts for docusign, live and demo. The demo one hasn't been used in a while, in fact the last time a refresh token was created was the 14th November. I'm therefore assuming it has expired and is potentially stopping me from getting a new one.
When I make a request I get the invalid_grant error. The same code (with testing credentials) works fine with my live account which requests a live token every couple of days or so. It also did work fine on with the testing credentials until it wasn't used for a prolonged period.
I assumed I need to get hold of a new refresh token but without a valid previous token I'm not sure how to go about this.
The following applies to DocuSign's OAuth2 authentication service:
When you use the refresh token to get a new access token, you also get a new refresh token. But see the following:
If your original OAuth request only included the signature scope then the expiration date of the new refresh token will be the same as the original refresh token (30 days).
However, if you request both the signature and extended scopes, then your new refresh token will expire 30 days from the time that you refreshed it.
So the way you can continue to get a new access token without requiring the user to authenticate again is:
User authenticates with the signature and extended scopes. Your app exchanges the auth code for an access token (good for 8 hours) and a refresh token (good for 30 days).
Within the 30 day period, refresh the access token. This also gives you a new refresh token, good for a new 30 day period.
Rinse and repeat. As long as you get a new refresh token at least every 30 days, you can keep going forever.
Caveat: For InfoSec reasons, the end user, their admin, and/or DocuSign might invalidate all existing refresh tokens. This is an unusual corner case but can happen. Easiest way to test the corner case: remove the user's consent for the app.
You cannot refresh a Refresh Token if the Refresh Token has expired or otherwise been revoked. You must repeat the authentication flow to obtain a new Refresh Token.
I'm using an API that by default has it's access tokens expire 30 days after generating/refreshing. Is there a reason I shouldn't simply have a cron job that refreshes the token every week? I would rather set-and-forget rather than dynamically watch the expiration.
Ideally the token lifespan should be short. Coming back to the question you asked, there are ways you can refresh the token.
We can let the token expire after 30 days and when the next call
you make after token expiration you will get 401 Unauthorized. Once
you get that you will know that the token is expired and you can
refresh the token. Depending upon from where you are refreshing the
token matters, I mean server side or client side.
We do have the token hence the expiration time as well.By watching the expiration time and refresh the token just before it expires. But for that you
should be able to get the token and read all the properties
associated with that.
I recommend 1st option as you do not need to worry about reading the token for each and every client.Also if the token is expiring every 30 days, there is no need to refresh every week as that's unnecessary calls to the server asking for refreshed token even though it's valid.