Sansanでの認証基盤内製化と移行

■ イベント
各社の事例に学ぶ！共通ID基盤 Lunch Talk
https://findy.connpass.com/event/383570/

■ 発表者
技術本部 Platform Engineering Unit
樋口 礼人

■ 技術本部 採用情報
https://media.sansan-engineering.com

Transcript

1. Sansanでの認証基盤内製化と移⾏ 各社の事例に学ぶ！共通ID基盤 Lunch Talk Sansan技術本部 Platform Engineering Unit 樋⼝ 礼⼈
2. Sansanのソフトウェアエンジニア - 2022年5⽉ 中途⼊社しContract Oneの開発を担当 - 2023年9⽉ Bill Oneへ異動し認証基盤の内製化に携わる - 2025年6⽉ チームごとPlatform EUへ異動 趣味：ポッドキャストを聞くこと 寄稿：Software Design 2025年12⽉号 「今さら聞けないID管理」 第4章 樋⼝ 礼⼈（Ayato Higuchi） Sansan株式会社 技術本部 Platform Engineering Unit / Identity Platformグループ
3. 1. Sansan / Bill Oneにおける認証基盤の課題 2. 認証基盤の技術選定・設計と移⾏について 3. 認証基盤内製化の振り返り Agenda
4. Sansan / Bill Oneにおける 認証基盤の課題
5. Sansan株式会社の働き⽅を変えるAXサービス ⽣産性を向上させ、企業のAI活⽤を最⼤化するデータベースとしても貢献できる 「働き⽅を変えるAXサービス」を提供します。 データクオリティマネジメント 請求 名刺 管理 営業 契約 名刺管理から、収益を最⼤化する AI契約データベースが、利益を守る 「なくせる」をつくり、全社の働き⽅を変える 名刺アプリ 経理AXサービス 取引管理サービス ビジネスデータベース 各サービスの活⽤で変わる働き⽅ 情報を分析・活⽤しやすく データに基づいた判断ができる 情報の管理がしやすく すぐに共有できる 必要な情報を すぐに⾒つけられる 個⼈向け 法⼈向け
6. 従来の認証基盤 Auth0とは Okta社が提供する 開発者向けのIDaaS (Identity as a Service) - セキュリティ機能が充実 - MFA (Multi Factor Authentication) - ブルートフォース攻撃対策など - 簡単にOIDC・SAMLでのシングルサインオンに 対応できる 経理AXサービス「Bill One」 - 2019年に開発スタート - 2020年5⽉にリリース - ファーストリリースまで3 ~ 5名の少数体制 - 現在のチーム数は27 - 認証基盤としてAuth0を利⽤する⽅針 - セキュリティ・可⽤性を担保 - 開発リソースをプロダクト本体に集中
7. プロダクト・会社の成⻑に伴い顕在化してきた課題 Bill Oneでの Auth0の 利⽤コスト 認証周りの ⼈材・ノウハウの 分散
8. Bill OneでのAuth0の利⽤コスト リリースから5年で T2D3を超える成⻑速度 ARR 109.62 億円 2.37 億円 2021年5⽉ 2025年5⽉ - サービスが急速に成⻑ - 成⻑に伴いユーザー数も増加 - 1年でMAUは2倍以上に増加
9. 主要⾔語 C# Kotlin Kotlin / Go Ruby インフラ AWS Google Cloud Google Cloud AWS IDaaS - Auth0 Auth0 - 認証周りの⼈材・ノウハウの分散 - 当社では歴史的にプロダクトごとの独⽴性が⾼い - ユーザー管理や認証も分かれている - 全社横断での改善が進めづらい - 新規プロダクトでの⼈材確保が難しい - IDaaSを使っても認証認可やSSO周りの知⾒は必要
10. 認証基盤内製化の経緯 Bill Oneでは認証基盤としてAuth0を利⽤していた 課題 1. サービスの成⻑に伴うAuth0利⽤コストの増加 2. 歴史的経緯による認証周りのノウハウ・⼈材の分散 専⾨チームを組んで認証基盤を内製化し、プロダクトの共通認証基盤とする 3 ~ 4名のタスクフォースで内製化に取り組むことに
11. 認証基盤の技術選定・設計 と移⾏について
12. 認証基盤構築の選択肢 選択肢 メリット デメリット 完全⾃前開発 完全な⾃由度 開発・運⽤コスト⼤ Keycloak等のOSS 開発⼯数低 運⽤負荷・セキュリティ Auth0以外のIDaaSへ移⾏ + ⾃前開 発 カスタマイズ性と セキュリティのバランス ⼀定の開発コスト Auth0以外のIDaaSへ移⾏ 運⽤負荷低、セキュリティ カスタマイズ性低
13. 代表的なIDaaSの料⾦ サービス MAU単価 (⽉額) 備考 Auth0 $0.24 B2B Professionalプランで7,500 MAUの場合の参考値 ※ 実際の契約額とは異なります https://auth0.com/pricing Amazon Cognito $0.0055 ~ 0.0025 東京リージョン 50,000MAUまで無料 それ以降MAUに応じてディスカウント https://aws.amazon.com/cognito/pricing Google Cloud Identity Platform $0.0055 ~ 0.0025 49,999MAUまで無料 それ以降MAUに応じてディスカウント Azure AD B2C (Premium P1) $0.00325 50,000MAUまで無料 2025年5⽉1⽇以降Azure AD B2Cは新規の利⽤が停⽌ - Auth0のMAU単価は⾮常に⾼い - IDaaS移⾏によって、⼤幅なコスト削減につながることがわかった
14. 新しい認証基盤に必要な要件 - 既存のログイン体験を維持するためのログイン画⾯のカスタマイズ性 - ⾃社の基準を満たせるパスワードポリシーの設定機能 - TOTP（Time-based One-Time Password）によるMFA（Multi-Factor Authentication） - ブルートフォース対策 - 複数回ログイン失敗でのアカウントロック - 不審なIPアドレスのブロック Auth0では実現できていた内容だが、IDaaSを移⾏した場合、 ⾃前開発せずに素直に実現することは難しい 将来の拡張性も踏まえ、⾜りない機能は⾃前開発で補う
15. 最終的な⽅向性 IDaaSの移⾏ + ⾃前開発 - IDaaS - Amazon Cognito - クラウドサービス - アマゾン ウェブ サービス（AWS） - OSSを利⽤し認可サーバーを⾃作 - 認証部分はCognitoに任せる Amazon Cognitoの選定理由 - コスト削減が⾒込める - TOTPでのMFAに対応 - 当時は対応していないIDaaSも - API経由で認証機能が利⽤できることから ⾃前のアプリケーションで機能を 補いやすい - 社内でAWSを得意とするメンバーは多い
16. システム構成 運⽤負荷を考慮し サーバーレスを 積極的に採⽤ Backend - Go - Connect RPC Frontend - TypeScript - React
17. 認証基盤の移⾏について
18. アカウント移⾏の選択肢 パスワードなどを再設定してもらう - ユーザーの負荷が⼤きいため⾒送り パスワードハッシュなどをインポート - Auth0は、パスワードハッシュを含むユーザー情報のエクスポートが可能だが、 具体的な実⾏⽇時の保証がない - Amazon Cognitoはパスワードハッシュの⼀括インポートをサポートしていない JIT(Just-In-Time)移⾏ - ダウンタイムなく、ログイン情報（パスワード）を引き継げる - Amazon CognitoのLambdaトリガーを利⽤して実現可能
19. Amazon CognitoのLambdaトリガーとは 認証・サインアップなどいくつかのタイミングで起動するLambda関数を 設定しておくことで、デフォルトの動作を変更することができる ユーザー移⾏のLambdaトリガー - ログインやパスワード再設定時に旧基盤から新基盤へアカウント情報を 移⾏することができる - ログイン・パスワード再設定時にCognitoのUser Poolにアカウントが存在しない場合、 Lambdaから旧基盤へ問い合わせを⾏うことでアカウント情報を移⾏する
20. Authentication API ログイン時のアカウント移⾏の流れ Auth0 1.ログイン試⾏ 2.ログイン試⾏ 3.Lambdaを起動 4.APIでログイン試⾏ 5.成功レスポンス 6.ユーザーの情報を登録 Amazon Cognito Lambda 8.ログイン成功 7.ユーザーの情報を登録 認証基盤 次回以降はCognitoで直接認証 CognitoのUser Poolに該当の ユーザーが存在しない場合 Lambdaが起動する
21. シングルサインオンの移⾏ - 移⾏の初期段階ではSSOは引き続きAuth0を利⽤する⽅針としていた - SSOを利⽤するユーザーの割合は⼩さく、契約更新のリミットを優先 - SSO利⽤ユーザーのログインの場合、新認証基盤からAuth0を経由してSSOさせることで、 既存のSSO設定をそのまま利⽤していた OIDC ・ ・ ・ Bill One 顧客のIdP (SAML) 顧客のIdP (OIDC) 顧客のIdP Auth0 SSO機能 内製認証基盤 Amazon Cognito 認証機能 (パスワード・MFA) OIDC
22. シングルサインオンの移⾏ 移⾏における課題 - 移⾏には顧客IdP側の設定変更も必要 - これまでシングルサインオンの設定は エンジニアが⼿作業で実施していた - コミュニケーション・作業の⼯数が 定常的に発⽣ - 設定ミスが発⽣することも - このまま数百のテナントの設定を やり直すには莫⼤な⼯数がかかるため ⾮現実的 Bill One + Auth0 CS エンジニア 設定情報をもらう CSからもらった 情報をもとに設定 顧客システム管理者
23. シングルサインオンの移⾏ 設定画⾯を実装し設定を セルフサービス化 - 既存テナントは画⾯上から再度 設定してもらうことで新しい 認証基盤を利⽤したSSOに切り替わる 結果 - 約3ヶ⽉で設定の移⾏を完了 - トイルを削減することで⽉当たり 10〜30時間の⼯数を削減 Bill One + 認証基盤 顧客システム管理者 CS エンジニア 直接設定可能に
24. 認証基盤内製化の振り返り
25. 内製化の成果 ⼤幅なコスト削減に成功 - IDaaSとOSSを活⽤して短期間での内製化を実現 - 認証基盤のコストを約90%削減 専⾨チームを設⽴ - 横断組織として独⽴、ノウハウの集約が可能な状態に 独⾃の機能拡張が可能になり体験の改善がスムーズに - Home Realm Discoveryの改善などを実施
26. 認証基盤切り替え時のドメイン変更による影響 ログイン画⾯のドメイン変更による、⼀時的な問い合わせの増加 - 共通基盤化を考慮し、bill-one.com配下からsansan.com配下へ変更 - ドメイン変更によってパスワードマネージャーの補完が効かなかったり、 Sansanのパスワードが補完されてしまうユーザーが発⽣ Bill Oneの旧ログイン画⾯ (auth.bill-one.com) Bill Oneの新ログイン画⾯ (auth.sansan.com) Sansanのログイン画⾯ (ap.sansan.com) Bill Oneの ID/パスワード Sansanの ID/パスワード サジェスト サジェスト
27. IDaaS・OSSの限界 Amazon Cognito単体の機能ではカバーできないケース - Amazon Cognitoにはリカバリコードを発⾏する機能がない > Cognito採⽤にあたって妥協した機能だったが、MFAリセットの問い合わせが微増 > システム管理者がユーザーのMFAをリセットできるようにしたり、リカバリーコードを発 ⾏する機能を⾃前で開発することで対応 OIDCのライブラリの機能不⾜ - e.g. PKCE(Proof Key for Code Exchange)がPublic Clientでしか利⽤できない - Confidential Clientでも認可コードのインジェクションやCSRFの対策として有効 - 不⾜している機能の追加などはOSSコントリビュートで対応