0

(This is a followup to my question about a general security scheme here)

As part of an authentication scheme for a single-page application + REST API, I planned to provide authenticated clients with a short-lived access JWT and a long-lived, revocable refresh token. After some consideration, it seems like the best way to store these client-side would be as cookies with HttpOnly and Secure set, as well as SameSite=Strict. HttpOnly should protect against XSS attacks accessing the tokens, and SameSite should provide some protection against CSRF.

However, if both tokens are sent with every request, is there any benefit to having separate access and refresh tokens? I suppose there's still the benefit of not requiring a database lookup while the access token is valid, but I thought part of the advantage of refresh tokens was that their exposure could be limited by only sending them on infrequent requests. Would it be better just to have a single, revocable token that requires a database lookup on every request?

  • Is the user with these access and refresh tokens a third party who is authorized to act on behalf of one of your service's users? – Ghedipunk Nov 1 '19 at 20:01
  • @Ghedipunk Nope, no third parties involved. – DylanSp Nov 1 '19 at 20:06
  • Then I don't see any reason to treat the refresh token as anything less than a slightly less secure password. Store it in a key-stretched form server side, store it securely client-side, and don't send it to your server unless you need it. And, since it isn't a password that the user themselves entered, don't trust that something on the client side computer can't read it (like a malicious browser plugin). – Ghedipunk Nov 1 '19 at 20:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.