The Introduction of OpenID OAuth Hybrid Protocol Vol.2

■ Overview

GoogleとPlaxoが実験的に採用したことで話題になったOpenIDとOAuthのHybrid Protocolについて改めてまとめてみました。

Vol.1では、Hybrid Protocolの目的と拡張仕様の紹介までをまとめました。(長すぎです。)
2009-03-29 - r-weblife

Vol.2の内容は以下になります。

Approach : 既存サービスへのHybrid Protocolの導入タイミングとメリットについて
Usecases : 効果的なHybrid Protocolの使い方についての考察

■ Approach

ここでは、既存サービスに対してどのようにしてHybrid Protocolを導入するべきなのか、タイミングとメリットを整理していきたいと思います。

◆ OpenID RP + Hybrid

初めに、既存のOpenID RPへのHybrid Protocol導入について考えます。

タイミング：「Hybrid Protocolに対応したCombined ProviderのOAuth APIを利用し始めるとき」
メリット：「API利用のタイミングでCombined ProviderのOpenIDとの連携が可能になる」

認証にOpenIDを用いるサービスについて、次のような場合が考えられます。

１ユーザーに対してひとつのOpenIDが紐づく
１ユーザーに対して複数のOpenIDが紐づく(例：Plaxo)

基本的に、OpenIDはOPが提供するIDシステムを利用してユーザー識別子をRPに渡しています。
言い換えると、OPがIDシステムを提供できなくなった場合、そのOpenIDが利用不可能になることも考えられます。
Delegateを用いることで複数のOpenIDを自分のURLと紐づけることができますが、そのためのHTML,XRDの管理が必要になります。
私の個人的な意見としては、1ユーザーに対して複数OpenIDを紐づけるような機能をRPが積極的に実装していくべきだと思います。

OpenID RPはOAuthのAPIの利用を考える際に、OAuth SP＝OpenID OPである場合にはHybrid Protocolを用いることで紐づくOpenIDを増やすことができます。

◆ OAuth Consumer + Hybrid

次に、既存のOAuth ConsumerへのHybrid Protocol導入について考えます。

タイミング：「SPがHybrid Protocolに対応」
メリット：「OAuth Token取得のタイミングでUser識別子としてOpenIDを利用可能」「『内部ID：OpenID(+そのアカウントに対するOAuth Token)＝1:n』という関係を厳密に構築可能」

基本的に、OAuth ConsumerはUser認証の機能を独自に実装しています。
ここで、OAuthのUser識別について少し説明します。

OAuthの仕様では、「認可を行ったUserが誰なのか」をConsumerは知ることができません。
GoogleのOAuthはAXでEmailを取得したり、APIアクセスして個人データの取得を行うまではUser識別ができないため、ConsumerはTokenを内部のUser識別子を紐づける必要があります。
「OAuth Consumer上のAというID」は「Google上のAというID」なのか「Google上のBというID」なのかConsumerはわかりません。
このような仕様によって、Consumerが要求するリソースに対して、どのIDのデータにアクセスを許可するのかはUserが選択できるべきであり、
「Consumer上のID：SP上のID＝1:1」といった関係ではなく「Consumer上のID：OAuth Token＝1:n」という柔軟なリソースアクセスが可能だということです。

Yahoo!の場合はAccess Token取得時にxoauth_guidというUser識別子を提供しており、「Consumer上のID：SP上のID＝1:1」としてConsumerは内部で持っているUser識別子と紐づけることができます。
また、Yahoo!ではOAuth認可のタイミングで必ずUser確認（ログイン/PW再確認）を行っているため、（同意画面のUX低下を無視すれば）OAuth認可をUser認証として利用することもできます。

Hybrid ProtocolをOAuth視点でとらえると、「OAuth認可のタイミングでOpenIDをUser識別子として受け取ることができる」となります。
GoogleでHybrid Protocolを利用するときにUserがGoogle上で利用するIDを切り替えたときには異なるOpenIDが渡されます。
ほとんどのConsumerは現在認識しているOpenIDと異なるOpenIDを受け取った時にエラーにする場合が多いと思います。
しかし、「１Userに対して複数OpenIDを紐づけ可能」という考えは、同一OPに関しても同じことが言えると思います。
便利なマッシュアップサイトに対して、Googleからアドレス帳をインポートするときはGoogle上のAというIDを利用したいけれども、Youtubeのお気に入りリストをインポートするときにはGoogle上でBというIDを利用したいというケースもあるかもしれません。

Hybrid Protocolを導入することで、「Consumer上のID：OAuth Token＝1:n」という関係ではなく、「内部ID：OpenID(+そのアカウントに対するOAuth Token)＝1:n」という関係を厳密に構築することが可能になります。
しかし、そのような関係を実現するためにはOpenIDやTokenの管理がとても複雑なロジックが必要となり、Userに優しくない印象を受ける可能性もあるため現実的ではありません。

◆ Combined Consumer + Hybrid

タイミング：「利用しているCombined ProviderがHybridに対応」
メリット：「UX改善」、「OpenID連携が用意」

既に、OpenID認証とOAuth対応APIを利用している場合、ロジックを組み替えるだけととらえるとHybrid導入の敷居は低いと言えるでしょう。
Hybrid ProtocolのGoalで説明した通り、認証、認可の画面の統合をとおして、OpenID連携が容易になることは確かです。
しかし、本来、認証と認可は異なる目的を持っているため、Hybrid Protocolを導入することで、「認証のみが必要とされているタイミング」で「認証＋認可」処理を行うようになってしまっては、導入前よりもUXが低下してしまう可能性があります。
次に、効果的にHybrid Protocolを利用するためのポイントを説明したいと思います。

■ Usecase

上述の通り、Hybrid ProtocolはOpenIDとOAuthの処理を同時に行うための仕様ですが、OpenIDとOAuthを利用するサービスが全ての認証要求に拡張を含めばいいというものではありません。
Combined Consumerは、次のようにHybrid Protocol認証とOpenID,OAuthそれぞれの認証、認可を使い分ける必要があります。
それぞれの使いどころについては以下のようになります。

◆ OpenID Only

Userが特定できていないが、Combined ConsumerはOAuthによるリソースアクセスが必須ではないとき
Userが自らのOpenIDを指定しており、そのOpenIDに紐づいたUserはOAuth Tokenを持っていることを確認できているとき

OpenIDの認証フローにおいてUserがOP Identifierを利用せず、自らのOpenIDを指定した場合、Combined ConsumerはOAuth Tokenが有効かどうかを判断することが可能です。
User認証完了前にそのような判断をすることの是非については検討の余地があると思いますが、Userに対して何度も不必要な同意を求めるような仕様はUX向上の妨げになる可能性があるため、避けるべきです。

また、現在のYahoo!(Hybrid Protocol非対応)の場合、OpenID認証よりもOAuth認可に必要な画面数が多く、画面の内容などもやや複雑です。
Providerがどのような実装するかはわかりませんが、Hybrid Protocol対応後でもOpenID認証のみと要求するロジックは残して利用すべきだと思います。

◆ OAuth Only

Userは特定できているが、まだOAuthのTokenを取得していない、OAuth Tokenが無効になった
Combined ConsumerはOAuthによるリソースアクセスが必須ではない

当り前の話ですが、OAuthによるリソースアクセスが必須ではない場合にはOpenID認証とOAuth認可を別々のタイミングで利用することによりUserに不必要な同意を求めることを防ぐことができます。
Hybrid Protocolの認証＋認可のタイミングではOpenIDの認証プロトコル仕様に従った実装を行う必要があります。
また、仕様面ではOAuthの認可要求のほうがシンプルです。

OAuth Consumer + Hybridで述べたようなOAuth TokenとOpenIDの厳密な関係についてはここでは言及しません。

◆ Hybrid

Userは特定できているが、まだOAuthのTokenを取得していないとき
Combined ConsumerはOAuthによるリソースアクセスが必須ではない

OAuth Onlyの場合と反対に、必ずOAuth Tokenが必要になるような場合には、Hybrid ProtocolでUser認証のタイミングでOAuth Tokenを取得する必要があります。

■ まとめ

Vol.2ではHybrid Protocolの導入までのアプローチ方法や効果的な使いどころについてまとめました。
OpenID,OAuthの組み合わせは深く考えていくと議論がつきませんが、最初のUser登録時などにHybrid Protocolを利用し、それ以降はOpenID認証とOAuth認可を使い分けることにより、UXを改善することができることができるのではないかと思います。

またまた長くなってしまったため、PlaxoとGoogleのユースケースについてはVol.3で説明したいと思います。

■ Information

2009-03-29 - r-weblife