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 am using Spring Security OAuth2 and JWT tokens. My question is: How can I revoke a JWT token?
As mentioned here
http://projects.spring.io/spring-security-oauth/docs/oauth2.html, revocation is done by refresh token. But it does not seem to work.
In general the easiest answer would be to say that you cannot revoke a JWT token, but that's simply not true. The honest answer is that the cost of supporting JWT revocation is sufficiently big for not being worth most of the times or plainly reconsider an alternative to JWT.
Having said that, in some scenarios you might need both JWT and immediate token revocation so lets go through what it would take, but first we'll cover some concepts.
JWT (Learn JSON Web Tokens) just specifies a token format, this revocation problem would also apply to any format used in what's usually known as a self-contained or by-value token. I like the latter terminology, because it makes a good contrast with by-reference tokens.
by-value token - associated information, including token lifetime, is contained in the token itself and the information can be verified as originating from a trusted source (digital signatures to the rescue)
by-reference token - associated information is kept on server-side storage that is then obtained using the token value as the key; being server-side storage the associated information is implicitly trusted
Before the JWT Big Bang we already dealt with tokens in our authentication systems; it was common for an application to create a session identifier upon user login that would then be used so that the user did not had to repeat the login process each time. These session identifiers were used as key indexes for server-side storage and if this sounds similar to something you recently read, you're right, this indeed classifies as a by-reference token.
Using the same analogy, understanding revocation for by-reference tokens is trivial; we just delete the server-side storage mapped to that key and the next time the key is provided it will be invalid.
For by-value tokens we just need to implement the opposite. When you request the revocation of the token you store something that allows you to uniquely identify that token so that next time you receive it you can additionally check if it was revoked. If you're already thinking that something like this will not scale, have in mind that you only need to store the data until the time the token would expire and in most cases you could probably just store an hash of the token so it would always be something of a known size.
As a last note and to center this on OAuth 2.0, the revocation of by-value access tokens is currently not standardized. Nonetheless, the OAuth 2.0 Token revocation specifically states that it can still be achieved as long as both the authorization server and resource server agree to a custom way of handling this:
In the former case (self-contained tokens), some (currently non-standardized) backend interaction between the authorization server and the resource server may be used when immediate access token revocation is desired.
If you control both the authorization server and resource server this is very easy to achieve. On the other hand if you delegate the authorization server role to a cloud provider like Auth0 or a third-party component like Spring OAuth 2.0 you most likely need to approach things differently as you'll probably only get what's already standardized.
An interesting reference
This article explain a another way to do that: Blacklist JWT
It contains some interesting pratices and pattern followed by RFC7523
The JWT cann't be revoked.
But here is the a alternative solution called as JWT old for new exchange schema.
Because we can’t invalidate the issued token before expire time, we always use short-time token, such as 30 minute.
When the token expired, we use the old token exchange a new token. The critical point is one old token can exchange one new token only.
In center auth server, we maintain a table like this:
table auth_tokens(
user_id,
jwt_hash,
expire
)
user_id contained in JWT string.
jwt_hash is a hash value of whole JWT string,Such as SHA256.
expire field is optional.
The following is work flow:
User request the login API with username and password, the auth server issue one token, and register the token ( add one row in the table. )
When the token expired, user request the exchange API with the old token. Firstly the auth server validate the old token as normal except expire checking, then create the token hash value, then lookup above table by user id:
If found record and user_id and jwt_hash is match, then issue new token and update the table.
If found record, but user_id and jwt_hash is not match , it means someone has use the token exchanged new token before. The token be hacked, delete records by user_id and response with alert information.
if not found record, user need login again or only input password.
when use changed the password or login out, delete record by user id.
To use token continuously ,both legal user and hacker need exchange new token continuously, but only one can succeed, when one fails, both need to login again at next exchange time.
So if hacker got the token, it can be used for a short time, but can't exchange for a new one if a legal user exchanged new one next time, because the token validity period is short. It is more secure this way.
If there is no hacker, normal user also need exchange new token periodically ,such as every 30 minutes, this is just like login automatically. The extra load is not high and we can adjust expire time for our application.
source: http://www.jianshu.com/p/b11accc40ba7
This doesn't exactly answer you question in regards to the Spring framework, but here's an article that talks about why if you need the ability to revoke JWT's, you might not want to go with JWT's in the first place, and instead use regular, opaque Bearer tokens.
https://www.dinochiesa.net/?p=1388
One way to revoke a JWT is by leveraging a distributed event system that notifies services when refresh tokens have been revoked. The identity provider broadcasts an event when a refresh token is revoked and other backends/services listen for the event. When an event is received the backends/services update a local cache that maintains a set of users whose refresh tokens have been revoked.
This cache is then checked whenever a JWT is verified to determine if the JWT should be revoked or not. This is all based on the duration of JWTs and expiration instant of individual JWTs.
This article, Revoking JWTs, illustrates this concept and has a sample app on Github.
For Googlers:
If you implement pure stateless authentication there is no way to revoke the token as the token itself is the sole source of truth
If you save a list of revoked token IDs on the server and check every request against the list, then it is essentially a variant of stateful authentication
OAuth2 providers like Cognito provides a way to "sign out" a user, however, it only really revokes refresh token, which is usually long-lived and could be used multiple times to generate new access tokens thus has to be revoked; the existing access tokens are still valid until they expire
What about storing the JWT token and referencing it to the user in the database? By extending the Guards/Security Systems in your backend application with an additional DB join after performing the JWT comparison, you would be able to practically 'revoke' it by removing or soft-deleting it from the DB.
In general, the answer about tokens by reference vs. tokens by value has nailed it. For those that stumble upon this space in future.
How to implement revocation on RS side:
TL;DR:
Take a cache or db that is visible to all your backend service instances that are verifying tokens. When a new token arrives for revocation, if it's a valid one, (i.e. verifies against your jwt verification algo), take the exp and jti claims, and save jti to cache until exp is reached. Then expire jti in cache once unixNow becomes > exp.
Then on authorization on other endpoints, you check everytime if a given jti is matching something in this cache, and if yes, you error with 403 saying token revoked. Once it expires, regular Token Expired error kicks in from your verification algo.
P.S. By saving only jti in cache, you make this data useless to anyone since it's just a unique token identifier.
The best solution for JWT revocation, is short exp window, refresh and keeping issued JWT tokens in a shared nearline cache. With Redis for example, this is particularly easy as you can set the cache key as the token itself (or a hash of the token), and specify expiry so that the tokens get automatically evicted.
I found one way of resolving the issue, How to expire already generated existing JWT token using Java?
In this case, we need to use any DB or in-memory where,
Step 1: As soon as the token is generated for the first time for a user, store it in a db with the token and it's "issuedAt()" time.
I stored it in DB in this JSON format,
Ex: {"username" : "username",
"token" : "token",
"issuedAt" : "issuedAt" }
Step 2: Once you get a web service request for the same user with a token to validate, fetch "issuedAt()" timestamp from the token and compare it with stored(DB/in-memory) issued timestamp.
Step 3: If stored issued timestamp is new (using after()/before() method) then return that the token is invalid (in this case we are not actually expiring the token but we are stop giving access on that token).
This is how I resolved the issue.
I'm developing a API to be used with my IOS App and I am curious on the best practice for using the refresh token in oAuth2. I am using the user password grant to generate a access token and refresh token.
If the token expires every 60 minutes then that means every 60 minutes the client will have to make 3 consecutive API calls: 1. use the access token to get the resource from the API, 2. api responds with a invalid token so we need to use the refresh token, 3. now that the token is refreshed we need to try the initial call again.
So, what I am wanting to know is if it's best to refresh the token just before it expires? Or is it better to generate a new access token once the API has responded with a expired token error?
Not sure there's a best practice as such, but it's certainly more efficient to refresh in advance as you then won't make requests that you can know will fail. The cost of the timer to refresh is much less than the cost of the network communication.
You still need handling for the token being invalid on any request as the server could invalidate the token for any number of other reasons, so this is really a 'how can I make this efficient and user friendly' than a 'can I remove some of my code' kind of thing. Handling the error response is the standard, refreshing in advance is the user friendly.
Be cautious about refreshing while you have in-flight requests and you could inadvertently cause a request to fail by invalidating its token...
Every time I read https://developers.facebook.com/roadmap/offline-access-removal/, I'm left more confused than the time before. I'm looking for some clarification on some items under scenarios 3 and 4 (server-side apps and client-side apps)
For server-side apps, it states "If the call is made while there is still a valid 60-day access_token for that user, the returned access_token from this second call may be the same or may have changed, but in either case the expiration time will be a fresh 60 days."
What is "the call" that is referred to here?
Is it the same exchange of an authorization code for the access token that takes place during the initial OAuth flow?
Or is it the endpoint call described under the client-side section to freshen the token to 60 days?
If it's the former, then where does the authorization code come from when trying to renew the token?
Is it the same authorization code from the original callback or do I have to go through the authorization flow again?
In short, can a server-side app keep freshening the life of a 60-day token and, if so then how?
Regarding client-side use, the document indicates that the client must make that endpoint call passing in (among other things) the application's client ID and client secret.
My interpretation of "client-side" may be wrong, but I'm thinking in terms of a JavaScript-based client running in a web-browser.
If that's what Facebook has in mind here, then should the JavaScript code really ever know about the client secret? (It won't be much of a secret if it's sent to the client.)
Even then, it indicates that 60-day tokens cannot have their life extended and that a new 2-hour token must first be acquired and used to get a 60-day token. This is under the client-side portion of the document, but does this rule apply to server-side 60-day tokens, too? If not, then I ask again: How do I freshen the life of a 60-day token on the server-side?
Finally, the question that has been burning in my mind for some time: Why has Facebook adopted this strategy and not adopted the refresh token as defined in the OAuth 2 specification (a specification that Facebook is helping define)???
EDIT: Further thoughts/questions after re-reading the document again:
At the beginning it says "a long-lived expiration time that can be renewed each time the user revists your app". My initial assumption is that the way to renew it would be to make a call to the endpoint later in the document. But, aside from the fact that the endpoint is described under the "client-side" heading, it also states "Please note, the endpoint can only be used to extend the short-lived user access_tokens. If you pass an access_token that had a long-lieved expiration time, the endpoint will simply pass that same access_token back to you without altering or extending the expiration time." (The typo on "long-lieved" is from FB's own documentation.)
Okay, so if that endpoint cannot be used to renew the expiration time (and my own attempts to renew a long-lived token with that endpoint prove this out), then how can I renew the expiration time on a long-lived token each time they visit my app?
Is there no one who understands how this is supposed to work?
After reading Facebook's doc (like for the 5th time) and with the help of this question/answer this are my conclusions.
What is "the call" that is referred to here?
It referres to the OAuth call to get an access token.
Is it the same exchange of an authorization code for the access token
that takes place during the initial OAuth flow?
Yes, I believe it's that flow.
Or is it the endpoint call described under the client-side section to
freshen the token to 60 days?
No, that endpoint is only valid for short-lived access tokens.
Is it the same authorization code from the original callback or do I
have to go through the authorization flow again?
You've to go through the authorization flow again.
how can I renew the expiration time on a long-lived token each time
they visit my app?
Long-lived access tokens cannot be renewed using the client side endpoint. The user will have to reauthorize the app to get a new one.
According to Facebook documentation:
If the call (OAuth authorization call) is made while there is still a valid long-lived user
access_token for that user, the returned user access_token from this
second call may be the same or may have changed, but in either case
the expiration time will be set to a long expiration time.
Once the application is reauthorized you'll get a new expiration time. Facebook may return a new long-lived access token, so you should grab it and replace that information for the one you already had.
Conclusion:
Seems there's no way to renew a long-lived access token without user intervention. To get a new expiration time/access token they'll have to reauthorize your app. My humble advice is that should suggest the user to reauthorize it, a few days before the expiration date.
Also, this Facebook how-to can came in handy for checking expired access tokens.
Is there any way to determine if an oauth token has been revoked besides actually making a function call? I am working with an Oauth provider that has a single function call that is time consuming and costs money. On my website, I'd like to be able to determine if my access token is valid withing making that call.
Thanks
Regrettably the OAuth specification does not provide a standard mechanism.
It would perhaps be appropriate for the OAuth provider to give an additional method to indicate that the token is valid.
You will notice that the token is not valid anymore when you try to use it to access some protected resource.
Without making a separate call, the server would have to push token revocation notification to you which it probably doesn't do.
Other than that, the server should provide you an expires_in token validity in seconds when issuing the token, so you should be able to at least tell yourself when the token is about to expire.