本報告では 2009 年上半期のアイデンティティ管理技術に関する動向として、OAuth 仕様の動きを概観する。

2.1 概要

 　OAuth [1] は、Web サイトや非 Web アプリケーション（「コンシューマ」）がWeb サービス（「サービス・プロバイダ」）内のデータやサービス（「リソース」）に対して Web API 経由のアクセスを行う際の、そのアクセスの認証を行うためのプロトコルである。
 　コンシューマとサービス・プロバイダが OAuth に対応することにより、ユーザはコンシューマに対してサービス・プロバイダでのクレデンシャル（ログインID ／パスワードなど）を開示することなく、ユーザのリソースへのアクセスを、コンシューマに許可することができるようになる。
 　ユースケースの一例として、写真共有サイトと写真加工アプリケーションとの間でのデータ共有が挙げられる。前者がサービス・プロバイダ、後者がコンシューマとしてOAuth に対応することにより、ユーザは写真加工アプリケーションに、写真共有サイトでのID ／パスワードを教えることなく、プライベートな写真の取り出しを許可することができる。
 　OAuth仕様は、2007年12月にOAuth Coreバージョン 1.0 が公開された[2] [3]。現在Googleや Yahoo!、MySpace、Twitter などが Web API の認証に採用するなど、大手 Webサービス事業者での対応が進んでいる。

2.2 OAuth Core プロトコル

 　OAuth Core 1.0 プロトコルでは、ユーザによる「サービス・プロバイダ内の自身のリソースへのアクセス権」のコンシューマへの委譲は、以下のように行われる。

ステップ 0：サービス・プロバイダがコンシューマを登録
 　サービス・プロバイダとコンシューマは、事前に双方の間で「コンシューマ・キー」と「コンシューマ・シークレット」を取り決める。コンシューマが以後のリクエストにこれらを用いて署名することで、サービス・プロバイダはコンシューマの真正性を判断できるようになる。


 

ステップ 1：ユーザがワークフローを開始
 　アクセス権委譲のワークフローはユーザが起点となる。開始方法はコンシューマによってまちまちだが、たとえば写真共有サイト（サービス・プロバイダ）のユーザが自身の写真データの取り出しを別の写真加工サイト（コンシューマ）に許可するようなケースでは、ユーザが写真加工サイトにログインし、「写真共有サイトへのアクセス権を写真加工サイトに与えるための手続き」を実行することで、ワークフローが開始される。


 

ステップ 2：コンシューマがリクエスト・トークンを取得
 　コンシューマはサービス・プロバイダ内の「ユーザに関するリソース」へのアクセス権を取得するにあたり、まずサービス・プロバイダに「リクエスト・トークン」を要求し、これを入手する。このリクエスト・トークンは、以後のコンシューマ／サービス・プロバイダ／ユーザの三者間でのやりとりをひもづけるために用いられる。


 

ステップ 3：コンシューマがユーザをサービス・プロバイダに誘導
 　リソースへのアクセス権をユーザから委譲してもらうために、コンシューマはユーザの Web ブラウザをサービス・プロバイダに誘導する。
 　コンシューマがWebサイトの場合には、同サイトがWebブラウザをサービス・プロバイダにリダイレクトさせる。また非 Web アプリケーションのコンシューマでは、同アプリケーションがWebブラウザを起動しユーザをサービス・プロバイダに誘導する一方、自身は待機状態となる。
 　いずれの場合にも、コンシューマはパラメータにリクエスト・トークンを含むリクエストを作成し、それをWeb ブラウザがサービス・プロバイダに送信することになる。


 

ステップ 4：サービス・プロバイダがユーザの同意を確認
 　サービス・プロバイダは Web ブラウザのリクエストからリクエスト・トークンを取得し、どのコンシューマがアクセス権の委譲を要求しているのか（そのリクエスト・トークンは先だってどのコンシューマに払い出したものか）を特定する。
 　そして、ユーザがアクセス権の委譲を許可する立場にいるかどうかを確認するために、ユーザ認証・認可を行う。（ユーザがサービス・プロバイダにまだログインしていない場合には、ここでIDとパスワードの入力を求めるなどして、ユーザを認証する）。
 　ユーザ認証後、サービス・プロバイダはユーザに対し、コンシューマがどのようなアクセス権の委譲を求めているかを示し、許可に同意するかどうかを確認する。


 

ステップ 5：サービス・プロバイダがユーザをコンシューマに誘導
 　ユーザの同意確認後、サービス・プロバイダは、ユーザをコンシューマに誘導する。コンシューマが Web サイトの場合にはそのサイトにWebブラウザをリダイレクトさせ（このときWebブラウザは、リクエスト・トークンをパラメータに含むリクエストをサイトに送信する）、また非 Web アプリケーションの場合には、そのアプリケーションの処理を再開するように促す。


 

ステップ 6：コンシューマがアクセス・トークンを取得
 　ユーザからのリクエストを受け、コンシューマは先ほどまでに取得済みのリクエスト・トークンをサービス・プロバイダに送信する。サービス・プロバイダは、そのリクエスト・トークンに基づく処理ワークフローの中でユーザがアクセス権の委譲を許可したことを認め、リクエスト・トークンとは別の、「アクセス・トークン」をコンシューマに発行する。


 

ステップ 7：コンシューマがアクセス・トークンをもとに API を利用
 　コンシューマはサービス・プロバイダのWeb APIの呼び出しにあたり、アクセス・トークンを含むリクエストを送信する。サービス・プロバイダはアクセス・トークンの有効性を検証し、委譲されたアクセス権の範囲内で、ユーザのリソースへのアクセスを許可する。

 　以上が OAuth Core 1.0 によるアクセス権の委譲処理であるが、今年4月、この処理ワークフローにセキュリティの問題が発見された。

3.1 問題の概要

 　2009年4月23日、OAuthコミュニティは 「2009.1 OAuth Security Advisory」を公開した [4]。同アドバイザリによれば、OAuth Core 1.0を実装したサービス・プロバイダでは、あるユーザのリソースへのアクセス権の委譲を、別のユーザが利用するコンシューマに許可してしまうことが起こりうるという。
 　想定される悪用のパターンは以下の通り。
 　まず攻撃者が善意のコンシューマにアクセスし、先に示した、サービス・プロバイダ内のリソースへのアクセス権の委譲プロセスを開始する。
 　コンシューマはサービス・プロバイダからリクエスト・トークンを取得し、ユーザ（攻撃者）の Web ブラウザをサービス・プロバイダに誘導するべく、サービス・プロバイダへのリダイレクト（リクエスト・トークンを含む）のレスポンスを返却する。
 　攻撃者はこのレスポンスを無視し、ワークフローを中断する。そしてこのリダイレクト（サービス・プロバイダへのリクエスト送信）を、なんらかの方法によって、ターゲットとなるユーザ（犠牲者）に実行させるように試みる。
 　攻撃者が犠牲者を欺くことに成功した場合、犠牲者のWebブラウザは、前に攻撃者が善意のコンシューマ経由で入手した値をリクエスト・トークンとして含むリクエストを、サービス・プロバイダに送信することになる。
 　リクエストを受けたサービス・プロバイダは、ユーザ（犠牲者）にアクセス権の委譲を許可するかどうか確認する。ただし、ここでの犠牲者の同意は、攻撃者がさきほど意図的に中断したプロセス（攻撃者のリクエスト・トークンにひもづく）に対して行われる。
 　犠牲者による許可が行われた後で、攻撃者はこのリクエスト・トークンを善意のコンシューマに提示する。するとコンシューマは、「犠牲者のリソースに対して」アクセス権の委譲が許可されたアクセス・トークンを、サービス・プロバイダから取得することになる。
 　つまり攻撃者は、「サービス・プロバイダ内にある、犠牲者のリソース」と「コンシューマ内にある、攻撃者のアカウント」のひもづけに成功してしまうのである。攻撃者はその後、このコンシューマ内の自身のアカウントを踏み台にして、サービス・プロバイダ内の犠牲者のリソースへアクセスできるようになる。

3.2 原因

 　この OAuth Core 1.0 の脆弱性の原因は、主に2点存在する。
 　ひとつは、サービス・プロバイダにおいてアクセス権の委譲を許可したユーザと、その後のプロセスでコンシューマにアクセス・トークンを取得させるユーザとの同一性が保証されないこと。
 　犠牲者がサービス・プロバイダにおいてアクセス権の委譲を許可し、その後コンシューマにアクセスする前に、攻撃者が先回りすることで、「コンシューマ内の犠牲者のアカウント」ではなく「コンシューマ内の攻撃者のアカウント」が、アクセス・トークンを取得できてしまうのだ。
 　もうひとつは、アクセス権の委譲の同意確認後にサービス・プロバイダがユーザをコンシューマにリダイレクトさせる先（コールバック URL）のすり替えが可能であること。
 　コールバック URL は、コンシューマがサービス・プロバイダにユーザを誘導する際に、パラメータとして指定される値である。攻撃者はこの値をすり替えることで、同意確認後の犠牲者を、攻撃者の都合の良い場所にアクセスさせることができる。そして攻撃者はこの場所へアクセスしてきた犠牲者をとらえることで、 先に示した「先回り」を、より容易に行うことが可能となる。

3.3 対応

 　以上の問題をうけ、OAuth コミュニティは 2009年5月12 日に修正版のImplementer's Draft として「OAuth Core 1.0 Rev A（Draft 3)」を策定し[5]、続く6月 24 日付で正式版となる「OAuth Core 1.0 Revision A」を公開した [6]。本リビジョンでは、当初の OAuth Core 1.0 仕様に対して以下の修正が行われている。
 　まず1点目の問題に関して、サービス・プロバイダとコンシューマとの間でのユーザの同一性を保証するために、「検証コード」が導入された。ユーザがアクセス権の委譲を許可した段階で、サービス・プロバイダは検証コードを生成し、ユーザ経由でコンシューマに送付する。これをコンシューマがアクセス・トークン要求時にサービス・プロバイダに提示することで、サービス・プロバイダにおいてアクセス権の委譲を許可したユーザと、最終的にコンシューマにアクセス・トークンを与えるユーザとが同一であるとみなすことができるようになる。
 　なお検証コードは、コンシューマが Web サイトの場合には、サービス・プロバイダからコンシューマへのリダイレクトの過程でリクエスト・パラメータのひとつとして含まれるため、ユーザはその存在を意識することがない。一方、非Web アプリケーションでは、サービス・プロバイダはユーザの Web ブラウザに検証コードを表示し、それをアプリケーションに入力するよう促すことで、ユーザ経由での検証コードの受渡しが行われる。
 　二点目のコールバック URL については、コンシューマが同パラメータをサービス・プロバイダに提示するステップが、従来のユーザをサービス・プロバイダに誘導する段階から、サービス・プロバイダにリクエスト・トークンを要求する段階に変更された。つまりコールバック URL を、ユーザの Web ブラウザを介さない経路を用いて行うことで、攻撃者によるすり替えが防止できる。
 　以上のセキュリティの問題はOAuth Core 1.0の実装ではなく仕様自体に起因していたため、一時は多くのOAuthサービス・プロバイダが、アクセス権の委譲ワークフローを停止したり、またはユーザに危険であることを警告した上でワークフロー実行を許可するなどの対処を行うこととなった。現在はサービス・プロバイダがOAuth Core 1.0 Revision Aに対応することによって、この問題については解消されている。

 　OAuth 仕様は、現在 IETF（Internet Engineering Task Force）のOAuth Working Groupにて標準化が進められている [7] [8]。草稿段階ではあるが、OAuthプロトコルは「コンシューマからサービス・プロバイダへのリクエストに対する署名方法」と「ユーザによるコンシューマへのアクセス権の委譲ワークフロー」の2パートに分割されたかたちで定義される見込みである。
 　この背景には、ユーザの同意確認方法としてOAuth Coreの委譲ワークフローの代わりに OpenID Authenticationを利用する 「OpenID OAuth Hybrid」[9]や、OAuth を HTTP リクエストへの署名のみに活用し委譲ワークフローは必要としない「2-legged OAuth」[10]など、OAuth の応用が進んできたことがあると考えられる。
 　この他にも Kantara Initiative の User Managed Access Work Group [11] ならびに ID-Web Services Framework（ID-WSF）Evolution Work Group [12]や、OpenID Contract Exchange Extension [13] など、OAuth プロトコルをベースにした、あるいはプロトコルの一部を援用した、新たな仕様策定の動きがある。これらの動向についても、ひきつづき注目していきたい。