認証基盤（ログインの仕組みの移管）とは
認証基盤とは、サービスの利用者のログインを担う仕組みで、自前のパスワード認証のほか、Firebase Authentication・Auth0・Amazon Cognito・Supabase Authなどの外部サービス、GoogleやAppleでのソーシャルログインを組み合わせて構成されます。事業を移管するとき、認証基盤の契約名義・ユーザーデータ（パスワードのハッシュ）・OAuthクライアントの登録を正しく引き継がないと、全利用者がログインできなくなります。
「ユーザーが全員ログインできなくなった」は、引き継ぎで起こりうる最も破壊的な障害です。データベースを移し、コードをデプロイし、ドメインを切り替えても、認証が外部サービスに依存していれば、そのサービス側のプロジェクトが旧オーナーの名義のままである限り、買主は何も制御できません。逆に、認証を買主のプロジェクトへ移そうとして、パスワードのハッシュを持ち出せない仕様であれば、全ユーザーにパスワードの再設定を強いることになります。
確認すべき点は4つです。①ユーザーデータの可搬性——パスワードのハッシュとそのアルゴリズム・ソルトをエクスポートできるか。Firebase Authenticationはハッシュを含めたエクスポートに対応していますが、サービスによっては不可能で、移管ではなく「再登録」になります。②ソーシャルログインのクライアント登録——Google・Apple・GitHubのOAuthクライアントIDは、それぞれの開発者コンソールのプロジェクトに紐づいており、名義を変えるにはプロジェクトの移管かクライアントの再登録が要ります。Sign in with Appleはユーザー識別子が開発者のチームに紐づくため、Apple Developerのチームが変わるとそのままでは同一人物と認識できず、Appleの手順に沿ったユーザー識別子の移行が必要です。③セッションとトークン——署名鍵を変えれば全セッションが無効になり、変えなければ旧オーナーがトークンを偽造できます。④二要素認証・パスワードリセットのメール送信基盤——送信ドメインの認証（SPF・DKIM）が旧オーナーの設定に依存していれば、リセットメールが届きません。
RIKKA M&Aの技術デューデリジェンスは、認証に使われているライブラリと外部サービスへの依存、署名鍵やクライアントシークレットのハードコードを検査します。資産移管チェックリストでは、認証基盤の移管は「動作確認」を伴う受領確認が必須で、テストユーザーでのログイン・新規登録・パスワードリセットの一連を買主が実際に試してから検収するべき項目です。