ACESにおけるAuth0導入と共通認証基盤の構築

Transcript

1. 1 ACESにおけるAuth0導入と共通認証 基盤の構築 2 0 2 5 / 1 1 / 1 4
2. 2 目 次 01 02 03 04 05 自己紹介・会社紹介 Auth0導入の背景・設計方針 実装・運用の工夫 Auth0の導入効果 まとめ
3. 3 自己紹介・会社紹介
4. 4 自己紹介 三田村 健 Ke n Mitam u ra 共同創業者/ソフトウェアエンジニア 株式会社ACES 「アルゴリズムを用いて事業開発を行う A I事業会社」 略歴 • 2 01 7年:東京大学工学部卒業 • 2 01 7年〜:株式会社A CES共同創業・現職
5. 5 A b o ut A C ES 会社情報 自在に組み合わせられるA Iモジュール群を活用し、自社の強みを学習・強化するエキスパート A I を開発。東京大学松尾研究室発A Iベンチャーの中でも、豊富な実績と先進性で社会実装を牽引 会 社 名 株 式 会 社 A C E S 経 営 陣 取 引 実 績 （ 一 部 ） 受 賞 歴 （ 一 部 ） 田 村 浩 一 郎 代 表 取 締 役 ・ C o - F o u n d e r 株 式 会 社 三 井 住 友 銀 行 、 S O M P O ホ ー ル デ ィ ン グ ス 株 式 会 社 、 株 式 会 社 電 通 、 株 式 会 社 テ レ ビ 朝 日 、 バ ン ダ イ ナ ム コ ホ ー ル デ ィ ン グ ス 株 式 会 社 、 株 式 会 社 日 本 政 策 投 資 銀 行 、 大 同 生 命 保 険 株 式 会 社 、 経 済 産 業 省 、 陸 上 自 衛 隊 、 そ の 他 多 数 東 京 大 学 大 学 院 工 学 系 研 究 科 卒 （ 工 学 博 士 ） 。 松 尾 研 究 室 で 金 融 工 学 に お け る 深 層 学 習 の 研 究 に 従 事 。 F o r b e s 3 0 U n d e r 3 0 A s i a 2 0 2 2 E n t e r p r i s e T e c h n o l o g y 部 門 に 選 出 。 H O N G O A I A W A R D 東 洋 経 済 新 報 社 「 す ご い ベ ン チ ャ ー 1 0 0 」 F o r b e s 3 0 U n d e r 3 0 A s i a 2 0 2 2 E n t e r p r i s e T e c h n o l o g y 部 門 松 尾 豊 技 術 顧 問 東 京 大 学 大 学 院 工 学 系 研 究 科 人 工 物 工 学 研 究 セ ン タ ー / 技 術 経 営 戦 略 学 専 攻 教 授 他 従 業 員 1 1 0 名 （ 業 務 委 託 ・ イ ン タ ー ン を 含 む ） 事 業 内 容 A I モ ジ ュ ー ル 群 を 用 い た ① D X パ ー ト ナ ー 事 業 ② A I ソ フ ト ウ ェ ア 事 業 設 立 2 0 1 7 年 1 1 月 2 0 日 資 本 金 1 億 円
6. 6 ア ル ゴ リ ズ ム で 、 社 会 は も っ と シ ン プ ル に な る V I S I O N M I S S I O N ア ル ゴ リ ズ ム で 、 人 の 働 き 方 に 余 白 を 作 る
7. 7 1 . 会 社 概 要 ビジネスモデル 自在に組み合わせられる A Iモジュール群を活用し、自社の強みを学習・強化するエキスパート A Iを開発。 ①D Xパートナー事業と②A Iソフトウェア事業を通して価値提供 業界横断の業務課題を プロダクトを提供することで解決 企業内の知見やノウハウを、データとして 蓄積・共有・活用できるようにするAI SaaSの提供 AIライセンス契約 特定の業界・顧客の経営課題を お客様とプロジェクトを伴走して解決 内 容 データ・AI統合基盤を提供しながら、アジャイルで プロセスの設計・開発・運用まで一貫して支援 契 約 プロジェクト実行契約＋AIライセンス契約 AIモジュール群 事業② AIソフトウェア プロダクトを活用し プロジェクトを推進 プロジェクトで得た 課題をプロダクト化 事業① DXパートナー 内 容 契 約 顧客や事業に合わせて、 ソフトウェアモジュールを 組み合わせる 組み合わせ
8. 8 D X パ ー ト ナ ー サ ー ビ ス コ ン サ ル か ら 開 発 ・ 実 装 、 デ ジ タ ル 事 業 の 推 進 ま で 一 気 通 貫 で 顧 客 の D X を プ ロ ジ ェ ク ト 型 で 並 走 し 、 業 務 生 産 性 の 向 上 や 改 革 を 実 現 。 トータル 約1年6ヶ月〜 約3~6ヶ月 約3~6ヶ月 約6ヶ月~ コンサルティング AIデザイン・ロードマップ策定 AI戦略策定・業務プロセス設計 開発・実装 PoC・技術検証 オーダーメイドAI開発 実行・運用 業務提携・デジタル事業推進 一気通貫の伴走型DX推進により、87%のプロジェクトが初回PoCから前進/AI導入へ*2
9. 9 1 . 会 社 概 要 様々な業界のPJで結果を出してきている豊富な実績 大手企業や中央官公庁との取引実績多数。実績経験に基づくソリューションやプロダクトを提供し、 D X PJの 8 7%がPo Cで終わらず、着実に D Xを進める「社会実装力」に強み 大手企業や中央官公庁との取引実績多数 PoCで終わらせない着実な社会実装 陸 上 自 衛 隊 の 組 織 に お け る AI 活 用 を 支 援 陸上自衛隊の組織におけるAI活用を支援 ACESと経済産業省が行政におけ る大規模言語モデル活用に向けた 協同プロジェクトを実施 43% 87% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 一般的なAI/DX PJ ACESのAI/DX PJ PJ開始後、実装に至る割合 約2倍 ACES Meet 豊富な実践経験に基づく ソリューションやプロダクト 実績のあるソリューション
10. 10 P ROD UC T O VE RVI EW プ ロ ダ ク ト ー A C E S M e e t 1つ1つのミーティングの生産性と資産性を最大化する A I-N ati veなプロダクト 成約率向上 人材育成効率化 業務負荷削減 (データ入力自動化など) ・・・ 社内MTG オンライン商談 電話 すべてのコミュニケーションをデータ化し、 AI で自動記録・解析 ・・・
11. 11 成 長 率 プ ロ ダ ク ト ー A C E S M e e t 2 0 2 2 年 の リ リ ー ス か ら 3 年 、 A R R は Y o Y で 2 . 5 倍 と 順 調 に 成 長 中 か つ 、 資 金 調 達 は せ ず 自 社 資 金 で 安 定 性 の 高 い 成 長 を 実 現 D X 事 業 の 高 い 利 益 率 を も と に 創 業 か ら ほ ぼ 黒 字 経 営 加 え て 、 A C E S M e e t は 自 社 利 益 か ら 投 資 す る こ と で 外 部 資 金 調 達 0 で の 成 長 を 実 現 FY2022 FY2023 FY2024 FY2025 約 2.5 倍 ARR 年間経常収益 *FY2023〜FY2024 約 2.2 倍 導入企業数 *FY2023〜FY2024
12. 12 Auth0導入の背景・設計方針
13. 13 認証基盤導入の背景 背景 • ACESでは、社外向けのSaaSや自社AIプロダクトが増加 • サービスごとに異なる認証が存在し、ユーザー体験や運用コストが課題に • 今後のAI活用を見据え、アイデンティティ管理の重要性が高まる • 人やシステムだけでなく、AIエージェントも含めた認証が求められる時代に • まずは、複数の自社サービスを横断して扱える共通認証基盤の整備から着手 • 外部ユーザーに対して、統一されたアイデンティティ管理を実現することを目指した
14. 14 認証基盤導入の背景 課題 • ①各サービスが個別認証を持ち、開発・運用コストが増化 • ②BtoB SaaSとして顧客企業からのSSO要望への対応が必要 • ③独自の認証機能から標準的な仕組みへ移行したい ACES Meet 認証 サービス A 認証 サービス B 認証 ACES Meet サービス A 認証 サービス B Before After IdP ②SSO対応 ①③標準的な全社 横断の認証基盤
15. 15 Auth0導入の決定 採用理由 • 機能が豊富・知名度が高い • 公式ドキュメントが充実しており、情報が得られやすい • OIDC（OpenID Connect）準拠 • 標準的な認証・認可の仕様に従っているため、技術的に理解しやすい • 外部IdP（Identity Provider）とのSSO（Single Sign On）をサポート • Microsoft Entra IDを始め、主要なIdPとの接続をサポートしており、設定が容易 • IaC（Infrastructure as Code）対応 • 設定をソースコードで管理することができ、属人性を排除して管理できる 懸念点 • 料金が他のIDaaSと比較して高い • → 認証基盤の重要性と得られる効果を社内で説明し、承認を得る
16. 16 Auth0導入のアーキテクチャ設計 設計思想 1. セキュリティ第一 • 認証はサービス提供における最重要の構成要素である • セキュリティのベストプラクティスに従い、脆弱性のある利用方法をなくす 2. 標準的な仕様にする • ACES独自仕様をなるべく避け、ステークホルダーが理解しやすい状態にする • 特に通信プロトコルや認証フローを標準的なものにし、今後の拡張性を担保する 3. Auth0の設計思想に従う • Auth0の設計思想に沿った利用方法を行う • サポートを得られやすい状態を保ち、機能アップデートの恩恵を受けやすくする
17. 17 Auth0導入のアーキテクチャ設計 設計方針 • Auth0と各サービスはOIDC接続を行う • 各サービスは共通の認証情報でログイン • ユニバーサルログインを利用する • フロントSPA+サーバーAPI構成に最適化 • Enterprise Connectionを利用する • Social Connectionを利用しない • e.t.c… → ※Auth0は柔軟かつ強力なSaaSだが、 自社の状況に合わせた設計が重要！ （特にAuthorization Code Flowなど、OAuth2.0や OIDCの概念を正しく把握しておくことで、 効果的かつセキュアな運用が可能になる）
18. 18 アーキテクチャ図 外部サービス（IdP） Auth0 ACES Meet 他サービス ログイン ログイン ログイン（SSO） OIDC OIDC ユーザー OIDCで接続することで 標準的な仕様で自社 サービスと連携可能 ユニバーサルログイン を利用し、同一の認証 情報で複数サービスの ログイン状態を管理 Auth0が各種IdP （Identity Provider） との接続をサポート Auth0の設定情報は Terraformを使ってIaC （ Infrastructure as Code ）管理
19. 19 実装・運用の工夫
20. 20 実装・運用の工夫 事例紹介 • 設計を現場に落とし込む中で見えた課題と解決策を紹介 ①認証方式の選択と移行 ②ユーザーアカウントのリンク ③ユーザーデータの移行 ④SSOの提供 フロントエンド バックエンド ID/PWログイン SSOログイン 同一ユーザー の統合 現サービス Auth0 外部IdP ログイン
21. 21 実装・運用の工夫 ①認証方式の選択と移行 • フロントエンドSPA+バックエンドAPI構成のWebサービス • 現行のサービスは1.に近い方式で運用しており、認証方式を比較検討 • 最終的に2.の方式を選択し、移行作業を実施 Auth0 フロントエンド バックエンド ①認証 ②コード ③IDトークン・ アクセストークン ④独自 セッションキー 1. OIDC+独自セッション管理 Auth0 フロントエンド バックエンド ①認証 ④アクセストークン 2. フロントでログイン管理 ③IDトークン・ アクセストークン ②コード フロントエンド バックエンド
22. 22 実装・運用の工夫 1. OIDC+独自セッション 2. フロントでログイン管理 認証フロー Authorization Code Flow Authorization Code Flow with PKCE OIDCにおけるOP（OpenID Provider） Auth0 Auth0 OIDCにおけるRP（Relying Party） フロントエンド+バックエンド フロントエンド OIDCにおけるRS（Resource Server ） なし バックエンド トークンの発行場所 バックエンド フロントエンド 使用トークン IDトークン・アクセストークン IDトークン・アクセストークン・リフレッシュトークン トークンの保持場所 なし（独自セッションはCookie） ブラウザのin-Memory（またはLocal Storageなど） フロント・バック間の認証情報 独自セッション用のキー（Cookie） アクセストークン（Authorization ヘッダー） ポイント フロントエンド+バックエンドをまとめてRelying Party（ OIDCクライアント）とみなし、バックエンド-フロントエン ド間で認可の機能（アクセストークン）は使わない ①サイレント認証を使ってブラウザの裏側でトークンを更新 ②Auth0のライブラリではトークンをJSのin-Memoryに保管で きる メリット ログイン管理にJWTのアクセストークンを利用しないのでセッ ションの更新・破棄をバックエンド側でコントロールできる ①Auth0のSDKを使って認証処理をセキュアに完結できる ②アクセストークンを使って認可をしたいときに対応しやすい 制約 Cookieを使うためにはバックエンド・フロントエンド間の同 一ドメインが必要 OPとフロントエンドのドメインが異なるとサイレント認証が動 作しないケースあり ①認証方式の選択と移行 • フロントエンドSPA+バックエンドAPI構成のWebサービス • 現行のサービスは1.に近い方式で運用しており、認証方式を比較検討 • 最終的に2.の方式を選択し、移行作業を実施 フロントエンド バックエンド
23. 23 実装・運用の工夫 ②ユーザーアカウントのリンク • Auth0は認証方式（ID/パスワードや、SSOなど）ごとに別ユーザーになる • ユーザーが複数の認証方式を行った際に統合できる仕組みがある • APIはあるがUIが提供されていない（古い）ため、独自実装した ID/PWログイン SSOログイン 同一ユーザー の統合
24. 24 実装・運用の工夫 ③ユーザーデータの移行 • システム移行時のユーザーの作業をなるべく減らしたい • Auth0は既存のユーザーデータを取り込む機能がある • 一括インポートを行い、既存ユーザーはパスワード変更なしで移行できた 比較項目 自動移行 (Automatic / Lazy Migration) 一括インポート (Bulk User Imports) 概要 ユーザーが初回ログイン時に旧DBからAuth0へ自 動移行 既存ユーザーをJSON形式で事前にAuth0へ一括登録 主な利用機能 Custom Database Connection（スクリプト実 装） Management API /post_users_imports または Import/Export Extension 移行タイミング 各ユーザーの初回ログイン時 移行実行時に全ユーザーを一括で登録 旧DBアクセス 必要（ログイン時に旧DB参照） 不要（事前移行済み） パスワード移行 ハッシュを利用し認証後にAuth0へ再保存（リ セット不要） 対応ハッシュ形式のみ移行可能。非対応ならリセット 要 UX影響 シームレス（パスワード変更不要） 一部ユーザーにパスワードリセットが必要な場合あり 実装難易度 中程度（スクリプト実装必要） 比較的簡単（データ準備とAPI呼び出し） 向いているケース ダウンタイムを避けたい、段階的移行したい 一度に全ユーザーを移行したい、旧DBを早期廃止し たい 現サービス Auth0
25. 25 実装・運用の工夫 ④SSOの提供 • 通常ログインとSSOログインの両立方法を検討 • メールアドレスのドメインでSSO適用かどうかを自動判定する機能を活用 • 統一したUIで扱えるようにした ID/PWログイン SSOログイン メールアドレス入力 外部IdP ログイン ドメインで判定
26. 26 Auth0の導入効果
27. 27 Auth0の導入効果 開発面 • 認証機能の開発工数が削減 • 外部API公開機能の開発時に、第三者用の認証アプリケーションを活用 • スマートフォンアプリ開発を行った際、追加の認証機能開発が不要に ビジネス面 • SSO対応による顧客要望への即応 • SSOの要望は多く、多様なIdPへの接続をすぐに対応できるように • エンタープライズ案件対応の促進 • エンタープライズの認証要件を満たしやすくなった セキュリティ運用 • 不正アクセス検知・自動ブロック • ログインログの保管・取得 • ISO27017（クラウドセキュリティ認証）取得のためのログインログ機能開発が最小限に
28. 28 今後の展望 エンタープライズ要件の拡張 • SCIM対応 • ユーザーの属性（グループなど）の自動反映 OpenFGA（Auth0 FGA）の導入 • 柔軟な関係ベース認可を検証中 AIエージェント認証・認可への展開 • Non-human identity（AI Agent）対応 • Identity Security Fabricへの接続
29. 29 まとめ
30. 30 まとめ Auth0導入を通じて得られた3つの成果 • 共通認証基盤の確立により、複数サービスの開発効率を大幅に改善 • SSO・セキュリティ対応を統合し、顧客要求と品質向上を両立 • 標準仕様・設計思想の徹底により、将来拡張性の高い基盤を構築 ポイント • 自社の状況に合わせて適切な設計を行うことでAuth0を最大限活用 • Auth0の仕組みを理解することでシンプルな設計が可能に
31. 31 ご清聴ありがとうございました！