D'ABORD : Utilisez la skill parent neon pour un aperçu de Neon, pour débuter avec Neon, les bonnes pratiques de développement Neon, et bien d'autres.

Si la skill neon n'est pas installée, récupérez-la depuis https://neon.com/docs/ai/skills/neon/SKILL.md ou installez-la avec :

neon skills -s neon -y

Neon Auth

Neon Auth est Better Auth Managed : les utilisateurs, sessions et configuration d'auth vivent dans le schéma neon_auth sur la Postgres Lakebase de la branche, et l'état d'auth évolue avec la base de données. L'API client est l'ensemble des méthodes Better Auth (signIn.email, signIn.social, getSession) via @neondatabase/auth. Ce wrapper n'est pas un remplacement clé-en-main pour better-auth/client : il verrouille la liste des plugins et ajoute le vérificateur OAuth, la popup iframe et la gestion JWT spécifiques à Neon. Restez sur le wrapper tant qu'Auth est géré.

Cette skill choisit l'identité, puis implémente Better Auth Managed. Elle ne remplace pas un serveur d'auth fonctionnant pour utiliser Postgres, Functions, Object Storage ou AI Gateway.

Quand l'utiliser

Inspectez l'identité existante et les fonctionnalités de connexion requises avant de provisionner. Une DATABASE_URL fournie n'est pas une raison de changer d'identité. Ajouter une Neon Function n'est pas une raison de changer d'identité.

Google, GitHub et Vercel social OAuth sont proposés sur Managed Auth. Ce n'est pas une raison de quitter Managed Auth. Les autres fournisseurs OAuth, OAuth générique, MFA, passkeys, clés API, MCP OAuth, SSO, plugins personnalisés, hooks et revendications JWT personnalisées sont la vérification de la matrice de plugins.

Avant d'activer Managed Auth, confirmez que le projet est sur AWS et n'utilise pas IP Allow ou Private Networking. Laissez ces protections en place.

Configurez les plugins Managed supportés via Neon (Console, API ou neon neon-auth), pas en passant plugins dans @neondatabase/auth. Activer auth: true n'implémente pas la connexion.

Ce qu'il fait

• Identité gérée dans Postgres — utilisateurs et sessions dans neon_auth, interrogeables en SQL, compatibles avec RLS.
• Emails d'auth sans mailer d'app — vérification, email OTP, magic links et réinitialisation de mot de passe. Pour débuter, utilisez SMTP partagé (auth@mail.myneon.app). Vous n'ajoutez pas Resend ou SendGrid pour implémenter la connexion. La production nécessite SMTP personnalisé : https://neon.com/docs/auth/production-checklist.md
• Branches avec la base de données — chaque branche a son URL Auth et son état d'auth isolé.
• Méthodes client Better Auth via SDK Neon — @neondatabase/auth (auth uniquement) ou @neondatabase/neon-js/auth (SDK combiné). UI optionnelle : @neondatabase/auth-ui.
• Ensemble de plugins fixe — le client Managed n'accepte pas l'option plugins. Voir plugin support.

Disponibilité

Better Auth Managed est généralement disponible. Régions AWS uniquement. Elle ne peut pas être activée sur un projet avec IP Allow ou Private Networking.

Organization est séparément Partial / Beta. L'hébergement de Better Auth auto-géré dans une Neon Function suit la disponibilité de Functions et les règles de claim ; utilisez la skill neon-functions pour cet hébergement. Un projet non révendiqué qui peut activer Auth ne peut toujours pas utiliser Functions jusqu'à révendication.

Setup Managed

Fusionnez Auth dans le neon.ts existant. Ne remplacez pas d'autres champs :

import { defineConfig } from "@neon/config/v1";

export default defineConfig({
  auth: true,
});

neon deploy
neon neon-auth status

Si Function env dans cette config lit process.env, utilisez neon deploy --env <file> comme le décrit la skill parent. La commande de service manuelle est neon neon-auth enable ; ne lancez pas à la fois enable et deploy comme étapes redondantes requises quand neon.ts déclare déjà auth: true.

Implémentez ensuite la connexion : references/managed-auth.md.

Projets révendicables : suivez le chemin Claimable parent, puis auth: true et neon deploy quand la connexion est demandée et aucun fournisseur existant ne doit être conservé.

Supabase Auth

Quand l'utilisateur a demandé de migrer la connexion depuis Supabase Auth, recommandez Better Auth Managed et suivez https://neon.com/docs/auth/migrate/from-supabase.md. Migrer seulement Postgres ou ajouter une Function n'est pas cette demande : conservez Supabase Auth.

SupabaseAuthAdapter() conserve les formes de méthodes telles que signInWithPassword et signInWithOAuth. Ces appels ne sont pas interchangeables avec les exemples Better Auth par défaut (signIn.email). Gardez un appelant d'adaptateur existant sur cette API.

Inventoriez les méthodes d'auth et les appels de base de données réellement utilisés :

• Les hashes de mot de passe ne peuvent pas être transférés. Les utilisateurs créent de nouveaux comptes ou se connectent via OAuth.
• Ne promettez pas des IDs utilisateur, sessions ou account linking inchangés. Planifiez les clés étrangères d'application avec le propriétaire.
• updateUser() ne peut pas changer l'email ou le mot de passe sur Managed Auth. La vérification d'email nécessite une UI d'application (les codes fonctionnent sur SMTP partagé ; les liens nécessitent SMTP personnalisé).
• Le guide de migration liste Supabase phone/SMS/WhatsApp, SAML et Web3 comme non supportés sur Managed Auth. Confirmez la version installée de Better Auth si l'utilisateur a toujours besoin de ce flux exact ; si le support reste non résolu, conservez Supabase Auth et arrêtez la transition d'auth. La revendication « no phone auth » de cette page concerne Supabase phone sign-in, pas le plugin Phone Number Managed contraint (les utilisateurs existants lient un numéro).
• @supabase/supabase-js utilisé uniquement pour Auth ne justifie pas l'activation de Data API. Conservez Data API seulement pour les requêtes existantes PostgREST / client de base de données Supabase.

Vérification

Chemin Managed : inscription, connexion, déconnexion, restauration de session après rechargement et accès protégé, incluant les états d'erreur et de chargement. Testez la vérification d'email (code sur SMTP partagé) quand elle est activée. Signalez tout flux qui reste non vérifié.

Un plugin requis sur le chemin auto-géré est vérifié dans le setup Better Auth de cette app, non comme un flux Managed.

Plugin support

Vérifié 2026-09-17 contre https://neon.com/docs/auth/guides/plugins.md, https://neon.com/docs/auth/roadmap.md et la liste des plugins client @neondatabase/auth. Re-récupérez ces pages si cette skill peut être obsolète. Un plugin amont non listé nécessite une vérification en direct ; ne traitez pas l'absence de ce tableau comme un élément de feuille de route dépassé.

« Non exposé » signifie le contrat Managed SDK/UI. Ce n'est pas une affirmation que chaque requête serveur brut a été testée.

La méthode client Managed par défaut est getAnonymousToken(). Ce JWT est un token Data API Neon anonyme. Ce n'est pas le plugin Anonymous-account de Better Auth (signIn.anonymous). anonymousTokenClient() est la fabrique de plugin SDK, pas une méthode sur le client public. Ne l'appelez pas et n'appelez pas getAnonymousToken() sur SupabaseAuthAdapter().

Les domaines de confiance et webhooks sont des paramètres Neon, pas des plugins Better Auth installables.

Domaines de confiance

Auth redirige uniquement vers les origines sur sa liste d'autorisation. invalid domain signifie que l'origine de l'app est manquante. Incluez le schéma, omettez une barre oblique finale, enregistrez les origines de production et d'aperçu avant de pointer les utilisateurs vers elles, et ciblez la branche correcte :

neon neon-auth domain add https://app.example.com
neon neon-auth domain list
neon neon-auth domain delete https://old.example.com

Les ports localhost sont pré-approuvés par défaut. Un projet existant peut avoir ça désactivé : neon neon-auth domain allow-localhost get|enable|disable. Docs : https://neon.com/docs/auth/guides/configure-domains.md

OAuth provider redirect est {NEON_AUTH_BASE_URL}/callback/{provider} (l'Auth URL inclut son chemin). callbackURL sur signIn.social est l'origine d'arrivée ultérieure de l'app et doit être de confiance.

Le SDK Managed gère la popup OAuth iframe et neon_auth_session_verifier. Conservez le wrapper, la route de callback et le middleware. Ne réimplémentez pas ce flux et ne promettez pas les cookies tiers dans tous les navigateurs.

Functions et Data API

Une Function authentifie quiconque signe déjà l'utilisateur. Ne changez pas d'identité pour appeler une Function. Vérifiez le token dans la skill neon-functions et https://neon.com/docs/compute/functions/authentication.md.

Managed Auth : NEON_AUTH_JWKS_URL injecté, issuer de NEON_AUTH_BASE_URL. Token : client par défaut .token() puis data.token ; SupabaseAuthAdapter() getSession() puis data.session.access_token. Un token valide n'est pas la permission de lire les lignes d'un autre utilisateur. La déconnexion termine la session navigateur ; ne prétendez pas qu'elle révoque immédiatement un JWT déjà émis.

Identité Data API : references/managed-auth.md. Les nouvelles apps interrogent Postgres depuis Functions ou des handlers existants, pas depuis Data API.