MS_OAuth20Tokens

OAuth 2.0 のトークン

• 戻る（OAuth 2.0 拡張）
  • OAuth 2.0 のトークン
  • OAuth 2.0
  • トークン
  • JWT

概要

OAuth 2.0 のトークンには、幾つか種類がある。

詳細

タイプ

以下のタイプがある（詳しくは トークン を参照）。

持参人切符（Bearer）

基本的に OAuth 2.0 の使用の範囲はコチラ
（故に Authorization: Bearer ヘッダを使う）。

記名式切符（送信者制約）

FAPI Part 2（FAPI Part 2 (Read and Write API Security Profile)）や OAuth 2.1 などで、
よりセキュアな実装ではコチラを要求される。

• MAC Token

  • 記名式切符の概念的な先駆で、2012 年〜、標準化されず。
  • Access トークンと共に Message Authentication Code (MAC) キーを発行する。
  • MAC キーは HTTP リクエストの一部分を署名するのに利用される。

• Financial API (FAPI)によって要求された
  OAuth2.0 Proof of Possession

  • OAuth2.0 DPoP
  • OAuth2.0 mTLS（最初）
  • Token Binding（廃止傾向）

補足（最新化：現在の記名式トークン）: 標準化の決着は次のとおり。

仕様	状態	方式
mTLS（RFC 8705, 2020）	標準	TLS クライアント証明書にトークンを束縛。金融系（FAPI）で採用
DPoP（RFC 9449, 2023）	標準	公開鍵を持つクライアントがリクエストごとに署名。証明書不要で SPA / モバイル向け
Token Binding	事実上の終了	ブラウザの実装が撤回された
MAC Token	標準化されず	—

「Bearer は盗まれたら終わり」という弱点への回答が、
現在は **mTLS（サーバー間・高保証）**と
**DPoP（公開クライアント）**の 2 本立てになった、と理解すればよい。

方式

識別子型

• GUID などを発行し、情報自体は、サーバー側のデータ・ストア等に格納しておく方式。
• 問題点としては、AuthZ(N) Server と Resource Server が
  データ・ストアを共有している必要がある。

内包型

• データ・ストアに依存しないように情報をトークンに内包させる。
• その際、
  • 一般的には、JWT（JWS）が使用される。
  • JWT（JWE）を使用すると暗号化されるので、機密性が高い場合は
    コチラを使用（FAPI Part 2（FAPI Part 2 (Read and Write API Security Profile)）の ID トークンなどで使用されている）。

ハイブリッド型

ハイブリッドで実装される。

• 識別子型：機密性の高い情報
• 内包型：一般的な情報

移行メモ: 元ページは「機密性が高い場合は、コチラを仕様」と
なっていたので「使用」に正した。

補足（識別子型 vs 内包型の判断）: 実務上のトレードオフは次のとおり。

	識別子型（opaque）	内包型（JWT）
リソース サーバの検証	AuthZ Server に問い合わせ（Introspection）	自前で署名検証（jwks_uri の公開鍵）
性能	毎回ネットワーク往復	往復不要で速い
即時失効	できる	できない（有効期限まで有効）
情報漏えい	中身が見えない	Base64URL を解けば誰でも読める
サイズ	小さい	大きい（ヘッダ長の上限に注意）

**「即時失効できない」**が内包型の最大の弱点である。
このため、

• アクセス トークンは短命（数分〜1 時間）にする
• 失効はリフレッシュ トークン側（＝識別子型）で管理する

という組み合わせが定石になる（＝上記のハイブリッド型）。

また、JWT を「暗号化していないから安全」と誤解しないこと。
内包型に個人情報を入れると、クライアント側で読めてしまう。

その他

• ID トークン
  OpenID Connectでは認証の意味合いが含まれるように成ったので、
  認証済みであることを証明するために規定されたトークンとその仕様。

• Resource Indicators for OAuth 2.0
  aud や scope を拡張する仕様。

補足: Resource Indicators は **RFC 8707（2020）**として標準化された。
認可要求に resource パラメタを付け、
「このトークンはどの API 向けか」を明示できる。
1 つのトークンがあらゆる API に通ってしまう事態を避けられる
（＝ aud を絞る）。

参考

• OAuth アクセストークンの実装に関する考察 - Qiita
  https://qiita.com/TakahikoKawasaki/items/970548727761f9e02bcd
• RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
  https://datatracker.ietf.org/doc/html/rfc6750
• RFC 9449 - OAuth 2.0 Demonstrating Proof of Possession (DPoP)
  https://datatracker.ietf.org/doc/html/rfc9449

---

Tags: 移行, IT国際標準, 認証基盤, クレームベース認証, OAuth