風柳メモ

ソフトウェア・プログラミング関連の覚書が中心。

OAuthのやり取りを読み取ってみる

よくわからないものを使おうとするからよ

さすがに何も知らないのもなぁ、と思って、OAuth Core 1.0aを日本語訳tzmtkを参考にしつつ、一通り目を通してみました。
で、Access Toke取得時の、User・Consumer・Service Provider三者間のやりとりをシーケンス図に表したのが、これ。*1

PDF版はこちら

自分用メモとして箇条書き

  1. OAuthは、特定のService Provider上で管理・保護されているUserリソースに対し、第三者であるConsumer(別サービス)がアクセスしたい場合、従来のID/Pawsswordを使用したBASIC認証等の代わりとして、"Access Token"というものを用いてアクセスすることを可能にする手法。このとき、ID/Pawsswordを直接Consumerに渡す場合と違い、アクセス可能期間やリソース種別などの制限をConsumerに対してかけることが可能(=Passwordを直渡しするよりも安全)。
  2. 1.より(当方がシーケンスとしてまとめた)OAuth認可手順を実施する最終的な目的は、Service ProviderがConsumerに対してAccess Tokenを発行することにある。
  3. OAuth認可手順(Authenticating with OAuth)には、大きく分けて以下の三段階がある。
    1. 「Obtaining an Unauthorized Request Token(Request Token(未認可)の取得手順)」
    2. 「Obtaining User Authorization(User認可取得手順)」
    3. 「Obtaining an Access Token(Access Token交換手順)」
  4. Service Providerは予め、"Request Token URL"、"User Authentication URL"、"Access Token URL"のURLを用意し、Consumerに伝えておく必要がある。また、Consumerに対し、予め"Consumer Key"及び"Consumer Secret"を発行しておく必要がある。これらのConsumerへの伝達・発行手法などはService Providerに任されており、実際にOAuth認可手順が実施される前に行われておく必要がある【例:Twitterの場合、http://twitter.com/oauth_clientsの"Register a new application ?"のリンクから設定。】。
  5. リソースアクセス範囲・アクセス期間などは、予めService Providerが決めておいてもよいし、OAuth認可手順中に独自パラメータでやり取りを定義したり、"Obtaining User Authorization"手順中でUser←→Service Provider間で取り決めしたりすることで変更・選択等も可能と思われる(この辺りの詳細はOAuthの仕様としては書かれていない模様)。
  6. "Obtaining an Unauthorized Request Token"は、Consumer←→Service Provider間のやり取りであり、未認可状態の"Request Token"をConsumerに対して発行するもの("Request Token"は1回かぎりの“引換券”)。
  7. "Obtaining User Authorization"は、User←→Service Provider間のやりとりで、「これこれのConsumerがあなたのリソースにアクセスしたがっていますがどうしますか?」と訪ねて、認可/拒否をUserに選択させるもの。Service Providerは(Userに対し)Consumerの身元を保証することはしない(してはいけない)ため、あくまでユーザ自身がConsumerを信頼するかどうかが決め手となる。
  8. "Obtaining an Access Token"は、Consumer←→Service Provier間のやりとりで、"Request Token"を"Access Token"へと引き換えるもの。当然ながら、この引き換えは"Obtaining User Authorization"でUserが認可した場合にのみ実施される。また、使用済みの"Request Token"はこの後は使用されない。
  9. 発行された"Access Token"によるアクセス権は、任意の時点でUserが停止・変更する仕組みがService Providerの機能として必要(少なくとも現状の仕様では、ConsumerからService Providerに対し、アクセス権を放棄する旨通知するような機能はないように思われる)。
  10. 少なくとも、現状のOAuth Core 1.0Aにおいては、「だれが(どのUserが)アクセスを認可してくれたのか」、という情報を、Consumerが知る術は、標準仕様ではないように思われる(Twitterの場合、"Obtaining an Access Token"でuser_id及びscreen_nameが返ってくる仕様にはなっている模様)。
  11. TwitterのOAuthはまだ Core 1.0 対応(というか1.0仕様でも動く仕組み)なのだろうか?"Obtaining an Unauthorized Request Token"時にoauth_callbackパラメータが無くても動くし、Core 1.0Aで規定された、"Obtaining User Authorization"でoauth_verifierが返ってこない/"Obtaining an Access Token"時にoauth_verifierが無くても動作する、みたい。

ぜんぶ読んだ4!』で使わせて頂いたGoogle App Engineで手軽にOAuthアプリを作成!(Twitterとか!) - AppEngine-OAuth [ゼロと無限の間に]のOAuth関連ソースは、どうもCore 1.0っぽい動作なので、そのうち Core 1.0A相当に改造して試してみようかな…?

*1:場合によってはリダイレクトの代わりにユーザに手入力させたりする実装も可能みたいだけれど(302 Found返すようになっている箇所とか)、それは省略。異常処理も省略。