CODEWITHSUNDEEP
node.jsapisecurityauthenticationjwt
undefined
undefined

Reputation: 2119

Access Token and Refresh Token Dilema - JWT

I have a dilemma following the use of Access Token with Refresh Tokens.

Let's say we have the following scenarios:

  1. User Login -> An access token valid for 5 minutes is returned and saved in local storage. At the same time, a refresh token valid for 3 months is saved in cookies with httpOnly and secure properties. The application will use the access token to get access to resources and after 5 minutes when it expires it will automatically use the refresh token to generate a new access token. After 3 months the user will be asked to log in again.

  2. User Login -> An access token valid for 3 months is saved in cookies with httpOnly and secure properties. The application will use this token to get access to resources and after 3 months the user will be asked to log in again.

What is the point in using method 1 instead of method 2?

Upvotes: 0

Views: 410

Answers (1)

Gabor Lengyel
Gabor Lengyel

Reputation: 15570

Nothing. If you can do #2, then you should, and it's more secure. JWTs are vastly overused, in case of #2, your access token is almost like a plain old session id, why not just use a session id then? (The only reason could be real statelessness, but in many cases the application is not stateless anyway, for example if you want to be able to revoke tokens.)

What you cannot do with #2 is sending the access token to a different origin, and that is actually needed sometimes. Imagine you app is hosted on example.com, but your api is exampleapi.com. If you stored your access token in a cookie, it could not be sent to the api. What usually happens in a more generic case is you have a refresh token (almost like a session, but without server-side state) with the identity provider that can issue tokens on idp.example.com, that's the domain of the secure, htponly cookie. This issues a jwt that your app downloaded from www.example.com can use on api.example.com or wherever else, because the access token is stored by javascript (eg. in localStorage). The point is the token can be accessed by javascript (xss), but it's short-lived, and xss requires user interaction, so it's not easy for an attacker to issue a new access token without the user doing something. The refresh token is stored more securely in a httponly cookie.

If you don't want to send your tokens to a different origin, a httponly cookie is actually better, and you're right, a refresh token doesn't make much sense then. Note though that if the token is stored in a cookie, you will have to mitigate csrf too.

Upvotes: 1

Related Questions