Zenn
🌐

IETF OAuth WGの仕様全部...じゃなく差分見る - 2022/12

2022/12/25に公開
Authentication
OAuth
IETF
#
authorization
#
spec
tech

ritouです。

Digital Identity技術勉強会 #iddance Advent Calendar 2022 最終日の記事です。

https://qiita.com/advent-calendar/2022/iddance

毎年やってる、いわゆるOAuthの仕様についての差分チェックです。これがないと年越しできないと言われていますよね。

去年からどう変わったんでしょうか。見ていきましょう。

https://zenn.dev/ritou/articles/aa99fabb810cff

仕様のありか

ここです。

https://datatracker.ietf.org/group/oauth/documents/

いつだったか忘れましたが、古臭い感じから今っぽい感じに この画面変わりましたよね。

ちなみに記事は年に一回しか書いてませんが、IETFのMLを追うのも辛いのでたまにここから仕様自体を見てます。

RFCs : 25 -> 27 (←仕様の数)

ここ1年でRFCになったのは2つあります。

  • RFC9278 JWK Thumbprint URI
    • 2022-01-29 に Draft.00 -> RFCへ！
  • RFC9207 OAuth 2.0 Authorization Server Issuer Identification

"RFC9207 OAuth 2.0 Authorization Server Issuer Identification" は去年の説明があるので良いでしょう。OAuth 2.0のAS/RS側から見ると、Clientが複数のAS/RSと連携かつ悪意があるかもしれないみたいな話なので、これをどう捉えるかというところではありますが、自分達の実装などから「うちは大丈夫！」と言いづらい話ではあるでしょう。認可レスポンスの安全性強化というとJARMなどがありますが、そこまでやらずともこの仕様のサポートだけしてみても良いかもしれません。

JSON Web Key(JWK)で表現される鍵情報のハッシュ値を計算する仕様として、RFC7638 JSON Web Key (JWK) Thumbprint 日本語訳 というものがあります。
これをURIな識別子として扱うための表現方法が "RFC9278 JWK Thumbprint URI" で定義されています。サクッとDraftからRFCまで進んでいますが、細かいところを標準化しておかないと同じ目的の値がちょっと違う表現をされたりするのでこういうRFCも大事ですね。

Active Internet-Drafts (9 hits) : 7 -> 9

Dateでソートすると 2022/12/22とか2022/12/29とか...先週ぐらいに新しいDraftが出たものもあるようです。それぞれ見ていきましょう。

RFC Ed Queue

もうRFC直近ってやつです。

JWT Response for OAuth Token Introspection

去年の説明

変わってないですね。

Approved-announcement to be sent::AD Followup

これもだいぶ仕様が煮詰まってきてる段階です。

OAuth 2.0 Rich Authorization Requests

Draft08 -> Draft22 まできました。

去年はこんなの書いてました。

Paymentなどのユースケースにとどまらず、ASの設計時にリソースアクセス要求に対して細かい制御を行いたい時とかの管理にも役立つかもしれません
あとGNAPでもこの表現は使われます

Appendix B. Document History を見てもフィードバックを受けての修正がほとんどなのでこのまま行きそうな雰囲気です。

AD Evaluation::Revised I-D Needed

OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)

Draft04 -> Draft11 まできました。

mTLSよりもアプリレイヤーのSender-Constrained Tokenの仕組みですが、Appendix B. Document History を見ると Draft08 に "Lots of editorial updates from WGLC feedback" とあってその後はリファレンスの更新や表現の修正が多いので大体固まったのかなというところです。

I-D Exists

その他アクティブに策定が進められている仕様です。

BCP系で前からあるやつはまぁいいでしょう。OAuth 2.1も見守る会でウォッチしています。
"OAuth 2.0 Step-up Authentication Challenge Protocol" については解説記事も出ているので理解が捗りますね。

残りの仕様で注目すべきはまずは "Selective Disclosure for JWTs (SD-JWT)" ですね。
去年はリストに挙げられていなかった新しい仕様です。
ユースケースとしては Introduction にもある Verifiable Credentials 文脈の例がわかりやすいでしょう。

  • 登場人物は Issuer / Holder / Verifier
  • Issuer から Holder に Verifiable Credentials が発行される
  • Verifier は Holder に Verifiable Presentation を要求し、Holder は Verifier に提示する
  • Verifier はその値を検証し、自サービスで利用する

という基本的な流れにおいて、JWTをVCとして利用すると

  • Issuer が生成したものを Holder はいじれない(署名をしているのはIssuer)
  • Verifier は Holder が所持しているJWTそのものをもらわないといけない

これはそうですよね。こんな感じではOIDCの認証フローのステップを分割したに過ぎません。
となると、困るのは必要最低限の値だけを使いたいというか、使わなくてはならない制約のある verifier の場合です。
HolderがVerifierにVPを提示するところで verifier が要求している値、さらにユーザーの意思によって開示する情報を選択できるようにするためのJWT拡張がこの仕様で定義されています。

Verifiable Credentialsで実現できるユースケースのキモ(の1つ)であると思いますので、仕様の詳細については別途追っていこうかなと思います。

あともう一つは "Cross-Device Flows: Security Best Current Practice" です。
こちらもざっくり中身を紹介しましょう。
"手元のスマホでなんとか"を利用するユースケース、実現するための仕様がいくつかあることはよく知られているでしょう。

この仕様では、

    1. Cross Device Flow Concepts - ユースケース
    1. Cross-Device Flow Exploits - 脆弱性、攻撃
    1. Cross-Device Protocols and Standards - クロスデバイスでの認証認可を実現するためのプロトコルと標準化仕様
    1. Mitigating Against Cross-Device Flow Attacks - 各種攻撃への対策について
    1. Conclusion - 結論

という流れで、どんな使われ方があるか、静寂性が生まれるところやそれをつく攻撃はどこか、既存のプロトコル/標準化仕様はどんなものがあるか、各種攻撃への対策としてはどんなものがあり、既存のプロトコル/標準化仕様ではどのように考えられているか、それぞれを比較してどうかみたいなところまでが書かれています。

例に挙げられている

  • OAuth 2.0 Device Authorization Grant (RFC8628)
  • OpenID Foundation Client Initiated Back-Channel Authentication (CIBA)
  • FIDO2/WebAuthn

自分もこれまで何度となく記事にしたりしてきましたが、比較となると何を軸にしてみたらいいか悩むところがあります。この仕様では脆弱性や攻撃への対策に注目しながら

  • FIDO2/WebAuthn と OAuth 2.0/OIDC の組み合わせが使えると結構強い
  • FIDO2/WebAuthn 使えない環境などでは CIBA が代替となるが、近接性の強化やトランザクション開始時のところでリスクの軽減策をとる必要がある
  • OAuth 2.0 Device Authorization Grant は色々柔軟で利用するデバイスに対する要件も低いが、デバイス間の未認証時のチャンネル悪用に気をつけて追加の緩和策を導入してから使う必要がある

とか書いてあります。この辺りは今後も説明が追加されそうなので注目しつつ、自分の中でプロトコル選択時に役立てられるようにしておきたいですね。

Recently Expired

去年 Expired になっていた BCP 系仕様が↑のように復活したので最近有効期限切れになったのはなさそうですね。

まとめ

今年もOAuth WGのRFC周りを振り返ってみました。

  • RFCになったのはそれほど大きい仕様ではなかった
  • DPoPなど、RFC間近のものが割とある
  • Verified Credentials 関連である SD-JWT に要注目
  • クロスデバイスのBCPも気になるぞ

といったあたりでしょうか。

アドカレに参加していただいた皆さん、ありがとうございました。

https://qiita.com/advent-calendar/2022/iddance

記事が空いたところは後でなんとかしておきます。また来年やりましょう。

ではまた！

Discussion