Allow httpOnly cookie storage

[jaycle]

Similar to #23 but with a different motivation.

To protect against XSS, I would like the option to store the JWT in an HttpOnly cookie. django-rest-framework-jwt has this feature as an optional setting but that project I believe is abandoned and also has a vulnerability due to preventing the usage of django's CSRF token (see: jpadilla/django-rest-framework-jwt#434). Combining an HttpOnly cookie with CSRF token would be a pretty rock solid solution.

References:
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
https://stackoverflow.com/questions/44133536/is-it-safe-to-store-a-jwt-in-localstorage-with-reactjs

[derek-adair]

This is super important for me going forward... and it should be for everyone who uses this project. It SEEMS to be rather trivial to set the cookie.

Unsure what other side effects this may have.

[fergyfresh]

@derek-adair I pick the cookie out in nginx and put it in the authorization header. This is a workaround, but it works for me.

[derek-adair]

I'll hopefully be submitting a PR for this in the near future!

[davesque]

Cool, @derek-adair . Looking forward to seeing that!

[mrodal]

I could give it a try too, but I'm not sure how the refresh tokens come into play with cookies.. I think they don't make sense with cookies,

• If both are cookied, then both would be included in each request.. which takes away little secrecy the refresh token had.
• If only one of the tokens is cookied, the other will be kept in the client, which makes it vulnerable to XSS attacks. In this case, it would make more sense to leave the access token in the client, since its lifespan is shorter

So.. I guess that in order to touch the less amount of code possible, the best solution would be to cookie both tokens, but yeah, the refresh tokens doesn't add any security here

[derek-adair]

@mrodal - yes it does, when its an httpOnly cookie. This may only add an extra step, but exposing your tokens to native, insecure browser api's is not good.

https://blog.codinghorror.com/protecting-your-cookies-httponly/

[derek-adair]

I'm pretty sure the scenario described is the way to go. If anyone else has a more thorough understanding of how to secure these tokens i'd love to learn about it.

While modern browsers support and prevent reading/writing via httpOnly. there are a fair amount of legacy browsers that allow for reading/writing of these headers. So this will really only slow down script kiddies, but its a pretty low effort feature that will add security.

It's my understanding that JWT is inherently insecure and requires certain steps to harden that are likely beyond the scope of this project. I'm certainly no expert on this subject so I welcome any corrections or direction on how to implement this project, or JWT in general... securely.

[mrodal]

what do you mean by "it does"? What I meant is that as far as i know, refresh tokens provide an extra security layer because they are less exposed (they are only used when the access token expires)

But if they are stored in cookies, both travel in each request, so I don't see how refresh tokens make it more secure

[davesque]

@mrodal makes a good point. Refresh tokens are supposed to be sent over the wire less frequently (only when obtaining a new access token or access/refresh pair). It's a bit awkward in the context of web browsers, but JWTs can potentially be used by non-browser clients as well. The access/refresh dichotomy makes more sense in that broader scope.

[davesque]

IIRC, another option would be that the refresh token cookie is only set for the refresh view's path. Then, it would only be sent over the wire for refresh requests in particular.

[derek-adair]

@mrodal it's my understanding that httpOnly + same site cookie is more secure than storing it in memory or localStorage (XSS vulnerability).

If the refresh token is not persisted in a cookie where would you suggest storing it?

Honestly this shit is soooo obtuse... this is the healthiest dialog i've participated around this subject. I'm almost convinced to NOT implement JWT for web browsers. However, i'm not sure the alternative for a single page app.

IIRC, another option would be that the refresh token cookie is only set for the refresh view's path. Then, it would only be sent over the wire for refresh requests in particular.

Could you elaborate? Didn't know it was possible to do this.

[derek-adair]

Does django mitigate XSS?

As someone who possesses JUST enough knowledge about security to fuck it up... i'm quite confused as to how to implement ANY jwt setup securely (in a web browser).

[mrodal]

If the refresh token is not persisted in a cookie where would you suggest storing it?

I would actually not use it at all when using cookies.. Since it requires extra logic in the front-end and, as I said before, I don't see the benefit from using it. This is what Im doing in a mobile app that's also going to be a spa in the future.

Take into account that storing it in the cookie makes you possibly vulnerable to CSRF attacks if you don't use CSRF tokens, since the auth token is automatically added to each request...

Does django mitigate XSS?

If you are using django templates, you are protected by default when printing data from the server side. But you could still be vulnerable if you generate content on the front-end, although last time I checked, browsers also help quite a lot to prevent these attacks.

[derek-adair]

I would actually not use it at all when using cookies

So just make them re-auth when it expires and/or store the actual token for longer?

Since it requires extra logic in the front-end

Now that you mention it... man i wish i would have came to that conclusion before I implemented a replay request thing in my redux app.... ha!

This is what Im doing in a mobile app that's also going to be a spa in the future.

Right, it's clear this is where the miscommunication.

Take into account that storing it in the cookie makes you possibly vulnerable to CSRF attacks if you don't use CSRF tokens, since the auth token is automatically added to each request...

What about if you are using CSRF tokens? Should be good is my understanding.

[derek-adair]

Jeeeeez. So the refresh token seems to be useless in a browser... however....

httpOnly cookie still seems essential for the access-token.