CODEWITHSUNDEEP
authenticationjwttoken
reesaspieces
reesaspieces

Reputation: 1810

In token-based authentication, how does the application server know which tokens are valid?

I'm trying to understand cookie vs token-based authentication. I get the basics - cookies have to be stored in the server (as well as the client) to be verified each time, whereas tokens only have to be stored on the client-side. The server simply decodes any incoming tokens and verifies the request.

What I don't understand is, how does the server know whether any decoded token is valid, if a list of valid tokens isn't being stored anywhere in the server?

https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide

  1. User enters their login credentials.
  2. Server verifies the credentials are correct and returns a signed token.
  3. This token is stored client-side, most commonly in local storage - but can be stored in session storage or a cookie as well.
  4. Subsequent requests to the server include this token as an additional Authorization header or through one of the other methods mentioned above.
  5. The server decodes the JWT and if the token is valid processes the request.
  6. Once a user logs out, the token is destroyed client-side, no interaction with the server is necessary.

To be specific - I'd like to know how #5 works. Thank you.

Upvotes: 2

Views: 1805

Answers (1)

Tim Biegeleisen
Tim Biegeleisen

Reputation: 522551

A full answer to your question would be very long, but here is my attempt at a brief one. The server also happens to be the entity which issues the JWT in the first place. As such, it possesses a key which it used to sign each outgoing JWT. As a result of this, when the server receives an incoming JWT, it first tries to open/unlock that JWT using its private key. If the JWT were tampered with in any way, the server might not be able to open it properly, and it would result in an exception. As an example of one sanity check the server would perform against an incoming JWT, it would observe the checksum of the JWT, would not pass in the case of tampering.

Once the server has opened the JWT and deemed it to be valid, the next thing it would likely check would be the exp claim, one of possibly several claims which are contained within the JWT. The exp, or expiry, claim, records for how long the JWT is valid. Should a user present a stale JWT, the server would immediately reject the JWT as being invalid.

So far, we have been discussing checks the server may perform using no state, that is, relying only on the state contained within the JWT itself. In reality, most of the time the server would in fact be storing some state of its own. As an example of why this might be necessary, consider the edge case of a user who logs out of the site or app. In this situation, his phone or browser would still be bearing a JWT with a valid exp expiry. In order to prevent the user from continuing to use this JWT, the server might maintain a blacklist of JWT which it will not honor, even if the exp and checksum pass inspection. So, a third step after unlocking the JWT and checking exp might be to make sure that the JWT does not appear on the blacklist.

A good JWT implementation can limit the amount of server side state to something very small, but typically the server would actually maintain some state of its own.

Upvotes: 3

Related Questions