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にアク...
HTTP Authentication:       MAC Authentication• 2011/1/30時点  – http://tools.ietf.org/html/draft-hammer-oauth-    v2-mac-tok...
一言で言うと• 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...
Example(2)• 実は事前にToken Credentialのセットを持  っていた Access Token: h480djs93hd8 Token Secret: 489dks293j39 MAC Algorithm: hmac-sh...
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...
Example終わり• OAuth 1.0系でおなじみの署名作成+AuthZ  Header作成処理に似ている – 1.0系では、全てのリソースアクセスにClient   CredentialとToken Credentialの両方が必要   ...
ざっくり内容まとめ• Issuing MAC Credentials• The "Authorization" Request Header• Body Hash• Signature• Verifying Requests• Use with...
Issuing MAC Credentials• 必要な値はこちら – access token   • この説明は省略! – secret   • 共有秘密鍵って感じの値 – algorithm   • 署名計算に利用するMAC algori...
The "Authorization" Request          Header• AuthZ Headerのフォーマット credentials = MAC [ RWS 1#param ] param = access-token / ...
Header attributes•   token : 【必須】 Access Token•   timestamp : 【必須】•   nonce : 【必須】ユニークでランダムな文字列•   bodyhash : 【任意】 このあと説明•...
Body Hash• Requestのentity-bodyのHash値を計算し  たもの bodyhash = BASE64 ( HASH (text) ) –   Hash : 指定されたHashアルゴリズム –   text : HTTP...
Signature• Normalized Request String  – いわゆるSignature base stringの作成• hmac-sha-1/hmac-sha-256  – Hash値を計算                 ...
Normalized Request String• 以下の値を連結 –   Access Token –   timestamp –   nonce –   request entity-body hash(任意) –   HTTP requ...
Parameters Normalization• クエリパラメータの処理 –   percent-encodingでエスケープ –   Key,valueを=でつなぐ –   ascending byte value orderingでソート...
hmac-sha-1/hmac-sha-256• algorithmにしたがってSignatureを作成 – hmac-sha-1   digest = HMAC-SHA1 (key, text) – hmac-sha-256   digest...
Verifying Requests• Resource Server側の検証処理 1. bodyhash, signatureの再計算を行い、    Requestの値と比較 2. timestamp,nonce,access tokenの検...
The "WWW-Authenticate"   Response Header Field• レスポンスのフォーマット challenge = "MAC" [ RWS 1#param ] param = realm / error / aut...
Use with OAuth 2.0• この仕様は、OAuth 2.0のMAC Token  Typeを定める• ただし、以下についてはこの仕様で定めない – MAC TypeのTokenの要求方法 – どのHMACアルゴリズムをサポートしてい...
Issuing MAC-Type Access           Tokens• とりあえず、Access Tokenと一緒に以下の  値が必要 – secret : 共有秘密鍵 – algorithm : hmac-sha-1, hmac-...
IANA Considerations• 下記のAccess Token TypeをRegistryに登  録する – “mac”• 下記のパラメータをRegistryに登録する – “secret” – “algorithm” 登録ってめんど...
そういえば• OAuth 2.0では、当初からSecretを必要とし  ないbearer tokenの形式を利用することが  提案されたが、”やっぱり署名も必要なんじゃ  ねーの?”という意見もあった – これを使うと、HTTP Request...
終わり• 続きはまたブログで! http://d.hatena.ne.jp/ritou/                                27
Upcoming SlideShare
Loading in …5
×

OAuth 2.0 MAC Authentication

3,412 views

Published on

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,412
On SlideShare
0
From Embeds
0
Number of Embeds
750
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

OAuth 2.0 MAC Authentication

  1. 1. OAuth 2.0 draft 12で出てきた MAC Authenticationとは @ritou http://twitter.com/ritou http://d.hatena.ne.jp/ritou/
  2. 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. 3. HTTP Authentication: MAC Authentication• 2011/1/30時点 – http://tools.ietf.org/html/draft-hammer-oauth- v2-mac-token-02 3
  4. 4. 一言で言うと• Access Token,Secret,MACアルゴリズム を使った署名付きHTTPリクエストの作り方! 4
  5. 5. Example• とりあえずどんな感じで使われるのか、流れ を見てみる 5
  6. 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. 7. Example(2)• 実は事前にToken Credentialのセットを持 っていた Access Token: h480djs93hd8 Token Secret: 489dks293j39 MAC Algorithm: hmac-sha-1• HTTPリクエストを作るために、以下の2つの 値を計算する Timestamp: 137131200 Nonce: dj83hs9s 7
  8. 8. Example(3)• 署名を作るために正規化 h480djs93hd8 137131200 dj83hs9s GET example.com 80 /resource/1 a=2 b=1 8
  9. 9. Example(4)• Token SecretとMAC algorithmで指定さ れた方法で署名を作成 YTVjyNSujYs1WsDurFnvFi4JK6o= 9
  10. 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. 11. Example終わり• OAuth 1.0系でおなじみの署名作成+AuthZ Header作成処理に似ている – 1.0系では、全てのリソースアクセスにClient CredentialとToken Credentialの両方が必要 なのでScaleしないとか言われていた – この仕様ではToken Credentialのみで署名を 作成するイメージ 11
  12. 12. ざっくり内容まとめ• Issuing MAC Credentials• The "Authorization" Request Header• Body Hash• Signature• Verifying Requests• Use with OAuth 2.0• Security Considerations• IANA Considerations 12
  13. 13. Issuing MAC Credentials• 必要な値はこちら – access token • この説明は省略! – secret • 共有秘密鍵って感じの値 – algorithm • 署名計算に利用するMAC algorithm • “hmac-sha-1”, “hmac-sha-256“もしくは登録され たもの(まだこのへん未定義) 13
  14. 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. 15. Header attributes• token : 【必須】 Access Token• timestamp : 【必須】• nonce : 【必須】ユニークでランダムな文字列• bodyhash : 【任意】 このあと説明• signature : 【必須】 署名 15
  16. 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. 17. Signature• Normalized Request String – いわゆるSignature base stringの作成• hmac-sha-1/hmac-sha-256 – Hash値を計算 17
  18. 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. 19. Parameters Normalization• クエリパラメータの処理 – percent-encodingでエスケープ – Key,valueを=でつなぐ – ascending byte value orderingでソート – 改行コード(ASCII code 10)を使って結合 19
  20. 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. 21. Verifying Requests• Resource Server側の検証処理 1. bodyhash, signatureの再計算を行い、 Requestの値と比較 2. timestamp,nonce,access tokenの検証 3. access tokenのscopeとstatusの確認• 検証に失敗した場合は、HTTP 401(unauthorized)を返すべき 21
  22. 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. 23. Use with OAuth 2.0• この仕様は、OAuth 2.0のMAC Token Typeを定める• ただし、以下についてはこの仕様で定めない – MAC TypeのTokenの要求方法 – どのHMACアルゴリズムをサポートしているか等 のDiscovery機能 23
  24. 24. Issuing MAC-Type Access Tokens• とりあえず、Access Tokenと一緒に以下の 値が必要 – secret : 共有秘密鍵 – algorithm : hmac-sha-1, hmac-sha-256もし くは今後登録されるアルゴリズム 24
  25. 25. IANA Considerations• 下記のAccess Token TypeをRegistryに登 録する – “mac”• 下記のパラメータをRegistryに登録する – “secret” – “algorithm” 登録ってめんどいね。。。 25
  26. 26. そういえば• OAuth 2.0では、当初からSecretを必要とし ないbearer tokenの形式を利用することが 提案されたが、”やっぱり署名も必要なんじゃ ねーの?”という意見もあった – これを使うと、HTTP Requestが”正しいToken Credentialの持ち主”によって作られたことを確 認できる と思われる 26
  27. 27. 終わり• 続きはまたブログで! http://d.hatena.ne.jp/ritou/ 27

×