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

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

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

マッシュアップと呼ばれる仕組みで、既存のWebサービスが次々とつながり、新たなサービスが登場している。しかし、メールアドレスなど重要な個人情報が意図せずに「つながれてしまう」可能性もある。そこで登場したのがアクセス権の「委譲」を目的としたプロトコル、OAuthである。本記事ではOAuthの仕組みとともに、なぜそれが登場したのかという背景にも触れる（編集部）

　マッシュアップの犠牲になるユーザーのアイデンティティ

　GETなどのHTTPメソッドをもちいてURLへリクエストする、いわゆる「RESTful」【注1】なWeb APIを使ったアプリケーション同士の交流は、いままさに隆盛を極めている。「マッシュアップ」と呼ばれているこのサービス形態が、これからのWebアプリケーションの発展の方向を決めるのは間違いなさそうだ。しかし、1つ気掛かりなことがある。アプリケーションの間でやりとりされるユーザーの「デジタルアイデンティティ」の扱いが今後どうなるか、ということだ。

　現在、マッシュアップされた2つのアプリケーションを利用する際、「アプリA」のユーザーIDとパスワードを、アプリAにある情報にアクセスしたい「アプリB」に丸ごと預けてしまうような実装や運用が平気で行われていたりする。たしかにクレデンシャル（アプリAのIDとパスワードのこと）を、サービスを実施するためにアプリAの情報を必要とするアプリBに預けるのは、ユーザーにとっても仕組みが明確で、開発者にとっても実装するのが簡単だ。

　しかしこの方法ではユーザーのセキュリティやエクスペリエンスが大きな犠牲になっているといわざるを得ない。アプリBはユーザーから許可も取らずに、アプリAにあるすべての情報にアクセスできてしまうし、アプリAのパスワードを変更すれば、アプリAに接続しているアプリケーションの数だけ、パスワードを変更しなければならなくなる。ユーザーに早くサービスを提供したい開発者の思いも分からなくはないが、この方法はベストプラクティスになり得ない。もっとよい方法はないものだろうか。

【注1】 RESTとはREpresentational State Transferの略。ロイ・フィールディング氏が2000年に発表した博士論文の中で定義した「ソフトウェア設計原則」に従う設計スタイルのこと。より狭い意味では「HTTPメソッドを用いてURLへリクエストできるAPI」を表す用語としても利用される。RESTの原則に従うシステムやAPIは、“RESTful”と形容されることがある。

　TwitterのAPIアクセス権を委譲できないか？

　2007年12月、2007年2回目のInternet Identity Workshop（IIW2007b）が開催された。今回も国内外を問わず各方面の技術者が集まり、さまざまなアイデンティティ技術について話し合われた。そこでGoogle、Yahoo!、AOLなどの大手ITサービス企業の技術者の間で熱心にディスカッションされていたのが「OAuth」（“オース”と発音する）と呼ばれる仕様である。

　OAuthはまさに、先に挙げた問題を解決するために考案されたプロトコル仕様である。IIW2007bの開催に合わせて、12月4日にOAuth Core 1.0の仕様が確定した。OAuth Coreを実装したライブラリもPHPやRubyなどで開発されたものがすでに公開されている。

【関連リンク】 OAuth Core 1.0仕様 http://oauth.net/core/1.0/ OAuth基本ライブラリ http://oauth.net/code/

　OAuthの開発は、2006年末にTwitterのブレイン・クック氏が同社で開発するAPI認証をOpenIDで行おうと試行錯誤していたことに端を発する。クック氏から協力を求められたクリス・メッシーナ氏、米シックス・アパートのデビッド・リコードン氏（当時は米ベリサインに在籍）、Ma.gnoliaのラリー・ハーフ氏の間で話し合ったところ、OpenIDではTwitterのAPIアクセス権を別のアプリケーションに委譲（Delegation）することはできないと判断した。

　そもそもOpenIDはIDの持ち主が本人か確認する「認証（Authentication）」情報をやりとりするためのプロトコルであり、OpenIDプロバイダで認証されたIDがどのリソースにアクセスできるかといった「認可（Authorization）」情報については一切関与しない。認可の仕方もコンシューマ【注2】側に一任される。

　Twitterが行いたかったのは、ユーザーのクレデンシャルを外部にさらすことなくAPIへのアクセス権を別のアプリケーションに譲渡することだったため、OpenIDで解決できるはずもなかった。

【注2】 OpenID 2.0では「Relying Party」という用語で統一された

【関連記事】 OpenIDの仕様と技術 連載インデックス http://www.atmarkit.co.jp/fsecurity/index/index_openid.html 最新仕様「OpenID 2.0」が公開 http://www.atmarkit.co.jp/news/200712/06/openid.html

　2007年4月に数名の開発者が集まり、この問題の解決に取り組むべくThe OAuth Google Groupを立ち上げ、グループを通じて意見を交換しながらAPI認可プロトコルの標準仕様の策定を開始する。7月には最初のドラフトが発表され、12月のCore 1.0 Finalに至っている。OAuth CoreはさまざまなWeb APIの認証・認可部分からベストプラクティスを抽出して抽象化したものだといわれているが、全体のフローはFlickrの認証APIがモデルになっており、非常に似ている。

　現時点でOAuthを採用しているのはTwitterとMa.gnoriaである。OAuth Groupの運用や仕様ドキュメントの執筆については、Hueniverseのエラン・ハマー氏が中心になって行っている。共同執筆者の中にはGoogle、AOL、Flickr（2005年3月にYahoo!が買収）の開発者が名を連ねており、今後これらの企業の間で採用が進むかもしれない。

1/3

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

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

Security&Trust記事一覧

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