Sansan、インボイス管理サービス「Bill One」の認証をAuth0からCognitoベースの内製基盤へ。リリース後3週間でMAUの約86%が移行し、コストを大幅に削減

Bill Oneは「請求書受領から、月次決算を加速する」をタグラインに掲げるBtoB SaaSのインボイス管理サービスで、これまでAuth0（Enterpriseプラン）を認証基盤として利用してきた。Bill Oneはユーザー数に基づく課金をしておらず、利用企業は必要なだけユーザーを作成できる。さらに請求書の代理受領を促すため、取引先企業にも送付用のアカウントを作成している。経理業務の都合上、月に一度しか使わないアカウントも多く、MAU課金のAuth0とは相性がよくなかった。直近一年で有料契約件数は倍に、MAUは倍以上に伸びており、この相性問題が認証基盤のコストとして顕在化した。公開されているAuth0のB2B Professionalプランは7500MAUで$1800/month、1MAUあたり$0.24で、他社のIDaaSは大幅に低コストだった。こうしてAuth0リプレースによるコスト最適化の検討が始まった。

まず移行先のIDaaSを比較した。Amazon Cognito、Google Cloud Identity Platform、Azure Active Directory B2Cの3つは課金体系がいずれもMAUベースで、概ね同じ価格帯だった。

• Cognitoを採用: TOTPによるMFAに対応し、採用事例が多い
• Identity Platformは見送り: 不足機能をサーバーサイドで補うのが難しく、検討時はTOTPによるMFAに非対応
• AzureAD B2Cは見送り: Azureになじみのあるエンジニアが少ない

Cognito単体では機能が足りないため、CognitoのAPIを直接利用して認証基盤を自前開発した。OIDCのOPとして振る舞うユーザー向けサービス（MPA）、Connectサーバーとして実装した管理API、SPAの管理画面の3つで構成し、Fargateを中心にAurora Serverless v2やElastiCache Serverlessを採用している。

アカウント移行には、Cognitoのユーザー移行Lambdaトリガーを使った。

• ログイン試行時: Auth0へROPC Flowでログインを試み、成功したらCognitoのUser Poolに登録。ユーザーは次回以降も従来のパスワードでログインできる
• パスワードリセット時: Auth0でユーザーの存在を確認し、User Poolに登録
• SSO: テナントに再設定を求めるのは契約更新までに非現実的だったため、新基盤からAuth0へ認証処理を委譲して3回のID連携を行う形で残した

新基盤は2023年12月に無事リリースされた。

• リリース後3週間でMAUの約86%のユーザーが新基盤に移行
• 認証基盤のコストは、Auth0の契約更新で想定されるコストと比べて大幅に削減できた
• メールアドレスごとにログイン方法を設定可能にするなど、独自の仕様を柔軟に組み込めるようになった

一方、ログイン画面をbill-one.comからsansan.comのサブドメインへ変更したことで、パスワードマネージャーがSansanのログイン情報をサジェストしてしまい、一時的にログイン失敗の問い合わせが増えた。ログイン失敗時のメッセージを追加して対処している。ログインしていない未移行ユーザーは近日中に一括インポートし、並行稼働を終了する予定としている。