Tokens in cookies

[ghost]

Issues:

There is a problem of storing refresh token at client side between page reloads and browser restarts. Localstorage or Sessionstorage are bad idea for such secret data due to a chance of XSS attack leaking the refresh token.

Solution proposed:

A possible solution would be to put the refresh token in httponly cookie and set its path to certain urls responsible for refreshing access token or verifying the token inside that cookie. Though one has to implement CSRF protection for these paths only.

What is implemented?

New views are implemented as follows:

• One view will authenticate the user with credentials and send the refresh token in an httponly cookie. The access token will be sent inside the response body.
• Another view will refresh the access token by accessing the refresh token from the cookie.
• A new verifier view for the tokens residing in cookies.

Corresponding tests are implemented too.

New settings are added for specifying the -

• Path
• Domain
• SameSite and
• Secure

attributes of the refresh cookie token.

[Andrew-Chen-Wang]

@PalSubham when I find the time, I'll make a middleware that allows for you to switch between session cookies by Django for production and SimpleJWT for local production for hot reloading if you're using an SPA.

However, this seems more like a duplicate of #321 and #157; what's the difference?

[ghost]

@PalSubham when I find the time, I'll make a middleware that allows for you to switch between session cookies by Django for production and SimpleJWT for local production for hot reloading if you're using an SPA.

However, this seems more like a duplicate of #321 and #157; what's the difference?

Unlike #321 , my implementation does not need the authentication backend to be changed. Only refresh token is sent in cookie. The access token will be sent in response body as already implemented. It could be stored in a variable and added to Authorization header using JS whenever required.

Hence, each request would not need CSRF protection, except the refresh-token request when refresh token cookie is sent automatically to retrieve the new access token.

I have a mind to implement a logout view based on the token blacklisting capability.

Also, all previous views based on non-cookie approach are kept, as they might be helpful for mobile clients.

[Andrew-Chen-Wang]

@PalSubham I appreciate you writing this code, and it must work well on your codebase, but without CSRF protection and also reading a comment in your code saying "This view needs CSRF protection," I'm going to favor the other two PRs.

I appreciate the code though; thank you!