OAuth

様々な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認証を成立させるまでに、大きく三段階の手順がある。

1. コンシューマー登録
2. リクエスト・トークン要求とユーザーの同意確認
3. アクセス・トークン要求とAPI接続

ここからOAuthの特徴は、次の二点に要約することができる。

• APIの接続確認にトークンが使われる
• トークンはユーザーの同意に基づいてサービスプロバイダーからコンシューマーへ付与される

コンシューマーは、APIを通じたアクセスに先立ち、一度だけコンシューマー登録という手順が必要となる。

この手順により、コンシューマーを表わす一意のキー「コンシューマー・キー」と、電子署名に使う「コンシューマー・シークレット」がコンシューマーに対して発行される。

これは動的に行なわれても、また電子メール等を用いて行なわれても良い。

1. ユーザーがコンシューマーにアクセスする
2. コンシューマーは、要求に応じてサービスプロバイダーに接続し、「リクエスト・トークン」の発行を要求する
3. サービスプロバイダーは、まず「未承認」のリクエスト・トークンをコンシューマーに返す
4. 未承認のリクエスト・トークン受け取ったコンシューマーは、承認を得るためにサービスプロバイダーに送り返す
5. サービスプロバイダーはユーザーに対しログインを要求し認証する。認証に成功したら、次に同意の確認をおこなう。
6. ユーザーが同意したら「承認」のリクエスト・トークンを返す。さもなくば「拒否」のリクエスト・トークンを返す。

拒否の場合は、ここで終了する。承認された場合は、次に進み実際のリソースへのアクセス権を得る。

1. コンシューマーは承認済のリクエスト・トークン、コンシューマー・キー、コンシューマー・シークレットで得られた値をサービスプロバイダーに送り、「アクセス・トークン」の発行を要求する
2. サービスプロバイダーは送られてきた情報を確認し、認証されればAPIへのアクセス権となるアクセス・トークンと、それを電子署名するのに使う「トークン・シークレット」をコンシューマーに返す
3. コンシューマーはアクセス・トークン、コンシューマー・キー、トークン・シークレットで生成した値をサービスプロバイダーに送り、APIへの接続を要求する
4. サービスプロバイダーは送られてきた情報を確認し、認証されればAPIの応答情報をコンシューマーに返す。

以降は、サービスプロバイダーがアクセス・トークンに含めた条件(リソースの種類、有効期間)に応じて(3)を繰り返し、API経由でリソースへアクセスする。