Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why are authentication tokens considered stateless and sessions not?

In the case of an authentication token the client sends the credentials, receives a token and uses this in all subsequent calls. The server needs to save the token in order to validate the requests.

With for example PHP sessions the server returns a session UID which the client sends in every request. The server needs to save the session.

In both cases the server needs to save a state so why is the former considered stateless?

like image 988
user2906759 Avatar asked Nov 07 '13 15:11

user2906759


People also ask

Why are tokens stateless?

Stateless Authentication is a way to verify users by having much of the session information such as user properties stored on the client side. It makes identify verification with the backend seamless. Also called token-based authentication, stateless authentication is efficient, scalable, and interoperable.

Is session-based authentication stateless?

Session-based authentication is stateful. This means that an authentication record or session must be kept both server and client-side. The backend keeps track of the active sessions in a database, while on the front-end a cookie is created that holds a session identifier.

What is the difference between session authentication and token authentication?

The main difference is session-based authentication of the connection stores the authentication details. The session method makes the server store most of the details, while in the case of the token-based one the client stores them.

Why is JWT token stateless?

Because the user receives a JWT after a successful login, which contains all important information about the user. This means that the session no longer has to be saved on the server and is therefore also called a stateless session.


2 Answers

Semantics. A session is generally implemented by assigning each user a unique ID and storing that ID in a client-side cookie. The auth token would be EXACTLY the same thing - a unique per-user ID of some sort. Cookies are sent back on every request automatically by the browser, and the auth token CAN be sent back on every request, but generally should be sent only on the requests that actually require authentication.

The difference has to do with how those tokens are treated on the server. The session ID is used to load up a corresponding session from storage (e.g. a file, a db record, whatever), and that session data will be persisted between requests.

An auth token doesn't have any associated session file. It's more just a "I'm allowed to be here, and here's the proof".

There's no reason a session ID can't be used to implement the authentication system. Even a simple $_SESSION['logged_in'] = true would turn the session into an authentication system.

like image 187
Marc B Avatar answered Oct 12 '22 23:10

Marc B


If the expectation is that the client will always send an authentication token for every request, the server actually doesn't need to save state. It has everything it needs in the message to determine how to evaluate the request.

Certain server architectures (I'm thinking Java servlets, specifically) are required to return a session cookie, but they aren't required to use it when it's passed back to them on the next request. In my stateless servlet application, a different cookie representing the JSESSIONID is returned for every response. So, in this case, it's just background noise.

Most sessions are stateful for two reasons:

  • the identifier passed by the client can't be parsed into a meaningful set of credentials without having had previous server interaction (they are usually just a random value assigned by the server)
  • the identifier has an implicit lifespan that isn't discoverable within the identifier
like image 35
Jonathan W Avatar answered Oct 12 '22 23:10

Jonathan W