## Authentication in Next.js Authentication is one of those topics that looks simple at first: ```text User enters email ↓ User logs in ↓ Done ``` Then you actually build it and suddenly you're dealing with: ```text Cookies Sessions OAuth JWTs Password hashing Callbacks Protected routes Server Components Client Components CSRF Authorization ``` and your "simple login page" has become a small cybersecurity course. 😭 [Next.js](/courses/nextjs) makes authentication especially interesting because your application runs across two environments: ```text SERVER + BROWSER ``` Some authentication work should happen securely on the server. Other parts, such as showing the currently logged-in user inside an interactive navbar, may need client-side state. That's why choosing the right authentication architecture matters. --- # Common Authentication Options There are several popular ways to add authentication to a [Next.js](/courses/nextjs) application. ### Auth.js Previously known as: ```text NextAuth.js ``` Auth.[js](/courses/javascript) is an open-source authentication library with strong Next.js integration. It supports: - Google login - GitHub login - OAuth providers - Credentials - JWT sessions - Database sessions - Server-side authentication - Client-side session [hooks](/courses/reactjs/chapter-11-advanced-hooks-useref-usereducer-usememo-usecallback) This chapter focuses on **Auth.[js](/courses/javascript)**. --- ### Clerk Clerk is a hosted authentication platform that provides ready-made UI components such as: ```jsx ``` and: ```jsx ``` It's useful when you want authentication infrastructure and UI managed for you. --- ### Supabase Auth Supabase Auth is another strong option, especially if your application already uses: ```text Supabase Database Supabase Storage Supabase Backend ``` --- # Auth.js vs NextAuth.js You'll see both names online. Historically, the library was called: ```text NextAuth.js ``` The broader project is now called: ```text Auth.js ``` But the Next.js package is still: ```text next-auth ``` So don't get confused when you see: ```bash npm install next-auth@beta ``` inside an Auth.js tutorial. They're talking about the same Next.js authentication ecosystem. --- # Authentication vs Authorization Before going further, let's separate two concepts. ### Authentication Authentication asks: > "Who are you?" Example: ```text Email + Password Google Login GitHub Login Session Cookie ``` --- ### Authorization Authorization asks: > "What are you allowed to do?" Example: ```text User ↓ Can view dashboard Admin ↓ Can delete users Editor ↓ Can edit articles ``` You usually authenticate first. Then authorize. Think: ```text Authentication ↓ Who is this user? Authorization ↓ What can this user do? ``` Very important distinction. --- # What Is a Session? After a user successfully logs in, your application needs some way to remember: ```text "This request belongs to Asif." ``` Otherwise the user would need to log in again on every page. That's what a **session** solves. Conceptually: ```text User logs in ↓ Server verifies identity ↓ Session created ↓ Browser receives secure cookie ↓ Future requests include cookie ↓ Server recognizes user ``` --- # JWT Sessions vs Database Sessions Auth.js supports different session strategies. Two important ones are: ```text JWT Sessions ``` and: ```text Database Sessions ``` --- ## JWT Session JWT stands for: **JSON Web Token** A token contains information representing the session. Conceptually: ```text User logs in ↓ Auth.js creates token ↓ Token associated with secure cookie ↓ Browser sends cookie on requests ↓ Server validates session ``` --- > **Definition: JSON Web Token** > > A JWT is a compact token format used to represent claims between systems. Authentication libraries can use JWT-based sessions to identify users without requiring a database lookup for every session check. --- # Database Sessions Auth.js can also store session information in a database. Conceptually: ```text Browser cookie ↓ Session identifier ↓ Database ↓ Session record ↓ User ``` This can be useful when you need stronger control over active sessions. For example: ```text Log user out from all devices Invalidate a specific session Track active sessions ``` So don't think: ```text Auth.js = JWT only ``` It supports both approaches depending on your configuration. --- # 1. Install Auth.js For the current Auth.js v5 Next.js setup, install: ```bash npm install next-auth@beta ``` Once installed, you'll configure authentication inside your project. --- # Generate `AUTH_SECRET` Auth.js requires a secure secret. You can generate one using: ```bash npm exec auth secret ``` This creates a cryptographically secure value for: ```text AUTH_SECRET ``` Your environment file might look like: ```env AUTH_SECRET="your-generated-secret" ``` Never write something like: ```env AUTH_SECRET="123456" ``` That's not a secret. That's a suggestion. 💀 --- # What Is `AUTH_SECRET` Used For? Auth.js uses the secret for security-sensitive operations involving things such as tokens and authentication data. The important rule is: ```text AUTH_SECRET = PRIVATE SERVER SECRET ``` Never expose it using: ```text NEXT_PUBLIC_ ``` So this would be catastrophic: ```env NEXT_PUBLIC_AUTH_SECRET="..." ``` Because: ```text NEXT_PUBLIC_ ``` literally means: > "Please send this to the browser." Not ideal for a secret. 😭 --- # OAuth Provider Credentials Suppose we're using GitHub authentication. You'll create OAuth credentials inside GitHub and receive: ```text Client ID Client Secret ``` Auth.js recommends environment variables following this pattern: ```text AUTH_[PROVIDER]_ID AUTH_[PROVIDER]_SECRET ``` For GitHub: ```env AUTH_GITHUB_ID="your-github-client-id" AUTH_GITHUB_SECRET="your-github-client-secret" ``` For Google: ```env AUTH_GOOGLE_ID="your-google-client-id" AUTH_GOOGLE_SECRET="your-google-client-secret" ``` Auth.js can automatically detect these naming conventions. That means less configuration code. Nice. --- # 2. Create the Main Auth Configuration Create: ```text src/auth.js ``` or, with [TypeScript](/courses/typescript): ```text src/auth.ts ``` A minimal GitHub configuration looks like: ```js import NextAuth from "next-auth" import GitHub from "next-auth/providers/github" export const { handlers, auth, signIn, signOut } = NextAuth({ providers: [ GitHub ], }) ``` That's surprisingly small. The environment variables: ```env AUTH_GITHUB_ID AUTH_GITHUB_SECRET ``` can be detected automatically. --- # What Does `NextAuth()` Return? This part is important. ```js NextAuth({ providers: [...] }) ``` returns several useful helpers: ```js handlers auth signIn signOut ``` Think: ```text handlers ↓ HTTP authentication endpoints ``` ```text auth ↓ Read authentication/session information ``` ```text signIn ↓ Start login ``` ```text signOut ↓ Log user out ``` You'll reuse these throughout your application. --- # 3. The Authentication Route Handler Auth.js needs HTTP endpoints for things such as: - Sign in - Sign out - OAuth callbacks - Session requests - Provider callbacks You don't create every endpoint manually. Auth.js handles them. Create: ```text src/app/api/auth/[...nextauth]/route.js ``` Then: ```js import { handlers } from "@/auth" export const { GET, POST } = handlers ``` That's it. Auth.js now owns the authentication routes underneath: ```text /api/auth/* ``` --- # Why `[...nextauth]`? Remember catch-all routes? ```text [...nextauth] ``` can capture multiple authentication paths. For example: ```text /api/auth/signin /api/auth/signout /api/auth/session /api/auth/callback/github ``` One Route Handler can support Auth.js's various endpoints. So: ```text [...nextauth] ``` basically says: > "Auth.js, you deal with whatever comes after `/api/auth/`." 😎 --- # OAuth Login Flow Suppose a user clicks: ```text Continue with GitHub ``` Conceptually: ```text User ↓ Your Next.js app ↓ GitHub authorization page ↓ User approves access ↓ GitHub callback ↓ Auth.js verifies response ↓ Session created ↓ User authenticated ``` You don't manually implement the entire OAuth protocol. That's one of the biggest reasons authentication libraries exist. --- # Signing In Because Auth.js exports: ```js signIn ``` you can trigger login from server-side code. Example: ```jsx import { signIn } from "@/auth" export default function LoginPage() { return ( ) } ``` The authentication flow can start from a Server Action. --- # Signing Out Similarly: ```jsx import { signOut } from "@/auth" export default function LogoutButton() { return ( ) } ``` No client-side authentication library required just to trigger logout. --- # 4. Reading the Session on the Server In modern Next.js, server-side authentication should usually be your first choice when possible. Auth.js gives you: ```js auth() ``` Example: ```jsx import { auth } from "@/auth" export default async function DashboardPage() { const session = await auth() return (

      {JSON.stringify(
        session,
        null,
        2
      )}

) } ``` A session might contain information such as: ```js { user: { name: "Asif", email: "asif@example.com", image: "..." }, expires: "..." } ``` --- # Protecting a Server Page Suppose: ```text /dashboard ``` should only be accessible to logged-in users. You can check the session directly inside the Server Component. ```jsx import { auth } from "@/auth" import { redirect } from "next/navigation" export default async function DashboardPage() { const session = await auth() if (!session?.user) { redirect("/login") } return (

Welcome, {session.user.name}

) } ``` Conceptually: ```text Request /dashboard ↓ auth() ↓ Session exists? ├── No → /login └── Yes → Dashboard ``` Very clean. --- > **Interview Highlight** > > **Q: How do you read a session inside an Auth.js Server Component?** > > Call the [async](/javascript/promises-asynchronous-javascript) `auth()` helper exported from your Auth.js configuration. This lets the server determine the current authentication state directly during server rendering. --- # Why Server-Side Session Reading Is Nice Imagine doing: ```text Page loads ↓ Browser downloads JS ↓ Browser requests session ↓ Loading spinner ↓ Session arrives ↓ Render dashboard ``` When the server already has access to the incoming request, it can often determine authentication before the page is sent. Conceptually: ```text Request ↓ Server checks session ↓ Render correct UI ↓ Browser receives result ``` Less unnecessary client-side work. --- # 5. Reading the Session in a Client Component Sometimes you genuinely need authentication state inside interactive browser UI. For example: ```text User menu Interactive profile dropdown Client-side dashboard controls ``` Auth.js provides: ```js useSession() ``` from: ```js next-auth/react ``` Example: ```jsx "use client" import { useSession } from "next-auth/react" export default function UserWidget() { const { data: session, status } = useSession() if ( status === "loading" ) { return (

) } if ( status === "unauthenticated" ) { return (

Please log in.

) } return (

Logged in as: {" "} {session.user.email}

) } ``` --- # `useSession()` Status Values The: ```js status ``` value can be: ```text loading authenticated unauthenticated ``` This lets your UI [react](/courses/reactjs) appropriately. For example: ```text loading ↓ Show skeleton ``` ```text authenticated ↓ Show user menu ``` ```text unauthenticated ↓ Show sign-in button ``` --- # `SessionProvider` `useSession()` needs Auth.js's [React](/courses/reactjs) context. That means the relevant Client Component tree needs: ```jsx ``` A common pattern is to create a provider component. ```jsx "use client" import { SessionProvider } from "next-auth/react" export default function AuthProvider({ children }) { return ( {children} ) } ``` Then use it where client-side session state is actually needed. --- # Don't Automatically Wrap Everything It's tempting to put: ```jsx ``` around your entire application just because one navbar button uses: ```js useSession() ``` But remember our Server vs Client Component rule: > Keep client-side boundaries as small as practical. If most of your application can read authentication using: ```js auth() ``` on the server, you don't need to turn your entire authentication architecture into client-side session fetching. Use: ```text auth() ``` when server authentication is enough. Use: ```text useSession() ``` when browser interactivity actually needs session state. --- # Server vs Client Session Reading Quick comparison: | Situation | Recommended API | |---|---| | Server Component | `auth()` | | Server Action | `auth()` | | Route Handler | `auth()` | | Interactive Client Component | `useSession()` | | Client session context | `SessionProvider` | The big rule: ```text Server first Client when needed ``` --- # 6. Credentials Authentication OAuth isn't the only option. You may want traditional: ```text Email + Password ``` authentication. Auth.js provides the: ```js Credentials ``` provider. Example: ```js import NextAuth from "next-auth" import Credentials from "next-auth/providers/credentials" export const { handlers, auth, signIn, signOut } = NextAuth({ providers: [ Credentials({ credentials: { email: { label: "Email", type: "email" }, password: { label: "Password", type: "password" }, }, async authorize(credentials) { // Validate credentials here return null }, }), ], }) ``` The most important [function](/javascript/functions-in-javascript) is: ```js authorize() ``` --- # What Does `authorize()` Do? The: ```js authorize() ``` [function](/javascript/functions-in-javascript) receives the credentials submitted by the user. Your job is to: ```text Validate input ↓ Find user ↓ Verify password ↓ Return safe user object ``` If authentication fails: ```js return null ``` If authentication succeeds: ```js return user ``` --- # Credentials Example ```js import NextAuth from "next-auth" import Credentials from "next-auth/providers/credentials" export const { handlers, auth, signIn, signOut } = NextAuth({ providers: [ Credentials({ credentials: { email: {}, password: {}, }, async authorize( credentials ) { const email = credentials.email const password = credentials.password const user = await db.user.findUnique({ where: { email } }) if (!user) { return null } const passwordMatches = await verifyPassword( password, user.passwordHash ) if (!passwordMatches) { return null } return { id: user.id, name: user.name, email: user.email, role: user.role, } }, }), ], }) ``` Important: ```text NEVER compare plaintext passwords. ``` Passwords stored in your database should be securely hashed. --- # Credentials Authentication Is Your Responsibility Auth.js gives you the authentication framework. It does **not** magically build your complete password-security system. If you use Credentials authentication, you are responsible for things such as: - Input validation - Password hashing - Password verification - Registration - Password reset - Rate limiting - Brute-force protection - Account verification - Secure password policies So don't think: ```text Credentials Provider = Complete authentication security ``` It's more like: > "Here's the integration point. You implement the credential logic safely." --- # Validate Credentials Never trust: ```js credentials.email ``` and: ```js credentials.password ``` just because they came from your own login form. The internet can call your endpoints too. Use a validation library such as: ```text Zod ``` Example: ```js import { z } from "zod" const loginSchema = z.object({ email: z.string().email(), password: z.string().min(8), }) ``` Then: ```js const parsed = loginSchema.safeParse( credentials ) if (!parsed.success) { return null } ``` Validate first. Database second. --- # 7. Adding Custom Data to the Session Suppose every user has a role: ```text user editor admin ``` You may want: ```js session.user.role ``` available throughout your application. Auth.js provides callbacks. Two commonly used ones are: ```text jwt session ``` --- # `jwt` Callback The JWT callback lets you customize token data when using the JWT session strategy. Example: ```js callbacks: { async jwt({ token, user }) { if (user) { token.role = user.role } return token } } ``` When the user initially signs in, you can copy: ```text user.role ``` into the token. --- # `session` Callback Then you can expose selected information through the session. Example: ```js callbacks: { async jwt({ token, user }) { if (user) { token.role = user.role } return token }, async session({ session, token }) { session.user.role = token.role return session }, } ``` Now: ```js session.user.role ``` can be: ```text admin ``` for example. --- # Be Careful What You Expose The session object may become available to client-side code. So don't put things like: ```text passwordHash database credentials private API keys internal security flags ``` into: ```js session ``` Just because the server knows something doesn't mean the browser needs to know it. A good session might contain: ```js { user: { id: "123", name: "Asif", email: "asif@example.com", role: "admin" } } ``` Not: ```js { passwordHash: "...", databasePassword: "...", secretKey: "..." } ``` Hopefully obvious. But production incidents suggest reminders are healthy. 😭 --- # 8. Authorization with Roles Once authentication works, you can add authorization. Suppose only admins should access: ```text /admin ``` You can check: ```js session.user.role ``` Example: ```jsx import { auth } from "@/auth" import { redirect } from "next/navigation" export default async function AdminPage() { const session = await auth() if (!session?.user) { redirect("/login") } if ( session.user.role !== "admin" ) { redirect("/unauthorized") } return (

Admin Dashboard

) } ``` Conceptually: ```text Request /admin ↓ Logged in? ├── No → Login └── Yes ↓ Is admin? ├── No → Unauthorized └── Yes → Admin Page ``` That's authorization. --- # Don't Protect Pages Only in the Browser This is insecure: ```jsx "use client" if ( session.user.role !== "admin" ) { return null } ``` Why? Because hiding UI is not the same as securing data. A malicious user could still try to call: ```text /api/admin/users ``` directly. Authorization must also happen where sensitive server operations are performed. For example: ```js export async function DELETE( request ) { const session = await auth() if ( session?.user?.role !== "admin" ) { return Response.json( { error: "Forbidden" }, { status: 403 } ) } // Perform deletion } ``` Golden rule: > **Never trust the UI as your security boundary.** --- # 9. Auth.js Inside Route Handlers You can call: ```js auth() ``` inside your own Route Handlers too. Example: ```js import { auth } from "@/auth" export async function GET() { const session = await auth() if (!session?.user) { return Response.json( { error: "Unauthorized" }, { status: 401 } ) } return Response.json({ message: "Secret data", }) } ``` Now the API endpoint itself is protected. That's much more important than simply hiding a button. --- # Authentication vs Authorization Status Codes Useful HTTP codes: ```text 401 Unauthorized ``` usually means: > "You're not authenticated." While: ```text 403 Forbidden ``` usually means: > "We know who you are, but you're not allowed to do this." Example: ```text Not logged in ↓ 401 ``` ```text Logged in as normal user Trying admin action ↓ 403 ``` Good API design makes these distinctions clear. --- # 10. Modern Next.js 16: `proxy.ts` Older Next.js authentication tutorials often use: ```text middleware.ts ``` to perform early authentication redirects. Starting with **Next.js 16**, that file convention has been renamed to: ```text proxy.ts ``` So older code may show: ```text middleware.ts ``` while modern Next.js uses: ```text proxy.ts ``` --- # Auth.js with `proxy.ts` Auth.js can expose: ```js auth ``` as the Next.js proxy. Example: ```js // src/proxy.js export { auth as proxy } from "@/auth" ``` This allows Auth.js to inspect authentication state before matching requests continue. --- # Matching Protected Routes You can configure which routes the proxy should run for. Example: ```js export { auth as proxy } from "@/auth" export const config = { matcher: [ "/dashboard/:path*", "/admin/:path*" ], } ``` Now the proxy only runs for those matching route groups. --- # Should Proxy Handle All Authorization? No. This is important. Proxy is useful for things such as: ```text Early redirects Optimistic authentication checks Route gating ``` But your real security checks should still live close to the protected data or server action. Think: ```text Proxy ↓ Convenience / early gate ``` and: ```text Server Component Route Handler Server Action Database operation ↓ Actual authorization enforcement ``` Don't put your entire security architecture into one giant proxy file. --- # Why Server Checks Still Matter Imagine your proxy protects: ```text /admin ``` but you forget to protect: ```text /api/admin/delete-user ``` A malicious user doesn't need your admin page. They can call the API directly. So always protect sensitive server operations themselves. Defense in depth. --- # OAuth vs Credentials Here's a useful comparison. | Feature | OAuth | Credentials | |---|---|---| | Example | Google / GitHub | Email + Password | | Password stored by you | Usually no | Yes | | Password hashing responsibility | Provider | You | | Password reset system | Provider | You | | Login UI flexibility | Good | Full control | | Security burden | Lower | Higher | | Easy social login | ✅ | ❌ | For many applications, OAuth reduces how much password security you need to manage yourself. Credentials are still useful when your product specifically requires email/password authentication. --- # Server vs Client Authentication Here's another important comparison: | Feature | Server | Client | |---|---|---| | Read session | `auth()` | `useSession()` | | Protect server page | ✅ | ❌ Not enough alone | | Protect database action | ✅ | ❌ | | Show interactive user menu | Possible | ✅ Useful | | Requires SessionProvider | No | Yes for `useSession()` | | Security authority | ✅ Server | UI only | Always remember: ```text Client authentication state = User experience ``` while: ```text Server authentication checks = Security ``` The server gets the final say. --- # A Real-World Architecture Imagine you're building a SaaS application. Your authentication structure might look like: ```text src/ ├── auth.js │ ├── proxy.js │ └── app/ ├── api/ │ └── auth/ │ └── [...nextauth]/ │ └── route.js │ ├── login/ │ └── page.jsx │ ├── dashboard/ │ └── page.jsx │ └── admin/ └── page.jsx ``` Responsibilities: ```text auth.js ↓ Main Auth.js configuration ``` ```text api/auth/[...nextauth]/route.js ↓ Authentication HTTP endpoints ``` ```text proxy.js ↓ Optional early route gating ``` ```text dashboard/page.jsx ↓ Server-side session check ``` ```text admin/page.jsx ↓ Authentication + role authorization ``` That's a much cleaner mental model than: ```text "Some login stuff somewhere." ``` 😄 --- # Authentication Flow A typical OAuth flow looks like: ```text User clicks Sign In ↓ signIn("github") ↓ GitHub ↓ User authorizes ↓ Auth.js callback ↓ User/session created ↓ Secure authentication cookie ↓ Future request ↓ auth() ↓ Current session ``` --- # Credentials Flow A credentials flow looks more like: ```text User enters email + password ↓ Credentials Provider ↓ authorize() ↓ Validate input ↓ Find user ↓ Verify hashed password ↓ Return safe user object ↓ Session created ``` Different login method. Same general goal: ```text Establish trusted identity ``` --- # Common Mistake: Trusting Client State Never assume: ```js useSession() ``` protects your API. It doesn't. It's useful for UI. Your backend should still perform: ```js const session = await auth() ``` before sensitive operations. --- # Common Mistake: Storing Plaintext Passwords Never: ```js user.password = credentials.password ``` in your database. Store a secure password hash produced by an appropriate password hashing algorithm. Then verify the submitted password against that hash. Passwords should not be recoverable from your database. --- # Common Mistake: Exposing Too Much Session Data Don't send your entire database user record into: ```text session.user ``` Only expose what the application genuinely needs. Good: ```text id name email role image ``` Potentially bad: ```text password hash security answers internal tokens private backend fields ``` --- # Common Mistake: Authentication Without Authorization This: ```js if (!session) { redirect("/login") } ``` answers: ```text Is the user logged in? ``` It does NOT answer: ```text Is the user allowed to delete another account? ``` Always distinguish: ```text Authentication ``` from: ```text Authorization ``` --- # Common Mistake: Building Password Auth Too Casually If you're using the Credentials provider, you aren't just building a login form. You're taking responsibility for: - Password storage - Validation - Rate limiting - Account recovery - Brute-force protection - Verification - Security monitoring OAuth or passkey-based authentication can reduce some of this responsibility. Credentials are powerful. But power comes with security homework. 😅 --- # Quick Reference | Need | Auth.js Tool | |---|---| | Main config | `NextAuth()` | | OAuth provider | `GitHub`, `Google`, etc. | | Email/password | `Credentials` | | Auth HTTP endpoints | `handlers` | | Read session on server | `auth()` | | Start login | `signIn()` | | Log out | `signOut()` | | Client session | `useSession()` | | Client session context | `SessionProvider` | | Customize JWT | `jwt` callback | | Customize session | `session` callback | | Early route gating | `proxy.ts` | | Role protection | Server-side authorization check | --- # Interview Quick Hits > **Q: What is Auth.js?** > > Auth.js is an open-source authentication framework that integrates with Next.js and supports OAuth providers, credentials, JWT sessions, database sessions, and server/client authentication patterns. --- > **Q: What does `auth()` do?** > > `auth()` reads the current authentication session on the server and can be used from [Server Components](/courses/nextjs) and other server-side contexts. --- > **Q: `auth()` vs `useSession()`?** > > Use `auth()` on the server. Use `useSession()` when an interactive Client Component needs session state. --- > **Q: What does `[...nextauth]` do?** > > It creates a catch-all Route Handler used by Auth.js for authentication endpoints such as sign-in, callbacks, sessions, and sign-out. --- > **Q: What does the Credentials `authorize()` function return?** > > Return a safe user object when authentication succeeds or `null` when credentials are invalid. --- > **Q: Does Auth.js automatically secure your database operations?** > > No. Sensitive Server Actions, Route Handlers, and database operations should still perform authentication and authorization checks. --- > **Q: What happened to `middleware.ts` in Next.js 16?** > > Next.js 16 deprecated the `middleware` file convention and renamed it to `proxy.ts`. --- > **Q: JWT sessions or database sessions?** > > Auth.js supports both. JWT sessions store session information using tokens, while database sessions maintain session records in persistent storage. The best choice depends on the application architecture. --- # The Mental Model Authentication becomes much easier when you stop thinking of it as: ```text Login Form ``` and start thinking: ```text IDENTITY ↓ How does the user prove who they are? SESSION ↓ How do we remember them? AUTHORIZATION ↓ What are they allowed to do? SERVER SECURITY ↓ Where do we enforce those rules? ``` With Auth.js: ```text Provider ↓ Authentication ↓ Session ↓ auth() ↓ Server knows user ↓ Authorization check ↓ Protected resource ``` That's the architecture. --- ## Summary Auth.js provides a powerful authentication layer for Next.js applications. The key ideas are: - Auth.js was previously known as NextAuth.js - The Next.js package remains `next-auth` - Current Auth.js v5 Next.js setups use `next-auth@beta` - `AUTH_SECRET` is required - OAuth provider credentials can use names such as `AUTH_GITHUB_ID` and `AUTH_GITHUB_SECRET` - `auth.js` contains the main authentication configuration - `handlers` powers the `/api/auth/[...nextauth]` Route Handler - `auth()` reads the current session on the server - `useSession()` provides session state inside Client Components - `SessionProvider` is required when using `useSession()` - OAuth providers can handle Google, GitHub, and many other login systems - Credentials authentication uses `authorize()` - Credentials users require your own password-security logic - Auth.js supports both JWT and database session strategies - `jwt` and `session` callbacks can add custom session information - Authentication identifies the user - Authorization determines what that user can do - Sensitive operations must always enforce authorization on the server - Next.js 16 renamed `middleware.ts` to `proxy.ts` - Proxy can help with early route gating but should not replace real server-side authorization The biggest rule is: ```text Client decides what UI to show. Server decides what the user is actually allowed to do. ``` If you remember that one sentence, you'll avoid a surprising number of authentication mistakes. And that's how we'll keep approaching authentication on **asif.to** — not as some mysterious collection of cookies, JWTs, callbacks, and providers, but as a simple chain of trust: **prove who the user is, remember them securely, and check what they're allowed to do before touching protected data.** Once that mental model clicks, Auth.js starts feeling a lot less scary. 🔐🚀