Submit Search
Upload
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
•
30 likes
•
13,410 views
Tatsuo Kudo
Follow
Prepared for 情報セキュリティワークショップ in 越後湯沢 2017 http://anisec.jp/yuzawa/?page_id=491
Read less
Read more
Internet
Report
Share
Report
Share
1 of 53
Download now
Download to read offline
Recommended
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
Nov Matake
Keycloak拡張入門
Keycloak拡張入門
Hiroyuki Wada
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
Hitachi, Ltd. OSS Solution Center.
これからのネイティブアプリにおけるOpenID Connectの活用
これからのネイティブアプリにおけるOpenID Connectの活用
Masaru Kurahayashi
Keycloak入門
Keycloak入門
Hiroyuki Wada
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
Masaru Kurahayashi
Keycloakのステップアップ認証について
Keycloakのステップアップ認証について
Hitachi, Ltd. OSS Solution Center.
なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景
Tatsuo Kudo
Recommended
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
Nov Matake
Keycloak拡張入門
Keycloak拡張入門
Hiroyuki Wada
KeycloakでAPI認可に入門する
KeycloakでAPI認可に入門する
Hitachi, Ltd. OSS Solution Center.
これからのネイティブアプリにおけるOpenID Connectの活用
これからのネイティブアプリにおけるOpenID Connectの活用
Masaru Kurahayashi
Keycloak入門
Keycloak入門
Hiroyuki Wada
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
Masaru Kurahayashi
Keycloakのステップアップ認証について
Keycloakのステップアップ認証について
Hitachi, Ltd. OSS Solution Center.
なぜOpenID Connectが必要となったのか、その歴史的背景
なぜOpenID Connectが必要となったのか、その歴史的背景
Tatsuo Kudo
実装して理解するLINE LoginとOpenID Connect入門
実装して理解するLINE LoginとOpenID Connect入門
Naohiro Fujie
NGINXをBFF (Backend for Frontend)として利用した話
NGINXをBFF (Backend for Frontend)として利用した話
Hitachi, Ltd. OSS Solution Center.
OSS+AWSでここまでできるDevSecOps (Security-JAWS第24回)
OSS+AWSでここまでできるDevSecOps (Security-JAWS第24回)
Masaya Tahara
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
Keycloakの最近のトピック
Keycloakの最近のトピック
Hitachi, Ltd. OSS Solution Center.
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
Tatsuo Kudo
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
Masaru Kurahayashi
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Tatsuo Kudo
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
今なら間に合う分散型IDとEntra Verified ID
今なら間に合う分散型IDとEntra Verified ID
Naohiro Fujie
OpenID Connect入門
OpenID Connect入門
土岐 孝平
Azure AD による Web API の 保護
Azure AD による Web API の 保護
junichi anno
[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな
[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな
Amazon Web Services Japan
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
Amazon Web Services Japan
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
Keycloakの実際・翻訳プロジェクト紹介
Keycloakの実際・翻訳プロジェクト紹介
Hiroyuki Wada
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
Shinya Yamaguchi
IDガバナンス&管理の基礎
IDガバナンス&管理の基礎
Hitachi, Ltd. OSS Solution Center.
OpenID ConnectとSCIMの標準化動向
OpenID ConnectとSCIMの標準化動向
Tatsuo Kudo
OpenID Connect のビジネスチャンス
OpenID Connect のビジネスチャンス
OpenID Foundation Japan
WebAPIのこれまでとこれから
WebAPIのこれまでとこれから
Yohei Yamamoto
More Related Content
What's hot
実装して理解するLINE LoginとOpenID Connect入門
実装して理解するLINE LoginとOpenID Connect入門
Naohiro Fujie
NGINXをBFF (Backend for Frontend)として利用した話
NGINXをBFF (Backend for Frontend)として利用した話
Hitachi, Ltd. OSS Solution Center.
OSS+AWSでここまでできるDevSecOps (Security-JAWS第24回)
OSS+AWSでここまでできるDevSecOps (Security-JAWS第24回)
Masaya Tahara
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
Keycloakの最近のトピック
Keycloakの最近のトピック
Hitachi, Ltd. OSS Solution Center.
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
Tatsuo Kudo
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
Masaru Kurahayashi
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Tatsuo Kudo
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
今なら間に合う分散型IDとEntra Verified ID
今なら間に合う分散型IDとEntra Verified ID
Naohiro Fujie
OpenID Connect入門
OpenID Connect入門
土岐 孝平
Azure AD による Web API の 保護
Azure AD による Web API の 保護
junichi anno
[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな
[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな
Amazon Web Services Japan
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
Amazon Web Services Japan
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
Keycloakの実際・翻訳プロジェクト紹介
Keycloakの実際・翻訳プロジェクト紹介
Hiroyuki Wada
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
Shinya Yamaguchi
IDガバナンス&管理の基礎
IDガバナンス&管理の基礎
Hitachi, Ltd. OSS Solution Center.
OpenID ConnectとSCIMの標準化動向
OpenID ConnectとSCIMの標準化動向
Tatsuo Kudo
What's hot
(20)
実装して理解するLINE LoginとOpenID Connect入門
実装して理解するLINE LoginとOpenID Connect入門
NGINXをBFF (Backend for Frontend)として利用した話
NGINXをBFF (Backend for Frontend)として利用した話
OSS+AWSでここまでできるDevSecOps (Security-JAWS第24回)
OSS+AWSでここまでできるDevSecOps (Security-JAWS第24回)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
Keycloakの最近のトピック
Keycloakの最近のトピック
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい (2020 年 2 月) #authlete
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
今なら間に合う分散型IDとEntra Verified ID
今なら間に合う分散型IDとEntra Verified ID
OpenID Connect入門
OpenID Connect入門
Azure AD による Web API の 保護
Azure AD による Web API の 保護
[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな
[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
202110 AWS Black Belt Online Seminar AWS Site-to-Site VPN
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
Keycloakの実際・翻訳プロジェクト紹介
Keycloakの実際・翻訳プロジェクト紹介
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
IDガバナンス&管理の基礎
IDガバナンス&管理の基礎
OpenID ConnectとSCIMの標準化動向
OpenID ConnectとSCIMの標準化動向
Viewers also liked
OpenID Connect のビジネスチャンス
OpenID Connect のビジネスチャンス
OpenID Foundation Japan
WebAPIのこれまでとこれから
WebAPIのこれまでとこれから
Yohei Yamamoto
Beginning Java EE 6 勉強会(6) #bje_study
Beginning Java EE 6 勉強会(6) #bje_study
Masato Kawamura
サバフェス 2016 Yahoo! ID連携のご紹介 〜OpenID Connect入門〜
サバフェス 2016 Yahoo! ID連携のご紹介 〜OpenID Connect入門〜
Masaru Kurahayashi
Microserviceなんて最初からやるもんじゃ無かった
Microserviceなんて最初からやるもんじゃ無かった
Akira Miki
REST 入門
REST 入門
Yohei Yamamoto
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
Nat Sakimura
今更聞けないOAuth2.0
今更聞けないOAuth2.0
Takahiro Sato
Office365のIdentity管理
Office365のIdentity管理
Naohiro Fujie
Spring Bootをはじめる時にやるべき10のこと
Spring Bootをはじめる時にやるべき10のこと
心 谷本
エンタープライズITでのOpenID Connect利用ガイドライン
エンタープライズITでのOpenID Connect利用ガイドライン
Tatsuo Kudo
Uberご紹介(髙橋正巳)
Uberご紹介(髙橋正巳)
一般社団法人シェアリングエコノミー協会
[AWSマイスターシリーズ] AWS CLI / AWS Tools for Windows PowerShell
[AWSマイスターシリーズ] AWS CLI / AWS Tools for Windows PowerShell
Amazon Web Services Japan
Viewers also liked
(13)
OpenID Connect のビジネスチャンス
OpenID Connect のビジネスチャンス
WebAPIのこれまでとこれから
WebAPIのこれまでとこれから
Beginning Java EE 6 勉強会(6) #bje_study
Beginning Java EE 6 勉強会(6) #bje_study
サバフェス 2016 Yahoo! ID連携のご紹介 〜OpenID Connect入門〜
サバフェス 2016 Yahoo! ID連携のご紹介 〜OpenID Connect入門〜
Microserviceなんて最初からやるもんじゃ無かった
Microserviceなんて最初からやるもんじゃ無かった
REST 入門
REST 入門
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG
今更聞けないOAuth2.0
今更聞けないOAuth2.0
Office365のIdentity管理
Office365のIdentity管理
Spring Bootをはじめる時にやるべき10のこと
Spring Bootをはじめる時にやるべき10のこと
エンタープライズITでのOpenID Connect利用ガイドライン
エンタープライズITでのOpenID Connect利用ガイドライン
Uberご紹介(髙橋正巳)
Uberご紹介(髙橋正巳)
[AWSマイスターシリーズ] AWS CLI / AWS Tools for Windows PowerShell
[AWSマイスターシリーズ] AWS CLI / AWS Tools for Windows PowerShell
Similar to OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
Tatsuo Kudo
認証技術、デジタルアイデンティティ技術の最新動向
認証技術、デジタルアイデンティティ技術の最新動向
Tatsuo Kudo
「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api
「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api
Tatsuo Kudo
OAuth Security Workshop 2017 #osw17
OAuth Security Workshop 2017 #osw17
Tatsuo Kudo
NRIセキュアが考える持続可能なID&アクセス管理基盤の実現
NRIセキュアが考える持続可能なID&アクセス管理基盤の実現
Tatsuo Kudo
OpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けて
OpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けて
Takashi Yahata
OpenID ConnectとSCIMのエンタープライズ利用ガイドライン
OpenID ConnectとSCIMのエンタープライズ利用ガイドライン
Takashi Yahata
OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護
Naohiro Fujie
『OpenID ConnectとSCIMのエンタープライズ実装ガイドライン』解説
『OpenID ConnectとSCIMのエンタープライズ実装ガイドライン』解説
Takashi Yahata
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Hitachi, Ltd. OSS Solution Center.
Auth0でAWSの認証認可を強化
Auth0でAWSの認証認可を強化
Hideya Furuta
クラウド時代の「ID管理」と「認証セキュリティ」
クラウド時代の「ID管理」と「認証セキュリティ」
Tatsuya (達也) Katsuhara (勝原)
アイデンティティ (ID) 技術の最新動向とこれから
アイデンティティ (ID) 技術の最新動向とこれから
Tatsuo Kudo
初めてのAuth0ハンズオン
初めてのAuth0ハンズオン
Hisashi Yamaguchi
リクルーティングパートナーシップのご提案
リクルーティングパートナーシップのご提案
DIVE INTO CODE Corp.
あなたはどうデータを守る?クラウド・AI・自動化を使った、みえない脅威との戦い方
あなたはどうデータを守る?クラウド・AI・自動化を使った、みえない脅威との戦い方
オラクルエンジニア通信
オープン API と Authlete のソリューション
オープン API と Authlete のソリューション
Tatsuo Kudo
Api meet up online#6 session1 ginco
Api meet up online#6 session1 ginco
Nihei Tsukasa
Authlete overview
Authlete overview
mtisol
Cloud Identity Summit 2012 TOI
Cloud Identity Summit 2012 TOI
Tatsuo Kudo
Similar to OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
(20)
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
利用者本位のAPI提供に向けたアイデンティティ (ID) 標準仕様の動向
認証技術、デジタルアイデンティティ技術の最新動向
認証技術、デジタルアイデンティティ技術の最新動向
「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api
「金融API向けOAuth」にみるOAuthプロファイリングの実際 #secjaws #finsecjaws01 #oauth #oidc #api
OAuth Security Workshop 2017 #osw17
OAuth Security Workshop 2017 #osw17
NRIセキュアが考える持続可能なID&アクセス管理基盤の実現
NRIセキュアが考える持続可能なID&アクセス管理基盤の実現
OpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けて
OpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けて
OpenID ConnectとSCIMのエンタープライズ利用ガイドライン
OpenID ConnectとSCIMのエンタープライズ利用ガイドライン
OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護
『OpenID ConnectとSCIMのエンタープライズ実装ガイドライン』解説
『OpenID ConnectとSCIMのエンタープライズ実装ガイドライン』解説
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Auth0でAWSの認証認可を強化
Auth0でAWSの認証認可を強化
クラウド時代の「ID管理」と「認証セキュリティ」
クラウド時代の「ID管理」と「認証セキュリティ」
アイデンティティ (ID) 技術の最新動向とこれから
アイデンティティ (ID) 技術の最新動向とこれから
初めてのAuth0ハンズオン
初めてのAuth0ハンズオン
リクルーティングパートナーシップのご提案
リクルーティングパートナーシップのご提案
あなたはどうデータを守る?クラウド・AI・自動化を使った、みえない脅威との戦い方
あなたはどうデータを守る?クラウド・AI・自動化を使った、みえない脅威との戦い方
オープン API と Authlete のソリューション
オープン API と Authlete のソリューション
Api meet up online#6 session1 ginco
Api meet up online#6 session1 ginco
Authlete overview
Authlete overview
Cloud Identity Summit 2012 TOI
Cloud Identity Summit 2012 TOI
More from 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
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
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
Tatsuo Kudo
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
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
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
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
APIdays Australia 2017 TOI #APIdaysAU
APIdays Australia 2017 TOI #APIdaysAU
Tatsuo Kudo
Random Thoughts on Digital Identity Professional #openid_eiwg
Random Thoughts on Digital Identity Professional #openid_eiwg
Tatsuo Kudo
API提供におけるOAuthの役割 #apijp
API提供におけるOAuthの役割 #apijp
Tatsuo Kudo
More from 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
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 ...
英国オープンバンキング技術仕様の概要
英国オープンバンキング技術仕様の概要
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
OAuth / OpenID Connect (OIDC) の最新動向と Authlete のソリューション
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authenticat...
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
#OAuth Security Workshop 2019 Recap @ #Authlete Partner Meetup Spring 2019
APIエコノミー時代の認証・認可
APIエコノミー時代の認証・認可
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
CIBA (Client Initiated Backchannel Authentication) の可能性 #authlete #api #oauth...
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
APIdays Australia 2017 TOI #APIdaysAU
APIdays Australia 2017 TOI #APIdaysAU
Random Thoughts on Digital Identity Professional #openid_eiwg
Random Thoughts on Digital Identity Professional #openid_eiwg
API提供におけるOAuthの役割 #apijp
API提供におけるOAuthの役割 #apijp
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
1.
情報セキュリティワークショップ in 越後湯沢
2017 OAuth / OpenID Connectを中心とする APIセキュリティについて 2017-10-06 工藤達雄 Cyber Consulting Services NRI SecureTechnologies, Ltd.
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 2 APIセキュリティ、とりわけアクセス認可に欠かせない 「OAuth」と「OpenID Connect」について、 適用例や仕様策定の動向をもとに、注意すべき ポイントや活用に向けたヒントをご紹介します。 本プレゼンテーションの内容
4.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 3 APIは新しい!? Source: 野村総合研究所
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.
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.
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.
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.
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.
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. OAuth
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 12 APIアクセス(フルオープン) API サーバー APP APIクライアント HTML5 WEBSITE 1 GET /items/12345 HTTP/1.1
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.
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.
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 16 「パスワード・アンチパターン」 Source: https://www.flickr.com/photos/factoryjoe/2110461562/ https://www.flickr.com/photos/ronin691/2110909518/
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.
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.
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 20 いわゆる “OAuth 2.0” RFC 6749: OAuth 2.0 認可フレームワーク RFC 6750: OAuth 2.0 認可フレームワーク: ベアラー・トークンの用法
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.
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. OAuthをどう使うか
25.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 24 「フレームワーク」であり、適用にはプロファイリングが必要 そもそもOAuth(2.0)はプロトコルではない リソースオーナー リソース サーバー 認可 サーバー クライアント WEBSITE 0 7 ユーザーエージェント 1 2 3 4 6 5 認可リクエストの形式 リソースオーナーの認証・同意方法 トークンリクエスト の形式 トークンレスポンス の形式 アクセストークンの ライフサイクル アクセストークンの 利用方法 ****** クライアント 認証の方式
26.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 25 OAuthプロファイリング101: ブラウザリダイレクト リソースオーナー リソース サーバー 認可 サーバー クライアント WEBSITE 0 7 ユーザーエージェント 2 3 4 6 5 ****** 4. 認可コード 提供(ブラウザ リダイレクト) 1. 認可リクエスト (ブラウザ リダイレクト) 1
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.
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.
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.
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.
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.
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 32 (実例)
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.
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.
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.
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.
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.
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.
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 40 (実例)
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. OAuth周辺の動向 (OpenID Connect, FAPI)
44.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 43 API サーバー OAuth仕様には「認証依頼」と「認証結果提供」のやりとり、 そして「認証結果」(ID情報)の定義は書かれていない エンドユーザー APP サードパーティ APIクライアント (Webサイトなど) サービス アクセス試行 APIアクセス 許可要求 APIアクセス 許可 APIアクセス サードパーティ Webサイト ユーザー認証 アクセス試行 認証依頼 認証結果提供 アイデンティティ連携 サードパーティに「いまアクセス してきたユーザーに関する情報」 を提供する APIアクセス認可 (OAuth) サードパーティに「ユーザーに 成り代わってアクセスをする ための許可証」を提供する 扱う情報が異なる
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.
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.
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.
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. まとめ
50.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 49 「ビジネス・モーメント」と「エコシステム」 ビジネス・モーメント 顧客に対してその瞬間に最も必要なサービスを エンドユーザー自発的な同意に基づいて提供 エコシステム 自社顧客へのサービスに他社のAPIを活用し 一方で別の事業者の顧客接点に対してAPIを提供 APIファースト 企業が自社のコアを外部に開放し、その機能を他社が取り込み、 エンドユーザーに対していままで提供できていなかった、 イノベーティブな価値やソリューションを創造するためのしくみ アイデンティティ & API セキュリティスタック
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.
Copyright © NRI
SecureTechnologies, Ltd. All rights reserved. 51 [PR]☺ ”APIセキュリティ” で検索していただければ幸いです NRIセキュアの 「APIセキュリティコンサルティングサービス」 https://www.nri-secure.co.jp/service/consulting/apisecurity.html
Download now