NextAuth

## 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 | Concept | Meaning | |---|---| | Provider | OAuth, credentials, magic link, or passkey login source. | | Session | Server-readable representation of the signed-in user. | | `auth()` | Helper exported from Auth.js configuration to read current session. | | Callback | Hook to customize sign-in, JWT, session, or authorization behavior. | | Adapter | Database 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 | Mistake | Why It Happens | Correct Approach | |---|---|---| | Checking auth only in client UI | It hides controls but does not protect data. | Re-check auth on the server. | | Putting provider secrets in client code | Environment variable boundaries are misunderstood. | Keep provider secrets server-side. | | Assuming middleware/proxy is enough | Route 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 | Feature | Browser Impact | Notes | |---|---|---| | OAuth redirect | Standard browser navigation | Works broadly. | | Session cookie | Browser cookie support | Requires secure cookie settings in production. | | Server session check | Server-side | No 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 | Need | Tool | |---|---| | OAuth login | Provider | | Current server session | `auth()` | | Protected page | Server check + redirect | | Protected endpoint | `auth()` in Route Handler | | Role check | Server 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.