認証の外部委託の危険性：Val TownのBetter Authへの移行から得た教訓

認証はしばしば商品として捉えられ、開発を加速させるためにサードパーティプロバイダーに委託できる解決済みの問題と見なされます。しかし、Val TownがSupabaseからClerk、そして最終的にBetter Authへと移行した過程が示すように、アイデンティティ層を外部委託する決定は、元に戻すのが困難なシステム的リスクをもたらす可能性があります。

多くのスタートアップにとって、「ゼロコンフィグ」認証の魅力は強いです。しかし、アプリケーションの要件が進化し、特にユーザーデータが頻繁にアクセス・表示されるソーシャルプラットフォームの場合、マネージドサービスが提供する抽象化がボトルネックになることがあります。これは、Val TownがClerkから離れた理由と、プロセス中に得られたアーキテクチャ上の教訓を詳細に見ていくものです。

「マネージドユーザーテーブル」の危険性

現代の認証サービスで最も議論の的となっているアーキテクチャパターンの一つは、独自のユーザーテーブルを廃止し、プロバイダーを唯一の真実の情報源（シングルソースオブトゥルース）とすることです。これにより初期設定は簡素化されますが、信頼性とレートリミットという二つの主要な失敗点が生まれます。

レートリミットの罠

サービスがユーザーテーブルを管理すると、ユーザーメタデータ（アバター、メール、設定）へのすべてのリクエストはそのAPIを通過しなければなりません。Val Townは、開発環境ではシームレスに機能したものの、本番環境では状況が異なることを発見しました。

「本番環境では、そのエンドポイントのレートリミットは1秒あたり5リクエストでした。これは全ユーザーに対するアカウント全体の上限です。」

複数ユーザーのコンテンツを一覧表示するページが多いソーシャルサイトにとって、このモデルは根本的に破綻しています。この問題を回避するために、開発者はしばしばデータをWebhookで自分のデータベースに同期させることを余儀なくされ、結果として二つの真実の情報源が生まれ、ユーザー管理の複雑さが倍増します。

セッション管理の単一障害点

プロバイダーがセッションを管理すると、ログイン処理だけでなく、認証が必要なすべてのリクエストのクリティカルパスの一部となります。プロバイダーが障害を起こすと、ユーザーはセッションクッキーを更新できず、既にログインしているユーザーでさえサイト全体が利用不能になります。

Val Townは、サイトの信頼性がすべてのクリティカルパーツの信頼性の積になっていることに気付きました。あるコミュニティメンバーが議論で指摘したように、ソフトウェア、認証レイヤー、クラウドプロバイダーそれぞれが99%の可用性を持つ場合、全体の可用性は97%に低下します。

代替案の評価

マネージドサービスの代替を見つけるのは困難です。市場は「古くて半放棄された」オープンソースライブラリと、高リスクなベンダーロックインプラットフォームに分かれがちです。

なぜBetter Authか？

Better Authが選ばれたのは、ライブラリの利便性とセルフホスティングの主権性を両立させているからです。完全にマネージドされたサービスとは異なり、データベースとセッション管理を開発者がコントロールでき、必要なフレームワーク統合（Remix、Fastify、Express）も提供します。

ベンダーリスクの低減: システムはセッション機能のためにサードパーティがオンラインであることに依存しなくなります。
拡張性: オープンソースでライブラリベースであるため、閉鎖的なAPIよりも「ハックしやすい」です。
ステートレスインフラ: Better Authの有料アドオンは主にステートレスで、セッション管理のパスに関与しません。

「自前で作る」議論

この移行は、エンジニア間で古くからの格言「自前の認証は決して作るな（Never roll your own auth）」に関する広範な議論を呼び起こしました。

かつてはコンセンサスが絶対的でしたが、経験豊富な開発者の多くは、基本的な要件（bcryptパスワード、マジックリンク、Postgresのセッションテーブル）に対しては、シンプルな内部システムを構築するリスクは、複雑で不透明なサードパーティのブロブに依存するリスクよりも低いと主張しています。ある貢献者が指摘したように、マネージドサービスの「ハッピーパス」はそれに従う限りは素晴らしいものの、そこから外れるとプロバイダー内部の抽象化が障害となります。

ダウンタイムゼロの移行実行

認証プロバイダーの変更は、チームが実行できる最もハイリスクな作業の一つです。Val Townはスムーズな引き継ぎを確保するために移行期間を設けました：

並行サポート: 2週間にわたり、すべての認証エンドポイントがClerkとBetter Authの両方からのクッキーを受け入れました。
段階的移行: ユーザーはサインイン時に移行され、サインインページがBetter Authのセッションを発行しました。
手書きの最終実装: 初期の移行コードの雛形作成にはLLMが支援しましたが、最終的なセキュリティクリティカルな実装は手書きで行い、脆弱性を防ぐために徹底的にテストされました。

最後に

SupabaseからClerk、そしてBetter Authへの旅路は、複雑なシステムの信頼性は最も弱いリンクで決まることを思い出させます。マネージドサービスはシンプルでフロントエンド中心のアプリ、特にソーシャルコンポーネントのないものには優れていますが、高可用性とユーザーデータとの深い統合が求められるプラットフォームにとっては負債となり得ます。最も楽しいエンジニアリングはしばしば「退屈」な領域、すなわちデータを自分で所有し、セッションをコントロールし、リクエストパスにおける重要なサードパーティ依存を最小化することです。