A Pre-Review of JSON Web Tokens (JWT)
JSON web tokens (JWT) is a novel method for authentication and sending headers and body.
- It is less about encryption, more about verification.
- Main objective is to ensure that your message is not changed.
- Your header and payload can be decoded (see the example at jwt.io). Avoid sending sensitive information without further precautions.
- Useful to work in a stateless manner.
Parts of JWT
A JWT consists of encoded versions of three parts: Header (red part), Payload (purple part), and Secret (key). Combination of the header+payload with the secret will yield Signature (blue part).
Again, your payload and headers are encoded but not encrypted. “Secret sauce” is the Signature.
How it works
I think a comparative example is the best way to understand how JWT is useful. Suppose you passed authentication with your credentials and you are able to perform operations during your “session”.
In the usual way, your session is stored somewhere (cookie, server etc.). In JWT, your token is your session. Your payload may include about your identification (e.g. user_id) and duration of the token (e.g. expires_at). Your JWT consists of encoded versions of a header, a payload and a signature. This signature is generated in the server using a secret (key).
Since in JWT your payload and header can be decoded you learned that your session ends in 5 minutes. You want to prolong your session, so you changed the parameter to 100 minutes and sent your request to the server. Your request will be denied.
Because, since you changed the payload, you also changed the signature somehow (assuming you don’t know the Secret). On the server side, your message (header and payload) will be encoded with server’s secret. You don’t know about server’s secret key. Therefore, server’s calculated signature will not match your signature.
Above is a very nice flowchart depicting the verifcation process. A JWT is generated with header / payload and signature and sent to client. Client takes the header and payload and generates its own signature. Then, it compares generated (test) signature with the received signature. If they match, then the message is ok.
Where it works
With REST API in a serverless environment, it is a convenient way of authentication. You don’t need to keep the state of authentication(i.e. validity and expiration) in some server or database. You just need to keep a secret and verify all message signatures with that secret.
ps. I’m writing this post to gather my understanding about JWT and to check whether its specifications match with potential use cases. That’s why it is pre-review. Feel free to disabuse my perception.
