Is storing access token in private data, refresh token in http-only cookie safe?

Question

• Backend: Django / Django Rest Framework, would be hosted at GCP k8s
• Frontend: Angular, would be hosted at some CDN e.g Vercel
• Authentication: JWT (https://github.com/jazzband/djangorestframework-simplejwt)

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.

• Laiv: 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.
• AhmedBilal: @Laiv I would be storing the refresh token cookie as secure and httpOnly.
• Laiv: 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

Answer 1

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

• AhmedBilal: 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/…
• Ewan: you are assuming the refresh token endpoint expects a cookie.
• AhmedBilal: 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
• Ewan: 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
• AhmedBilal: +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.