liveBook · Manning

Authentication

As explained in Build AI-Enhanced Web Apps

The process of verifying the identity of a user, application, or other requesting entity.

Authentication determines a user’s identity. Authorization is the separate decision about what that user may access or how many AI messages they may send. Both matter when a public AI application must protect user data and control costly model usage. section 9.3 section 9.1

Choose a sign-in method that fits the application and its data-handling responsibilities:

  • Username and password are familiar, but securely maintaining passwords and user information is complex. section 9.3
  • OAuth 2.0 social login lets users sign in with an existing account; review requested permissions and provide ways to unlink accounts and delete data. section 9.3
  • Passwordless login verifies users with email or SMS codes instead of passwords. section 9.3

In a Next.js application, a Clerk-based flow starts by creating a Clerk project, choosing authentication methods, installing @clerk/nextjs, and setting its publishable and secret keys in environment variables. Protect the chat route in middleware. The index page can send unsigned-in visitors to /sign-in and signed-in users to /chat. Keep authorization separate: the example limits authenticated users to 10 messages per day with Upstash Redis, and that quota can be adjusted to match AI costs and expected usage. section 9.3.1

Listing 9.3 Configuring Clerk middleware
import { clerkMiddleware, createRouteMatcher } from "@clerk/nextjs/server";   #1

const isProtectedRoute = 
createRouteMatcher(["/chat(.*)"]);    #2

export default clerkMiddleware(async (auth, req) => {
  if (isProtectedRoute(req)) await auth.protect();

  const corsResponse = handleCORS(req);
  if (corsResponse instanceof NextResponse) {
    return corsResponse;
  }
  const rateLimitResponse = rateLimit(req);
  if (rateLimitResponse instanceof NextResponse) {
    return rateLimitResponse;
  }
  return NextResponse.next();
});

export const config = {
  matcher: [
    // Skip Next.js internals and all static files, unless found in search params
    '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)
|jpe?g|webp|png|gif|svg|ttf|woff2?|
ico|csv|docx?|xlsx?|zip|webmanifest)).*)',
    // Always run for API routes
    '/(api|trpc)(.*)',
  ]
};

The middleware listing matches /chat routes and calls auth.protect() before continuing through CORS handling and rate limiting. section 9.3.1

Sign-in before an AI interview

An AI interview assistant requires Clerk sign-in before users reach its features; its login page offers Google or email. A document-based RAG application likewise requires sign-in before chat access and uses Clerk to restrict document uploads and access. Authentication is only one layer: request validation, rate limits, security headers, upload checks, and careful handling of API keys and sensitive data remain necessary. section 10.1.1 section 11.1.1 section 11.2.2 section 10.2

How Build AI-Enhanced Web Apps covers it

How deep it goes
Defines authentication against authorization, compares sign-in methods, and walks through Clerk setup, middleware protection, redirects, and quotas.
Examples
Shows a protected Next.js chat route, sign-in redirects, a daily message quota, and sign-in for interview and RAG applications.
What it assumes
Assumes a Next.js project and existing AI and Upstash credentials while walking through Clerk project, key, and middleware setup.
What you can do after
Apply it via Clerk.js to require sign-in for Next.js AI features and pair protected routes with usage limits.
How it connects
Links authentication to authorization, OAuth 2.0, middleware, rate limiting, API key management, and data protection.

Also explained in

Compare how 34 books explain authentication →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Build AI-Enhanced Web Apps. The section links point to the parts of the book it draws on.