Enviar pesquisa
Carregar
「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api
•
14 gostaram
•
3,104 visualizações
Tatsuo Kudo
Seguir
Prepared for FinTech X Security-JAWS 勉強会#01 https://atnd.org/events/88202
Leia menos
Leia mais
Internet
Denunciar
Compartilhar
Denunciar
Compartilhar
1 de 25
Baixar agora
Baixar para ler offline
Recomendados
プロトコルから見るID連携
プロトコルから見るID連携
Naohiro Fujie
Azure AD B2CにIdPを色々と繋いでみる
Azure AD B2CにIdPを色々と繋いでみる
Naohiro Fujie
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
Hitachi, Ltd. OSS Solution Center.
NGINXでの認可について考える
NGINXでの認可について考える
Hitachi, Ltd. OSS Solution Center.
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
Masaru Kurahayashi
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
Hitachi, Ltd. OSS Solution Center.
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
日本マイクロソフト株式会社
Keycloakのステップアップ認証について
Keycloakのステップアップ認証について
Hitachi, Ltd. OSS Solution Center.
Recomendados
プロトコルから見るID連携
プロトコルから見るID連携
Naohiro Fujie
Azure AD B2CにIdPを色々と繋いでみる
Azure AD B2CにIdPを色々と繋いでみる
Naohiro Fujie
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
Hitachi, Ltd. OSS Solution Center.
NGINXでの認可について考える
NGINXでの認可について考える
Hitachi, Ltd. OSS Solution Center.
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
Masaru Kurahayashi
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
Hitachi, Ltd. OSS Solution Center.
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
日本マイクロソフト株式会社
Keycloakのステップアップ認証について
Keycloakのステップアップ認証について
Hitachi, Ltd. OSS Solution Center.
Keycloak入門
Keycloak入門
Hiroyuki Wada
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
Shinya Yamaguchi
池澤あやかと学ぼう!: はじめてのOAuthとOpenID Connect - JICS 2014
池澤あやかと学ぼう!: はじめてのOAuthとOpenID Connect - JICS 2014
Nov Matake
OpenID Connect入門
OpenID Connect入門
土岐 孝平
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
Tatsuo Kudo
OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA)のご紹介 ~ ...
OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA)のご紹介 ~ ...
OpenID Foundation Japan
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
Hitachi, Ltd. OSS Solution Center.
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
OpenID Foundation Japan
Kongの概要と導入事例
Kongの概要と導入事例
briscola-tokyo
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
Nov Matake
Azure Key Vault
Azure Key Vault
junichi anno
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
NTT DATA Technology & Innovation
OAuth 2.0による認可の流れ
OAuth 2.0による認可の流れ
Takeshi Mikami
Keycloak拡張入門
Keycloak拡張入門
Hiroyuki Wada
Keycloakの紹介と最新開発動向
Keycloakの紹介と最新開発動向
Yuichi Nakamura
KubeConRecap_nakamura.pdf
KubeConRecap_nakamura.pdf
Hitachi, Ltd. OSS Solution Center.
IDaaS を利用すべき理由とエンジニアがおさえておくべきポイント (2021年1月14日)
IDaaS を利用すべき理由とエンジニアがおさえておくべきポイント (2021年1月14日)
Masanori KAMAYAMA
Azure ADと外部アプリのID連携/SSO - Deep Dive
Azure ADと外部アプリのID連携/SSO - Deep Dive
Naohiro Fujie
自己主権型IDと分散型ID
自己主権型IDと分散型ID
Naohiro Fujie
今なら間に合う分散型IDとEntra Verified ID
今なら間に合う分散型IDとEntra Verified ID
Naohiro Fujie
ブロックチェーン〜信頼の源泉の民主化のもたらす変革
ブロックチェーン〜信頼の源泉の民主化のもたらす変革
Nat Sakimura
OpenID Foundation FAPI WG: June 2017 Update
OpenID Foundation FAPI WG: June 2017 Update
Nat Sakimura
Mais conteúdo relacionado
Mais procurados
Keycloak入門
Keycloak入門
Hiroyuki Wada
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
Shinya Yamaguchi
池澤あやかと学ぼう!: はじめてのOAuthとOpenID Connect - JICS 2014
池澤あやかと学ぼう!: はじめてのOAuthとOpenID Connect - JICS 2014
Nov Matake
OpenID Connect入門
OpenID Connect入門
土岐 孝平
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
Tatsuo Kudo
OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA)のご紹介 ~ ...
OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA)のご紹介 ~ ...
OpenID Foundation Japan
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
Hitachi, Ltd. OSS Solution Center.
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
OpenID Foundation Japan
Kongの概要と導入事例
Kongの概要と導入事例
briscola-tokyo
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
Nov Matake
Azure Key Vault
Azure Key Vault
junichi anno
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
NTT DATA Technology & Innovation
OAuth 2.0による認可の流れ
OAuth 2.0による認可の流れ
Takeshi Mikami
Keycloak拡張入門
Keycloak拡張入門
Hiroyuki Wada
Keycloakの紹介と最新開発動向
Keycloakの紹介と最新開発動向
Yuichi Nakamura
KubeConRecap_nakamura.pdf
KubeConRecap_nakamura.pdf
Hitachi, Ltd. OSS Solution Center.
IDaaS を利用すべき理由とエンジニアがおさえておくべきポイント (2021年1月14日)
IDaaS を利用すべき理由とエンジニアがおさえておくべきポイント (2021年1月14日)
Masanori KAMAYAMA
Azure ADと外部アプリのID連携/SSO - Deep Dive
Azure ADと外部アプリのID連携/SSO - Deep Dive
Naohiro Fujie
自己主権型IDと分散型ID
自己主権型IDと分散型ID
Naohiro Fujie
今なら間に合う分散型IDとEntra Verified ID
今なら間に合う分散型IDとEntra Verified ID
Naohiro Fujie
Mais procurados
(20)
Keycloak入門
Keycloak入門
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
池澤あやかと学ぼう!: はじめてのOAuthとOpenID Connect - JICS 2014
池澤あやかと学ぼう!: はじめてのOAuthとOpenID Connect - JICS 2014
OpenID Connect入門
OpenID Connect入門
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
PDSを実現するにあたっての技術動向の紹介 (OAuth, OpenID Connect, UMAなど)
OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA)のご紹介 ~ ...
OpenID Connect Client Initiated Backchannel Authentication Flow (CIBA)のご紹介 ~ ...
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
KeycloakでFAPIに対応した高セキュリティなAPIを公開する
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
次世代 IDaaS のポイントは本人確認 NIST と、サプライチェーンセキュリティと、みなしご ID - OpenID Summit 2020
Kongの概要と導入事例
Kongの概要と導入事例
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
Azure Key Vault
Azure Key Vault
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
OAuth 2.0による認可の流れ
OAuth 2.0による認可の流れ
Keycloak拡張入門
Keycloak拡張入門
Keycloakの紹介と最新開発動向
Keycloakの紹介と最新開発動向
KubeConRecap_nakamura.pdf
KubeConRecap_nakamura.pdf
IDaaS を利用すべき理由とエンジニアがおさえておくべきポイント (2021年1月14日)
IDaaS を利用すべき理由とエンジニアがおさえておくべきポイント (2021年1月14日)
Azure ADと外部アプリのID連携/SSO - Deep Dive
Azure ADと外部アプリのID連携/SSO - Deep Dive
自己主権型IDと分散型ID
自己主権型IDと分散型ID
今なら間に合う分散型IDとEntra Verified ID
今なら間に合う分散型IDとEntra Verified ID
Destaque
ブロックチェーン〜信頼の源泉の民主化のもたらす変革
ブロックチェーン〜信頼の源泉の民主化のもたらす変革
Nat Sakimura
OpenID Foundation FAPI WG: June 2017 Update
OpenID Foundation FAPI WG: June 2017 Update
Nat Sakimura
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
Nat Sakimura
Introduction to the FAPI Read & Write OAuth Profile
Introduction to the FAPI Read & Write OAuth Profile
Nat Sakimura
ID連携概要 - OpenID TechNight vol.13
ID連携概要 - OpenID TechNight vol.13
Nov Matake
AWS Lambdaで作るクローラー/スクレイピング
AWS Lambdaで作るクローラー/スクレイピング
Takuro Sasaki
Destaque
(6)
ブロックチェーン〜信頼の源泉の民主化のもたらす変革
ブロックチェーン〜信頼の源泉の民主化のもたらす変革
OpenID Foundation FAPI WG: June 2017 Update
OpenID Foundation FAPI WG: June 2017 Update
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
Introduction to the FAPI Read & Write OAuth Profile
Introduction to the FAPI Read & Write OAuth Profile
ID連携概要 - OpenID TechNight vol.13
ID連携概要 - OpenID TechNight vol.13
AWS Lambdaで作るクローラー/スクレイピング
AWS Lambdaで作るクローラー/スクレイピング
Semelhante a 「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
Tatsuo Kudo
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
Tatsuo Kudo
OAuth 2.0の概要とセキュリティ
OAuth 2.0の概要とセキュリティ
Hiroshi Hayakawa
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
Tatsuo Kudo
FAPI Security について聞いてきた話(2017/08/18 社内勉強会)
FAPI Security について聞いてきた話(2017/08/18 社内勉強会)
Yoko TAMADA
How FIDO Works
How FIDO Works
Keiko Itakura
OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護
Naohiro Fujie
CLT-009_Windows 10 アプリとシングルサインオン ~Microsoft Passport の意義とその実装方法~
CLT-009_Windows 10 アプリとシングルサインオン ~Microsoft Passport の意義とその実装方法~
decode2016
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Tatsuo Kudo
LINEログインの最新アップデートとアプリ連携ウォークスルー
LINEログインの最新アップデートとアプリ連携ウォークスルー
Naohiro Fujie
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
Tatsuo Kudo
Cloud で Active Directory を活用するには
Cloud で Active Directory を活用するには
junichi anno
The Latest Specs of OpenID Connect at #idcon 9
The Latest Specs of OpenID Connect at #idcon 9
Ryo Ito
CSS2020 Client Policies on keycloak
CSS2020 Client Policies on keycloak
Hitachi, Ltd. OSS Solution Center.
OCHaCafe#5 - 避けては通れない!認証・認可
OCHaCafe#5 - 避けては通れない!認証・認可
オラクルエンジニア通信
FAPI and beyond - よりよいセキュリティのために
FAPI and beyond - よりよいセキュリティのために
Nat Sakimura
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
Masaru Kurahayashi
認証技術、デジタルアイデンティティ技術の最新動向
認証技術、デジタルアイデンティティ技術の最新動向
Tatsuo Kudo
[AWS DevDay] Cognito / Amplify で加速するエンタープライズのアプリケーション開発
[AWS DevDay] Cognito / Amplify で加速するエンタープライズのアプリケーション開発
Yuki Ando
FAPI and Beyond: From an specification author's point of view #fapisum - Japa...
FAPI and Beyond: From an specification author's point of view #fapisum - Japa...
FinTechLabs.io
Semelhante a 「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api
(20)
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth 2.0の概要とセキュリティ
OAuth 2.0の概要とセキュリティ
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
FAPI Security について聞いてきた話(2017/08/18 社内勉強会)
FAPI Security について聞いてきた話(2017/08/18 社内勉強会)
How FIDO Works
How FIDO Works
OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護
CLT-009_Windows 10 アプリとシングルサインオン ~Microsoft Passport の意義とその実装方法~
CLT-009_Windows 10 アプリとシングルサインオン ~Microsoft Passport の意義とその実装方法~
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
LINEログインの最新アップデートとアプリ連携ウォークスルー
LINEログインの最新アップデートとアプリ連携ウォークスルー
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
Cloud で Active Directory を活用するには
Cloud で Active Directory を活用するには
The Latest Specs of OpenID Connect at #idcon 9
The Latest Specs of OpenID Connect at #idcon 9
CSS2020 Client Policies on keycloak
CSS2020 Client Policies on keycloak
OCHaCafe#5 - 避けては通れない!認証・認可
OCHaCafe#5 - 避けては通れない!認証・認可
FAPI and beyond - よりよいセキュリティのために
FAPI and beyond - よりよいセキュリティのために
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
認証技術、デジタルアイデンティティ技術の最新動向
認証技術、デジタルアイデンティティ技術の最新動向
[AWS DevDay] Cognito / Amplify で加速するエンタープライズのアプリケーション開発
[AWS DevDay] Cognito / Amplify で加速するエンタープライズのアプリケーション開発
FAPI and Beyond: From an specification author's point of view #fapisum - Japa...
FAPI and Beyond: From an specification author's point of view #fapisum - Japa...
Mais de Tatsuo Kudo
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Tatsuo Kudo
金融APIセキュリティの動向・事例と今後の方向性
金融APIセキュリティの動向・事例と今後の方向性
Tatsuo Kudo
Client Initiated Backchannel Authentication (CIBA) and Authlete’s Approach
Client Initiated Backchannel Authentication (CIBA) and Authlete’s Approach
Tatsuo Kudo
In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021
In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021
Tatsuo Kudo
Authlete: API Authorization Enabler for API Economy
Authlete: API Authorization Enabler for API Economy
Tatsuo Kudo
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
Tatsuo Kudo
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
Tatsuo Kudo
Financial-grade API Hands-on with Authlete
Financial-grade API Hands-on with Authlete
Tatsuo Kudo
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...
Tatsuo Kudo
英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要
Tatsuo Kudo
オープン API と Authlete のソリューション
オープン API と Authlete のソリューション
Tatsuo Kudo
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
Tatsuo Kudo
APIエコノミー時代の認証・認可
APIエコノミー時代の認証・認可
Tatsuo Kudo
Japan/UK Open Banking and APIs Summit 2018 TOI
Japan/UK Open Banking and APIs Summit 2018 TOI
Tatsuo Kudo
Trends in Banking APIs
Trends in Banking APIs
Tatsuo Kudo
銀行APIのトレンド #fapisum
銀行APIのトレンド #fapisum
Tatsuo Kudo
アイデンティティ (ID) 技術の最新動向とこれから
アイデンティティ (ID) 技術の最新動向とこれから
Tatsuo Kudo
OAuth Security Workshop 2017 #osw17
OAuth Security Workshop 2017 #osw17
Tatsuo Kudo
APIdays Australia 2017 TOI #APIdaysAU
APIdays Australia 2017 TOI #APIdaysAU
Tatsuo Kudo
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
Tatsuo Kudo
Mais de Tatsuo Kudo
(20)
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
Apigee の FAPI & CIBA 対応を実現する「Authlete (オースリート)」
金融APIセキュリティの動向・事例と今後の方向性
金融APIセキュリティの動向・事例と今後の方向性
Client Initiated Backchannel Authentication (CIBA) and Authlete’s Approach
Client Initiated Backchannel Authentication (CIBA) and Authlete’s Approach
In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021
In-house OAuth/OIDC Infrastructure as a Competitive Advantage #eic2021
Authlete: API Authorization Enabler for API Economy
Authlete: API Authorization Enabler for API Economy
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
Financial-grade API Hands-on with Authlete
Financial-grade API Hands-on with Authlete
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC ...
英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要
オープン API と Authlete のソリューション
オープン API と Authlete のソリューション
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
APIエコノミー時代の認証・認可
APIエコノミー時代の認証・認可
Japan/UK Open Banking and APIs Summit 2018 TOI
Japan/UK Open Banking and APIs Summit 2018 TOI
Trends in Banking APIs
Trends in Banking APIs
銀行APIのトレンド #fapisum
銀行APIのトレンド #fapisum
アイデンティティ (ID) 技術の最新動向とこれから
アイデンティティ (ID) 技術の最新動向とこれから
OAuth Security Workshop 2017 #osw17
OAuth Security Workshop 2017 #osw17
APIdays Australia 2017 TOI #APIdaysAU
APIdays Australia 2017 TOI #APIdaysAU
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api
1.
FinTech X Security-JAWS
勉強会 #01 「金融API向けOAuth」にみるOAuthプロファイリングの実際 2017-06-16 工藤達雄 http://www.linkedin.com/in/tatsuokudo Cyber Consulting Services NRI SecureTechnologies, Ltd.
2.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 1 工藤達雄 http://www.linkedin.com/in/tatsuokudo/ @tkudos / https://fb.me/tkudo サン・マイクロシステムズ (1998~2008) 野村総合研究所 (2008~) OpenIDファウンデーション・ジャパン (2013~2014) NRIセキュアテクノロジーズ (2014~) ▪ 現在はデジタル・アイデンティティとAPIを専門とする コンサルティングに従事 自己紹介
3.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 2 OpenID Foundation 配下のワーキンググループが策定を進めている 「Financial API (FAPI)」 https://openid.net/wg/fapi/ をネタに API セキュリティにおける OAuth 2.0 適用(プロファイリング)の ベストプラクティスとその先について紹介します。 本プレゼンテーションの内容
4.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 3 OAuthとは? APIアクセス(フルオープン) API サーバー APP APIクライアント HTML5 WEBSITE 1 GET /items/12345 HTTP/1.1
5.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 4 OAuthとは? APIアクセスを「クライアントのクレデンシャル」で制限する API サーバー APP APIクライアント HTML5 WEBSITE 1 ****** GET /items/12345 HTTP/1.1 x-api-key: ****** クライアントのクレデンシャルを要求
6.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 5 OAuthとは? 「クライアントのクレデンシャル」をもとに付与した「トークン」でAPIアクセスを制限する OAuth 2.0 (RFC 6749) の「クライアント・クレデンシャル・グラント」 リソース サーバー APP 認可 サーバー クライアント HTML5 WEBSITE 2 2. アクセストークン 提供 3 3. アクセストークンを 使ってAPIアクセス 1 1. クライアントのクレデンシャルを 使ってトークンリクエスト ****** アクセストークンを要求 クライアントのクレデンシャルを以て アクセストークンを提供する
7.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 6 OAuthとは? リソースオーナーのID/パスワードを使ってAPIのアクセスを制限したい場合には? リソースオーナー リソース サーバー APP クライアント HTML5 WEBSITE 0 0. ID/パスワードを登録 ユーザーID: johndoe パスワード: ****** 1 1. ID/パスワードを 使ってAPIアクセス ユーザーID: johndoe パスワード: ****** ID/パスワードを要求
8.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 7 OAuthとは? 「リソースオーナーのID/パスワード」をもとに付与した「トークン」でAPIアクセスを制限する OAuth 2.0 (RFC 6749) の「リソース・オーナー・パスワード・クレデンシャル・グラント」 ※非推奨 リソースオーナー リソース サーバー APP 認可 サーバー クライアント HTML5 WEBSITEWEBSITE 0 0. ID/パスワードを登録 ユーザーID: johndoe パスワード: ****** 2 2. アクセストークン 提供 3 3. アクセストークンを 使ってAPIアクセス 1 1. クライアントのクレデンシャルと ユーザーのID/パスワードを 使ってトークンリクエスト クライアントのクレデンシャル: ****** ユーザーID: johndoe パスワード: ****** アクセストークンを要求 リソースオーナーのクレデンシャル を以てアクセストークンを提供する
9.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 8 OAuthとは? 「認可コード」をもとに付与した「トークン」でAPIアクセスを制限する OAuth 2.0 (RFC 6749) の「認可コード・グラント」 リソースオーナー リソース サーバー 認可 サーバー クライアント WEBSITE 0 0. リソースへのアクセスを リクエスト 7 7. アクセストークンを 使ってAPIアクセス ユーザーエージェント 1 1. 認可リクエスト (ブラウザ リダイレクト) 2 2. ユーザー認証 & クライアントへの権限委譲の確認 4 4. 認可コード提供 (ブラウザリダイレクト) 6 6. アクセストークン 提供 3 3. OK! ユーザーID: johndoe パスワード: ****** 5 5. クライアントの クレデンシャルと 認可コードを使って トークンリクエスト ****** アクセストークンを要求 認可コードを以て アクセストークンを提供する
10.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 9 「Amazon API Gateway with カスタム・オーソライザー」と「外部認可サーバー」による構成例 API Gatewayは認可サーバーと連携し、クライアントから受け取ったアクセストークンを検証する リソースオーナー クライアント WEBSITE 0 7 ユーザーエージェント 1 2 3 4 6 5 ****** API Gateway “カスタム・ オーソライザー” (Lambda関数) リソースサーバー 認可サーバー (e.g. Authlete, Hydra, WSO2 etc.) 認可依頼 検証依頼 検証結果 ポリシー Lambda 関数やEC2上 のエンドポイント、あるい は外部のエンドポイントへ 参考情報: http://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/use-custom-authorizer.html http://qiita.com/TakahikoKawasaki/items/b372ab49da0a9aedb76a https://blogs.edwardwilde.com/2017/01/12/creating-an-oauth2-custom-lamda-authorizer-for-use-with-amazons-aws-api-gateway-using-hydra/ http://www.dushantech.com/2016/10/wso2-is-with-amazon-api-gateway.html
11.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 10 OAuthは「プロトコル」ではなく「フレームワーク」。 実際のサービスに適用するにはそこからいろいろな決めごとを考えていく(プロファイリングする)必要がある リソースオーナー リソース サーバー 認可 サーバー クライアント WEBSITE 0 7 ユーザーエージェント 1 2 3 4 6 5 認可リクエストの形式 リソースオーナーの認証・同意方法 トークンリクエスト の形式 トークンレスポンス の形式 アクセストークンの ライフサイクル アクセストークンの 利用方法 ****** クライアント 認証の方式
12.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 11 決めごとの例 クライアント側に用意する「認可コードの受け口」 クライアントは認可リクエストを認可サーバーに送信する際に redirect_uriパラメーターを用いて、どの「リダイレクション・エンド ポイント」に認可コードを送信してほしいかを指定することができる 認可サーバーはリソースオーナーとのインタラクションを行った後、 ユーザーエージェントに、「リダイレクション・エンドポイントへの リダイレクトレスポンス」として認可コードを返却する。これにより ユーザーエージェントは「リダイレクション・エンドポイント」への リクエストとして、そのパラメーターを自動的に送信することになる クライアントの「リダイレクション・エンドポイント」 リソース オーナー 認可 サーバー クライアント 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
13.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 12 決めごとの例 仕様上(RFC 6749 3.1.2.2)、クライアントのリダイレクション・ エンドポイントは認可サーバーに事前登録すべき (SHOULD) “The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint” “The authorization server SHOULD require the client to provide the complete redirection URI” これを認可サーバーはどう解釈するか? 1. “SHOULD” であり、事前登録しなくてもよい。 クライアントは認可リクエスト時に任意の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を どう扱うか?
14.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 13 決めごとの例 クライアントが認可リクエストのパラメーターとして設定する値 認可リクエストに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
15.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 14 決めごとの例 仕様上(RFC 6749 4.1.1)、stateパラメーターの利用は推奨 (RECOMMENDED) “RECOMMENDED. An opaque value used by the client to maintain state between the request and callback.” “The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.” これをクライアントはどう解釈するか? 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の値を どう作るか?
16.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 15 決めごとの例 仕様上 (RFC 6749 2.3)、認可サーバーはクライアント認証に任意の 手段を用いることができ、そのひとつとしてクライアントパスワードの 用法が定義されている (同 2.3.1) “The authorization server MAY accept any form of client authentication meeting its security requirements.” “Clients in possession of a client password MAY use the HTTP Basic authentication scheme” 一方、仕様上 (同 10.1)、単なるクライアントパスワードではない より強固なクライアント認証を行うことが推奨されている “The authorization server is encouraged to consider stronger client authentication means than a client password.” これを認可サーバーはどう解釈するか? 1. クライアントパスワードを使って認証 2. 加えてIPアドレス制限 3. あるいはTLS双方向認証 4. またはSAMLやJWTなどの「セキュリティ・アサーション」による認証 トークンリクエストにおけるクライアント認証 リソース オーナー 認可 サーバー クライアント WEBSITE ユーザー エージェント リダイレクション エンドポイント 32 14 6 6 5 ****** 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 Base64(client_id:client_secret) で良い?
17.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 16 金融分野のAPIにおけるOAuthの「詳細仕様の標準化」 → プロファイルの標準化 が期待されてる(んだと思う) オープンAPIのあり方に関する検討会報告書-オープン・イノベーションの活性化に向けて-【中間的な整理(案)】 https://www.zenginkyo.or.jp/fileadmin/res/news/news290316_2.pdf
18.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 17 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)」を規定
19.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 18 FAPI クライアントの「リダイレクション・エンドポイント」 認可サーバーはクライアントのリダイレクト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の利用)
20.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 19 FAPI 5.2.2 Authorization Server The Authorization Server 1. shall support confidential clients 2. should support public clients 3. shall provide a client secret that adheres to the requirements in section 16.19 of OIDC if a symmetric key is used 4. shall authenticate the confidential client at the Token Endpoint using one of the following methods: 1. TLS mutual authentication TLSM; 2. JWS Client Assertion using the client_secret or a private key as specified in section 9 of OIDC 5. shall require a key of size 2048 bits or larger if RSA algorithms are used for the client authentication 6. shall require a key of size 160 bits or larger if elliptic curve algorithms are used for the client authentication 7. shall support RFC7636 with S256 as the code challenge method if it supports public clients 8. shall require Redirect URIs to be pre-registered 9. shall require the redirect_uri parameter in the authorization request 10. shall require the value of redirect_uri to exactly match one of the pre-registered Redirect URIs 11. shall require user authentication at LoA 2 as defined in X.1254 or more 12. shall require explicit consent by the user to authorize the requested scope if it has not been previously authorized “Part 1: 「読み出し専用」 APIセキュリティ・プロファイル” における認可サーバーのセキュリティ条項 (認可サーバーだけではなくクライアントとリソースサーバーについてもそれぞれ別途セキュリティ条項があることに留意) Source: https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_001.md 13. shall verify that the Authorization Code (section 1.3.1 of RFC6749) has not been previously used if possible 14. shall return token responses that conform to section 4.1.4 of RFC6749 15. shall return the list of allowed scopes with the issued access token 16. shall provide opaque non-guessable access tokens with a minimum of 128 bits as defined in section 5.1.4.2.2 of RFC6819 17. should clearly identify long-term grants to the user during authorization as in 16.18 of OIDC 18. should provide a mechanism for the end-user to revoke access tokens and refresh tokens granted to a Client as in 16.18 of OIDC 19. shall support the authentication request as in Section 3.1.2.1 of OIDC 20. shall perform the authentication request verification as in Section 3.1.2.2 of OIDC 21. shall authenticate the user as in Section 3.1.2.2 and 3.1.2.3 of OIDC 22. shall provide the authentication response as in Section 3.1.2.4 and 3.1.2.5 of OIDC depending on the outcome of the authentication 23. shall perform the token request verification as in Section 3.1.3.2 of OIDC 24. shall issue an ID Token in the token response when openid was included in the requested scope as in Section 3.1.3.3 of OIDC with its sub value corresponding to the authenticated user and optional acr value in ID Token
21.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 20 FAPI Part 1のセキュリティ条項を遵守した上で、さらに追加の対策が求められている 私的ハイライト: OpenID Connect の「ハイブリッド・フロー」 ▪ 認可サーバーは、クライアントからの認可リクエストにおいて、response_type として「code id_token」もしくは「code id_token token」を要求すること 「分離署名」としてのIDトークン ▪ 認可サーバーは、認可レスポンスへの「分離署名」として機能する IDトークンを返却すること リクエスト・オブジェクト ▪ 認可サーバーはクライアントに対し、request もしくは request_uriパラメータを 用いて認可リクエストを JWS signed JWT とするよう求めること “Holder of Key” ▪ 認可サーバーは「holder of key」の認可コード、アクセストークン、リフレッシュ トークンを返却すること。また「holder of key」機構として、OAuth 2.0 Token Binding もしくは Mutual TLS Profiles for OAuth Clients をサポートすること “Part 2: 「読み書き」 APIセキュリティ・プロファイル” に盛り込まれる(であろう)セキュリティ条項 Source: https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md
22.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 21 OAuth を活用してAPIアクセス認可を実現する ためには「プロファイリング」が必要です 金融向けAPIはもとより、それに限らず一般的 にOAuthのプロファイリングを行う際には、 OpenID Foundation の Financial API WG が 策定を進めている仕様群は要チェックです まとめ
23.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 22 使える「車輪」や「車輪の部品」はたくさんある 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 (和訳) ▪ “This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol.” draft-ietf-oauth-security-topics: OAuthセキュリティ・トピックス https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics ▪ “This draft gives a comprehensive overview on open OAuth security topics. It is intended to serve as a working document for the OAuth working group to systematically capture and discuss these security topics and respective mitigations and eventually recommend best current practice and also OAuth extensions needed to cope with the respective security threats.” draft-ietf-oauth-native-apps: ネイティブ・アプリケーション向けのOAuth 2.0 https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps ▪ “OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice.” DO IT YOURSELF!!
24.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 23 [PR]☺ ”APIセキュリティ” で検索していただければ幸いです NRIセキュアの 「APIセキュリティコンサルティングサービス」 https://www.nri-secure.co.jp/service/consulting/apisecurity.html
Baixar agora