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

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プロトコルの特徴は、

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

の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記事一覧

Security&Trust フォーラム新着記事

Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。
WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。
Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
　代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する
侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。