CODEWITHSUNDEEP
restwebtoken
user3844028
user3844028

Reputation:

Why are tokens considered stateless?

So I have kind of an issue to understand why "tokens" have so much hype in the differents new web technologies for authentication.

I understand it's meant to improve the controls you can "lose" when using cookies and session. But a lot of people are talking about the fact that it sticks to the Restful "ideology" by allowing a client-server communication to be Stateless.

But... does it ? I mean, a stateless communication means that the server doesn't have to store any informations on the client for auth, and that requests are 100% independent from one to another.

In the case of tokens :

So to me, tokens are nothing close to what we could call a "stateless" communication (which is a necessary condition for a architecture to be Restful).

By the way, I think HTTP credentials are closer to achieve a stateless communication, because basically, even if the server still have a state by storing the credentials, the auth+request process rely on only one single request, (as credentials are full part of the very first request of an HTTP "conversation").

One other point HTTP credentials hit better than tokens is the "Client/server roles" in Restful API. This point states that a RESTFul communication split client and server, meaning inter alia that the client doesn't have to deal with data storage. But in the case of token, they definitely needs to be stored, at least temporarily (and even more if (for example) you want the browser to keep the token after a restart by using cookies or localstorage). In contrast, HTTP cred can be filled in by the user at every request of a conversation making the client non-data-storing just as it should be in Restful representation.

Also I wanted to point out that according to Rest architecture, any information held by the client should on it's own be enough for the client to decide whether or not he should delete/modify it, which is not the case with 99% of tokens system that doesn't make the client store tokens' timeout date (where cookies does).

So in conclusion, a lot of people are blaming HTTP creds or session for violating the Restfulness of an architecture. But tokens systems doesn't solve the issue at all, does it ?

Upvotes: 2

Views: 2730

Answers (1)

SilverlightFox
SilverlightFox

Reputation: 33588

As noted in your comments, I am assuming you are referring to jwt.io.

Server obviously needs to store those ( just as the client in most cases of applications if you want to keep token over restart) so, both client and server does have a states.

There is no requirement for the server to store any state. Even the default example on jwt.io demonstrates this:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

Using the JSON Web Token this information is signed and stored on the client. The information cannot be changed without knowing the secret, so in this design it is considered secure provided a "strong enough" secret key is used.

This is why it can be considered stateless. As you mentioned, the client does need to store the token and therefore carries state. However, the server does not, meaning the implementation on the server side can be considered stateless.

Upvotes: 3

Related Questions