Right now we put the session ID in the URL, which means that if someone shares the URL they are leaking their access (in a scenario where session IDs are handed out only after authentication). This may be undesirable and could be fixed by allowing the session ID to be set in a cookie instead.
The text was updated successfully, but these errors were encountered:
Pushing this off again, but leaving some comments:
I think this should actually be a Bearer token in the auth header, not a cookie
I think we should use standard JWT tokens instead of rolling our own solution
I think also we might want to decouple the session id notion from the token. Currently the session id essentially is the token when it is signed, but I am not sure it makes sense for that to be the case. Maybe it's fine, but if not changing something like that is a 2.0 tasks.
@bryevdv I assume the bearer token has to be stored securely, right? If so, it should probably be placed in a cookie and not in a regular header since cookies are designed to be much more secure.
Why do you think putting it in a header is better?