JSON Web Token (JWT) is a standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. It literally encrypts the necessary information into a token and uses it.

JWT is emphasized as a signed token. When signing with a public/private key pair, this signature ensures that only the party holding the private key signed the token. In other words, the server holding the key can tell if the token is valid.

JWT Structure

JWT consists of Header, Payload, and Signature.

Each part is Base64 encoded and separated by a dot (.). 

Header

{
    "alg": "HS256",
    "typ": "JWT"

The header contains two key pieces of information: the type of token (typ) and the signing algorithm used (alg). The signing algorithm is used to generate and verify the signature.

The typ is set to "JWT", and alg is written as HMAC, SHA256, etc. As in the example above, it means using the HS256 algorithm with the private key. 

Payload

{
    "sub": "1234567890",
    "name": "John Doe",
    "iat": 1516239022

The payload contains the Claims that you want to transmit in the token. Store user identification information or properties about the token in a key-value format. In other words, you can put anything you want!

The standard specification defines the key names in a compact form with three letters.

Registered claims are as follows. 

• iss (Issuer): Token issuer (includes the issuer's unique identification information)
• sub (Subject): The subject of the token
• aud (Audience): Token recipient
• exp (Expiration Time): Token expiration time (no longer valid after this time)
• nbf (Not Before): Token activation date (the token cannot be used before this time)
• iat (Issued At): Token issuance time
• jti (JWT Id): JWT token identifier (used to distinguish between multiple issuers)

You can add and use additional values if there are any other necessary values. 

However, the payload is not an encrypted signed value, so it does not contain sensitive information.

Anyone can read it by decoding it. jwt.io You can also check it directly on the site.

Signature

HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    your-256-bit-secret

The header and payload are concatenated with a dot (.) after being Base64 encoded, and the server signs it using the private key, your-256-bit-secret. 

Therefore, only the server that issued the token can decrypt the signature using the private key.

To decrypt it, you can decrypt the signature with the private key, and then check if the base64UrlEncode(header) matches the JWT's header value and if the base64UrlEncode(payload) matches. 

The header and payload excluding the signature are only encoded, so you can see the information in the body, but the signature ensures the integrity and security of the information. 

JWT is Self-contained, containing all the necessary information, and it was created to overcome the disadvantages of stateful sessions, so a separate storage is not essential. 

There is no need to maintain sessions on the server side, making it stateless, which increases scalability in distributed systems or microservice architectures. 

It is protected by a signature, a digital signature, and can guarantee data integrity.