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?
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.
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
First of all, what you described in this question is a session management, not token management.
SessionIds are generated by business system itself. The workflow is same as your question.
While tokens are usually generated and managed by an independent system, not the business system. When client sent subsequent calls to the business server after it had got a token already, the business server had to validate the token from the token system. So when we talk about the business system, we say it is stateless.
Additionally, in my point of view, token is not born to handle authentication, it is designed to keep important information secure.