JWTとは？（JSON Web Tokenの仕組みと概念）
JSON Web Token（RFC 7519仕様） — Architectural definition, operational mechanics, real-world examples, security posture, and client-side inspection utilities.
Web Protocols & Security Architecture Research
JWTとは？（JSON Web Tokenの仕組みと概念）
Supporting Architectural Explanation
A JWT consists of three Base64URL-encoded parts delimited by periods: a Header (declaring token type and signing algorithm), a Payload (containing identity claims such as subject `sub`, expiration `exp`, and roles), and a cryptographic Signature (generated via HMAC-SHA256 with a secret key or RSA/ECDSA with a private key).
Because JWTs are self-contained and tamper-evident, receiving servers can verify the token’s validity, authenticity, and expiration locally using public-key cryptography—eliminating the need to query a central database or cache on every single API request.
Key Facts: JSON Web Token（RFC 7519仕様） (JWT)
- A JSON Web Token consists of three base64url-encoded parts separated by periods: Header, Payload, and Signature.
- The Header identifies the token type (JWT) and cryptographic signing algorithm (such as HS256, RS256, or ES256).
- The Payload contains registered claims (sub, exp, iss, aud) and application-specific attributes.
- Base64URL encoding provides transport serialization, not confidentiality; anyone who holds a JWT can read its payload unless it is encrypted via JWE.
- Cryptographic signatures verify data integrity and authenticity; any modification to the header or payload invalidates the signature.
- Because JWTs are self-contained and stateless, instantaneous token revocation requires an external revocation list or short token expiration lifetimes.
How JWT Relates to Other Entities
RFC 7519 standardizes the JSON Web Token format and registered claim definitions.
JWT uses URL-safe Base64URL encoding without trailing padding to ensure safe transmission across HTTP query parameters and headers.
JWTs store verified claims statelessly on the client, whereas sessions store user profile state on a server database or cache.
JSON Web Signatures (JWS) use HMAC symmetric keys or RSA/ECDSA asymmetric key pairs to cryptographically validate claims.
Why does JWT exist?
中央集権的なセッションストレージ（RedisやDB）への高頻度な問い合わせを排除し、マイクロサービスや分散API間で高速かつスケーラブルに認証・認可を行うために考案されました。
Traditional web applications relied on stateful session IDs stored in server RAM or shared Redis databases. In massive distributed microservice architectures, querying a central database for every single inter-service API call created performance bottlenecks and single points of failure.
中央集権的なセッションストレージ（RedisやDB）への高頻度な問い合わせを排除し、マイクロサービスや分散API間で高速かつスケーラブルに認証・認可を行うために考案されました。
How does JWT work?
ヘッダー、ペイロード、署名の3ブロックで構成され、ドットで連結されたBase64URL文字列として通信されます。署名によりデータの改ざんを確実に検知します。
Authentication
User submits credentials to `/auth/login`; authentication server validates identity.
Token Minting
Auth server generates Header and Payload, signs `Base64URL(header) + "." + Base64URL(payload)` using RS256 private key, and outputs 3-part string.
Client Storage & Presentation
Client stores token in an HttpOnly cookie or memory and transmits it via `Authorization: Bearer ...` header.
Stateless Verification
API gateway verifies signature against public key (JWKS) and checks `exp > Date.now()` in 0.1ms without database queries.
How is JWT implemented in code?
// 1. HEADER: Algorithm & Token Type
{
"alg": "RS256",
"typ": "JWT",
"kid": "key-2026-auth"
}
// 2. PAYLOAD: Registered & Custom Identity Claims
{
"sub": "usr_94821034",
"name": "Alex Chen",
"email": "alex@curious-techie.com",
"roles": ["admin", "editor"],
"iat": 1791144000,
"exp": 1791147600,
"iss": "https://auth.curious-techie.com"
}
// 3. SIGNATURE: Cryptographic Verification (Over Header + Payload)
// RSASHA256(
// base64UrlEncode(header) + "." + base64UrlEncode(payload),
// privateKey
// )Architectural Explanation: Three dot-separated Base64URL strings: `eyJhbGciOi... . eyJzdWIiOi... . 5f8aBc...`. The signature guarantees the payload was not modified.
Where is JWT commonly used?
Standard format for OpenID Connect ID Tokens and OAuth 2.0 Bearer Access Tokens.
Transmitting user context and RBAC permissions across dozens of backend internal microservices.
Maintaining offline-first authenticated state with refresh token rotation.
What are the advantages and limitations of JWT?
Core Advantages
Stateless & Highly Scalable
Zero database reads required to verify authentication; scales effortlessly across global clusters.
Compact & URL-Safe
Base64URL encoding ensures tokens can travel safely in HTTP headers, cookies, and query strings.
Cryptographic Integrity
Any modification of claims by the user or an attacker invalidates the cryptographic signature immediately.
Architectural Limitations
Difficult Instant Revocation
Because tokens are stateless, revoking a compromised token before its expiration requires maintaining a token denylist or Redis cache.
Token Size Overhead
JWTs are larger than simple 32-character session IDs, adding 500-1500 bytes to every HTTP request header.
Can JWT introduce security vulnerabilities?
Algorithm Confusion ("none" algorithm / HMAC-RSA confusion)
Attacker sets `"alg": "none"` or verifies RSA public keys using HMAC to forge arbitrary administrator tokens.
Hardcode explicit allowed algorithms in verification libraries (`algorithms: ['RS256']`).
Token Theft via XSS in localStorage
Storing JWTs in browser localStorage allows any injected script to steal the token.
Store sensitive JWTs in `HttpOnly; Secure; SameSite=Lax` cookies.
What are common misconceptions about JWT?
JWTs are signed, NOT encrypted! Base64URL is simple encoding. Anyone with the token can decode and read the JSON payload.
Decoding merely reads the plaintext JSON; verification cryptographically recalculates the signature using the secret or public key.
Frequently Asked Questions About JWT
Q:How do you revoke a JWT before it expires?
For immediate revocation, an in-memory Redis token revocation list (denylist) checking token JTI (unique ID) can be implemented.
12. Related Interactive Tools
Inspect, test, and verify this protocol directly in your browser with 100% private client-side execution:
13. Related Comprehensive Guides
関連技術エコシステムと次の学習ステップ
関連する技術Q&A
Can a JWT Be Decrypted by Anyone?
Answer: Yes, standard JSON Web Tokens (JWS) are signed, not encrypted. Anyone can decode and inspect the payload without the secret key.
Why Shouldn't You Store JWTs in LocalStorage?
Answer: Storing tokens in localStorage exposes them to instant exfiltration by any Cross-Site Scripting (XSS) vulnerability.
Can an Expired JWT Token Still Be Verified?
Answer: Yes, the cryptographic signature remains mathematically valid, but compliant libraries reject the token because exp is checked after signature verification.
開発者向け規格・仕様リファレンス
次のステップへ進む
JWT Interactive Tampering & Validation Lab
Put your theoretical understanding into practice by tampering with claims and testing signature rejection in the live sandbox.
References & Primary Sources
Every source below directly substantiates technical statements and protocol behaviors explained in JSON Web Token（RFC 7519仕様） (JWT). Curious-Techie prioritizes official Internet standards (IETF RFCs, W3C Recommendations, WHATWG specifications) and established security bodies (OWASP, NIST). Zero sponsored or secondary links.
- [1]IETFPrimary SpecificationRFC 7519 • Section 3 & 4Verified Primary SourceTechnical Claim Supported:
Defines the compact, URL-safe format of JSON Web Tokens consisting of three Base64URL segments (Header, Payload, Signature) and registered claims (iss, sub, aud, exp, nbf, iat, jti).
“A JWT is represented as the concatenation of the Encoded JWT Header, the Encoded JWT Claims Set, and the Encoded JWT Signature or Encoded JWT Encryption Data, with the parts being separated by period ('.') characters.”Source URI: https://datatracker.ietf.org/doc/html/rfc7519 - [2]IETFPrimary SpecificationRFC 7515 • Section 4 (Cryptographic Signatures)Verified Primary SourceTechnical Claim Supported:
Defines digital signatures and MAC algorithms (HS256, RS256, ES256) used to secure JWT integrity and verify token authorship.
Source URI: https://datatracker.ietf.org/doc/html/rfc7515 - [3]IETFAuthoritative Security StandardRFC 8725 • Security Considerations § 3Verified Primary SourceTechnical Claim Supported:
Mandates explicit algorithm validation on receiving servers, prohibiting the insecure "alg: none" algorithm and enforcing strict signature verification.
Source URI: https://datatracker.ietf.org/doc/html/rfc8725 - [4]OWASPAuthoritative Security StandardOWASP Cheat Sheet Series • Token Storage & RevocationVerified Primary SourceTechnical Claim Supported:
Details token theft mitigation, recommending storage in secure HttpOnly cookies over localStorage and outlining token revocation strategies.