SlideShare a Scribd company logo
1 of 23
© Hitachi, Ltd. 2022. All rights reserved.
NGINXをBFF (Backend for Frontend)として利用した話
NGINXユーザー会 2022春
株式会社 日立製作所
田畑 義之
1
© Hitachi, Ltd. 2022. All rights reserved.
自己紹介
田畑 義之 (たばた よしゆき)
 株式会社 日立製作所
 ソフトウェアエンジニア
 GitHub: @y-tabata, Qiita: @yo-tabata
• 認証認可スペシャリストとしてのAPI/SSO関連案件の支援
 金融、公共、社会、産業分野における
API管理基盤や認証認可システムのコンサル/サポート
→ NGINXのコンサル実績も多数。
• 認証認可・API管理関連のOSSへのコントリビュート
 Keycloak (IAMのOSS)
 3scale (API管理のOSS)
 MidPoint (IGAのOSS)
• OSSの活用事例や検証結果の情報発信
 Keycloak書籍の執筆
 Qiita / ThinkITでのWeb記事投稿
 Apidays / API Specifications Conference / CloudNative Daysなど、国内外のイベントでの情報発信
© Hitachi, Ltd. 2022. All rights reserved.
Contents
2
1. APIゲートウェイとして一定の地位を確立したNGINX
2. 高セキュリティAPIシステムでBFFが必要な理由
3. NGINXをBFFとして利用する
© Hitachi, Ltd. 2022. All rights reserved.
Contents
3
1. APIゲートウェイとして一定の地位を確立したNGINX
2. 高セキュリティAPIシステムでBFFが必要な理由
3. NGINXをBFFとして利用する
4
© Hitachi, Ltd. 2022. All rights reserved.
APIシステム
オーソドックスなAPIシステム
3. APIコール w/ アクセストークン 4. 認可済みのAPIコール
1. 認証・同意取得
2. トークンの発行
認可サーバー
(Keycloakなど)
• APIを公開するリソースサーバーはまず必要。
• 加えて、APIの用途に応じた何かしらの認証認可の仕組みが必須。
 API認可の標準仕様であるOAuth 2.0の認可コードフローに準拠するのが一般的。
 そのために認証認可を司る認可サーバーを配置。
• アクセス制御のために、手前にAPIゲートウェイを置く構成もよく見受けられる。
エンドユーザー
0. 使用
APIゲートウェイ リソースサーバー
クライアント
5
© Hitachi, Ltd. 2022. All rights reserved.
参考: Keycloakとは
• Keycloakは、Red Hat社を中心に開発されているOSSのIAM製品。
• シングルサインオンや、OAuth 2.0の認可サーバーの機能を提供。
 OAuth 2.0/OpenID ConnectやSAMLに対応
 LDAPサーバーやActive Directoryと連携可能
 GitHubなどのユーザーアカウントを利用した
ソーシャルログインにも対応
Keycloak
主要標準に対応したID連携
(OAuth 2.0の認可サーバーを含む)
ソーシャルログイン
(Identity Brokering)
ID管理と認証
LDAP
Active
Directory
RDB
OpenID Connect SAML
GitHub
Twitter Facebook
主な特徴
6
© Hitachi, Ltd. 2022. All rights reserved.
NGINX APIゲートウェイ
3. APIコール w/ アクセストークン 4. 認可済みのAPIコール
1. 認証・同意取得
2. トークンの発行
認可サーバー
(Keycloakなど)
• NGINXはAPIゲートウェイの実装の最有力候補の一つ。
 圧倒的なパフォーマンス: APIゲートウェイは全APIコールを捌く必要があるため、とにかくパフォーマンスが重要。
 高いカスタマイズ性: 豊富なモジュールのほか、JavaScriptやLua言語で自由にカスタマイズができる。
APIを呼ぶ側と呼ばれる側双方の業務要件をここで吸収するため、カスタマイズ性も非常に重要。
→ 実際に、3scaleやKongといった著名なAPI管理製品は、APIゲートウェイのベースにNGINXを用いており、
それをLuaで拡張している。
エンドユーザー
0. 使用
APIゲートウェイ
(NGINXなど)
リソースサーバー
クライアント
NGINX + KeycloakのAPIシステム構成例は
以下の記事でも紹介しているので
是非ご参照ください。
「Keycloakで実現するAPIセキュリティ」
https://thinkit.co.jp/series/9721
© Hitachi, Ltd. 2022. All rights reserved.
Contents
7
1. APIゲートウェイとして一定の地位を確立したNGINX
2. 高セキュリティAPIシステムでBFFが必要な理由
3. NGINXをBFFとして利用する
8
© Hitachi, Ltd. 2022. All rights reserved.
オーソドックスなAPIシステムがハマらないケース ~某案件で直面した課題~
3. APIコール w/ アクセストークン 4. 認可済みのAPIコール
1. 認証・同意取得
2. トークンの発行
認可サーバー
(Keycloakなど)
エンドユーザー
0. 使用
APIゲートウェイ
(NGINXなど)
リソースサーバー
SPA
• 大体のケースにおいて、先に紹介したオーソドックスなAPIシステムで事足りるが、SPAのようなブラウザベースの
アプリケーションをクライアントとして想定し、かつ高いセキュリティ保護が必要なAPIを公開する場合には注意要。
 SPAでは、クライアントの認証情報やトークンなどの機密情報を安全に保管する術がない。
→ 漏えい時の影響をできる限り軽減するように設計するか、アーキを変えるか、の2択。高いセキュリティ保護が
必要なAPIを公開する場合、漏えい時のリスクを抱えきれないので、後者を採るケースも多い。
→ 実際、ブラウザベースのアプリケーションのセキュリティベストプラクティスは、グローバルでもまだ現在絶賛策定中。
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-09
金融取引や重要度の高い
情報を扱うAPIを公開
9
© Hitachi, Ltd. 2022. All rights reserved.
BFFを採用したアーキテクチャへの変更 ~我々の解決策~
3. APIコール
w/ Cookie
4. 認可済みの
APIコール
1. 認証・同意取得
2. トークンの発行
認可サーバー
(Keycloakなど)
エンドユーザー
0. 使用
APIゲートウェイ
(NGINXなど)
リソースサーバー
SPA
• このようなケースでBFF (Backend for Frontend)を採用する。
 APIシステムから見ると、クライアントはBFF。クライアント含めたサービス全体で
Webアプリケーション相当の高いセキュリティを担保できるようになる。
 SPAとBFFの間は、一般的なクッキーとセッションを使ったいわゆるクライアントサーバーシステム。
BFF 3’. APIコール
w/ アクセストークン
© Hitachi, Ltd. 2022. All rights reserved.
Contents
10
1. APIゲートウェイとして一定の地位を確立したNGINX
2. 高セキュリティAPIシステムでBFFが必要な理由
3. NGINXをBFFとして利用する
11
© Hitachi, Ltd. 2022. All rights reserved.
NGINXをBFFとして利用する
3. APIコール
w/ Cookie
4. 認可済みの
APIコール
1. 認証・同意取得
2. トークンの発行
認可サーバー
(Keycloakなど)
エンドユーザー
0. 使用
APIゲートウェイ
(NGINXなど)
リソースサーバー
SPA
BFF
(NGINXなど)
3’. APIコール
w/ アクセストークン
• BFFとしてもNGINXは優秀。
 BFFもAPIゲートウェイと同様、全APIコールを捌く必要があるため、パフォーマンスが重要。
 APIゲートウェイと比較して、よりクライアント側に寄り添った実装が必要になるため、
ここでも高いカスタマイズ性が重要。
12
© Hitachi, Ltd. 2022. All rights reserved.
BFFとしてのNGINXの導入
• BFFが持つべき基本的な機能
 OAuth 2.0のクライアント(OpenID Connect 1.0のRP)機能
 このアーキでは、BFFがOAuth 2.0のクライアントとして振舞うので、トークンを要求するなどの機能が
必要。
 セッション管理機能
 トークンなどの機密情報をBFFで管理するために、セッション管理機能が必要。
3. APIコール
w/ Cookie
4. 認可済みの
APIコール
1. 認証・同意取得
2. トークンの発行
認可サーバー
(Keycloakなど)
エンドユーザー
0. 使用
APIゲートウェイ
(NGINXなど)
リソースサーバー
SPA
BFF
(NGINXなど)
3’. APIコール
w/ アクセストークン
13
© Hitachi, Ltd. 2022. All rights reserved.
BFFとしてのNGINXの導入① ~ OAuth 2.0のクライアント機能 ~
• OAuth 2.0のクライアント(OpenID Connect 1.0のRP)機能を一から実装するのは大変なので、
既存のライブラリを参考にするのがおすすめ。
 Lua拡張: lua-resty-openidc
https://github.com/zmartzone/lua-resty-openidc
 JavaScript拡張: nginx-openid-connect
https://github.com/nginxinc/nginx-openid-connect
→ 商用版のNGINX Plusであれば、後者のJavaScript拡張を用いる方が圧倒的に楽。
OSS版のNGINXでも、後者を参考に実装することはできるが、後述するセッション管理が
うまくいかないため、前者のLua拡張を選択。
→ 両者とも、OpenID Connect 1.0のRP用のライブラリであるため、アクセストークンを付与してAPIを
コールする部分は自前で拡張する必要がある。
14
© Hitachi, Ltd. 2022. All rights reserved.
BFFとしてのNGINXの導入② ~ セッション管理機能 ~
• BFFが止まると、業務が停止する(APIコールができなくなる)ので、冗長化は必須。
• 加えて、片系停止時もセッションを維持するためには、セッションを共有する仕組みが必要。
 この事例ではRedisを採用。lua-resty-openidcを採用した場合、Redisと相性が良い。
一方、JavaScript拡張を選択すると、JavaScriptは元々フロントエンド用の言語であるため、
このDB接続の部分に苦労する。
 ちなみに、NGINX Plusであれば、ngx_http_keyval_moduleというモジュールを使うことで、
Redisのような他コンポーネントの導入なしにセッション共有を実現できる。
BFF
(NGINX)
BFF
(NGINX)
LB
Redisなど
15
© Hitachi, Ltd. 2022. All rights reserved.
BFFを実現するにあたっての注意点① ~ CSRF対策 ~
• クッキーとセッションを用いる以上、一般的なCSRF (Cross-Site Request Forgery)対策は必須。
• CSRF対策をしないと、BFFで正規のAPIコールかどうかを見分けることができず、APIの不正利用が可能に。
 対策例: SPAからのAPIコールを見分けるために、毎回ランダムな文字列をページに設定し、
APIコール時にBFF側で照合する、など。
APIコール
w/ Cookie
APIゲートウェイ
(NGINXなど)
SPA
BFF
(NGINXなど)
APIコール
w/ アクセストークン
エンドユーザー
攻撃者
攻撃者の口座に
送金するAPIのリンク
ブラウザ
APIコール
w/ Cookie
リンクをクリックすると
ブラウザ起動
16
© Hitachi, Ltd. 2022. All rights reserved.
BFFを実現するにあたっての注意点② ~ セッション共有 ~
• Lua拡張であるlua-resty-openidcを使って、複数インスタンス間でセッションを共有するときの注意点。
• lua-resty-openidcはセッション管理にlua-resty-sessionというライブラリを使用。
 $session_secretという変数をセッションの識別子として利用。デフォルトだと$session_secretに
ランダム値が設定される。
 クラスタ内全インスタンスの$session_secretに同じ値を設定しないとセッションが共有されないので
注意が必要。
BFF
(NGINX)
BFF
(NGINX)
LB
Redisなど
17
© Hitachi, Ltd. 2022. All rights reserved.
まとめ
- 以下を中心に、NGINXをBFFとして利用する事例をご紹介しました。
 NGINXがAPIゲートウェイの最有力候補の一つであること。
 クライアントがSPAの場合にBFFアーキテクチャがハマること。
 NGINXを利用してBFFアーキテクチャを実現するときの概要と注意点。
18
© Hitachi, Ltd. 2022. All rights reserved.
日立のサービス紹介: 強固なセキュリティを確保したAPI管理基盤の構築
todo:
説明文を入れる
お客さまシステムの要件に最適な「API管理基盤」を構築します。
スモールスタート向け構成からマイクロサービス向け構成まで幅広く対応し
それらに合ったAPIセキュリティを実現します。
ソ
リュー
ション
APIゲートウェイ
(NGINX /
NGINX Plus)
認可サーバー
(Keycloak)
認可
API管理基盤
流量制御
アクセス制御
DBサーバー
ユーザー管理
ID管理
Active Directory,
LDAPサーバー、
既存ユーザー管理
DBなどとの連携
外部ユーザー
Google, GitHub
とのSNS連携や、
Oktaなどの外部ID
管理製品との連携
バックエンド
APIサーバー
APIサーバー
APIサーバー
フロントエンド
Webアプリ
モバイルアプリ
外部サービス
特徴1
スモールスタート向けからマイクロ
サービス向けまで、お客さまのシス
テムに最適なAPI管理の実現が可能
特徴2
OSSを活用し、
最新のAPIセキュリティの実現が可能
特徴3
APIセキュリティやOSSの専門家とし
て
の高度な知見を活かし、導入から運
用までトータルにカバー
19
© Hitachi, Ltd. 2022. All rights reserved.
日立の強みを生かしたサービスの提供
F5社
技術・ノウハウ
OSSサービス
フィードバック
連携
日立はさまざまな分野におけるOSSのお客さまビジネスでの活用を
コミュニティ貢献で培った高い技術力とF5社との連携で、サービスを提供します。
お客さまビジネスでの活用
OSSを活用したシステム開発・構築
API管理ソリューション提供
OSS単独ではなく、システム要件に合わせたソフト
ウェアの組み合わせや処理フローの支援などにより、
日立のSI事業を強力に支援します
コミュニティ貢献
有用なOSSの目利き
OSSの発展への寄与、技術蓄積
お客さま案件のニーズをコミュニティにフィードバック、
国内外での講演活動や寄稿活動による発信、
技術者交流を積極的に行い、さまざまな用途に
柔軟に対応できるOSSに成長させます
OSSサービス提供
OSSを安心して使うための
サポートサービスの提供
コミュニティ活動で製品内部を知る、高度な技術者
が、知見をもとにした製品内部(ソースレベル)での
調査により、迅速な障害解決に導きます
20
© Hitachi, Ltd. 2022. All rights reserved.
日立はOSSコミュニティリーダーを擁する専門チームを保有し、金融(銀行、保険など)や公共、社会、産業など
さまざまな分野の案件を多数支援しています。
社外でも認証認可の専門家として認知されており、お客さまのご指名で案件対応した実績もあります。
多くの導入実績
CIO補佐官向けに監査説明ができるセキュリ
ティ専門家として要望を受け対応。
認証認可のフロー設計やAPI管理基盤構築の
支援を実施。
お客さまへOAuthやAPI管理の説明ができる
セキュリティ専門家としての要望を受け対応。
APIゲートウェイや認証認可サーバーの構築支
援を実施。
セミナーの日立講演をきっかけに日立の
セキュリティ技術力の高さを評価いただき、
日立をご指名頂いた。
日立の社外著作物で日立のセキュリティ技
術の高さを認知。
お客さまのご指名で案件を対応。
専門家としての技術力を評価さ
れ
対応した案件の一例
[金融] 某金融機関様 デジタル決済プラットフォーム
[公共] 某省庁様 国民向け申請システム [金融] 某金融機関様 API管理基盤構築
[金融] 某金融機関様 認証認可システムのトラブル対応
お客さまのご指名で対応した
対応した案件の一例
21
© Hitachi, Ltd. 2022. All rights reserved.
Trademarks
• OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other
countries.
• GitHub is a trademark or registered trademark of GitHub, Inc. in the United States and other
countries.
• Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries.
• NGINX is a registered trademark of F5 Networks, Inc. in the United States and other countries.
• Other brand names and product names used in this material are trademarks, registered trademarks,
or trade names of their respective holders.
NGINXをBFF (Backend for Frontend)として利用した話

More Related Content

What's hot

モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)NTT DATA Technology & Innovation
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Akihiro Suda
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法についてYuji Otani
 
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜Masaru Kurahayashi
 
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~Hitachi, Ltd. OSS Solution Center.
 
これからのネイティブアプリにおけるOpenID Connectの活用
これからのネイティブアプリにおけるOpenID Connectの活用これからのネイティブアプリにおけるOpenID Connectの活用
これからのネイティブアプリにおけるOpenID Connectの活用Masaru Kurahayashi
 
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーKubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーToru Makabe
 
今なら間に合う分散型IDとEntra Verified ID
今なら間に合う分散型IDとEntra Verified ID今なら間に合う分散型IDとEntra Verified ID
今なら間に合う分散型IDとEntra Verified IDNaohiro Fujie
 
組織の問題も解決するアーキテクチャ BackendsForFrontends
組織の問題も解決するアーキテクチャ BackendsForFrontends組織の問題も解決するアーキテクチャ BackendsForFrontends
組織の問題も解決するアーキテクチャ BackendsForFrontendsPIXTA Inc.
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021Hiroshi Tokumaru
 
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawawsOAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawawsTatsuo Kudo
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織Takafumi ONAKA
 
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDayマイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay都元ダイスケ Miyamoto
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014Nov Matake
 
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところY Watanabe
 
20200630 AWS Black Belt Online Seminar Amazon Cognito
20200630 AWS Black Belt Online Seminar Amazon Cognito20200630 AWS Black Belt Online Seminar Amazon Cognito
20200630 AWS Black Belt Online Seminar Amazon CognitoAmazon Web Services Japan
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAkihiro Kuwano
 
実装して理解するLINE LoginとOpenID Connect入門
実装して理解するLINE LoginとOpenID Connect入門実装して理解するLINE LoginとOpenID Connect入門
実装して理解するLINE LoginとOpenID Connect入門Naohiro Fujie
 

What's hot (20)

モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
モノリスからマイクロサービスへの移行 ~ストラングラーパターンの検証~(Spring Fest 2020講演資料)
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
 
Redisの特徴と活用方法について
Redisの特徴と活用方法についてRedisの特徴と活用方法について
Redisの特徴と活用方法について
 
認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜認証の課題とID連携の実装 〜ハンズオン〜
認証の課題とID連携の実装 〜ハンズオン〜
 
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
最近のKeycloakのご紹介 ~クライアントポリシーとFAPI~
 
これからのネイティブアプリにおけるOpenID Connectの活用
これからのネイティブアプリにおけるOpenID Connectの活用これからのネイティブアプリにおけるOpenID Connectの活用
これからのネイティブアプリにおけるOpenID Connectの活用
 
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーKubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
 
今なら間に合う分散型IDとEntra Verified ID
今なら間に合う分散型IDとEntra Verified ID今なら間に合う分散型IDとEntra Verified ID
今なら間に合う分散型IDとEntra Verified ID
 
組織の問題も解決するアーキテクチャ BackendsForFrontends
組織の問題も解決するアーキテクチャ BackendsForFrontends組織の問題も解決するアーキテクチャ BackendsForFrontends
組織の問題も解決するアーキテクチャ BackendsForFrontends
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
 
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawawsOAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
OAuth / OpenID Connectを中心とするAPIセキュリティについて #yuzawaws
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDayマイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
 
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014SAML / OpenID Connect / OAuth / SCIM 技術解説  - ID&IT 2014 #idit2014
SAML / OpenID Connect / OAuth / SCIM 技術解説 - ID&IT 2014 #idit2014
 
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
ツール比較しながら語る O/RマッパーとDBマイグレーションの実際のところ
 
20200630 AWS Black Belt Online Seminar Amazon Cognito
20200630 AWS Black Belt Online Seminar Amazon Cognito20200630 AWS Black Belt Online Seminar Amazon Cognito
20200630 AWS Black Belt Online Seminar Amazon Cognito
 
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティスAWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
 
Keycloak入門
Keycloak入門Keycloak入門
Keycloak入門
 
実装して理解するLINE LoginとOpenID Connect入門
実装して理解するLINE LoginとOpenID Connect入門実装して理解するLINE LoginとOpenID Connect入門
実装して理解するLINE LoginとOpenID Connect入門
 
IDガバナンス&管理の基礎
IDガバナンス&管理の基礎IDガバナンス&管理の基礎
IDガバナンス&管理の基礎
 

Similar to NGINXをBFF (Backend for Frontend)として利用した話

Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_insideAuthlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_insideTatsuo Kudo
 
Kongの概要と導入事例
Kongの概要と導入事例Kongの概要と導入事例
Kongの概要と導入事例briscola-tokyo
 
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向Hitachi, Ltd. OSS Solution Center.
 
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可Hitachi, Ltd. OSS Solution Center.
 
Kong meetup tokyo 2018.10.26 ブリスコラ
Kong meetup tokyo 2018.10.26 ブリスコラKong meetup tokyo 2018.10.26 ブリスコラ
Kong meetup tokyo 2018.10.26 ブリスコラbriscola-tokyo
 
技術選択とアーキテクトの役割
技術選択とアーキテクトの役割技術選択とアーキテクトの役割
技術選択とアーキテクトの役割Toru Yamaguchi
 
社内認証基盤用のVault Pluginを作るメリット
社内認証基盤用のVault Pluginを作るメリット社内認証基盤用のVault Pluginを作るメリット
社内認証基盤用のVault Pluginを作るメリットKatsuya Yamaguchi
 
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチKazuya Sugimoto
 
Unityゲームにオンラインランキングとゴースト機能を追加しよう!
Unityゲームにオンラインランキングとゴースト機能を追加しよう!Unityゲームにオンラインランキングとゴースト機能を追加しよう!
Unityゲームにオンラインランキングとゴースト機能を追加しよう!史識 川原
 
OpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けて
OpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けてOpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けて
OpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けてTakashi Yahata
 
OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護Naohiro Fujie
 
"Kongゲートウェイ2.5リリース" Kong Konnectアップデート オンラインミートアップ :kong 製品整理、優位性
"Kongゲートウェイ2.5リリース" Kong Konnectアップデート オンラインミートアップ :kong 製品整理、優位性"Kongゲートウェイ2.5リリース" Kong Konnectアップデート オンラインミートアップ :kong 製品整理、優位性
"Kongゲートウェイ2.5リリース" Kong Konnectアップデート オンラインミートアップ :kong 製品整理、優位性Junji Nishihara
 
AI-first Code Editor 「Cursor」の機能紹介
AI-first Code Editor 「Cursor」の機能紹介AI-first Code Editor 「Cursor」の機能紹介
AI-first Code Editor 「Cursor」の機能紹介ssuser39314d
 
Spring Social でソーシャルログインを実装する
Spring Social でソーシャルログインを実装するSpring Social でソーシャルログインを実装する
Spring Social でソーシャルログインを実装するRakuten Group, Inc.
 
【de:code 2020】 ハンズオンで学ぶ AI ~ Bot Framework Composer + QnA Maker / Custom Visi...
【de:code 2020】 ハンズオンで学ぶ AI ~ Bot Framework Composer + QnA Maker / Custom Visi...【de:code 2020】 ハンズオンで学ぶ AI ~ Bot Framework Composer + QnA Maker / Custom Visi...
【de:code 2020】 ハンズオンで学ぶ AI ~ Bot Framework Composer + QnA Maker / Custom Visi...日本マイクロソフト株式会社
 
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform拓将 平林
 

Similar to NGINXをBFF (Backend for Frontend)として利用した話 (20)

Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_insideAuthlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
Authlete: セキュアな金融 API 基盤の実現と Google Cloud の活用 #gc_inside
 
Kongの概要と導入事例
Kongの概要と導入事例Kongの概要と導入事例
Kongの概要と導入事例
 
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
 
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
 
Kong meetup tokyo 2018.10.26 ブリスコラ
Kong meetup tokyo 2018.10.26 ブリスコラKong meetup tokyo 2018.10.26 ブリスコラ
Kong meetup tokyo 2018.10.26 ブリスコラ
 
技術選択とアーキテクトの役割
技術選択とアーキテクトの役割技術選択とアーキテクトの役割
技術選択とアーキテクトの役割
 
社内認証基盤用のVault Pluginを作るメリット
社内認証基盤用のVault Pluginを作るメリット社内認証基盤用のVault Pluginを作るメリット
社内認証基盤用のVault Pluginを作るメリット
 
【初心者向け】API を使ってクラウドの管理を自動化しよう
【初心者向け】API を使ってクラウドの管理を自動化しよう【初心者向け】API を使ってクラウドの管理を自動化しよう
【初心者向け】API を使ってクラウドの管理を自動化しよう
 
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
#decode19 #MW04 誰のための API? Azure デベロッパーにもエンド ユーザーにも嬉しいAPI エコシステム活用アプローチ
 
Unityゲームにオンラインランキングとゴースト機能を追加しよう!
Unityゲームにオンラインランキングとゴースト機能を追加しよう!Unityゲームにオンラインランキングとゴースト機能を追加しよう!
Unityゲームにオンラインランキングとゴースト機能を追加しよう!
 
[Japan Tech summit 2017] DEP 005
[Japan Tech summit 2017] DEP 005[Japan Tech summit 2017] DEP 005
[Japan Tech summit 2017] DEP 005
 
20170705 apiをつくろう
20170705 apiをつくろう20170705 apiをつくろう
20170705 apiをつくろう
 
NGINXでの認可について考える
NGINXでの認可について考えるNGINXでの認可について考える
NGINXでの認可について考える
 
OpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けて
OpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けてOpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けて
OpenID ConnectとSCIMによるエンタープライズでのID連携活用に向けて
 
OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護OAuth2.0によるWeb APIの保護
OAuth2.0によるWeb APIの保護
 
"Kongゲートウェイ2.5リリース" Kong Konnectアップデート オンラインミートアップ :kong 製品整理、優位性
"Kongゲートウェイ2.5リリース" Kong Konnectアップデート オンラインミートアップ :kong 製品整理、優位性"Kongゲートウェイ2.5リリース" Kong Konnectアップデート オンラインミートアップ :kong 製品整理、優位性
"Kongゲートウェイ2.5リリース" Kong Konnectアップデート オンラインミートアップ :kong 製品整理、優位性
 
AI-first Code Editor 「Cursor」の機能紹介
AI-first Code Editor 「Cursor」の機能紹介AI-first Code Editor 「Cursor」の機能紹介
AI-first Code Editor 「Cursor」の機能紹介
 
Spring Social でソーシャルログインを実装する
Spring Social でソーシャルログインを実装するSpring Social でソーシャルログインを実装する
Spring Social でソーシャルログインを実装する
 
【de:code 2020】 ハンズオンで学ぶ AI ~ Bot Framework Composer + QnA Maker / Custom Visi...
【de:code 2020】 ハンズオンで学ぶ AI ~ Bot Framework Composer + QnA Maker / Custom Visi...【de:code 2020】 ハンズオンで学ぶ AI ~ Bot Framework Composer + QnA Maker / Custom Visi...
【de:code 2020】 ハンズオンで学ぶ AI ~ Bot Framework Composer + QnA Maker / Custom Visi...
 
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform
[REV UP] あなたならどう使う?最新Azureレシピ for LINE Platform
 

More from Hitachi, Ltd. OSS Solution Center.

Guide of authentication and authorization for cloud native applications with ...
Guide of authentication and authorization for cloud native applications with ...Guide of authentication and authorization for cloud native applications with ...
Guide of authentication and authorization for cloud native applications with ...Hitachi, Ltd. OSS Solution Center.
 
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩みKeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩みHitachi, Ltd. OSS Solution Center.
 
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...Hitachi, Ltd. OSS Solution Center.
 
Challenge to Implementing "Scalable" Authorization with Keycloak
Challenge to Implementing "Scalable" Authorization with KeycloakChallenge to Implementing "Scalable" Authorization with Keycloak
Challenge to Implementing "Scalable" Authorization with KeycloakHitachi, Ltd. OSS Solution Center.
 
Why Assertion-based Access Token is preferred to Handle-based one?
Why Assertion-based Access Token is preferred to Handle-based one?Why Assertion-based Access Token is preferred to Handle-based one?
Why Assertion-based Access Token is preferred to Handle-based one?Hitachi, Ltd. OSS Solution Center.
 
What API Specifications and Tools Help Engineers to Construct a High-Security...
What API Specifications and Tools Help Engineers to Construct a High-Security...What API Specifications and Tools Help Engineers to Construct a High-Security...
What API Specifications and Tools Help Engineers to Construct a High-Security...Hitachi, Ltd. OSS Solution Center.
 
Implementing security and availability requirements for banking API system us...
Implementing security and availability requirements for banking API system us...Implementing security and availability requirements for banking API system us...
Implementing security and availability requirements for banking API system us...Hitachi, Ltd. OSS Solution Center.
 
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...Lightweight Zero-trust Network Implementation and Transition with Keycloak an...
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...Hitachi, Ltd. OSS Solution Center.
 
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...Overall pictures of Identity provider mix-up attack patterns and trade-offs b...
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...Hitachi, Ltd. OSS Solution Center.
 
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~Hitachi, Ltd. OSS Solution Center.
 
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現Hitachi, Ltd. OSS Solution Center.
 

More from Hitachi, Ltd. OSS Solution Center. (20)

Guide of authentication and authorization for cloud native applications with ...
Guide of authentication and authorization for cloud native applications with ...Guide of authentication and authorization for cloud native applications with ...
Guide of authentication and authorization for cloud native applications with ...
 
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩みKeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
 
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
 
Challenge to Implementing "Scalable" Authorization with Keycloak
Challenge to Implementing "Scalable" Authorization with KeycloakChallenge to Implementing "Scalable" Authorization with Keycloak
Challenge to Implementing "Scalable" Authorization with Keycloak
 
KubeConRecap_nakamura.pdf
KubeConRecap_nakamura.pdfKubeConRecap_nakamura.pdf
KubeConRecap_nakamura.pdf
 
Security Considerations for API Gateway Aggregation
Security Considerations for API Gateway AggregationSecurity Considerations for API Gateway Aggregation
Security Considerations for API Gateway Aggregation
 
Why Assertion-based Access Token is preferred to Handle-based one?
Why Assertion-based Access Token is preferred to Handle-based one?Why Assertion-based Access Token is preferred to Handle-based one?
Why Assertion-based Access Token is preferred to Handle-based one?
 
What API Specifications and Tools Help Engineers to Construct a High-Security...
What API Specifications and Tools Help Engineers to Construct a High-Security...What API Specifications and Tools Help Engineers to Construct a High-Security...
What API Specifications and Tools Help Engineers to Construct a High-Security...
 
Implementing security and availability requirements for banking API system us...
Implementing security and availability requirements for banking API system us...Implementing security and availability requirements for banking API system us...
Implementing security and availability requirements for banking API system us...
 
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...Lightweight Zero-trust Network Implementation and Transition with Keycloak an...
Lightweight Zero-trust Network Implementation and Transition with Keycloak an...
 
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...Overall pictures of Identity provider mix-up attack patterns and trade-offs b...
Overall pictures of Identity provider mix-up attack patterns and trade-offs b...
 
Apache con@home 2021_sha
Apache con@home 2021_shaApache con@home 2021_sha
Apache con@home 2021_sha
 
Node-RED Installer, Standalone Installer using Electron
Node-RED Installer, Standalone Installer using ElectronNode-RED Installer, Standalone Installer using Electron
Node-RED Installer, Standalone Installer using Electron
 
Hacktoberfest 概要、Node-REDプロジェクト貢献手順
Hacktoberfest 概要、Node-REDプロジェクト貢献手順Hacktoberfest 概要、Node-REDプロジェクト貢献手順
Hacktoberfest 概要、Node-REDプロジェクト貢献手順
 
Node-RED v2.0新機能紹介
Node-RED v2.0新機能紹介Node-RED v2.0新機能紹介
Node-RED v2.0新機能紹介
 
Node-REDからREST APIに接続
Node-REDからREST APIに接続Node-REDからREST APIに接続
Node-REDからREST APIに接続
 
Node-RED v1.3新機能紹介
Node-RED v1.3新機能紹介Node-RED v1.3新機能紹介
Node-RED v1.3新機能紹介
 
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~
社会のコードを、書き換えよう~エンジニア起点のNew Normalな働き方~
 
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現
CloudNative Days Spring 2021 Online: Apache CamelおよびKeycloakを用いたAPI管理基盤の実現
 
CSS2020 Client Policies on keycloak
CSS2020 Client Policies on keycloak CSS2020 Client Policies on keycloak
CSS2020 Client Policies on keycloak
 

NGINXをBFF (Backend for Frontend)として利用した話

  • 1. © Hitachi, Ltd. 2022. All rights reserved. NGINXをBFF (Backend for Frontend)として利用した話 NGINXユーザー会 2022春 株式会社 日立製作所 田畑 義之
  • 2. 1 © Hitachi, Ltd. 2022. All rights reserved. 自己紹介 田畑 義之 (たばた よしゆき)  株式会社 日立製作所  ソフトウェアエンジニア  GitHub: @y-tabata, Qiita: @yo-tabata • 認証認可スペシャリストとしてのAPI/SSO関連案件の支援  金融、公共、社会、産業分野における API管理基盤や認証認可システムのコンサル/サポート → NGINXのコンサル実績も多数。 • 認証認可・API管理関連のOSSへのコントリビュート  Keycloak (IAMのOSS)  3scale (API管理のOSS)  MidPoint (IGAのOSS) • OSSの活用事例や検証結果の情報発信  Keycloak書籍の執筆  Qiita / ThinkITでのWeb記事投稿  Apidays / API Specifications Conference / CloudNative Daysなど、国内外のイベントでの情報発信
  • 3. © Hitachi, Ltd. 2022. All rights reserved. Contents 2 1. APIゲートウェイとして一定の地位を確立したNGINX 2. 高セキュリティAPIシステムでBFFが必要な理由 3. NGINXをBFFとして利用する
  • 4. © Hitachi, Ltd. 2022. All rights reserved. Contents 3 1. APIゲートウェイとして一定の地位を確立したNGINX 2. 高セキュリティAPIシステムでBFFが必要な理由 3. NGINXをBFFとして利用する
  • 5. 4 © Hitachi, Ltd. 2022. All rights reserved. APIシステム オーソドックスなAPIシステム 3. APIコール w/ アクセストークン 4. 認可済みのAPIコール 1. 認証・同意取得 2. トークンの発行 認可サーバー (Keycloakなど) • APIを公開するリソースサーバーはまず必要。 • 加えて、APIの用途に応じた何かしらの認証認可の仕組みが必須。  API認可の標準仕様であるOAuth 2.0の認可コードフローに準拠するのが一般的。  そのために認証認可を司る認可サーバーを配置。 • アクセス制御のために、手前にAPIゲートウェイを置く構成もよく見受けられる。 エンドユーザー 0. 使用 APIゲートウェイ リソースサーバー クライアント
  • 6. 5 © Hitachi, Ltd. 2022. All rights reserved. 参考: Keycloakとは • Keycloakは、Red Hat社を中心に開発されているOSSのIAM製品。 • シングルサインオンや、OAuth 2.0の認可サーバーの機能を提供。  OAuth 2.0/OpenID ConnectやSAMLに対応  LDAPサーバーやActive Directoryと連携可能  GitHubなどのユーザーアカウントを利用した ソーシャルログインにも対応 Keycloak 主要標準に対応したID連携 (OAuth 2.0の認可サーバーを含む) ソーシャルログイン (Identity Brokering) ID管理と認証 LDAP Active Directory RDB OpenID Connect SAML GitHub Twitter Facebook 主な特徴
  • 7. 6 © Hitachi, Ltd. 2022. All rights reserved. NGINX APIゲートウェイ 3. APIコール w/ アクセストークン 4. 認可済みのAPIコール 1. 認証・同意取得 2. トークンの発行 認可サーバー (Keycloakなど) • NGINXはAPIゲートウェイの実装の最有力候補の一つ。  圧倒的なパフォーマンス: APIゲートウェイは全APIコールを捌く必要があるため、とにかくパフォーマンスが重要。  高いカスタマイズ性: 豊富なモジュールのほか、JavaScriptやLua言語で自由にカスタマイズができる。 APIを呼ぶ側と呼ばれる側双方の業務要件をここで吸収するため、カスタマイズ性も非常に重要。 → 実際に、3scaleやKongといった著名なAPI管理製品は、APIゲートウェイのベースにNGINXを用いており、 それをLuaで拡張している。 エンドユーザー 0. 使用 APIゲートウェイ (NGINXなど) リソースサーバー クライアント NGINX + KeycloakのAPIシステム構成例は 以下の記事でも紹介しているので 是非ご参照ください。 「Keycloakで実現するAPIセキュリティ」 https://thinkit.co.jp/series/9721
  • 8. © Hitachi, Ltd. 2022. All rights reserved. Contents 7 1. APIゲートウェイとして一定の地位を確立したNGINX 2. 高セキュリティAPIシステムでBFFが必要な理由 3. NGINXをBFFとして利用する
  • 9. 8 © Hitachi, Ltd. 2022. All rights reserved. オーソドックスなAPIシステムがハマらないケース ~某案件で直面した課題~ 3. APIコール w/ アクセストークン 4. 認可済みのAPIコール 1. 認証・同意取得 2. トークンの発行 認可サーバー (Keycloakなど) エンドユーザー 0. 使用 APIゲートウェイ (NGINXなど) リソースサーバー SPA • 大体のケースにおいて、先に紹介したオーソドックスなAPIシステムで事足りるが、SPAのようなブラウザベースの アプリケーションをクライアントとして想定し、かつ高いセキュリティ保護が必要なAPIを公開する場合には注意要。  SPAでは、クライアントの認証情報やトークンなどの機密情報を安全に保管する術がない。 → 漏えい時の影響をできる限り軽減するように設計するか、アーキを変えるか、の2択。高いセキュリティ保護が 必要なAPIを公開する場合、漏えい時のリスクを抱えきれないので、後者を採るケースも多い。 → 実際、ブラウザベースのアプリケーションのセキュリティベストプラクティスは、グローバルでもまだ現在絶賛策定中。 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-09 金融取引や重要度の高い 情報を扱うAPIを公開
  • 10. 9 © Hitachi, Ltd. 2022. All rights reserved. BFFを採用したアーキテクチャへの変更 ~我々の解決策~ 3. APIコール w/ Cookie 4. 認可済みの APIコール 1. 認証・同意取得 2. トークンの発行 認可サーバー (Keycloakなど) エンドユーザー 0. 使用 APIゲートウェイ (NGINXなど) リソースサーバー SPA • このようなケースでBFF (Backend for Frontend)を採用する。  APIシステムから見ると、クライアントはBFF。クライアント含めたサービス全体で Webアプリケーション相当の高いセキュリティを担保できるようになる。  SPAとBFFの間は、一般的なクッキーとセッションを使ったいわゆるクライアントサーバーシステム。 BFF 3’. APIコール w/ アクセストークン
  • 11. © Hitachi, Ltd. 2022. All rights reserved. Contents 10 1. APIゲートウェイとして一定の地位を確立したNGINX 2. 高セキュリティAPIシステムでBFFが必要な理由 3. NGINXをBFFとして利用する
  • 12. 11 © Hitachi, Ltd. 2022. All rights reserved. NGINXをBFFとして利用する 3. APIコール w/ Cookie 4. 認可済みの APIコール 1. 認証・同意取得 2. トークンの発行 認可サーバー (Keycloakなど) エンドユーザー 0. 使用 APIゲートウェイ (NGINXなど) リソースサーバー SPA BFF (NGINXなど) 3’. APIコール w/ アクセストークン • BFFとしてもNGINXは優秀。  BFFもAPIゲートウェイと同様、全APIコールを捌く必要があるため、パフォーマンスが重要。  APIゲートウェイと比較して、よりクライアント側に寄り添った実装が必要になるため、 ここでも高いカスタマイズ性が重要。
  • 13. 12 © Hitachi, Ltd. 2022. All rights reserved. BFFとしてのNGINXの導入 • BFFが持つべき基本的な機能  OAuth 2.0のクライアント(OpenID Connect 1.0のRP)機能  このアーキでは、BFFがOAuth 2.0のクライアントとして振舞うので、トークンを要求するなどの機能が 必要。  セッション管理機能  トークンなどの機密情報をBFFで管理するために、セッション管理機能が必要。 3. APIコール w/ Cookie 4. 認可済みの APIコール 1. 認証・同意取得 2. トークンの発行 認可サーバー (Keycloakなど) エンドユーザー 0. 使用 APIゲートウェイ (NGINXなど) リソースサーバー SPA BFF (NGINXなど) 3’. APIコール w/ アクセストークン
  • 14. 13 © Hitachi, Ltd. 2022. All rights reserved. BFFとしてのNGINXの導入① ~ OAuth 2.0のクライアント機能 ~ • OAuth 2.0のクライアント(OpenID Connect 1.0のRP)機能を一から実装するのは大変なので、 既存のライブラリを参考にするのがおすすめ。  Lua拡張: lua-resty-openidc https://github.com/zmartzone/lua-resty-openidc  JavaScript拡張: nginx-openid-connect https://github.com/nginxinc/nginx-openid-connect → 商用版のNGINX Plusであれば、後者のJavaScript拡張を用いる方が圧倒的に楽。 OSS版のNGINXでも、後者を参考に実装することはできるが、後述するセッション管理が うまくいかないため、前者のLua拡張を選択。 → 両者とも、OpenID Connect 1.0のRP用のライブラリであるため、アクセストークンを付与してAPIを コールする部分は自前で拡張する必要がある。
  • 15. 14 © Hitachi, Ltd. 2022. All rights reserved. BFFとしてのNGINXの導入② ~ セッション管理機能 ~ • BFFが止まると、業務が停止する(APIコールができなくなる)ので、冗長化は必須。 • 加えて、片系停止時もセッションを維持するためには、セッションを共有する仕組みが必要。  この事例ではRedisを採用。lua-resty-openidcを採用した場合、Redisと相性が良い。 一方、JavaScript拡張を選択すると、JavaScriptは元々フロントエンド用の言語であるため、 このDB接続の部分に苦労する。  ちなみに、NGINX Plusであれば、ngx_http_keyval_moduleというモジュールを使うことで、 Redisのような他コンポーネントの導入なしにセッション共有を実現できる。 BFF (NGINX) BFF (NGINX) LB Redisなど
  • 16. 15 © Hitachi, Ltd. 2022. All rights reserved. BFFを実現するにあたっての注意点① ~ CSRF対策 ~ • クッキーとセッションを用いる以上、一般的なCSRF (Cross-Site Request Forgery)対策は必須。 • CSRF対策をしないと、BFFで正規のAPIコールかどうかを見分けることができず、APIの不正利用が可能に。  対策例: SPAからのAPIコールを見分けるために、毎回ランダムな文字列をページに設定し、 APIコール時にBFF側で照合する、など。 APIコール w/ Cookie APIゲートウェイ (NGINXなど) SPA BFF (NGINXなど) APIコール w/ アクセストークン エンドユーザー 攻撃者 攻撃者の口座に 送金するAPIのリンク ブラウザ APIコール w/ Cookie リンクをクリックすると ブラウザ起動
  • 17. 16 © Hitachi, Ltd. 2022. All rights reserved. BFFを実現するにあたっての注意点② ~ セッション共有 ~ • Lua拡張であるlua-resty-openidcを使って、複数インスタンス間でセッションを共有するときの注意点。 • lua-resty-openidcはセッション管理にlua-resty-sessionというライブラリを使用。  $session_secretという変数をセッションの識別子として利用。デフォルトだと$session_secretに ランダム値が設定される。  クラスタ内全インスタンスの$session_secretに同じ値を設定しないとセッションが共有されないので 注意が必要。 BFF (NGINX) BFF (NGINX) LB Redisなど
  • 18. 17 © Hitachi, Ltd. 2022. All rights reserved. まとめ - 以下を中心に、NGINXをBFFとして利用する事例をご紹介しました。  NGINXがAPIゲートウェイの最有力候補の一つであること。  クライアントがSPAの場合にBFFアーキテクチャがハマること。  NGINXを利用してBFFアーキテクチャを実現するときの概要と注意点。
  • 19. 18 © Hitachi, Ltd. 2022. All rights reserved. 日立のサービス紹介: 強固なセキュリティを確保したAPI管理基盤の構築 todo: 説明文を入れる お客さまシステムの要件に最適な「API管理基盤」を構築します。 スモールスタート向け構成からマイクロサービス向け構成まで幅広く対応し それらに合ったAPIセキュリティを実現します。 ソ リュー ション APIゲートウェイ (NGINX / NGINX Plus) 認可サーバー (Keycloak) 認可 API管理基盤 流量制御 アクセス制御 DBサーバー ユーザー管理 ID管理 Active Directory, LDAPサーバー、 既存ユーザー管理 DBなどとの連携 外部ユーザー Google, GitHub とのSNS連携や、 Oktaなどの外部ID 管理製品との連携 バックエンド APIサーバー APIサーバー APIサーバー フロントエンド Webアプリ モバイルアプリ 外部サービス 特徴1 スモールスタート向けからマイクロ サービス向けまで、お客さまのシス テムに最適なAPI管理の実現が可能 特徴2 OSSを活用し、 最新のAPIセキュリティの実現が可能 特徴3 APIセキュリティやOSSの専門家とし て の高度な知見を活かし、導入から運 用までトータルにカバー
  • 20. 19 © Hitachi, Ltd. 2022. All rights reserved. 日立の強みを生かしたサービスの提供 F5社 技術・ノウハウ OSSサービス フィードバック 連携 日立はさまざまな分野におけるOSSのお客さまビジネスでの活用を コミュニティ貢献で培った高い技術力とF5社との連携で、サービスを提供します。 お客さまビジネスでの活用 OSSを活用したシステム開発・構築 API管理ソリューション提供 OSS単独ではなく、システム要件に合わせたソフト ウェアの組み合わせや処理フローの支援などにより、 日立のSI事業を強力に支援します コミュニティ貢献 有用なOSSの目利き OSSの発展への寄与、技術蓄積 お客さま案件のニーズをコミュニティにフィードバック、 国内外での講演活動や寄稿活動による発信、 技術者交流を積極的に行い、さまざまな用途に 柔軟に対応できるOSSに成長させます OSSサービス提供 OSSを安心して使うための サポートサービスの提供 コミュニティ活動で製品内部を知る、高度な技術者 が、知見をもとにした製品内部(ソースレベル)での 調査により、迅速な障害解決に導きます
  • 21. 20 © Hitachi, Ltd. 2022. All rights reserved. 日立はOSSコミュニティリーダーを擁する専門チームを保有し、金融(銀行、保険など)や公共、社会、産業など さまざまな分野の案件を多数支援しています。 社外でも認証認可の専門家として認知されており、お客さまのご指名で案件対応した実績もあります。 多くの導入実績 CIO補佐官向けに監査説明ができるセキュリ ティ専門家として要望を受け対応。 認証認可のフロー設計やAPI管理基盤構築の 支援を実施。 お客さまへOAuthやAPI管理の説明ができる セキュリティ専門家としての要望を受け対応。 APIゲートウェイや認証認可サーバーの構築支 援を実施。 セミナーの日立講演をきっかけに日立の セキュリティ技術力の高さを評価いただき、 日立をご指名頂いた。 日立の社外著作物で日立のセキュリティ技 術の高さを認知。 お客さまのご指名で案件を対応。 専門家としての技術力を評価さ れ 対応した案件の一例 [金融] 某金融機関様 デジタル決済プラットフォーム [公共] 某省庁様 国民向け申請システム [金融] 某金融機関様 API管理基盤構築 [金融] 某金融機関様 認証認可システムのトラブル対応 お客さまのご指名で対応した 対応した案件の一例
  • 22. 21 © Hitachi, Ltd. 2022. All rights reserved. Trademarks • OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other countries. • GitHub is a trademark or registered trademark of GitHub, Inc. in the United States and other countries. • Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries. • NGINX is a registered trademark of F5 Networks, Inc. in the United States and other countries. • Other brand names and product names used in this material are trademarks, registered trademarks, or trade names of their respective holders.