前から思っていたことを一度まとめてみます。
長いので読む際は十分に気を付けてください。
■ 背景
OAuth Coreおよびいくつかの拡張仕様で定義されているRequestは、以下のような関係者による違いはありますが、基本的にRequestは"ConsumerからSPへ送られるもの"です。
- 3legged OAuth Request : SP,Consumer,Userの3者が絡む
- 2legged OAuth Request, OAuth Consumer Request, Signed Request(OpenSocial) : SP,Consumerの2者が絡む
OpenSocial Containerの例を見てみましょう。
前提:
- Container : examplecon.com
- 開発者のサイト : exampledev.com
このとき、以下の２つのRequestではProvider/Consumerの立場が逆になります。
- 開発者のサイトからContainerのRESTful APIをたたく : Provider=examplecon.com, Consumer=exampledev.com
- OpenSocial GadjetがmakeRequestを用いて開発者サーバのAPIをたたく : Provider=exampledev.com, Consumer=examplecon.com
当然、この２つのRequestには、ConsumerKeyと暗号化に必要なConsumerSecret(もしくはRSAの鍵ペア)が2種類存在します。
しかし、この２つのRequestの機能は独立したものなので、特に異論/問題はありません。
次の例はどうでしょう。
前提:
- OAuth対応APIを提供するSP : examplesp.com
- Consumer : exampleconsumer.com
当たり前ですが、2者間で送られるRequestは以下のようになります。
- ConsumerがSPのAPIを利用 : Provider=examplesp.com,Consumer=exampleconsumer.com
現在の多くのAPIは、このような1方向のRequestのみで実装されていますが、ProviderからConsumerに対してRequestを送りたいケースもあるのではないかと思っています。
- 非同期通信
ConsumerからのRequestを受けたタイミングですぐにResponseを返すのではなく、受け付けたことをあらわすResponseを返す。
実際の処理が終わったらProviderがConsumerに結果を通知する。
- 決済情報などを扱うAPIの月末のbatch処理
これについて具体的な話はしませんが、今までよりもAPIのRequestで実現できることが増えるのではないでしょうか。
また、使い方もあると思います。
- SP上のUser状態に変化があったときの通知
OpenID/OAuthのHybridを使っているような場合、User認証をSPに依存している場合があります。しかし、SPはConsumerの都合を気にせず、自分たちのポリシーでUser管理を行います。
突然あるユーザーがSP上で認証不可能になることもあるでしょう。
その際に、SPのほうからConsumerに通知することで、Consumer側が他のOpenIDと紐づける仕組みを提供するなどのアカウントリカバリーの仕組みを用意できるかもしれません。
Provider/Consumerの２者間で共有しているConsumerKey/Secretを用いてProviderから Consumerに送られるRequest(OAuth Provider Request)を定義することで、今まで実現できなかった双方向のOAuth Requestが可能になります。
