5

In my web application I am using JWT. After a user loggs in, they are issued a refresh token and an access token. The refresh token is sent to cookie storage with the HTTP-only flag, while the access token is only saved in the memory of the front-end application. Basically once the browser is closed and re-opened, a new access token has to be requested based on the existing refresh token.

Now I want to implement a "remember me" functionality. I am thinking that if the "remember me" option is not set, only the access token (and not the refresh token) will be sent. Once the browser is closed or the access token expired, the user will have to login again.

Is this method secure? Are there any alternatives to it?

2 Answers 2

5

Access Tokens (AT) and Refresh Tokens (RT) should still both be used. ATs should be short in duration no matter what. They are the keys to your house and shouldn't be exposed for long.

Adding to Anders UX discussion, something like the following could be considered which would present better security:

Remember me is checked

Have a sliding RT expiration time, with a lengthy lifetime (a month). If a user keeps accessing your application, the sliding mechanism keeps pushing it a month. If you feel like at some point you need for the user to re-authenticate, you can set an absolute time (a year).

AT and RT (it should be linked to a specific path, e.g. /refresh) should both be stored as cookies with the upmost levels of security, by implementing cookie prefixes (e.g. __HOST-), attributes (Secure, HttpOnly, SameSite) to avoid HTTP leakage, XSS attacks, and CSRF. XSS still has one way to achieve an attack which is by simply creating an XHR and sending it to the attacker with credentials. CSP could help with locking data exfiltration attacks if properly implemented.

By using other web storage mechanisms, you're opening up the attack surface. Cookies are the main spot where security controls are being added over the years.

Remember me is NOT checked

Instead of having the RT with a lifetime of a month, it could have it for a couple of hours. The AT should still be as small as possible. To remove the RT on browser closing, create Session Cookies.

Using cookies allows you to destroy them on demand by setting the Expiry to an earlier date, so that helps as well on that end.

I mainly focused on cookies, but any other type of storage could be used with the same logic in mind. I am biased to using cookies for anything related to AuthN-Z.

1

If I understand you correctly, everything will stay the same for a user that uses the "remember me" option? But a user that doesn't will only recieve an acces token? This should not pose any new security problems. All you are doing is giving the user the option to not getting a refresh token, i.e. recieve less access.

One thing, though. For non-remembered users, you plan to expire the session once the access token expires. That will probably either lead to a very annoying user experience where you have to login over and over again, or to long expiration times on the access tokens (which could be a security issue).

To get around that you will need a refresh token for all users, but set a shorter expiration time and perhaps don't store it on clients for as long if the user doesn't use the "remember me" option.

3
  • Don't store any tokens in local storage. That's the weakest kind of storage the browser can provide, and that's not the last straw to pull. This isn't even SPA.
    – Elie Saad
    Jun 29, 2020 at 12:11
  • 1
    @ElieSaad Storing refresh tokens in local storage is fairly standard practice, and in my opinion no better or worse than the alternatives.
    – Anders
    Jun 29, 2020 at 12:18
  • @ElieSaad Thinking about it, I removed that part of my answer since it is actually out of scope of the question and a bit off topic.
    – Anders
    Jun 29, 2020 at 12:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .