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.
Improve this question
3
  • 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 at 10:32
  • @Laiv I would be storing the refresh token cookie as secure and httpOnly.
    – AhmedBilal
    Mar 14 at 14:10
  • Then checkout SameSite 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 at 14:44

1 Answer 1

Reset to default
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

Improve this answer
5
  • I would set the path attribute of cookie to the url of endpoint responsible for updating the refresh token developer.mozilla.org/en-US/docs/Web/HTTP/…
    – AhmedBilal
    Mar 5 at 13:53
  • you are assuming the refresh token endpoint expects a cookie.
    – Ewan
    Mar 5 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 6 at 6: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 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 at 6:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.