When logging in, a JWT access token is sent from the server and saved in AsyncStorage in RN.
Now I want the user to stay logged for 5 years, until they either:
log out
admin revokes their token
they are logged in on 3 devices, change their password on one of the devices, which should log them out from the other 2 devices until they login again on those devices
lose their phone, and login from another device to log out from all devices
It looks like I'd have to store JWT tokens in the DB (I know that's not the point of JWT tokens and defeats the purpose they are serving based on my reading) but I would need to know the user's tokens, on their different devices, to be able to revoke them.
One thing that confuses me is reading that the access tokens should be short lived, say 60 mins, and refresh tokens long lived, say 5 years in my case.
What I don't understand is why can't we just use the access tokens to have a 5 year life span (for each device), save them against the user in the DB so we can identify their tokens and revoke their tokens based on the aforementioned points? What would be the point of a refresh token, would it even be needed in this case?
Note: I also read that we can't revoke access tokens, but can only revoke refresh tokens, so I am really confused. Would I have to send both an access token and a refresh token to RN, and only use the refresh token for the Authorization Bearer header and save only the refresh token in the DB? Then what would be the point of the access token if it's not the one in the DB?
I think this should be something simple to implement, but my criteria are the 5 year login and being able to revoke tokens based on the points above.
What's a correct solution for this situation?
Access Tokens are short lived, which is by default 24 hours. But why? Why not 5 years?
Anyone with the access token is guaranteed access to whatever the user (to whom it was originally issued) can access. This means the server cannot differentiate between that user and anyone else who has the access token.
There is NO logging out. What I mean here is that you can have your front-end redirect to sign-in page to have him enter the credentials, but truly logging out does not happen in the server. Technically, the user can use the same access token to continue getting access (until it expires)
Access Tokens canNOT be revoked. Access tokens are invalidated only upon expiry. Anyone can use it until the token expires. For instance, if the expiry is set to 5 years and I happen to get your token by some chance, I can have all access that you have till it expires which in this case would be 5 years. This is exactly what gives more sense to set the expiry time lesser than 24 hours.
Now lets address your queries. "I want to user to be signed in until he"
Logs out
Send refresh token to user after he signs in. Store both access token and refresh token very securely. After his access token has expired, use the refresh token to get a fresh access token. Loop this until he logs out. When he logs out, delete the access token and refresh token on the front-end and revoke the refresh token on the server side. (Again, if he somehow gets the access token, he still can access his account till it expires)
Admin revokes token
The server can't revoke access tokens as I told before, once issued its valid until expiry, no matter what -> But only as long as the user has the access token :P Delete the access token as soon as he opens the app, if he did not last open the app in the past 1 hour or so. Now the front-end is forced to get a new access token using the refresh token it has stored. Now, you want the user to force logout? Revoke his refresh token.
Logout on all devices after password change
Same as 2. After he changes password, revoke all refresh tokens issued (In case you don't want the user to sign in again, revoke all refresh tokens except for the current device). Your app on all devices will be forced to get a new access token using the refresh token, but since you revoked it, the user has no way other than to log in using his credentials.
User-triggered logout from all devices
Same as 3. Changing the password triggers logout on all devices and here you just need to add a "Logout on all devices" button that will send a server request which revokes all refresh tokens except for the current device.
Caveat: Current user session cannot be closed; You need to wait for the user the exit the app, so as to have the current access token deleted. Workaround is to delete the access token as immediately as he closes the app (or even he minimizes the app) or setting the access token expiration to 30 minutes, provided you can tolerate the latency caused by obtaining new access token using the refresh token everytime he does that. You need to tradeoff time for security or vice-versa, depending on the your app specifications.
"That's all fine, but I don't want a refresh token in the first place" (Alternative Solution):
I don't encourage storing tokens as it defeats the very purpose of scaling and preventing easy DDoSes, by increasing the response time which increases due to querying the db. But since Redis is amazingly fast key-value store that runs on memory, some prefer storing access tokens in it. Well how does that work?
Setup: Once the user logs in, issue an access token. store it in Redis, then send it to user.
Check JWT signature && token's integrity, if it fails hurray, no db query. Send back 404 user not found. This will be as quick as how JWTs without Redis function.
If it succeeds, check Redis for the token. IF it exists, grant access. If it doesn't, ask the user to log-in again. Note that this will be a bit slower than granting access using just JWTs, but hey, you aren't storing in it Postgres or Mongo, which might take a few milliseconds to respond; Redis being a key-value store - and for it sits on memory (and not storage) - is considerable faster than those.
Access is granted if and only if both the conditions are satisfied: JWT is valid. JWT is present in Redis
Answering your queries:
Logouts are now possible. When user hits logout, delete from Redis the access token. He can't login even if he has the access token. Access Token is now literally invalid.
Admin forces logout: Delete access tokens for that user from Redis.
After the user is successfully granted access by the server, you shall allow the user to issue a request to delete all other tokens with the same user-id (or uid) which will allow logout
After password change, issue such a request.
On Logout from other devices, issue such a request.
Finally the left out 1. Stay logged in until user logs out: Now that you have authority to invalidate access token which you didn't have when not using Redis, you can have a 5-year valid access token, provided you implement other required security measures to prevent misuse of the access token.
Related
I am currently building a Node.js application and trying to use JWT to handle sessions. In every implementation that I've seen the refresh-token is stored in a fast database like redis. When the token has expired, the client sends the refresh-token to get the new access-token, then the server checks if the refresh-token is in the database, then generates a new token.
But since the refresh-token must be generated by the server, cannot be tampered with, and we can also check if it has expired, why do we need to store it. If it is for logout then can't we just store the user_id in the database for the people who have been logged in without storing the refresh-token.
I was also thinking along the lines of storing the newest access-token instead of refresh-token in redis as value for the user_id. The reason being that we will generate a new access-token only when the previous one has expired. So the following scenario cannot happen,
User logs in, gets access-token and refresh-token.
Immediately refreshes their token while the previous one is still valid.
Logs out, and uses their old access token.
Since most implementations blacklist only the access-token provided by the client during logout, I believe this scenario can be possible if the REST API is used by the client.
So what is the use of storing the refresh-token, and would storing the access-token instead be beneficial in any way. Some more information regarding the application,
I am using redis for logged in users, and blacklisted access-token (provided during logout).
I am storing both refresh and access tokens in httpOnly cookies, and sending access tokens as bearer tokens.
refresh-token is sent in POST body while refreshing the access token.
I am not using https
Let me answer each of your questions:
"But since the refresh-token must be generated by the server, cannot be tampered with, and we can also check if it has expired, why do we need to store it":
Refresh tokens are meant to have very long expiration times (possibly months), so that users do not have to log into the application frequently (especially in the case of mobile applications). Therefore, if a malicious person steals a user's refresh token, the user's protected information will be exposed for a long time. In case this happens, a considerably secure application should have mechanisms to, for example, detect sudden changes in the IP address of its users and report them. Now, if a user confirms the existence of strange behavior in his account, it is necessary to revoke all his refresh tokens to protect his information, and to do this, it is necessary to have control of the refresh tokens that a certain user has, so they have to be stored.
"If it is for logout then can't we just store the user_id in the database for the people who have been logged in without storing the refresh-token":
You need to store both, both the "user_id" and the refresh tokens, in such a way that you can have a control of all the refresh tokens of a certain "user_id" (as stated above). If you only want to store the "user_id" of the logged in users (without storing refresh tokens), I don't know how you will check if a user is authorized to renew an access token without having to make the user log in.
"I was also thinking along the lines of storing the newest access-token instead of refresh-token...":
By doing this you are losing advantages of the "stateless" approach offered by JWTs (https://restfulapi.net/statelessness), since you are storing a state of them. If you really want something like this, it's probably best to use a "stateful" approach like sessions.
I don't see the reason to do this. Suppose you have a web application and a mobile application connected to a RESTful API, if the user logs into both applications he will have multiple valid access tokens and refresh tokens, so it is perfectly normal for a user to have multiple valid tokens at the same time.
If a user logs out, simply remove the access token and the refresh token from his device, additionally, remove the refresh token from the database. Use short expiration times on access tokens (15 minutes is very common), and so you have no need to store them as they will expire quickly. That's it.
I've been doing a lot of reading on this subject and I can see that there are many different opinions and approaches to authenticating using JWT.
My understanding is as follows:
In its simplest form, a JWT authentication mechanism should:
Verify username and password.
Create a signed JWT access token containing information (depending on the app's needs) on the user.
Send that token in the response.
The client then stores the token (which from my understanding there is some debate whether a secure cookie or localStorage is more secure), and sends it with each request's headers.
The server can then authorize the user using middleware verifying the JWT. No state, all information in contained within the JWT.
Assuming the JWT has no expiration (or perhaps a very long expiration date, maybe a couple of months), it sounds good because I can provide the user a persistent logged in state for a long time. The concern is, to my understanding, if the JWT was to be stolen, it is essentially an unlimited access card and a huge security breach.
So that's where the refresh token enters, the server issues both refresh and access tokens (refresh token with a long/unlimited expiration and the access token short).
The server database holds some kind of table of valid refresh tokens (so that if one is stolen it can be invalidated easily) and when issuing a new access token, validates the refresh token.
This also adds the need to add some sort of countdown mechanism on the front end where a refresh request is to be sent to the server prior to the access token expiration date so that the user won't be logged out.
And my question:
Why? If we go through all the trouble of creating a db table for refresh tokens, why not just make a table of valid access tokens and invalidate them if needed? How is that less secure than using refresh tokens?
Thank you
Access tokens aren't primarily used to provide extra security, but to provide efficiency and decoupling.
An access token can have a very short lifetime - maybe even less than a minute - but be used to authenticate multiple requests to different services within that time. Those services don't need to have any access to the authentication database, because they can trust the access token until its expiry date; that makes them faster and simpler.
For instance, if you're using a dynamic page with lots of AJAX requests, that might run in very quick succession. Those AJAX calls might be implemented as serverless functions (e.g. AWS Lambda), or as standalone scripts in different programming languages on different servers, or you might just want to make them as efficient as possible, and avoid any database access. The only information that needs to be shared between them is a public key to verify the signature on the JWTs they receive.
From a security a point of view, this is a trade-off: on the one hand, an access token for a user whose access has been revoked can still be used until it expires; on the other hand, the long-lived refresh token is transmitted much less than a traditional session token, so there are fewer chances for it to be intercepted.
To address your concrete concern:
This also adds the need to add some sort of countdown mechanism on the front end where a refresh request is to be sent to the server prior to the access token expiration date so that the user won't be logged out.
No "countdown" is needed. The code that has access to both tokens simply looks at its current access token before using it; if it has expired, or is about to expire, it requests a new one using the refresh token. It then gets a new access token, and probably a renewed refresh token - the expiry date on the refresh token represents how long the user can be idle before they are automatically logged out.
We don't need to make a table of access tokens and it is dangerous to secure.
We have to save only refresh token and add one field for valid/invalid in the table. And send access token and refresh token to the client side.
The clients send access token with each request's headers.
The server can authorize the user using middleware verifying the JWT.
After some time, the access token will be expired(access token's expired time is shorter than the refresh token's expired time).
The client sends refresh token to server.
Then the client will get new access token using refresh token(refresh token should be recreated, in other words, we can use only one-time refresh token, we have to update table of refresh token with new refresh token).
The client can get new access token and refresh token.
I hope it will be help you.
here is my auth's flow:
The user receives two tokens (access token with expiration time and refresh token without expiration time) after logging in
for each user , The refresh token is stored in the database in a json column called refreshTokens(which is an array).
on the client side, Both access token and refresh token are stored on the local storage.
when user needs to be verified, If the access token is expired, a new access token is created using the refresh token and sent back to the user and keeps the user logged in.
When the user logs out, the refresh token stored in the database (in the refreshTokens list) is removed.
my questions are:
is this flow, secure?
do i need to save refresh token on the cookie or is local storage good enough?
That flow is according to how OAuth works and how tokens can be stored in a secure way, so "yes" to both questions. The part that is missing is how the tokens are obtained in the first place: for that the Authorization Code grant type using PCKE is the preferred way, over the legacy Implicit grant type.
An important part of this flow being secured is that in point 4 you use the list of refresh tokens kept in the database to verify that the RT was not revoked. Other than that it looks ok. You can add more security by adding expiration times to refresh tokens. Then, even if the user doesn't actively log out (you don't clear RTs from the DB), the RT will not be usable after some time.
Keeping the tokens in local storage is good enough in my opinion.
Few stuffs that popped up in my mind while reading this :
Refresh Token also needs expiration time. In fact, I consider refresh tokens as a double edge sword. Imagine a scenario where a person gets access to the refresh token, not only he gets access to the resources, he will practically gain more time with the resources. I prefer to re-generate refresh token along with access token when refresh token is being used to re-generate the access token. And, also set an expiry to it.
It is cool to store the refresh token in database. However. I do have an alternative though, you can easily use RSA algorithm and then do token generation using private key and verify using public key. This is yo mitigate the scenario of needing to store the refresh tokens.
On client side, local storage is a BIG NO from my side. What I prefer is that you use HttpOnly Cookies and set flag as true. HttpOnly Cookies are not rendered in JS and is sent to server securely as per Http protocol. This is fix the chances of compromising tokens.
Your rest concept of it is good enough.
I am implementing JWT inside a client mobile app with a separate back-end server, and I am looking for an optimum way to use refresh tokens without too much server calls and while keeping a good user experience.
I am new to implementing such a mechanism, and I am confused about many things, so what I am really looking for is a solid conceptual solution to secure the user access to the app, and keep him at the same time logged in indefinitely.
Any correction or suggestion would be most welcome:
Why refresh tokens anyway?
Using a JWT access token alone might compromise the user security: If an attacker holds the access token, he might run feature requests whenever he wants. Even when applying an expiry date to the access token, if the server issues a new access token whenever the old one expires, the attacker will receive this new access token using his old one, and keep accessing the user features.
Refresh tokens stop the attacker once the user regains access to his account using his login/password: When the user uses the app and the server detects that his refresh token is invalid, he will be logged out and a new refresh token and access token are issued after he's logged in with his credentials. The attacker won't be able then to use the old tokens.
My first question would be:
I. Regardless of how the attacker gets hold of the tokens from the user environment, would he be able to use them indefinitely as long as the user is still inactive and isn't logged in again with his credentials to create new tokens?
What about when the tokens are refreshed asynchronously?
Let's imagine a scenario where the user is inside the app, and at least two server calls are run asynchronously:
"Service1" makes a server call with an expired accessToken1 and a refreshToken1, and the server responds by sending a new accessToken2 and refreshToken2
Before receiving the "Service1" response, "Service2" makes an other server call with accessToken1 and refreshToken1, the server compares refreshToken1 to the previously saved refreshToken2 and finds them different. It responds then with an Invalid refresh token response, and this causes the user to be logged out!
To avoid this problem and keep the user logged in, there could be a centralized authentication service that checks first the validity of the tokens before any server call is made. Which means that any call won't be executed unless the authentication service is idle, or wait for the new tokens if it's already loading.
My second question here is:
II. Having such a service to avoid the asynchronous refresh token problem means more round trips to the server, which might prove costly. Is there a better solution?
There are some steps to login / revoke access to an api:
When you do log in, send 2 tokens (Access token, Refresh token) in response to the client.
The access token will have less expiry time and Refresh will have long expiry time.
The client (Front end) will store refresh token in his local storage and access token in cookies.
The client will use an access token for calling APIs. But when it expires, pick the refresh token from local storage and call auth server API to get the new token.
Your auth server will have an API exposed which will accept refresh token and checks for its validity and return a new access token.
Once the refresh token is expired, the User will be logged out.
JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.
What about when the tokens are refreshed asynchronously?
that supposed be done with a single request to an endpoint, so there is a single accessToken
Having such a service to avoid the asynchronous refresh token problem means more round trips to the server, which might prove costly. Is there a better solution?
i think that's the best & secure solution for mobile and serverless apps, token are like ssh keys must be kept secure all the time :)
for more information check [question]: JWT refresh token flow
Here's the official introduction to JWT
I am building a token based authentication (Node.js using passport/JWT with an angular client).
After the user enter his credentials he gets an access token, which he sends in every request inside the header (header: bearer TOKEN).
I don't want to prompt a login request everytime his access token expires (about everyday I guess),
I've heard about the Refresh Tokens. The refresh token never expires (or rarely expires) and able to renew tokens indefinitely.When the access token is about to expire, the client can send a renew request to get a new access token by sending his refresh token.
I don't understand few things, I might be missing something:
How a long-living/never expiring refresh tokens don't ruin the security of having short-living
access tokens.
Cookies can be stole and be used until they expire. Tokens are short living so they more secured,
but if I provide a long-living refresh token I lose the advantage of using tokens.
NOTE: I am aware that the refresh tokens are sent at the initial login, so cann't be spoofed in every request, but if they are spoofed at the initial request they are vulnerable.
The refresh token is presented on a different path than the access token: the access token is only ever presented to the Resource Server, the refresh token is only ever presented to the Authorization Server. The access token can be self-contained so that it does not need costly calls to the Authorization Server to check its validity, but to mitigate loss and to increase accuracy (it cannot be revoked in case something goes wrong) it is short-lived. The refresh token is long lived and gets validated on each call to the Authorization Server and as such it can be revoked. The combination of the two makes the system secure.
I use the following approach:
Tables/indexes:
User table (just has the user ids and all the user related meta-data)
JWT table (three fields : user_id, access_token, refresh_token)
Authentication Flow
1.When a previously unauthenticated user signs in, issue a JWT which contains an access token, and a refresh token. Update the refresh token in the JWT table, together with the user_id, and the access token.
2.Make sure that the JWT has an expiration time that is something small/comfortable for your users. Usually less than an hour.
4.When a client makes a request with a JWT
a. Check expiry of the access token. If the token has not expired -> continue without hitting any db tables.
b. If the access token has expired, lookup the user_id in the JWT table, and check if the refresh token and access tokens match, whatever the client has provided,
If yes, issue a new JWT with the response and update the new refresh token,access token into the JWT table.
if no, return 401. The client is forced to ask the user to then sign in.
END.
To summarize,
1.DB calls are required only to check if the refresh token is valid.
2.This system allows for a user to sign in from any number of devices, with any number of JWT's
3.All JWT's related to a user can be invalidated, by wiping the refresh tokens related to that user from the JWT table, this can be done, for eg: when a user changes his/her password. This, in effect, narrows down the window of compromise to the expiration time of the access token/JWT.
I believe this is the intention behind JWT's. The percentage of DB calls/user depends on your expiration time, the duration a user is usually on your website, etc.