新しいアプリに認証機能を追加します。 次のような場合に使用: 「認証を追加する」「ログイン機能を追加する」「Neon Auth」（Neon社が管理するBetter Auth）、ID（利用者識別）のルーティング、サインアップ、サインイン、パスワードリセット、メールOTP（メールで送信されるワンタイムコード）、マジックリンク（リンククリックで認証する方式）、複数組織の管理、電話OTP、OAuth（他社のアカウント認証を利用する方式）、パスキー（指紋認証など生体認証の使用）、MFA（多要素認証）、信頼できるドメイン設定、無効なドメイン対応、@neondatabase/authライブラリの使用など。 **デフォルト設定:** - 既存の認証機能がない場合は、Neon社が管理するBetter Authをデフォルトで使用します。 **既存の認証機能がある場合:** - Better Auth、Clerk、Supabase Auth、その他の認証サービスをそのまま利用し続けることができます。 **移行が必要な場合:** - Supabase Authからの移行が必要な場合は、Neon社が管理するBetter Authへの移行をお勧めします。 - Neon社が対応していない認証機能が必要な場合は、Neon Function（Neonの関数実行機能）またはアプリのホストサーバー上に自分で管理するBetter Authをセットアップしてください。 このプラグインは、@neondatabase/neon-jsライブラリの認証API（プログラムインターフェース）にも対応しています。
Add authentication to a new app. Use for "add auth", "add login", Neon Auth (Managed Better Auth), identity routing, sign-up, sign-in, password reset, email OTP, magic links, organizations, phone OTP, OAuth, passkeys, MFA, trusted domains, invalid domain, and @neondatabase/auth. No existing identity: default to Managed Better Auth. Keep working Better Auth, Clerk, Supabase Auth, or another IdP. User asked to migrate from Supabase Auth: Managed Better Auth. A required plugin outside Managed support: self-managed Better Auth on a Neon Function or the existing app host. Also use for auth APIs in @neondatabase/neon-js.
まず最初に: 親スキルの neon を使用して、Neon の概要、利用開始方法、開発のベストプラクティスなどを確認してください。
neon スキルがインストールされていない場合は、以下から取得するか、コマンドでインストールしてください:
neon skills -s neon -y
Neon Auth は「管理型Better Auth（認証サービスの一括管理）」です。ユーザー情報、セッション、認証設定が、ブランチの Lakebase Postgres の neon_auth スキーマに保存され、データベースと一緒にブランチ化されます。クライアント側の API は Better Auth のメソッド（signIn.email、signIn.social、getSession など）で、@neondatabase/auth を通じて利用できます。このラッパーは単独の better-auth/client とは異なり、プラグインのリストが固定され、Neon 独自の OAuth 検証、iframe ポップアップ、JWT 処理が追加されています。Auth が管理型である間は、このラッパーを使い続けてください。
このスキルはまず認証方式を選択し、その後に管理型 Better Auth を導入します。Postgres、Functions、Object Storage、AI Gateway を使うために既存の認証サーバーを置き換えるものではありません。
既存の認証方式と必要なログイン機能を確認してから、導入を進めてください。DATABASE_URL の存在や Neon Function の追加は、認証方式の変更理由にはなりません。
| 状況 | 対応方法 |
|---|---|
| 認証がまだない場合 | 管理型 Better Auth をデフォルトにします。管理型セットアップ、その後 references/managed-auth.md を参照してください。 |
| 管理型にない機能が必要な場合 | 既存のアプリホスト（Vercel など）か Neon Function 上で自管理型 Better Auth を導入します。Lakebase Postgres は変わりません。推奨前に、インストール済みの Better Auth バージョンがそのフローをサポートしているか確認してください。解決しない場合は現在の認証方式を維持します。references/self-managed.md を参照してください。 |
| 既に Better Auth を使用中 | そのまま保持します。他の Neon プリミティブと互換性があります。ユーザーが明示的に要望しない限り、管理型への移行は進めません。 |
| Supabase Auth からの移行を希望 | 管理型 Better Auth を推奨します。Supabase Auth を参照してください。Postgres のみの移行や Function の追加は、この要望ではありません。Supabase Auth を続けてください。 |
| Clerk、Auth.js、Supabase Auth など、既に動作中の認証サービスがある | ユーザーが移行を要望しない限り、保持してください。 |
Google、GitHub、Vercel のソーシャル OAuth は管理型 Auth で提供されます。これらは管理型 Auth を離れる理由にはなりません。その他の OAuth プロバイダー、汎用 OAuth、多要素認証、パスキー、API キー、MCP OAuth、SSO、カスタムプラグイン、フック、カスタム JWT クレーム（トークンに含まれる情報）については、プラグイン対応表を確認してください。
管理型 Auth を有効化する前に、プロジェクトが AWS 上にあり、IP Allow や Private Networking（プライベートネットワーク機能）を使用していないことを確認してください。これらの保護機能は有効なままにしておいてください。
管理型で対応したプラグインは、Neon（コンソール、API、または neon neon-auth コマンド）から設定します。@neondatabase/auth に plugins を渡して設定しないでください。auth: true の有効化だけではログイン機能は実装されません。
neon_auth に保存され、SQL で問い合わせ可能で、RLS（行レベルセキュリティ）に対応しています。auth@mail.myneon.app）を使用します。ログイン機能の実装のために Resend や SendGrid を追加する必要はありません。本番環境ではカスタム SMTP が必要です: https://neon.com/docs/auth/production-checklist.md@neondatabase/auth（認証のみ）または @neondatabase/neon-js/auth（統合 SDK）。オプションの UI：@neondatabase/auth-ui。plugins オプションを受け付けません。プラグイン対応を参照してください。管理型 Better Auth は一般公開中です。AWS リージョンのみ対応しています。IP Allow や Private Networking を使用しているプロジェクトでは有効化できません。
Organization（組織機能）は別途 Partial / Beta の状態です。Neon Function で自管理型 Better Auth をホストするには Functions の利用可能性と要件に従います。neon-functions スキルを参照してください。未クレーム状態（ownership 未確定状態）のプロジェクトでも Auth は有効化できますが、クレーム完了までは Functions は使用できません。
既存の neon.ts に Auth を統合します。他のフィールドは置き換えないでください:
import { defineConfig } from "@neon/config/v1";
export default defineConfig({
auth: true,
});
neon deploy
neon neon-auth status
Function の環境変数が process.env を読む場合は、親スキルの説明通り neon deploy --env <file> を使用してください。手動コマンドは neon neon-auth enable ですが、neon.ts で既に auth: true が宣言されている場合は、enable と deploy の両方を実行しないでください。
次にログイン機能を実装します: references/managed-auth.md。
クレーム可能なプロジェクト：まず親スキルのクレーム手順に従い、その後 ログイン が要望され既存の認証サービスを保持すべきでない場合に auth: true と neon deploy を実行してください。
ユーザーが Supabase Auth からのログイン移行を要望した場合、管理型 Better Auth を推奨し、以下のガイドに従ってください: https://neon.com/docs/auth/migrate/from-supabase.md。Postgres のみの移行や Function の追加はこの要望には該当しません。Supabase Auth を保持してください。
SupabaseAuthAdapter() は signInWithPassword や signInWithOAuth といったメソッド形式を保持します。これらの呼び出しはデフォルトの Better Auth の例（signIn.email）とは互換性がありません。既存のアダプタを使用するコードは、そのまま保持してください。
実際に使用されている認証メソッドとデータベース呼び出しを整理してください:
updateUser() は管理型 Auth でメールやパスワードの変更に対応していません。メール確認にはアプリケーション側で UI が必要です（確認コードは共有 SMTP で動作し、リンクはカスタム SMTP が必要）。@supabase/supabase-js を認証のみに使用している場合、Data API の有効化は不要です。Data API は既存の PostgREST / Supabase データベースクライアント クエリにのみ保持してください。管理型パス：サインアップ、サインイン、サインアウト、再読込み後のセッション復元、保護されたアクセス。エラーと読み込み状態を含めて確認してください。有効になっている場合はメール確認（共有 SMTP のコード）を実施してください。未検証のフローがあれば報告してください。
自管理型パスで必須のプラグインは、管理型フローではなく、そのアプリの Better Auth セットアップで検証されます。
2026-09-17 時点で https://neon.com/docs/auth/guides/plugins.md、https://neon.com/docs/auth/roadmap.md、および @neondatabase/auth クライアントプラグインリストに基づき確認済み。このスキルが古い可能性がある場合はこれらのページを再取得してください。リスト外のアップストリームプラグインは実装検証が必要です。このテーブルに掲載されていないことを、古いロードマップとして扱わないでください。
「非対応」とは、管理型 SDK/UI の契約範囲を指します。すべての生のサーバーリクエストが検証されたわけではありません。
| 機能 | 管理型 Auth | 使用方法 |
|---|---|---|
| メール / パスワード | 対応 | signUp.email、signIn.email |
| ソーシャル OAuth（Google、GitHub、Vercel） | 対応 | signIn.social。共有 Google 認証は開発向け。本番環境および GitHub / Vercel は独自の OAuth アプリが必要です。https://neon.com/docs/auth/guides/setup-oauth.md |
| 管理者 | 対応 | 管理者セッションが必須。プラグインのカスタマイズはロードマップに掲載されています。 |
| メール OTP | 対応 | 管理型配信。emailOtp.sendVerificationOtp、signIn.emailOtp。 |
| マジックリンク | 対応 | ブランチで有効化（デフォルトはオフ）。signIn.magicLink。 |
| Organization（組織） | Partial、Beta | メンバー、招待、オーナー / 管理者 / メンバー。Teams、サーバーフック、カスタムロール / パーミッション、動的アクセス制御はなし。メール招待：managed-auth.md。 |
| JWT | 対応 | EdDSA（Ed25519）、15 分有効期限、カスタムクレーム不可。デフォルトクライアント：.token() その後 data.token。SupabaseAuthAdapter()：getSession() その後 data.session.access_token（.token() なし）。 |
| Open API | 対応 | サーバールート /reference および /open-api/generate-schema。 |
| 電話番号 | 制限付き対応 | ブラウザクライアント：既存ユーザーが電話番号をリンク後にサインイン。電話でのサインアップなし。独自 SMS ウェブフック。カスタム UI 必須。Next.js auth.handler() がキャッチオールパスを転送（電話 OTP 含む）。auth.phoneNumber サーバーメソッドがないことは、型付きヘルパーがない状態であり、プロキシ拒否ではありません。https://neon.com/docs/auth/guides/plugins/phone-number.md |
| 多要素認証 / 二要素認証 | ロードマップ | 管理型 Auth では利用不可。必要な場合：self-managed.md。インストール済み Better Auth バージョンの確認後。 |
| パスキー、API キー、汎用 OAuth、ワンタップ、マルチセッション | 管理型 SDK/UI で非対応 | 必要な場合：self-managed.md。汎用 OAuth は Google / GitHub / Vercel ソーシャルサインインではありません。 |
| MCP / OAuth プロバイダー | 管理型 Auth ではなし | 第三者 MCP |
FIRST: Use the parent neon skill for a Neon overview, getting started with Neon, Neon development best practices, and more.
If the neon skill is not installed, fetch it from https://neon.com/docs/ai/skills/neon/SKILL.md or install it with:
neon skills -s neon -y
Neon Auth is Managed Better Auth: users, sessions, and auth config live in the neon_auth schema on the branch's Lakebase Postgres, and auth state branches with the database. The client API is the Better Auth method set (signIn.email, signIn.social, getSession) through @neondatabase/auth. That wrapper is not a drop-in for bare better-auth/client: it pins the plugin list and adds Neon-specific OAuth verifier, iframe popup, and JWT handling. Stay on the wrapper while Auth is managed.
This skill chooses identity, then implements Managed Better Auth. It does not replace a working auth server in order to use Postgres, Functions, Object Storage, or the AI Gateway.
Inspect existing identity and the required login features before provisioning. A supplied DATABASE_URL is not a reason to change identity. Adding a Neon Function is not a reason to change identity.
| Situation | What to do |
|---|---|
| No existing auth | Default to Managed Better Auth. Managed setup, then references/managed-auth.md. |
| Needs a feature Managed does not offer | Self-managed Better Auth on the existing app host (Vercel or similar) or a Neon Function. Keep Lakebase Postgres. Confirm the installed Better Auth version documents that exact flow before recommending the move. If support stays unresolved, keep the current identity. references/self-managed.md. |
| Already has Better Auth | Keep it. It works with the other Neon primitives. Migrate to Managed only if the user asks. |
| User asked to migrate from Supabase Auth | Managed Better Auth. Supabase Auth. Moving only Postgres or adding a Function keeps Supabase Auth. |
| Clerk, Auth.js, Supabase Auth, or another working IdP | Keep it unless the user asks to migrate. |
Google, GitHub, and Vercel social OAuth are offered on Managed Auth. They are not a reason to leave Managed Auth. Other OAuth providers, generic OAuth, MFA, passkeys, API keys, MCP OAuth, SSO, custom plugins, hooks, and custom JWT claims are the plugin matrix check.
Before enabling Managed Auth, confirm the project is on AWS and does not use IP Allow or Private Networking. Leave those protections in place.
Configure supported Managed plugins through Neon (Console, API, or neon neon-auth), not by passing plugins into @neondatabase/auth. Enabling auth: true is not implementing login.
neon_auth, queryable with SQL, compatible with RLS.auth@mail.myneon.app). You do not add Resend or SendGrid to implement login. Production needs custom SMTP: https://neon.com/docs/auth/production-checklist.md@neondatabase/auth (auth only) or @neondatabase/neon-js/auth (combined SDK). Optional UI: @neondatabase/auth-ui.plugins option. See plugin support.Managed Better Auth is generally available. AWS regions only. It cannot be enabled on a project with IP Allow or Private Networking.
Organization is separately Partial / Beta. Hosting self-managed Better Auth in a Neon Function follows Functions availability and claim rules; use the neon-functions skill for that host. An unclaimed project that can enable Auth still cannot use Functions until claim.
Merge Auth into the existing neon.ts. Do not replace other fields:
import { defineConfig } from "@neon/config/v1";
export default defineConfig({
auth: true,
});
neon deploy
neon neon-auth status
If Function env in that config reads process.env, use neon deploy --env <file> as the parent skill describes. The manual service command is neon neon-auth enable; do not run both enable and deploy as redundant required steps when neon.ts already declares auth: true.
Then implement login: references/managed-auth.md.
Claimable projects: follow the parent Claimable path, then auth: true and neon deploy when login is requested and no existing provider should be preserved.
When the user asked to migrate login from Supabase Auth, recommend Managed Better Auth and follow https://neon.com/docs/auth/migrate/from-supabase.md. Moving only Postgres or adding a Function is not that request: keep Supabase Auth.
SupabaseAuthAdapter() keeps method shapes such as signInWithPassword and signInWithOAuth. Those calls are not interchangeable with default Better Auth examples (signIn.email). Keep an existing adapter caller on that API.
Inventory the auth methods and database calls actually used:
updateUser() cannot change email or password on Managed Auth. Email verification needs application UI (codes work on shared SMTP; links need custom SMTP).@supabase/supabase-js used only for Auth does not justify enabling the Data API. Keep Data API only for existing PostgREST / Supabase database-client queries.Managed path: sign-up, sign-in, sign-out, session restoration after reload, and protected access, including error and loading states. Exercise email verification (code on shared SMTP) when it is on. Report any flow that remains unverified.
A required plugin on the self-managed path is verified in that app's Better Auth setup, not as a Managed flow.
Checked 2026-09-17 against https://neon.com/docs/auth/guides/plugins.md, https://neon.com/docs/auth/roadmap.md, and the @neondatabase/auth client plugin list. Re-fetch those pages if this skill may be stale. An unlisted upstream plugin needs a live check; do not treat absence from this table as a dated roadmap item.
"Not exposed" means the Managed SDK/UI contract. It is not a claim that every raw server request was tested.
| Feature | Managed Auth | Boundary |
|---|---|---|
| Email/password | Supported | signUp.email, signIn.email |
| Social OAuth (Google, GitHub, Vercel) | Supported | signIn.social. Shared Google credentials are for development; production and GitHub/Vercel need your own OAuth apps. https://neon.com/docs/auth/guides/setup-oauth.md |
| Admin | Supported | Admin session required. Plugin customization is on the roadmap. |
| Email OTP | Supported | Managed delivery. emailOtp.sendVerificationOtp, signIn.emailOtp. |
| Magic Link | Supported | Enable on the branch (off by default). signIn.magicLink. |
| Organization | Partial, Beta | Members, invitations, owner/admin/member. No Teams, server hooks, custom roles/permissions, or dynamic access control. Emailed invitations: managed-auth.md. |
| JWT | Supported | EdDSA (Ed25519), 15-minute expiry, no custom claims. Default client: .token() then data.token. SupabaseAuthAdapter(): getSession() then data.session.access_token (no .token()). |
| Open API | Supported | Server routes /reference and /open-api/generate-schema. |
| Phone Number | Supported with constraints | Browser client: existing users link a number, then sign in; no phone-first signup; own SMS webhook; custom UI. Next.js auth.handler() forwards the catch-all path, including phone OTP. A missing auth.phoneNumber server method is a missing typed helper, not a proxy rejection. https://neon.com/docs/auth/guides/plugins/phone-number.md |
| MFA / Two-Factor | Roadmap | Unavailable on Managed Auth. If required: self-managed.md, after confirming the installed Better Auth version. |
| Passkey, API Key, Generic OAuth, One Tap, Multi Session | Not exposed by Managed SDK/UI | If required: self-managed.md. Generic OAuth is not Google/GitHub/Vercel social sign-in. |
| MCP / OAuth Provider | Not Managed Auth | Third-party MCP clients self-authorizing against your server. Keep existing login. See neon-functions references/mcp.md. |
| SSO / SAML | Not listed or exposed | If required: self-managed.md, after confirming the installed Better Auth version. |
The default Managed client method is getAnonymousToken(). That JWT is a Neon anonymous Data API token. It is not Better Auth's Anonymous-account plugin (signIn.anonymous). anonymousTokenClient() is the SDK plugin factory, not a method on the public client. Do not call it, and do not call getAnonymousToken() on SupabaseAuthAdapter().
Trusted domains and webhooks are Neon settings, not installable Better Auth plugins.
Auth redirects only to origins on its allowlist. invalid domain means the app origin is missing. Include the scheme, omit a trailing slash, register production and preview origins before pointing users at them, and target the correct branch:
neon neon-auth domain add https://app.example.com
neon neon-auth domain list
neon neon-auth domain delete https://old.example.com
Localhost ports are pre-approved by default. An existing project can have that off: neon neon-auth domain allow-localhost get|enable|disable. Docs: https://neon.com/docs/auth/guides/configure-domains.md
OAuth provider redirect is {NEON_AUTH_BASE_URL}/callback/{provider} (the Auth URL includes its path). callbackURL on signIn.social is the later app landing origin and must be trusted.
The Managed SDK handles iframe OAuth popup and neon_auth_session_verifier. Keep the wrapper, callback route, and middleware. Do not reimplement that flow, and do not promise third-party cookies in every browser.
A Function authenticates whoever already signs the user in. Do not switch identity to call a Function. Verify the token in the neon-functions skill and https://neon.com/docs/compute/functions/authentication.md.
Managed Auth: injected NEON_AUTH_JWKS_URL, issuer from NEON_AUTH_BASE_URL. Token: default client .token() then data.token; SupabaseAuthAdapter() getSession() then data.session.access_token. A valid token is not permission to read another user's rows. Sign-out ends the browser session; do not claim it immediately revokes an already-issued JWT.
Data API identity: references/managed-auth.md. New apps query Postgres from Functions or existing handlers, not the Data API.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。