XYZとXAuthのその後 - "Shadows Over XYZ"

tech

この記事はDigital Identity技術勉強会 #iddance Advent Calendar 2020 第5日目の記事です。そういえばQiitaの個人情報流用騒動のときにアカウント消したのですがアドベントカレンダー専用のアカウントを改めて作り直しました。

はじめに

今年の3月の技術書典応援祭にてサークルCryptic Commandとして"OAuth of the Gatewatch"というタイトルでOAuth Security BCP*1やXYZ*2・XAuth*3を解説する同人誌を書きました。今回の記事では2020年3月以降のOAuth 2.1、XYZ/XAuth改めGNAP(Grant Negotiation and Authorization Protocol)の動向について軽く紹介しようと思います。

なおOAuth of the Gatewatchは諸事情*4により現在は頒布を中止していますが、今後の動向次第では書き直しの上で再リリースする可能性はゼロではないと考えています。

OAuth 2.1, OAuth Security BCP

OAuth of the Gatewatch執筆時点(=IETF 107直前)ではOAuth 2.1はside meetingで触れられた程度だった扱いでしたが、その後3/7にdraft-00が提出され、7/30、つまりIETF 108の後にWorking Group Draftになっています。

OAuth 2.1の目的は文書上

This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749.

とあるように OAuth 2.0(RFC 6749)を置き換える ことと定義されました。RFC 8252, OAuth 2.0 Security Best Current Practice, OAuth 2.0 for Browser-Based AppsでRFC 6749の内容が更新されていることについて言及しており、これらのドキュメントの内容をまとめ(consolidate)、insecureとわかった機能を取り除くことでこれを実現しようとしています。

OAuth 2.0との差分は Differences from OAuth 2.0 (12.) にまとまっています。その内容はまとめると以下のようになります:

  • Authorization Code FlowにおけるPKCEの必須化
  • Redirect URIの比較・検証はexact string matchで行うよう明確化
  • Implicit Flowの削除
  • Resource Owner Password Credentials Flowの削除
  • Bearer Tokenの使い方について、URIのquery string中で用いる用法を削除
  • Refresh Tokenの使い方について、one-time useあるいはsender-constrainedを要求

これを受けてOAuth 2.0 Security Best Current Practiceのdraft-16ではpublic clientでのPKCEがMUSTにするという修正が反映されています。

GNAP(Grant Negotiation and Authorization Procotol)

OAuth 2.1は既存の仕様を更新して置き換えるものであるのに対して、XYZ/XAuthの議論の結果できたGNAP(Grant Negotiation and Authorization Procotol)はOAuth 2の拡張でもOAuth 3でもなくOAuth 2の限界を乗り越えるための新しいプロトコルである、と位置づけられています。

XYZ/XAuth/GNAPの何が嬉しいの

XYZのもともとのコンセプトが"Transactional Authorization"と呼ばれていたことや、XAuthはGrantという要素を操作するREST APIを通して認可を実現するプロトコルであったことからわかるように、XYZ/XAuth/GNAPは認可のプロセスをTransactionやGrantといった要素に束ねることで整理することを大きな目的としています。

アクセストークンを得るまでのリクエスト・レスポンスの集合を一つの要素（つまり一つのIDを通して識別可能な要素）に束ねることで、Authorization Serverがリクエストの対応関係を取り違えることによって発生するAuthorization Code Injectionなどのセキュリティ脆弱性を解決できる、というメリットが生まれます。

また、サーバーがTransaction/Grantの状態を特定のIDに関連付けて保存しておくことが可能になるため、認可に関して追加の情報を他のサイトから得る必要が出た際に、今までのOAuthなどの認可では一度今まで行った認可を中断した上でやり直す必要があったのに対して、他のサイトで情報を得た後該当のIDを利用して認可の手続きを再開することができます（このようなユースケースの詳細はIETF 106の報告会スライドの中で説明しています（28p前後）のでそちらをご参照ください）。

OAuth of the Gatewatch執筆以降の動向

IETF 107の後、Working Groupの形成にあたって名称の決定が行われ*5、XAuthにて用いられていたGrantという用語を取り入れたGNAPという名称が採用されました。IETF 108時点でのWorking Groupのstatus pageには関連するドキュメントとしてXAuthプロトコルの詳細を示したdraft-hardt-gnap-advanced-00とdraft-hardt-gnap-jose-01の2つがありましたが、この時点ではXYZとXAuthのどちらを軸にプロトコルを構成するかは決まっていませんでした*6。

結論からいうと、10月にWGはricher-transactional-authz、つまりXYZをもとにした文書をgnap-core-protocol-00としてWG Documentとして採用します。現在の-02の文章も大筋は-00のままであり、1.1節に示されている用語もXYZの用語の用法がそのまま用いられていることから、XYZ vs XAuthはXYZの勝利に終わった、といえるでしょう。XAuthの関連ドキュメントである人名draftも8月から更新されていない点もこの現状を示唆しているといえます。とはいえXAuthをそのまま捨てることはもちろんしないようで、GNAP WG内にデザインチームが形成され、XAuthとXYZから機能をピックアップしたデザインを目指して文章化を進めており、そのため現在のドキュメントはXYZ・XAuthいずれとも互換性がない、という状態のようです。

これからGNAPの動向を追ってみたい、という方はgnap-core-protocolのInternet-Draftとgnap-core-protocolのGitHubレポジトリを中心に見ていくとよいでしょう。

記事サブタイトルの由来

Magic: the GatheringのOath of the Gatewatchの次のエキスパンションがShadows over Innistradなので（安直）。

*1:執筆時点ではdraft no.は14、リンクは執筆時点最新のものである16

*2:当時の名称。リンクにあるdraft-14ではすでに新名称に変わっている

*3:当時はdraft-02、本記事執筆時点最新はdraft-14

*4:ヒント: Wizards of the Coast社に目をつけられたわけではなくｗ、まえがきのdisclaimerの内容に関連して火を吹いた

*5:命名にあたって「特定の言語でoffensiveな語を使うのは避けたい」の悪い例としてFederation Under Cryptographic Keysという名称を出してきたのには笑った

*6:現時点でsnapshotを持っている理由はここはIETF 108直後のメモを参照して書いているから