The Introduction of OpenID OAuth Hybrid Protocol Vol.1

■ Overview

本ドキュメントでは、GoogleとPlaxoが実験的に採用したことで話題になったOpenIDとOAuthのHybrid Protocolについてまとめました。
Vol.1の内容は次のようになっています。

  • Goal : Hybrid Protocolの目的
  • Technical Scope : Hybrid Protocolを実現するための技術的なポイント
  • Spec : OpenID OAuth Extensionの仕様紹介
  • Demo : Hybrid Protocolのデモ環境を利用した動作検証

■ Goal

ここでは、Hybrid Protocolの目的について説明します。
まず初めに、OpenIDとOAuthのそれぞれのProtocolについて、標準的なUXの説明をします。
バックグラウンドで行われる処理について、ここでは省略します。

◆ OpenID Flow

Spec ： Final: OpenID Authentication 2.0 - Final

例 ： OPのOpenIDを用いてRPにサインイン

  1. UserがRP上で自分のOpenIDを入力もしくはOPを選択
  2. RPがUserをOPにリダイレクト
  3. UserがOP上で「RPにサインインすること」について同意
  4. OPがClaimed IDとともにUserをRPにリダイレクト
  5. RPがUserを特定し、認証完了

◆ OAuth Flow

Spec ： OAuth Core 1.0

例：アドレスブックのインポート

  1. Userが利用するアドレスブックのSPを選択
  2. ConsumerがUserをSPにリダイレクト
  3. UserがSP上で「アドレスブックの情報をConsumerにシェアすること」について同意
  4. SPがUserをConsumerにリダイレクト
  5. ConsumerがUserの代わりにSPのアドレスブックにアクセス

このように、OpenID FlowにおけるUXとOAuth FlowにおけるUXは非常に似ています。
例えば、次のようなサービスを構築することを考えます。

この場合、UserはGoogle上で2回の同意を行う必要があります。
Hybrid Protocolは「OpenIDのOP＝OAuthのSP,OpenIDのRP＝OAuthのConsumer」である場合に焦点をあて、
「OpenIDの認証画面にOAuthの認可画面を統合することによるUX改善」を目的としています。

■ Technical Scope

画面統合のために、OpenIDとOAuthの技術面、仕様面の調整が必要になります。
そもそも、OpenIDとOAuthではそれぞれ異なる目的で作られたものであり、Data FlowやURLパラメータの仕様も異なります。
それぞれの仕様を根本的に変えることは現在の開発者に大きな仕様変更を伴うことになるため好ましくありません。
OpenID OAuth Extensionでは共通の目的をもっているパラメータの利用しつつ、機能統合のための必要最小限の拡張仕様が定義されています。
ここからは、OpenID OAuth Extensionが注目したOpenID,OAuthの仕様をいくつかピックアップして説明していきます。

◆ RP,Consumer識別子

OpenID,OAuthにおけるRP,Consumerの識別子は次のようになっています。

  • OpenID : realm,return_to
  • OAuth : Consumer Key

OpenIDの仕様ではRPの事前登録が必要ありません。
OPのポリシーにもよりますが、RPを特定するための要素としてはrealm,return_toパラメータがあります。
OAuthではConsumerとしての事前登録が必要であり、SPから識別子としてConsumer Keyが発行されます。
OpenID OAuth Extensionでは「OpenIDのRP＝OAuthのConsumer」であることを確認する必要があるため、OpenIDの認証要求にConsumer Keyの値を含みます。

◆ 戻り先URL

UserをOP=SPにリダイレクトする際に戻り先URLとして、次のようになっています。

  • OpenID : return_to
  • OAuth : oauth_callback

これらの２つのパラメータの目的は共通であるため、return_toの値をoauth_callbackの代わりに利用します。

◆ OAuthのRequest Token

OAuthにおけるTokenの扱いは以下のようになっています。

  1. ConsumerはSPから未認可のRequest Tokenを取得
  2. Consumerは取得したRequest Tokenを含むSPのエンドポイントにUserをリダイレクト
  3. SP上でUserがConsumerに対してリソースアクセスの認可を与える
  4. SPは認可済みのRequest Tokenを含むCallback URLにUserをリダイレクト
  5. Consumerは認可済みのRequest TokenとAccess Tokenを交換

セキュリティ要件から、Access Tokenの値はUserのリダイレクトURLに含まれません。
Hybrid Protocolでは4にあたるOpenIDの認証応答に認可済みのRequest Tokenを含むことで、RP,Consumer側にRequest Tokenの値を渡します。

これらを要件として定義された仕様について、説明します。

■ Spec

拡張仕様の詳細はhttp://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.htmlを参照してください。
ここではTechnical Scopeの内容が定義されている部分を中心に説明します。

◆ Terminology

Hybrid Protocolにより追加された定義が説明されています。

  • Combined Consumer : OpenID RP + OAuth Consumer
  • Combined Provider : OpenID OP + OAuth SP

◆ Purpose of this Specification

Goalで説明した内容とほぼ同じです。

  • UX向上のためにOpenIDとOAuthの同意画面を統合する
  • OpenIDの認証要求にOAuthの認可要求を含む
  • Securityの点からAccess Tokenを認証応答に含めず、Access Tokenとの取得方法を本仕様で提供する

◆ Overview

  • 標準のOAuthとは異なり、この拡張ではサーバ間通信によるRequest Tokenを提供しない
  • その代わり、OpenID認証応答に認可済みのRequest Tokenを含む
  • Combined ProviderはRequst TokenとAccess Tokenを交換する

◆ Extension Namespace

本拡張のnamespace URIは次のようになります。

http://specs.openid.net/extensions/oauth/1.0

本拡張を利用する際に、OpenIDの認証要求、認証応答には次のようなパラメータが含まれます。

openid.ns.=http://specs.openid.net/extensions/oauth/1.0

◆ Discovery

Hybrid ProtocolをサポートするCombined Providerは、以下のnamespaceをDiscovery用のXRDSドキュメントに含みます。

現在のGoogleのDiscovery用ドキュメントは以下のようになっています。





http://specs.openid.net/auth/2.0/server
http://openid.net/srv/ax/1.0
https://www.google.com/accounts/o8/ud


Hybrid Protocolの仕様が確定すると、以下のような記述になると思います。





http://specs.openid.net/auth/2.0/server
http://openid.net/srv/ax/1.0
http://specs.openid.net/extensions/oauth/1.0
https://www.google.com/accounts/o8/ud


これで、Combined Consumer側はHybridに対応しているかどうか判断できます。
Discoveryを利用して認証要求の内容を出し分けできるしくみにしておくと、今までHybrid Protocolに対応していなかったOP+SPが対応した時点でCombined Consumerもすぐに対応できます。

◆ Before Requesting Authentication - Registration

Combined ConsumerはOAuthのConsumer Kye/Secretの値をConbined Providerから取得する必要があります。
Combined Providerはこの時、本拡張が利用されたOpenIDの認証要求に含まれる可能性がある有効なrealmのリストを取得し、検証時にCombined Consumerがそのrealmを使うことについて許可されていることを確認すべきです。

◆ Requesting Authentication

Combined ConsumerはOpenIDの認証要求に次のパラメータを含みます。

  • openid.ns.oauth : namespace
  • openid.oauth.consumer : Conbined ConsumerのConsumer Key
  • openid.oauth.scope : 要求するOAuth TokenのScope(option)

◆ Authorizing the OAuth Request

Combined Providerは次の処理を行います。

  • Combined ProviderはConsumer Keyとrealmの値をチェックする
  • Combined Providerが持つUserリソースに対して、Combined Consumerがアクセスすることについて、Userの同意を得る

◆ Responding to Authentication Requests

  • Combined ProviderはOpenID認証要求の検証に失敗したときにはOAuthの認証要求も失敗したと考えるべきであり成功の応答を返してはいけない

OpenID認証の検証結果が成功でありUserがアクセス許可を与える場合、Combined Providerは次のようなパラメータをOpenID認証応答に含み署名を行います。

  • openid.ns.oauth
  • openid.oauth.request_token : 認可済みのRequest Token
  • openid.oauth.scope

◆ Obtaining the Access Token

Combined Consumerは受け取った認可済みのRequest Tokenを用いてAccess Tokenの取得を要求します。
この部分の仕様はOAuth Coreの仕様と同じですが、次のようにOAuth Tokenにあたる値を取得していないため、署名のための鍵はconsumer secretのみとなります。

  • consumer key : パラメータに含む。
  • consumer secret : この値を用いて署名を行う
  • OAuth token : 取得した認可済のRequest Token
  • OAuth token secret : この値は取得していないため、空

Access Tokenを取得したあとはOAuth Coreの仕様に従ってリソースアクセスを行います。

■ Demo

GoogleのDemoサイトは以下になります。
http://googlecodesamples.com/hybrid/

◆ Requesting Authentication

OpenIDの認証要求には、以下のような値が含まれます。
これは、SpecのRequesting Authenticationで説明しているとおりです。

openid.ns.oauth : http://specs.openid.net/extensions/oauth/1.0
openid.oauth.consumer : googlecodesamples.com
openid.oauth.scope : http://docs.google.com/feeds/ http://spreadsheets.google.com/feeds/ http://sandbox.gmodules.com/api/

Demoサイトは、Googleに対してOpenIDの認証要求に次のような認可要求を含めています。

OpenID OAuth Extensionに従い、以下のリソースにアクセスする認可済みのRequest Tokenをください

◆ Authorizing the OAuth Request

Googleは認証要求を検証し、Userに対して同意画面を表示します。
通常のOpenIDの画面に加えて、OAuthの認可に対する文言が表示されてます。

このサイトは下記の追加情報へのアクセスをリクエストしています。 詳細

◆ Responding to Authentication Requests

OpenIDの認証応答には次のような値が含まれています。

openid.ns.ext2 : http://specs.openid.net/extensions/oauth/1.0
openid.ext2.scope : http://docs.google.com/feeds/ http://spreadsheets.google.com/feeds/ http://sandbox.gmodules.com/api/
openid.ext2.request_token : 1%2FSsr6NRzbOCUWRrPcpKeq2WATiaQZnWPB51nTvo8n9Sw

この後、Demo SiteはRequest Tokenを用いて、Access Tokenを取得します。
取得したAccess Tokenを用いて、APIアクセスを行います。

■ まとめ

Vol.1では、Hybrid Protocolの目的と仕様の紹介と、Demoサイトを使った動作確認までを行いました。
Vol.2では、Hybrid Protocolを実際のサービスに導入していく際に考えなくてはいけない点と、GoogleとPlaxoのユースケースの紹介を行いたいと思います。

■ Information