A service needs a database password, an API key, a TLS certificate. The naive approach: put secrets in environment variables, config files, or hardcode them. The problem: secrets in config files end up in git history. Environment variables get logged. Hardcoded secrets live in every build artifact. A centralized secrets management service solves this: services request secrets at runtime from a vault, which enforces access control and logs every access.

Your service delivers webhooks to customer endpoints. How does the customer know the POST came from you and not an attacker? Without authentication, any party that knows a customer’s webhook URL can forge events. Webhook signatures solve this: you sign each payload with a shared secret, the customer verifies the signature before processing. HMAC-SHA256 Signing Generate a secret per customer endpoint (not one global secret: if one leaks, only that customer is affected).

DNS was designed in 1983 with no authentication. A recursive resolver has no way to verify that the answer it receives actually came from the authoritative nameserver. This creates attack surface: an attacker who can inject a forged DNS response can redirect traffic for any domain to any IP. DNSSEC adds cryptographic signatures to DNS responses. Understanding the attacks first explains why DNSSEC exists. DNS Cache Poisoning The Kaminsky attack (2008): DNS queries use UDP, which is connectionless.

You log out. Your JWT is still valid. The server has no record it was ever issued. This is the stateless token revocation problem. Why Revocation Is Hard JWTs are stateless by design. The server validates a token by checking the signature and expiry. It doesn’t consult a database. This is what makes them fast and scalable. But it means there’s no central list of “valid tokens” to update when a token should no longer be accepted.

OAuth 2.0 is not an authentication protocol. It’s an authorization protocol. That confusion is the root of most OAuth misuse. What OAuth Actually Does OAuth lets a user grant a third-party application limited access to their account without sharing their password. The user sees a consent screen listing what the app wants to access. They approve. The app gets a token with exactly those permissions. Your password never leaves the authorization server.

The server doesn’t remember you. Every request carries proof of who you are. That’s the point of a token. The Structure A JWT is three base64url-encoded segments joined by dots: header, payload, signature. The header says which algorithm signed it. The payload carries claims: user ID, roles, expiry time. The signature is a cryptographic proof that the header and payload haven’t been tampered with. The server doesn’t need a database lookup to verify a JWT.