For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /ja/docs/web/authentication.md (or send Accept: text/markdown).

認証

サインイン方法、セッション、アカウントセキュリティ。

このガイドについて質問

実際のアカウントを作成して確認する

認証とは、誰がアプリを使用しているかを証明することを意味します。 Postgres を起動し、最初にデータベースガイドを使用して移行を実行してから、Web サーバーを実行したままにします。 http://localhost:3000/auth, を開き、電子メール/パスワードによるサインアップを選択し、名前、電子メール、パスワードを入力して送信します。この最初のテストでは、EMAIL_PROVIDER=local を保持します。

フローが電子メールコードを要求する場合、別のブラウザータブで http://localhost:3000/mail-preview を開き、そのアドレスの最新メッセージを見つけて、そのコードをサインインフォームにコピーして戻します。有効期限が切れた場合は、新しいコードをリクエストしてください。これらのメッセージはローカルの送信トレイに残ります。外部の受信箱を繰り返しチェックしても見つかりません。サインアウトしてから再度サインインし、データベースにバックアップされたアカウントが機能することを確認します。

サインアップでデータベース接続またはテーブル欠落エラーが報告された場合は、ソーシャルログインを有効にする代わりにデータベースのセットアップを終了します。 Google、GitHub、Apple、X、および Microsoft ボタンには、独自のプロバイダーアプリケーションとコールバック設定が必要です。プロバイダーガイドが完了した後でのみ有効にしてください。 Better Auth は出荷時のデフォルトエンジンであり、ローカル電子メールサインインに有料の認証アカウントは必要ありません。

有効なログイン方法を選ぶ

基盤にはメール/パスワード、OTP、設定可能なソーシャル認証が含まれます。Better Auth が認証とセッションを所有し、アプリケーションがプロバイダー設定と OTP のトランザクショナル配信を組み立てます。

設定したソーシャルプロバイダーのみを有効にしてください。プロバイダーのクライアントシークレットと認証シークレットはサーバーに留まります。

認証をワークスペースに接続する

認証済みハンドラーはワークスペースレコードに触れる前にセッション状態を解決します。ワークスペースプロビジョニングは冪等でなければならず、ライフサイクルフックを繰り返しても所有レコードが二重に作られないようにします。

セッション動作を検証する

ログイン、無効または期限切れの OTP、一回限りの消費、ログアウト、拒否された匿名アクセスをテストします。メモリアダプターテストはハンドラー意味論をカバーします。本番データベース永続化と実プロバイダーコールバックは別の受け入れが必要です。

インストールとセットアップ

Better Auth がデフォルトエンジンです(AUTH_PROVIDER=better-auth)。Auth.js エンジンはそれに統一するチーム向けに用意されています。有効なメソッドはプロバイダーごとに宣言します: メール/パスワード、トランザクションメールで配信されるワンタイムコード、Google・Apple・GitHub・Microsoft・Twitter のソーシャルサインイン。

各ソーシャルプロバイダーは AUTH_<PROVIDER>_ENABLED フラグと対応する client id・secret で有効化します。認証シークレット、プロバイダーシークレット、セッション署名キーはサーバー専用の設定です。

AUTH_PROVIDER=better-auth
AUTH_SECRET=generate-a-long-random-value
AUTH_GOOGLE_ENABLED=true
GOOGLE_CLIENT_ID=…
GOOGLE_CLIENT_SECRET=…

実装ワークフロー

/auth サーフェスは設定済みのメソッドを描画し、サーバーは auth-runtime でエンジンを組み立て、保護された境界ごとにセッションを解決します。最初のサインイン成功でメンバーの個人ワークスペースが冪等にプロビジョニングされます — 繰り返されたライフサイクルフックが二つ目の所有権レコードを作成してはいけません。

アカウントセキュリティは /settings/security にあります: パスワード変更、アクティブセッション、ビルドで有効な場合のパスキー。セッション復元、ログアウト時の失効、ワークスペース間拒否は UI 状態ではなくサーバー強制の動作として維持してください。

検証とトラブルシューティング

サインイン、無効・期限切れの OTP コード、単回消費、HTTPS オリジンでのパスキーセレモニー、ソーシャルコールバックの戻り、ログアウト、匿名拒否を確認します。コールバックをテストする前に各プロバイダーのリダイレクト URI を登録し、失効したセッションが保護された処理を実行できないことを確認してください。

認証