5

My understanding is that tokens are signed by server and every time a client makes a request with the token, the server decrypts it to get the user info.

A couple of problems I see about calling this stateless:

1) Is there one private key for all users? If it's different, you are maintaining all the private keys instead of session information.

2) Once the server decrypts the token, lets say the decrypted message is a JSON blob with fields like id,username on it. How will the server know whether or not that id, username exists on their platform without maintaining that in the first place?

Improve this question
  • 1
    One important thing to keep in mind is that the payload is not encrypted, it's just base64 encoded. So you should not store anything sensitive data in jwt. – FINDarkside Jan 27 '18 at 14:05
  • I think this boils down to sloppy use of the word "stateless". Strictly speaking, it is not the token that is stateless, rather the token allows the server to avoid keeping state, so if anything the server (or server application) is stateless - for some type of state, in this case session state. A more precise wording would be "the token allows a server to perform authentication without looking up a session each time". – sleske Oct 17 '18 at 11:30
7

There is only one private key that is used to sign all tokens. So the key itself is not a server state.

Yes, off course you need a database with user data, like ID and username. But having a database to store permanent data does not make you stateful. When we talk about stateless servers, we mean that there is no session state stored on the server. But off course there is still loads of data about users, blog posts, products or whatever.

Also, since the token is signed by the server you do not actually need to check with the database that the user info is correct on every request. The server makes sure the data is correct when it signs the token, and after that the signature verifies it.

Improve this answer
  • So, 1 private key for entire db and 1 signature/user, right? – Abhibandu Kafle Jan 25 '18 at 22:37
  • 1
    One signatue per token you want to sign. Since the token will most likely include an expiration time, over time you will have signed many tokens per user. – Anders Jan 26 '18 at 7:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.