2

I've always been under the impression that storing both of these tokens in an httpOnly cookie is secure enough, but been lately reading some people only store the refresh token in the cookie, and since the accessToken is short lived, they store it somewhere in app memory (context, redux, whatever). Since the entire goal of the refresh token is to fetch a new access token, the access token doesn't have to be stored in a cookie, but has it's disadvantages if you don't?

I think the issue for me is that with SSR, you can't access the access token on the server (NextJS for example), so you can't do prefetch/other operations on the server when you need to access token values right?

I assume that even context is an attack vector, so storing both of those tokens within the cookies is the safest?

It seems its more of a debate than being frowned upon in terms of storing both tokens in a cookie at the same time.

haptn
  • 650
  • 6
  • 11
Nelson Melon
  • 21
  • 2
  • Why store and manage anything yourself, when browser can do it for you? Like, why do extra work? – zerkms Feb 17 '23 at 03:04

1 Answers1

1

Storing both tokens in HTTP-only cookies is the safest way and is currently recommended as a security best practice for SPAs. However, this has some limitations and sometimes it's more convenient to store the access token in memory. When you have the access token in a cookie then you need your own backend that will handle those cookies. E.g., if you're calling APIs that require access tokens in the Authorization header, and you're not in control of those APIs, then you somehow have to translate the cookie to the header. Some people find it easier to just keep the access token in memory and call the APIs directly, without any intermediary backend components. Not all systems require the toughest security standards. Sometimes it's about finding the balance between robust security and good developer or user experience.

Michal Trojanowski
  • 10,641
  • 2
  • 22
  • 41