1

The frontend and backend would have different domains. (could be on same domain but different sub-domains)

My flow:

  • Get CSRF token (as a cookie) from an endpoint
  • Attaches that token with any unsafe request as cookie as well as a header e.g X-CSRFToken with value that is mentioned in the cookie.
  • Take credentials from client and pass it to login endpoint.
  • Login endpoint returns an JWT access token inside response and refresh token as a httpOnly cookie.
  • Store JWT access token in a private data or a function closure
  • Any further requests would include
    • JWT access token as Authorization token value
    • CSRF cookie
    • CSRF cookie values as X-CSRFToken value

My question is, whether the flow seems okay from security standpoint CSRF/XSS and whether we really need CSRF? What about login CSRF, does the above covers it?

Edits

  • Clarifications
    • I have overridden the obtain token endpoint (of simplejwt) to return refresh token not inside the response but as a cookie with httpOnly attribute set to true and path attribute set to that of token refresh endpoint.
    • I have overridden the token refresh endpoint to expect the refresh token inside a cookie.
AhmedBilal
  • 65
  • 7
  • Cookies are still vulnerable to XSS. If an attacker manages to inject code into your client-side app, it can fetch cookies and send'em anywhere. On the other hand, what makes you believe that CSRF is not needed? Auth & refresh tokens and CSRF tokens address different security concerns. – Laiv Mar 14 '23 at 10:32
  • @Laiv I would be storing the refresh token cookie as secure and httpOnly. – AhmedBilal Mar 14 '23 at 14:10
  • Then checkout [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#samesite_attribute) cookie attribute. Be careful with `Lax`, but I agree with Ewan, ideally, you don't want to send sensitive data in every single request. The "most" secure way to manage sensitive data like this is by making them short-living. Even if it's safe on the client side, it could be vulnerable on the server side. Say the HTTP or App server is logging request headers for whatever purpose. Someone may see 1 refresh token now and then. In your case, it will see everyone's refresh token – Laiv Mar 14 '23 at 14:44

1 Answers1

3

No. the refresh token should only be used to refresh your access token.

So it doesn't make sense to store it in a cookie, which will be sent with every request, needed or not

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • I would set the path attribute of cookie to the url of endpoint responsible for updating the refresh token https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#path_attribute – AhmedBilal Mar 05 '23 at 13:53
  • you are assuming the refresh token endpoint expects a cookie. – Ewan Mar 05 '23 at 14:44
  • Sorry, I forgot to mention it, I added the clarifications in the original post as well. I have overridden the token refresh endpoint to expect the refresh token inside a cookie – AhmedBilal Mar 06 '23 at 06:01
  • so your question is "should i put the refresh token in a cookie (and then change lots of standard stuff about cookies and token auth to overcome the downsides)"? it kinda begs the question, why do you _want_ to use a cookie in the first place – Ewan Mar 14 '23 at 18:56
  • +ewan My goal is to use a method that is secure enough so that tokens can't get stolen using XSS attack. If I use localStorage it can be read by Javascript thus can be stolen using XSS attack. If you can suggest a method that wouldn't be too complicated yet secure, I would be thankful to you. – AhmedBilal Mar 15 '23 at 06:50