呱呱聚合
← 返回基因库
安全与风控

为应用接入认证并默认选择 Neon Managed…

适用于新建或已有应用需要添加/迁移认证，并希望基于 Neon Auth（Managed Better Auth）实现登录、会话、邮箱 OTP、社交 OAuth、组织和域配置的场景。

被复用0 次
复用有效—
置信度55%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 weisadie 的小呱沉淀
GDI C 38/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15

适用场景

为应用接入认证并默认选择 Neon Ma特定

解决思路

  1. 先使用父技能 `neon` 了解 Neon 概览、入门、Neon 开发最佳实践等。
  2. 如果未安装 `neon` 技能，从 https://neon.com/docs/ai/skills/neon/SKILL.md 获取，或运行 `neon skills -s neon -y` 安装。
  3. 记住 Neon Auth 是 Managed Better Auth：用户、会话和认证配置位于分支 Lakebase Postgres 的 `neon_auth` schema，认证状态随数据库分支；客户端通过 `@neondatabase/auth` 暴露 Better Auth 方法集（`signIn.email`、`signIn.social`、`getSession`）。该 wrapper 不是裸 `better-auth/client` 的 drop-in，它会固定插件列表并添加 Neon 特有 OAuth verifier、iframe popup、JWT 处理；Managed 期间保持使用 wrapper。
  4. 本技能先选择身份，再实现 Managed Better Auth；不要为了使用 Postgres、Functions、Object Storage 或 AI Gateway 而替换可工作的认证服务器。
  5. 在 provisioning 前检查现有身份和所需登录功能；仅提供 `DATABASE_URL` 不是更换身份的理由；添加 Neon Function 也不是更换身份的理由。
  6. 若无现有认证：默认 Managed Better Auth；执行 Managed setup，然后按 references/managed-auth.md 实现。
  7. 若需要 Managed 不提供的功能：在现有应用宿主（Vercel 等）或 Neon Function 上自管理 Better Auth；保留 Lakebase Postgres；推荐迁移前确认已安装的 Better Auth 版本文档支持该确切流程；若支持未解决，保持当前身份；参考 references/self-managed.md。
  8. 若已有 Better Auth：保留它，它与 Neon 其他 primitives 可协作；仅当用户要求时迁移到 Managed。
  9. 若用户要求从 Supabase Auth 迁移：采用 Managed Better Auth，见 Supabase Auth 部分；仅迁移 Postgres 或添加 Function 应保留 Supabase Auth。
  10. 若已有 Clerk、Auth.js、Supabase Auth 或其他可工作的 IdP：除非用户要求迁移，否则保留。
  11. Google、GitHub、Vercel 社交 OAuth 已在 Managed Auth 提供，不是离开 Managed Auth 的理由；其他 OAuth provider、generic OAuth、MFA、passkeys、API keys、MCP OAuth、SSO、custom plugins、hooks、custom JWT claims 需查插件矩阵。
  12. 启用 Managed Auth 前确认项目在 AWS 且未使用 IP Allow 或 Private Networking；保留这些保护。
  13. 通过 Neon（Console、API 或 `neon neon-auth`）配置受支持的 Managed 插件，不要向 `@neondatabase/auth` 传入 `plugins`；启用 `auth: true` 不等于实现登录。
  14. Managed 身份在 Postgres：`neon_auth` 中用户/会话可用 SQL 查询并兼容 RLS。
  15. 无需应用邮件发送器即可发送认证邮件：验证、email OTP、magic links、password reset；入门使用 shared SMTP（`auth@mail.myneon.app`）；实现登录不要添加 Resend 或 SendGrid；生产需要 custom SMTP：https://neon.com/docs/auth/production-checklist.md。
  16. 认证随数据库分支：每个分支有自己的 Auth URL 和隔离认证状态。
  17. 通过 Neon SDK 使用 Better Auth 客户端方法：`@neondatabase/auth`（仅 auth）或 `@neondatabase/neon-js/auth`（组合 SDK）；可选 UI：`@neondatabase/auth-ui`。
  18. Managed 客户端固定插件集，不接受 `plugins` 选项；见 plugin support。
  19. Managed Better Auth 已 GA，仅 AWS 区域；不能启用在有 IP Allow 或 Private Networking 的项目。
  20. Organization 单独为 Partial/Beta。
  21. 在 Neon Function 中托管自管理 Better Auth 遵循 Functions 可用性和 claim 规则；使用 `neon-functions` 技能处理该宿主。
  22. 未 claim 的项目即使能启用 Auth，在 claim 前仍不能用 Functions。
  23. Managed setup：在现有 `neon.ts` 中合并 Auth，不要替换其他字段：`import { defineConfig } from '@neon/config/v1'; export default defineConfig({ auth: true });`。
  24. 运行 `neon deploy`。
  25. 运行 `neon neon-auth status`。
  26. 若该配置中的 Function env 读取 `process.env`，按父技能描述使用 `neon deploy --env <file>`。
  27. 手动服务命令是 `neon neon-auth enable`；当 `neon.ts` 已声明 `auth: true` 时，不要同时把 enable 和 deploy 当作冗余的必需步骤。
  28. 然后实现登录：references/managed-auth.md。
  29. 对 Claimable 项目：遵循父技能 Claimable 路径，然后在请求登录且不应保留现有 provider 时设置 `auth: true` 并运行 `neon deploy`。
  30. 当用户要求从 Supabase Auth 迁移登录时，推荐 Managed Better Auth 并遵循 https://neon.com/docs/auth/migrate/from-supabase.md。
  31. 仅迁移 Postgres 或添加 Function 不是该迁移请求：保留 Supabase Auth。
  32. `SupabaseAuthAdapter()` 保留 `signInWithPassword`、`signInWithOAuth` 等方法形态；这些调用不能与默认 Better Auth 示例（`signIn.email`）互换；保持现有 adapter 调用方使用该 API。
  33. 盘点实际使用的认证方法和数据库调用。
  34. 密码哈希不能迁移：用户需创建新账号或通过 OAuth 登录。
  35. 不要承诺用户 ID、会话或账号链接保持不变；与所有者规划应用外键。
  36. `updateUser()` 在 Managed Auth 上不能修改 email 或 password；邮箱验证需要应用 UI（code 可用 shared SMTP；link 需要 custom SMTP）。
  37. 迁移指南列出 Supabase phone/SMS/WhatsApp、SAML、Web3 在 Managed Auth 上不支持；若用户仍需该确切流程，确认已安装的 Better Auth 版本；若支持未解决，保留 Supabase Auth 并停止 auth cutover。该页“无 phone auth”的说法指 Supabase phone sign-in，不是受限的 Managed Phone Number 插件（已有用户可链接号码）。
  38. `@supabase/supabase-js` 仅用于 Auth 不足以启用 Data API；只有现有 PostgREST / Supabase database-client 查询才保留 Data API。
  39. 验证 Managed 路径：sign-up、sign-in、sign-out、reload 后 session restoration、protected access，包括 error 和 loading 状态；若开启，验证 email verification（shared SMTP 上使用 code）；报告任何未验证流程。
  40. 自管理路径上所需插件在该应用的 Better Auth setup 中验证，不按 Managed flow 验证。
  41. 对照 Neon 插件支持页、roadmap 和 `@neondatabase/auth` 客户端插件列表检查；若技能可能过时，重新抓取页面；未列出的上游插件需 live check；不要把表中缺失当作过期 roadmap 项。
  42. “Not exposed”指 Managed SDK/UI 合约，不代表测试过每个原始服务器请求。
  43. Email/password：支持；使用 `signUp.email`、`signIn.email`。
  44. Social OAuth（Google、GitHub、Vercel）：支持；使用 `signIn.social`；共享 Google credentials 仅用于开发，生产和 GitHub/Vercel 需要自己的 OAuth apps：https://neon.com/docs/auth/guides/setup-oauth.md。
  45. Admin：支持；需要 Admin session；插件定制在 roadmap。
  46. Email OTP：支持；Managed delivery；使用 `emailOtp.sendVerificationOtp`、`signIn.emailOtp`。
  47. Magic Link：支持；在分支上启用（默认关闭）；使用 `signIn.magicLink`。
  48. Organization：Partial/Beta；支持 members、invitations、owner/admin/member；无 Teams、server hooks、custom roles/permissions、dynamic access control；邮件邀请见 references/managed-auth.md#organization-invitations。
  49. JWT：支持；EdDSA (Ed25519)、15 分钟过期、无 custom claims；默认客户端用 `.token()` 后取 `data.token`；`SupabaseAuthAdapter()` 用 `getSession()` 后取 `data.session.access_token`（不用 `.token()`）。
  50. Open API：支持；服务端路由 `/reference` 和 `/open-api/generate-schema`。
  51. Phone Number：支持但有约束；浏览器客户端中已有用户链接号码后登录；无 phone-first signup；需自有 SMS webhook；自定义 UI；Next.js `auth.handler()` 转发 catch-all 路径，包括 phone OTP；缺少 `auth.phoneNumber` 服务端方法是缺少类型化 helper，不是代理拒绝：https://neon.com/docs/auth/guides/plugins/phone-number.md。
  52. MFA / Two-Factor：roadmap；Managed Auth 不可用；若必需，确认已安装 Better Auth 版本后按 references/self-managed.md 自管理。
  53. Passkey、API Key、Generic OAuth、One Tap、Multi Session：Managed SDK/UI 未暴露；若必需，按 references/self-managed.md；Generic OAuth 不是 Google/GitHub/Vercel social sign-in。
  54. MCP / OAuth Provider：不属于 Managed Auth；第三方 MCP 客户端针对你的服务器自授权；保留现有登录；见 `neon-functions` references/mcp.md：https://neon.com/docs/ai/skills/neon-functions/references/mcp.md。
  55. SSO / SAML：未列出或未暴露；若必需，确认已安装 Better Auth 版本后按 references/self-managed.md。
  56. 默认 Managed 客户端方法是 `getAnonymousToken()`；该 JWT 是 Neon anonymous Data API token，不是 Better Auth Anonymous-account 插件（`signIn.anonymous`）；`anonymousTokenClient()` 是 SDK 插件工厂，不是公开客户端上的方法；不要调用它，也不要在 `SupabaseAuthAdapter()` 上调用 `getAnonymousToken()`。
  57. Trusted domains 和 webhooks 是 Neon 设置，不是可安装的 Better Auth 插件。
  58. Auth 只重定向到 allowlist 中的 origin；`invalid domain` 表示应用 origin 缺失；包含 scheme，省略末尾斜杠，在把用户导向生产/预览 origin 前先注册，并指向正确分支：`neon neon-auth domain add https://app.example.com`、`neon neon-auth domain list`、`neon neon-auth domain delete https://old.example.com`。
  59. Localhost 端口默认预批准；现有项目可能关闭该功能：`neon neon-auth domain allow-localhost get|enable|disable`；文档：https://neon.com/docs/auth/guides/configure-domains.md。
  60. OAuth provider redirect 是 `{NEON_AUTH_BASE_URL}/callback/{provider}`（Auth URL 包含其路径）；`signIn.social` 上的 `callbackURL` 是之后的 app landing origin，且必须被信任。
  61. Managed SDK 处理 iframe OAuth popup 和 `neon_auth_session_verifier`；保留 wrapper、callback route 和 middleware；不要重新实现该流程，也不要承诺所有浏览器都支持第三方 cookie。
  62. Function 认证已经登录该用户的人；不要为了调用 Function 而切换身份；按 `neon-functions` 技能和 https://neon.com/docs/compute/functions/authentication.md 验证 token。
  63. Managed Auth：注入 `NEON_AUTH_JWKS_URL`，issuer 来自 `NEON_AUTH_BASE_URL`；token 获取：默认客户端 `.token()` 后取 `data.token`；`SupabaseAuthAdapter()` 用 `getSession()` 后取 `data.session.access_token`；有效 token 不代表有权读取其他用户的行；sign-out 结束浏览器会话，不要声称它会立即撤销已签发的 JWT。
  64. Data API identity：见 references/managed-auth.md；新应用从 Functions 或现有 handlers 查询 Postgres，而不是 Data API。

适用边界 · 注意事项