Blog

2019.12.03

IETF106参加記録 - OAuthの未来

こんにちは、本年4月よりレピダムにjoinしましたプログラマの梶原です。

11月16日〜22日に開催されましたIETF 106に参加して来ました。本記事ではその中でも特に今回個人的に注目すべきであると考えるOAuthに関連する2つの新しい動きについて速報します。

IETFについての一般的な記述はIETF 101 Hackathon報告の記事がありますのでそちらをご覧になってください。

TL;DR

2012年にRFC化されたOAuth 2.0は今やインターネット上で広く使われている認可技術のフレームワークですが、その歴史の中で多くの脆弱性が見つかり、対策のために多くの変更がなされました。今やOAuthを取り巻く環境は大きく複雑化しており、OAuthを完全に理解することは非常に困難な道のりとなってしまっています。

OAuthの複雑性に立ち向かうため、IETF 105では OAuth XYZ という、トランザクションを中心にOAuthを整理しなおそう、そのためには互換性の維持を気にせず新しいプロトコルを作る必要がある、という動きが出てきました。今回のIETF 106では既存のOAuthの枠組みを維持したまま複雑性を整理しようという OAuth 2.1 と称する提案がなされ、それに求められるものは何かを議論するサイドミーティングが開かれました。

txauth BoFとOAuth XYZ

前回のIETF 105ではXYZと呼ばれるプロトコルが提案され、今回はXYZとそのコンセプトであるTransactional Authorizationを扱うWorking Groupを形成するためのBoF(Birds-of-a-Feather meeting)が開かれました。

OAuthは複数のユースケースをカバーできる非常に柔軟な認可プロトコルですが、その拡張プロファイル(OpenID Connect, UMA, CIBA, FAPIなど)はそれぞれOAuthをベースに「同じような問題を別々の方法で解決してしまって」いるという現状があります。特に、OAuthはユーザーエージェントとサーバーの間のフロントチャネルの通信に重要な情報を入れて送信するため、フロントチャネルを保護するために多くの方法が考えられてきました(PKCEやToken Bindingなど)。

XYZではこのようなOAuthの複雑性に対処するため、フロントチャネルを可能な限り使わない、クライアントからサーバーへのトランザクションを中心に認可に関連する情報をトランザクションに集約していく、という方法を提案しています。もちろんこのようなコンセプトは通常のOAuthでは実現困難であるため、 OAuth 2.0との互換性を切り捨て、新たなプロトコルを作る というアプローチを取ることにしています。

今回のtxauth BoFではトランザクションで認可機能が整理されることによって生まれる新しいユースケースの提案がなされており、それを例に取るとトランザクションベースの認可のメリットがわかりやすくなると思うので紹介します。例えばホームアシスタントデバイスを通してオンラインショップで購入を行うとき、購入が失敗した、という結果が返ってきたとして、その理由にはカードの失効・残高の不足・商品の情報不足などいろいろな原因がありますが、この問題を解決するためのフローは既存の認可の仕組みではもともとの購入というアクションとは別のものになってしまい、問題を解決したあとにそのまま購入のフローに戻ることができません。失敗時の問題解決後のリトライが難しい問題は特にインターフェースのないデバイスで自動化する際に問題になります。もし別々のトランザクションとみなされる購入リクエストを延々とリトライし続けて、あるとき問題が解決したおかげでそのリトライが全て別々に有効になった場合、本来1つの購入だけを目的としていたハズが、複数の購入が発生することになってしまいます。認可のトランザクションと問題解決のための情報取得のトランザクションが一つにまとまっていれば、これはリトライである、ということをサービス側が理解することができ、複数の購入が発生せずに済みます。

XYZの具体的なフローの解説は本記事では分量の関係から割愛しますが、日本語の記事としては「Transactional Authorization - “XYZ”と呼ばれる認可プロトコルとは」という記事が存在します。

OAuth 2.1

一方で今回提案がなされた”OAuth 2.1”とは、OAuth 2.0のドキュメントの再整理という側面が強い提案です。

背景として、RFC 6749に書かれている内容のうちImplicit FlowとResource Owner Password Credentials FlowはSecurity BCPによって無効になっており(2019年7月時点のInternet-DraftではImplicitはSHOULD NOT、ROPCはMUST NOT)、一番高頻度で使われているAuthorization Code FlowについてもCSRF対策として可能ならばPKCEを用いるようにとされています。さらに、RFC 6749時点では存在しなかったDevice Flowという新規のフローがRFC 8628にて登場しており、OAuthを知りたい、実装したい、という人が参照すべき仕様としてRFC 6749を読んだところでそれだけでは不十分どころか現代的に誤った情報が書かれている、という状態が生まれてしまっています。OAuth 2.1は、これだけ読めば現代のOAuthが理解できる、というドキュメントを目指してOAuthを整理しよう、という取り組みです。

今回の会合ではOAuth 2.1では何を目指すべきか、というサイドミーティングがセッション後に開かれました。その中で議論が分かれた点として、

  • OAuth 2.0から2.1で互換性を保つべきか、breaking changeを許容するべきか否か
    • 2.1といった場合2.0からbreaking changeがないことが期待される
    • implicitとROPCが消えることはライブラリとしてはbreaking changeではないが、AuthCode+PKCEが必須となるのはbreaking changeである
  • どのような成果物を目指すのか?
    • RFC 6749の改定を6749bisという形で目指すのか
    • それとも6749をupdateする/obsoleteする新規のRFCを目指すのか

という点がありました。コミュニティとしてはドキュメント整理の必要性は認識しているがbreaking changeが存在することに対して警戒しているようで、総論賛成各論反対、という様子でした。

おわりに

OAuthコミュニティはOAuth 2.0とその関連RFCの山が複雑化していることは問題であると感じていて何らかの策を講じたいとしているようですが、ここに来て2つの異なるアプローチの提案が出てきたことで、コミュニティのエフォートが分裂することへの懸念も見られています。txauth BoFの参加者はoauth WGと参加者がかなり重なっており、現在のoauth WGもIETFの会合で与えられるセッション枠2つをギリギリまで使って進行中の作業を行うほど作業を抱えているので、既存のOAuth 2.0のメンテナンス、2.1としてのドキュメントの整理、”3.0”としてのXYZ、を同時に進められる体力がワーキンググループにあるのか疑問視する声が出ていました。私見としては、どちらのアプローチにせよOAuthの抱えている複雑性が解決することでOAuthをパッチするための作業が減ることは期待できそうですが、それでも現行のOAuthをパッチされないまま残して新しいものの作業を行うわけにも行かないので、OAuthコミュニティの努力が試される時期がやってきたように思います。


より詳細な話や他のIETFのトピックに関する話はISOC-JPのIETF報告会で話す予定なので、興味のある方はぜひそちらでお会いできればと思います。

【宣伝】レピダムはOpenID Foundation Japan会員企業として、セキュアな認証認可技術の普及と標準化を推進しております。また、その知見を生かした開発やコンサルティングも行っております。