JWT: Everything you need to know to get started

JWT (JSON Web Token) is a powerful way to securely transmit data between parties, making authentication seamless in modern applications. Whether you're building APIs, handling user sessions, or implementing OAuth, understanding JWT is essential. This guide covers everything you need to know to get started!

Why JWT Needed?

In the client-server model, servers need to verify who's making requests. The simplest approach might seem to be sending username and password with every request. However, this creates several security and practical challenges:

• Security risks from transmitting sensitive credentials repeatedly

• The burden on clients to store credentials securely

• Server overhead from constant database lookups

• Increased vulnerability to man-in-the-middle attacks

Tip: While working with systems always consider client (web, mobile or third party) with suspicious, never trust them to do “right” thing.

Developers tried to solve these issues with session-based authentication, where servers generate sessionIDs after login. While this improved security, it introduced new challenges:

• Difficulty in scaling horizontally (adding more servers)

• Need for shared storage to manage sessions across servers If scaling horizontally enabled

• Continued database lookup overhead

JWTs are particularly powerful because they're self-contained and signed. This means all necessary user information is encoded within the token itself, and its integrity can be verified without accessing a database for every request.

Key Benefits of JWT

• Stateless authentication: Servers don't need to store session information

• Scalability: Add or remove servers without worrying about session management

• Token expiration: Built-in security through time-limited access

• Reduced database load: Servers can verify users without database lookups

Think of it like a tamper-proof receipt you get at a restaurant. Anyone can read what's on it, but nobody can modify it without detection.
Note: JWT doesn’t make your data aka credentials secure, it guarantees there haven’t been any tampering with data sent by other end.

Structure

A JWT consists of three distinct parts, separated by dots (.): the header, payload, and signature. Let's dive into each component:

Header

The header contains metadata about the token itself, specifically
alg The algorithm used for signing
type Type of token (mostly it’s jwt)
It helps these info helps party with which algorithm to use to verify token and it’s type

Payload

The payload (also called claims) carries the actual data. there are few standard fields/claims in payload that have universal meaning across platforms
Standard claims (commonly used):

• sub: Subject (usually user ID)

• iat: Issued At (timestamp of token creation)

• exp: Expiration Time

• iss: Issuer

Signature

The signature is the security seal that ensures the token hasn't been tampered with. Signature is what makes JWT secure, it ensures the token hasn't been modified

Flow

Let's dive into how JWT actually solves our authentication challenges through two main types of algorithms: Symmetric and Asymmetric. Both Algorithm have same initial flow of encoding header & payload and passing “encoded header.encoded payload" into algorithm to get signature.

Asymmetric Algorithms (eg: HS256)

Symmetric algorithms use a single secret key for both signing and verifying tokens. Think of it like a special lock where the same key both locks and unlocks the door.
HS256 (HMAC+SHA256) calculates hash twice along with the help of padding & key, ensuring any tempering with jwt will be detected.

Symmetric Algorithms (eg: RS256)

Asymmetric algorithms use a pair of keys: private and public. The private key signs the tokens, while the public key verifies them.
RS256 (RSA + SHA256) used RSA to encrypt encoded, dot concatenated header & payload using private key followed by hashing using SHA256. Client validates signature using public key by recalculating signature, if not tempered it should will same created using private key

Don’t share your secret/private key, make it secure & hard to reach by bad actors!

Each algorithm has its own use cases and trade-offs, and the choice should be based on your specific requirements. Symmetric algorithms are generally more performant than asymmetric ones. They are the better choice when building a single-server application where you control both ends, working with services within the same organization, or when performance is a critical factor. On the other hand, asymmetric encryption offers stronger security at the cost of performance and is better suited for scenarios such as building public APIs consumed by third parties or implementing OAuth.

Nothing is Perfect

While JWT elegantly solves many authentication challenges, it's not a silver bullet. Its strengths include stateless authentication, reduced database load, and cross-domain flexibility. However, it comes with its own challenges:

• Token Size: JWTs can be larger than session IDs, increasing bandwidth usage

• Token Revocation: Once issued, tokens remain valid until expiration unless you implement additional blacklisting mechanisms

• Data Storage: While tempting, storing too much data in tokens can bloat your requests

• Exposure Risk: Since tokens are stored client-side, they're vulnerable to XSS attacks if not properly secured

Hope you enjoyed the read! Feel free to share your thoughts and suggestions in the comments.