Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
今更OAuth1.0についてRFC読んで理解してみた
- 2. OAuth1.0の概要
- 4. 今までだと… 別のサービスがリソースにアクセスするには， ユーザからID・パスワードを貰う必要があった． 問題点が２つ ID・パスワードを不正利用される可能性 リソースへの全権限を渡してしまう．
- 6. OAuth1.0のフロー リソースオーナー 3つの登場人物 リソースオーナー - サーバ上にリソースを所有しているユーザ クライアント - リソースにアクセスしたいサーバ サーバ - リソースを直接管理しているサーバ クライアント サーバ
- 7. OAuth1.0のフロー リソースオーナー クライアント サーバ access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可
- 8. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 最終目標はクライアントが アクセストークンを取得して APIを利用できる状態 OAuth1.0の最終目標 リソースオーナー クライアント サーバ
- 9. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 アクセストークン取得までの道のり リソースオーナー クライアント サーバ 大きく３ステップに分けられる
- 10. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ① リクエストトークンの取得 リソースオーナー クライアント サーバ 最初にこの （リソースオーナー，クライアント）の組み合わせ に固有の識別子を発行 以降この識別子を用いることで サーバは彼らを認識することができる
- 11. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ② リソースオーナーの認可を得る リソースオーナー クライアント サーバ クライアントへの権限の委譲を リソースオーナーが認可するプロセス
- 12. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ② リソースオーナーの認可を得る 詳細（1/3） リソースオーナー クライアント サーバ まず先ほど取得したリクエストトークンと共に リソースオーナーをサーバの認証画面へリダイレクト
- 13. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ② リソースオーナーの認可を得る 詳細（2/3） リソースオーナー クライアント サーバ リソースオーナーは認可するかどうかを選択
- 14. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ② リソースオーナーの認可を得る 詳細（3/3） リソースオーナー クライアント サーバ 認可された場合，サーバはリソースオーナーを 検証コードと共にクライアントにリダイレクトさせ， クライアントに間接的に検証コードを渡す
- 15. access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 ③ アクセストークンの取得 リソースオーナー クライアント サーバ リクエストトークン・検証コードと引き換えに アクセストークンを取得する
- 16. OAuth1.0のフロー リソースオーナー クライアント サーバ access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 以上の３ステップにより クライアントはアクセストークンを取得
- 17. OAuth1.0のフロー リソースオーナー クライアント サーバ access token APIの利用 access token アクセストークン取得 request token リクエストトークン取得 request token request token request token verifier verifier 認可 リソースオーナー認可 以降，実装方法の詳細について述べる
- 18. 実装方法について
- 20. テンポラリクレデンシャルの取得 クライアントはリソースオーナーの指示を受け， 認証済みのPOSTリクエストを行う． この時，以下のパラメータをリクエストに加える． oauth_callback - リソースオーナー認可（ ）後にサーバが リソースオーナーをリダイレクトさせるURI レスポンスが返ったら， 以下のテンポラリクレデンシャルを取り出す． - oauth_token：識別子 - oauth_token_secret：共有鍵
- 22. トークンクレデンシャルの取得 クライアントは 認証済みのPOSTリクエストを行う． この時，以下のパラメータをリクエストに加える． oauth_verifier - で得られた検証コード レスポンスが返ったら， 以下のトークンクレデンシャルを取り出す． - oauth_token：識別子 - oauth_token_secret：共有鍵
- 23. 認証済みリクエストって なんぞや
- 27. リクエストに付与する必須パラメータ（1/3） oauth_consumer_key - クライアントクレデンシャルの識別子 - クライアントを認識するのに必要 oauth_token - リソースオーナーを認識するためのトークン - API利用時以外は省略する．
- 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. リクエストに付与する必須パラメータ（2/3） oauth_timestamp - 1970/01/01 00:00:00 GMT を起点にした経過秒数 oauth_nonce - ユニークな文字列（タイムスタンプのミリ秒など） - タイムスタンプ・ノンス（・トークン）の 組み合わせが既存のリクエストと同一である場合 リクエストは拒否される． oauth_signature_method - 署名メソッドであり， OAuthでは３つ提供されているが， TwitterではHMAC-SHA1を値として設定する．
- 33. oauth_signatureの生成 以下に示すkey・textを使って HMAC-SHA1によるハッシュ値を生成し， それをbase64でエンコードすることで生成 key： - クレデンシャルの正当性が示される． - トークン無しの場合でも＆は付ける． text：シグニチャーベースストリングに設定 - パラメータの正当性が示される． エンコード済み クライアント共有鍵 エンコード済み トークン共有鍵＆
- 34. シグニチャーベースストリングの生成 以下の３つの文字列を順に＆で結合して生成 エンコード済みHTTPリクエストメソッド - TwitterだとGETかPOST エンコード済みベースストリングURI - リクエスト対象リソースを示すURI - 以下の条件で構築する - スキーマ・ホストは小文字 - ホスト・ポート番号はHostヘッダと同一 - http・httpsに対応するポート番号は省略 リクエストパラメータを繋げて エンコードした文字列