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
Cheat sheet & pop quiz
Here is the whole track on one page: nine ideas, a checklist for before you open an API, and five scenarios to prove it stuck.
Nine ideas that secure an API
| # | If you remember nothing else… |
|---|---|
| 1 | Sort credentials by what a stolen copy buys. API keys, passwords, cookies and bearer tokens travel whole, so a copy works. Signatures, mTLS and DPoP send only a fresh proof, and the private key stays home. Workload identity has no stored secret. Access tokens beat API keys because they live shorter and have narrower scopes. They are still bearer secrets. |
| 2 | Credentials go in headers, never URLs. HTTPS encrypts the query string on the wire. But URLs get copied into logs, history and Referer. 401 means no valid credentials. 403 means a known caller who still may not. |
| 3 | A certificate ties a public key to a name, signed by a CA. Clients check the chain up to a trusted root, every signature and date, the CA flags, the SAN and the purpose. Servers send leaf and intermediates. Never switch verification off. |
| 4 | TLS proves the server and protects the channel. It does not prove the user. Mutual TLS makes the client prove it holds its private key too. Map the certificate to one exact name, and still check permission. Behind a gateway, remove incoming identity headers. Trust them only from the gateway. |
| 5 | A key's worst enemy is a copy. Keep signing and encryption keys non-exportable in a KMS or HSM. Use envelope encryption for bulk data. Rotate with overlap and key ids. After a leak, pull the key at once. |
| 6 | Sign the canonical request, or the webhook's raw body. Verify before you parse. Compare in constant time. A valid signature does not prove the message is fresh. Add a signed timestamp window and remembered ids. |
| 7 | Some risks are not missing checks: valid requests abused at scale, a server tricked into fetching internal URLs (SSRF), unsafe setup, forgotten versions that still answer, and unchecked replies from other APIs. |
| 8 | CORS relaxes the browser's read rule for origins you name. It is not sign-in. It does nothing outside browsers. Never repeat back any origin with credentials. Use an exact allowlist. |
| 9 | Rate-limit by the right key (IP, client, user, tenant). Answer 429 and Retry-After. Keep quotas separate from rate limits. Use idempotency keys so retries are safe. |
Before you open an API, ask…
| The question | Where it is answered |
|---|---|
| Does each kind of caller use a credential that fits? What would a stolen copy buy? | The API sign-in menu · API keys vs OAuth |
| Could any credential end up in a URL or an unmasked log? | The Authorization header |
| Does every server send its full chain? Is verification on everywhere? | Certificates and chains of trust |
| Where does TLS end? Who may set identity headers after it? | TLS and mutual TLS |
| Can the signing key be copied out? Is the leak playbook written down? | Guarding private keys |
| Are webhooks checked over the raw body, fresh, and handled once? | Signed requests and webhooks |
| Can any feature fetch a URL a caller chose? Is every old version on your list? Do you check what partner APIs send back? | More ways APIs break |
| Which origins can read replies that use a user's cookies? | CORS and browser-facing APIs |
| What happens when one client sends a thousand times its normal traffic? | Rate limits, quotas and abuse control |
Pop quiz: five questions
Q1 · Sam's company wants to pull your customers' order history, with names and addresses, every night. They ask for "an API key, please". What do you offer instead? Why is it better?
Offer OAuth client credentials with private_key_jwt (or mutual TLS). Sam's server keeps its private key and sends you only the public half. Each night it signs a short assertion. It trades that for a token that lives minutes and is scoped to orders:read. An API key is a bearer secret that usually never expires, and it sits in two companies' systems. The key-pair option leaves nothing in your database that can sign in as Sam. A stolen token dies by itself (the sign-in menu).
Q2 · Priya finds lines like GET /v1/orders?api_key=k_live_… in the gateway's access logs. A teammate says: "It's HTTPS, the URL is encrypted." Who is right, and what should happen next?
Both are partly right, and it is still a leak. HTTPS does encrypt the query string on the wire. But URLs get copied at the two ends: into access logs like this one, browser history, Referer headers and screenshots. Anyone who can read those logs holds a working key. Rotate the key. Move it into a header. Make the API reject credentials in query strings. Mask credential headers and key-like query parameters in logs (the Authorization header).
Q3 · Your gateway checks partners' client certificates well. Then it tells the backend who called in a Client-Cert header. An attacker with no certificate sends a normal request with that header typed in, and gets partner data. What went wrong? What are the two fixes?
The cryptography was fine. The plumbing was not. A header is just text. A gateway that passes unknown headers through lets anyone choose their identity. Fix one: the gateway removes or overwrites any incoming identity header before it adds the one it verified. Fix two: the backend believes that header only from the gateway. Use mTLS between them, or a network path nothing else can reach. If not, an attacker who reaches the backend directly types the header there (TLS and mutual TLS).
Q4 · The private key that signs your partner tokens turns up in a public repository, in a .pem file. Your usual rotation publishes a new key, overlaps for a day, then retires the old one. Is that the right move today? What else changes?
No. Overlap is for routine days. Pull the leaked key's public half from the published key set at once, even though real sessions break. Move signing to a new key with a new key id. The key lived in a file, so no log can say if anyone used it. Treat every token it signed as possibly forged. Then fix the cause. Make the new key non-exportable, in a KMS or HSM. Only the token service may ask it to sign, and every use is logged (guarding private keys).
Q5 · Bot A's payment webhook handler parses the JSON, re-serializes it, and then checks the HMAC. Some real events fail the check. One busy night a slow reply made an order ship twice. What are the fixes?
Check the signature over the raw bytes before you parse. Re-serializing changes spacing or key order, so you checked different bytes than the provider signed. Check the signed timestamp against a tolerance window. Compare tags in constant time. Record each message id, so a retry gets a 2xx but is never handled again. Answer fast. Move slow work like shipping to a background queue. Then timeouts stop causing retries (signed requests and webhooks).
That is API security. You can choose a credential for every kind of caller and keep it out of URLs and logs. You can read a certificate chain and a TLS handshake. You can guard keys, check webhooks and spot SSRF, CORS and rate-limit mistakes. Next up is AI and agents. You put an AI agent on the calling end and give it an identity, limits and a kill switch. Start with the AI and agents intro.
Put the track to work on a real API. Check a client assertion with Client Assertion Check. Grade a certificate with Cert Lint. Look inside a DPoP proof with DPoP Check. Or browse the rest of the tools shelf. To secure your own APIs, see how we help or talk to our team.