3 ms·
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
by blackflame 7y ago
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.
- aaomidi 7y agoAuthenticating JWT isn't checking the JWT against an external server.
- blackflame7000 7y agoHow can you validate that it was properly signed without comparing it to the entity's public key?
- cstrahan 7y agoWhy 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.
- rblatz 7y agoYou could pre share a public key, but a common way is to use the discovery mechanism in OIDC to automatically manage key distribution/rolling.
- blackflame 7y agoBecause else how do you handle key revocation?
- aaomidi 7y agoWhich 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?
- blackflame 7y agoBecause 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.
- altmind 7y agoWhich 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.