JWT：構造、検証、そして侵害を引き起こすミス

问题

3 つのセグメントの内容、署名検証が実際に証明するもの、そして繰り返し発生する失敗パターン（alg 混同、none、有効期限チェックの欠落、安全でない保管）を解説します。

ステップ

1. 1. Anatomy of the three segments

   A JWT is header.payload.signature, each segment Base64URL-encoded. The header names the algorithm (alg) and token type (typ). The payload carries claims: registered ones (iss issuer, sub subject, aud audience, exp expiry in Unix seconds, iat issued-at, nbf not-before) plus whatever your application adds. The signature is computed over the first two segments with the key. All three parts are readable by anyone who holds the token — decoding is not a security event, which is why offline decoders are safe to exist.

2. 2. What verification proves — and what it does not

   Verification recomputes the signature with the key and compares. It proves the token was issued by whoever holds the key and that header+payload were not modified. It does not prove anything inside the payload is true for your context: a valid token for audience A is not valid for audience B, an unexpired token from a revoked session is still cryptographically valid, and claims like role or scope are only as trustworthy as the issuer that wrote them. Verify alg, audience, issuer, and expiry every time — in that order — before reading any claim for authorization decisions.

3. 3. The alg confusion and 'none' attacks

   The alg header is attacker-controlled input. Two historical vulnerabilities remain worth understanding: the 'none' algorithm (a header claiming no signature at all — a verifier that trusts the header accepts forgeries) and algorithm confusion (a token signed with a public RSA key being replayed as HS256, where the public key itself becomes the HMAC secret). The defense is the same in both cases: the verifier pins the expected algorithm and rejects everything else, regardless of what the header claims.

4. 4. HS256 vs RS256 in practice

   HS256 is a symmetric HMAC: the same secret signs and verifies, so every service that can verify tokens can also forge them — acceptable for a single service, risky once tokens are shared across a fleet. RS256 (and ES256) are asymmetric: the issuer keeps the private key, verifiers hold only the public key, so a compromised verifier cannot mint tokens. Asymmetric algorithms also enable JWKS-based key rotation, which is why hosted identity providers default to them.

5. 5. Storage, lifetime, and the practical checklist

   Where a token lives determines its exposure: localStorage is readable by any injected script (XSS turns into session theft), while httpOnly cookies are unreadable to scripts but bring CSRF considerations. Keep access-token lifetimes short (minutes), pair with refresh-token rotation, and include jti plus a server-side denylist when instant revocation matters. The practical checklist: verify signature and pinned algorithm; check exp with clock-skew tolerance; check iss and aud; check nbf if present; and treat every claim as data from the issuer — never as proof by itself.

期待される結果

JWT の 3 つのセグメントをすべてデコードして検査し、アルゴリズムの固定に加えて exp/iss/aud チェックで署名を検証できるようになります。また、典型的な失敗パターン(alg 混同、none アルゴリズム、有効期限チェックの欠落、安全でない保存)を見分けられるようになります。