Web API is stateless. if we use JWT authentication then we need to maintain user state using JWT token then how we can say that API is restful?

Question

For web api to be rest it should be stateless. if we use JWT authentication then we need to track user with JWT the how we can say that API with JWT token is rest?

Answer 1

For web api to be rest it should be stateless.

Correct.

I'll quote Roy Fielding's paper (emphasis mine):

5.1.3 Stateless

We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.

if we use JWT authentication then we need to track user with JWT

(I assume bv "JWT authentication" you mean a HTTP Authentication scheme using the Bearer scheme with the HTTP Authorization header, where the header's <authorization-parameters> field is the JWT token itself).

When a web-service authenticates and authorizes requests using self-contained bearer-tokens it means the clients have to retain those JWT tokens - not you or your service. The clients will get their JWT tokens from the IdP that your service defers authentication and profile/id info to.

the how we can say that API with JWT token is rest?

Because:

• holding of client tokens is (by default) the responsibility of each client. Ergo, the client holds session state.
• Fielding's paper states "Session state is therefore kept entirely on the client.".
  • ...which is in-line with clients holding (and bearing) their tokens.

Answer 2

Stateless communication means that you store the session (part of the client state) on the client and send it with each request that requires it. In the case of normal sessions the session is stored on the server and only the session id is sent by the client. In the case of JWT you sign the token, because you don't want the client to modify things like user id in it, but the client stores the session data. This is important because of scalability. When you have a few thousand servers and it is random which server gets the request, then maintaining sessions on server side becomes really hard. Either you make a copy of all the sessions on each server and syncing copies becomes a nightmare or you maintain it on a single server which will crash eventually. So better to keep session data on the client and you solve this issue with a little communication overhead.