クロスドメインでのデジタルアイデンティティを守る

APIアクセス権を委譲するプロトコル、
OAuthを知る

作島　立樹
NRIパシフィック
2008/1/21

---

　OAuthプロトコルを知る

　OAuthを使ったWeb APIアクセス権の委譲が実際にどのように行われるかはエラン・ハマー氏のブログに詳しいが、簡単に説明すると、2つのアプリケーションをマッシュアップさせたい「ユーザー」が、リソース（例えば、アルバムサイトにある写真など）を管理するサイト「サービスプロバイダ」が提供するAPIの接続許可証「トークン」を、サービスプロバイダを通じて、リソースを利用したサービスを提供する別のサイト（例えば、写真を現像するサイト）「コンシューマ」へ発行し、IDとパスワードの代わりにトークンを渡してサービスプロバイダ上のリソースへアクセスさせる、ということになる。

（1） コンシューマは、APIを通じたユーザーリソースの利用者としてサービスプロバイダへ登録を要求する。【注3】 （2） サービスプロバイダは、コンシューマを表す一意のキーである「コンシューマ・キー」と署名に利用する「コンシューマ・シークレット」をコンシューマに発行する。 【注3】 このステップは、サービスプロバイダとコンシューマの間で一度だけ取り交わす必要がある。必ずしも、オンラインで動的に行われるとは限らず、電話やメールなどの方法でも構わない。コンシューマ・キーとコンシューマ・シークレットを発行して、安全にコンシューマに渡せる方法であれば何でもよい。また、API接続に利用するURLも、APIドキュメンテーションに書いておくなどして、コンシューマに知らせておく必要がある （1） ユーザーはコンシューマのサービスを利用するために、Webブラウザでコンシューマにアクセスする。 （2） コンシューマはユーザーからサービスプロバイダのリソースを利用する意思を確認した後、サービスプロバイダに接続して「リクエスト・トークン」の発行を要求する。この際、コンシューマ・キーや、コンシューマ・シークレットを使って生成したサイン値などをパラメータとして渡す。 （3） サービスプロバイダはコンシューマから送られてきた値を確認した後、未承認の（Unauthorized）リクエスト・トークンをコンシューマに返す。 （4） 未承認のリクエスト・トークンを受け取ったコンシューマは、リクエスト・トークンにユーザーの承認を取るために、未リクエスト・トークンとともにユーザーをサービスプロバイダにリダイレクトする。 （5） サービスプロバイダはまずユーザーにログインを要求し、クレデンシャル（ユーザーIDやパスワードなど）を確認する。ユーザー認証が成功したら、ユーザーにコンシューマがアクセスするユーザーリソースの内容と条件を表示し、同意の確認を促す。 （6） ユーザーの同意が取れたら、リクエスト・トークンを「承認（Authorized）」にして、ユーザーとともにコンシューマへリダイレクトして返す。ユーザーが同意しなかった場合は「拒否（Denied）」にして返す。 （1） コンシューマは承認済みのリクエスト・トークン、コンシューマ・キー、コンシューマ・シークレットで生成したサイン値などをパラメータとしてサービスプロバイダに送って、「アクセス・トークン」の発行を要求する。 （2） サービスプロバイダはコンシューマから送られてきたパラメータの値を確認し、問題がなければ、APIへの接続に必要なアクセス・トークンとそれを署名するのに利用する「トークン・シークレット」をコンシューマに返す。 （3） コンシューマはアクセス・トークン、コンシューマ・キー、トークン・シークレットで生成したサイン値などをパラメータとして送り、ユーザーリソースの入り口であるAPIに接続を要求する。 （4） サービスプロバイダはそれぞれのパラメータの値を確認し、問題がなければ、APIの応答データをコンシューマに返す。以後、サービスプロバイダがアクセス・トークンに付与した条件（リソースの種類・期間など）に応じて、コンシューマは（3）を繰り返してAPIを経由してユーザーのリソースにアクセスする。

図1　OAuthの動作

　OAuthプロトコルの特徴は、

1. APIの接続確認にトークンを使うこと
2. そのトークンはユーザーの同意に基づいてサービスプロバイダからコンシューマへ付与されること

の2点に要約できる。

　トークンは、サービスプロバイダがAPIのアクセス権を確認するのに利用する一意のキー（ランダムに生成された文字列）のことである。コンシューマからの接続要求に応じて、サービスプロバイダからコンシューマへ発行される。トークンを受け取ったコンシューマは自サイトでそれを保管し、APIへ接続する際にトークンをサービスプロバイダへ示すことで、トークンに付与された権限の範囲でAPIへアクセスできるようになる。

　サービスプロバイダがトークンを発行するか否かはユーザーの意思によって決められる。コンシューマはサービスを利用しにきたユーザーをいったんサービスプロバイダへリダイレクトし、サービスプロバイダ上でのユーザー認証を経た後、APIに接続するうえでの条件の確認を行ってもらう。ユーザーが条件に同意すると、今度はサービスプロバイダがトークンとともに、ユーザーをコンシューマへリダイレクトして返す。このリダイレクトを用いてユーザーから同意を取るフローはOpenIDから影響を受けている。

　OAuthを使うと、トークンに対し、APIを通じてアクセスできるリソースの種類や期間などを細かくコントロールできるようになるが、これらをどう行うかについては仕様で定義していない。定義しているのは、APIへの接続内容をサービスプロバイダ側で確認するのに必要なトークンの発行とそのやりとりの方法だけである。また、認証手段に関しても定義していない。サービスプロバイダのIDとパスワードで認証するのが一般的な方法のようだが、より強力な認証手段やOpenIDと組み合わせることも可能である。開発者にとってアクセスコントロールや認証の部分の開発で融通が利く仕様となっている。

2/3

Index
APIアクセス権を委譲するプロトコル、OAuthを知る
	Page1 マッシュアップの犠牲になるユーザーのアイデンティティ TwitterのAPIアクセス権を委譲できないか？
	Page2 OAuthプロトコルを知る
	Page3 プロバイダにとっても大きいOAuthのメリット OAuthのこれから

関連記事
	OpenIDの仕様と技術　連載インデックス
	OpenIDが熱狂的に受け入れられる理由
	OpenIDを使ってみた
	「OpenIDはメアド同様に複数使い分けてもいい」、OpenID提唱者

Security&Trust記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）