Bill Oneの認証を内製認証基盤に置き換えた話

by SansanTech

Slide 1

Slide 1 text

Sansan株式会社部署名前 Bill Oneの認証を内製認証基盤に置き換えた話 Sansan技術本部 AWS SaaS Builders Forum Sansan株式会社樋口礼人

Slide 2

Slide 2 text

Sansan株式会社のソフトウェアエンジニア 2022年に入社後、Contract Oneの開発に携わる 2023年9月にBill Oneへ異動し認証基盤を担当好きなAWSサービス：AWS Fargate 趣味：ポッドキャストを聴くこと樋口礼人（Ayato Higuchi） Sansan株式会社技術本部 Bill One Engineering Unit 共通認証基盤チーム

Slide 3

Slide 3 text

本セッションについて発表内容 Amazon Cognitoを利用して構築した認証基盤の設計・移行プロセスについてアジェンダ - Bill Oneとは - 認証基盤内製化の背景 - 内製化の方針 - 新しい認証基盤の設計 - 無停止でのアカウント移行について - リリース後の状況 - まとめ

Slide 4

Slide 4 text

Bill Oneとは

Slide 5

Slide 5 text

働き方を変えるDXサービス請求人や企業との出会いをビジネスチャンスにつなげる「働き方を変えるDXサービス」を提供ビジネスフローにおけるさまざまな分野でサービスを展開名刺管理名刺DX 営業営業DX 契約契約DX 経理DX 個人向けDX 法人向けDX 必要な情報をすぐに見つけられる情報の管理がしやすくすぐに共有できる情報を分析・活用しやすくデータに基づいた判断ができる SansanのDXサービスの活用で変わる働き方

Slide 6

Slide 6 text

請求書受領から、月次決算を加速するインボイス管理サービス「Bill One」あらゆる請求書をオンラインで受け取り、企業全体の請求書業務を加速するインボイス管理サービスです。

Slide 7

Slide 7 text

Bill Oneの提供価値どんな形式の請求書でもワンストップで受領し、契約企業の請求書の一元管理を実現します。 ※ Sansan株式会社が規定する条件を満たした場合のデータ化精度ワンストップ受領 99.9％※の精度でデータ化クラウド上で一元管理請求書を発行する企業 Bill Oneの契約企業メール添付アップロード郵送代理受領代理スキャン

Slide 8

Slide 8 text

認証基盤内製化の背景

Slide 9

Slide 9 text

従来の認証基盤: Auth0 Okta社が提供するIDaaS (Identity as a Service) - さまざまなアプリケーションに簡単に組み込める - セキュリティ機能が充実 ○ MFA (Multi Factor Authentication) ○ ブルートフォース攻撃対策など - B2B (企業向け), B2C (消費者向け), B2E (従業員向け) のログインを提供 - Single Sign-On (SSO) やOrganizationなど、B2B SaaS向けの機能も充実 - M2M (Machine-to-Machine) の認証も提供 https://auth0.com/

Slide 10

Slide 10 text

従来の認証基盤の課題1: コスト - サービスの成長に伴うコストの増加認証基盤の移行タイミング

Slide 11

Slide 11 text

従来の認証基盤の課題1: コスト - サービスの成長に伴うコストの増加 - MAU単価の比較（参考）サービス MAU単価 (月額) 備考 Auth0 $0.24 B2B Professionalプランで7,500 MAUの場合の参考値（実際の契約額とは異なる） https://auth0.com/pricing Amazon Cognito $0.0055 AWS アジアパシフィック (東京) リージョン 50,001 ～ 100,000MAUの場合の参考値 https://aws.amazon.com/cognito/pricing - Bill OneはMAUに応じて直接的に収益が上がるビジネスモデルではない - ユーザー数課金ではない課金体系 - 取引先に無料アカウントを作成してもらえる > 取引先のユーザーが毎月ログインして請求書を送るケースも多い

Slide 12

Slide 12 text

従来の認証基盤の課題2: 人材 - 当社では歴史的にプロダクトごとの独立性が高い - ユーザー管理や認証も分かれている - 新規プロダクトの初期フェーズではプロダクトごとに認証周りに強い人材を配置するのが難しい - IDaaSを使ってもSSO周りの知見は必要 C# AWS Kotlin 他社サービス Kotlin / Go 他社サービス Ruby AWS 主要言語インフラ

Slide 13

Slide 13 text

共通認証基盤プロジェクト 1. サービスの成長に伴うコストの増加 2. 認証周りのノウハウ・人材が分散している新規プロダクトを開始する際、初期のフェーズではプロダクトごとに認証周りに強い人材を配置するのが難しい専門チームを組んで認証基盤を内製化し、プロダクトの共通認証基盤とする

Slide 14

Slide 14 text

内製化の方針

Slide 15

Slide 15 text

内製化するとしてどこまで自前開発するか - 完全自前開発 - KeycloakのようなOSSを利用 + 自前開発 - KeycloakのようなOSSを利用 - Auth0以外のIDaaSへ移行 + 自前開発 - Auth0以外のIDaaSへ移行自前で管理する部分大小

Slide 16

Slide 16 text

代表的な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 A社 $0.0055 ~ 0.0025 49,999MAUまで無料それ以降MAUに応じてディスカウント B社 $0.00325 50,000MAUまで無料 - Auth0のMAU単価は非常に高い - IDaaS移行によって、大幅なコスト削減につながることがわかった

Slide 17

Slide 17 text

認証基盤に必要な要件 - 自社の基準を満たせるパスワードポリシー - TOTP（Time-based One-Time Password）によるMFA（Multi-Factor Authentication） - ブルートフォース攻撃対策 - 複数回ログイン失敗でのアカウントロック - 不審なIPアドレスのブロック Auth0では実現できていた内容だが、IDaaSを移行した場合、自前開発せずに素直に実現することは難しい将来の拡張性も踏まえ、足りない機能は自前開発で補う

Slide 18

Slide 18 text

最終的な方向性と技術選定新基盤の方向性 - Auth0以外のIDaaSへ移行 + 自前開発技術選定 - IDaaS - Amazon Cognito - クラウドサービス - アマゾンウェブサービス（AWS） - アプリケーション - ユーザー向け画面・API: Go - 管理画面: TypeScript, React 選定理由 - コスト削減が見込める - IDaaS移行するとしても、既存の要件を維持するためには自前開発が必要になる - 自前のアプリケーションで機能を補いやすい - 社内でAWSを得意とするメンバーは多い

Slide 19

Slide 19 text

Amazon Cognitoとは

Slide 20

Slide 20 text

Amazon Cognitoとは AWSの提供するIDaaSで認証認可・アカウント管理の機能を提供特徴ふたつの方法でAmazon Cognitoのユーザープールを利用可能 - Hosted UIを利用すると独自のUI構築が不要 - User Pools APIを利用すれば自前のアプリケーションにCognitoの認証を組み込むことが可能 Lambdaトリガー - ログイン試行時・IDトークン発行時などに起動するLambdaを設定することでCognitoの挙動をカスタマイズ可能

Slide 21

Slide 21 text

新しい認証基盤の設計

Slide 22

Slide 22 text

従来の構成 Bill One OIDC /SAML OIDC - Bill OneアプリケーションがAuth0とOIDCでID連携することで認証を実現 - Auth0のEnterprise Connectionsを利用してSSO（Single Sign-On）を実現 SSO パスワード OTPシークレット顧客のIdP ・・・顧客のIdP (SAML) OIDC /SAML Auth0 顧客のIdP （OIDC）認証機能（パスワード・MFA） SSO機能

Slide 23

Slide 23 text

新しい認証基盤の構成 - 認証や機微な情報の管理はAmazon Cognitoに寄せる - 足りない機能は自前のアプリケーションで補う - SSOはAuth0を使い続ける認証基盤 Bill One OIDC Amazon Cognito OIDC 顧客のIdP (SAML) OIDC /SAML Auth0 顧客のIdP （OIDC）顧客のIdP ・・・ SSO機能認証機能（パスワード・MFA）

Slide 24

Slide 24 text

アーキテクチャ（エンドユーザー向け部分の抜粋） ECSを中心としたシンプルな構成サーバーレスを積極的に採用 → 運用工数を最小化

Slide 25

Slide 25 text

無停止でのアカウント移行について

Slide 26

Slide 26 text

アカウント移行についてパスワードハッシュ移行の課題 - Auth0は、パスワードハッシュを含むユーザー情報のエクスポートが可能だが、具体的な実行日時の保証がない - Amazon Cognitoはパスワードハッシュの一括インポートをサポートしていない課題解決の方向性 - ユーザーにパスワードを再設定させる移行も検討したが、ユーザーの手間・ダウンタイムを最小限にしたい CognitoのLambdaトリガーを利用したリアルタイム移行を実施

Slide 27

Slide 27 text

Amazon CognitoのLambdaトリガーとは認証・サインアップなどいくつかのタイミングで起動するLambda関数を設定しておくことで、デフォルトの動作を変更することができるユーザー移行のLambdaトリガー - ログインやパスワード再設定時に旧基盤から新基盤へアカウント情報を移行することができる - ログイン・パスワード再設定時にCognitoのUser Poolにアカウントが存在しない場合、Lambdaから旧基盤へ問い合わせを行うことでアカウント情報を移行する

Slide 28

Slide 28 text

ログイン時のアカウント移行

Slide 29

Slide 29 text

ログイン時のアカウント移行 Cognitoにユーザーが存在しない場合、 Lambdaが起動する

Slide 30

Slide 30 text

ログイン時のアカウント移行ログイン成功したメールアドレス / パスワードでアカウントが登録される

Slide 31

Slide 31 text

注意点

Slide 32

Slide 32 text

ログイン時のアカウント移行 APIでのログイン試行に平文パスワードが必要になるため、 SRP（Secure Remote Password）プロトコルが利用できない

Slide 33

Slide 33 text

ログイン時のアカウント移行パスワードの移行はできても、TOTPのシークレットの移行はできないのでMFAの再設定が必要

Slide 34

Slide 34 text

パスワード再設定時のアカウント移行

Slide 35

Slide 35 text

パスワード再設定のアカウント移行 Cognitoにユーザーが存在しない場合、 Lambdaが起動する

Slide 36

Slide 36 text

注意点

Slide 37

Slide 37 text

パスワード再設定のアカウント移行一度パスワードの再設定を開始すると、再設定が完了するまで、正しいパスワードを入れてもログインできなくなる

Slide 38

Slide 38 text

リリース後の状況

Slide 39

Slide 39 text

リリース後の状況 - 3週間でMAUの約86%のユーザーが新基盤に移行 - ログイン画面のドメイン変更により、ログイン不可の問い合わせが増加 - パスワードマネージャーはサブドメインの違いを無視してサジェストする - 一度保存すれば、サブドメインが一致するものが優先される Bill Oneの旧ログイン画面 (auth.bill-one.com) Bill Oneの新ログイン画面 (auth.sansan.com) Sansanのログイン画面 (ap.sansan.com) Bill Oneの ID/パスワード Sansanの ID/パスワードサジェストサジェストサジェスト

Slide 40

Slide 40 text

まとめ

Slide 41

Slide 41 text

まとめコスト削減のため、Amazon Cognitoを利用した認証基盤を構築ユーザー移行のLambdaトリガーを利用して無停止での基盤移行を実現認証基盤内製化の成果 - 大幅なコスト削減に成功 - 専門チームの結成認証基盤の今後 - 認可などの機能追加や他プロダクトでの活用 - ログイン体験の向上

Slide 42

Slide 42 text

- プロダクトの初期フェーズで認証周りの工数を削減できた効果は大きい - Auth0は機能が豊富であることを痛感 - 例: Auth0では、ブルートフォース対策としてのアカウント・IPアドレスのロック機能や柔軟なパスワードポリシーの設定などが自前で開発することなく利用できた - コストの問題がなければAuth0を使い続けたかった - ユーザー数課金のサービスや、MAUあたりの収益が高いビジネスモデルであれば、コストに見合う価値があると思う - 一方で内製化によって、自由度が上がってプロダクト独自の要件が実現しやすくなった面もある Auth0の利用を振り返って

Slide 43

Slide 43 text

No content