Draft Specを読んでOAuth 2.0を理解するその１ （注意！）この内容は古いので、参考になりませんよ。。。

2. • 名前
• Ryo Ito (id:ritou)
• アカウント
• twitter,friendfeed,hatena : ritou
• ブログ
• r-weblife http://d.hatena.ne.jp/ritou/
• 内容はOpenID/OAuthあたりが多め
• 所属
• OpenID OP かつ OAuth SPな会社
• 2010年5月現在、社会人5年目

3.  2010年5月5日時点で、以下の資料を参考にして
OAuth 2.0の仕様を噛み砕いている自分用メモ
です。
 全てを解説するのは無理なのであとで小分けに
ブログで書く予定ですが、話についてこれる方
は参考にしてみてください。
 The OAuth 2.0 Protocol draft-hammer-
oauth2-00
http://tools.ietf.org/html/draft-hammer-oauth2-00
 Facebook Developers Document
http://developers.facebook.com/docs/authentication
/

4.  今回見ておくところは以下の2点！
› Terminology : 新しい登場人物とかいない？
› AuthZ flow : Clientの特性や環境によって想定さ
れているAccessToken取得までのフロー

5. あまり劇的な変更はなさそう
 resource server : APIサーバ
 protected resource : APIでやりとりされるデータ
 client : Consumer(OAuth 1.0a)
 resource owner
 end user
 access token
 authorization server : SP(OAuth 1.0a)
 authorization endpoint
 token endpoint
 client identifier
 refresh token

6.  OAuth 1.0aでは、ブラウザアプリ/クライアン
トアプリに対するAuthZ flowのみが定義された
 OAuth 2.0では、その他のflowも考慮し、
Access Token取得までの流れが定義される
› The user delegation authZ flows
 ユーザーがClientに権限を委譲
› The end user credentials flow
 ユーザーのID/PWを利用
› The autonomous authZ flows
 ClientがResource owner

7.  The user delegation authZ flows
› User-Agent Flow : JavaScriptなどでAuthZ
› Web Server Flow : Web App Flow(OAuth1.0a)
› Device Flow : Client App Flow(OAuth1.0a)

8. ※仕様ドキュメントから抜粋

9.  JavaScriptなど、User-Agent(ブラウザ)上で処
理が完結されるケースを想定
 AuthZ処理後、 AccessTokenなどがURI
FragmentとしてClientに渡される
 Client側は、 URI Fragmentに含まれるAccess
Tokenなどの値を取得するScriptを用意する
 Facebookはほぼそのままの仕様で実装済み
http://developers.facebook.com/docs/authentication/javascript

10. ※仕様ドキュメントから抜粋

11.  Clientがサーバ間通信可能なWebサーバで
ある状況を想定
 Request/Responseの形式はほぼOAuth
WRAPのWeb App Profileの仕様と同じ
› OAuth 1.0aのRequestTokenのくだりがなくな
る

12.  AuthZ Serverが複数のFlowをサポートする場合、
AuthZ URLは共通でtypeパラメータによりどの
Flowによる要求なのかを判断する
 immediateパラメータにより、OpenIDの
checkid_immediate modeのような、画面を必要
としない処理を要求可能
› ここは別途まとめたいところ
 Access TokenにSecretが必要かどうかはClient側
からsecret_typeというパラメータで指定可能...？
› typeによってこの場合はSecretつき(Web Server Flow)、
Secret不要(User-Agent Flow)のように最初から決めとい
たほうがいいのでは？

13. ※仕様ドキュメントから抜粋

14.  OAuth1.0aのClient App Flowに近いが微妙に
異なる
› ユーザーがAuthZ URLにアクセスし、User Codeを
必ず手動で入力することでユーザー本人の処理を保
証させようとしている
 OAuth 1.0時代のあの問題が再発しないか気に
なる！
› OAuth 1.0aの認可処理後のVerification Code手動
入力はなくなってる
› 悪意のあるユーザーが第3者にAuthZ URLにアクセス
させ、User Codeを入力させたらアウトなような...

15.  The end user credentials flow
› Username and Password Flow : ID/PW入力パ
ターン

16. ※仕様ドキュメントから抜粋
 twitterのxAuthのような、ID/PWをリクエス
トに含む状況を想定
› ID/PW → Access Tokenを行い、Clientは
Access Tokenを保存

17.  The autonomous authZ flows
› Client Credentials Flow : Client ID/Secretを利
用
› Assertion Flow : SAMLのアサーションを利用
！省略！

18.  その２で残りの仕様を見ていく予定です
› Refreshing an Access Token
 Refresh Tokenが任意ということはまたY!のOAuth
は悪者扱いされるんか...
› Accessing a Protected Resource
 署名はどうなる？
› Identifying a Protected Resource...
 ではまた！