「OAuth」の基本動作を知る：デジタル・アイデンティティ技術最新動向（1）（1/2 ページ）
いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サードパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。（編集部）
デジタル・アイデンティティの世界へようこそ
はじめまして、OpenID Foundation JapanでエバンジェリストをしているNovです。
この連載では、僕を含めOpenID Foundation Japanにかかわるメンバーで、OpenID ConnectやOAuthなどの「デジタル・アイデンティティ（Digital Identity）」にかかわる技術について紹介していきます。
APIエコノミー時代のデジタル・アイデンティティ
世界中で9億人のユーザーを抱える「Facebook」や5億人のユーザーを持つ「Twitter」など、巨大なソーシャルグラフを持つサービスが、日々その存在感を増しています。日本でも、グリーやモバゲーなどがそれぞれソーシャルゲームプラットフォームを公開し、国内に一気に巨大なソーシャルゲーム市場を作り上げました。最近では、ユーザー数が5000万人を突破し、プラットフォームを公開した「LINE」も記憶に新しいところです。
これらのサービスはプラットフォーム公開に際して、それぞれのサービス機能を「API」として外部に提供しています。APIを公開することで、外部デベロッパーが新たなサービスを提供し、それが結果的に、ユーザーにより多くの価値を提供することにつながっていくのです。
プラットフォームとその上で提供されるサードパーティのアプリケーションが作り出す市場は、APIを中心にした「APIエコノミー」とも表現できるでしょう。
このAPIエコノミーでは、1つのサービスが複数のプラットフォームと連携するといった状況も当然出てきます。そういった状況では、各プラットフォームの差別化要因となる部分以外は、標準化されたプロトコルを可能な限り導入し、API連携にかかるサードパーティデベロッパーのコストを抑えることが重要になります。
個人的には、今後、APIエコノミーが
- ユーザーのその時点でのコンテキストを理解し（Identity、Sensing……）
- 任意の適切なサービスを発見し（Discovery）
- それを動的に連携させる（OAuth、OpenSocial……）
といった方向に進むにつれて、“デジタル・アイデンティティ”の重要性が増していくのではないかと思います。
この“デジタル・アイデンティティ”は、好むと好まざるとにかかわらず、皆さんがWebの世界で生きていく上で非常に重要な概念です。ただ、この言葉自体を理解するのはなかなか大変です。この連載を通じてデジタル・アイデンティティについての理解が徐々に深まればと思います（注1）。もちろん、デジタル・アイデンティティ自体を理解していなくても、各要素技術について理解できるように書いていくつもりです。
注1：デジタル・アイデンティティ自体に興味を持ち、より深く理解したいという場合には、以下の資料をご覧ください。
- 非技術者のためのデジタル・アイデンティティ入門
http://www.sakimura.org/2011/06/1124/ - デジタルアイデンティティ - Wikipedia
http://ja.wikipedia.org/wiki/デジタルアイデンティティ - デジタルアイデンティティ Digital Identity
http://shop.oreilly.com/product/9780596008789.do
さて、連載の第1回と第2回は、ユーザーの認可の下でAPIアクセスを行う場合に必要になる「OAuth」というプロトコルについて紹介します。
OAuthとはどういうプロトコルか
いままでにFacebookやTwitter、Googleなどが提供するAPIを使ってサービスを開発したことがあるデベロッパーならば、何らかの形でOAuthに触れたことがあるでしょう。
また、FacebookやTwitterのIDを用いて外部サイトにログインしたことがある方も、実は、エンドユーザーとしてOAuthに触れています（GoogleやYahoo! IDでのログインは、OAuthではなくOpenIDというプロトコルを用いていますが、それについては次回触れます）。
ひと言でいうとOAuthは、
- あるサービス（サービスA）上にエンドユーザーが所有するリソースや、そのエンドユーザーがアクセス権限を持つサービスAの各種機能に対し、
- エンドユーザーの許可を受けたほかのサービス（サービスB）がアクセスする
ために
- エンドユーザーがサービスBに対して許可を与え
- サービスBがサービスAの提供するAPIにアクセスする際に許可を受けていることを証明する
という一連のフローを、セキュアに実現することを目的とした「アクセス権限の付与」のためのプロトコルです。
以下に2つほど、もう少し具体的な例を挙げてみましょう。
OAuthの利用事例
■例1：Instagramで共有した写真をFacebookやTwitterにも投稿
Instagramをはじめとしたカテゴリ特化型のアプリケーションの多くは、FacebookやTwitterといったほかのサービスにも同時にコンテンツを投稿する機能を備えています。
Instagramならば、設定画面の［Sharing settings］からTwitter、Facebook、Flickr、TumblrそしてFoursquareといった複数の外部サービスと連携するように設定できます。利用するプラットフォームや連携するサービスごとにアクセス権限付与時のユーザー・エクスペリエンスは異なりますが、Instagramで外部サービスへの投稿を行う際には、連携サービスを問わず、すべてOAuthが使われています。
InstagramはOAuthを用いて、ユーザーの代理として写真を投稿するためのアクセス権限を受け取ります。ひとたびアクセス権限の付与を受けると、ユーザーがInstagramで写真をアップロードするたびに、各サービスが提供するAPI経由で写真をクロスポストします。
■例2：Facebook IDでほかのサイトにログイン
FoursquareやPinterestなど、最近では至るサービスで「Facebook IDでログイン」や「Twitter IDでログイン」というボタンを見かけます。
OAuthは本来ID連携のために設計されたものではないのですが、FacebookやTwitterなどのようにユーザーのプロフィール情報（特にユーザーの識別子）を取得するためのAPIが存在する場合、ID連携に用いることもできます。
OAuthでAPIへのアクセス権限を受け取る際には、FacebookやTwitterがユーザーの認証を行っています。ですから、それらの認証結果を信頼した上で各アプリがプロフィールAPIにアクセスしてユーザーの識別子を習得すれば、ユーザーを認証できるのです。新規登録時にFacebookやTwitterからプロフィール項目を取得してくることで、ユーザーの入力項目を減らしたり、ゼロにすることもできます。
またID連携やプロフィール情報の取得だけでなく、ポストの投稿権限や友達リストなどを取得することも可能です。このため、FacebookやTwitterなどのプラットフォーム上でバイラルにサービスを広めたいサービスでは「Facebook IDでログイン」や「Twitter IDでログイン」といったボタンが多く利用されています。
しかしながら前述の通り、OAuthは本来、認証のために設計されたプロトコルではありません。このため、誤った使い方をして脆弱性を生み出しているケースも（特にiPhone/Androidアプリに）多く見受けられます。その点については本稿後半で紹介します。
Copyright © ITmedia, Inc. All Rights Reserved.