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 API gateway — the checkpoint in front
Every request to your APIs should pass one guarded front door before it reaches a service. That door is the API gateway. Your goal: know what the gateway checks, and why services behind it must still check too.
- The gateway is one door that every outside call must pass.
- It checks the token, then the scope, then the rate limit.
- It cannot check who owns each record. The service must.
- Inside, services prove who they are to each other with mTLS.
The gateway is your enforcement point
In the words of policy as code, the gateway is the Policy Enforcement Point (PEP) for your whole API. Every call must pass it, so a rule you set there holds everywhere. It sees all north-south traffic: clients outside talking to services inside. Without it, each service writes its own checks, and the weakest copy becomes the way in.
the watchman at a society gate. They check each visitor's pass and note the vehicle number. They stop anyone who comes at 3 a.m. for no reason. But they do not know which flat belongs to whom. A guest with a valid pass can still knock on the wrong door. The service behind the gate must check that.
What the door checks, in order
🔏 1. Authenticate locally
Check the JWT's signature, expiry, audience and issuer at the edge, with cached signing keys. There is no trip to the identity provider for each call. It still catches forged, old or wrong-audience tokens.
🎯 2. Enforce scopes
Each route asks for the scope it needs, such as bookings:write to book. A valid token with the wrong scope gets 403 insufficient_scope before the service runs.
⏱️ 3. Rate limits
Per-client limits keep things fair and stop a runaway agent (see the agent registry). Over the limit gives 429 with a Retry-After header.
🧹 4. Schema validation
Reject broken or oversized bodies and unexpected fields. Junk input never reaches your code.
The gateway sees the token and the route. It does not know who owns booking 1002. So the service must still ask "is this booking hers?" You will see why in the OWASP tour.
The candy-shell mistake
A candy has a hard shell and a soft center. Some systems are the same: the gateway checks everything, but the services behind it trust anything that got in. They have no login and use plain HTTP on a "private" network. One foothold inside lets an attacker walk anywhere.
Zero trust says: check again inside. Put mTLS and a service identity on the east-west traffic (service to service). Then each service proves who it is to the next. The gateway guards the front door. mTLS locks the inner doors too.
North-south and east-west traffic are two different places to attack. The candy-shell mistake defends only the first. A gateway that checks every request, plus services that never blindly trust each other, means one broken part cannot become the whole estate. This is defense in depth. It assumes the shell will crack one day.
🧪 Interactive lab — enable JavaScript to play with this one.
Check your gateway's JWT policy for gaps with Gateway JWT Lint. Grade an AI-gateway setup with AI Gateway Check. Then see the attacks the door must stop in the OWASP API Top 10 tour.