JWT (Intro to JSON Web Token) is just a token format, authentication it's something completely out of scope for that specification. It is indeed commonly used within authentication systems, but you could also use it for completely different scenarios so it makes sense to not include authentication specific constraints within that specification.
If you're looking for guidance on authentication you should refer to the OpenID Connect family of specifications. Additionally, if your system is comprised of HTTP API's and you're interested in providing delegated access to those API to your own or to third-party client application then you should refer to the OAuth 2.0 specification.
There are additional authentication related protocols like SAML and WS-Federation that are still widely used in enterprise scenarios, but they are significantly more complex to implement.
About your specific open points:
- The bearer token authentication scheme is defined in RFC 6750 which contains instructions on how to perform requests and the possible error codes.
- OAuth2 and OpenID Connect both contemplate the possibility and define the way to exchange a username/password with a token.
- The problem of extending a self-contained/by-value token (JWT) lifetime is addressed within OpenID Connect and OAuth2 through the means of refresh tokens.
Even though OAuth2 and OpenID Connect can be seen as easier to implement than some of its predecessors, they are still complex enough to warrant some caution and only implement them yourself if you're willing to spend a considerable amount of time and resources. It's generally a better option to use third-party libraries or services that do that heavy-lifting for you.
Finally, these protocols cover a lot of scenarios so they may be overkill in some situations.
Best Answer
Cookies are tuples
key-value
originally addressed to retain data related to the client activity. This retention is what we know as session or application state. Fundamentally, they were made for holding the state of web applications; more specifically, the state on the client-side. (1)Cookies are usually set by the server via response headers (
Set-Cookie key=value
). However, they can be set by the client too. For example, by DOM (document.cookie
).One important thing to know about cookies is that they don't identify users. They rather associate the terna data - client - server/path. (3)
We usually associate cookies with files because during the early days of the web browsers they had to persist the cookies somehow, being files the most feasible support. Today's browsers store cookies (among other things) in local storages (embedded DBs).
By session, I guess you mean server sessions. As I commented, sessions can be implemented in the client-side too. The difference with client-side sessions is that the data is stored somewhere on the server-side. (2) In such scenarios, what we get is a session id; and we get it in form of cookie. Without the session id, the server would not be able to correlate the incoming requests with the previous activity of the client. (3) For example, the authenticated user, the shopping cart, etc.
In any case, a session ID doesn't necessarily identify a user. It associates a specific application state with a web client. Sessions might or might not contain user data.
In distributed appllications, the session should be serializable for obvious reasons. If they are stored in memory, the in-memory storage (component) should be serializable. A common solution is to store sessions in files. Or in NoSQL DB like Redis.
Regarding security. Server-side sessions are safer than the client-side. Clients are more vulnerable to threats because users usually are unaware of the so many threats they are exposed to. At least not the regular user.
On the other hand, attacking a server-side infrastructure is not trival.
Not really. JWT stores data mainly related to the authorization and the issuer of the token.
Although they use to contain the user ID (sub), we find JWTs that don't identify authenticated users. For example, tokens for guests sessions. The main content of JWTs are claims; items to be checked by the authorization process.
Is important to keep in mind that JWTs are not global storages. The session or the application state still has to be stored somewhere and managed independently.
Regarding JWTs, these are often stored as cookies, although they can be also stored in local storages. Moreover, OWASP community considers the sessionStorage to be the more secure for web browsers. However, it depends on the version of the browser.
1: The World Wide Web is meant to be stateless. If we want to build stateless server-side applications, sessions should be stored somewhere in the client-side.
2: Turning the server-side application into a stateful application.
3: Client as application, not as user.