•   名前
    • Ryo Ito   (id:ritou)
•   アカウント
    • twitter,friendfeed,hatena : ritou
•   ブログ
    • r-weblife http://d.haten...
 2010年5月5日時点で、以下の資料を参考にして
  OAuth 2.0の仕様を噛み砕いている自分用メモ
  です。
 全てを解説するのは無理なのであとで小分けに
  ブログで書く予定ですが、話についてこれる方
  は参考にしてみてくださ...
   今回見ておくところは以下の2点!
    › Terminology : 新しい登場人物とかいない?
    › AuthZ flow : Clientの特性や環境によって想定さ
     れているAccessToken取得までのフロー
あまり劇的な変更はなさそう
 resource server : APIサーバ
 protected resource : APIでやりとりされるデータ
 client : Consumer(OAuth 1.0a)
 resource ...
 OAuth 1.0aでは、ブラウザアプリ/クライアン
  トアプリに対するAuthZ flowのみが定義された
 OAuth 2.0では、その他のflowも考慮し、
  Access Token取得までの流れが定義される
    › Th...
   The user delegation authZ flows
    › User-Agent Flow : JavaScriptなどでAuthZ
    › Web Server Flow : Web App Flow(OAuth1...
※仕様ドキュメントから抜粋
 JavaScriptなど、User-Agent(ブラウザ)上で処
  理が完結されるケースを想定
 AuthZ処理後、 AccessTokenなどがURI
  FragmentとしてClientに渡される
 Client側は、 URI ...
※仕様ドキュメントから抜粋
 Clientがサーバ間通信可能なWebサーバで
  ある状況を想定
 Request/Responseの形式はほぼOAuth
  WRAPのWeb App Profileの仕様と同じ
    › OAuth 1.0aのRequestTok...
   AuthZ Serverが複数のFlowをサポートする場合、
    AuthZ URLは共通でtypeパラメータによりどの
    Flowによる要求なのかを判断する
   immediateパラメータにより、OpenIDの
   ...
※仕様ドキュメントから抜粋
   OAuth1.0aのClient App Flowに近いが微妙に
    異なる
    › ユーザーがAuthZ URLにアクセスし、User Codeを
     必ず手動で入力することでユーザー本人の処理を保
     証させよう...
   The end user credentials flow
    › Username and Password Flow : ID/PW入力パ
      ターン
※仕様ドキュメントから抜粋




   twitterのxAuthのような、ID/PWをリクエス
    トに含む状況を想定
    › ID/PW → Access Tokenを行い、Clientは
     Access Tokenを保存
   The autonomous authZ flows
    › Client Credentials Flow : Client ID/Secretを利
      用
    › Assertion Flow : SAMLのアサーシ...
   その2で残りの仕様を見ていく予定です
    › Refreshing an Access Token
        Refresh Tokenが任意ということはまたY!のOAuth
         は悪者扱いされるんか...
 ...
Introduction of OAuth 2.0 vol.1
Upcoming SlideShare
Loading in...5
×

Introduction of OAuth 2.0 vol.1

2,636

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,636
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Introduction of OAuth 2.0 vol.1"

  1. 1. • 名前 • 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年目
  2. 2.  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 /
  3. 3.  今回見ておくところは以下の2点! › Terminology : 新しい登場人物とかいない? › AuthZ flow : Clientの特性や環境によって想定さ れているAccessToken取得までのフロー
  4. 4. あまり劇的な変更はなさそう  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
  5. 5.  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
  6. 6.  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)
  7. 7. ※仕様ドキュメントから抜粋
  8. 8.  JavaScriptなど、User-Agent(ブラウザ)上で処 理が完結されるケースを想定  AuthZ処理後、 AccessTokenなどがURI FragmentとしてClientに渡される  Client側は、 URI Fragmentに含まれるAccess Tokenなどの値を取得するScriptを用意する  Facebookはほぼそのままの仕様で実装済み http://developers.facebook.com/docs/authentication/javascript
  9. 9. ※仕様ドキュメントから抜粋
  10. 10.  Clientがサーバ間通信可能なWebサーバで ある状況を想定  Request/Responseの形式はほぼOAuth WRAPのWeb App Profileの仕様と同じ › OAuth 1.0aのRequestTokenのくだりがなくな る
  11. 11.  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)のように最初から決めとい たほうがいいのでは?
  12. 12. ※仕様ドキュメントから抜粋
  13. 13.  OAuth1.0aのClient App Flowに近いが微妙に 異なる › ユーザーがAuthZ URLにアクセスし、User Codeを 必ず手動で入力することでユーザー本人の処理を保 証させようとしている  OAuth 1.0時代のあの問題が再発しないか気に なる! › OAuth 1.0aの認可処理後のVerification Code手動 入力はなくなってる › 悪意のあるユーザーが第3者にAuthZ URLにアクセス させ、User Codeを入力させたらアウトなような...
  14. 14.  The end user credentials flow › Username and Password Flow : ID/PW入力パ ターン
  15. 15. ※仕様ドキュメントから抜粋  twitterのxAuthのような、ID/PWをリクエス トに含む状況を想定 › ID/PW → Access Tokenを行い、Clientは Access Tokenを保存
  16. 16.  The autonomous authZ flows › Client Credentials Flow : Client ID/Secretを利 用 › Assertion Flow : SAMLのアサーションを利用 !省略!
  17. 17.  その2で残りの仕様を見ていく予定です › Refreshing an Access Token  Refresh Tokenが任意ということはまたY!のOAuth は悪者扱いされるんか... › Accessing a Protected Resource  署名はどうなる? › Identifying a Protected Resource...  ではまた!

×