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/setup-oauth.md (or send Accept: text/markdown).

OAuth サインインのセットアップ

Google、Apple、GitHub、Microsoft、Twitter——それぞれフラグ 1 つとクライアントのペア 1 組。

このガイドについて質問

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

認証とは、誰がアプリを使用しているかを証明することを意味します。 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、一回限りの消費、ログアウト、拒否された匿名アクセスをテストします。メモリアダプターテストはハンドラー意味論をカバーします。本番データベース永続化と実プロバイダーコールバックは別の受け入れが必要です。

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

1. AUTH_SECRET を 32 文字以上のランダムな文字列に設定します——openssl rand -hex 32 が使えます。

2. 各プロバイダーの開発者コンソールで OAuth アプリを作成し、コールバック URL を登録します：Better Auth（デフォルトの AUTH_PROVIDER）では {APP_URL}/api/auth/callback/<provider>。プロバイダーがコールバックを 1 つしか許可しない場合はローカルと本番で別のアプリを使います——docs/github-auth-setup.md が GitHub の流れを端から端まで案内します。

3. プロバイダーのフラグを有効にし、クライアントのペアを設定します——AUTH_GOOGLE_ENABLED と GOOGLE_CLIENT_ID・GOOGLE_CLIENT_SECRET、Apple・GitHub・Microsoft・Twitter も同じ 3 つ組です。認証情報なしでフラグを有効にすると起動が失敗し、不足している変数が名指しされます。

4. Microsoft だけはエンジンでコールバックが異なります：Better Auth では /api/auth/callback/microsoft、Auth.js では /api/auth/callback/microsoft-entra-id。

AUTH_SECRET=<at-least-32-random-characters>
AUTH_PASSKEY_ENABLED=true
EARLY_ACCESS_INVITE_ONLY=false

AUTH_GOOGLE_ENABLED=true
GOOGLE_CLIENT_ID=…
GOOGLE_CLIENT_SECRET=…

AUTH_GITHUB_ENABLED=true
GITHUB_CLIENT_ID=…
GITHUB_CLIENT_SECRET=…

# AUTH_APPLE_ENABLED / AUTH_MICROSOFT_ENABLED / AUTH_TWITTER_ENABLED
# follow the same pattern:
# MICROSOFT_CLIENT_ID=…  MICROSOFT_CLIENT_SECRET=…
# TWITTER_CLIENT_ID=…    TWITTER_CLIENT_SECRET=…

# Workspace connected accounts (Settings → Connections):
# CONNECTED_X_CLIENT_ID=          CONNECTED_X_CLIENT_SECRET=
# CONNECTED_GOOGLE_CLIENT_ID=     CONNECTED_GOOGLE_CLIENT_SECRET=
# CONNECTED_MICROSOFT_CLIENT_ID=  CONNECTED_MICROSOFT_CLIENT_SECRET=

# Callbacks to register (Better Auth):
#   {APP_URL}/api/auth/callback/google
#   {APP_URL}/api/auth/callback/apple
#   {APP_URL}/api/auth/callback/github
#   {APP_URL}/api/auth/callback/twitter
#   {APP_URL}/api/auth/callback/microsoft   (Auth.js: microsoft-entra-id)

実装ワークフロー

ワークスペースの外部アカウントは別のサーフェスです：CONNECTED_X_*、CONNECTED_GOOGLE_*、CONNECTED_MICROSOFT_* の各ペアは設定 → 接続に供給し、そのコールバックは {APP_URL}/api/accounts/{x|google|microsoft}/callback 配下にあります。クライアント ID が空ならそのプロバイダーの連携フローは無効のままです——サインインアプリの認証情報をそこで再利用しないでください。

プロバイダーのクライアントシークレットは AUTH_SECRET と同様にサーバー専用です——NEXT_PUBLIC_ や EXPO_PUBLIC_ 変数には絶対に入れないでください。

サインインは動きましたか？「AI のセットアップ」に進みます。

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

初回サインイン、再訪セッション、キャンセルされた同意画面、無効化されたプロバイダーをテストします。よくある失敗はコールバックの不一致です——登録された URL は APP_URL とエンジンのコールバック ID に正確に一致しなければならず、env 変更後はアプリの再起動が必要です。

設定を続けるには、AI のセットアップをご覧ください。