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.

API提供におけるOAuthの役割 #apijp

Prepared for API Meetup Tokyo #13 https://api-meetup.doorkeeper.jp/events/41135

昨今、APIアクセス認可のフレームワークとして "OAuth" 仕様を使うケースが一般的になっています。本セッションでは OAuth 適用のトレンドと今後について紹介します。

  • Be the first to comment

API提供におけるOAuthの役割 #apijp

  1. 1. API Meetup Tokyo #13 API提供におけるOAuthの役割 2016年4月8日 NRIセキュアテクノロジーズ株式会社 工藤達雄 〒100-0004 東京都千代田区大手町1-7-2 東京サンケイビル
  2. 2. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 1 昨今、APIアクセス認可のフレームワークとして "OAuth" 仕様を使うケースが一般的になっています。 本セッションでは OAuth 適用のトレンドと今後について 紹介します。 はじめに
  3. 3. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 2 工藤達雄 http://www.linkedin.com/in/tatsuokudo/ @tkudos サン・マイクロシステムズ (1998~2008) 野村総合研究所 (2008~) OpenIDファウンデーション・ジャパン (2013~2014) NRIセキュアテクノロジーズ (2014~) 自己紹介
  4. 4. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 3 なぜOAuth?
  5. 5. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 4 ダイレクトチャネルはID/パスワードでログイン コンテンツ/ 機能 Webサイト モバイルAPI サービス事業者 ID/パスワード エンドユーザー ID/パスワード APP
  6. 6. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 5 サードパーティにAPIを公開する場合はどうするか コンテンツ/ 機能 Webサイト モバイルAPIID/パスワード エンドユーザー ID/パスワード 外部向け API サービス事業者 サードパーティ Webサイト サードパーティ モバイルAPI サードパーティ APP APP APP ID/パスワード…!?
  7. 7. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 6 ユーザーはID/パスワードをサードパーティに預けることになる → 認証リスク サードパーティからの情報漏えいやサードパーティ自身による不正利用の懸念が残る ユーザーはサードパーティに全権委任することになる → 認可リスク サードパーティは本来サービスに不要な(過剰な)APIアクセスを行うこともできてしまう 使い勝手が悪い サードパーティのアクセス有効期間を制御できない サードパーティにユーザーのID/パスワードを渡す?
  8. 8. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 7 ID/パスワードではなく「トークン」を渡す コンテンツ/ 機能 Webサイト モバイルAPIID/パスワード エンドユーザー ID/パスワード 外部向け API サービス事業者 サードパーティ APIクライアント APP トークン 管理 ID/パスワード + 権限委譲 トークン 発行 トークン
  9. 9. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 8 ユーザーのID/パスワードがサードパーティに漏れない サードパーティからのID/パスワード流出や不正利用が発生しなくなる サードパーティに委譲する権限をユーザーが限定できるようになる ユーザーが指定した範囲・機能のみをサードパーティに許可できる 使い勝手が良くなる サードパーティごとにAPIアクセスの可否をコントロールできる トークンを使うと
  10. 10. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 9 オープン標準への道のり  2005年前後、各社はそれぞれ独自のAPIアクセス認可のしくみを策定していた  Flickr Auth, Google AuthSub, Yahoo! BBAuth, …  2006年11月、TwitterのエンジニアやOpenIDコミュニティを中心に、API代理認証に OpenIDを適用できないか議論が始まった  結果的にOpenIDは適用できなかった  また当時API代理認証のオープン標準と呼べるものはまだ存在しないことが明らかになった  2007年4月、少人数にてプロトコル検討が始まった  同7月には仕様草案の初版をもとに公開の場にて議論されるようになった  そして同10月、OAuth 1.0の最終ドラフトが公開された Source: http://oauth.net/about/
  11. 11. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 10 Source: I CAN HAD OPEN: OAuth First Summit a Hit! « hueniverse http://hueniverse.com/2008/07/i-can-had-open-oauth-first-summit-a-hit/
  12. 12. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 11 「トークンによる API アクセス認可」の標準仕様 現在のバージョンはOAuth 2.0 (1.0はobsolete) ▪ RFC 6749 The OAuth 2.0 Authorization Framework ▪ RFC 6750 同 Bearer Token Usage 「RESTful API」との親和性が高い スコープによるアクセス権限指定、Authorizationヘッダの利用など モダンなクライアント環境を考慮している Webブラウザだけではなく、モバイルネイティブやJavaScriptなど OAuth Source: http://oauth.net/2/
  13. 13. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 12 OAuthの基本 登場人物と処理の流れ リソースオーナー リソース サーバー APP 認可 サーバー クライアント HTML5 WEBSITE 0 0. リソースへのアクセスを リクエスト 1 1. 認可 リクエスト 2 2. ユーザー認証 & クライアントへの権限委譲の確認 3 3. OK! 4 4. アクセストークン 提供 5 5. アクセストークンを 使ってAPIアクセス
  14. 14. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 13 リソースオーナー OAuthの基本 クライアントがユーザー(リソースオーナー)の同意に基づき「アクセストークン」を入手するための 一連のフローの起点 レスポンスタイプ: フローは「認可コード」か「インプリシット」か クライアントID: リクエスト元はどのクライアントか スコープ(オプション): どのようなアクセス権限を持つアクセストークンか OAuth認可リクエスト クライアント WEBSITE 認可 サーバー 認可リクエスト GET /authorize?response_type=code&client_id=s6BhdRkqt3&scope=message.readonly&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com
  15. 15. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 14 OAuthの基本 認可サーバーはユーザーエージェントを介して間接的に クライアントに「認可コード」を返す (C)  HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz クライアントは認可サーバーに認可コードを送信する (D)  POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 認可サーバーはクライアントにアクセストークンを返却する (E)  HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value“ } 認可コード・グラント・フロー +----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI ---->| | | User- | | Authorization | | Agent -+----(B)-- User authenticates --->| Server | | | | | | -+----(C)-- Authorization Code ---<| | +-|----|---+ +---------------+ | | ^ v (A) (C) | | | | | | ^ v | | +---------+ | | | |>---(D)-- Authorization Code ---------' | | Client | & Redirection URI | | | | | |<---(E)----- Access Token -------------------' +---------+ (w/ Optional Refresh Token) Source: https://tools.ietf.org/html/rfc6749
  16. 16. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 15 OAuthの基本 認可サーバーはアクセストークン をフラグメントとしてユーザーエー ジェントに返す (C)  HTTP/1.1 302 Found Location: http://example.com/cb#access_token=2YotnFZFEjr1zCs icMWpAA &state=xyz&token_type=example&expires_in=3600 ユーザーエージェントはフラグメ ントからアクセストークンを取り出し クライアントに提供する (F, G) インプリシット・グラント・フロー +----------+ | Resource | | Owner | | | +----------+ ^ | (B) +----|-----+ Client Identifier +---------------+ | -+----(A)-- & Redirection URI --->| | | User- | | Authorization | | Agent -|----(B)-- User authenticates -->| Server | | | | | | |<---(C)--- Redirection URI ----<| | | | with Access Token +---------------+ | | in Fragment | | +---------------+ | |----(D)--- Redirection URI ---->| Web-Hosted | | | without Fragment | Client | | | | Resource | | (F) |<---(E)------- Script ---------<| | | | +---------------+ +-|--------+ | | (A) (G) Access Token | | ^ v +---------+ | | | Client | | | +---------+ Source: https://tools.ietf.org/html/rfc6749
  17. 17. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 16 OAuthの基本 Authorizationヘッダに入れる GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer mF_9.B5f-4.1JqM ボディに入れる POST /resource HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form- urlencoded access_token=mF_9.B5f-4.1JqM クエリパラメーターに入れる https://server.example.com/resource? access_token=mF_9.B5f-4.1JqM&p=q アクセストークンの利用(Bearerトークン) リソース サーバー APP クライアント HTML5 WEBSITE アクセストークンを 使ってAPIアクセス
  18. 18. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 17 OAuth 2.0は「プロトコル」ではなく「フレームワーク」 要件に合わせた「プロファイリング」が必要 権限付与ポリシー パラメーターの動的指定・事前指定 クライアントに提供するフロー アクセストークンのリフレッシュ、失効ポリシー … OAuth 2.0をどうAPIに適用するか
  19. 19. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 18 プロファイリング フローは認可コード・グラントのみ 認可リクエストのパラメーター にscopeが必須 Slackの例 Source: Using OAuth 2.0 | Slack https://api.slack.com/docs/oauth
  20. 20. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 19 プロファイリング スコープは object:action:entity の形式 Slackの例 (cont.) Source: OAuth Scopes | Slack https://api.slack.com/docs/oauth-scopes
  21. 21. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 20 プロファイリング アクセストークンは失効しない Slackの例 (cont.) Source: Using OAuth 2.0 | Slack https://api.slack.com/docs/oauth
  22. 22. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 21 プロファイリング 「Bot Userアクセス トークン」という特別な アクセストークンがある Slackの例 (cont.) Source: Using OAuth 2.0 | Slack https://api.slack.com/docs/oauth
  23. 23. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 22 プロファイリング ひとつのトークンにスコープ が追加されていく APIレスポンスヘッダに現在 トークンに追加されているス コープ一覧が返ってくる Slackの例 (cont.) Source: Using OAuth 2.0 | Slack https://api.slack.com/docs/oauth
  24. 24. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 23 Google Google Identity Platform Microsoft Azure AD “v2.0 エンドポイント” B2C, B2B, B2B2EすべてのAPIアクセス認可をOAuth 2.0に統一 Source: Google, Microsoft
  25. 25. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 24 RFC 7009 OAuth 2.0 Token Revocation RFC 7519 JSON Web Token (JWT) RFC 7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC 7522 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol RFC 7636 Proof Key for Code Exchange by OAuth Public Clients RFC 7662 OAuth 2.0 Token Introspection RFC 7800 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) “OAuth 2.0” 以後にProposed Standard RFCとなった仕様
  26. 26. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 25 OAuthはユーザー認証にも 使えるか?
  27. 27. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 26 アクセストークンは「権限が移譲されたことを示す情報」 であり、認証結果や属性情報ではない 実運用ではアクセストークンに加えてID情報も扱うよう 独自拡張を行なうケースが多い 認可リクエストに要求属性を指定 「アクセストークンレスポンス」にID情報を示すキー/値を追加 アクセストークン自体を構造化し、ID情報を包含 アクセストークンを受け取ってID情報を返却するAPIを提供 → 標準化できるのでは!? OAuth仕様には「ID情報」の扱い方は書かれていない { "access_token":"mF_9.B5f-4.1JqM", "token_type":"Bearer", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" } アクセストークン(レスポンス)の例
  28. 28. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 27 OAuth 2.0仕様をベースに「アイデンティティ層」を拡張し、認証結果や属性情報の連携、 セッション管理などのAPIを標準化 OpenID Connect リライング・パーティ (RP: ID情報要求側) Webアプリ ケーション モバイル アプリケーション ライブラリや パッケージの導 入が不要 ネイティブ (non-Web) アプリでも 利用可能 認証結果/属性情報提供 JWT * によって セキュアにID情報を提供 * JSON Web Token アイデンティティ・プロバイダ (IdP: ID情報提供側) SSO / アクセス 管理システム “Self-issued IdP” OpenID Connect 対応製品が 続々登場 携帯端末が IdPに! 認可リクエスト/APIアクセス OAuth 2.0による API認可と統合
  29. 29. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 28 主要ID/API連携仕様がすべてOpenID Connectに収斂 Source: http://civics.com/OpenID-connect-webinar/ セキュリティ・ アサーション JSON形式の 「IDトークン」 サービス発見 シンプル、APIとの親和性、 モバイル対応 動的なクライント 登録
  30. 30. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 29 ユーザーの認証イベント (認証結果)を「IDトークン」として定 義 OAuth 2.0と同一のフローにて、「ア クセストークン」に加え、新たに「ID トークン」の要求・提供を定義 また、属性情報を提供する 「ユーザー情報(UserInfo)API」を 定義 OpenID ConnectによるID連携のしくみ 2 2. 認可 リクエスト ID情報提供側 (アイデンティティ・ プロバイダ) ID情報要求側 (リライング・ パーティ) ユーザー 1 1. アクセス 試行 7 7. サービス 提供 3 3. 認証・ 同意 4’ 4’. 「認可 コード」を 送信 4’’ 4’’. 「アクセス トークン」 「IDトークン」 4 4. 認可レスポンス (「認可コード」 or 「アクセストークン」 「IDトークン」) 5 5. UserInfo アクセス w/ アクセス トークン 6 6. 属性 情報
  31. 31. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 30 ID情報提供側におけるユーザ認証イベントの情報を含む、署名付き JWT(Signed JSON Web Token)  「このエンドユーザーは○○で、何時何分に、こういう方法で認証を受け、認 証レベルは○で、…」 ID情報要求側は主に、IDトークンに含まれる以下のクレーム(ID情報提 供側がユーザーに関して表明する情報)を用いて、エンドユーザーのア クセス認可を行う  エンドユーザーを識別する値(識別子)  IDトークンの有効期限  ユーザ認証を実施した日時  認証コンテクスト・クラス・リファレンス  認証手段リファレンス  その他(ユーザー属性など) IDトークン { "iss": "http://server.example.com", "sub": "248289761001", "aud": "s6BhdRkqt3", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "gender": "female", "birthdate": "0000-10-31", "email": "janedoe@example.com", "picture": "http://example.com/janedoe/me.jpg" } IDトークンの中身の例
  32. 32. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 31 Beyond OAuth
  33. 33. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 32 ユーザーの立場から見ると、ユーザーは APIクライアントに対して 定められた範囲内で 自分がオーナーであるリソースへ 自分の代理としてアクセス を認可している → 「他人の代理としてアクセス」するAPIクライアントの認可は!? そもそもOAuthはなにを「認可」しているのか リソースオーナー リソース サーバー APP 認可 サーバー クライアント HTML5 W EBS ITE 0 0. リソースへのアクセス をリクエスト 1 1. 認可 リクエスト 2 2. ユーザー認証 & クライアントへの権限委譲の確認 3 3. OK! 4 4. アクセス トークン提供 5 5. アクセストークンを 使ってAPIアクセス
  34. 34. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 33 OAuth 2.0をベースに策定された 「他人からのアクセスの認可」 http://tinyurl.com/umawg UMA (User Managed Access) Resource owner Resource server Authorization server Client Authorization API UI UI UI Requesting party Protection API Authorization client Protection client RS-specific API RS-specific client 1 5 RPT 6 7 8 3 4 PAT 9 AAT PAT PAT RPT choose resources to protect – out of band set policies – out of band AAT 2 1. Resource Server (RS) がリソースセットとスコープをAuthorization Server (AS) に登録 (ongoing) 2. ClientがRSにリソースをリクエスト 3. RSがパーミッションをASに登録 4. ASが「パーミッション・チケット」をRSに返却 5. RSがClientにエラーレスポンスのかたちで「パーミッション・チケット」を返却 6. ClientがASにチケットを送信し、認可データとRPTをリクエスト 7. ASがClientに RPTと認可データを返却 (after optional claim flows) 8. ClientがRSにリソースをリクエスト(RPTを送信) 9. RSがClientにリソース表現を返却 Source: https://kantarainitiative.org/confluence/download/attachments/17760302/UMA-flow.pptx?api=v2
  35. 35. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 34 まとめ
  36. 36. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 35 OAuth 2.0仕様はAPI公開におけるトークンベースのアクセス認可 の実現に有用 自社のAPIに適用するには「OAuth 2.0認可フレームワーク」の 「プロファイリング」が必要 OAuth 2.0を補完する仕様の策定、OpenID ConnectやUMAなどの 派生がいまも進行中 まとめ
  37. 37. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 36 OAuth as a Business Enabler  さまざまなAPIを提供し、他社サービス経由でユーザーの利用状況を把握  例: ユーザーのターゲティングを強化し本業である広告収益を最大化 エンド ユーザー サービス事業者アカウントでログイン サービス提供 アカウントを ひもづけ (ID連携) アカウントの ユーザーと してAPI利用 サービス提供サービス提供 サードパーティ (API利用事業者) ダ イ レ ク ト チ ャ ネ ル API 広告 システム 利用 履歴 広告配信 広告 出稿者 広告+ 掲載料 さまざまなサービスやアプリケーションに 自社サービスの機能が埋め込まれることにより ユーザーの行動把握が強化できる
  38. 38. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 37 「API インタラクションの軸としてアイデンティティを考えない人 → ゲーム終了」 (クレイグ・バートン) Source: http://www.slideshare.net/tkudo/cis2011toi/21

×