JWT 的結構：header, payload, signature

Three Parts, Two Dots

A JWT looks like one long random string. It is not random.

Look for the two dots. They split the token into three separate sections: header, payload, and signature.

Each section is encoded separately with base64url. The dots simply join them into one transportable string.

The Header

The header is the smallest part. It describes the token itself.

It usually states the token type and the signing algorithm used to produce the signature.

A verifier reads the header first, because it needs to know which algorithm to check the signature against.

Like the other sections, it is base64url encoded, so anyone can decode and read it.

The Payload

The payload carries the claims: the actual data the token is transporting.

This is the section applications care about most, because it describes who or what the token is about.

It is base64url encoded, exactly like the header.

Encoding is not protection. Decoding the payload requires no key and no secret.

Encoded Is Not Encrypted

This is the mistake that causes real damage.

base64url encoding is a reversible transformation. It exists so binary or awkward characters survive being placed in a URL or header.

Encryption hides content from anyone without a key. Encoding hides nothing.

Treat every value inside a payload as public text.

The Signature

If the payload is readable, what stops someone from editing it?

The signature. It is computed over the encoded header and encoded payload using the algorithm named in the header.

Change a single character in the payload and the recomputed signature no longer matches.

The signature does not keep data secret. It proves the data was not altered.

Each Part's Job

The three sections are not interchangeable. Each answers a different question.

The header answers how was this signed. The payload answers what does it claim. The signature answers was this altered.

Only the third part offers any security guarantee, and that guarantee is integrity, not secrecy.

Putting It To Work

Decode any token you receive. The header and payload will open instantly in any decoder.

Use that habit as a test: if reading the payload aloud would embarrass you, the data does not belong there.

Never place passwords or secrets in a payload.

Trust claims only after the signature verifies.

A JWT payload is secret because it is base64url encoded.

• True
• False

Answer: False

False. Base64url encoding is reversible and requires no key, so anyone can decode and read the payload. Encryption, not encoding, is used to hide content.

In a JWT, the _____ identifies the signing algorithm, the _____ carries claims, and the _____ detects alteration.

Answer: In a JWT, the header identifies the signing algorithm, the payload carries claims, and the signature detects alteration.

The header describes how the token was signed, the payload contains the transported claims, and the signature helps verify that the token was not changed.

An application receives a JWT whose payload contains a user role. What should it do before trusting that role?

• Verify the signature, then use the role claim
• Trust the role because the payload can be decoded
• Trust the role because the header names an algorithm
• Encrypt the decoded payload before using the role

Answer: Verify the signature, then use the role claim

The application should verify the signature using the algorithm identified in the header, then trust the claims only if verification succeeds. Decoding the payload alone does not establish integrity.