Authentication Demo

01 How Do You Get a Token?

You can't just ask a secure API for an authorization token. In a standard application, you must prove your identity first by sending credentials (like a password) to a login backend.

If the credentials match, the backend issues an expiring JWT. Sending your password over the network on every single API request is both dangerous and slow. A JWT acts as a Temporary Access Grant. Once the server verifies your credentials, it hands you a cryptographically-signed grant. For the rest of your session, you never expose your password again. All your user requests will include the JWT grant in the header.

What is happening in this demo? To let you test this UI without making you create an account, my backend is actively issuing Anonymous Passwordless Tokens.

Why would a server ever issue anonymous tokens? DDoS Mitigation & Rate Limiting. By forcing unauthenticated clients to negotiate a cryptographic handshake and receive a JWT before they are permitted to hit backend endpoints, the API Gateway can track connections and drops abusive IPs entirely at the network edge without tying up backend server threads or database connections.

Without a valid token, the gateway bounces you natively. My backend has a protected /contact endpoint. Watch what happens if you attempt to hit the API without a JWT.

02 The Anatomy & Tracking

A JWT consists of three pieces of text separated by dots: Header.Payload.Signature.

• Header: Created by the server. It simply declares the token type (JWT) and the hashing algorithm used to secure it (like HS256).
• Payload: Created by the server. This is where user tracking happens. Instead of a database looking up "Session #1234", the payload directly embeds your user data as JSON claims (e.g. sub: "user_1").
• Signature: Created by the server using a secret key. It acts as the mathematical seal of trust.

Because the Header and Payload are just Base64Url encoded—NOT encrypted—anyone can read them easily by splitting the string at the dots. Never put sensitive data inside.

03 What is Actually Being Verified?

If the payload is just Base64 JSON, why not just send raw JSON headers to the API? Why wrap it in a JWT at all?

Because if the API is stateless and doesn't check a database, it needs a way to guarantee the data is authentic. The API needs to verify exactly one thing: who issued the data.

When you initially log in with a password, the backend creates your JSON payload and hashes it against a highly guarded Private Secret Key to generate a unique Signature.

When you send the token back, the API Gateway recalculates that hash. If the hashes match, it mathematically proves two things instantly, all without touching a database:

• Proof of Origin: The token was definitely generated by this exact backend server (because nobody else knows the private secret).
• Proof of Integrity: Not a single comma in the payload has been altered since the server originally signed it.

04 Expiration

There is a massive tradeoff with stateless authentication: you cannot easily revoke a token.

Because the API Gateway doesn't query a central database, there is no master "session list" where an admin can execute a logout command and immediately kill your access. If an attacker steals your token, the gateway has no way of knowing it was stolen. It only checks the mathematical signature, which is still valid.

To solve this, JWTs embed an exp (Expiration Time) claim directly into the payload as a Unix timestamp. Best practices mandate that JWTs be extremely short-lived (e.g., 15 minutes). Once that exact second passes, the API Gateway automatically rejects the token, forcing the frontend application to silently refresh the grant. If you unmask the Payload above, you will see the exp timestamp governing this session.