Zenn
🌐

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

2023/12/25に公開
Authentication
RSpec
OAuth
IETF
authorization
tech

ritouです。

Digital Identity技術勉強会 #iddance Advent Calendar 2023 シリーズ1の記事です。

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

毎年やってる、いわゆるOAuthの仕様についての差分チェックです。諸々の事情で某カウントダウンコンサートの開催が見送られた今、これがないと年越しできないと言われています。

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

https://zenn.dev/ritou/articles/8d5d142040d6f0

仕様のありか

ここです。

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

まずはRFCになった仕様から。

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

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

DPoP!DPoPじゃないか！最初の頃から注目してきたのでやっとRFCになったかというところです。
Confidential Clientの方はmTLS使えば良いと思うので、Public Clientからどうしてもリソースアクセスしたかったら使えるかなという感じです。

RARについては、RP->IdP->RPみたいなダンスを踊るフローを使って何でもかんでもできるようにした仕様とも言えます。

Step Up AuthenticationなんたらはOIDCの認証コンテキストがOAuthの方に染み出してきた感じですね。OIDCではIDTokenを受け取ってRPが判断する仕組みですが、これはRS(リソースサーバー)側で制限したい時に使える仕様です。そこまで聞いてもピンとこないかもしれませんが、例えばSPAのユースケースならどうでしょう。

  • SPAがRPとなり、バックエンドのIdP相当の機能を提供するAPIから各種トークンを取得する
  • SPAは取得したトークンを使ってRS相当の機能を提供するAPIを叩く
  • このRSの機能では特定の認証方式による認証が必要だったり、認証日時からx分以内であることが必要

みたいなところで利用できそうです。Passkeyによる認証を必須としたメルコインみたいなところ、あとはログイン日時から特定時間が経過したら再認証を要求する設定機能などがユースケースとして考えられます。

ちょっと思ったのが、このStep Up Authenticationなんたらを応用して「この機能を利用するなら追加の身元確認(KYC)が必要」みたいなことにも使えそうな気がします。しかし、そうなるとRP->IdP->RPというフローで身元確認を要求する必要があります。そこでRARを使えるのではないかと。

ということが想像できるぐらいには応用的な仕様ではありますが、FAPIに関わる分野以外でも使い所を考えていきたいですね。

Active Internet-Drafts 9 -> 12

RFC Ed Queue

変わっていないので省略します。

AD Evaluation::Revised I-D Needed

新しい仕様との関連などが差分に含まれていますね。

I-D Exists

  • Selective Disclosure for JWTs (SD-JWT): Draft02 -> Draft07
    • W3C Verifiable Credentials Data Modelにおいて Issuer -> Holder -> Verifier とクレデンシャルが発行、提示される中で "Selective Disclosure" 機能を実現するための仕様
  • Identity Chaining across Trust Domains: Draft00(new)
    • 異なるトラストドメインを超えたリソースアクセスを実現するための仕様
    • RSが別ドメインのClientになったり、ASが別ドメインのClientになったりする
  • Transaction Tokens: Draft00(new)
    • 内部で複数のマイクロサービスによるワークロードが呼び出されるリソースアクセスにおいて、その内部の処理で使うTransaction Tokensの発行、検証方法が定義された仕様
  • OAuth 2.0 Attestation-Based Client Authentication: Draft01(new)
    • クライアントはインスタンスキーっていう非対称の暗号鍵を作成、それを証明する"Client Attestation JWT"をクライアントのバックエンドが作成、それとクライアントが作成したPoP用JWTである "Client Attestation Proof of Possession (PoP) JWT" をくっつけて送ることでクライアント認証をする方法が定義された仕様
  • OAuth 2.0 for Browser-Based Apps: Draft12 -> Draft15
    • これは前からあるSPAみたいなやーつのSecurity BCP。
  • SD-JWT-based Verifiable Credentials (SD-JWT VC): Draft01(new)
    • SD-JWTベースのVCフォーマットが定義された仕様
  • OAuth Status List: Draft00(new)
    • JWT/CWTのステータスリストのデータ構造、そのJWT/CWT表現
  • Cross-Device Flows: Security Best Current Practice: Draft00 -> Draft04
    • 手元のスマホを使ってhogehogeする仕組みのBCP。Device FlowやCIBA、FIDOのHybridフローのようなプロトコルの比較などもあるので個人的に大好きなやつ
  • OAuth 2.0 Protected Resource Metadata: Draft01(new)
    • RSのメタデータの定義
  • The OAuth 2.1 Authorization Framework: Draft07 -> Draft09

新しい仕様(draft-名前-ってのからdraft-ietf-oauth-に変わった)が多いですね。

Verifiable Credentials関連の仕様が動いているのは把握していましたが、それ以外も結構ありました。

"Identity Chaining across Trust Domains"や"Transaction Tokens"なんてのはリソースサーバーがAccessTokenを受け取った後に結構複雑な処理をするときにどうやって実装しよう、みたいなところに刺さりそうです。

"Attestation-Based Client Auth" について、これまでのPublic Clientの諸々を安全にしたかったらDPoPで鍵ペアとトークンをBindさせて...という流れでは強化できていなかったクライアント認証の部分を補う仕様なのでちょっと気になりました。

"Cross-Device Flows" もFIDOとの比較検討みたいなのがあるので興味深いです。どこかで記事にしたい気持ちだけあります。

OAuth 2.1はスクラップを見て貰えばどんな流れで来てるのかは把握できるかと思います。

初めて見たやつを一つずつ見て行ったら疲れたので既存のやつの差分を調べるのを諦めました...まぁいいか。

その他

基本的に "draft-お名前-" みたいなので気になったのは "OAuth 2.0 for First-Party Applications" ですかね。ネイティブアプリからブラウザを立ち上げてWebアプリとして認可サーバーに遷移させるのが正しいのはわかってる、わかってるけど(そもそもネイティブしかないとかで)UXを考慮してネイティブだけでやっちゃうんやみたいな時に参考にできそうです。今後の仕様策定に期待しましょう。

まとめ

今年も年末にIETF OAuth WGの状況を見てみました。

  • RFC間近！ってなっていた仕様がRFCになってた
  • 新しいドラフトが結構たくさん出てきた
  • BCP,OAuth 2.1系も少しずつ更新されているので読んでみよう

みたいなところでしょうか。
是非みなさんの気になる仕様がありましたら動画のコメントなどで教えてくださいどっかで書いてください。

ではまた。

Discussion