OAuth 2.0で
Webサービスの利用方法はどう変わるか

OAuthの現状と1.0の問題点、2.0での特徴などを解説し、2.0の例としてFacebookのAPIの利用例を紹介します

OAuthの現状

　TwitterがOAuth 1.0を採用したのを皮切りに、今では多くのサービスがOAuth 1.0に対応しています。国内でも、例えば、マイクロブログ型コラボツール「youRoom」、小規模グループ向けグループウェア「サイボウズLive」、「はてな」のいくつかのサービス、「Yahoo!オークション」、リアルタイムドローツール「Cacoo」などがOAuth 1.0に対応したAPIを公開しています。

　ここ数年でOAuthはさまざまなWebサービスのリソースを利用する際の認証方式として普及してきました。これは大きなプレーヤーがサポートしたことも一因ですが、OAuthの持つ以下の2つの特徴によって、「OAuthを使うと、サービスプロバイダも、サービスを利用するサードパーティのアプリ開発者も、エンドユーザーも安全・安心なサービス利用が可能になる」ところが一番大きな理由といえるでしょう。

1. パスワードをサードパーティのアプリに渡すことなくAPIを利用できる
2. どのリソースにアクセス可能かを細かくユーザーに認可させることができる

　そして、現在は次期バージョンであるOAuth 2.0の仕様の策定が進んでいます。すでにFacebook、Twitter、mixiなどがOAuth 2.0のドラフト版のサポートを始めています。

　本稿では、Facebook、mixiなどでサポートされているOAuth 2.0 Draft v.10をベースにOAuth 2.0の概要を説明します（原稿執筆時現在の最新は2011年1月21日に公開されたDraft v.12です。それについても一部紹介します）。

OAuth 1.0のおさらい

　OAuth 2.0の良さを理解するには、1度OAuth 1.0のおさらいをしておく必要があります。OAuth 1.0での認証は、以下のような流れで行われます。手前味噌ではありますが、筆者の開発したソーシャルメディアクライアント「Crowy」とのやりとりを例として掲載します。

図1　OAuth 1.0での認証の流れ（CrowyとTwitterの連携の例）

　上の図の通り、OAuth 1.0ではサードパーティのアプリとOAuthサービスプロバイダの間で何度もリクエストのやりとりが行われ、2つのトークンシークレット（署名生成のための共通鍵）と、2つのアクセストークンがやりとりされます。

　また各リクエストは、すべてOAuthの仕様に従って署名を付ける必要があります（万年筆のアイコンが付いているリクエストが署名の必要なリクエストです）。

　OAuth 1.0について詳しくは、以下の記事をご覧ください。

　また、「OAuth.jp」というOAuthの情報を日本向けに発信しているコミュニティがOAuth 1.0の仕様の日本語訳を公開しています。より詳しく知りたい方は、そちらが参考になると思います。

OAuth 1.0の3つの課題とは

　さて、すでに利用の進んでいるOAuth 1.0に代えて次期バージョンのOAuth 2.0の策定が進んでいるのはどのような理由からでしょうか？ OAuth 2.0仕様策定の中心人物である米ヤフーのEran Hammer-Lahav（エラン・ハマー）氏がOAuth 1.0の課題として以下の3つを挙げています（参考：「Introducing OAuth 2.0 ≪ hueniverse」）。

■ 【1】認証と署名

　OAuth 1.0での開発を経験された方なら、おそらく誰しも署名と複雑な認証フローには苦しめられたのではないでしょうか？

　この仕組みが複雑なため、OAuthクライアントを作成するためにはOAuthのライブラリが必須でした。しかし複雑なため、ライブラリにバグが存在することもしばしばありました。ライブラリが存在しない言語でOAuthを使用したい開発者は諦めざるを得ないような状況でした。

■ 【2】デスクトップ／モバイルアプリ対応

　OAuth 1.0はWebアプリのみを対象としていて、モバイルやデスクトップアプリでは、OAuth 1.0の仕組みはあまりうまくいきませんでした。

　このため結局、Twitterはデスクトップクライアントとモバイルアプリのために「xAuth」というTwitter独自のOAuth拡張を取り入れました。

■ 【3】スケール時のパフォーマンス

　OAuthサービスプロバイダにとっても、OAuth 1.0の仕様は問題を抱えていました。

　リクエストトークンはよく使用されずに捨てられることが多いのですが、サービスプロバイダはリクエストトークンを保持する必要がありました。リクエストトークンを長い期間保持するのはセキュリティも低下し、管理も大変になります。

　また大規模サービスプロバイダでは、認証サーバにクレデンシャルの発行を任せ、APIの応答は別サーバで行うことが一般的です。しかし、OAuth 1.0では保護されたリソースにアクセスする際にクライアントクレデンシャルとトークンクレデンシャルの両方を必要とするため、これらの分離が難しくなり、サーバをスケールするのが困難になります。

1/3

INDEX
ソーシャルAPI活用に必須の“OAuth”の基礎知識 OAuth 2.0でWebサービスの利用方法はどう変わるか
	Page1 OAuthの現状 OAuth 1.0のおさらい OAuth 1.0の3つの課題とは
	Page2 OAuth 2.0の3つの主な特徴 OAuth 2.0の4つのクライアントプロファイル Webサーバプロファイルの場合の処理の流れ
	Page3 OAuth 2.0を利用する際のコード例（Facebookの場合） OAuth 2.0の今後に注目！

Smart＆Social フォーラム トップページへ