ReviseAlgo Logo

Authentication

NextAuth

Learn how Auth.js/NextAuth fits into Next.js authentication, including providers, sessions, protected pages, and route protection.

1. Learning Objectives

By the end of this lesson, you will be able to configure Auth.js/NextAuth at a high level, read sessions on the server, protect pages and endpoints, and choose where authentication checks belong.

Difficulty: Intermediate.

2. Prerequisites

  • Route Handlers.
  • Server Components.
  • Cookies and sessions.
  • OAuth basics.

    • 3. Overview

    NextAuth, now developed as Auth.js, provides authentication primitives for Next.js apps: providers, callbacks, sessions, sign-in/sign-out helpers, and server-side session access through an exported auth() function.

    4. Why This Topic Matters

    Authentication touches every sensitive workflow. A good setup keeps provider logic centralized, avoids leaking secrets to the browser, and verifies sessions close to protected data access.

    5. Real-World Analogy

    Auth.js is like the reception desk in an office building. It verifies who you are, issues a visitor badge, and lets each floor check whether your badge allows entry.

    6. Core Concepts

    ConceptMeaning
    ProviderOAuth, credentials, magic link, or passkey login source.
    SessionServer-readable representation of the signed-in user.
    auth()Helper exported from Auth.js configuration to read current session.
    CallbackHook to customize sign-in, JWT, session, or authorization behavior.
    AdapterDatabase integration for persisted users and sessions.

    7. Syntax & API Reference

    8. Visual Diagram

    9. Live Example - Full Working Code

    What just happened? The page checks the session on the server before rendering protected content.

    10. Interactive Playground

    Try this:

  • Add a GitHub provider.
  • Render the current session in a Server Component.
  • Protect a Route Handler with auth().

    • 11. Common Mistakes

    MistakeWhy It HappensCorrect Approach
    Checking auth only in client UIIt hides controls but does not protect data.Re-check auth on the server.
    Putting provider secrets in client codeEnvironment variable boundaries are misunderstood.Keep provider secrets server-side.
    Assuming middleware/proxy is enoughRoute guards can be bypassed by internal code paths.Verify authorization near data access too.

    12. Best Practices

  • Keep auth configuration centralized.
  • Use server-side auth() for protected pages and handlers.
  • Validate authorization, not just authentication.
  • Keep secrets in server environment variables.
  • Use database sessions when revocation and auditability matter.

    • 13. Browser Compatibility

    FeatureBrowser ImpactNotes
    OAuth redirectStandard browser navigationWorks broadly.
    Session cookieBrowser cookie supportRequires secure cookie settings in production.
    Server session checkServer-sideNo browser API required.

    14. Interview Questions

    Easy: What problem does NextAuth/Auth.js solve?

    Answer: It provides authentication, provider integration, session handling, and helpers for Next.js apps.

    Medium: Where should protected page checks happen?

    Answer: On the server, usually in Server Components, Route Handlers, Server Actions, or middleware/proxy gates.

    Hard: Why is authorization different from authentication?

    Answer: Authentication proves identity; authorization decides whether that identity can perform a specific action.

    15. Debugging Exercise

    Bug report: "The dashboard link is hidden, but users can still call the admin API."

    Solution

    Client UI checks are not security. Add server-side auth() and role/permission checks inside the API Route Handler or Server Action.

    16. Practice Exercises

  • Easy: Render a signed-in user's email on a server page.
  • Medium: Protect a dashboard route with redirect.
  • Hard: Add role-based checks to an admin Route Handler.

    • 17. Scenario-Based Challenge

    A SaaS app needs GitHub login, billing pages, and admin-only organization settings. Where should checks live?

    Walkthrough

    Use Auth.js providers for sign-in, middleware/proxy for coarse route gating, and server-side authorization checks in billing/admin data access paths.

    18. Quick Quiz

    1. What helper reads the server session? Answer: auth(). 2. Should provider secrets ship to the browser? Answer: No. 3. Is hiding a link enough security? Answer: No. 4. What is a provider? Answer: A login source such as GitHub or Google. 5. What is authorization? Answer: Permission checking after identity is known.

    19. Summary & Key Takeaways

  • Auth.js/NextAuth centralizes authentication.
  • Use server-side session checks for protected content.
  • Keep secrets server-side.
  • Middleware/proxy can gate routes but should not be the only authorization layer.
  • Authorization must be checked close to sensitive data and mutations.

    • 20. Cheat Sheet

    NeedTool
    OAuth loginProvider
    Current server sessionauth()
    Protected pageServer check + redirect
    Protected endpointauth() in Route Handler
    Role checkServer authorization logic

    21. Further Reading

  • Auth.js Docs: Protecting Resources.
  • Auth.js Docs: Session Management.
  • Next.js Docs: Authentication guide.

    • 22. Next Lesson Preview

    Next, you will learn JWTs and when token-based sessions are useful or risky.