MS_JWTAndOAuth2 - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

JWTとOAuth2.0

概要

  • JWTを使う OAuth 2.0 についての纏め。
  • OAuth 2.0 のセキュリティ上の課題を解決し認証での利用を可能にする。

移行メモ: 元ページは「セキュリティ上の解題」となっていたので
「課題」に正した。

詳細

Bearer Token の JWT 化

概要

  • OAuth 2.0 では Access Token まで仕様化されていないので
    JWT アサーションを利用可能。

  • Access Token として、JWT アサーションを使用すれば、
    改ざん、置換、CSRF（XSRF）などを検出できるようになるため、
    Implicit グラント種別でもより安全に利用できるようになる。

  • OpenID Connect の ID トークンに同梱されるクレームを
    同梱させれば、ほぼ安全になり、認証用途にも利用できるようになる。

    • Client や Resource Server で token の署名検証が可能になる。
    • また、発行者の AuthZ Server（iss: issuer）と
      発行対象の Client（aud: audience ＝ クライアント識別子）を特定できる。
    • これにより、トークン置き換え攻撃も防ぐことができる。

  • ポイントは、この Access Token は、ASP.NET Identity などの
    特定テクノロジを使用した Resource Server でなくても利用可能であるという点。

補足（最新化）: 2 点、現在の理解に合わせて補足する。

1. Implicit は使わない。
「JWT 化すれば Implicit でもより安全」というのは当時の緩和策で、
現在は Implicit グラント自体が廃止である
（OAuth 2.1 / RFC 9700）。
JWT にしてもフラグメントに載る以上、
ブラウザ履歴・Referer・拡張機能からの漏えいは避けられない。
代わりに Authorization Code + PKCE を使う。

2. アクセス トークンの JWT 形式は標準化された。
**RFC 9068（JWT Profile for OAuth 2.0 Access Tokens, 2021）**により、
typ: at+jwt や必須クレーム（iss / exp / aud / sub / client_id /
iat / jti）が規定された。
「仕様化されていないので自由」だった状態は解消している。

なお、アクセス トークンをクライアントが解析するのは誤りである
（中身の形式は AuthZ Server と Resource Server の間の取り決め）。
クライアントが知りたいのは ID トークンの側である。

ASP.NET Identity

Microsoft Entra ID（Azure Active Directory）

この方式は、Entra ID の OAuth でも利用されている模様。

参考

クライアント認証

  • JWT bearer token authorization グラント種別

    • Client Credentials グラント種別の代替フロー
    • 強化されたクライアント認証を使用して access_token を取得する。

  • JWT Secured Authorization Request (JAR)
    JAR のリクエスト署名もクライアント認証として機能する。

補足: クライアント認証の方式は次のように整理される
（後ろほど強い）。

方式 内容
client_secret_basic / _post 共有シークレット。漏えいすると詰む
client_secret_jwt シークレットで署名した JWT（HS256）
private_key_jwt 秘密鍵で署名した JWT（RS256/ES256）。シークレットを送らない（RFC 7523）
tls_client_auth / self_signed_tls_client_auth mTLS（RFC 8705）。FAPI で要求される

公開クライアント（SPA・モバイル）はシークレットを持てないため、
クライアント認証を行わず PKCE で代替する。

認可・レスポンス署名

認可リクエストの高度化

  • JAR（前述）
  • OAuth 2.0 Pushed Authorization Requests (PAR)（RFC 9126）
  • OAuth 2.0 Rich Authorization Requests (RAR)（RFC 9396）
    複雑な JSON 構造を持つ authorization_details リクエストパラメタを追加。

移行メモ（元 Wiki 側のリンク切れ）: 元ページは PAR / RAR に
個別ページへのリンクを張っていたが、3 サイトのダンプいずれにも実体が無い
（元 Wiki 側でリンクのみ存在していた）ため、注記に変更し RFC 番号を補った。

補足（JAR と PAR の違い）: 名前が似ているが、目的が違う。

内容 効果
JAR（RFC 9101） パラメタを JWS にまとめて request に入れる 改ざん検知。ただし URL が長くなる
PAR（RFC 9126） 認可要求を事前にバックチャネルで送る。ブラウザには request_uri だけを渡す URL が短くなり、ブラウザにパラメタが載らない

両者は併用でき、
PAR で送ったものを JAR で署名するのが FAPI 2.0 の形である。

RAR（RFC 9396）は scope の限界（文字列 1 つでは
「A 銀行の口座から B へ 1 万円」のような細かい認可を表せない）への回答。

OpenID Connect

参考

Tags: 移行, IT国際標準, 認証基盤, ASP.NET Identity, OAuth

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️