Hacker News Reader

Comment by blackflame | Hacker News Reader

You always have to authenticate the JWT anyways to verify data hasn't been changed. The stateless part is the fact that the sensitive data is stored in the JWT itself instead of retrieved from a DB. As long as you can validate the HMAC / Signature then you can assume the contents of the JWT haven't been altered and can therefore trust the client's data.

View on HN

Authenticating JWT isn't checking the JWT against an external server.

How can you validate that it was properly signed without comparing it to the entity's public key?

Why would you need to make a request to another server for this purpose?

Hint: you don’t — but I figure taking the Socratic approach may be more convincing.

You could pre share a public key, but a common way is to use the discovery mechanism in OIDC to automatically manage key distribution/rolling.

Because else how do you handle key revocation?

Which is the point of the post.

If you need to do revocation you need to call an external server.

If you need to call an external server why do JWT?

Because pinging another server for a few bytes of data and offloading that working memory to the client side is much more efficient than storing the session data in server memory in between requests. Furthermore a single coordinating key server can work in conjunction with many micro-services to simplify architecture, security, and hardware requirements.

Which still leaves a window for JWT to be re-played. If you store something valuable, like # of credits left on a users account, the user can spend some, and then re-use an old jwt to spend again.

Reply on news.ycombinator.com