Why It Fits
選ぶ理由
- ステートレス(サーバ側に保存不要)
- 署名で改ざん検知
- API/マイクロサービスと相性が良い
Product Profile
トークン形式
「誰が・何ができるか」を署名付き JSON で運ぶトークン形式。OIDC の ID トークンや API 認証で広く使われる。詳しくは Web の [認証](/web/web-auth/) も参照。
Specifications
Introducing
Decision Guide
採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。
Why It Fits
Trade-offs
Deep Dive
JWT(JSON Web Token)は、署名付きで自己完結したトークンです。中身に「誰か」「いつまで有効か」といった情報(クレーム)を持ち、それ全体に署名が付くことで、受け取った側が改ざんを検知できます。
「自己完結」が肝で、トークン自体に必要な情報が入っているため、サーバ側にセッションを保持しなくても検証できます。
JWT は 3 つの部分をドット区切りでつないだ文字列です。
header.payload.signature
- header: 署名アルゴリズムなど
- payload: クレーム(sub, exp など)
- signature: header と payload への署名
受け取った側は署名を検証し、改ざんされていないこと、有効期限内であることを確認します。サーバに問い合わせず手元で検証できるため、ステートレスに扱えます。
サーバ側にセッション情報を持つ伝統的なセッション方式と対照的です。
スケールしやすさと引き換えに、発行後の無効化が難しい、という性質を理解しておく必要があります。
複数のサーバにまたがる API 認可や、サーバ間でセッションを共有したくない構成に向きます。一方で、いったん発行した JWT は有効期限が切れるまで原則として使えてしまい、即時の失効が困難です。
Implementation View
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
API 認証
種別: トークン形式 / 目的: 認証/認可情報の運搬 / トークン/形式: 署名付き JSON
署名で改ざん検知
発行後すぐ失効できない(要設計)
Best Fit