As above, is token still assigned to user when server is shutting down?
Use case: user get token with 10 minutes expiration time, 30 seconds after user get authorized, server shutdowns. After 30 second server wakes up. Does user still authenticated with previously granted token ?
That completely depends on the Authorization Server's implementation of the requested token. If the token is a self-contained token like a JWT, it would still validate. If the token is a "by-reference-style" token then it may still validate if the Authorization Server uses persistent storage for its tokens, otherwise it would no longer validate.
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.
In my web application I am using access and refresh tokens to authorize user access to protected resources, the flow is as following:
The user, through a mobile app, sends a request to the "auth/token" endpoint providing his credentials. The server authenticates the user and issue an access and refresh token. The refresh token is saved in a whitelist to be able to revoke it later on, if necessary.
Upon access token expiration, the mobile app sends the refresh token to the "/token/refresh" endpoint presenting the refresh token. A new access/refresh token pair is created and the old refresh token is invalidated ,implementing in this way the token rotation.
Now the problem:
Let's say that the client refresh the token but never receive a response back from the server because the network is lost. After 30 mins the client tries to refresh again but its token is now invalid and the user is logged out. In the Oauth implementations we can set a time for the old token after which this will be invalidated, giving the possibility to the mobile app to resend the same refresh token if any problem occurs. But I do not think this is a solution because we can't be sure of when the mobile client will retry to refresh the token. It can be in some minutes, hours or worse also days.
How do you approach this problem?
The first solution I could think of is increasing expiration time.
I'm creating an app that integrates with several 3rd-party Oauth2 providers (think Zapier). The user adds a connection through Oauth2 which gives me a refresh token and access token and which I'm storing in a database.
What is the best practice to keep the access token fresh? Should I be running an async job (e.g. cron) that refreshes the access token every 30 minutes for every connection? If the user doesn't use my app for several days I'd like to still be able to access his 3rd-party data without having him to go through the Oauth2 consent.
What is the best practice to keep the access token fresh? Should I be running an async job (e.g. cron) that refreshes the access token every 30 minutes for every connection?
Not necessarily. Wait till your API call fails. Check for a proper response such as "401 Unauthorized" which hints your access token is invalidated/expired. Once this happens use refresh token to renew the access token. If refresh token fails, then you have to fall back again and ask user to login again.
A refresh token can have a varying life time. It can be from few days to few months. For example check Google's explanation mentioning long lived refresh tokens and possible expiry of them. Also check how Azure AD mention about configurations related to token lifetimes.
So user not using app for few days (ex:- leave it and return after weekend) can be handled through proper validity configurations of tokens lifetimes. But be mindful about threats that could occur from long-lived, unmanaged tokens (ex:- due to token stealing).
The Oauth website has a pretty informative answer
The “expires_in” value is the number of seconds that the access token
will be valid. It’s up to the service you’re using to decide how long
access tokens will be valid, and may depend on the application or the
organization’s own policies. You could use this timestamp to
preemptively refresh your access tokens instead of waiting for a
request with an expired token to fail. Some people like to get a new
access token shortly before the current one will expire in order to
save an HTTP request of an API call failing. While that is a perfectly
fine optimization, it doesn’t stop you from still needing to handle
the case where an API call fails if an access token expires before the
expected time. Access tokens can expire for many reasons, such as the
user revoking an app, or if the authorization server expires all
tokens when a user changes their password.
If you make an API request and the token has expired already, you’ll
get back a response indicating as such. You can check for this
specific error message, and then refresh the token and try the request
again.
TLDR: I would only refresh the token when a request fails
I would like to request Uber cabs on behalf of an Uber user, but first the user needs to permit the app to have access to his profile and permit the app to send requests on his behalf. However, the returned authorization code that I can use to get the access token in order to send user requests on their behalf is only valid for 10 minutes and my requirement needs me to send requests even 24 hours later.
Is there a way to get a permanent authorization code or access token that never expires or at least one that lasts for a long period, e.g. a month?
RFC 6749 says as follows in 4.1.2. Authorization Response:
code
REQUIRED. The authorization code generated by the authorization server. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code
Therefore, it is hopeless to expect an authorization code with longer lifetime than 10 minutes. So, you should exchange an authorization code for an access token at the token endpoint immediately using the way described in 4.1.3. Access Token Request.
If Uber's authorization server issues a refresh token when it issues an access token, you can expect it has longer lifetime than an access token. You can use a refresh token at the token endpoint in order to get a new access token. See 6. Refreshing an Access Token for details.
If lifetime of access tokens and refresh tokens issued by Uber is less than 24 hours, you have to change the flow of your application.
I'm working with an API that uses OAuth2, provides an access token that expires in 3600 seconds, and provides a refresh token with it. Originally, I'd waited for an API call to fail in a way that indicated the access token was expired and then tried to refresh the access token using the refresh token. This has become problematic when the access token is expired and several API calls are made concurrently (each call separately triggers a refresh and most of the calls fail).
Would it be better to automatically refresh the access token using the refresh token after 3600 seconds? (Or 3599 seconds or 3601 seconds?) Is there a different paradigm I should be using for refreshing the access token?
Ideally, the client should have sufficient smarts to not use an expired access token. Fortunately the response from your OAuth AS's token endpoint should include the expires_in attribute to confirm that the expiry will be in 3600 seconds. E.g.:
{"token_type":"Bearer","expires_in":3600,"refresh_token":"p8BPdo01kkjh6fhatclD3wwBEQblm4kL4ctYRVlrHo","access_token":"9XebAAXeu6hQOAiwmOk8vdhRyUFV"}
Since this JSON response is generated by the server, there's a chance that the transmission back to the client has taken time, and thus the "expires_in" value may be smaller than it appears.
Given that, I'd recommend that you have some sort of buffer (say 5-10 seconds) before expiry to automatically use your refresh token to request a new access token.
I may have used the following scenario. There will be access failures due to access token validation error but those errors will be minimal.
App1 invokes the token api with password grant type and get the access token and refresh token pair (accto1/refto1)
App2 also do the same at the starting up of the execution (accto1/refto1)
When the access token is expired for App1, he may do the refresh token by invoking the token api with refresh token grant type and with his existing refresh token (refto1) and he will retrieve a new pair of access token and refresh token. (accto2/refto2)
When App2 also reaches the instance when his access token is expired, he will also try the refresh token grant with the refresh token he already has (refto1) but he will get an authorization error since that refresh token is now expired.
When either of the apps get this error then app needs to realize that someone else has refreshed the token so at this moment the app needs to make a call with the password grant to retrieve the new access token / refresh token pair in action. This time as in the example the App2 will also retrieve the same access token and refresh token pair that the App1 has previously received for his refresh token grant. (accto2/refto2)