全てはあの人のtweetから始まりました。
OpenIDのOAuth Hybrid ProtocolとOAuth WRAPの相性ってどうなんだろ。ぜんぜん問題ないのか
Taizo Matsuoka on Twitter: "OpenIDのOAuth Hybrid ProtocolとOAuth WRAPの相性ってどうなんだろ。ぜんぜん問題ないのか"
Consumer Key送るだけだし、大丈夫なんじゃ？
nov matake on Twitter: "@tzmtk Consumer Key送るだけだし、大丈夫なんじゃ？"
OpenIDのRequestに関する部分は今と変わんなくて、そのあとのOAuthの処理が簡単になると思います。
http://twitter.com/ritou/status/7270275593
仕様決めてる人じゃないのでどうなるかわかりませんが、たぶんまだ話されてないと思います。
なので、ここでどうなるか想像してみます。
リダイレクトでユーザーを行き来させてAccess Token取得するまであたりの仕様を簡単に並べてみます。
■ OAuth WRAP
- (1) Client : 認可要求(AuthZ URLへのリダイレクト)にClient Identifier,Callback URLを含める
- (2) AuthZ Server : 認可応答(Callback URLへのリダイレクト)にVerification Codeを含む
- (3) Client : Client Identifier,Callback URL,Verification Codeを用いてAccess Tokenを取得
■ OpenID OAuth Extension
- (1) Consumer : OpenIDのAuthN Request(Providerへのリダイレクト)にConsumer Keyを含める
- (2) Provider : OpenIDのAuthN Response(Consumerへのリダイレクト)に認可済みのRequest Tokenを含む
- (3) Consumer : Consumer Key,認可済みのRequest Token+その他いろいろを用いてAccess Tokenを取得
細かい話をするとRequest TokenとVerification Codeの違いとか・・・いろいろあると思いますが、Access Token取得までに必要なパラメータの流れという点においては、現在のHybridとOAuth WRAPは似ています。
■ OAuth WRAPとOAuth 1.0aとの違い
- Request Tokenのくだりイラネ
- Signatureイラネ。HTTPS使う
詳しくはここ見てください。The Introduction of OAuth WRAP vol.1 : Web App Profile on FriendFeed - r-weblife
で、結局Hybridはどうなりそうかというと、、、
■ OpenID OAuth WRAP Extension
現在の仕様の「認可済みのRequest Token」の部分を「Verification Code」にreplaceしてやりましょう。
- (1) Consumer : OpenIDのAuthN Request(Providerへのリダイレクト)にClient Identifier(=Consumer Key)を含める
- (2) Provider : OpenIDのAuthN Response(Consumerへのリダイレクト)にVerification Codeを含む
- (3) Consumer : Client Identifier,Verification Code,Callback URL(=OpenIDのreturn_to)を用いてAccess Tokenを取得
そうすると、(3)のアクセスがOAuth WRAPのみのときとHybridのときで同じパラメータになります。
そのほうが実装するほうも楽ですよね？
■ 結局、相性は？
(・∀・)イイ！！
■ (おまけ)Hybridについていまさらながら思ったこと
細かい話なので、興味がある人はどうぞ。
現在のOpenID OAuth ExtensionはOAuth Core 1.0をベースに書かれています。
なので、
- Access Token取得のためにRequest Tokenは必須
- Token Secretは直接通信で渡してないので"空"でいい
という風に一部のパラメータが空になってるわけです。
1.0aになってVerification Code(=OAuth Verifier)が出てきてしまったものの、
- OpenIDは戻り先がしっかりしてるからVerification Codeは"空"でいい
みたいな感じで、純粋なOAuth 1.0aのAccess Token取得要求と比べると２つのパラメータが空になっています。
これ、SP側の実装も気持ち悪い。
- HybridのときはToken Secretとoauth_verifierを"空"にして処理
ってことをしないといけません。
上述したように、「認可済みのRequest Token」を「Verification Code」に変えてやると、
- HybridのときはToken,Token Secretを"空"にして処理
になります。
これなら、SP側の処理はただの2legged Requestになるので、処理も簡単で済むような。
ただ、これやろうと思うと仕様で定義されている「Access Token取得時のoauth_tokenパラメータ」を"任意"にする必要がありますね。
大したことないと思うけど。。。どうでしょうか？
