I managed to implement authentication with jwt tokens based on access token, refresh token and RTR (refresh token rotation). It simply follows all the rules:
Tokens are signed JWT-s with both having their own secret (one for access, one for refresh)
Tokens are set in httpOnly cookies with secure option so XSS and Man-in-middle are prevented
Refresh token has set path only to endpoint for refreshing tokens so it is not send on every request
RTR is enabled and on every refresh, refresh token is blacklisted in db and new access and refresh tokens are send back
CSRF tokens are used on routes that insert/delete/update db to prevent attacks
Now only problem I see is what to do when someone steals refresh token.
If someone actually steals it, he can send it to my refresh endpoint and he will then blacklist that stolen token and get himself new pair of valid tokens that can use indefinitely.
Since I don't want to keep track of sessions and users (that is why I use stateless authentication).
How can I detect stolen refresh token?
Should I keep track somehow of refresh tokens in db?
How can someone even steal refresh token?
Related
I have built one authentication using access token, refresh token and refresh token rotation. When a user login, the system generates one JWT token and one UUID hashed refresh token and its refresh token id then return back to user.
The init refresh token is a UUID token and it uses bcrypt to hash the uuid token then saving on the database. On the database, apart from saving the refresh token id and the hashed token, I also saved its expired date, its userId, active status and revoked ip.
The access token is passed inside Authentication header as a Bearer token for JWT verify. When one access token is expired, it calls /refresh-token with the old refresh token value and its id to get a new access token and refresh token pair. If the refresh token is expired, I will ask the user to login again.
I also have a refresh token rotation method to avoid refresh token reusing. When a refresh token reused, I will revoke and disable all the refresh tokens belonging to that userId family. So the user should login again to get the new access token and refresh token pair.
I know OAuth2 is a good protocol to implement access token and refresh token authentication. With my authentication design, how to improve it to make it with OAuth2?
Well it sounds like your UUID has all the powers of a refresh token to a client. And if the client is a browser it should never receive a refresh token - a secure cookie is considered better.
The main things I would recommend are the use an Authorization Server and to follow standard guidance around APIs, web and mobile apps.
OAuth provides a number of security design patterns. It is worth understanding the specifics of web and mobile clients. Also think about security related features such as auditing of tokens issued.
Here are some resources from Curity, where I work. The concepts here apply to any provider - it is the principles that matter:
IAM Primer
Free Authorization Server
Guides
I'm working on a project (nothing production-level, only for leveling up my skills) and I'm using JWT to handle authentication.
From what I've read, using a JWT only as an access token is quite unsafe, and hence we need refresh tokens. So, on login, the server returns an access token and a refresh token (which I will be storing in an httpOnly cookie). The access token expires in a short time, but the refresh token is used to get a new one when it does.
My question is, when do we use the refresh token to get a new access token? Is it when the user wants to get a protected resource and finds that the access token is expired (and the refresh token has not) or do we send a new access token each time the user wants to get the protected resource? I'm confused about when and where the refresh token comes into play.
(I'm using React for the frontend and Nodejs for the server)
You're using some security token so it mean that your system has some protected resources. Those resources can only be accessible on successful validation of the token. As you're using the JWT Token (usually for stateless authentication) and your system is granting both access_token and refresh_token to the client, so on server side you can use some authentication interceptor to validate the access_token in the each private request and return some error code on token expiration. On the client side you could also use some filter which should capture the error code and by utilizing the available refresh_token it should request for new access_token from the server. In case of refresh_token expiration your system should follow the route of fresh authentication.
The refresh token can be used at any time to request a new access token. Checking the validity of the access token before he request is one way of accomplishing that. Another common practice is to refresh the access token if it is within a certain timeframe of the current token expiring. A simple cronjob can work in this case. If you assume the access token is not used in multiple places (which it shouldn't be) then the current access token can be invalidated when the new access token is created. Also, for maximum security, the refresh token should be replaced with the access token. This limits security risk around a long-living refresh token becoming compromised.
In the last few days I've been reading on Authentication with refresh and access tokens, but this is one thing I can't find the answer to. Let's say an expired access token is sent. Should the backend automatically refresh it (if a refresh token was provided), or the refreshing should only be done at a refresh endpoint?
As an example, consider the two following auth flows:
Automatically Refreshing
User authenticates with username and password. The API sends back a short lived access token containing his data, and a long lived refresh token.
For every request that requires authentication/authorization, the user will send both tokens on the request headers.
If the access token is expired, the API will check if a valid refresh token was sent, if it is active and if it belongs to the same user as the access token. If everything looks good then it will sign a new access token and update the response headers with it.
Front-end doesn't have to worry about refreshing the token, but it still has to look up response headers after each request to check if a new token was sent.
Manually Refreshing
User authenticates with username and password. The API sends back a short lived access token containing his data, and a long lived refresh token.
For every request that requires authentication/authorization, the user will send his access token.
When the access token expires, the user will send his refresh token to the refresh/ route. The API checks if the token is valid. If everything looks good, it returns a new access token.
After every request, the client has to check if the token expired, and if it did it will have to perform a new request to refresh the token. More requests are being made to the server, but on the other hand responsibilities are better separated, since auth route is only responsible for handling access tokens, while the refresh token handling lives in another route.
I've had some hard time finding resources on the subject, so I'm not quite about sure which solution is better, or even if the solutions I described are correct at all. If I had to pick one, I would go with Automatically Refreshing, since less requests are made, and the client side usability looks better, but as I said, I'm not 100% on this, and thus I'm making that thread.
How should access tokens be refreshed?
It feels to me that you are missing a role here, which is that of the Authorization Server (AS):
UI redirects to AS to authenticate the user via password
AS issues an access token and refresh token, then returns them to the UI
UI calls the API for a while with the access token
Eventually the access token expires and the API returns a 401 response
The UI then calls the AS with the refresh the token to get a new access token
The UI then retries the API call with the new access token
Eventually the refresh token expires and the refresh attempt will fail
The UI then redirects the user to sign in again and the cycle repeats
It is always the client's responsibility to refresh tokens and only the access token should be sent to the API. The API's only OAuth job is verify the access token and authorize based on its contents.
It is possible that you have an API that is doing the job of the Authorization Server. I would aim to separate these roles. If it helps my Messages Blog Post has a lot of detail on the messages in a full UI and API solution.
The implementations of the OAuth2-protocol I know use the flow you are describing under "Manual Refreshing". The client has to care himself about the refreshing.
The client can either check the access_token if it is still valid before every request or do a refresh after a failed request due to an invalid token response.
The access_token is short lived and so the risk sending it with every request and having it eavesdropped and misused is limited. The refresh_token is long lived. If you send the refresh_token with every request an attacker has a much greater chance to get hold of it.
If you send both token with every request you would not need the distinction between these two types. You would work with one long lived token only.
Following is the Main Disadvantage of using Automatic Refresh Token Rotation Scheme :-
Let's say the Client makes 2 API calls (API A and API B) at the same time. At the time of triggering these two API calls, the access token was expired. Both of these API calls are carrying the same expired access token and the refresh token (let's assume this refresh token is valid).
Let's assume API A gets handled by the server first. According to the Automatically Refreshing Scheme, the server will check the API A's access token, if that token is expired, server will check the refresh token and if that refresh token is verified (this refresh token is present in the database too), the server will create a new access token and a new refresh token (the refresh token that came with the API will be deleted from the database and will be updated with this new refresh token). These new tokens will be returned to the Client.
API B will follow the same flow. BUT its Refresh Token will be invalid because during the handling of API A, the refresh token was replaced in the database by a new token. API B's Refresh Token is not present in the Database and thus this request will fail.
If you have multiple APIs being called at the same time, Automatic Refresh Token Rotation Scheme will fail as the First API request will replace the Refresh Token when renewing the tokens and the remaining API requests will be coming with a Refresh Token which is not present in the Database !
My experience has been that the OAuth2 access_token requests dont like extra data meaning that you wont be able to send both the access_token and the refresh_token. That would lead to the Manual Refreshing scenario youve described as the only option
I'm working on an application that uses a token-based authentication system, where the user provides their username / password and receives a token in return (the token gets saved to the database as well). Then subsequent requests will include this token as a custom header and we can use this to identify the user. This all works fine.
Right now if the user doesn't login for 3 days, we expire the token. I was reading a little about refresh tokens in OAuth and I was wondering if I could somehow implement something similar. i.e. when providing the auth token, I also provide a refresh token which can be used later to request a new auth token. In terms of security though, it seems quite similar to just never expiring the user's auth token in the first place. Should I be sending additional information with the refresh token to validate the user?
In OAuth2, the resource server and authorization server are often not the same.
The refresh token is sent back to the client when the access token is issued and when the token is refreshed. The client needs to authenticate itself (using client id and client secret) to use the refresh token. The resource server never sees the refresh token.
Also, access tokens are not stored at the server side as they have a limited lifetime. Refresh tokens are stored and can therefore be revoked.
From https://stackoverflow.com/a/7209263/1225328:
The idea of refresh tokens is that if an access token is compromised,
because it is short-lived, the attacker has a limited window in which
to abuse it.
I get it, but if the attacker accesses the refresh token, they will be able to get a fresh auth token, am I wrong? This seems to just postpone the long-lived tokens security flaw...
Concerning this point, you'll find in the same answer:
Refresh tokens, if compromised, are useless because the attacker
requires the client id and secret in addition to the refresh token in
order to gain an access token.
Then what's the difference between using a refresh token and simply resigning in? And how do you store the client id and secret if you don't want users to have to reenter them again?
As #FStephenQ pointed out, a refresh token can be used only once: an attacker will then be able to get a new auth token, but only once, and a short-lived one. But then, how do you obtain a new refresh token once you already used one? If you get a new one when you use one, an attacker will then be able to refresh their token too...
The actual question is: how to keep my users signed in? On the apps I use, once I signed in, I never have to sign in again: how do they proceed?
A refresh token can only be used to refresh once, and it is only sent to the authentication server when the client's access token has expired. When a refresh token is used, the authentication server returns a new authentication token, and optionally a new refresh token. The idea is to allow using short-lived access tokens, while allowing a valid client to re-authenticate without forcing the user to login again.
If a refresh token is stolen, then it can be used once to get a valid access token by the attacker. When the client tries to refresh their token, their refresh token will be stale, and so will be rejected. They will then ask the user to login again, and the authentication server will give them a new access token and refresh token, and the stolen token will be invalidated.