ReviseAlgo Logo

Authentication

JWT

Learn JSON Web Tokens in Next.js authentication, what belongs in a token, and how to avoid common session security mistakes.

1. Learning Objectives

By the end of this lesson, you will be able to explain JWT structure, decide what claims belong in a token, compare JWT sessions with database sessions, and identify common JWT security risks.

Difficulty: Intermediate.

2. Prerequisites

  • Authentication basics.
  • Cookies and HTTP headers.
  • Server-side authorization.

    • 3. Overview

    A JSON Web Token is a signed token containing claims about a subject. In web apps, JWTs are often used to represent session or authorization state, but they must be handled carefully because they can outlive server-side changes unless invalidation is designed.

    4. Why This Topic Matters

    JWTs are common in Next.js apps, APIs, and OAuth flows. Misusing them can leak sensitive data, create hard-to-revoke sessions, or make authorization depend on stale claims.

    5. Real-World Analogy

    A JWT is like a sealed badge. Guards can inspect the badge and verify the seal, but if the badge says too much or is valid too long, losing it becomes dangerous.

    6. Core Concepts

    ConceptMeaning
    HeaderToken metadata such as signing algorithm.
    PayloadClaims such as subject, issuer, audience, and expiry.
    SignatureCryptographic proof the token was issued by a trusted server.
    ClaimA named piece of token data.
    ExpiryTime after which the token should no longer be accepted.

    7. Syntax & API Reference

    JWT shape:

    Example claims:

    8. Visual Diagram

    9. Live Example - Full Working Code

    What just happened? Authorization checks use token claims, but still verify expiry before trusting them.

    10. Interactive Playground

    Try this:

  • Decode a sample JWT payload.
  • Remove sensitive fields from the payload.
  • Add expiry checks before authorizing a request.

    • 11. Common Mistakes

    MistakeWhy It HappensCorrect Approach
    Storing secrets in JWT payloadJWT payloads are easy to decode.Store only non-sensitive claims.
    Long-lived tokens without revocationStateless tokens feel convenient.Use short expiry, rotation, or database sessions.
    Trusting role claims foreverRoles change after token issue.Refresh claims or check critical permissions server-side.

    12. Best Practices

  • Keep JWT payloads minimal.
  • Store web session tokens in secure, HTTP-only cookies.
  • Use short lifetimes for high-risk tokens.
  • Re-check critical permissions against server data.
  • Rotate secrets carefully and plan invalidation.

    • 13. Browser Compatibility

    FeatureBrowser ImpactNotes
    Cookie storageBroad supportPrefer HTTP-only secure cookies for sessions.
    Bearer token headersStandard HTTPCommon for API clients.
    Token verificationServer-sideBrowser should not be the security authority.

    14. Interview Questions

    Easy: What are the three parts of a JWT?

    Answer: Header, payload, and signature.

    Medium: Is JWT payload data encrypted by default?

    Answer: No. It is encoded and signed, so do not put secrets in it unless using an encryption scheme.

    Hard: Why are database sessions sometimes safer than JWT sessions?

    Answer: Database sessions can be revoked or updated centrally, while stateless JWTs may remain valid until expiry.

    15. Debugging Exercise

    Bug report: "A demoted admin can still access admin pages for an hour."

    Solution

    The JWT likely contains stale role claims. Shorten token lifetime, refresh claims, or re-check sensitive permissions against the database.

    16. Practice Exercises

  • Easy: Identify claims in a decoded JWT.
  • Medium: Write an expiry check.
  • Hard: Design a token refresh and revocation strategy for admin roles.

    • 17. Scenario-Based Challenge

    A mobile API needs bearer tokens, but the web dashboard uses cookies. Should both use the same storage strategy?

    Walkthrough

    No. Browser sessions usually prefer secure HTTP-only cookies; mobile/API clients often use bearer tokens with careful storage, expiry, and rotation.

    18. Quick Quiz

    1. Are JWT payloads secret by default? Answer: No. 2. What claim usually identifies the user? Answer: sub. 3. What claim controls expiration? Answer: exp. 4. Can JWTs be hard to revoke? Answer: Yes. 5. Should critical authorization be blindly trusted from stale tokens? Answer: No.

    19. Summary & Key Takeaways

  • JWTs are signed claim containers.
  • Payloads are readable, so keep them minimal.
  • Expiry and revocation strategy matter.
  • Cookies are often safer for browser sessions.
  • Re-check high-risk permissions server-side.

    • 20. Cheat Sheet

    NeedJWT Guidance
    User identifierUse sub
    Secret dataDo not store in payload
    Session expiryUse exp
    Admin authorizationRe-check server-side
    Browser sessionPrefer secure HTTP-only cookie

    21. Further Reading

  • Auth.js Docs: Session strategies.
  • JWT RFC 7519.
  • OWASP: JSON Web Token cheat sheet.

    • 22. Next Lesson Preview

    Next, you will learn middleware/proxy route gating for coarse authentication checks.