Idea : OAuth User Authentication Extension

Idea : OAuth User Authentication Extension

twitterがOAuthで"Sign-in with Twitter"っていうあいまいなことをやりだしたので、どうせならこんな拡張を作ればいいんじゃないかと思い書いてみました。
最初は"OAuth OpenID Extension"ってのを考えていたんですが、Hybridのやり方も嫌いじゃないのでもっと汎用的な仕様ということで考えてみました。
実装アイディアなんかもあったりしますが、とりあえずやりたいことを書いてみます。

■ 目的

本拡張の目的はシンプルです。

OAuth SPがConsumerに対してUser Identifierを返すしくみを提供

OAuthではUser Identifierの渡し方が定義されていないため、ほとんどのSPは独自の実装で提供しています。

  • Yahoo : Access Tokenと一緒にxoauth_yahoo_guidというパラメータを渡す
  • twitter : 認可後にrequest_tokenと一緒にuser_idというパラメータとして渡す

また、GoogleのようにOAuthの機能としてはUser Identifierを渡さず、HybridにするかgmailなどのAPIアクセスを行うまではUserが何者かわからないような作りになっているところもあります。
そこで、本拡張では渡し方を定義してみればいいのではないかと。

渡すUser Identifierについては次のように考えます。

OpenStackを意識したUser Identifierを提供

渡すUser Identifierを絞っては、汎用的に使うことはできません。
それぞれの値にnamespaceを用意し、ConsumerはUser認証後に欲しい値をRequestに含みます。

ConsumerからSP,SPからConsumerへのIndirect Communication(リダイレクト時のURL)には署名を含まない

署名のあたりの仕様を拡張させるのはセキュリティの話が出てくるので、よくありません。
複雑なデータのやり取りはDirect Communicationでやります。
また、日本のモバイル端末のようにURL制限があったりすることも考え、URLはなるべく短くするべきです。

ConsumerKeyを登録していないConsumerに対してもUser識別子を渡す

OpenIDとの差異を解消するために、ConsumerKeyが発行されていないOpenIDのRPからも利用できるようにすべきです。
本拡張をOAuthで実装することで、OpenIDのモバイル対応をイレギュラーな形式で実装できると思っています。
というか、むしろURLの識別子だけ残してOpenIDのプロトコルは不要になってもいいんじゃないかとかこっそり思っています。

■ 仕様検討のポイント

  • 要求するUser Identifierの指定するタイミング : Request Token取得のタイミング？
  • User Identifierを取得するタイミング : Access Token取得のタイミング？
  • Unregisted Consumerの扱い : OpenIDの仕様から何か使いたい(realmかreturn_toあたり)。

Unregisted ConsumerはOAuthでそのうち議論されるような気がしていますが、話が出てきませんね。
ってことで、少しだけ書いてみましたが、どうでしょう？

えっと、OpenIDが嫌いなわけではないですよ。