关于JWT的技术疑问：服务端认证、令牌验证及Base64编码作用

Hey there, let's break down your JWT questions clearly and practically—great to see you digging into the nitty-gritty details!

1. How do application servers implement authentication with JWT? #

The process follows a straightforward, stateless flow:

• User Login: When a user submits valid credentials (like username/password), the server verifies them against its user database.
• Token Generation: If credentials are valid, the server creates a JWT. This involves:
  • Defining a Header (specifying the signing algorithm, e.g., HS256 or RS256)
  • Crafting a Payload with user identity claims (like user ID, role) and metadata (expiration time exp, issuer iss)
  • Signing the combined Header+Payload with a secret key (symmetric) or private key (asymmetric) to generate the Signature
• Token Delivery: The server sends the full JWT back to the client, which stores it (usually in localStorage, session storage, or a secure cookie).
• Subsequent Requests: For every protected resource request, the client includes the JWT in the request (most commonly via the Authorization header: Bearer <your-jwt-token>).
• Token Validation: The server receives the JWT, verifies its signature and validity (checking expiration, issuer, etc.), and if everything checks out, grants access to the requested resource. Since JWT is stateless, the server doesn't need to store session data—all necessary info is in the token itself.

2. Your remaining JWT confusion points #

You already have a solid grasp of encoding vs encryption and JWT structure, so let's tackle your two remaining questions:

a. How does the token verification process work (as mentioned in the article's Section 5)? #

Here's a step-by-step breakdown of what the server does when it receives a JWT:

1. Split the Token: The server splits the JWT string into three parts using the dot (.) separator: Header, Payload, and Signature.
2. Decode the Header: Base64-decode the Header to get the signing algorithm (e.g., RS256) and other metadata.
3. Recompute the Signature: Using the same algorithm from the Header, the server takes the Base64-encoded Header and Base64-encoded Payload, concatenates them with a dot, and signs the result with the appropriate key (secret key for symmetric algorithms, public key for asymmetric ones).
4. Compare Signatures: The server compares the recomputed signature with the Signature part from the incoming JWT. If they match, it confirms the Header and Payload haven't been tampered with.
5. Validate Payload Claims: The server checks critical claims in the Payload:
   • exp: Ensures the token hasn't expired
   • iss: Verifies the token was issued by a trusted server
   • aud: Confirms the token is intended for this application (if applicable)
6. Grant Access: If all checks pass, the server extracts user identity from the Payload and processes the request.

b. Why use Base64 encoding for Header and Payload if they're not encrypted (and thus not secure)? #

Base64 encoding isn't about security—it's about compatibility and structure. Here's why it's essential:

• Text Protocol Compatibility: HTTP is a text-based protocol. JSON (the format of Header and Payload) is text, but when transmitted, raw JSON can have characters that cause issues (like spaces or special characters). Base64 converts the JSON into a safe, URL-friendly string that works seamlessly in headers, query parameters, or cookies.
• Standardized Structure: Base64 ensures the Header and Payload are in a consistent, predictable format that any JWT library can decode easily. Without it, parsing raw JSON across different systems might introduce inconsistencies.
• Tamper Protection via Signature: Even though Header and Payload are readable, the Signature ensures they can't be modified without detection. If someone changes the Payload (e.g., altering a user's role), the recomputed signature won't match the original, and the server will reject the token.
• Optional Encryption: If you need the Payload to be confidential, you can use JWE (JSON Web Encryption) instead of the standard JWS (JSON Web Signature). JWE encrypts the Payload, but it's a separate spec—JWT defaults to JWS for use cases where integrity matters more than secrecy (like user roles or basic identity info).

内容的提问来源于stack exchange，提问作者Jwan622