Switch authentication from cookies to another mechanism

[mgwalker]

3rd-party cookies are becoming increasingly difficult to work with, and Chrome seems intent on killing them entirely if at all possible. Rather than keep working around these issues with cookies, we should switch to a different mechanism. It's a bit more work, but it'll pay off in not having to fight these cookie fires over and over.

This task is done when...

• we've picked a different approach
  • my initial thought is to take the token we're currently putting in the cookie and instead send it back and have subsequent requests put it in the Authorization header, similar to a bearer token
• implemented
• documentation is updated

[radavis]

Breaking this task up a bit...

Back-end

• turn off passport sessions
• add jwt passport authentication strategy
• add update serializeUser and deserializeUser functions
• successful POST /auth/login returns jwt in json response
• ensure other paths are locked down

Front-end

• after sign in, store jwt in local storage (or redux)
• pass jwt in the authorization header with each request

examples

[mgwalker]

This looks good! I wish I'd known about passport's JWT strategy in the first place! I only have two comments:

1. We can't turn off sessions entirely. Without a server-side component, we can't satisfy some of the NIST requirements in order to get an Authority to Operate (ATO).
   • Without a session on the server side, users would log out by throwing away their JWT. However, if a 3rd-party had intercepted their JWT, it would still be valid until it expired. Having server-side sessions allows a complete logout. (AC-12). We manage this now by putting the session ID into the JWT and using the session ID to look up the user ID. On logout, we remove the session ID from the database.
   • We couldn't enforce a limit on the total number of active sessions for a single user (AC-10 - may not apply since we're calling ourselves a moderate system; see also Define the number of allowed concurrent sessions #1509)
   • We can't allow administrators to forcibly log users out. (I think there's a NIST control for this, but I can't find it now... maybe I'm just dreaming. 🤷‍♂)
2. I think I'd lean towards storing the token in local storage rather than Redux since, presumably, only the API wrapper would ever need it. But that's just a gut response.

[radavis]

Ah, cool. Thanks for looking and for this helpful info.