I think cookies are meant for long-lived tokens and JWTs are not meant to be long-lived.
The way in which I do it I create a JWT and a refresh token. The JWTs lasts for at most 30 minutes in my case and the refresh token which can just be any random string I normally do a UUID for that token and it can last up to a year but can only be used once. I personally just choose to store them in local storage but if I wanted to use a cookie I would only store the refresh token in an HTTP cookie that way it can not be accessed by JS.
If using refresh tokens, when would you refresh it? Would your application have a timer that lasts the duration of the JWT and automatically uses the refresh token when the timer reaches zero, or would you keep using the JWT until an error comes back then use the refresh token? Thanks.
That is a great question. We keep using the access token (the name our JWT has when we are also dealing with refresh tokens) until it expires. Afterwards we use the refresh token with an authentication service to generate another access token (JWT) so your second assumption is correct.
How does it know that our JWT expired? In the payload we include the iat (issued at) claim with a value that is the date and time of when it was generated. Afterwards this IAT claim is compared with the exp (expiration) claim to determine if it should be accepted. If it is rejected what I wrote above happens.
You explained in a great and clear manner! Just adding to what you said to help Tushar in case he is unfamiliar with refresh tokens:
It's good to set a low expiration for the JWT, as low as possible. So if we set a low expiration we'll have to login into a page more often, for the user this may get annoying.
Refresh tokens were created with many purposes in mind, one of them is to enhance user experience, since it has a long expiration date and is used to generate a new JWT (in this context the JWT is called access token) when it inevitably expires with its short expiration. This avoids making us have to login into a page again when the access token expires.
There are other important purposes to them, here are useful reference material:
Garret's comment is a useful tip. Another good thing to keep in mind is that a truly 100% secure place does not exist, so it's important to understand the limitations and unique vulnerabilities of local storage vs cookies and learn how to mitigate these vulnerabilities.
I recommend you to read the reference resources below, especially the 'So, What’s the difference?' section on the first link.
I have used jwt before in cookies for front-end auth. Do you think it's a good idea to do that?
I think cookies are meant for long-lived tokens and JWTs are not meant to be long-lived.
The way in which I do it I create a JWT and a refresh token. The JWTs lasts for at most 30 minutes in my case and the refresh token which can just be any random string I normally do a UUID for that token and it can last up to a year but can only be used once. I personally just choose to store them in local storage but if I wanted to use a cookie I would only store the refresh token in an HTTP cookie that way it can not be accessed by JS.
If using refresh tokens, when would you refresh it? Would your application have a timer that lasts the duration of the JWT and automatically uses the refresh token when the timer reaches zero, or would you keep using the JWT until an error comes back then use the refresh token? Thanks.
That is a great question. We keep using the access token (the name our JWT has when we are also dealing with refresh tokens) until it expires. Afterwards we use the refresh token with an authentication service to generate another access token (JWT) so your second assumption is correct.
How does it know that our JWT expired? In the payload we include the iat (issued at) claim with a value that is the date and time of when it was generated. Afterwards this IAT claim is compared with the exp (expiration) claim to determine if it should be accepted. If it is rejected what I wrote above happens.
You explained in a great and clear manner! Just adding to what you said to help Tushar in case he is unfamiliar with refresh tokens:
It's good to set a low expiration for the JWT, as low as possible. So if we set a low expiration we'll have to login into a page more often, for the user this may get annoying.
Refresh tokens were created with many purposes in mind, one of them is to enhance user experience, since it has a long expiration date and is used to generate a new JWT (in this context the JWT is called access token) when it inevitably expires with its short expiration. This avoids making us have to login into a page again when the access token expires.
There are other important purposes to them, here are useful reference material:
Thank you, for the explanation and further information, all the people answering my questions are awesome!
Garret's comment is a useful tip. Another good thing to keep in mind is that a truly 100% secure place does not exist, so it's important to understand the limitations and unique vulnerabilities of local storage vs cookies and learn how to mitigate these vulnerabilities.
I recommend you to read the reference resources below, especially the 'So, What’s the difference?' section on the first link.
Here are useful reference resources:
Thank you, for the explanation and further information, all the people answering my questions are awesome!