JSON Web Token
JSON Web Token (JWT) is a string composed by the server and stored on the browser that allows client to indicate its identity for further exchanges after authentication (authorization).
JWT base64 string consisting of a header for metadata, a payload for session information, and a signature to ensure that the JWT is not tampered by anyone. The specifics would be covered in the Structure section.
Notably, JWT is compact and self-contained in contrast to traditional session management. It is a way to operate a stateless server. That is, no session information would be stored on the server, as everything is encoded in the JWT. More advatanges will be in the Advantages section.
JWT's main use is for user authorization. More on that in the Authorization section.
Structure
A JWT look something like this
[Base64(HEADER)].[Base64(PAYLOAD)].[Base64(SIGNATURE)]
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9. TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
The header contains the type of the token (JWT) and the algorithm used to sign it. It is encoded in Base64Url. The next two sections is a bit more complicated.
Payload
The payload contains the session information that the server needs, encoded in Base64Url similar to the header.
The payload is composed of claims: statements about an entity and additional data. There are three types of claims.
- Registered claims are sets of predefined, generally useful, but optional claims. This include iss (issuer), exp (expiration time), sub (subject), aud (audience), and others.
- Public claims are stuff defined by us. While not required, the claims should be defined in the IANA JWT registry to avoid collisions.
- Private claims are custom claims to share information between people who uses the token.
Public claims are required to be universally collision resistance, whereas private claims do not.
Signature
The signature of the JWT is used to verify that the JWT is not tampered with.
The signature is produced by putting the header and the payload through a signing algorithm with a secret key.
To check the signature, the process would be repeated once the server receives the JWT. If the signature matches the one on the JWT, then the JWT has not been tampered with. This works because without the secret key, there is no way a malicious user can find the value output by the signing algorithm.
All together
Lastly, the header, the payload, and the signature are concatenated together with periods to form a single Base64 string.
Advantages
JWT has several advantages over other authorization methods.
- Compact: A JWT is very small after being encoded
- Secure: JWT's can use public/private key pairs. I'm not too familiar with this part.
- Usage: A JWT easily maps to an object, making it easy to use in most programming languages.
- Stateless: The state of the user (i.e. session information) is stored within the JWT, not the server. This allows for shared session information between servers.
Authorization
There is no hard rule on how to use JWT tokens for authorization. This is only one of the options.
After authentication (the user logs in), a JWT is returned by the server. When the user wants to access a protected route, they would attach this token in the Authorization header:
Authorization: Bearer <token>
