Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

今更OAuth1.0についてRFC読んで理解してみた

4,429 views

Published on

OAuth1.0について発表する機会があったので、
全体的なフローやクライアントサイドの実装方法について、RFCを読んでまとめました。
Twitterを例に説明しています。

Published in: Internet
  • Sex in your area is here: ❶❶❶ http://bit.ly/2ZDZFYj ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Follow the link, new dating source: ♥♥♥ http://bit.ly/2ZDZFYj ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

今更OAuth1.0についてRFC読んで理解してみた

  1. 1. OAuth1.0 for Twitter @nemupm
  2. 2. OAuth1.0の概要
  3. 3. OAuth1.0の背景 沢山のクラウドサービスが普及 これらのサービスには有用なリソースが 眠っている. 別のサービスからも(ユーザの同意のもとに) 自由にリソースにアクセスしたい!!
  4. 4. 今までだと… 別のサービスがリソースにアクセスするには, ユーザからID・パスワードを貰う必要があった. 問題点が2つ ID・パスワードを不正利用される可能性 リソースへの全権限を渡してしまう.
  5. 5. OAuth1.0の役割 リソースへの権限を ID・パスワードを秘匿したまま スコープ付きで 渡せるようになった. 安全で便利な世の中に!
  6. 6. OAuth1.0のフロー リソースオーナー 3つの登場人物 リソースオーナー - サーバ上にリソースを所有しているユーザ クライアント - リソースにアクセスしたいサーバ サーバ - リソースを直接管理しているサーバ クライアント サーバ
  7. 7. OAuth1.0のフロー リソースオーナー クライアント サーバ access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可
  8. 8. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 最終目標はクライアントが アクセストークンを取得して APIを利用できる状態 OAuth1.0の最終目標 リソースオーナー クライアント サーバ
  9. 9. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 アクセストークン取得までの道のり リソースオーナー クライアント サーバ 大きく3ステップに分けられる
  10. 10. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ① リクエストトークンの取得 リソースオーナー クライアント サーバ 最初にこの (リソースオーナー,クライアント)の組み合わせ に固有の識別子を発行 以降この識別子を用いることで サーバは彼らを認識することができる
  11. 11. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ② リソースオーナーの認可を得る リソースオーナー クライアント サーバ クライアントへの権限の委譲を リソースオーナーが認可するプロセス
  12. 12. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ② リソースオーナーの認可を得る 詳細(1/3) リソースオーナー クライアント サーバ まず先ほど取得したリクエストトークンと共に リソースオーナーをサーバの認証画面へリダイレクト
  13. 13. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ② リソースオーナーの認可を得る 詳細(2/3) リソースオーナー クライアント サーバ リソースオーナーは認可するかどうかを選択
  14. 14. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ② リソースオーナーの認可を得る 詳細(3/3) リソースオーナー クライアント サーバ 認可された場合,サーバはリソースオーナーを 検証コードと共にクライアントにリダイレクトさせ, クライアントに間接的に検証コードを渡す
  15. 15. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ③ アクセストークンの取得 リソースオーナー クライアント サーバ リクエストトークン・検証コードと引き換えに アクセストークンを取得する
  16. 16. OAuth1.0のフロー リソースオーナー クライアント サーバ access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 以上の3ステップにより クライアントはアクセストークンを取得
  17. 17. OAuth1.0のフロー リソースオーナー クライアント サーバ access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 以降,実装方法の詳細について述べる
  18. 18. 実装方法について
  19. 19. 先ほどのフローを今度は クライアント視点で の順に説明します.
  20. 20. テンポラリクレデンシャルの取得 クライアントはリソースオーナーの指示を受け, 認証済みのPOSTリクエストを行う. この時,以下のパラメータをリクエストに加える. oauth_callback - リソースオーナー認可( )後にサーバが リソースオーナーをリダイレクトさせるURI レスポンスが返ったら, 以下のテンポラリクレデンシャルを取り出す. - oauth_token:識別子 - oauth_token_secret:共有鍵
  21. 21. リソースオーナーの認可 リソースオーナーを サーバの認可画面にリダイレクトさせ待機する. この時,リダイレクト先のURIに 以下のクエリを追加する. oauth_token - で得られたテンポラリクレデンシャルの識別子 送信したものと同一のoauth_tokenが クエリに付与されたリクエストが届いたら, クエリからoauth_verifierを取り出す.
  22. 22. トークンクレデンシャルの取得 クライアントは 認証済みのPOSTリクエストを行う. この時,以下のパラメータをリクエストに加える. oauth_verifier - で得られた検証コード レスポンスが返ったら, 以下のトークンクレデンシャルを取り出す. - oauth_token:識別子 - oauth_token_secret:共有鍵
  23. 23. 認証済みリクエストって なんぞや
  24. 24. OAuthにおいて サーバがクライアントの正当性を検証する ために必要なルール
  25. 25. サーバがリクエストについて確認すべきこと リクエストを送ったのがどのクライアントか パラメータが改竄されていないか (以下はAPI利用時のみ) どのリソースオーナーに結び付けられているか クライアントは本当に リソースオーナーの代理として信用できるか
  26. 26. OAuthで定義されている要件 先ほどの項目を満たすために リクエストに付与する必須のパラメータ それらのパラメータの正当性を証明する方法 がリクエスト生成時の要件として定義されている. - これらを満たしたリクエストを 認証済みリクエストと呼ぶ. 以下ではこれら2つの要件を順に説明する.
  27. 27. リクエストに付与する必須パラメータ(1/3) oauth_consumer_key - クライアントクレデンシャルの識別子 - クライアントを認識するのに必要 oauth_token - リソースオーナーを認識するためのトークン - API利用時以外は省略する.
  28. 28. クライアントクレデンシャルの取得(oauth_consumer_key) OAuthでは サーバがクライアントを識別する必要がある. 実は先ほどの図では省略していたが, 常にリクエストには クライアントクレデンシャルが必要 クライアントクレデンシャルは一般的に クライアントが事前にサーバに登録することで サーバから配布される.
  29. 29. Twitterにおけるクライアントクレデンシャルの取得 Application ManagementでCreate New App Access levelで権限のスコープを設定 Sign in with Twitterをオンにすると 特定条件下で認証画面をスキップできる. Callback URLで認証後のリダイレクト先を指 定 以下の4つの値は控えておく. - Consumer Key/Secret(クライアントクレデンシャル) - Request token URL - Authorize URL - Access token URL のエンドポイント
  30. 30. リクエストに付与する必須パラメータ(2/3) oauth_timestamp - 1970/01/01 00:00:00 GMT を起点にした経過秒数 oauth_nonce - ユニークな文字列(タイムスタンプのミリ秒など) - タイムスタンプ・ノンス(・トークン)の 組み合わせが既存のリクエストと同一である場合 リクエストは拒否される. oauth_signature_method - 署名メソッドであり, OAuthでは3つ提供されているが, TwitterではHMAC-SHA1を値として設定する.
  31. 31. パラメータをリクエストへ追加 OAuthでは追加する箇所を3つ用意しているが, TwitterではAuthorizationヘッダフィールドへ 追加する. 具体的には, パラメータ(key・value)を全て パーセントエンコーディングする. - RFC3986に従う. パラメータを使って以下の形式の 文字列を生成し,ヘッダに追加する. OAuth key1=“value1”, key2=“value2”…
  32. 32. リクエストに付与する必須パラメータ(3/3) oauth_signature - リクエストの正当性を証明するための署名 以降oauth_signatureの生成方法について 説明していく.
  33. 33. oauth_signatureの生成 以下に示すkey・textを使って HMAC-SHA1によるハッシュ値を生成し, それをbase64でエンコードすることで生成 key: - クレデンシャルの正当性が示される. - トークン無しの場合でも&は付ける. text:シグニチャーベースストリングに設定 - パラメータの正当性が示される. エンコード済み クライアント共有鍵 エンコード済み トークン共有鍵&
  34. 34. シグニチャーベースストリングの生成 以下の3つの文字列を順に&で結合して生成 エンコード済みHTTPリクエストメソッド - TwitterだとGETかPOST エンコード済みベースストリングURI - リクエスト対象リソースを示すURI - 以下の条件で構築する - スキーマ・ホストは小文字 - ホスト・ポート番号はHostヘッダと同一 - http・httpsに対応するポート番号は省略 リクエストパラメータを繋げて エンコードした文字列
  35. 35. リクエストパラメータ文字列の生成方法(1/2) 以下のパラメータ群を集める. リクエストURIのクエリー要素を分解したもの Authorizationヘッダフィールドの realm・oauth_signature以外のパラメータ リクエストエンティティボディのクエリー要素 を分解したもの - ただし,ボディがシングルパートかつ application/x-www-form-urlencodedの エンコード要件を満たしている場合のみ
  36. 36. リクエストパラメータ文字列の生成方法(2/2) 以下の手順を実行し単一文字列を生成 各パラメータの名前と値をエンコード 昇順にソート 各パラメータの名前と値を=で連結 名前と値のペアを&で連結 これでsignature完成!
  37. 37. OAuth1.0まとめ・感想 リソースへのアクセス権限移譲を セキュアに行うための仕組み signature生成が面倒 - 間違っててもどこが間違ってるか発見しづらい… callbackらへんガバガバ

×