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

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 Special

- PR -

TechTargetジャパン

Security&Trust フォーラム 新着記事
  • 情報危機管理コンテストで考える――人材は育てるもの? それとも育つもの? (2017/6/21)
    さまざまなセキュリティインシデントに対応する能力をコンテスト形式で鍛える「第12回情報危機管理コンテスト」の決勝戦が、2017年5月25〜27日に和歌山県田辺市で開催された。競技シナリオにもない脆弱(ぜいじゃく)性を見つけたチームあり、意識的に初参加者を加えたチームあり、これまでのコンテストの枠を超えた戦いが繰り広げられた
  • リクルートのCSIRTが、マルウェア対策の一部を内製化した理由 (2017/6/19)
     本連載では、ランサムウェアを含む「マルウェア感染」という、さまざまな企業が頭を悩ませる問題について、リクルートグループのコンピューターインシデント対応チーム「Recruit-CSIRT」の発想と技術をお伝えする
  • 「WannaCry」の次は「SambaCry」? (2017/6/14)
    2017年5月のセキュリティクラスタ、ゴールデンウイークはのんびり過ごせたものの、その後が大変。ワームとして動くランサムウェア「WannaCry」の話題で持ちきりとなりました。騒ぎが落ち着いたと思ったら「SambaCry」が話題に。結局5月末まで、Windowsファイル共有サービスがタイムライン(TL)を賑わしていました。この他、無線LANのタダ乗り無罪判決に対し、総務省が違法だと主張してTL上で意見が飛び交いました。
  • 「WannaCry」にどう対処する、猛威を振るった「ランサムウェア」を知る記事12選 (2017/5/30)
     2017年5月12日からランサムウェア「WannaCry」が大きな話題になった。これをきっかけにランサムウェア対策を講じることになった企業も多いのではないだろうか。本稿では、ランサムウェアに関する記事をピックアップ。今後のセキュリティ対策の参考にしてみてはいかがだろうか
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Security & Trust 記事ランキング

本日 月間
ソリューションFLASH