インボイス管理サービスBill Oneの認証を内製認証基盤に置き換えて認証基盤のコストを削減した話
Bill One Engineering Unit 共通認証基盤チームの樋口です。Bill Oneでは昨年までAuth0を認証基盤として利用してきましたが、認証基盤を内製化することでコストを大幅に削減しました。この認証基盤は、昨年12月に無事リリースされ、Bill Oneの認証を支えています。今回は認証基盤の内製化に至った経緯と設計、移行プロセスについて紹介します。
I am Higuchi from the Bill One Engineering Unit shared authentication platform team. Until last year, Bill One used Auth0 as its authentication platform, but we significantly reduced costs by building the authentication platform in-house. This authentication platform was successfully released last December and now supports Bill One's authentication. This time, I will introduce the background that led to building the authentication platform in-house, the design, and the migration process.
Bill Oneについて
Bill Oneは、BtoB SaaSとして提供しているインボイス管理サービスです。本サービスは「請求書受領から、月次決算を加速する」をタグラインに掲げ、あらゆる請求書をオンラインで受け取り・請求書業務を効率化することで、企業経営における意思決定のスピード向上を目指しています。
Bill One is an invoice management service offered as a BtoB SaaS. Under the tagline "Accelerate monthly financial closing from invoice receipt," it aims to improve the speed of corporate decision-making by receiving all invoices online and streamlining invoice operations.
認証基盤に関する課題
Bill OneはこれまでAuth0を認証基盤として利用してきました。Auth0は非常に機能が充実しており多くの採用実績がありますが、他のIDaaSと比較して高い価格設定となっています。前述の通り、Bill Oneではユーザー数課金を行っていないことに加え、経理業務という都合上、月に一度しかBill Oneを利用しないアカウントも多く存在します。そのためAuth0の価格体系であるMAU課金とは相性がよくありません。
Bill One had been using Auth0 as its authentication platform. Auth0 is extremely feature-rich with a strong track record, but its pricing is high compared to other IDaaS providers. As mentioned, Bill One does not charge per user, and due to the nature of accounting work, many accounts only use Bill One once a month. Therefore, Auth0's MAU-based billing model was not a good fit.
解決方法の検討
認証基盤のコストの問題を解決するため、どのような選択肢を取るかを検討しました。IDaaSを移行する、もしくは内製するにあたって次のようなグラデーションが考えられます。Auth0以外のIDaaSへ移行、IDaaS + 自前開発、KeycloakのようなOSSの利用、完全自前開発などです。もともと、認証の機能をできるだけマネージドサービスに寄せることで開発工数は抑えつつも、可用性やセキュリティを担保したいという意図でAuth0を利用していました。
We examined what options to take in order to solve the authentication platform cost problem. A range of approaches could be considered for migrating or building the IDaaS in-house: migrating to another IDaaS, IDaaS plus custom development, using an OSS like Keycloak, or fully custom development. Originally, we had been using Auth0 with the intention of keeping development effort down by leaning on managed services as much as possible, while still ensuring availability and security.
認証基盤の設計
上述の通り、Cognito単体では機能が足りないため、不足している機能を自前で実装する必要があります。CognitoのAPIを直接利用する形でOIDC（OpenID Connect）のOP（OpenID Provider）としてふるまうアプリケーションを開発することにしました。最終的に認証基盤は、ユーザー向けサービス（OP）、管理API、管理画面の3つで構成されています。
As mentioned above, Cognito alone lacked sufficient features, so we needed to implement the missing functionality ourselves. We decided to develop an application that acts as an OIDC (OpenID Connect) OP (OpenID Provider) by directly using the Cognito API. Ultimately, the authentication platform is composed of three parts: the user-facing service (OP), a management API, and an admin UI.
アカウントの移行について
Auth0はサポートチケットから依頼することでパスワードハッシュを含むユーザー情報のエクスポートが可能ですが、エクスポート作業の具体的な実行日時を保証してもらえません。また、Amazon Cognitoはパスワードハッシュの一括インポートをサポートしていないため他の方法を採る必要がありました。そこでAmazon Cognitoに用意されているユーザー移行のLambdaトリガーを利用しました。ログイン試行もしくはパスワードリセットのタイミングでCognitoのUser Poolに該当ユーザーが存在しなかった場合にLambdaを呼び出せます。
Auth0 allows exporting user information including password hashes via support ticket, but cannot guarantee a specific execution date. Furthermore, Amazon Cognito does not support batch import of password hashes, so we needed to take a different approach. We used the user migration Lambda trigger provided by Amazon Cognito, which can invoke a Lambda function when the corresponding user does not exist in the Cognito User Pool during a login attempt or password reset.
振り返りと今後
新基盤は、昨年の12月に無事リリースされました。その結果、リリース後3週間でMAUの約86%のユーザーが新基盤に移行し、認証基盤のコストはAuth0の契約更新で想定されるコストと比べて大幅に削減できました。
The new platform was successfully released last December. As a result, approximately 86% of MAU users migrated to the new platform within three weeks of release, and authentication platform costs were significantly reduced compared to the expected costs of renewing the Auth0 contract.
最後に
Bill OneはAuth0の利用をやめ、認証基盤を内製化する選択肢を取りました。しかし、これまでAuth0を利用してきたことで認証周りの開発運用工数を大幅に削減しプロダクトの本質的な部分にフォーカスできたことは事実です。内製化にあたって、Auth0では当たり前にあった機能がCognitoになく自前開発の必要な部分がいくつもありました。改めてAuth0が非常によくできたサービスであったことを痛感しました。
Bill One chose to stop using Auth0 and build the authentication platform in-house. However, it is a fact that using Auth0 up until now had significantly reduced development and operations effort around authentication, allowing us to focus on the essential parts of the product. When building in-house, there were numerous features that Auth0 had as a matter of course but Cognito lacked, requiring custom development. We keenly realized once again what an excellently built service Auth0 was.