- Open-source industry standart (RFC-7519).
- Usable for Authorization or secure exchange of information bretween parties.
- Verify that the sender is who it/he/she claims to be.
- Signed by the issuer, using a secret or keypair (HMAC algorithm, RSA or ECDSA).
Header contains metadata about the token (type, hashing algorithm etc).
Payload contains claims (statements about an entity - for example, a user) and additional data.
Signature is the result of the encoded heade, the encoded payload, signed against a secret.
User "John Doe" signs into our application. We want to create a token with which John can authorize for a while.
We create a payload containing the username and role. We then sign the token with an expiry time of 1 hour. We use a secret for signing.
Payload
{
"username:: "John Doe",
"role: "admin",
"iat" : 1620445606610, // issued at
"exp": 1620445607710, // expires at
}
Secret
We use our payload and secret against a cryptographic algorithm and the result would be a token.
Here the last part i.e. signature
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Signature is the result of header and payload processed against a secret (that only we know).
John Doe sends a request to our API. He wants to delete a task. In the request headers, we can find a JWT token.
To validate his token, we take the headers and payload, and re-generate the signature using our secret.
We then compare the result signature with the signature in his token.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
===
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Signature valid therefore John Doe is who he claims to be
Dohn Joe sends a request to our API, and he wants to access some information that should only be available to admins. In reality, he is a normal user with no admin rights. But DJ is smart. He managed to grab the token and modified the payload!.
Modified Payload
{
"username:: "Dohn Joe",
"role: "admin",
"iat" : 1620445606610, // issued at
"exp": 1620445607710, // expires at
}
DJ is not going to get admin access. We will take header and payload from his fake token, and generate a signature against out secret.
We will then compare the result signature to the signature provided in his token. Since DJ does not know out secret - there is no way he could fake signature as well
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
!==
vX3eLnaHwiZO2ZqqbLMaUOI1dNMKE0wrybh-Xo5DLVw
Signature didn't match so therefore we know DJ is fake
JSON Web Tokens can be decoded by anyone. They should not contain sensitive information such as passwords.
It is useful for font-end applications to use these token to toggle features conditionally. For example, if a user is an administrator, we could show or hide a certain button based on the claims in the token.
Finally - JWTs should ideally be short-lived.