Source profileQuality 93/100

agents-inc/skills/src/skills/api-auth-nextauth/SKILL.md

api-auth-nextauth

Auth.js (NextAuth v5) authentication patterns - configuration, providers, session strategies, middleware, database adapters, role-based access, Edge compatibility

Source repository stars
23
Declared platforms
0
Static risk flags
0
Last source update
2026-08-09
Source checked
2026-08-28

Decision brief

What it does: where it fits

Quick Guide: Configure Auth.js in a root auth.ts file exporting { auth, handlers, signIn, signOut } from NextAuth(). Use the unified auth() function everywhere (Server Components, Route Handlers, middleware). Default session strategy is JWT (cookie-based); add a database adapter…

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/agents-inc/skills --skill "src/skills/api-auth-nextauth"
    Safe inspection promptEditorial

    Inspect the Agent Skill "api-auth-nextauth" from https://github.com/agents-inc/skills/blob/81d43a51211aca12c85dcc16085fa99014ec548e/src/skills/api-auth-nextauth/SKILL.md at commit 81d43a51211aca12c85dcc16085fa99014ec548e. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      Basic OAuth Setup

      Why good: Single config file exports all auth utilities, providers auto-detect AUTH env vars, API route is minimal

      Why good: Single config file exports all auth utilities, providers auto-detect AUTH env vars, API route is minimal
    2. 02

      CRITICAL: Before Using This Skill

      All code must follow project conventions in CLAUDE.md (kebab-case, named exports, import ordering, import type, named constants)

      Adding authentication to Next.js, SvelteKit, Express, or Qwik appsImplementing OAuth login (GitHub, Google, Discord, etc.) with 80+ built-in providersBuilding email/magic link authentication flows
    3. 03

      Philosophy

      Auth.js (v5) consolidates authentication into a single, unified API. The auth() function replaces getServerSession, getSession, withAuth, and getToken from v4 for server-side use. useSession() remains the correct client-side API. Configuration lives in a root file, not in API ro…

      Framework-agnostic - Works with Next.js, SvelteKit, Express, QwikUnified API - Single auth() function for all server-side contextsProvider ecosystem - 80+ built-in OAuth providers with auto-detection of AUTH env vars
    4. 04

      Core Patterns

      The central configuration file exports everything you need from NextAuth().

      The central configuration file exports everything you need from NextAuth().Why good: Single config file exports all auth utilities, providers auto-detect AUTH env vars, API route is minimal
    5. 05

      Pattern 1: Auth Configuration

      The central configuration file exports everything you need from NextAuth().

      The central configuration file exports everything you need from NextAuth().Why good: Single config file exports all auth utilities, providers auto-detect AUTH env vars, API route is minimal

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score93/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars23SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    agents-inc/skills
    Skill path
    src/skills/api-auth-nextauth/SKILL.md
    Commit
    81d43a51211aca12c85dcc16085fa99014ec548e
    License
    MIT
    Collected
    2026-08-28
    Default branch
    main
    View the original SKILL.md

    Auth.js (NextAuth v5) Patterns

    Quick Guide: Configure Auth.js in a root auth.ts file exporting { auth, handlers, signIn, signOut } from NextAuth(). Use the unified auth() function everywhere (Server Components, Route Handlers, middleware). Default session strategy is JWT (cookie-based); add a database adapter for persistent sessions. Protect routes via middleware or per-page auth() checks.


    <critical_requirements>

    CRITICAL: Before Using This Skill

    All code must follow project conventions in CLAUDE.md (kebab-case, named exports, import ordering, import type, named constants)

    (You MUST configure Auth.js in a root auth.ts file and export { auth, handlers, signIn, signOut } from NextAuth())

    (You MUST use the unified auth() function for server-side session access - NOT the deprecated getServerSession(), getSession(), or getToken())

    (You MUST use AUTH_SECRET environment variable - NEXTAUTH_SECRET is deprecated in v5)

    (You MUST use AUTH_ prefixed environment variables for provider credentials (e.g., AUTH_GITHUB_ID, AUTH_GITHUB_SECRET) - they are auto-detected)

    (You MUST split auth config into auth.config.ts (Edge-compatible) and auth.ts (with adapter) when using database sessions with middleware)

    (You MUST check session inside Server Actions and API routes - middleware alone is NOT sufficient for authorization)

    </critical_requirements>


    Auto-detection: Auth.js, NextAuth, next-auth, authjs, auth.ts, auth.config.ts, NextAuth(), signIn, signOut, auth(), handlers, SessionProvider, useSession, AUTH_SECRET, OAuth provider, credentials provider, database adapter, @auth/prisma-adapter, @auth/drizzle-adapter, authorized callback, jwt callback, session callback, proxy auth, middleware auth

    When to use:

    • Adding authentication to Next.js, SvelteKit, Express, or Qwik apps
    • Implementing OAuth login (GitHub, Google, Discord, etc.) with 80+ built-in providers
    • Building email/magic link authentication flows
    • Need JWT or database-backed session management
    • Projects requiring Edge-compatible middleware authentication

    When NOT to use:

    • Building a custom auth system from scratch (Auth.js is opinionated)
    • Need fine-grained organization/team management out of the box
    • Mobile-only apps without web frontend
    • Need self-hosted auth with plugin architecture

    Key patterns covered:

    • Auth configuration (auth.ts, auth.config.ts)
    • OAuth providers (GitHub, Google, Credentials, Email)
    • Session strategies (JWT vs database)
    • Session access (Server Components, Route Handlers, Client Components)
    • Middleware/proxy route protection
    • Database adapters (Prisma, Drizzle)
    • Callbacks (jwt, session, signIn, redirect)
    • Role-based access control
    • Edge compatibility split configuration

    Detailed Resources:

    • For decision frameworks and anti-patterns, see reference.md

    Core patterns:


    Philosophy

    Auth.js (v5) consolidates authentication into a single, unified API. The auth() function replaces getServerSession, getSession, withAuth, and getToken from v4 for server-side use. useSession() remains the correct client-side API. Configuration lives in a root file, not in API routes.

    Core principles:

    1. Framework-agnostic - Works with Next.js, SvelteKit, Express, Qwik
    2. Unified API - Single auth() function for all server-side contexts
    3. Provider ecosystem - 80+ built-in OAuth providers with auto-detection of AUTH_* env vars
    4. JWT by default - Stateless sessions in encrypted cookies, no database required
    5. Edge-compatible - Middleware runs on Edge runtime with split configuration (Next.js 16 proxy runs on Node.js)
    6. Progressive complexity - Start with OAuth, add database adapter, then customize callbacks

    Core Patterns

    Pattern 1: Auth Configuration

    The central configuration file exports everything you need from NextAuth().

    Basic OAuth Setup

    // auth.ts
    import NextAuth from "next-auth";
    import GitHub from "next-auth/providers/github";
    import Google from "next-auth/providers/google";
    
    export const { auth, handlers, signIn, signOut } = NextAuth({
      providers: [
        GitHub, // Auto-detects AUTH_GITHUB_ID and AUTH_GITHUB_SECRET
        Google, // Auto-detects AUTH_GOOGLE_ID, AUTH_GOOGLE_SECRET
      ],
    });
    
    // app/api/auth/[...nextauth]/route.ts
    import { handlers } from "@/auth";
    
    export const { GET, POST } = handlers;
    

    Why good: Single config file exports all auth utilities, providers auto-detect AUTH_* env vars, API route is minimal

    Environment Variables

    # .env.local
    AUTH_SECRET="generate-with-npx-auth-secret"  # Required
    AUTH_GITHUB_ID="your-github-client-id"       # Auto-detected by GitHub provider
    AUTH_GITHUB_SECRET="your-github-secret"      # Auto-detected by GitHub provider
    AUTH_GOOGLE_ID="your-google-id"       # Auto-detected by Google provider
    AUTH_GOOGLE_SECRET="your-google-secret"
    

    Why good: AUTH_ prefix is standardized in v5, AUTH_SECRET replaces deprecated NEXTAUTH_SECRET, providers auto-detect credentials


    Pattern 2: Providers

    Auth.js supports OAuth, email/magic link, and credentials authentication. 80+ built-in OAuth providers auto-detect AUTH_* env vars.

    // OAuth: customize profile mapping
    GitHub({
      profile(profile) {
        return {
          id: String(profile.id),
          name: profile.name ?? profile.login,
          role: "user",
        };
      },
    });
    
    // Credentials: validate input, return null on failure
    Credentials({
      async authorize(credentials) {
        const parsed = LoginSchema.safeParse(credentials);
        if (!parsed.success) return null;
        const user = await getUserByEmail(parsed.data.email);
        if (
          !user ||
          !(await verifyPassword(parsed.data.password, user.hashedPassword))
        )
          return null;
        return { id: user.id, name: user.name, email: user.email };
      },
    });
    

    Key rules: Validate input before DB lookup, always hash passwords, return null on failure (never throw - it leaks info). See examples/core.md for complete implementations.


    Pattern 3: Callbacks

    Four callbacks customize auth behavior. Data flows: jwt callback (enrich token) -> session callback (expose to client).

    callbacks: {
      jwt({ token, user }) {
        if (user) { token.id = user.id; token.role = user.role ?? "user"; }
        return token;
      },
      session({ session, token }) {
        session.user.id = token.id as string;
        session.user.role = token.role as string;
        return session;
      },
    }
    

    Key rules: JWT callback runs on EVERY auth() call (keep lightweight), user param is only present at sign-in, never expose OAuth tokens to client. See examples/core.md for complete callback implementations including signIn and redirect.


    Pattern 4: Session Access

    The unified auth() function replaces getServerSession, getSession, and getToken from v4 for server-side use. useSession() remains for Client Components.

    ContextHow to access session
    Server Componentconst session = await auth()
    Route Handlerexport const GET = auth(function GET(req) { req.auth })
    Server Actionconst session = await auth()
    Middleware/Proxyexport { auth as middleware } or authorized callback
    Client ComponentuseSession() (requires SessionProvider in layout)

    Key rules: Server-side imports come from @/auth, client-side imports from next-auth/react. Never call auth() in Client Components. See examples/session.md for complete implementations.


    Pattern 5: Sign In / Sign Out Actions

    Two approaches: Server Actions (recommended, progressive enhancement) or client-side.

    // Server-side (recommended): import from @/auth, use Server Actions in forms
    import { signIn, signOut } from "@/auth";
    // In form action: await signIn("github", { redirectTo: "/dashboard" })
    // In form action: await signOut({ redirectTo: "/" })
    
    // Client-side: import from next-auth/react, use onClick handlers
    import { signIn, signOut } from "next-auth/react";
    // onClick: signIn("github", { callbackUrl: "/dashboard" })
    

    Key rules: Server-side uses redirectTo, client-side uses callbackUrl. signIn() throws a NEXT_REDIRECT exception internally -- don't wrap in try/catch expecting a return value. See examples/core.md for complete implementations.


    Pattern 6: TypeScript Extensions

    Extend session and JWT types via declaration merging in types/next-auth.d.ts. Declare custom fields (e.g., id, role) on Session, User, and JWT interfaces using & DefaultSession["user"] to preserve defaults. See examples/core.md for the complete type declaration example.


    Integration Guide

    Auth.js is the authentication layer. It handles identity verification, session management, and route protection. It does NOT handle authorization logic (role checks, permission systems) -- that is application code.

    Framework support: Auth.js works with multiple web frameworks via framework-specific packages (next-auth, @auth/sveltekit, @auth/express).

    Database adapters: For database sessions, Auth.js provides adapter packages (@auth/prisma-adapter, @auth/drizzle-adapter, etc.) that integrate with your ORM. See examples/database.md.

    Session strategy depends on your needs:

    • JWT (default) - No database needed, works on Edge, stateless
    • Database - Requires adapter, server-side session store, supports immediate revocation

    Auth.js does NOT handle: fine-grained authorization/RBAC, rate limiting, or database queries beyond auth -- those are application-level concerns.


    <red_flags>

    RED FLAGS

    • Using getServerSession(authOptions) -- deprecated in v5; use auth() from your auth.ts
    • Using NEXTAUTH_SECRET or NEXTAUTH_URL -- deprecated; use AUTH_SECRET (URL is auto-detected)
    • Credentials provider without rate limiting -- vulnerable to brute-force attacks
    • Exposing OAuth tokens to client via session callback -- keep accessToken/refreshToken server-side only
    • Middleware/proxy as sole authorization -- runs before rendering but does not replace per-route checks in Server Actions/API routes
    • Database adapter imported in middleware -- database ORMs can't run on Edge runtime (Next.js 14/15); split config into auth.config.ts + auth.ts
    • Wrapping signIn() in try/catch -- it throws a NEXT_REDIRECT exception internally (this is intentional)
    • JWT callback querying database on every call -- runs on EVERY auth() invocation; keep it lightweight

    See reference.md for the complete anti-pattern list, gotchas, and migration table.

    </red_flags>


    <critical_reminders>

    CRITICAL REMINDERS

    All code must follow project conventions in CLAUDE.md

    (You MUST configure Auth.js in a root auth.ts file and export { auth, handlers, signIn, signOut } from NextAuth())

    (You MUST use the unified auth() function for server-side session access - NOT the deprecated getServerSession(), getSession(), or getToken())

    (You MUST use AUTH_SECRET environment variable - NEXTAUTH_SECRET is deprecated in v5)

    (You MUST use AUTH_ prefixed environment variables for provider credentials (e.g., AUTH_GITHUB_ID, AUTH_GITHUB_SECRET) - they are auto-detected)

    (You MUST split auth config into auth.config.ts (Edge-compatible) and auth.ts (with adapter) when using database sessions with middleware)

    (You MUST check session inside Server Actions and API routes - middleware alone is NOT sufficient for authorization)

    Failure to follow these rules will cause authentication failures, expose deprecated patterns, or create security vulnerabilities.

    </critical_reminders>

    Frequently asked questions

    What to verify before installation and use

    What does the api-auth-nextauth source document cover?

    Quick Guide: Configure Auth.js in a root auth.ts file exporting { auth, handlers, signIn, signOut } from NextAuth(). Use the unified auth() function everywhere (Server Components, Route Handlers, middleware). Default session strategy is JWT (cookie-based); add a database adapter…

    How do I install api-auth-nextauth?

    The source record exposes this install command: npx skills add https://github.com/agents-inc/skills --skill "src/skills/api-auth-nextauth". Inspect the command and pinned source before running it.

    Alternatives

    Compare before choosing

    Computed 10045,960

    coreyhaines31/marketingskills

    ab-testing

    When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

    Computed 10029,236

    garrytan/gbrain

    bulk-ingestion

    End-to-end discipline for turning any large data source (audio libraries, email takeouts, document corpora, chat exports, API dumps) into brain pages at scale. The lifecycle spine: SCHEMA → ACCESS → TRIAL → EVALUATE → IMPROVE → CODIFY → TEST → SKILLIFY → BULK → MONITOR. State is tracked in a durable JSON manifest (see MANIFEST-PATTERN.md) so any crash, session boundary, or subagent fan-out resumes from ground truth instead of memory.

    Computed 10025,136

    alirezarezvani/claude-skills

    app-store-optimization

    App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist

    Computed 1005,277

    dotnet/skills

    migrate-vstest-to-mtp

    Migrates .NET test projects from VSTest to Microsoft.Testing.Platform (MTP). Use when user asks to "migrate to MTP", "switch from VSTest", "enable Microsoft.Testing.Platform", "use MTP runner", set OutputType=Exe only for test projects in Directory.Build.props, or mentions EnableMSTestRunner, EnableNUnitRunner, or UseMicrosoftTestingPlatformRunner. USE FOR: MTP behavioral differences vs VSTest (exit code 8, zero tests discovered, --ignore-exit-code, TESTINGPLATFORM_EXITCODE_IGNORE); centralizing