こんばんは、ritouです。
秋田はコンクリートジャンゴゥなわけでもないのに、なんか最近、暑いです。
OAuth Echoとは
たくさんの方が調査されているので、細かい説明は省略。
Delegator(Twitpic)がConsumer(Twitter Client)からリクエストをもらったときに、Service Provider(Twitter)上のどのユーザーなのかを問い合わせることができるしくみです。
このときにService Providerのユーザー確認用URL(X-Auth-Service-Provider)とユーザー確認時に利用するリクエストヘッダ(X-Verify-Credentials-Authorization)をConsumerが作成するのですが、これはOAuth 1.0aベースの署名作成ロジックを利用しています。
「OAuth 2.0になるとこの辺がもっと楽(簡単)にならないのかなー」という意見をよく目にします。今でも十分簡単じゃねーかとも思いますが、現在検討されているOAuth 2.0関連の仕様にあわせるとどうなるのか考えてみました。
※ここから用語の使い方もOAuth 2.0ベースにしますので混乱してください！
1. Bearer Tokenでやるにはそれなりに工夫が必要
OAuth 2.0の象徴ともいうべき、署名なしのAccess Tokenのみでリソースアクセスを行ういわゆる"Bearer Token"の形式をこのしくみに適用すると、Access TokenをDelegatorにそのまま渡すことになり、Scope次第ではDelegatorがなりすましでアクセスし放題になりますのでよろしくありません。
OAuth Echoは"ConsumerがDelegaorにユーザー情報に関するAPIのアクセス結果を渡す"しくみともとらえられます。Access TokenのScopeをIdentity Verification専用のものにセットしておくことでDelegatorが悪さを働く範囲を制限することができます。もちろん、ID/PWを渡すよりはいいですが、ちょっと微妙ですね。
あとは別途、Delegation用のAccess Tokenを返すなども考えられます。
では、署名を持つリソースアクセス形式ではどうでしょうか？
2. MAC Access AuthNを使えば同様の実装が可能
MAC Access AuthNに関する以前のエントリはこちら
MAC Access AuthNを利用すると、ClientはMAC key identifier(Access Token)とMAC key(Secret)から署名付きのリクエストを作成してDelegatorに送ることになるでしょう。
よって、オリジナルのOAuth Echoに"近い"実装が可能です。
Restrictedの方も、あらかじめDelegatorがAuthZ ServerからDelegate用のMAC key identifier, MAC keyを取得していれば署名を追加できます。
3. Chain Grant Type
Chain Grant Typeに関する以前のエントリはこちら
この仕様は、Clientからリクエストを受けたあるAuth Server(A)の保護下にあるResource Server (A)が別のAuthZ Server (B)の保護下にあるResource Server (B)にアクセスしたいとき、Auth Server(B)からAccess Tokenをもらう仕組みです。
なんか日本語変ですね。
一見、OAuth Echoの代替になりえそうな仕様にも見えますが、このしくみとOAuth Echoの登場人物の関係は大きく異なります。気になる方は自分でよーく考えてみてください。
OAuth Echoでは物足りない
そもそもの話になりますが、私個人としてはこんな世界が実現したらいいと思っています。
もうtwitterのIDは広く浸透しているんだから、写真とかは腐るほどあるClientが持つリソースを親であるtwitterのOAuth経由してアクセスできるようなしくみを考えた方が良かったのではないか？ってふと思った。
http://twitter.com/#!/ritou/status/75399234748293122
OAuth Echoだけでは、この世界は実現できないと思います。
今回のTwitterとTwitpicの実装について、気になるところがいくつかあります。
- 1. Restrictedフローでない場合は、Clientが渡したHeaderを用いてユーザーの許可なしにDelegator(Twitpic)はAuthZ Server(Twitter)のユーザー情報を取得しているようだが、そんなんでいいのか？
- 2. ClientはDelegator(Twitpic)との間に別途Clientの登録を行いAPIキーの取得などが必要なようだが、Twitterに登録してあるClient情報をなんとか使えないものか？
- 3. 世の中にたくさんあるTwitter Clientが誰でも簡単にRestrictedフローのDelegatorになれるようなしくみならば勝手にProtected Resourceが増えていくことになり、Twitterにとってもいいことなのでは？
ということで、OAuth 2.0の仕様のRequest AuthZのあたりをいじったり、Discoveryのしくみをつかったりして、AuthZ Server保護下にないリソースへのアクセスも可能になるようなしくみを考えたいとこっそり思っています。
まぁ、みんなはOpenID Connectの方が気になってるようですので、そっちの仕様もチェックしないとですね。
ではまた！
