JWTアクセストークンとIDトークンは誰が何のために必要としているのか

JWTアクセストークンとIDトークンは誰が何のために必要としているのか産業⽀援グループ fannaly事業部 / fannaly auth エンジニア宮部侑弥

⾃⼰紹介宮部侑弥クラスメソッド株式会社 fannaly事業部 fannaly auth エンジニア認証基盤の開発に従事 2

どっちがどのトークンの中⾝？ A B ヘッダヘッダ { "alg": "RS256", "typ": "JWT"
} { "alg": "RS256", "typ": "at+jwt" } ペイロードペイロード { { "iss": "https://as.example.com", "sub": "5ba552d67", "aud": "s6BhdRkqt3", "exp": 1639528912, "iat": 1618354090, "jti": "9f8e7d6c5b4a", "nonce": "n-0S6_WzA2Mj" "iss": "https://as.example.com", "sub": "5ba552d67", "aud": "https://api.example.com", "client_id": "s6BhdRkqt3", "exp": 1639528912, "iat": 1618354090, "jti": "9f8e7d6c5b4a", "scope": "orders:read" } } ▪ アクセストークンとIDトークンのJWTをデコードした際のヘッダとペイロード 3

仕様⾃⾝が「似ている」と⾔っている The JWT access token data layout described here is
very similar to that of the id_token as deﬁned by [OpenID.Core]. RFC 9068 Section 5 https://www.rfc-editor.org/rfc/rfc9068#section-5 アクセストークンが JWT なのは仕様の要求ではない OAuth 2.0 はアクセストークンの形式を何も決めていない。⼀般的なのはopaqueとJWT。 RFC 6749 Section 1.4 https://www.rfc-editor.org/rfc/rfc6749#section-1.4 4

JWTにする利点有効？誰の？どのスコープ？アクセストークン（opaque）クライアントリソースサーバー認可サーバーイントロスペクション
有効期限‧スコープアクセストークン（JWT）クライアントリソースサーバー署名を検証して中を読む ✕ 認可サーバー問い合わせが不要（イントロスペクション） JWTにすることで認可サーバーを介す必要がなくなる RFC 9068 Section 1 https://www.rfc-editor.org/rfc/rfc9068#section-1 5

audが違う場合がある IDトークンアクセストークンヘッダヘッダ { "alg": "RS256", "typ": "JWT"
} { "alg": "RS256", "typ": "at+jwt" } ペイロードペイロード { { "iss": "https://as.example.com", "sub": "5ba552d67", "aud": "s6BhdRkqt3", "exp": 1639528912, "iat": 1618354090, "nonce": "n-0S6_WzA2Mj" "iss": "https://as.example.com", "sub": "5ba552d67", "aud": "https://api.example.com", "client_id": "s6BhdRkqt3", "exp": 1639528912, "iat": 1618354090, "jti": "9f8e7d6c5b4a", "scope": "orders:read" } } IDトークンの aud → クライアントID アクセストークンの aud → リソースサーバーの識別⼦ 6

audが違うということは宛先が違う IDトークン認可サーバークライアントリソースサーバーアクセストークン • IDトークンクライアントが受け取り、読むのもクライアント •
アクセストークンクライアントが受け取り、読むのはリソースサーバー 7

クライアントは読まずに送るだけ The client MUST NOT inspect the content of the
access token RFC 9068 Section 6 https://www.rfc-editor.org/rfc/rfc9068#section-6 中⾝を⾒ずにリソースサーバーへ送る Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6ImF0K2p3dCJ9.eyJpc3Mi… 個⼈情報が⼊っていることもあり読んでログや画⾯に出せば漏えいになる中⾝を⾒て検証するのは受け取ったリソースサーバーの役割 8

トークンを受け取った側はどう⾒分ける？ IDトークン保護は緩いことが多い認可サーバー JWKS リソースサーバー公開されている署名鍵署名検証 OK アクセストークン
リソースサーバー署名検証が通るだけで受け⼊れると、IDトークンも受け⼊れてしまう認可サーバー id_token_hint にアクセストークンを⼊れられても同様 9

typ ヘッダで⾒分ける IDトークン { "alg": "RS256", "typ": "JWT" } アクセストークン
{ "alg": "RS256", "typ": "at+jwt" } The resource server MUST verify that the "typ" header value is "at+jwt" or "application/at+jwt" and reject tokens carrying any other value. RFC 9068 Section 4 https://www.rfc-editor.org/rfc/rfc9068#section-4 署名が通ったかどうかと、それが何のトークンなのかは、別の話 10

typ は絶対にあるのか RFC 9068 は 2021年10⽉発⾏。OAuth 2.0（RFC 6749, 2012年10⽉）から9年後にできた⽐較的新しい仕様 Microsoft
Entra ID アクセストークンの typ は常に JWT Okta（カスタム認可サーバー）アクセストークンに typ が付かない Auth0 デフォルトは JWT。RFC 9068 プロファイルを選んだときだけ at+jwt IDトークン OpenID Connect Core は typ を定めていない（歴史的にJWTの場合が多い）各社の公式ドキュメント（2026年10⽉時点）。URL は参考⽂献に記載 typ に頼れないときは、検証ルールを排他的にする If more than one kind of JWT can be issued by the same issuer, the validation rules for those JWTs MUST be written such that they are mutually exclusive, rejecting JWTs of the wrong kind. 例: aud が⾃分の識別⼦か、⽚⽅のトークンにしか存在しないクレームがあるか RFC 8725 Section 3.12 https://www.rfc-editor.org/rfc/rfc8725#section-3.12 11

⽚⽅にしか存在しないクレームとは Q. 認可のためのアクセストークンなら認証情報はないのでは？ A. ないとは⾔い切れない auth_time OPTIONAL - as defined
in Section 2 of [OpenID.Core]. acr OPTIONAL - as defined in Section 2 of [OpenID.Core]. amr OPTIONAL - as defined in Section 2 of [OpenID.Core]. RFC 9068 Section 2 https://www.rfc-editor.org/rfc/rfc9068#section-2 クレームで区別するための標準仕様はない IDトークンは OIDC Discovery で claims_supported が公開されているアクセストークンにはそれに相当する仕様がない各サービスの公開資料等で⾒⽐べる OpenID Connect Discovery 1.0 https://openid.net/specs/openid-connect-discovery-1_0.html 12

まとめ IDトークンアクセストークンヘッダ { "alg": "RS256", "typ": "JWT" }
ヘッダ { "alg": "RS256", "typ": "at+jwt" } ペイロード { "iss": "https://as.example.com", "sub": "5ba552d67", "aud": "s6BhdRkqt3", "exp": 1639528912, "iat": 1618354090, "nonce": "n-0S6_WzA2Mj" } ペイロード { "iss": "https://as.example.com", "sub": "5ba552d67", "aud": "https://api.example.com", "client_id": "s6BhdRkqt3", "exp": 1639528912, "iat": 1618354090, "jti": "9f8e7d6c5b4a", "scope": "orders:read" } 似た⾒た⽬の JWT でも宛先が違うクライアントは読まずに渡すし受け取った側は typ、無ければ aud や⽚⽅にしかないクレームで判別できる 13

参考⽂献 RFC 9068 JWT Profile for OAuth 2.0 Access Tokens
Microsoft Entra ID Access token claims reference https://www.rfc-editor.org/rfc/rfc9068 https://learn.microsoft.com/en-us/entra/identity-platform/access-token-clai ms-reference RFC 6749 The OAuth 2.0 Authorization Framework https://www.rfc-editor.org/rfc/rfc6749 Okta The typ field is missing from the access token header RFC 7662 OAuth 2.0 Token Introspection https://support.okta.com/help/s/article/the-typ-field-is-missing-from-the-ac cess-token-header https://www.rfc-editor.org/rfc/rfc7662 RFC 8725 JSON Web Token Best Current Practices https://www.rfc-editor.org/rfc/rfc8725 Auth0 Access Token Profiles https://auth0.com/docs/secure/tokens/access-tokens/access-token-profiles OpenID Connect Core 1.0 https://openid.net/specs/openid-connect-core-1_0.html OpenID Connect Discovery 1.0 https://openid.net/specs/openid-connect-discovery-1_0.html 14

JWTアクセストークンとIDトークンは誰が何のために必要としているのか

JWTアクセストークンとIDトークンは誰が何のために必要としているのか

miyabe.yuya

Featured

Transcript