What this prompt does
This prompt makes the AI set up Auth.js v5 in a Next.js 15 App Router app, returning working code and real file paths. You provide the [app_name], the [oauth_providers], the [database], and the [session_strategy]. It produces an auth.ts config with a credentials provider using secure password hashing plus your OAuth providers, the Prisma adapter wired to your database with the required Auth.js models, session handling with callbacks attaching user id and role, a middleware.ts protecting routes, server actions for sign-in/out and registration, and a protected server component example.
The structure works because Auth.js v5 changed enough that stale tutorials waste time, so a clean baseline matters. [oauth_providers] decides which social logins are registered alongside credentials, [database] drives the Prisma adapter and schema models, and [session_strategy] (JWT or database) shapes the session callbacks and how the user id and role are attached. The middleware deliverable is where you lock down which routes require auth.
When to use it
- You're adding auth to a Next.js 15 App Router app and want a current v5 baseline.
- You need credentials login plus social OAuth working the same day.
- You're using Prisma and want the adapter and required models wired correctly.
- You need session callbacks that attach the user id and role.
- You want middleware protecting authenticated routes with clean redirects.
- You keep losing time to outdated Auth.js tutorials that no longer apply.
Example output
You get auth.ts, middleware.ts, the server actions, and the env vars [app_name] needs: an auth.ts registering a credentials provider with bcrypt or argon2 hashing plus [oauth_providers]; the Prisma adapter wired to [database] with the required Auth.js schema models; session handling using the [session_strategy] strategy, including callbacks that attach the user id and role; a middleware.ts protecting authenticated routes and redirecting unauthenticated users; server actions for sign-in, sign-out, and registration with validation; and a protected server component example reading the session.
Pro tips
- Lock down the
middleware.tsmatcher early, before you scatter protected routes everywhere — a loose matcher either leaves pages unguarded or redirects pages it shouldn't. - Set
[oauth_providers]to exactly the ones you'll configure, since each needs its own client id and secret in the env vars the prompt lists. - Match
[database]to your real database so the Prisma adapter and schema models fit; the required Auth.js models differ subtly by store. - Choose
[session_strategy]deliberately — JWT avoids a session table read per request, while database sessions are easier to revoke; the callbacks differ between them. - Verify the credentials provider uses a strong hash (bcrypt or argon2) and never logs the raw password during sign-in.
- Ask a follow-up to add role-based route protection if you need more than authenticated-versus-not, since the base middleware focuses on authentication.