How to implement the refresh token flow in Loopback 3.x ?
Some have recommended to refresh the 'created' columns of access token table, so the access token does not expire. But this results in a 'long-lived' access token. This is a security flaw.
Related
I'm using .NET 6 with HttpOnly cookie-based JWT authentication in my WebAPI, and I'm now implementing token refresh.
I store the JWT and a Refresh Token in cookies, e.g.:
X-Access-Token: eyJhbGciO...
X-Refresh-Token: d8085ec8-d0bc-4e5c-b6b6-cd76146c419f
Most flows I've found for token refresh look like this, with the client calling the /refresh endpoint to get a new JWT:
client sends request to server
server rejects request with a 401 Unauthorized
client requests new JWT (expired JWT and Refresh Token automatically sent to server in cookie)
server validates cookie Refresh Token, generates new JWT and Refresh Token, assigns to cookies
client sends original request to server, with the new JWT and Refresh Token in the cookie
My question is:
When the initial request with the expired JWT is received by the server, since the server already has the refresh token (sent in the X-Refresh-Token cookie), can't the server issue a new JWT and Refresh Token at that time and successfully complete the request? This completely eliminates the need for a separate request and response to refresh the tokens. This is the flow:
client sends request to server
JWT is expired, but Refresh Token is valid
server creates new JWT and Refresh Token, assigns to cookies
server successfully completes the request
Is there a vulnerability or security risk implementing the refresh this way? I cannot think of one, but I could not find any examples with this flow.
Thanks!
Why are you using JWT access tokens? If the server could respond with an updated access token by looking at the refresh token, then why wouldn't the server just look at refresh tokens every time, and then the JWT access tokens aren't needed?
The point of using JWTs, and access tokens in general, is that it allows stateless authentication with services that have no access to the refresh token store. Usually, you will have an authentication service, it stores the refresh tokens, and calls to /refresh get routed to it, and it will validate the refresh token, and issue the access token. Then, calls to other services are able to validate the access token, without needing to make any calls on the authentication service. So, the reason why they don't just reply with a new access token when authentication fails is because those services are incapable of checking the refresh token, they don't have access to the refresh token store, only the authentication service does.
If however your application is one big monolith, where every endpoint is hosted by the same server and therefore is capable of checking refresh tokens and issuing access tokens, then there is absolutely no reason for you to be using access tokens or JWTs in general. You should just use refresh tokens, which, in this case, would be better called a session token.
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.
I have used jwt token securing angular application and in the backend, we have used asp.net core API. After login successfully we have saved the token in local storage in web browser memory and we log out from the application simply remove the token from browser memory.
We can stop the user to access the application through the application but if some have the token he can access the endpoint using postman and other api test tool. How can we overcome this problem.Is there any way to remove the token or expire the token manually.
Revoke the jwt token is not easy , 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.
A simply way is using short lived access tokens and refresh token , use refresh token to renew the access token , if you want to revoke the user , revoke the refresh token on server side , clear refresh token and access token on client side .
Another way is reference tokens. The basic idea is Authorization Server will store the contents of the token in a data store and will only issue a unique identifier for this token back to the client. The API receiving this reference must then open a back-channel communication to Authorization Server to validate the token , so that the server side could control whether reference token(unique identifier) is still available . Identity server 4 also provides the reference token feature :
http://docs.identityserver.io/en/latest/topics/reference_tokens.html
I am currently working on an API with django rest framework, and I have a question about token (JWT or OAuth2) authentication.
Actually I have a doubt about the utility of a long-lived refresh token when the authentication server and the resource server are the same.
What I understand about refresh token is that when a user authenticate, the authentication server send in return a short-lived access token and a long-lived refresh token that we store.
When the user interact with the resource server we send the access token in the request and never the refresh token. And if the access token has expired, we ask for a new access token sending the refresh token to the authentication server.
By this way if the attacker get the access token, he will have a short window to use it because it is short lived.
But in the case of authentication server = resource server, if the attacker can compromise the access token, he can compromise the refresh token too. And he can get new access token easily, am I right ?
So what is the purpose of using a refresh token system in this case (authentication server = resource server) ? In my opinion this is the same as set a long-lived access token, but I'm not sure...
Thank you