I'm running a website + native apps that communicate via HTTPS with my backend. The following requirements must be fulfilled:
Sliding session on the website. That means if the user interacted with the website within the last xx Minutes, he must not be logged out
Remember me on the website. When this is checked, the user must not be logged out (or after a very long time)
The user must not be logged out on the app
Access can be revoked, either by the user (currently logged in) or specific events (password changes).
What I currently have is the following: A refresh token endpoint generates a JWT when password hash and username match in the database. Every refresh token has a jti that is stored in the database, as well as expiration (for DB cleanup only), device_id and a revoked flag.
Another endpoint can be hit with the refresh token, which returns a JWT access token. The access token is valid for 15 minutes. The access token cannot be revoked.
My problems arise with requirement 1. I do not want the user to reauthenticate when he's interacting with the website. This means I need the refresh token. However, the refresh token must only be valid for e.g. last user interaction + xx Minutes. I cannot extend the access token with every request, as there is no way to blacklist access tokens. This would mean that a leaked access token is like a master key forever (as long as you constantly hit the api in 15-minute intervals). But I also do not know what the expiration for the request token could be.
The second problem is (2) with incognito modes or multiple devices. Assuming the user opens 20 private tabs and uses remember me on all of them. Then I have to store 20 tokens in the database. I could, of course, set a limit for type "web" to say 5 and "app" to 3 and remove the oldest last accessed one from the database (and therefore invalidate it). But this would log him out on the "main" browser if he opens 5 private tabs somewhere. It would also limit the number of phones to e.g. 2.
Different PCs/laptops would also generate many refresh tokens of type web. How would I best identify the corresponding device so access can be revoked, but I also do not store hundreds of refresh tokens over the application's lifetime? Best would be one refresh token per device (windows+firefox, iPhoneA, iPhoneB, windows2+firefox). But identifying desktop PC's is super hard.
What it comes down to is:
How can I store refresh tokens in the DB so they are identifiable to the end-user (e.g. Whatsapp webs "Safari started in New York last used at xxx-xxx-xxx"
How do I avoid having hundreds of tokens per user in the DB (as refresh token basically never expire, and the user can open as many private tabs as he likes without logging off)
How can I implement sliding windows with the refresh/access token pattern? So no unlimited refresh token on the client-side, but also no logoff after the access token expires as long as there is any usage. I could have it in the session storage, but then it still clutters my database and shows to the user as "currently logged in" (which displays all refresh tokens) as it's basically still valid.
Sliding session on the website. That means if the user interacted with the website within the last xx Minutes, he must not be logged out
To solve this problem you can use a refresh token, i.e when the user login for the first time, the application will return a access token (JWT format), with an expiration date set to the amount that you want.
When the user will browse the application, your backend will return a X-Refresh-Token header valid for your xx amount of time (i.e you'll need to return this header for each backend call).
If the acess token is expired (the backend will read the access token used, and perform check on expiration date token field), the backend will return a 401 Unauthorized error,
and your client must call the authentication endpoint, providing the last refresh token stored, to issue a new access token.
With this implementation your requirement #1 is satisfied.
Remember me on the website. When this is checked, the user must not be logged out (or after a very long time)
To solve this one, you'll just need to generate a long lived access token (i.e with an expiration date set to the amount of time you want).
The user must not be logged out on the app
I don't understand this one
Access can be revoked, either by the user (currently logged in) or specific events (password changes).
This one is really tricky. Since backend is stateless, revoking access token is a really complex topic.
Hopefully a lot of pattern existing to solve this one, we just need to discuss about it.
Related
I don't see a point in which you would with implemented refresh token rotation blacklisted tokens instead of keeping track of current ones.
If you are blacklisting tokens, you would get a lot of tokens blacklisted very fast. Let's assume your access token TTL is 5 minutes and your refresh is 7 days. If user is using your app for and hour, he would blacklist 12 tokens in that time. If you have great number of users, that would be a lot of blacklisted tokens.
Problem with that is also theft of refresh token. If someone managed to steal it, they can immediately exchange it for pair of new tokens, users active token (that is stolen) would be blacklisted and thief could just use your app normally from that point. How to solve that? Your user would provide blacklisted token on next request and would be logged out, he will log in again and start normally using app but so does the thief, since his token is valid, unless you invalidate his token somehow, but for that you need to keep track of current tokens.
Why just don't keep track of current client token? On every refresh request, you just check if provided token is current users token, if it is not put token value in database to "null". That why users will be forced to log in even if they stole your refresh token since current token must be valid to even check the database if it is same as current (because if refresh token is invalid or expired, you must logout user). Next time they log in, you would set new current refresh token in database and thief can't do nothing with stolen token.
Isn't this breaking stateless rule? It does, but in classic session you need to check database on every request, in this system you would check only when access token expires.
Plus, you don't need to keep track of possible of millions blacklisted tokens and you prevent from refresh token theft.
Only downside I see is that if someone actually steals your refresh token, and you never make any requests after that, they will be logged in until they log out or somebody sends bad request to refresh token endpoint that will "lock" your account.
I have been using Flask and JWT to create authentication on my backend. Creating and using access tokens is simple enough, but I've run into some conceptual misunderstanding when trying to discover how to handle the usage and storage of refresh tokens.
Upon initial login, I distribute an access token (with 10 minute expiry) and a refresh token (with 4 day expiry). The 'jti' attribute of the refresh token is stored in a table on the database, along with its expiry date. The access token is stored in memory, and the refresh token is stored in HttpOnly cookies. When the access token expires, a "silent refresh" is sent to the backend with the refresh token. It is first checked for validity (user ID matches up, signed correctly, and is not expired), and then the database is checked to see if it contains that specific refresh token's 'jti'. If it does, then that refresh token is deleted from the database (and can therefore no longer be used) and a new access token and refresh token are sent to the user. This allows for the refresh tokens to only be single use. However, if a user logs out and logs back in repetitively, the refresh token cookie in their browser keeps getting overwritten with a new value (which is fine), but the database now contains a ton of references to "unused" refresh tokens. I'm not sure if my understanding of the JWT workflow is completely incorrect, or if this is normal.
I mainly conceptually followed this guide. Is this repetitive logging in and getting refresh tokens normal? I don't see how to manually find and remove older (but still valid) tokens that are used in the same browser.
Your implementation looks fine. It's normal that you issue new tokens for a new session. I think there are two solutions to your problem:
Add a expiration column to your table with refresh tokens. Then you will be able to remove stale jtis from the table once they're expired.
Instead of keeping information about issued refresh tokens, you can keep information about used refreshed tokens. So, when you issue the token you don't save it in the DB. When the user uses the RT, you can save the jti and expiration in the DB. Whenever a RT is used you check whether the jti is in the DB. If it is, you decline the request. You can remove entries from this table after expiration, as you verify expiration on the RT anyway.
I was worried, as you are, when implementing an Access/Refresh flow with overwritting refresh tokens (there are other strategies,as keeping a blacklist and a whitelist).
I discovered that there were two ways to end with "unused" refresh tokens (as you say) or, as I prefer to name them, "stalled" refresh token (you will see why in a second):
First way: LogOut
As you detected Log Out can lead to stalled refreshed tokens in the database.
Probably, you, as me, (and 90% reading this answer) were just "logging out" from the Client side, aka "deleting Access and Refresh tokens" from the client memory/cookies/localstorage and done. Right? Why so?
However, you can send a "/logout" request to your server with your access token (to authenticate) and your refresh token (in the body), so you can delete the refresh token from the database. I would not pass the JTI, but the whole refresh token (after all it is going to be erased shortly afterwards, so no issues if anyone intercepts it with a MIM attack). This way you can double check the user requesting the /logout is exactly the owner of the refresh token (as a security measure), this security check would be lost if you send just the JTI value (which could lead to an attack: an user requesting a refresh token to be erased, through its JTI, from other user). (Yes you can use the JTI to perform a database check to know its owner, but each time the server performs a database call "God kills a kitten", while you can easily compare the user_id in the access against the user_id in refresh token)
Performing a /logout call, each time the user "/logout" you are really killing her refresh token from the database. And hence the ability to create access tokens if the refresh token got compromised (or sniffed) before the user performed a /logout. If an attacker got the "unused" refresh token, even if the user logged out, could exchange it for a refresh and access token again. Let's reduce the "number of refresh tokens" able to create access tokens for an user.
Second Way: Expired Tokens
A second way to have a "stalled" token is when the client tries to /refresh but the refresh token is already expired. In such case, dont just return an error code that will be used by your app to send the user to the Log In page, but also delete the refresh token from the database. Why do you need to keep it? This cleanup strategy reduces the size of your table and helps to clean your database of already expired refresh tokens. You, ofc, will need a script to clean refresh tokens from users "never-returning" to your app or from users who decided to delete localstorage/cookies, but ey! your cleanup script will be fast as hell now.
This second way is the reason I prefer to call all of them "stalled" because they are sitting there (ones being "unused", others being "expired") and filling your table.
Hope these strategies help your security concerns, a pleasure to meet someone as "geek" as me regarding JWT security.
I have a server which protects its api with an ouath2 authentication.
The scenario:
User asks for a token (password flow).
User deactivates\deletes its account.
The token is still valid (I know that its possible to invalidate token but there is another scenario where user generates tokens from 2 different clients (browser\mobile) or 2 different browsers -> receives two valid tokens -> impossible to invalidate 2 different token so one is still valid).
How should I protect my API from a valid token that it's owner isn't relevant anymore?
Should I invalidate all tokens related to the user in the account deactivation\deletion moment? Not sure if its a good idea to store in the database all user's tokens.
Should I check that the user is still active for every operation after token verification? Its a big overhead for such an end case.
*In a situation where all user's related data is being deleted as well there is no problem (the api's response will be empty), but there are cases where this data isn't being deleted.
Thanks!
You can reduce the lifetime of access tokens and use them in combination with refresh tokens. Your information will only ever be as stale as the lifetime of the access token so set it to whatever you think is acceptable, at the cost of your clients having to go back to the Authorization Server to get a new access token (this is where the deleted account check takes place). See: Why Does OAuth v2 Have Both Access and Refresh Tokens?.
In the Facebook's Graph API, once we have initially authenticated the user, we can interact directly with the API (from the server) to obtain a long-lived page access token. This long-lived page access token never expires. (https://developers.facebook.com/docs/facebook-login/access-tokens/)
In reading LinkedIn's documentation, it appears that it is impossible to obtain an access token with an indefinite (non-expiring) access token. It seems that they expire every 60 days. However, these access tokens can be refreshed before the 60 days is up.
What isn't entirely clear from the documentation is whether or not the access token renewal can be performed on the server alone without the client's interaction. The language of the documentation suggests that the interaction of the client (browser) is required, but nothing is explicitly stated.
So, my question is, is it possible to renew a LinkedIn access token using the server alone, without the interaction of the client (browser)?
Relevant LinkedIn reference material: https://developer.linkedin.com/documents/handling-errors-invalid-tokens
As it turns out, the access tokens of linkedin can not be refreshed without having linkedin user logging in to linkedin. Please refer to the first comment here by LinkedIn employee which clearly states a note that "this refresh will only work if the user is still logged into LinkedIn (authenticated) and the current access token isn't expired. Otherwise, the user will be presented with the login dialog again."
I guess that is now a major issue for those who were previously storing the linkedin access tokens to database for later use.
I am mentioning few links here which refer to the issue with refreshing linkedin oauth2 tokens (hope this makes it clear for everyone who is struggling with the same issue):
1) This refresh will only work if the user is still logged into LinkedIn (authenticated) and the
current access token isn't expired. Otherwise, the user will be presented with the login
dialog again.
2) There is no way to refresh the token using the old authentication token/secret. User
needs to log into linkedin in order for you to refresh the tokens. We use this flow as it
protects our members and their data in the best possible manner.
3) Refreshing an access token is very simple and can happen without an authorization
dialog appearing for the user. In other words, it's a seamless process that doesn't affect
your application's user experience. Simply have your application go through the
authorization flow in order to fetch a new access token with an additional 60 day life span. When the following conditions exist:
-User is still logged into Linkedin.com
-The current access token isn't expired (within the 60 life span)
We will automatically redirect the user back to your redirect_uri without requiring them to reauthorize your application. If they don't exist, we'll prompt them to login and then redirect
them.
4) We have also standardized the duration of the authorization tokens. Previously, members
could choose to grant tokens that were as short as one day or as long as forever. Now all
tokens are 60 days in length, with the ability for you to extend them in a series of rolling 60 day increments whenever the member comes back to your application. To prevent a bad user experience in your application, be sure to proactively refresh tokens and elegantly route any expired tokens through a refresh flow.
5) As long as the user is logged into LinkedIn and their current access token hasn't expired, you can fetch an access token with a 60 day lifespan the next time the user comes to your application.
I had the same question and the LinkedIn docs and forum posts are confusing, but I'm pretty sure now that it's not possible to do it programmatically without user intervention (i.e. the user needs to login to your app via LinkedIn auth to refresh the token).
i have to confess i've had this question for a very long time, never really understand.
say auth token is like a key to a safe, when it expires it's not usable anymore. now we're given a magic refresh token, which can be used to get another usable key, and another... until the magic key expires. so why not just set the expiration of the auth token as the same as refresh token? why bother at all?
what's the valid reason for it, maybe a historical one? really want to know. thanks
I was reading an article the other day by Taiseer Joudeh and I find it very useful he said:
In my own opinion there are three main benefits to use refresh tokens which they are:
Updating access token content: as you know the access tokens are self contained tokens, they contain all the claims (Information) about the authenticated user once they are generated, now if we issue a long lived token (1 month for example) for a user named “Alex” and enrolled him in role “Users” then this information get contained on the token which the Authorization server generated. If you decided later on (2 days after he obtained the token) to add him to the “Admin” role then there is no way to update this information contained in the token generated, you need to ask him to re-authenticate him self again so the Authorization server add this information to this newly generated access token, and this not feasible on most of the cases. You might not be able to reach users who obtained long lived access tokens. So to overcome this issue we need to issue short lived access tokens (30 minutes for example) and use the refresh token to obtain new access token, once you obtain the new access token, the Authorization Server will be able to add new claim for user “Alex” which assigns him to “Admin” role once the new access token being generated
Revoking access from authenticated users: Once the user obtains long lived access token he’ll be able to access the server resources as long as his access token is not expired, there is no standard way to revoke access tokens unless the Authorization Server implements custom logic which forces you to store generated access token in database and do database checks with each request. But with refresh tokens, a system admin can revoke access by simply deleting the refresh token identifier from the database so once the system requests new access token using the deleted refresh token, the Authorization Server will reject this request because the refresh token is no longer available (we’ll come into this with more details).
No need to store or ask for username and password: Using refresh tokens allows you to ask the user for his username and password only one time once he authenticates for the first time, then Authorization Server can issue very long lived refresh token (1 year for example) and the user will stay logged in all this period unless system admin tries to revoke the refresh token. You can think of this as a way to do offline access to server resources, this can be useful if you are building an API which will be consumed by front end application where it is not feasible to keep asking for username/password frequently.
I would like to add to this another perspective.
Stateless authentication without hitting the DB on each request
Let's suppose you want to create a stateless (no session) security mechanism that can do authentication of millions of users, without having to make a database call to do the authentication. With all the traffic your app is getting, saving a DB call on each request is worth a lot! And it needs to be stateless so it can be easily clustered and scaled up to hundreds or even thousands of servers.
With old-fashioned sessions, the user logs in, at which point we read their user info from the database. To avoid having to read it again and again we store it in a session (usually in memory or some clustered cache). We send the session ID to the client in a cookie, which is attached to all subsequent requests. On subsequent requests, we use the session ID to lookup the session, that in turn contains the user info.
Put the user info directly in the access token
But we don't want sessions. So instead of storing the user info in the session, let's just put it in an access token. We sign the token so no one can tamper with it and presto. We can authenticate requests without a session and without having to look up the user info from the DB for each request.
No session ... no way to ban users?
But not having a session has a big downside. What if this user is banned for example? In the old scenario we just remove his session. He then has to log in again, which he won't be able to do. Ban completed. But in the new scenario there is no session. So how can we ban him? We would have to ask him (very politely) to remove his access token. Check each incoming request against a ban list? Yes, would work, but now we again have to make that DB call we don't want.
Compromise with short-lived tokens
If we think it's acceptable that a user might still be able to use his account for, say, 10 minutes after being banned, we can create a situation that is a compromise between checking the DB every request and only on login. And that's where refresh tokens come in. They allow us to use a stateless mechanism with short-lived access tokens. We can't revoke these tokens as no database check is done for them. We only check their expiry date against the current time. But once they expire, the user will need to provide the refresh token to get a new access token. At this point we do check the DB and see that the user has been banned. So we deny the request for an access token and the ban takes effect.
The referenced answer (via #Anders) is helpful, It states:
In case of compromise, the time window it's valid for is limited, but
the tokens are used over SSL, so unlikely to be compromised.
I think the important part is that access tokens will often get logged (especially when used as a query parameter, which is helpful for JSONP), so it's best for them to be short-lived.
There are a few additional reasons, with large-scale implementations of OAuth 2.0 by service providers:
API servers can securely validate access tokens without DB lookups or RPC calls if it's okay to not worry about revocation. This can have strong performance benefits and lessen complexity for the API servers. Best if you're okay with a token revocation taking 30m-60m (or whatever the length of the access token is). Of course, the API servers could also keep an in-memory list of tokens revoked in the last hour too.
Since tokens can have multiple scopes with access to multiple different API services, having short-lived access tokens prevents a developer of API service for getting a lifelong access to a user's data on API service B. Compartmentalization is good for security.
Shortes possible answer:
Refresh tokens allow for scoped / different decay times of tokens. Actual resource tokens are short lived, while the refresh token can remain valid for years (mobile apps). This comes with better security (resource tokens don't have to be protected) and performance (only the refresh token API has to check validity against DB).
The following is an addition to the benefits of refresh tokens that are already mentioned.
Safety First!
Access tokens are short-lived. If someone steals an access token, he will have access to resources only until access token expires.
"...But what if a refresh token is stolen?"
If an attacker steals the refresh token, he can obtain an access token. For this reason, it it recommended that a new refresh token is issued each time a new access token is obtained. If the same refresh token is used twice, it probably means that the refresh token has been stolen.
When the refresh token changes after each use, if the authorization
server ever detects a refresh token was used twice, it means it has
likely been copied and is being used by an attacker, and the
authorization server can revoke all access tokens and refresh tokens
associated with it immediately.
https://www.oauth.com/oauth2-servers/making-authenticated-requests/refreshing-an-access-token/
Of course, this is just another layer of security. The attacker can still have time to obtain access tokens, until the refresh token is used a second time (either by the attacker or the real user).
Always keep in mind that the refresh token must be stored as securely as possible.