SlideShare ist ein Scribd-Unternehmen logo
1 von 27
OAuth 2.0 draft 12で出てきた
 MAC Authenticationとは

              @ritou
     http://twitter.com/ritou
   http://d.hatena.ne.jp/ritou/
OAuth 2.0 draft 12の説明
• http://tools.ietf.org/html/draft-ietf-oauth-v2-12
• Clientは、Access Tokenを用いて
  protected resourcesにアクセスする
• Access Tokenの使用方法はAuthZ Server
  から発行されたAccess TokenのTypeに依
  存する
   – Token Type “mac” はなんとかかんとか
   ↑これ気になるので調べる

                                                      2
HTTP Authentication:
       MAC Authentication
• 2011/1/30時点
  – http://tools.ietf.org/html/draft-hammer-oauth-
    v2-mac-token-02




                                                     3
一言で言うと
• Access Token,Secret,MACアルゴリズム
  を使った署名付きHTTPリクエストの作り方!




                                  4
Example
• とりあえずどんな感じで使われるのか、流れ
  を見てみる




                         5
Example(1)
• こんな感じで何も考えずリソースアクセス
 GET /resource/1?b=1&a=2
 HTTP/1.1 Host: example.com


• 結果は、エラー!
 HTTP/1.1 401 Unauthorized
 WWW-Authenticate: MAC realm="example"
 Date: Thu, 02 Dec 2010 21:39:45 GMT


                                         6
Example(2)
• 実は事前にToken Credentialのセットを持
  っていた
 Access Token: h480djs93hd8
 Token Secret: 489dks293j39
 MAC Algorithm: hmac-sha-1
• HTTPリクエストを作るために、以下の2つの
  値を計算する
 Timestamp: 137131200
 Nonce: dj83hs9s

                                7
Example(3)
• 署名を作るために正規化
 h480djs93hd8
 137131200
 dj83hs9s

 GET
 example.com
 80
 /resource/1
 a=2
 b=1                         8
Example(4)
• Token SecretとMAC algorithmで指定さ
  れた方法で署名を作成
 YTVjyNSujYs1WsDurFnvFi4JK6o=




                                   9
Example(5)
• HTTP Authorization Headerにいろいろと
  詰め込んでHTTP Requestを作成
 GET /resource/1 HTTP/1.1 Host: example.com
 Authorization: MAC
 token="h480djs93hd8",
 timestamp="137131200",
 nonce="dj83hs9s",
 signature="YTVjyNSujYs1WsDurFnvFi4JK6o="



                                              10
Example終わり
• OAuth 1.0系でおなじみの署名作成+AuthZ
  Header作成処理に似ている
 – 1.0系では、全てのリソースアクセスにClient
   CredentialとToken Credentialの両方が必要
   なのでScaleしないとか言われていた
 – この仕様ではToken Credentialのみで署名を
   作成するイメージ



                                   11
ざっくり内容まとめ
• Issuing MAC Credentials
• The "Authorization" Request Header
• Body Hash
• Signature
• Verifying Requests
• Use with OAuth 2.0
• Security Considerations
• IANA Considerations
                                       12
Issuing MAC Credentials
• 必要な値はこちら
 – access token
   • この説明は省略!
 – secret
   • 共有秘密鍵って感じの値
 – algorithm
   • 署名計算に利用するMAC algorithm
   • “hmac-sha-1”, “hmac-sha-256“もしくは登録され
     たもの(まだこのへん未定義)

                                        13
The "Authorization" Request
          Header
• AuthZ Headerのフォーマット
 credentials = 'MAC' [ RWS 1#param ]
 param = access-token /
           timestamp /
           nonce /
           body-hash /
           signature
 access-token = 'token' '=' <"> plain-string <">
 timestamp = 'timestamp' '=' <"> 1*DIGIT <">
 nonce = 'nonce' '=' <"> plain-string <">
 body-hash = 'bodyhash' '=' <"> plain-string <">
 signature = 'signature' '=' <"> plain-string <">
 plain-string = 1*( DIGIT / ALPHA / %x20-21 / %x23-5B / %x5D-7E )
                                                                    14
Header attributes
•   token : 【必須】 Access Token
•   timestamp : 【必須】
•   nonce : 【必須】ユニークでランダムな文字列
•   bodyhash : 【任意】 このあと説明
•   signature : 【必須】 署名




                                15
Body Hash
• Requestのentity-bodyのHash値を計算し
  たもの
 bodyhash = BASE64 ( HASH (text) )
 –   Hash : 指定されたHashアルゴリズム
 –   text : HTTP request entity-body
 –   BASE64 : base64-encoding関数
 –   bodyhash : AuthZ Headerに指定する値
• OAuth 1.0系でもOAuth Request Body
  Hashという拡張仕様がある
                                       16
Signature
• Normalized Request String
  – いわゆるSignature base stringの作成
• hmac-sha-1/hmac-sha-256
  – Hash値を計算




                                   17
Normalized Request String
• 以下の値を連結
 –   Access Token
 –   timestamp
 –   nonce
 –   request entity-body hash(任意)
 –   HTTP request method
 –   hostname
 –   port
 –   URI Path
 –   URI query (この詳細は3.3.1.1を見れ!)
                                    18
Parameters Normalization
• クエリパラメータの処理
 –   percent-encodingでエスケープ
 –   Key,valueを=でつなぐ
 –   ascending byte value orderingでソート
 –   改行コード(ASCII code 10)を使って結合




                                         19
hmac-sha-1/hmac-sha-256
• algorithmにしたがってSignatureを作成
 – hmac-sha-1
   digest = HMAC-SHA1 (key, text)
 – hmac-sha-256
   digest = HMAC-SHA256 (key, text)




                                      20
Verifying Requests
• Resource Server側の検証処理
 1. bodyhash, signatureの再計算を行い、
    Requestの値と比較
 2. timestamp,nonce,access tokenの検証
 3. access tokenのscopeとstatusの確認
• 検証に失敗した場合は、HTTP
  401(unauthorized)を返すべき


                                      21
The "WWW-Authenticate"
   Response Header Field
• レスポンスのフォーマット
 challenge = "MAC" [ RWS 1#param ]
 param = realm / error / auth-param
 error = "error" "=" quoted-string
 – サンプル
 HTTP/1.1 401 Unauthorized
 WWW-Authenticate: MAC realm="example“
 HTTP/1.1 401 Unauthorized
 WWW-Authenticate: MAC realm="example"
                         error="The access token expired"
                                                       22
Use with OAuth 2.0
• この仕様は、OAuth 2.0のMAC Token
  Typeを定める
• ただし、以下についてはこの仕様で定めない
 – MAC TypeのTokenの要求方法
 – どのHMACアルゴリズムをサポートしているか等
   のDiscovery機能




                          23
Issuing MAC-Type Access
           Tokens
• とりあえず、Access Tokenと一緒に以下の
  値が必要
 – secret : 共有秘密鍵
 – algorithm : hmac-sha-1, hmac-sha-256もし
   くは今後登録されるアルゴリズム




                                        24
IANA Considerations
• 下記のAccess Token TypeをRegistryに登
  録する
 – “mac”
• 下記のパラメータをRegistryに登録する
 – “secret”
 – “algorithm”

 登録ってめんどいね。。。

                                25
そういえば
• OAuth 2.0では、当初からSecretを必要とし
  ないbearer tokenの形式を利用することが
  提案されたが、”やっぱり署名も必要なんじゃ
  ねーの?”という意見もあった
 – これを使うと、HTTP Requestが”正しいToken
   Credentialの持ち主”によって作られたことを確
   認できる と思われる



                               26
終わり
• 続きはまたブログで!

 http://d.hatena.ne.jp/ritou/




                                27

Weitere ähnliche Inhalte

Ähnlich wie OAuth 2.0 MAC Authentication

Twitter連携chrome extension作り方
Twitter連携chrome extension作り方Twitter連携chrome extension作り方
Twitter連携chrome extension作り方
Hiroshi Oyamada
 
Beginning Java EE 6 勉強会(7) #bje_study
Beginning Java EE 6 勉強会(7) #bje_studyBeginning Java EE 6 勉強会(7) #bje_study
Beginning Java EE 6 勉強会(7) #bje_study
ikeyat
 
ASP.NET シングル ページ アプリケーション (SPA) 詳説
ASP.NET シングル ページ アプリケーション (SPA) 詳説ASP.NET シングル ページ アプリケーション (SPA) 詳説
ASP.NET シングル ページ アプリケーション (SPA) 詳説
Akira Inoue
 

Ähnlich wie OAuth 2.0 MAC Authentication (20)

OSS開発勉強会
OSS開発勉強会OSS開発勉強会
OSS開発勉強会
 
ログ管理のベストプラクティス
ログ管理のベストプラクティスログ管理のベストプラクティス
ログ管理のベストプラクティス
 
後期02
後期02後期02
後期02
 
Status 425 HTTP/Tokyo
Status 425 HTTP/Tokyo Status 425 HTTP/Tokyo
Status 425 HTTP/Tokyo
 
OpenStack API
OpenStack APIOpenStack API
OpenStack API
 
Twitter連携chrome extension作り方
Twitter連携chrome extension作り方Twitter連携chrome extension作り方
Twitter連携chrome extension作り方
 
Couchbase MeetUP Tokyo - #11 Omoidenote
Couchbase MeetUP Tokyo - #11 OmoidenoteCouchbase MeetUP Tokyo - #11 Omoidenote
Couchbase MeetUP Tokyo - #11 Omoidenote
 
OAuth Echo の Rails Gem
OAuth Echo の Rails GemOAuth Echo の Rails Gem
OAuth Echo の Rails Gem
 
Web packaging IETF 側
Web packaging IETF 側Web packaging IETF 側
Web packaging IETF 側
 
OAuth 2.0 と ライブラリ
OAuth 2.0 と ライブラリOAuth 2.0 と ライブラリ
OAuth 2.0 と ライブラリ
 
クラウドインターネットルータ
クラウドインターネットルータクラウドインターネットルータ
クラウドインターネットルータ
 
Beginning Java EE 6 勉強会(7) #bje_study
Beginning Java EE 6 勉強会(7) #bje_studyBeginning Java EE 6 勉強会(7) #bje_study
Beginning Java EE 6 勉強会(7) #bje_study
 
20120423 hbase勉強会
20120423 hbase勉強会20120423 hbase勉強会
20120423 hbase勉強会
 
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
Mobage Connect と Identity 関連技術への取り組み - OpenID Summit Tokyo 2015
 
Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Hokkaido.cap #osc11do Wiresharkを使いこなそう!Hokkaido.cap #osc11do Wiresharkを使いこなそう!
Hokkaido.cap #osc11do Wiresharkを使いこなそう!
 
ASP.NET シングル ページ アプリケーション (SPA) 詳説
ASP.NET シングル ページ アプリケーション (SPA) 詳説ASP.NET シングル ページ アプリケーション (SPA) 詳説
ASP.NET シングル ページ アプリケーション (SPA) 詳説
 
Web基礎
Web基礎Web基礎
Web基礎
 
AWS は形式手法の夢を見るか? - モデル検査器 Alloy によるインフラ設計
AWS は形式手法の夢を見るか? - モデル検査器 Alloy によるインフラ設計AWS は形式手法の夢を見るか? - モデル検査器 Alloy によるインフラ設計
AWS は形式手法の夢を見るか? - モデル検査器 Alloy によるインフラ設計
 
さくらのDockerコンテナホスティング-Arukasの解説とインフラを支える技術(July Tech Festa 2016 『IoTxAIxインフラ時代...
さくらのDockerコンテナホスティング-Arukasの解説とインフラを支える技術(July Tech Festa 2016 『IoTxAIxインフラ時代...さくらのDockerコンテナホスティング-Arukasの解説とインフラを支える技術(July Tech Festa 2016 『IoTxAIxインフラ時代...
さくらのDockerコンテナホスティング-Arukasの解説とインフラを支える技術(July Tech Festa 2016 『IoTxAIxインフラ時代...
 
Akka HTTP
Akka HTTPAkka HTTP
Akka HTTP
 

Mehr von Ryo Ito

OpenID-TechNight-11-LT-mixi
OpenID-TechNight-11-LT-mixiOpenID-TechNight-11-LT-mixi
OpenID-TechNight-11-LT-mixi
Ryo Ito
 
なんとなくOAuth怖いって思ってるやつちょっと来い
なんとなくOAuth怖いって思ってるやつちょっと来いなんとなくOAuth怖いって思ってるやつちょっと来い
なんとなくOAuth怖いって思ってるやつちょっと来い
Ryo Ito
 
UserManagedAccess_idcon13
UserManagedAccess_idcon13UserManagedAccess_idcon13
UserManagedAccess_idcon13
Ryo Ito
 
WebIntents × SNS
WebIntents × SNSWebIntents × SNS
WebIntents × SNS
Ryo Ito
 
OpenID_Connect_Spec_Demo
OpenID_Connect_Spec_DemoOpenID_Connect_Spec_Demo
OpenID_Connect_Spec_Demo
Ryo Ito
 
Ritou idcon7
Ritou idcon7Ritou idcon7
Ritou idcon7
Ryo Ito
 

Mehr von Ryo Ito (20)

安全な"○○でログイン"の作り方 @ NDS in Niigata #1
安全な"○○でログイン"の作り方 @ NDS in Niigata #1安全な"○○でログイン"の作り方 @ NDS in Niigata #1
安全な"○○でログイン"の作り方 @ NDS in Niigata #1
 
idcon mini vol3 CovertRedirect
idcon mini vol3 CovertRedirectidcon mini vol3 CovertRedirect
idcon mini vol3 CovertRedirect
 
OpenID-TechNight-11-LT-mixi
OpenID-TechNight-11-LT-mixiOpenID-TechNight-11-LT-mixi
OpenID-TechNight-11-LT-mixi
 
Idcon 17th ritou OAuth 2.0 CSRF Protection
Idcon 17th ritou OAuth 2.0 CSRF ProtectionIdcon 17th ritou OAuth 2.0 CSRF Protection
Idcon 17th ritou OAuth 2.0 CSRF Protection
 
なんとなくOAuth怖いって思ってるやつちょっと来い
なんとなくOAuth怖いって思ってるやつちょっと来いなんとなくOAuth怖いって思ってるやつちょっと来い
なんとなくOAuth怖いって思ってるやつちょっと来い
 
#idcon 15th ritou 2factor auth
#idcon 15th ritou 2factor auth#idcon 15th ritou 2factor auth
#idcon 15th ritou 2factor auth
 
Open id connect claims idcon mini vol1
Open id connect claims idcon mini vol1Open id connect claims idcon mini vol1
Open id connect claims idcon mini vol1
 
OID to OIDC idcon mini vol1
OID to OIDC idcon mini vol1OID to OIDC idcon mini vol1
OID to OIDC idcon mini vol1
 
Account Chooser idcon mini Vol.1
Account Chooser idcon mini Vol.1Account Chooser idcon mini Vol.1
Account Chooser idcon mini Vol.1
 
BackplaneProtocol超入門
BackplaneProtocol超入門BackplaneProtocol超入門
BackplaneProtocol超入門
 
UserManagedAccess_idcon13
UserManagedAccess_idcon13UserManagedAccess_idcon13
UserManagedAccess_idcon13
 
WebIntents × SNS
WebIntents × SNSWebIntents × SNS
WebIntents × SNS
 
Idcon11 implicit demo
Idcon11 implicit demoIdcon11 implicit demo
Idcon11 implicit demo
 
OpenID_Connect_Spec_Demo
OpenID_Connect_Spec_DemoOpenID_Connect_Spec_Demo
OpenID_Connect_Spec_Demo
 
OAuth 2.0 Dance School #swj
OAuth 2.0 Dance School #swj OAuth 2.0 Dance School #swj
OAuth 2.0 Dance School #swj
 
Ritou idcon7
Ritou idcon7Ritou idcon7
Ritou idcon7
 
Summary of OAuth 2.0 draft 8 memo
Summary of OAuth 2.0 draft 8 memoSummary of OAuth 2.0 draft 8 memo
Summary of OAuth 2.0 draft 8 memo
 
Introduction of OAuth 2.0 vol.1
Introduction of OAuth 2.0 vol.1Introduction of OAuth 2.0 vol.1
Introduction of OAuth 2.0 vol.1
 
0905xx Hybrid Memo
0905xx Hybrid Memo0905xx Hybrid Memo
0905xx Hybrid Memo
 
Anonymous OAuth Test
Anonymous OAuth TestAnonymous OAuth Test
Anonymous OAuth Test
 

OAuth 2.0 MAC Authentication

  • 1. OAuth 2.0 draft 12で出てきた MAC Authenticationとは @ritou http://twitter.com/ritou http://d.hatena.ne.jp/ritou/
  • 2. OAuth 2.0 draft 12の説明 • http://tools.ietf.org/html/draft-ietf-oauth-v2-12 • Clientは、Access Tokenを用いて protected resourcesにアクセスする • Access Tokenの使用方法はAuthZ Server から発行されたAccess TokenのTypeに依 存する – Token Type “mac” はなんとかかんとか ↑これ気になるので調べる 2
  • 3. HTTP Authentication: MAC Authentication • 2011/1/30時点 – http://tools.ietf.org/html/draft-hammer-oauth- v2-mac-token-02 3
  • 4. 一言で言うと • Access Token,Secret,MACアルゴリズム を使った署名付きHTTPリクエストの作り方! 4
  • 6. Example(1) • こんな感じで何も考えずリソースアクセス GET /resource/1?b=1&a=2 HTTP/1.1 Host: example.com • 結果は、エラー! HTTP/1.1 401 Unauthorized WWW-Authenticate: MAC realm="example" Date: Thu, 02 Dec 2010 21:39:45 GMT 6
  • 7. Example(2) • 実は事前にToken Credentialのセットを持 っていた Access Token: h480djs93hd8 Token Secret: 489dks293j39 MAC Algorithm: hmac-sha-1 • HTTPリクエストを作るために、以下の2つの 値を計算する Timestamp: 137131200 Nonce: dj83hs9s 7
  • 8. Example(3) • 署名を作るために正規化 h480djs93hd8 137131200 dj83hs9s GET example.com 80 /resource/1 a=2 b=1 8
  • 9. Example(4) • Token SecretとMAC algorithmで指定さ れた方法で署名を作成 YTVjyNSujYs1WsDurFnvFi4JK6o= 9
  • 10. Example(5) • HTTP Authorization Headerにいろいろと 詰め込んでHTTP Requestを作成 GET /resource/1 HTTP/1.1 Host: example.com Authorization: MAC token="h480djs93hd8", timestamp="137131200", nonce="dj83hs9s", signature="YTVjyNSujYs1WsDurFnvFi4JK6o=" 10
  • 11. Example終わり • OAuth 1.0系でおなじみの署名作成+AuthZ Header作成処理に似ている – 1.0系では、全てのリソースアクセスにClient CredentialとToken Credentialの両方が必要 なのでScaleしないとか言われていた – この仕様ではToken Credentialのみで署名を 作成するイメージ 11
  • 12. ざっくり内容まとめ • Issuing MAC Credentials • The "Authorization" Request Header • Body Hash • Signature • Verifying Requests • Use with OAuth 2.0 • Security Considerations • IANA Considerations 12
  • 13. Issuing MAC Credentials • 必要な値はこちら – access token • この説明は省略! – secret • 共有秘密鍵って感じの値 – algorithm • 署名計算に利用するMAC algorithm • “hmac-sha-1”, “hmac-sha-256“もしくは登録され たもの(まだこのへん未定義) 13
  • 14. The "Authorization" Request Header • AuthZ Headerのフォーマット credentials = 'MAC' [ RWS 1#param ] param = access-token / timestamp / nonce / body-hash / signature access-token = 'token' '=' <"> plain-string <"> timestamp = 'timestamp' '=' <"> 1*DIGIT <"> nonce = 'nonce' '=' <"> plain-string <"> body-hash = 'bodyhash' '=' <"> plain-string <"> signature = 'signature' '=' <"> plain-string <"> plain-string = 1*( DIGIT / ALPHA / %x20-21 / %x23-5B / %x5D-7E ) 14
  • 15. Header attributes • token : 【必須】 Access Token • timestamp : 【必須】 • nonce : 【必須】ユニークでランダムな文字列 • bodyhash : 【任意】 このあと説明 • signature : 【必須】 署名 15
  • 16. Body Hash • Requestのentity-bodyのHash値を計算し たもの bodyhash = BASE64 ( HASH (text) ) – Hash : 指定されたHashアルゴリズム – text : HTTP request entity-body – BASE64 : base64-encoding関数 – bodyhash : AuthZ Headerに指定する値 • OAuth 1.0系でもOAuth Request Body Hashという拡張仕様がある 16
  • 17. Signature • Normalized Request String – いわゆるSignature base stringの作成 • hmac-sha-1/hmac-sha-256 – Hash値を計算 17
  • 18. Normalized Request String • 以下の値を連結 – Access Token – timestamp – nonce – request entity-body hash(任意) – HTTP request method – hostname – port – URI Path – URI query (この詳細は3.3.1.1を見れ!) 18
  • 19. Parameters Normalization • クエリパラメータの処理 – percent-encodingでエスケープ – Key,valueを=でつなぐ – ascending byte value orderingでソート – 改行コード(ASCII code 10)を使って結合 19
  • 20. hmac-sha-1/hmac-sha-256 • algorithmにしたがってSignatureを作成 – hmac-sha-1 digest = HMAC-SHA1 (key, text) – hmac-sha-256 digest = HMAC-SHA256 (key, text) 20
  • 21. Verifying Requests • Resource Server側の検証処理 1. bodyhash, signatureの再計算を行い、 Requestの値と比較 2. timestamp,nonce,access tokenの検証 3. access tokenのscopeとstatusの確認 • 検証に失敗した場合は、HTTP 401(unauthorized)を返すべき 21
  • 22. The "WWW-Authenticate" Response Header Field • レスポンスのフォーマット challenge = "MAC" [ RWS 1#param ] param = realm / error / auth-param error = "error" "=" quoted-string – サンプル HTTP/1.1 401 Unauthorized WWW-Authenticate: MAC realm="example“ HTTP/1.1 401 Unauthorized WWW-Authenticate: MAC realm="example" error="The access token expired" 22
  • 23. Use with OAuth 2.0 • この仕様は、OAuth 2.0のMAC Token Typeを定める • ただし、以下についてはこの仕様で定めない – MAC TypeのTokenの要求方法 – どのHMACアルゴリズムをサポートしているか等 のDiscovery機能 23
  • 24. Issuing MAC-Type Access Tokens • とりあえず、Access Tokenと一緒に以下の 値が必要 – secret : 共有秘密鍵 – algorithm : hmac-sha-1, hmac-sha-256もし くは今後登録されるアルゴリズム 24
  • 25. IANA Considerations • 下記のAccess Token TypeをRegistryに登 録する – “mac” • 下記のパラメータをRegistryに登録する – “secret” – “algorithm” 登録ってめんどいね。。。 25
  • 26. そういえば • OAuth 2.0では、当初からSecretを必要とし ないbearer tokenの形式を利用することが 提案されたが、”やっぱり署名も必要なんじゃ ねーの?”という意見もあった – これを使うと、HTTP Requestが”正しいToken Credentialの持ち主”によって作られたことを確 認できる と思われる 26