Social Web Conference vol.6で発表したスライドです。

1. OAuth 2.0 Dance School
@ritou
SocialWeb Conference vol.6 ～OAuth Night～

2. 自己紹介
• 伊東 諒（@ritou）
• ヤフー株式会社 所属 2006~
– Login
– ログイン履歴/ログインシール/ログインアラート
– OpenID/OAuth
• http://d.hatena.ne.jp/ritou
2

3. 本日のGOAL
• OAuth 1.0仕様の難しさを整理しよう
• 最新仕様 OAuth 2.0を知ろう
• OAuthの今後を少し考えてみよう
3

4. OAuth 1.0の課題
• Signature/Authorization Header
– 仕様が複雑/ライブラリ必須
• User Experience / Profile（Flow）
– 実際使われてるのはWebアプリのみ
– デスクトップアプリにシークレットって置いて良いの？
– Facebookって昔から使いやすいよね
• Performance / Scale
– トークンシークレットって意味あるの？
– 署名の確認に、毎回クライアントクレデンシャル（2個）と
トークンクレデンシャル（2個）の両方が必要
4

5. OAuth 1.0の課題
• Signature/Authorization Header
– 仕様が複雑/ライブラリ必須
• User Experience / Profile（Flow）
– 実際使われてるのはWebアプリのみ
– デスクトップアプリにシークレットって置いて良いの？
– Facebookって昔から使いやすいよね
• Performance / Scale
– トークンシークレットって意味あるの？
– 署名の確認に、毎回クライアントクレデンシャル（2個）と
トークンクレデンシャル（2個）の両方が必要
5

6. OAuth 1.0の課題
• Signature/Authorization Header
– 仕様が複雑/ライブラリ必須
• User Experience / Profile（Flow）
– 実際使われてるのはWebアプリのみ
– デスクトップアプリにシークレットって置いて良いの？
– Facebookって昔から使いやすいよね
• Performance / Scale
– トークンシークレットって意味あるの？
– 署名の確認に、毎回クライアントクレデンシャル（2個）と
トークンクレデンシャル（2個）の両方が必要
6

7. OAuth WRAP登場
• HTTPS必須で署名不要
• トークンのみでリソースアクセス
• 新たなフロー（Profile）
• 対応Provider
– FriendFeed
– Google
これをベースにして作られてるのが。。。
7

8. The OAuth 2.0 Protocol
現在、IETFにて仕様策定中（Draft 10）
http://tools.ietf.org/html/draft-ietf-oauth-v2-10
9月前半で次のDraft（11）が出るっぽい
2010年冬-2011年春？ 仕様Fix
8

9. OAuthの歴史
• 2007/12 OAuth Core 1.0
• 2009/6 OAuth Core 1.0 Revision A
• 2009/7 Yahoo! JAPANもSPに!
• 2009/12 OAuth WRAP
• 2010/4 OAuth 1.0 RFC 5849 = Revision A
• 2010-2011 OAuth 2.0
9

10. 登場人物
End User Authorization
Server
Client Resource Server
10

11. Accessing a Protected Resource
• 必要なのはAccess Tokenのみ
– Signature不要
– Web BrowserとHTTP Cookieのような関係
• 指定方法
– Authorization Header
– URI Query Parameter
– Form-Encoded Body Parameter
11

12. Client Type
Client TypeによりAccess Tokenの取得方法が異なる
• Web Servers
– Webサーバ上で動作。サーバ間通信が可能
• User-Agents
– JSなど、User-Agent上で動作。Secret不要。
• Native Applications
– iPhone/Android App
– Desktop App
• Autonomous Clients
12

13. Profiles（フロー）
• OAuth 2.0の2大フロー
– Web Server Profile
→ Facebook Graph API
– User-Agent Profile
→Twitter @Anywhere
13

14. Web Server Profile
End User Client AuthZ Resource
Server Server
1. Clientにサービス要求
2. AuthZ Serverにリダイレクト
3. 認証/認可処理
4. Clientにリダイレクト
5. Access Token取得
6. Protect Resourceにアクセス
7. Access Token更新
14

15. Facebook Graph API デモ
• https://r-weblife.sakura.ne.jp/oauth2_sample_fb/
15

16. 1. Clientにサービス要求
• Clientにサービスを要
求する
End User Client AServer RServer
16

17. 2. AuthZ Serverにリダイレクト
• Clientは AuthZ Serverの • パラメータ
End-user Authorization – response_type
Endpointにユーザーを送 • “code” : Web Server
る Profile
– client_id
– redirect_uri
End User Client AServer RServer
– scope （option）
– state （option）
17

18. 3. 認証/認可処理
• End Userの本人確認
• Clientにデータを渡すこと
に対する同意取得
End User Client AServer RServer
18

19. 4. Clientにリダイレクト
• AuthZ Server は • パラメータ
Authrozation Codeをパ
ラメータに付加し、 – code
redirect_uriにユーザーを – state （option）
送る
End User Client AServer RServer
19

20. 5. Access Token取得
• Clientは AuthZ Serverの • リクエストパラメータ
Token Endpointに直接通 – grant_type
信を送り、Access Token
• “authorization_code”
を要求
• TLS必須！
– client_id
– client_secret
End User Client AServer RServer – code
– redirect_uri
20

21. 5. Access Token取得
• AuthZ ServerはClientに • JSON フォーマット
Access Token, Refresh • レスポンスパラメータ
Tokenを返す
– access_token
• Access Tokenの有効期
限は短く、Refresh Token – expires_in
を用いて更新する （option）
End User Client AServer RServer – refresh_token
（option）
– scope （option）
21

22. 6. Protect Resourceにアクセス
• ClientはAccess Tokenを • リクエストパラメータ
用いてリソースアクセスを – token
行う
End User Client AServer RServer
22

23. 7. Access Token更新
• Clientは AuthZ Serverの • リクエストパラメータ
Token Endpointに直接通 – grant_type
信を送り、Access Token
• “refresh_token”
の更新を要求
– client_id
– client_secret
End User Client AServer RServer – refresh_token
23

24. 7. Access Token更新
• AuthZ ServerはClientに • JSON フォーマット
新しいAccess Tokenを返 • レスポンスパラメータ
す
– access_token
– expires_in
（option）
End User Client AServer RServer – scope （option）
24

25. User-Agent Profile
End User Client AuthZ Resource
Server Server
1. Clientサービス要求
2. AuthZ Serverにリダイレクト
3. 認証/認可処理
4. Clientにリダイレクト
5. Access Token取得
6. Protect Resourceにアクセス
25

26. Twitter @Anywhere デモ
• https://r-weblife.sakura.ne.jp/oauth2_sample_anywhere/
26

27. 1. Clientにサービス要求
• Clientにサービスを要
求する
End User Client AuthZ Resource
Server Server
27

28. 2. AuthZ Serverにリダイレクト
• Clientは AuthZ Serverの • パラメータ
End-user Authorization – response_type
Endpointにユーザーを送 • “token” : User-Agent
る Profile
– client_id
– redirect_uri
End User Client AuthZ
Server
Resource
Server
– scope （option）
– state （option）
28

29. 3. 認証/認可処理
• End Userの本人確認
• Clientにデータを渡すこと
に対する同意取得
End User Client AuthZ Resource
Server Server
29

30. 4. Clientにリダイレクト
• AuthZ Serverはフラグメン • パラメータ
ト識別子にAccess Token – access_token
の値を付加してユーザーを
redirect_uriに送る – expires_in
（option）
– scope （option）
End User Client AuthZ
Server
Resource
Server – state （option）
30

31. 5. Access Token取得
• JavaScriptなどでフラグメ
ント識別子からAccess
Tokenの値を取得
End User Client AuthZ Resource
Server Server
31

32. 6. Protect Resourceにアクセス
• ClientはAccess Tokenを • リクエストパラメータ
用いてリソースアクセスを – token
行う
End User Client AuthZ Resource
Server Server
32

33. Native Application
ガイドラインのようなものが記載されている
• 外部ブラウザを立ち上げる
– カスタムURIスキームなどを用いてシームレスに
• 内臓ブラウザを利用
– セキュリティに難あり？
• ユーザーのID/PWを利用（非推奨）
– SignatureなしのxAuth
33

34. OAuth 2.0 メリット
• シンプルな仕様
– 1.0aにあったRequest Tokenがなくなった
– Signatureに悩まされなくなる
– User-Agent上で動作するClientの実装が可能
になった
• 他のシステム/プラットフォームと連携可能
– 2legged OAuth
– SAML
34

35. OAuth 2.0 で気になること
• URLが長くなる？（→JPのモバイルに影響）
– 1.0aのRequestTokenはURL短縮という意味で
はよかったのかも
• Core部分以外の仕様があいまい
– Scope, User Identifier…
• いまさらだけど、本当に署名なくて大丈夫？
今後の仕様に期待！
35

36. OpenIDとOAuthの関係
• OpenID Auth 2.0 vs OAuth 1.0
– OAuth 1.0の方がSexy？
– Hybridで（むりやり？）共存可能
• 両方の機能持っていないといけない
• モバイルフローに課題
• OpenID v.Next vs OAuth 2.0
– OAuth 2.0ベース or 互換性をもった形になる！
36

37. OAuthの未来
• 全てのリソースアクセスをOAuthが担う
– ソーシャル系からPIM、決済、POP/IMAPまで
• 他のプロトコルやプラットフォームとの連携
– SAML,OpenID,OpenSocial…
• 端末に縛られない！
– Web/Mobileアプリからデジタル家電まで対応
できるClient Profile
37

38. そんな未来を目指すために
• OAuthでシングルサインオン
• フィッシング対策
• 認可範囲など、細かい考え方
日本とUSはいろいろ考えが違うので、議論しながら
日本独自の拡張をみんなで考えていきたい
http://oauth.jp/
38

39. これからもOAuthを盛り上げて行きましょう！
39

40. 最後にちょっと告知
• Yahoo! JAPANはOAuthのSP機能につい
て、改修を行いました
– SSO機能の利便性向上
• 「パスワード入力の省略」機能
– ユーザーの利便性向上
• 「次回から同意省略」機能
– クライアントアプリ対応（パートナー企業様限定）
• カスタムURIスキーム対応
• あとでTech Blogなどで紹介します！
40

41. 御静聴ありがとうございました
41