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.

Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside

731 views

Published on

Prepared for Google Cloud INSIDE FinTech
https://inthecloud.withgoogle.com/fintech-jp-02-19/register.html

Authlete は、OAuth 2.0 / OpenID Connect サーバーを「正しく」実装するための API サービスです。金融 API の標準と目される Financial-grade API (FAPI) と、Google Apigee と Authlete の連携による FAPI 対応、そして SaaS 事業者としての弊社の Google Cloud 活用についてご紹介します。

Published in: Internet
  • Be the first to comment

Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside

  1. 1. #gc_inside
  2. 2. 工藤達雄 Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 Authlete
  3. 3. About Me ● サン・マイクロシステムズ、野村総合研究所、NRI セ キュアを経て、2018年から Authlete 社にて VP of Solution Strategy を担当 ● 専門はデジタル・アイデンティティを中心とするプリ セールス、コンサルティング、事業開発、 エバンジェリズム ● LinkedIn https://www.linkedin.com/in/tatsuokudo Twitter @tkudos
  4. 4. Who is Authlete? API セキュリティの “B2D” (Business-to-Developer) SaaS プロバイダー 2015/09 🔵 Authlete 社設立 2016/09 🔵 Authlete UK 設立 2016/11 🔵 FINOLAB に入居 2017/03 🔵 FIBC 2017 大賞受賞 2017/05 🔵 Level39 に入居 2017/05 🔵 資金調達(シード) 2017/07 🔵 OpenID Certification 取得 2017/09 🔵 Tech in Asia Tokyo 2017 決勝 2018/02 🔵 資金調達(プレシリーズA) 2018/04 🔵 Draper Nexus B2B Summit 2018 にて IBM 賞受賞 2018/07 🔵 Japan/UK Open Banking and APIs Summit 2018 開催 2018/07 🔵 Financial-grade API (FAPI) サポート 2018/08 🔵 Open Banking Security Profile テスト合格 2019/01 🔵 『OAuth 徹底入門』 監修 2019/02 🔵 CIBA サポート 2019/04 🔵 OpenID FAPI Certification 取得 2019/09 🔵 OpenID FAPI-CIBA OP Certification 取得
  5. 5. Agenda ● Authlete + GCP による「金融グレード API」の実現 ● Authlete サービスにおける GCP 活用
  6. 6. Authlete + GCP による 「金融グレード API」の実現
  7. 7. OAuth: トークンによるアクセス権移譲 ユーザー 認証・同意確認 
 当人確認と同意確認を直 接行うことができる (ID/PW,モバイルApp, 専用デバイス、 …) 銀行 「アクセストークン」を用いたAPIアクセス Fintech 事業者 利用 銀行のログイン情報を渡 さずに利用できる ✔ 口座情報 ✔ 送金機能 ✔ 与信情報 ✔ 口座一括管理 ✔ 入金・送金 ✔ 決済 API公開 ⇒ 売上・集客拡大 API利用 ⇒ 新サービス創出 ユーザーに関する口座情報や決 済機能を活用できる ✔ 複数口座をまとめて 管理したい ✔ 振込処理をかんたん にしたい ✔ 銀行口座を決済に使 いたい
  8. 8. “OAuth Dance” 利用者 Fintech 企業 金融機関 ユーザー Web ブラウザ Web サイト 認可 サーバー API サーバー 認可 リクエスト 認可 コード 認可 コード アクセス トークン アクセス トークン API レスポンス ログインして連携 を許可 金融機関との連 携を開始 連携完了
  9. 9. OAuth / OpenID Connect (OIDC) の標準化状況 Source: https://twitter.com/blhjelm/status/1055551254401736704 ● 2005~2007: 黎明期 ○ 2005: OpenID 誕生 / 2006: OAuth 誕生 ● 2007: OpenID 2.0 / OAuth 1.0 仕様化 ● 2008~2012: 変革期 ○ OAuth 1.0 → 1.0a → WRAP ○ OpenID 2.0 → Contract Exchange / Artifact Binding (AB) / 旧 OpenID Connect → AB/Connect ● 2012: OAuth 2.0 仕様化 / 2014: OpenID Connect (OIDC) 1.0 仕様化 ● … ● 2019: 引き続き活発に仕様策定が続いている
  10. 10. 金融 API に OAuth/OIDC をどう使うか ● OAuth 仕様の解釈のブレや実装の不備が頻発 ● 金融機関が個別に OAuth を適用し、対策水準も各社各様 ● 結果的に… ○ 金融機関(API 提供事業者)が「オープン標準ではない独自仕様」かつ 「不十分なセキュリティ対策」をサードパーティ(API 利用事業者)に押し 付ける構図 ○ サードパーティによる API 活用の阻害要因に
  11. 11. Financial-grade API (FAPI) ● 金融 API 向けの OAuth 2.0 適用プラクティス ● さまざまな立場の専門家が仕様策定に集結 ○ OAuth / OpenID Connect 仕様策定者 ○ 金融機関 ○ サードパーティ(Fintech 事業者) ○ セキュリティ研究者 ○ ソリューションベンダー ○ … Source: https://openid.net/wg/fapi/
  12. 12. FAPI セキュリティ・プロファイル ● Part 1 (Read Only) ○ OAuth 2.0 適用プラクティス+ 拡張仕様 ○ OIDC によるユーザー識別子の授受 ● Part 2 (Read & Write) ○ OIDC の積極的な活用+ 新たな拡張仕様 ○ Request Object, Hybrid Flow, MTLS, OAUTB ○ JARM OIDC 拡張仕様 OIDC プラクティス OAuth2 拡張仕様 OAuth2 プラクティス Part1(ReadOnly) Part2(Read&Write)
  13. 13. “OAuth Dance” の改善・改良 ● 認可リクエスト / レスポンスの送信者詐称 ・改ざん防止 ○ Request Object の利用 ○ Hybrid Flow もしくは JARM の利用 ● 認可コードの漏洩・盗用防止 ○ redirect_uri の厳密な管理 ● クライアントのなりすまし防止 ○ Mutual TLS もしくは JWT によるクライアント認証 ● トークンの漏洩・盗用防止 ○ OAUTB(トークン・バインディング)もしくはMTLS(双 方向 TLS 接続へのバインド)の利用 Resource Owner User Agent Client Authorization Server Resource Server (スタート) (OAuth) 認可リクエスト (OAuth) 認可レスポンス (OAuth) トークン リクエスト (OAuth) トークン レスポンス (OAuth) API リクエスト (OAuth) API レスポンス (完了) ユーザー認証・ アクセス承認 認可 リクエスト 認可 コード 認可 コード アクセス トークン アクセス トークン API レスポンス
  14. 14. 不正なトークン授受・利用の防止 Fintech 事業者 攻撃者 金融機関 OAuth 2.0 アクセス認可リクエスト 認可レスポンス・トークン付与 トークン付きAPI リクエスト(参照・更新) 電子署名により真正性を担保し 不正なトークン授受を防止 トークン窃取 双方向 TLS (SSL) により リクエスト送信者を特定し トークンの不正利用を防止 窃取したトークンを用いた 「なりすましアクセス」を 検知しリクエストを拒否
  15. 15. CIBA Client Initiated Backchannel Authentication ● 「サービスを利用するデバイス」と「認証を行うデバイス」を分離 (decouple) し、API の適用シーンを拡大
  16. 16. CIBA のフロー ユーザー Consumption Device (CD) Authentication Device (AD) クライアント (リライング・パー ティ) 認可・API サーバー (アイデンティティ・プロバ イダー) 0 0. ユーザーの 識別子を把握 login_hint_token id_token_hint login_hint BA EP API (*) Access Token (**) Refresh Token (4) (4) トークンを 使って APIアク セス (4) (4) 認証結果を利 用して処理を実 行 1 1. 認証 リクエスト User Identifier 2 2. 受付応答 AuthN Req ID 3 3. 認証結果と トークンを返却 (Poll / Ping / Push) ID Token / AT* / (RT**) バックチャネル認証エ ンドポイント 2’ 2’. ユーザー 認証
  17. 17. FAPI が求める OAuth/OIDC 実装 Resource Owner User Agent Client Authorization Server Resource Server (スタート) (OAuth) 認可リクエスト (OAuth) 認可レスポンス (OAuth) トークン リクエスト (OAuth) トークン レスポンス (OAuth) API リクエスト (OAuth) API レスポンス ユーザー認証・ アクセス承認 認可リクエスト処理 ・Request Object 認可コード発行 ・OIDC Hybrid Flow / JARM トークンリクエスト処理 ・Client Authentication w/ MTLS ・Sender-constrained Token アクセストークン検証 ・Client Authentication w/ MTLS ・Sender-constrained Token ・Token Introspection
  18. 18. 複雑な処理を Authlete が代行 Resource Owner User Agent Client Authorization Server Resource Server (スタート) (OAuth) 認可リクエスト (OAuth) 認可レスポンス (OAuth) トークン リクエスト (OAuth) トークン レスポンス (OAuth) API リクエスト (OAuth) API レスポンス ユーザー認証・ アクセス承認 Authlete API 認可リクエスト処 理 認可コード生成 トークンリクエスト処理 アクセス トークン検 証 認可サーバーと リソースサーバーに おける複雑な処理を Authlete に外部化 → 開発者の負担を軽減し 開発期間の短縮と セキュリティリスクの 低減に貢献
  19. 19. Authlete による認可リクエスト処理の例 Resource Owner User Agent Client Authorization Server Resource Server (スタート) (OAuth) 認可リクエスト (OAuth) 認可レスポンス (OAuth) トークン リクエスト (OAuth) トークン レスポンス (OAuth) API リクエスト (OAuth) API レスポンス ユーザー認証・ アクセス承認 Authlete API 認可リクエスト処 理 Authlete GET /authorize ?redirect_uri=https://client.example.org /cb/example.com &response_type=code &client_id=12800697055611 &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t 8URWbuGJSstw-cM &code_challenge_method=S256 HTTP/1.1 Host: as.example.com 「認可エンドポイント」が 認可リクエストを受信 リクエストの内容を そのまま Authlete に転送  /auth/authorizationPOST {"parameters":"redirect_uri=https://client. example.org/cb/example.com &response_type=code&client_id=12800697055611 &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t 8URWbuGJSstw-cM &code_challenge_method=S256"}
  20. 20. Authlete を活用した認可サーバーの構築 API 認可・公開基盤 API クライ アント 既存システム Web サイト 携帯端末 ネットワーク デバイス 認可サーバー 認可ロジック (認可判定) ユーザー 認証 同意確認 権限管理 API サーバー /data /function /transaction Authlete 認可 バックエ ンド API 認可情報 DB API 認可リクエスト (トークン取得) API アクセス (トークン利用) 認可状態確認 (トークン検証など) OAuth/OIDC 処理リクエスト(認可コード/トークン発行など) 認可 フロントエン ド 既存の認証/同意/ 権限等と認可 サーバーとを分離 Authlete に依存することなく 自由に認可ロジックを実装可能 API サーバーと 認可サーバーの 構築・運用を分離 面倒な OAuth/OIDC 処理 と認可情報(トークン) 管理を外部化 /… 認可サーバー 構築に必要な ライブラリを OSSにて提供
  21. 21. バックエンドAPI 管理基盤 Apigee リクエスト Apigee + Authlete for FAPI Deployment 既存システム 認可ロジック (認可判定) ユーザー 認証 同意確認 権限管理 Authlete 認可 バックエ ンド API 認可情報 DB API 認可リクエスト (トークン取得) API アクセス (トークン利用) 認可状態確認(トークン検証など) OAuth/OIDC 処理リクエスト(認可コード/トークン発行など) OAuth エンド ポイント API エンド ポイント API クライ アント Web サイト ● Request Object ● Hybrid Flow / JARM ● Client Authentication w/ MTLS ● Sender-constrained Token ● Client Authentication w/ MTLS ● Sender-constrained Token
  22. 22. Request Object Resource Owner User Agent Client Authorization Server Resource Server OIDC 認証リクエスト • 値渡し • 参照渡し リクエストオブジェクトのクレーム { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400, "claims": { "userinfo": { … "email": {"essential": true},…}, "id_token": { "gender": null, … "acr": {"values": ["urn:mace:incommon:iap:silver"]} } } } GET /authorize? request=eyJhbGciOiJSUzI1NiIsImtpZCI6Imsy YmRjIn0.ew0KICJpc3MiOiAiczZCaGRS… GET /authorize? request_uri=%3A%2F%2Fclient.example.org%2Frequest.jwt… リクエストオブジェクト生成 OIDC 認証リクエストへの署名や暗号化 (スタート) (OIDC) 認証リクエスト (OIDC) 認証レスポンス トークン リクエスト トークン レスポンス API リクエスト ユーザー認証・ アクセス承認
  23. 23. Sender-Constrained Token (mTLS)  トークンリクエスト時のクライアント証明書にアクセストークンをバインド Resource Owner User Agent Client Authorization Server Resource Server トークンリクエスト • TLS相互認証を行ってクライアントのX.509証明書を取得し、 その証明書のサブジェクトDNをもとにクライアントを認証 • リクエスト内のclient_idの値からクライアントを識別 • そのクライアント情報として事前登録されている「証明書の サブジェクトDN」の値と照合し認証 X.509 PKC + code + client_id client_id code トークンレスポンス • 証明書に結びつけた(バインドした)アクセストークンを返却 AT, RT APIリクエスト • TLS相互認証を行いクライアントのX.509証明書を取得 • 証明書とアクセストークンの結びつき(バインド)を確認 • トークンに含まれる or イントロスペクションの結果として得ら れる、証明書の「サムプリント」を利用 X.509 PKC + AT X.509 PKC + RT + client_id (スタート) (OAuth) 認可 リクエスト (OAuth) 認可 レスポンス トークン リクエスト トークン レスポンス API リクエスト ユーザー認証・ アクセス承認
  24. 24. Authlete サービスにおける GCP 活用
  25. 25. Our Offerings ● お客さまの要件に応じてマ ネージドクラウド/オンプレミ スにてサービスを提供 ● マネージドクラウドの基盤と して GCP を活用
  26. 26. Deployment Architecture Kubernetes Engine Logging API Server Cloud SQL Cloud SQL Instance Stackdriver Logging Cloud SQL Proxy Consoles Cache Server 各種通知システム
  27. 27. GCP 複数リージョンの活用 https://www.authlete.com/ja/news/20191024_failover/ ● Authlete サービスの フェイルオーバー ○ 主リージョンの Authlete サー バー障害時に副リージョンの サーバーが応答 ○ サーバーの切り替えを 自動的に実施 Region A Region B Periodic replication Health check Switch traffic when region A down
  28. 28. GCP の良いところ ● 楽しい・使いやすい・新技術をいちばん早く試せる ○ コンテナ技術がいちばん進んでいる ○ コンソール / CLI が使いやすい * Stackdriver 以外 ● GKE ○ 非常に安定している。またマネージドサービスであるため運用負荷を大幅に軽減 ○ PaaS (GAE) に比べコントロールできる部分が多く、障害発生時も対処しやすい ● Cloud SQL ○ フェイルオーバーのしくみをかんたんに使える
  29. 29. GCP に期待するところ ● Stackdriver ○ 使い勝手の向上(とくにモニタリング)、ログ表示の応答性 ● Cloud SQL ○ 東京・大阪リージョン間でのフェイルオーバー機能 ○ メンテナンスやスケールアップ時のダウンタイム最小化 ● GKE ○ ノードの面倒を見てくれるサービス(細かいところは任せたい) ● 全般 ○ ステータス公開の強化(コミュニティ情報のほうが早くて正確なことも …)
  30. 30. Takeaways
  31. 31. まとめ ● Financial-grade API (FAPI) ○ 金融 API 向けの OAuth 2.0 / OpenID Connect 仕様 ○ セキュリティ強化に有用だが実装には深い理解が必要 ● Apigee + Authlete ○ FAPI 処理を Authlete に外部化し実装・運用を容易に ● Authlete on GCP ○ マネージドクラウドサービス提供の基盤として活用
  32. 32. リソース ● Authlete ウェブサイト ○ https://www.authlete.com/ja/, https://github.com/authlete ● OAuth/OIDC 解説記事・スライド ○ https://qiita.com/TakahikoKawasaki ○ https://www.slideshare.net/tkudo ● 弊社主催勉強会サイト ○ https://authlete.connpass.com/
  33. 33. Thank you

×