クロスドメインでのデジタルアイデンティティを守る
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記事一覧 |
- 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)対策の観点から考える。
|
|