36_JWT.txt

JWT (JSON Web Token)
    
-> As, you know that token sare used to authenticate users/give access to the resources in web applications
 
  1️⃣ Definition:
        A JWT (JSON Web Token) is a compact string used to securely pass information between two parties (like a client and a server).
        It’s most often used for authentication — to prove “who you are” after you log in.
        It's defined by the JSON web token standard (RFC 7519). 
        It is compact and self-contained means of transmitting information between two parties as a JSON object

  2️⃣ Structure
        A JWT has 3 parts, separated by dots (.): header.payload.signature
        ➡️Header – says what type of token it is and what algorithm is used to sign it (e.g., HS256).
        ➡️Payload – contains the actual data (user ID, roles, expiry time, etc.).
        ➡️Signature – a cryptographic signature created by the server to prove the token wasn’t changed.
        ➡️JWT Token Example (shortened):
            eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjEyMyIsIm5hbWUiOiJKb2huIn0.XYZ123abchjvxcbhjx

  3️⃣ Usage:
        After a user logs in, the server creates a JWT and gives it to the client.
        The client saves it (usually in localStorage, sessionStorage, or a cookie).
        They can store user claims, such as User Id, roles, permissions and custom data in a secure and portable format.
        For each request to a protected API, the client sends the token in the Authorization header like:
        Authorization: Bearer <your_jwt>
        The server verifies the signature and expiry — if valid, it processes the request.

  4️⃣ Statelessness:
        JWT tokens are stateless.
        The server does not store anything about the user session.
        All the needed info is inside the token itself.
        As long as the server has the secret key (or public key) to verify the signature, it can validate any token without looking it up in a database.
        This makes JWTs easy to scale across multiple servers because there’s no shared session store.

  ➡️ Structure of JWT:
            ┌───────────────────────────────────────────────────────────────────────────┐
            │                          JWT Token Structure                              │
            ├───────────────────────────────────────────────────────────────────────────┤
            │ Header (metadata) │ Payload (claims)   │ Signature                        │
            ├───────────────────────────────────────────────────────────────────────────┤
            │ Example:          │ Example:           │ Example:                         │
            │ {                 │ {                  │ HMACSHA256(                      │
            │  "alg": "HS256",  │  "sub": "123456",  │  base64UrlEncode(header) + "." + │
            │  "typ": "JWT"     │  "name": "John",   │  base64UrlEncode(payload),       │
            │ }                 │  "iat": 1516239022 │  secret key)                     │
            │ Base64URL encoded │ Base64URL encoded  │ Base64URL encoded signature      │
            ├───────────────────────────────────────────────────────────────────────────┤
            │ Combined token (3 parts separated by dots):                               │
            │       header.payload.signature                                            │
            │ Example:                                                                  │
            │  xxxxx.yyyyy.zzzzz                                                        │
            └───────────────────────────────────────────────────────────────────────────┘
            🔹 Header → describes the token type and signing algorithm (e.g. HS256).
            🔹 Payload → contains claims (user ID, roles, expiry time, etc.).
            🔹 Signature → ensures the token hasn’t been tampered with.

      -> The 'alg' in header indicates which algorithm is used to sign the token such as HMAC, SHA256 or RSA

      -> Payload Claims: Contains claims/statements about the user or any other additional data.
            Claims are categorized into three types:
            1️⃣ Reserved Claims: Predefined claims standardized by the JWT specification, such as:
                                 iss (issuer), sub (subject), aud (audience), exp (expiration time), and iat (issued at)
            2️⃣ Public Claims: Custom claims defined by the application developer to convey information about the user
            3️⃣ Private Claims: Custom claims agreed upon by parties that exchange JWTs, not registered or standardized

      -> Signature: Verifies the integrity of the token and ensures that it has not been tampered with during transmission.
                    It's created by taking the encoded header, encoded payload, a secret key (for HMAC algorithms), and
                    applying the specified algorithm to generate the signature
      In short:
         Header → Metadata (algorithm, type).
         Payload → Claims (user info, expiry).
         Signature → Verification to ensure integrity.


      ➡️ JWT is like this: gsdfdsbdfkhjdfjdsbfhdsbhfhdsbg.fdvshfvdsfsdfdsfvgsduifbdsudsbg.sdhjfvcsfvdshfbgdshjfvbdsuhvbdfv
         The first string before first dot  represents 'header', the second string before second dot represents 'payload' and the
         third string after the second dot represents the signature:

         🔹1. Header: Tells which algorithm is used and that it’s a JWT.
                        Example: {
                                    "alg": "HS256",
                                    "typ": "JWT"
                              }
                        this is Encoded (Base64URL):sdfdsbdsfskdfgsbdhskgvdsuygvbdshvdfvdfsvdfsvfdgg

         🔹2. Payload: Contains claims (data about the user + token validity).
                        Example: {
                                    "sub": "1234567890",
                                    "name": "John Doe",
                                    "admin": true,
                                    "iat": 1516239022,
                                    "exp": 1516242622
                                 }
                        this is Encoded (Base64URL): jfdsfbsdfhdsjgbdisfbgvdfisogvbdfsiugvhdfsvjdsfhhjvbdfghjvgb sdiufvhbdv
          🔹3. Signature: Ensures the token wasn’t tampered with:
                          Example:
                                    HMACSHA256(
                                    base64UrlEncode(header) + "." + base64UrlEncode(payload), 
                                    your-256-bit-secret
                                    )
                          this is Encoded (Base64URL):jhbdsjcdsjkfbdsijufdhfvdsfgbdsf
            -> Then Combining these three forms JWT.

      ➡️Extra but very very important:
      Note: Encoded (Base64URL) is a way to convert binary data (like JSON text or images) into a string made of A–Z, a–z, 0–9

      ➡️Base64 vs Base64URL:
         🔹Base64:
            A way to convert binary data (like JSON text or images) into a string made of A–Z, a–z, 0–9, + and /.
            Often ends with = padding.
            Not safe to put directly in URLs or cookies because + and / have special meanings.

         🔹Base64URL:
            Same concept as Base64 but modified to be URL-safe:
            + is replaced with - (dash).
            / is replaced with _ (underscore).
            Padding = is removed.
            This way the encoded string can safely be used in URLs, headers, and cookies.

        🔹Why JWT uses Base64URL:
            JWT tokens are often sent in HTTP headers and sometimes in URLs.
            Using normal Base64 could break the URL or require extra escaping.
            Base64URL avoids these issues.
            
      Checkout next file : 37_JWT_Auth_Flow.txt