顧客認証
顧客のログイン方法を選び、MFA とプラットフォーム権限で独立した運用コンソールを守ります。
スターターのコミット
2a1a04aで検証済みです。
この設定により、顧客は新規登録、メールアドレスの確認、ログイン、パスワードの復旧、セッション、組織の切り替えを利用できます。信頼する運用担当者は、プラットフォーム管理者の権限と MFA の両方を要求する独立したコンソールを使います。
Sushi SaaS は Better Auth を使い、メールアドレスとパスワードによる認証と 2FA を提供します。Google OAuth は任意で有効にできます。組織のメンバー管理、招待、クエリパラメーターを使った組織の切り替えは含まれていますが、入れ子のチーム、独自の役割、組織スラッグを含むルートはありません。
認証方法を選ぶ
| 選択 | 同梱される動作 | あなたが設定すること |
|---|---|---|
| メールアドレスとパスワード | メール確認とパスワード復旧を有効化 | 本番用の Resend 認証情報と送信ドメイン |
| Google OAuth | 認証情報を追加すると有効 | Google のクライアント ID、シークレット、コールバック URL |
| CAPTCHA | Turnstile が既定で有効 | 本番用キー、または明示的な NEXT_PUBLIC_CAPTCHA_ENABLED=false |
| 顧客の 2FA | アカウント設定から利用可能 | 顧客にも必須にするか |
| 管理者アクセス | 独立した admin_ro / admin_rw 権限、MFA 必須 | 専用オリジンと、必要最小限の運用担当者一覧 |
BETTER_AUTH_SECRET、BETTER_AUTH_URL、NEXT_PUBLIC_AUTH_BASE_URL、Web URL を設定します。本番の認証には、Redis を使う分散アクセス頻度制限と、信頼できる IP アドレスの取得元も必要です。Resend がメールを送ります。ローカルでは、外部サービスが未設定か AUTH_DEV_EMAIL_LINKS=true のときに、認証リンクを安全にログへ出力できます。この設定は本番では拒否されます。
ID と認可
- Better Auth の文字列 ID が認証用 ID、
user.uuidが公開する機能領域用 ID です。 - メールアドレスと認証事業者は一意ですが、メールアドレスを認可には使いません。
- 組織内の役割（
owner、admin、member）が操作を決め、プランのエンタイトルメントが機能と上限を決めます。 - ルートはデータを参照する前に認証し、クライアントは内部メッセージではなく、安定したエラーコードを翻訳します。
独立管理アプリ
pnpm dev:admin は 3001 番ポートで起動します。apps/admin は独自のオリジンと認証 URL を持つ別アプリとしてデプロイします。pnpm admin:promote で権限を付与し、admin_ro は閲覧、admin_rw は変更が可能です。MFA は必須で、書き込み操作は監査記録に残ります。組織内の役割をプラットフォーム管理者の権限に流用しません。
公開前に、登録、メール確認、ログイン、パスワード復旧、有効にした場合の Google コールバック、セッション失効、MFA、二つの管理者権限をテストしてください。成功とは単にページが開くことではありません。未認証のリクエストが非公開データを読めず、admin_ro が書き込めず、admin_rw によるすべての変更が監査履歴に残る必要があります。認証方式を選んだ理由と変更時の注意点は、Sushi SaaS の認証の仕組みで確認できます。デプロイと運用担当者の導入は、専用の管理コンソールのセットアップとアクセスに従ってください。