Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
CDN Edge Computing上で動くOIDC認証Proxyのススメ
Search
Atsushi Harada
September 19, 2025
1
1.1k
CDN Edge Computing上で動くOIDC認証Proxyのススメ
2025/9/20 ServerlessDays Tokyo 2025資料 @meteor0090
Atsushi Harada
September 19, 2025
Tweet
Share
More Decks by Atsushi Harada
See All by Atsushi Harada
ビジネスアジリティを高める内製化戦略
haradaa9
0
71
LIXILの静的コンテンツ配信について
haradaa9
0
1.5k
Featured
See All Featured
Six Lessons from altMBA
skipperchong
28
4k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Building an army of robots
kneath
306
46k
KATA
mclloyd
32
14k
Visualization
eitanlees
148
16k
Faster Mobile Websites
deanohume
310
31k
Typedesign – Prime Four
hannesfritz
42
2.8k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
It's Worth the Effort
3n
187
28k
Transcript
Copyright © LIXIL Corporation. All rights reserved. CDN Edge Computing上で動くOIDC
認証 Proxy のススメ 株式会社LIXIL CX Digital デジタルインフラエキスパート 原田 篤(@meteor0090 / たこちー) OIDC RelyingPartyの組み込み課題の解決 2025/9/20 ServerlessDays Tokyo 2025
2 株式会社LIXIL CX Digital デジタルインフラエキスパート 原田 篤(@meteor0090 / たこちー) 顧客認証基盤や見積システムを始め、
様々なサービスに関わるWebエンジニア兼プロダクトオーナー。 開発以外にも、デジタル部門の組織戦略や採用、人材育成など幅広く携わる。 3児の父。 自己紹介
3 • 話すこと ◦ OIDCのRelying Party側の話 ◦ CDN上で稼働する認証Proxyの話 • 話さないこと
◦ OIDCのOpenID Provider側の話 この発表で話すこと・話さないこと
4 アジェンダ • LIXILの紹介 • OIDC RelyingParty実装における困りごと • ケース別の考慮 ◦
スクラッチでOIDCを組み込むケース ◦ ミドルウェアを使ってOIDCを組み込むケース • CDN EdgeComputing上の認証Proxyを使った課題解決 • まとめ
LIXILの紹介
6 LIXILの企業理念 LIXILの Purpose(存在意義)は持続的な成長に向けて、よりアジャイルで起業家精神にあふれた企業になるための 取り組みを続け、意思決定を行う際に指針となるものです。LIXILの従業員は、目的意識を持ち、日々の業務で LIXIL Behaviors(3つの行動)を実践することで、Purposeの実現と社会・環境へのインパクトの創出に取り組んでいます。 (存在意義) (3つの行動)
7 LIXILについて LIXILは、日本のものづくりの伝統を礎に、世界をリードする技術やイノベーションで、日々の暮らしの課題 を解決する高品質な製品をグローバルに提供しています。 従業員数 約53,000人 10億人以上の 生活を支える 世界 150ヵ国以上で
事業を展開 100年以上の ブランドの歴史 ※2025年3月現在
8 様々な技術スタック、製品を扱っている ・Vue.js, Nuxt ・React.js, Next.js ・Swift ・Dart, Flutter ・Node.js,
Express, Fastify ・Python, Bottle, Flask ・Go, Gin ・PHP, Laravel ・C#, .NET ・Java ・COBOL ・Terraform, Serverless Framework
9 過去の経緯で認証基盤がいっぱいある 社内向け 社外向け icewall Akamai EAA My LIXIL OIDC
Proxy Proxy SAML OIDC SAML OIDC WS Fed 古い 新しい
こんな困りごとないですか?
新しくサービス作るんだけど認証どうすればいい? 新しいサービスの認証 どうすればいい? 認証基盤使ってね! OIDC使ってね! アプリチーム 認証基盤チーム
12 サービスへの OpenID Connectの組み込みどうやればいい? スクラッチ? ミドルウェア使う? ケースバイケースだよ! アプリチーム 認証基盤チーム
スクラッチで OIDCを組み込むケース
14 ・呼び出し元 (OIDC Relying Party)の基本的な実装 ・セキュアに組み込めているかのチェック ・ライブラリ等の継続的なアップデート いろいろやる必要がある
15 そういうサービスが 100個以上あったら? 運用を考えるとできればスクラッチは避けたい
ミドルウェアを使って OIDCを組み込む ケース
17 こちらも方法はいろいろある
18 AWS Application LoadBalancerのOIDC認証機能を使うケース 出典: https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/ application/listener-authenticate-users.html 1. ユーザーがALBにアクセス 2.
ALBが必要に応じてOPに Authorized Redirect 3. ユーザーがOP画面で認証 4. AuthZ CodeをALB callbackに返却 5. ALBがToken取得と検証 6. OKならTargetへ転送
19 Google Cloud Identity-Aware ProxyとIdentity Platformを使うケース 1. ユーザーがURLにアクセス 2. IAPが必要に応じて
Identity PlatformにRedirect 3. Identity Platformが OpenID ProviderにAuthorized Redirect 4. ユーザーがOP画面で認証 5. AuthZ CodeをIdentity Platform callbackに返却 6. Identity PlatformがToken取得と検証 7. Identity PlatformからIAPに情報受け渡し 8. OKならTargetへ転送
20 Nginx Plusを使う場合 出典: https://docs.nginx.com/nginx/admin-guide/security-contro ls/configuring-oidc/ 使用したことないので 細かいところは割愛
21 ・ALBやIAPの場合、オンプレ Targetに転送する際に考慮が必要 LIXILはAWS、Google Cloud、Azure、OnpremiseにTargetがあるため、特定の Cloud技術に依存しにくい ・IAPの場合、 IssuerとOPのURLが異なる場合に設定ができない ・IAPの場合、 OP側でユーザーのメールアドレスが変更されたときの挙動が不安定
・IAPの場合、 Identity Platformの中間ページの呼び出しに時間がかかるケースがあり UXがいまいち ・IAPの場合、 Third Party Cookieの使用が必要で、ブラウザ側の設定によっては動作しない ・ALBの場合、 LB単位で最低限のコストがかかる (3000円/LBぐらい) ・Nginx Pro等のミドルウェアを使用する場合、ミドルウェア自体のインフラ管理が必要 ・Nginx Pro等のミドルウェアを使用する場合、それ自体のライセンスコスト等がかかる ミドルウェアを使用する場合もいくつか考慮事項がある
なんかもうちょっと良い方法ない?
23 Lambda@Edge上でOpenID Connectの Relying Party機能を実装している例がある。 仕組みとしては認証 ProxyをCDNに近い Functionsに設置したイメージ。 ・CDNはOriginがどこにあっても使用するから 環境依存が少ない
・Lambda@Edge等のCDN Edge Computing型の仕組みは、 ピュアサーバーレスでメンテナンスフリー ・もともと CDNで使うことを想定しているので動作が早い これはいけるのでは? 調べてみる 出典: https://qiita.com/yh1224/items/2cc440f6fe0fef1502b7 https://zenn.dev/yh1224/articles/f473a9325a48404bd
24 ・全ての ApplicationTrafficに対して Proxyとして高速に動作する必要がある (数msレベル) ・ColdStartとリソースレベルの調整対応が必要 ・高いSLAが求められる 普通のLambdaやCloud Functionsで動作させることも考えてみる 不可能ではないが、良くもなさそう
CDN認証Proxy実装の話
26 LIXILではAkamai CDNを全面的に採用しているので、 Akamai CDNに付随する Akamai EdgeWorkersをCDN Edge Computingとして使用 Akamai
EdgeWorkersのアーキテクチャ Akamai CDN Client Edge Workers Origin Server CDN を通る時に JavaScript が動作
27 HTTP Requestにおける 4フェイズに対して、それぞれ Javascriptを使った挙動の定義が可能 Akamai EdgeWorkersのCDN Edge Cpmputingの特徴 出典:
https://techdocs.akamai.com/ edgeworkers/docs/event-han dler-functions
28 CDN認証Proxyの概要 認証付き ALB・IAP と (ほぼ) 同様の挙動をとる Client Edge Workers
Edge Workers Service 認証情報がない 場合、 ログイン画面にリダイレクト ある場合はスキップ 認証結果の処理 ユーザー情報をヘッダに 書き込む Ex)My LIXILを利用するサービスにアクセスする場合
29 ・ProxyとOIDC RelyingPartyを担当する Coreに機能を分離 ・Proxyの機能 ・Sessionハンドリングと Token Verification ・Token Refresh
・OriginRequestに対する認証結果 Header情報の付与 ・Coreの機能 ・OIDC Authorizeハンドリング ・OIDC Callbackハンドリング ・OIDC Logoutハンドリング CDN認証Proxyの設計内容
30 各種シーケンス 主に4つのステップに分けられている 1. セッションハンドリング 2. 認可リクエスト 3. トークン交換 4.
保護されたリソースへのアクセス
31 各種シーケンス (セッションチェック )
32 各種シーケンス (認可リクエスト )
33 各種シーケンス (トークン交換リクエスト )
34 各種シーケンス (保護されたリソースへの転送 )
35 当日はデモがあります。 実際に動作する様子
36 ・CDN Edge Computing系の仕組みは、元の HTTP Requestに対する Timeoutが厳しいため、内部で呼び出す APIは高速なレスポンスが求められる ・セッションに関する情報保持の話 CDN認証Proxyの実装上考慮する必要があったこと
37 ・認証Proxyを扱う上で幾つかの情報を扱う必要があり、高速な Read, Writeが頻繁に発生する ・Authorize時: PKCE, state, nonce ・認証後 :
各種tokenや期限など ・Strong Consistencyが求められるユースケースでどこに格納するべきか? セッションに関する情報保持の話
38 Strong Consistencyが満たせる可能性がある レイテンシーが犠牲になる可能性が高い CDNベンダーは RDBMSタイプのネイティブなデータベースをあまり提供してない Cloudfrare
D1はSQLiteによるデータベースエンジンで例外的。 (ただリードレプリカを使用した場合は Strong Consistencyをサポートしない? ) 出典: https://news.ycombinator.com/item?id=31340942 RDBMSを使用した場合
39 CDNベンダーは NoSQL型のデータベースエンジンを提供していることが多い Cloudflare KV, EdgeKV etc… (ただ、Strong Consistencyはサポートされてない・・・
) DynamoDB等の強整合性オプションを使用する手もあるが、レイテンシーが許容できるかが問題 NoSQLを使用した場合
40 Strong Consistencyとスケーラビリティを両立できる。レイテンシーもそこそこ。 (TiDBとか・・・。 ) ? インフラ等の運用コストが現実的に許容できるかという課題がある。 月間1億Request *
(読み出し &書き込みユースケース ) NewSQLを使用した場合 良さそうだけどまだトライできてない
41 Request毎に最新のものが得られるのでレイテンシーと整合性の担保が容易 Cookieの横取り対策が必須 (このケースに限った話ではないが・・・ ) ブラウザ側の制約として Cookie毎のSizeには4KBの制限がある
出典: https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/Cookies#%E3%83%87%E3%83%BC%E3%82%BF%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8 HTTP Header Sizeにはホスティング環境により Size制限がある Cookieに格納する場合 現状はCookieに格納し、必要な情報だけを Clientに返却している
現在のCDN認証Proxy利用実態
43 ・サービス数 2年ぐらいで 60程度のサービスが活用中。今後 200程度まで増える予定。 ・CDN認証Proxyで処理している月間 Request数 ・CDN認証Proxy自体の平均レイテンシー ・EdgeWorkersのコスト 年間10万程度
+ CDNのTraffic運用コスト ・EdgeWorkersのコスト 年間10万程度 + CDNのTraffic運用コスト CDN認証Proxy運用実績
44 ・Multi CloudかつOnpremise併用環境に対する認証ミドルウェア課題のアプローチとして、 CDN上で稼働する OIDC 認証Proxyを実装し運用 ・OIDC認証ProxyのComputing環境として CDN Edge Cpmputingを活用することで、
Serverlessかつ高速なインフラ運用が可能 ・Javascriptベースの仕組みとして OIDC認証Proxyを実装することで、各社の CDN Edge Computing上でも動作可能なポータビリティの高い仕組みとして設計が可能 ・CDN Edge ServerlessはQuotaやProduct Limitationとうまく付き合っていく必要があるが、 使いこなせると強力なソリューション ぜひCDN Edge Serverlessのユースケースをもっと広げていきましょう!! まとめ
45 ①LIXIL IT・Digitalの求人一覧 https://hrmos.co/pages/lixil/jobs?category=1807273222947917832 募集中のポジションがあります。 ②LIXIL採用情報ページ https://www.lixil.co.jp/corporate/recruit/career/ →社員インタビューやニュース、 LIXILの働き方などがまとまっております。 余談:
LIXILの採用関連ページの紹介
None