Mais conteúdo relacionado
Semelhante a Introduction of OAuth 2.0 vol.1 (20)
Introduction of OAuth 2.0 vol.1
- 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)
- 9. JavaScriptなど、User-Agent(ブラウザ)上で処
理が完結されるケースを想定
AuthZ処理後、 AccessTokenなどがURI
FragmentとしてClientに渡される
Client側は、 URI Fragmentに含まれるAccess
Tokenなどの値を取得するScriptを用意する
Facebookはほぼそのままの仕様で実装済み
http://developers.facebook.com/docs/authentication/javascript
- 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)のように最初から決めとい
たほうがいいのでは?
- 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. その2で残りの仕様を見ていく予定です
› Refreshing an Access Token
Refresh Tokenが任意ということはまたY!のOAuth
は悪者扱いされるんか...
› Accessing a Protected Resource
署名はどうなる?
› Identifying a Protected Resource...
ではまた!