Session Authentication

[paribaker]

In this version of the bootstrapper Session Authentication is enabled by default. With session authentication enabled the default DRF user token is not necessary for api calls, in order to remove the session token you must call the backend. Is there a reason to keep both? Should we prefer one over the other?
I bring this up because it creates conflicts when a SU or Staff member logs in to the admin panel and then tries to login to the client side, in some apps that are leveraging a separate Authentication (JWT) the session is never cleared and this causes confusion when a user switches to the client side.

[paribaker]

One thing that comes to mind about sessions and their utility is for user tracking and analytics. Often when we are integrating GA or NR, Sentry etc we see sessions being logged to track user journeys.

[oudeismetis]

I think we might have kept both, if I'm remembering correctly, to help with debugging via the Swagger docs. Without token auth you wouldn't be able to click the "test" button and interact with the API there. I might be wrong about that though. I do seem to recall there was some specific reason for having both.

[whusterj]

I think it makes sense to maintain both, while figuring out how to address the auth conflict you mentioned. Token-based auth has a lot of merits, if ever an app needs to open up its API.

But we're definitely not using token-based auth in the "best" way. It's more of a convenience, because its statelessness makes it easier to implement and test than sessions. We're not playing to its strengths, e.g. having different tokens with limited permissions. Right now, tokens are one-to-one with users and don't expire. That's a pretty severe security issue.

I suggest we start small by addressing the auth conflict in the Django admin. I think the issue is that after login, our FE code is saving the token but not updating the session cookie / invalidating any existing session in the browser. I believe even REST calls should be returning updated session cookies, and the FE code needs to handle that better to resolve the conflict.