Storing the authentication token in an HTTP-only cookie on the server side

[alecvn]

It seems that storing authentication tokens in HTTP-only cookies is the most secure way of attaching the token to requests. As far as I understand, even if the frontend and backend are served from separate domains, CORS rules can be implemented to allow the cookies.

So, I have a few questions surrounding the option of storing the auth token in an HTTP-only cookie on the server side via KNOX:

1. What would be the suggested way to implement this? I've seen some small examples on stack-overflow but presumably the contributors/owner here would have the best advice. Would you override the LoginView or would you create a different authentication class (or both)?
2. If such an implementation is viable and useful, would the repo owner accept a pull request to have this become an option for the package?
3. Why is this not already a default/option in the package? I don't mean that in a snarky way, just that it seems widely enough in use that it could be, but perhaps there are specific concerns with the approach that have been discussed.

[James1345]

I can answer (2) and (3):

2. absolutely, more options are always welcome if they're useful and easy to configure
3. Because no-one using the package has needed/wanted to do it that way up to now. The current default is easy to work with regardless of client (browser, mobile app, other services). Cookies are fine in browser and a little more awkward on mobile clients a lot of the time. No objection to having it as an option for people who want it though

Now for (1)
It's been a while since I looked at this code, so I'm not sure. I'd be inclined to try making it a new view of its own (possibly using LoginView as a reference point) and then comparing to LoginView to see how good a fit it is for code-sharing, and only once I'd identified if it was good for sharing or not would I refactor for a shared base or for one to extend the other (Too many messes are caused by people trying to share code that isn't truly the same for both)

Hope this helps :) I keep telling myself I'll find some time for this project soon, others are doing a great job of maintaining it in the meantime though :)

[Luis-Ramirez21x]

I would love to see this solution implemented as well. It would be very useful!

[johnraz]

I would really like to challenge how useful this would be?
Using a regular session cookie in Django would give you pretty much the same result: an encrypted « token » readable only by the server and handling authentication for you, giving you a corresponding « user » on the backend side. The session cookie can also be shared between subdomains of the same main domain… Allowing a cookie to be shared between completely different domains is probably not a good idea security wise anyway, subdomains are fine.
Sessions are designed to be used by browsers and this library IMO is made for server to server or mobile app to server communication, not browser to server.
Maybe I’m missing the point for the browser to server use case (that is not hurting security) and if that’s the case please let me know 😊

[James1345]

Apparently I wasn't thinking when I wrote the answer last time, because I agree with @johnraz - Django already has Session auth if I remember correctly, what is the benefit of adding it to this package?

[Luis-Ramirez21x]

Hey guys! Thank you for the quick replies.

You make a good point, I had gone down the rabbit hole of figuring out what the best way to secure our client side token was and didn't realize I was just replicating the same authentication flow of simply using sessions. So as you suggested rather than hosting our front end and back end on different domains and sharing cookies we'll host on a subdomain.

I hope other people see your answer as I'm finding a lot of other developers attempting to replicate what I was doing.

Thank you so much!

[johnraz]

@James1345 I think we should close this issue and the related PR to make the decision of not doing this kinda final.