This drives me nuts. To expand on your point, there are a number of separate, debatable design decisions that seem to get conflated all the time:
* Transport: how the session ID or token is shipped between clients and servers (authorization header, cookie headers, or payload).
* Storage: how the session ID or token is stored on clients (cookies, localStorage, sessionStorage, or in memory).
* Statefulness: whether to use a stateless token (with or without a revocation list) or a stateful, server-side session.
* Encryption and/or signing
* Structure/standardization
Examples:
* JWT generates structured, stateless tokens that are signed—and optionally encrypted (JWE)—with the implementor's choice of algorithm. The tokens can be transported and stored by any mechanisms.
* Rack::Session::Cookie (in Ruby) generates unstructured, stateless tokens that are signed—not encrypted—with HMAC. The tokens are transported and stored as cookies.
* Rack::Session::Pool (also in Ruby) maintains an in-memory store of unstructured, stateful sessions. Unsigned and unencrypted session IDs are transported and stored as cookies.
The point being that you can really mix and match. You can even send a session ID in a header and store it as a non-HttpOnly-cookie on the client. Anything goes!
* Transport: how the session ID or token is shipped between clients and servers (authorization header, cookie headers, or payload).
* Storage: how the session ID or token is stored on clients (cookies, localStorage, sessionStorage, or in memory).
* Statefulness: whether to use a stateless token (with or without a revocation list) or a stateful, server-side session.
* Encryption and/or signing
* Structure/standardization
Examples:
* JWT generates structured, stateless tokens that are signed—and optionally encrypted (JWE)—with the implementor's choice of algorithm. The tokens can be transported and stored by any mechanisms.
* Rack::Session::Cookie (in Ruby) generates unstructured, stateless tokens that are signed—not encrypted—with HMAC. The tokens are transported and stored as cookies.
* Rack::Session::Pool (also in Ruby) maintains an in-memory store of unstructured, stateful sessions. Unsigned and unencrypted session IDs are transported and stored as cookies.
The point being that you can really mix and match. You can even send a session ID in a header and store it as a non-HttpOnly-cookie on the client. Anything goes!