OAuth
読み：オース
外語：OAuth
Webアプリケーションなどに対し、
セキュア
なAPIアクセス権認可を与えるための標準的手段を提供するもの。
目次
概要
版
由来
背景
従来
開発
特徴
手順
コンシューマー登録
リクエスト・トークン
アクセス・トークン
利点
概要
簡単には、OAuthは次の特徴を持つ「認可情報の委譲」をするための仕様である。
あらかじめ信頼関係を築いたサービスの間で
ユーザーの同意により
セキュアにユーザーの権限を受け渡しする
全権委譲はあったが、特定の権利の委譲は従来なく、初めて実用化された標準的手段がOAuthであった。
版
OAuth 1.0 (
RFC 5849
) 2010(平成22)年4月
OAuth 2.0
(
RFC 6749
) 2012(平成24)年10月
由来
背景
様々なWebアプリケーションが登場し、その後Webアプリケーション同士の連携(
マッシュアップ
)が増えてくると、認証手段の共有をどうするかが問題化した。
OpenID
といった共有認証機能は登場したが、OpenIDで出来ることはIDの持ち主の認証のみで、どのようなリソースへのアクセスを許可するかといった認可機能は持っていなかった。
そこで、登場してきたのがOAuthである。
従来
マッシュアップされた二つのWebアプリケーションを利用する場合、従来であれば、「WebサービスA」のユーザーIDとパスワードを、WebサービスAにアクセスしたい「WebサービスB」にそのまま登録するような運用が行なわれてきた。
OpenIDもその延長線上であり、ユーザーIDとパスワードの共有が基本的機能である。仕様は明快であり、実装も簡単である。
しかし、WebサービスAのユーザーIDとパスワードがあれば、WebサービスBはユーザーから何の許可も得ることなくWebサービスAにある全情報へアクセスできたり、機能を利用できることになり、セキュリティ面で望ましいことではない。
また、WebサービスAのパスワードを変更した場合、WebサービスBもそれに合わせて登録し直す必要が発生し、手間が大きい。
開発
Twitterは、認証機能の改善として、まずOpenIDの実装に取りかかった。
SNSのMa.gnoliaも同様に、
Mac OS X
のDashboardウィジェットからサービスへのアクセス方法としてOpenIDを検討し始め、Twitterなどと協議を始めたが、前述したようにOpenIDには認可機能がなく、採用するに不十分と判断された。
そこで2007(平成19)年4月、彼らが集まりOAuth標準仕様の策定が開始された。それを知ったGoogleも賛同し、支援に加わった。結果、2007(平成19)年7月に最初のドラフト仕様が発表され、2007(平成19)年12月にOAuth Core 1.0がリリースされた。
特徴
手順
OAuthによって、ユーザーのリソースがあるサイト(サービスプロバイダー)と、その情報を利用したい別のサイト(コンシューマー)がAPI認証を成立させるまでに、大きく三段階の手順がある。
コンシューマー登録
リクエスト・トークン要求とユーザーの同意確認
アクセス・トークン要求とAPI接続
ここからOAuthの特徴は、次の二点に要約することができる。
APIの接続確認にトークンが使われる
トークンはユーザーの同意に基づいてサービスプロバイダーからコンシューマーへ付与される
コンシューマー登録
コンシューマーは、APIを通じたアクセスに先立ち、一度だけコンシューマー登録という手順が必要となる。
この手順により、コンシューマーを表わす一意のキー「コンシューマー・キー」と、電子署名に使う「コンシューマー・シークレット」がコンシューマーに対して発行される。
これは動的に行なわれても、また電子メール等を用いて行なわれても良い。
リクエスト・トークン
ユーザーがコンシューマーにアクセスする
コンシューマーは、要求に応じてサービスプロバイダーに接続し、「リクエスト・トークン」の発行を要求する
サービスプロバイダーは、まず「未承認」のリクエスト・トークンをコンシューマーに返す
未承認のリクエスト・トークン受け取ったコンシューマーは、承認を得るためにサービスプロバイダーに送り返す
サービスプロバイダーはユーザーに対しログインを要求し認証する。認証に成功したら、次に同意の確認をおこなう。
ユーザーが同意したら「承認」のリクエスト・トークンを返す。さもなくば「拒否」のリクエスト・トークンを返す。
拒否の場合は、ここで終了する。承認された場合は、次に進み実際のリソースへのアクセス権を得る。
アクセス・トークン
コンシューマーは承認済のリクエスト・トークン、コンシューマー・キー、コンシューマー・シークレットで得られた値をサービスプロバイダーに送り、「アクセス・トークン」の発行を要求する
サービスプロバイダーは送られてきた情報を確認し、認証されればAPIへのアクセス権となるアクセス・トークンと、それを電子署名するのに使う「トークン・シークレット」をコンシューマーに返す
コンシューマーはアクセス・トークン、コンシューマー・キー、トークン・シークレットで生成した値をサービスプロバイダーに送り、APIへの接続を要求する
サービスプロバイダーは送られてきた情報を確認し、認証されればAPIの応答情報をコンシューマーに返す。
以降は、サービスプロバイダーがアクセス・トークンに含めた条件(リソースの種類、有効期間)に応じて(3)を繰り返し、API経由でリソースへアクセスする。
利点
一旦、サービスプロバイダーへリダイレクトし、ユーザーの承認を得る処理はOpenIDと同様で、OpenIDの影響を受けている。
OAuthは、OpenIDと違って第三者にパスワード等を預ける必要がないことと、ユーザーが、許可する権利を事前に確認できるのが利点となっている。
将来的には、OpenIDとの相互運用なども検討されているとされる。
再検索
) 2010(平成22)年4月) 2012(平成24)年10月