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.

OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws

6,607 views

Published on

Prepared for 情報セキュリティワークショップ in 越後湯沢 2017
http://anisec.jp/yuzawa/?page_id=491

Published in: Internet
  • Be the first to comment

OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws

  1. 1. 情報セキュリティワークショップ in 越後湯沢 2017 OAuth / OpenID Connectを中心とする APIセキュリティについて 2017-10-06 工藤達雄 Cyber Consulting Services NRI SecureTechnologies, Ltd.
  2. 2. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 1 工藤達雄 https://www.linkedin.com/in/tatsuokudo @tkudos サン・マイクロシステムズ (1998~2008) 野村総合研究所 (2008~) OpenIDファウンデーション・ジャパン (2013~2014) NRIセキュアテクノロジーズ (2014~) ▪ 現在はデジタル・アイデンティティと APIを専門とするコンサルティングに従事 自己紹介
  3. 3. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 2 APIセキュリティ、とりわけアクセス認可に欠かせない 「OAuth」と「OpenID Connect」について、 適用例や仕様策定の動向をもとに、注意すべき ポイントや活用に向けたヒントをご紹介します。 本プレゼンテーションの内容
  4. 4. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 3 APIは新しい!? Source: 野村総合研究所
  5. 5. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 4 事業者によるAPI公開は決して新しいものではない APIの歴史を振り返ると、嚆矢は2003年に AmazonがProduct Advertising APIを公開したこ とに始まると言える。Amazonが公開したこのAPI によってブログなどにアフィリエイト機能を簡単に 付加できるようになり、一気にAmazonの商圏が 拡大した。 Source: FinTechを加速させる APIエコノミー https://www.nri.com/~/media/PDF/jp/opinion/teiki/kinyu_itf/2016/itf_201603_6.pdf
  6. 6. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 5 以前からWebサービス間の相互運用標準も存在していた Source: WS-IがWebサービス相互運用性ガイドラインBasic Profile 1.0を一般公開 http://www.ws-i.org/docs/press/20030825wsipr.doc
  7. 7. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 6 ` 最近のAPIは開発者本位のアプローチ Source: JSON's Eight Year Convergence With XML https://www.programmableweb.com/news/jsons-eight-year-convergence-xml/2013/12/26 Source: User accounts services https://www.bbvaapimarket.com/documentation/bbva/accounts
  8. 8. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 7 最近のAPIは利用者本位の連携 会員情報の登録 を登録お客さまの 1. パートナーサイトの 会員情報に、自分の 「ECサイトのID」を登録 「ECサイトID」 パートナーサイト 会員情報の登録 ECサイトID: taro@example.jp 4. 登録完了 パートナーサイト 2. ECサイトにログイン ログイン キャンセル ID: パスワード: taro@example.jp ******** ECサイト あなたへのおすすめ商品がありま す Powered by 「ECサイト」 •… •… •… パートナーサイトから出ることなく、ECサイトの 商品情報とショッピングカートにアクセス ECサイト内での行動履歴を元に パートナー提携ショップでの体験を最適化 パートナーが開発した個別デバイス向け アプリケーションに情報を提供 ECサイトに登録してあるID情報を用いたパーソナライズや、 ECサイトのカート機能をパートナーに提供 カートに入れる カートに入れる カートに入れる パートナーサイト 3. ECサイト上のサービスへ のアクセスを許可 パートナーが提供するサービス経由で ECサイトの「ほしい物リスト」 「クチコミ投稿」「カート機能」を 利用できるようにします OK キャンセル ECサイト
  9. 9. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 8 「利用者本位のAPI連携」のための仕様はOAuth以前にも存在した Source: リバティ・アライアンスの取組みについて http://www.kantei.go.jp/jp/singi/it2/nextg/meeting/dai7/siryou4.pdf 相互に連携するWebサービス を、 最終的にサービスを受ける 「利用者」 を中心に置いて実行 させるには、 すべてのWebサー ビスが 「そのサービスをリクエ ストしている大元は誰か」 を認 識することが必要です。 Source:アイデンティティ Web サービス:エンド・ツー・エンドのアイデンティティ連携 http://otn.oracle.co.jp/technology/global/jp/sdn/javasystem/techtopics/identity/200706.html
  10. 10. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 9 …が、普及しなかった Source: Liberty ID-WSF Web Services Framework Overview Version: 2.0 http://www.projectliberty.org/liberty/content/download/889/6243/file/liberty-idwsf-overview-v2.0.pdf Source: Liberty Specifications Tutorial https://www.itu.int/itudoc/itu-t/com17/tutorial/85606.html
  11. 11. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. OAuth
  12. 12. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 11 OAuthの誕生 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/ • APIアクセス認可のしくみは各社各様だった(Flickr Auth, Google AuthSub, Yahoo! BBAuth, …)2005 • 11月、コミュニティを中心に、API代理認証にOpenIDを適 用できないか議論が始まった(結果的に適用できず)2006 • 4月、少人数にてプロトコル検討が始まった • 7月、仕様草案の初版をもとに公開の場にて議論される ようになった • 10月、OAuth 1.0の最終ドラフトが公開された 2007
  13. 13. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 12 APIアクセス(フルオープン) API サーバー APP APIクライアント HTML5 WEBSITE 1 GET /items/12345 HTTP/1.1
  14. 14. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 13 APIアクセスを「クライアントのクレデンシャル」で制限する API サーバー APP APIクライアント HTML5 WEBSITE 1 ****** GET /items/12345 HTTP/1.1 x-api-key: ****** クライアントのクレデンシャルを要求
  15. 15. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 14 OAuth 2.0 (RFC 6749) の「クライアント・クレデンシャル・ グラント」 「クライアントのクレデンシャル」をもとに付与した「トークン」で APIアクセスを制限する リソース サーバー APP 認可 サーバー クライアント HTML5 WEBSITE 2 2. アクセストークン 提供 3 3. アクセストークンを 使ってAPIアクセス 1 1. クライアントのクレデンシャルを 使ってトークンリクエスト ****** アクセストークンを要求 クライアントのクレデンシャルを以て アクセストークンを提供する
  16. 16. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 15 リソースオーナーのID/パスワードを使ってAPIのアクセスを 制限したい場合には? リソースオーナー リソース サーバー APP クライアント HTML5 WEBSITE 0 0. ID/パスワードを登録 ユーザーID: johndoe パスワード: ****** 1 1. ID/パスワードを 使ってAPIアクセス ユーザーID: johndoe パスワード: ****** ID/パスワードを要求
  17. 17. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 16 「パスワード・アンチパターン」 Source: https://www.flickr.com/photos/factoryjoe/2110461562/ https://www.flickr.com/photos/ronin691/2110909518/
  18. 18. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 17 ユーザーはID/パスワードをサードパーティに 預けることになる サードパーティからの情報漏えいやサードパーティ 自身による不正利用の懸念が残る ユーザーはサードパーティに全権委任する ことになる サードパーティは本来サービスに不要な(過剰な) APIアクセスを行うこともできてしまう サードパーティにユーザーのID/パスワードを渡す? “When customers give out their bank passcode, they may not realize that if a rogue employee at an aggregator uses this passcode to steal money from the customer’s account, the customer, not the bank, is responsible for any loss.” --- Jamie Dimon's Letter to Shareholders, Annual Report 2015 | JPMorgan Chase & Co. http://www.jpmorganchase.com/corporate/annual -report/2015/
  19. 19. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 18 OAuth 2.0 (RFC 6749) の「リソース・オーナー・パスワード・ クレデンシャル・グラント」 ※非推奨 「リソースオーナーのID/パスワード」をもとに付与した 「トークン」でAPIアクセスを制限する リソースオーナー リソース サーバー APP 認可 サーバー クライアント HTML5 WEBSITEWEBSITE 0 0. ID/パスワードを登録 ユーザーID: johndoe パスワード: ****** 2 2. アクセストークン 提供 3 3. アクセストークンを 使ってAPIアクセス 1 1. クライアントのクレデンシャルと ユーザーのID/パスワードを 使ってトークンリクエスト クライアントのクレデンシャル: ****** ユーザーID: johndoe パスワード: ****** アクセストークンを要求 リソースオーナーのクレデンシャル を以てアクセストークンを提供する
  20. 20. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 19 APIアクセスを制限するための「トークン」を、リソースオーナーの 確認をふまえた「認可コード」をもとに付与する リソースオーナー リソース サーバー 認可 サーバー クライアント WEBSITE 0 0. リソースへのアクセスを リクエスト 7 7. アクセストークンを 使ってAPIアクセス ユーザーエージェント 1 1. 認可リクエスト (ブラウザ リダイレクト) 2 2. ユーザー認証 & クライアントへの権限委譲の確認 4 4. 認可コード提供 (ブラウザリダイレクト) 6 6. アクセストークン 提供 3 3. OK! ユーザーID: johndoe パスワード: ****** 5 5. クライアントの クレデンシャルと 認可コードを使って トークンリクエスト ****** アクセストークンを要求 認可コードを以て アクセストークンを提供する
  21. 21. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 20 いわゆる “OAuth 2.0” RFC 6749: OAuth 2.0 認可フレームワーク RFC 6750: OAuth 2.0 認可フレームワーク: ベアラー・トークンの用法
  22. 22. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 21 金融分野のAPIにもOAuth Source: オープンAPIのあり方に関する検討会報告書-オープン・イノベーションの活性化に向けて- https://www.zenginkyo.or.jp/fileadmin/res/news/news290713_1.pdf
  23. 23. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 22 OAuthはセキュアか? Source:警報:Google Docフィッシング拡大中 ――PSAは連絡先全員に偽の招待メールを送る http://jp.techcrunch.com/2017/05/04/20170503ps a-this-google-doc-scam-is-spreading-fast-and-will- email-everyone-you-know/ Source: PayPal Fixes OAuth Token Leaking Vulnerability https://threatpost.com/paypal-fixes-oauth-token-leaking- vulnerability/122136/ Source: OAuthとOpenIDに深刻な脆弱性か- -Facebookなど大手サイトに影響も https://japan.cnet.com/article/35047497/ ニュースサイトでの記事の例
  24. 24. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. OAuthをどう使うか
  25. 25. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 24 「フレームワーク」であり、適用にはプロファイリングが必要 そもそもOAuth(2.0)はプロトコルではない リソースオーナー リソース サーバー 認可 サーバー クライアント WEBSITE 0 7 ユーザーエージェント 1 2 3 4 6 5 認可リクエストの形式 リソースオーナーの認証・同意方法 トークンリクエスト の形式 トークンレスポンス の形式 アクセストークンの ライフサイクル アクセストークンの 利用方法 ****** クライアント 認証の方式
  26. 26. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 25 OAuthプロファイリング101: ブラウザリダイレクト リソースオーナー リソース サーバー 認可 サーバー クライアント WEBSITE 0 7 ユーザーエージェント 2 3 4 6 5 ****** 4. 認可コード 提供(ブラウザ リダイレクト) 1. 認可リクエスト (ブラウザ リダイレクト) 1
  27. 27. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 26 ありがち? なシナリオ (1 of 3) 金融機関と連携する家計簿サイト 利用者(家計簿サイトにログイン済み) 口座情報 API 認可 サーバー 家計簿サイト WEBSITE 0 0. 金融機関との口座情報 連携をリクエスト 1 1. 認可リクエスト (ブラウザ リダイレクト) 2 2. (ログイン後)「家計簿サイトか らのアクセスを許可しますか?」 3 3. OK! 金融機関 利用者として ログイン 4 4. 認可コード提供 (ブラウザリダイレクト) 5 5. 認可コードを使っ てトークンリクエスト ****** 6 6. アクセストークン 提供 7 7. アクセストークンを 使ってAPIアクセス
  28. 28. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 27 ありがち? なシナリオ (2 of 3) 家計簿サイトを騙るフィッシングメールを使って… 利用者(家計簿サイトにログイン済み) 口座情報 API 認可 サーバー 偽の家計簿サイト WEBSITE 0 0. 「偽の家計簿サイト」に アクセスし、再連携を実行 1 1. 認可リクエスト (ブラウザ リダイレクト) 2 2. (ログイン後)「家計簿サイトか らのアクセスを許可しますか?」 3 3. OK! 金融機関 攻撃者 From: 家計簿サイト 「金融機関との接続 が切れました。再連 携を行ってください」 4 4. 認可コード提供 (ブラウザリダイレクト) 認可コードを ゲット
  29. 29. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 28 ありがち? なシナリオ (3 of 3) 他人の口座情報にアクセスできる 攻撃者(家計簿サイトにログイン済み) 口座情報 API 認可 サーバー 家計簿サイト WEBSITE 0 0. 金融機関と の口座情報連 携をリクエスト 1 1. 認可リクエスト (ブラウザ リダイレクト) 2 2. (ログイン後)「家計簿サイトか らのアクセスを許可しますか?」 3 3. OK! 金融機関 他人の 認可コード 攻撃者として ログイン 8 8. アクセストークンを 使って他人の口座情報 にアクセス 4 4. 認可コード提供 (ブラウザリダイレクト) 7 7. 他人の口座情報に アクセス可能なアクセス トークンを提供 6 6. 認可コードを 使ってトークン リクエスト ****** 5 5. リダイレクトを 中断し他人の 認可コードを送信すり替え
  30. 30. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 29 クライアント側に用意する「認可コードの 受け口」 クライアントが認可リクエストを認可サーバー に送信する際、どの「リダイレクション・エンドポ イント」に認可コードを戻してほしいかを指定 認可サーバーは「リダイレクション・エンドポイ ントへのリダイレクトレスポンス」として認可 コードを返却し、ユーザーエージェントがそれ を自動的に送信(≒転送) クライアントの 「リダイレクション・エンドポイント」 リソース オーナー 認可 サーバー クライアント WEBSITE ユーザー エージェント リダイレクション エンドポイント 32 1. 認可リクエスト GET /authorize? response_type=code& client_id=s6BhdRkqt3& scope=message.readonly& state=3af23asl0989gnv& redirect_uri=https%3A%2F%2F client%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com 4. 認可レスポンス HTTP/1.1 302 Found Location: https://client.example.com/cb ?code=SplxlOBeZQQYbYS6WxSbIA& state=3af23asl0989gnv
  31. 31. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 30 仕様上はクライアントのリダイレクション・エンドポイントを 認可サーバーに事前登録すべき (SHOULD) これを認可サーバーはどう解釈するか? 1. 事前登録不要。認可サーバーはクライアントが認可リクエ スト時に指定した任意のURIに認可コードを戻す 2. リダイレクション・エンドポイントのFQDNのみ事前登録。 URIパスやパラメーターの動的追加を許容する 3. リダイレクション・エンドポイントのドメインのみ事前登録。 サブドメインの動的指定を許容する 4. リダイレクション・エンドポイントとして完全なURIを事前登 録。それと一致しないURIは指定不可 クライアントの 「リダイレクション・エンドポイント」 (cont.) リソース オーナー 認可 サーバー クライアント WEBSITE ユーザー エージェント 1. 認可リクエスト 4. 認可レスポンス リダイレクション エンドポイント 32 GET /authorize? response_type=code& client_id=s6BhdRkqt3& scope=message.readonly& state=3af23asl0989gnv& redirect_uri=https%3A%2F%2F client%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com HTTP/1.1 302 Found Location: https://client.example.com/cb ?code=SplxlOBeZQQYbYS6WxSbIA& state=3af23asl0989gnv redirect_uriを どう扱うか?
  32. 32. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 31 もう一度、パラメーターレベルで見てみよう 利用者(家計簿サイトにログイン済み) 口座情報 API 認可 サーバー 偽の家計簿サイト WEBSITE 0 0. 「偽の家計簿サイト」に アクセスし、再連携を実行 金融機関 攻撃者 From: 家計簿サイト 「金融機関との接続 が切れました。再連 携を行ってください」 1 1. 認可リクエスト (ブラウザ リダイレクト) GET /authorize? response_type=code& client_id=家計簿サイト& scope=message.readonly& state=3af23asl0989gnv& redirect_uri=偽の家計簿サイトのURI HTTP/1.1 Host: 金融機関
  33. 33. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 32 (実例)
  34. 34. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 33 ありがち? なシナリオ その2 (1 of 3) 認可コードを家計簿サイトに送信せずに… ログイン API 認可 サーバー 家計簿サイト WEBSITE 0 0. 外部サイトとのログイン 連携をリクエスト 1 1. 認可リクエスト (ブラウザ リダイレクト) 2 2. (ログイン後)「家計簿サイトへ のログインを許可しますか?」 3 3. OK! 外部サイト 攻撃者(家計簿サイトにログイン済み) 攻撃者として ログイン 4 4. 認可コード提供 (ブラウザリダイレクト)
  35. 35. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 34 ありがち? なシナリオ その2 (2 of 3) その認可コードを他人に送信させる ログイン API 認可 サーバー 家計簿サイト WEBSITE 外部サイト 攻撃者 <img src=“https:// 家計簿サイト /.../?code=攻撃者 の認可コード”> 利用者(家計簿サイトにログイン済み) 1 1. 攻撃者の 認可コードを送信 利用者 として ログイン 2 2. 攻撃者の認可コードを 使ってトークンリクエスト ****** 3 3. 攻撃者のログイン情報に アクセス可能なアクセス トークンを提供 4 4. アクセストークンを 使って攻撃者のログイン 情報にアクセス 5 5. 攻撃者のログイン 情報を返却 6 6. 利用者のアカウン トと攻撃者のログイン 情報とがリンク
  36. 36. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 35 ありがち? なシナリオ その2 (3 of 3) 他人になりすまして家計簿サイトにログイン完了 ログイン API 認可 サーバー 家計簿サイト WEBSITE 1 1. 認可リクエスト (ブラウザ リダイレクト) 2 2. (ログイン後)「家計簿サイトへ のログインを許可しますか?」 3 3. OK! 外部サイト 攻撃者(家計簿サイトにログイン済み) 4 4. 認可コード提供 (ブラウザリダイレクト) 5 5. 攻撃者の認可コードを 使ってトークンリクエスト ****** 6 6. 攻撃者のログ イン情報にアクセ ス可能なアクセス トークンを提供 7 7. アクセストークンを 使って攻撃者のログイン 情報にアクセス 8 8. 攻撃者のログイン 情報を返却 9 9. 利用者として ログイン完了 0 0. 外部サイトのIDを使った ログインをリクエスト 外部サイトのログイン 情報とのひもづけ
  37. 37. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 36 クライアントが認可リクエストのパラ メーターとして設定する値 認可リクエストにstateパラメーターの 値が設定されていた場合、認可サー バーはその値を認可レスポンスに設 定する クライアントはこの値を用いて、送信し た認可リクエストと、受信した認可レス ポンスとをひもづけることができる 認可リクエストの “state” パラメーター リソース オーナー 認可 サーバー クライアント WEBSITE ユーザー エージェント リダイレクション エンドポイント 32 1. 認可リクエスト GET /authorize? response_type=code& client_id=s6BhdRkqt3& scope=message.readonly& state=3af23asl0989gnv& redirect_uri=https%3A%2F%2F client%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com 4. 認可レスポンス HTTP/1.1 302 Found Location: https://client.example.com/cb ?code=SplxlOBeZQQYbYS6WxSbIA& state=3af23asl0989gnv
  38. 38. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 37 仕様上はstateパラメーターの利用を推奨 (RECOMMENDED) これをクライアントはどう解釈するか? 1. “RECOMMENDED” であり、設定しなくても良い 2. クライアントはすべての認可リクエストに同じstate 値をセットする 3. クライアントは認可リクエストごとにstate値をセット する a. セッションIDをセットする b. セッションIDのハッシュなどをセットする 認可リクエストの “state” パラメーター (cont.) リソース オーナー 認可 サーバー クライアント WEBSITE ユーザー エージェント リダイレクション エンドポイント 32 1. 認可リクエスト GET /authorize? response_type=code& client_id=s6BhdRkqt3& scope=message.readonly& state=3af23asl0989gnv& redirect_uri=https%3A%2F%2F client%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com 4. 認可レスポンス HTTP/1.1 302 Found Location: https://client.example.com/cb ?code=SplxlOBeZQQYbYS6WxSbIA& state=3af23asl0989gnv クライアントは stateの値を どう作るか?
  39. 39. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 38 もう一度、パラメーターレベルで 見てみよう ログイン API 認可 サーバー 家計簿サイト WEBSITE 0 0. 外部サイトとのログイン 連携をリクエスト 2 2. (ログイン後)「家計簿サイトへ のログインを許可しますか?」 3 3. OK! 外部サイト 攻撃者(家計簿サイトにログイン済み) 攻撃者として ログイン 4 4. 認可コード提供 (ブラウザリダイレクト) 1 1. 認可リクエスト (ブラウザ リダイレクト) GET /authorize? response_type=code& client_id=家計簿サイト& scope=message.readonly& state=攻撃者のログインセッ ションにひもづく値& redirect_uri=家計簿サイト のURI HTTP/1.1 Host: 外部サイト
  40. 40. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 39 もう一度、パラメーターレベルで見てみよう(cont.) ログイン API 認可 サーバー 家計簿サイト WEBSITE 外部サイト 攻撃者 <img src=“https:// 家計簿サイト /.../?code=攻撃者の 認可コード&state=攻 撃者のログインセッ ションにひもづく値”> 利用者(家計簿サイトにログイン済み) 利用者 として ログイン 1 1. 攻撃者の 認可コードを送信 GET /.../? state=攻撃者のログインセッションにひもづく値& code=攻撃者の認可コード HTTP/1.1 Host: 家計簿サイト
  41. 41. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 40 (実例)
  42. 42. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 41 使える「車輪」や「車輪の部品」はたくさんある OAuthの拡張仕様など https://datatracker.ietf.org/wg/oauth/documents/ OpenID Connect http://openid.net/developers/specs/ For starters… RFC 6819: OAuth 2.0の脅威モデルとセキュリティ検討 https://tools.ietf.org/html/rfc6819, https://openid-foundation-japan.github.io/rfc6819.ja.html (和訳) draft-ietf-oauth-security-topics: OAuthセキュリティ・トピックス https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics RFC 8252: ネイティブ・アプリケーション向けのOAuth 2.0 https://tools.ietf.org/html/rfc8252 プロファイリングをどう進めていくか?
  43. 43. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. OAuth周辺の動向 (OpenID Connect, FAPI)
  44. 44. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 43 API サーバー OAuth仕様には「認証依頼」と「認証結果提供」のやりとり、 そして「認証結果」(ID情報)の定義は書かれていない エンドユーザー APP サードパーティ APIクライアント (Webサイトなど) サービス アクセス試行 APIアクセス 許可要求 APIアクセス 許可 APIアクセス サードパーティ Webサイト ユーザー認証 アクセス試行 認証依頼 認証結果提供 アイデンティティ連携 サードパーティに「いまアクセス してきたユーザーに関する情報」 を提供する APIアクセス認可 (OAuth) サードパーティに「ユーザーに 成り代わってアクセスをする ための許可証」を提供する 扱う情報が異なる
  45. 45. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 44 API サーバー OAuth 2.0仕様をベースに「アイデンティティ層」を拡張し、認証結果や属性情報の連携、 セッション管理などのAPIを標準化 アイデンティティ連携: OpenID Connect (OIDC) エンドユーザー APP サードパーティ APIクライアント (Webサイトなど) サービス アクセス試行 APIアクセス許可要求 + 認証依頼 APIアクセス許可 + 認証結果提供 APIアクセス ユーザー認証 認証結果(IDトークン) • ID情報提供側におけるユーザ 認証イベントの情報 • エンドユーザーを識別する値 (識別子) • IDトークンの有効期限 • ユーザ認証を実施した日時 • 認証コンテクスト・クラス・ リファレンス • 認証手段リファレンス • その他(ユーザー属性など) • 署名付きJWT(Signed JSON Web Token)として表現
  46. 46. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 45 金融機関 (サービス事業者) 資産管理サービスにおけるOAuth 2.0とOpenID Connect (OIDC) を用いた認証・認可フローの例 NRI ITソリューションフロンティア Vol.33 No.08 https://www.nri.com/~/media/PDF/jp/opinion/teiki/it_solution/2016/ITSF160802.pdf に加筆 サードパーティはAPIアクセス許可依頼 とユーザー認証依頼を同時に実行 口座所有者 (エンドユーザー) 資産管理FinTech企業 (サードパーティ) サービス事業者はエンドユーザーに アクセス許可を確認 サービス事業者はサードパーティに 「アクセストークン(APIアクセス許可 情報)」と「IDトークン(認証結果)」を返却 サードパーティは認証結果をもとに エンドユーザーの当人確認を行い、 必要に応じてユーザーを新規登録 サードパーティはアクセストークンを 用いてサービス事業者のAPIを呼び出し サービス事業者はエンドユーザーを 認証
  47. 47. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 46 OpenID Foundation “Financial API (FAPI) WG” http://openid.net/wg/fapi/  策定を進めている仕様  APIセキュリティ・プロファイル ▪ Part 1: 「読み出し専用」 API ▪ Part 2: 「読み書き」 API  API仕様 ▪ Part 3: オープンデータAPI ▪ Part 4: 保護対象データAPIおよびスキーマ - 「読み出し専用」 ▪ Part 5: 保護対象データAPIおよびスキーマ - 「読み書き」  認可サーバー、クライアント、 リソースサーバーに対する 「セキュリティ条項 (Security Provisions)」を規定
  48. 48. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 47 クライアントの「リダイレクション・エンドポイント」  認可サーバーはクライアントのリダイレクトURIを事前登録すること  認可サーバーはクライアントからの認可リクエストにredirect_uriパラメー ターが指定されていない場合には処理を中断すること  認可サーバーは、認可リクエスト内のredirect_uriパラメーターの値を 事前登録したリダイレクトURIと比較し、完全一致しない場合には 処理を中断すること 認可リクエストの “state” パラメーター  クライアントは有効なCSRF対策を実装すること トークンリクエストにおけるクライアント認証  認可サーバーはTLS双方向認証 or JWSクライアントアサーションを用い てクライアント認証を行うこと FAPIにおけるプロファイリングの例 “Part 1: 「読み出し専用」 APIセキュリティ・プロファイル” リソース オーナー 認可 サーバー クライアント WEBSITE ユーザー エージェント リダイレクション エンドポイント 32 14 6 6 5 ****** リダイレクション・ エンドポイントの 厳密なチェック クライアント認証は Basic認証不可 CSRF対策 (i.e. 適切な stateの利用)
  49. 49. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. まとめ
  50. 50. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 49 「ビジネス・モーメント」と「エコシステム」 ビジネス・モーメント 顧客に対してその瞬間に最も必要なサービスを エンドユーザー自発的な同意に基づいて提供 エコシステム 自社顧客へのサービスに他社のAPIを活用し 一方で別の事業者の顧客接点に対してAPIを提供 APIファースト 企業が自社のコアを外部に開放し、その機能を他社が取り込み、 エンドユーザーに対していままで提供できていなかった、 イノベーティブな価値やソリューションを創造するためのしくみ アイデンティティ & API セキュリティスタック
  51. 51. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 50 これからのアイデンティティ & API セキュリティスタック Source: Forging a Modern Cloud-first Identity Ecosystem for a 125-year-old Startup https://www.slideshare.net/identityhutch/forging-a-modern-cloudfirst-identity-ecosystem-for-a-125yearold-startup アイデンティティ & 認証コンテクスト アイデンティティAPI セッション管理 クライアント登録 サービス・ディスカバリー 署名付きリクエスト アサーション認証 暗号化/署名/鍵 構造化トークン ミティゲーション & プルーフ 拡張認可フロー トークン・イントロスペクション トークン失効 ユーザー/クライアント認可 オブジェクト記法
  52. 52. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 51 [PR]☺ ”APIセキュリティ” で検索していただければ幸いです NRIセキュアの 「APIセキュリティコンサルティングサービス」 https://www.nri-secure.co.jp/service/consulting/apisecurity.html

×