IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
The big picture
You began with one question: who is calling your API, and can they prove it? Now you can choose a credential, carry it safely, guard the keys and close the gaps. This page walks one launch week through all of it.
The story you just lived
Maya's pilates studio opens its booking API to partners. Zara runs the launch review. She starts with the callers.
- Maya's browser app uses a hardened session cookie, with tokens on a backend-for-frontend.
- Sam's partner server asked for "an API key". It gets client credentials with private_key_jwt. His private key stays on his server.
- Bot A runs on the studio's cluster. It gets workload identity, with no stored secret.
- Kai books for Maya with a token Maya delegated, never her password.
Next, how credentials travel. They ride in a header, never a URL, because URLs are copied into logs and Referer headers. The gateway masks Authorization in logs. The API answers 401 for an expired token and 403 with insufficient_scope for a weak one.
Under that sits the connection. The server sends its full certificate chain. Nobody turns verification off. Sam's calls use mutual TLS with a certificate from the studio's private CA. The gateway removes any identity header a caller types in. ACME renews certificates before they expire.
The key that signs access tokens lives in a KMS, non-exportable. Rotation publishes the new key first. A webhook to Sam is signed with HMAC over the id, a timestamp and the raw body. Sam's handler checks before it parses, and ignores a retry it has seen.
Then Zara looks past credentials. Release-day bookings get business limits. The calendar import runs in an isolated fetcher, and its replies are checked like user input. The forgotten /v1 goes behind the gateway. The browser app gets a CORS allowlist with one origin. Each partner gets a token bucket, a quota, polite 429 replies and idempotency keys. Launch day is boring. That was the goal.
Six pictures to remember
- A notarized copy: a certificate is a stamp that you trust only through the chain behind it.
- A sealed courier parcel: TLS keeps the call private. Mutual TLS also checks the sender.
- A bank locker, not a flowerpot: keep keys where they can be used but not copied.
- A "payment received" SMS: check a webhook before you act on it.
- A hostel warden's list: CORS names who may read the reply.
- A tea stall with a rush: rate limits say "wait", not "never".
The threads that tie it together
Assume every credential leaks
Shorter lives, narrower permissions and proof of possession help most. Headers, masked logs and a leak playbook do the rest.
Keep the private key home
A certificate is public. Only the private key behind it proves anything.
Trust is only as good as its plumbing
Typed identity headers, switched-off verification and reflected CORS origins break good crypto.
Valid is not the same as safe
A genuine signature is not fresh. A valid request can be abuse. A polite client can still overwhelm you.
Next, the AI track puts agents like Kai on the other end of your API. It starts at AI and agents. To go deeper, revisit the API gateway, DPoP and certificate-bound tokens and SPIFFE workload identity. Ready? Take the cheat sheet and pop quiz.