Looks like jwt token really contains necessary info inside itself and the correctness of this data ensured via cryptographic signatures. Is there any reasons to persist this token somewhere on the server or "issue and forget" policy should be fine?
No, there is no reason to store JWT tokens on the server side. You can validate the token by checking signature. No need to talk to any server.
If the tokens have a short time to live, there's no need to revoke the access token itself.
Refresh tokens on the other hand are stored on the authorization server, have a long time to live and can be revoked.
Related
We have used JWT authentication scheme and resource owner password grant type with identity server. Backend is .Net core based micro services which is providing access token to angular based front end website.
As jwt token is not revocable and business requirement is to have longer access token lifetime, it seems only option is to have track of blacklisted tokens in database or cache.
Is there any way to modify the access token on backend and make it expire immediately when user triggers log out from frontend?
JWT cannot be revoked, it is by design as it is self-contained. Revocable alternative is Reference token which is not self-contained and thus server needs to actively communicate with identity server.
The compromise and common approach is to set access token lifetime to lower value and increase refresh token lifetime. Refresh tokens are revocable - it is supported by identity server 4 as well. So it is all about trade-off between the frequency of communication with your Identity server and long access token lifetime.
The JWT tokens are stored in the browser, so you can delete the cookie of it.
But this option gives no security on the server side.
If you are worried about deleted/suspended accounts then yes, you have either to create a blacklist but you have to compare them for each request.
The other option is to reduce the expire times and rotate them. there is a post with more details here Invalidating JSON Web Tokens
Background
I'm implementing an authentication system based on JWT and Refresh tokens but I had an hard time searching for serious documentation about the refresh token generation and handling.
The common scenarios I've found expect:
A short-live token JWT that is stateless and not stored on the server-side
A long-live refresh token that is stored somewhere on the client side and on the server-side and that allows to get new authorized JWTs.
Refresh token generation
My first question is about the refresh token generation. I've seen two main scenarios:
The refresh token is a simple random string or a uuid that it is stored (with its expiring time) on the server side and represent a long user session
The refresh token is itself a JWT containing the not-sensitive data of the user that has logged in and has itself an expiration
The first case is the simplest but allows to encapsulate session data only manually, the second case is more complex but allows to encapsulate the session data, the expiration and it is generated only by a secret held in the server (it means more security). In this last case, however, making the JWT persistent is against the JWT phylosophy and more effort is required for validating also this JWT and comparing the data.
Refresh token workflow
Prerequisites
Storing the refresh token on the client side is the only way to persist the session on something like a browser. However it has to been stored securely so there are two scenarios even here:
The refresh token get stored in the browser in something like the localStorage or the sessionStorage (less secure)
The refresh token is passed to the client using a HttpOnly cookie that are less reachable with Javascript.
Question
Assuming that we store the refresh token in an HttpOnly cookie I was wondering: does the endpoint /refresh_token, that returns a new JWT and a new refresh token, need to be authorized?
If the endpoint has to be authorized, I should have a valid JWT for validating my user without requesting username and password again. In a scenario where the user uses the web application in a browser, then he closes it, then after a while he returns to the web application (and the JWT has expired) this is not possible and requires the user to authenticate again.
If the endpoint is not authorized I cannot have, while validating the refresh token, a valid user instance to check the refresh token data against. So, the only thing that I can check is the validity of the refresh token with the store (or with JWT strategies). This solves the above-mentioned scenario but, is this safe enough?
Another scenario is that the endpoint accepts also expired JWTs, validates them and then it checks the refresh token.
How should the refresh token be validated for a secure implementation? What are the best practices about this?
I read a few articles, but still not able to derive a good enough understanding. So far, I understand that:
After successful authentication, server sends back an access token (ex. jwt) that a client uses to make authorized subsequent requests.
But this access token can get stolen from the client. So we'd make it short-lived. And, we use refresh token to renew the access token without having the user to follow authentication process again.
Questions:
Where do we keep the refresh token? Do we send it back to the client on initial successful authentication? Or do we store it on the server somewhere (DB)?
If we're sending it back to client and the client is using the refresh token to generate more short-lived access token, than that refresh token can also be stolen. How does it make the process secure? Wouldn't keeping a long-lived access token safe suffice?
Thank you.
To answer your first question, Ideally refresh token should be returned to the client along with the access token.
In order to make your access token/refresh token more secure you could add in some browser specific metadata into the JWT that you generate and verify on the server side to avoid token side jacking.
To learn more on some good REST security practices you can refer to this link
https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets
I am reading about jwt. after couple of days I get the idea of this concept.
now i my question is about create jwt token per user witch privent others to use
others token.
for example scenario :
user A login to server and get its jwt token and server allow it to access the
resources.
now a third party come in and get jwt token of user A. now third party can use this token and use this token to use resources without login to system.
how can i create jwt token spatially for a uniqe user?
The JWT includes in the 'sub' field the user identifier. It may only be used to identify this user
Once issued, the token replaces the user's credentials, so you have to prevent a token can be stolen and also mitigate its effects :
Mainly use HTTPS to avoid Man-In-The-Middle
Set a short expiration time and rotate the tokens
Remove token at client side after logout
Use cookies to store and set HttpOnly to mitigate the risk of client side script accessing the protected cookie
Maintain a server blacklist for non-accepted tokens. For example when user log out, changes password or updates permissions, also when administrator revokes an account.
Use cookies to store and set HttpOnly to mitigate the risk of client side script accessing the protected cookie
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.