Claimsを共通形式で運ぶ
iss、sub、aud、expなどの登録済みClaimと、用途固有のClaimをJSONオブジェクトとして表現します。
Overview
この仕様は、
何を解決するのか。
JWTの三つの部分、署名と暗号化の違い、OAuth/OIDCで検証すべきClaimsを整理したい人向けです。JWTは、名前や権限、有効期限といったClaimsをJSONで表し、URLでも扱いやすいコンパクトな文字列として交換する形式です。JWTという名前はトークンの形式を示すものであり、それだけでOAuthのアクセストークンやログインセッションになるわけではありません。
一般的な署名付きJWTはHeader、Payload、Signatureの3部分をピリオドで連結します。Payloadは暗号化されていないため誰でもBase64URLデコードできます。信頼性は秘密性ではなく、JWS署名とClaimsの検証によって確かめます。
Purpose and responsibilities
仕様が定める、大切なこと。
改ざんを検出する
JWSで署名されたJWTでは、HeaderやPayloadが発行後に変更されていないことを受信側が検証できます。
サービス間で検証する
公開鍵署名を利用すると、秘密鍵を持たないResource Serverも発行者の公開鍵でトークンを検証できます。
Key concepts
01Header / Payload / Signature02Registered Claims03iss / sub / aud04exp / nbf / iat05JWS / JWE
Security considerations
安全に使うための確認事項。
仕様を実装するときは、正常系の通信だけでなく、値のすり替え、再利用、漏えいが起きた場合も考えます。
- 01
algをトークン任せにせず、受信側が許可した署名Algorithmだけを受け入れます。
- 02
署名だけでなくiss、aud、exp、nbfと、用途に必要なnonceやscopeも検証します。
- 03
Payloadへパスワードや不要な個人情報を入れません。機密性が必要ならJWEまたは別の安全な保存・通信方法を選びます。
- 04
JWTの用途を分離し、ID TokenをアクセストークンとしてAPIへ送らないようにします。
Interactive flows
この仕様に属するフロー
Position and relationship
ほかの仕様との関係
RFC 7519はClaimsとJWT表現を定義し、実際の署名はJWS、暗号化はJWE、鍵表現はJWKが支えます。OIDCはID TokenをJWTとして定義しますが、OAuthのアクセストークンは必ずJWTであるとは限りません。
Other specifications
OAuth 2.0 (RFC 6749)The OAuth 2.0 Authorization Framework→OAuth 2.0 Device Authorization (RFC 8628)OAuth 2.0 Device Authorization Grant→OAuth 2.1OAuth 2.1 Authorization Framework→OpenID Connect Core 1.0OpenID Connect Core 1.0→FIDO2 WebAuthn Level 3Web Authentication: Public Key Credentials→FIDO2 CTAP 2.2Client to Authenticator Protocol→FIDO UAF 1.1Universal Authentication Framework→FIDO U2F 1.2Universal Second Factor→OpenID Connect CIBA Core 1.0Client-Initiated Backchannel Authentication→OAuth 2.0 PKCE (RFC 7636)Proof Key for Code Exchange by OAuth Public Clients→OAuth 2.0 DPoP (RFC 9449)OAuth 2.0 Demonstrating Proof of Possession→SAML 2.0Security Assertion Markup Language 2.0→SCIM 2.0 (RFC 7644)System for Cross-domain Identity Management: Protocol→