A door has two sides
Part E gave the gateway a way to name a consumer with a subscription key. A name is not a proof. A subscription key is a long random string in a header — it tells the gateway which consumer claims to be calling, but it is a bearer token in the oldest, weakest sense: anyone holding the string is treated as the holder, and the string ends up in logs, browser histories, curl commands pasted into chat, and the occasional public repository. For a partner reading a catalogue that is a reasonable trade. For anything that moves money or touches a person's data, "whoever holds this string is trusted" is not a sentence you want read back to you in an incident review.
So this part is about strength, and it has two sides — because a gateway is a door, and a door is only as secure as its weaker face. The front is the caller proving who they are to APIM: keys, then OAuth2 tokens, then client certificates, each a stronger proof for a higher-stakes caller. The back is APIM proving who it is to the backend, and doing so without a password sitting in a config file — because a backend that accepts calls from anywhere has quietly made the whole front-door effort decorative. Secure one side and forget the other and you have not built a door; you have built a doorframe.
- Subscription key
- An identifier and a weak secret in one string. Good for "which consumer," poor for "prove it" — it is a bearer credential with no expiry and no cryptography behind it.
- OAuth2 / JWT
- A short-lived, signed token issued by an identity provider (Microsoft Entra). The validate-jwt policy checks its signature, issuer, audience, and expiry at the door — a real proof of identity, not just a name.
- Client certificate / mTLS
- The caller presents a certificate during the TLS handshake and APIM verifies it (thumbprint, issuer, subject, expiry). Strong, mutual authentication for machine-to-machine partners who can hold a private key.
- Managed identity
- APIM's own Entra identity, used to authenticate to a backend or to Key Vault without a stored secret. The back-door credential that no human ever types or pastes.
- Named Values / Key Vault
- APIM's key-value store for policy configuration. Values can be plain, marked secret, or a reference to a Key Vault secret — so the real secret lives in the vault and rotates there, never in the policy text.
The front door — from a key to a signed token
Start where most APIs start: the subscription key, carried in the Ocp-Apim-Subscription-Key header. It is enough to identify a partner and drive the per-consumer arithmetic of 38d, and for a low-stakes read API it is a defensible stopping point. Its weaknesses are the weaknesses of any bearer string: it does not expire on its own, it carries no claims about who the human is, and if it leaks the holder is trusted until you notice and rotate. You keep it for identity and metering; you do not lean on it for anything you would not write on a postcard.
The upgrade is OAuth2 with JWT validation. Instead of a static string, the caller obtains a short-lived, signed token from an identity provider — Microsoft Entra, in the Azure world — and presents it as a bearer token. At the door, the validate-jwt policy does the work the key never could: it checks the token's signature against the issuer's published keys, confirms the iss (who issued it) and aud (who it was meant for), enforces expiry, and can require specific claims or scopes before the request is allowed through. An unauthenticated or expired token is rejected at the gateway, so the backend never spends a cycle on a request that had no business arriving.
Here is the shape of it — readable, and doing exactly what it says:
<!-- inbound: reject anything without a valid Entra token -->
<validate-jwt header-name="Authorization"
failed-validation-httpcode="401"
failed-validation-error-message="Unauthorized">
<openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" />
<audiences><audience>api://campux-catalog</audience></audiences>
<required-claims>
<claim name="roles" match="any"><value>Catalog.Read</value></claim>
</required-claims>
</validate-jwt>
Notice what moved: the gateway is no longer asking "do you hold a string I recognise" but "do you carry a signed, unexpired token, from the issuer I trust, minted for this API, bearing the role this operation requires." That is the difference between a name badge and a passport.
A key is a name badge; a token is a passport.
Client certificates and mTLS — proof that cannot be pasted
For machine-to-machine partners — a payment processor, a bank, a partner whose contract demands it — the strongest front-door proof is a client certificate. In mutual TLS (mTLS), the server proves its identity to the client as usual, and the client proves its identity to the server by presenting a certificate during the TLS handshake. Because the private key never leaves the caller's machine, there is no string to leak, paste, or commit — possession of the key is the proof, and possession cannot be copied out of a log file.
In APIM you verify the presented certificate in an inbound policy: check its thumbprint against an allow-list, or validate its issuer and subject, and confirm it has not expired or been revoked. A common shape checks that the certificate was issued by a CA you trust and carries a subject you expect, so only a caller holding a specific, currently-valid certificate gets through. One operational detail earns its keep in interviews: for the gateway to receive a client certificate at all, the host must be configured to negotiate (request) the client certificate during the handshake — on a consumption or custom-domain setup that is an explicit setting, and forgetting it is why "my mTLS policy sees no certificate" is a support ticket, not a bug in your policy.1
Ranked by strength, the front door reads: subscription key (identifier, weak secret), JWT (signed, short-lived, claim-bearing), client certificate (cryptographic possession, hardest to steal). You do not use the strongest everywhere — you match the proof to the stakes. A public catalogue read gets a key; a partner writing orders gets a token with a scope; a processor moving money gets mTLS.
The back door — a credential no human types
Now the side beginners forget. Once the gateway has authenticated the caller, it must call the backend — and the backend should trust the gateway and no one else. The lazy way is a stored password or a shared key in the policy: a secret in text, in a config, one screenshot or repo-leak away from being everyone's. The right way is a managed identity.2 APIM is assigned its own identity in Entra (system-assigned, tied to the instance, or user-assigned, a standalone identity you attach), and the authentication-managed-identity policy has the gateway fetch an Entra token for a named resource and attach it to the backend call — no secret stored, no secret to rotate, no secret to leak.
<!-- inbound: get a token for the backend as APIM's own identity -->
<authentication-managed-identity resource="api://campux-orders"
output-token-variable-name="msi-token" />
<set-header name="Authorization" exists-action="override">
<value>@("Bearer " + (string)context.Variables["msi-token"])</value>
</set-header>
The backend is then configured to accept only tokens for that identity, which closes the loop: the only caller it will answer is the gateway, and the gateway carries a credential that exists nowhere as a copyable string. The same identity fetches secrets from Key Vault, which is where the other secrets go.
Because some secrets are unavoidable — a third party's API key, a legacy backend that only speaks passwords — APIM gives you Named Values: a key-value store you reference from policy as {{name}}. A named value can be plain (fine for a non-secret like a base URL), marked secret (masked in the portal and logs), or best, a Key Vault reference — the named value points at a secret in Key Vault, APIM reads it using its managed identity, and the real secret lives and rotates in the vault, never in the policy text or a template. The rule that survives every audit: secrets belong in Key Vault, referenced; never inline in a policy, and never in source control.
Three callers, three proofs
Campux does not secure everything the same way, because the callers are not the same. The two marketplaces reading the catalogue keep their subscription keys — identity and metering, nothing that moves money. The order-amendment operations the marketplaces call are lifted to validate-jwt: each partner's integration presents a signed Entra token with a Orders.Write role, and an expired or unscoped token is refused at the door, so the orders backend never sees a request it would have to reason about. The new payment processor — the one caller that literally moves money — authenticates with a client certificate, thumbprint allow-listed, because a private key cannot be pasted into a channel the way a string can.
Behind the desk, the change nobody sees is the one the auditor cares about most. APIM calls the orders and payments backends with its own managed identity; those backends accept that identity and refuse everything else, so there is no shared backend password anywhere in the estate. The one unavoidable secret — a legacy shipping provider's API key — lives in Key Vault, referenced by a Named Value the policy reads as {{shipping-key}}. The engineer who once pasted that key into a policy during a late deploy has the pull request pinned above the whiteboard, annotated in red pen: this is what the vault replaced.
Both faces locked
The door is now a real door. The front proves the caller — a key for the curious, a signed token for the trusted, a certificate for the one who moves money — and the back proves the gateway to a backend that will answer no one else, with a credential no human ever types. The subscription of Part E is still the unit you meter and revoke; this part just made the proof behind it strong enough to trust with something that matters. What is left is to make sure the wire itself cooperates: that the backend is not quietly reachable around the gateway, and that the only network path to it runs through this desk. That is the whole of Part G.
The password in the pull request
A teammate's pull request adds a backend call and, to make it work, pastes the backend's API key straight into the policy XML: Authorization: ApiKey abc123…. It works in the demo, which is exactly the trap. You block the merge and explain the two-line fix rather than the scolding: the secret moves into Key Vault, a Named Value references it, and the policy reads {{backend-key}} — or, better, the backend is switched to accept APIM's managed identity and the key disappears entirely. The cost of the lazy version is not hypothetical: that repo is mirrored to three laptops and a CI cache, so the moment it merges, the key is un-rotatable without a coordinated scramble, and it is one git log away from anyone who ever clones the project. Ten minutes now, or an afternoon and an apology later.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B — a key is a name badge, not a passport. It tells the gateway which consumer claims to be calling, which is exactly what per-consumer metering and revocation need, but it carries no proof: no signature to verify, no expiry to bound the damage of a leak, no claims about the human behind the call. Whoever holds the string is trusted, and the string ends up in logs, browser history, and the occasional public commit. A misdiagnoses the problem as length — a longer bearer string is still a bearer string. C is false: keys travel over TLS like everything else, so wire-sniffing is not the weakness. D is simply wrong — keys identify any consumer. The fix is not a bigger key; it is a different kind of credential — a signed, short-lived token — where the stakes justify it.
B — the credential that no human ever types. APIM is assigned its own identity in Entra; the authentication-managed-identity policy fetches a token for the named backend and attaches it, and the backend is configured to accept only that identity. There is no secret stored anywhere, so there is nothing to leak and nothing to rotate on a schedule. A is better than nothing but still puts a real secret in the system — even masked, it exists and must be rotated; managed identity removes the secret entirely. C is the anti-pattern this whole part exists to kill: a secret in policy text is a secret in source control. D confuses front-door identity with back-door identity — the caller's key proves the caller to the gateway; it says nothing the backend should trust, and forwarding it hands the backend a bearer string it has no way to validate.
Signature, audience/issuer/expiry, required claims. Those three are exactly what turns a bearer string into a proof: the signature check means the token was really minted by the issuer you trust; the aud/iss/expiry checks mean it was meant for this API and is still valid; the claim check means the caller carries the role this operation demands. The two rejects are jobs that belong elsewhere. Encrypting the body is TLS's job, not the JWT policy's — validation reads the token, it does not encrypt payloads. And issuing the token is the identity provider's job (Entra); APIM validates tokens, it does not mint them. Keep the roles clean: Entra issues, the gateway validates, the backend trusts what the gateway let through.
# apim security checklist
1. validate-jwt on write operations: signature,
audience, issuer, expiry, required role.
2. Payment processor authenticates with a client
certificate (mTLS), thumbprint allow-listed.
3. Backend key stored inline in the inbound policy
XML so deploys are self-contained.
4. APIM uses a managed identity to read secrets
from Key Vault; no passwords in templates.
Line three — and notice it contradicts line four. "Self-contained deploys" is the seductive phrasing, but a secret pasted into policy XML lives in the ARM/Bicep template, which lives in the repo, which lives on every laptop and CI cache that ever cloned it. The same instance is doing it correctly one line down — line four keeps secrets in Key Vault and reads them with a managed identity, exactly the pattern line three abandons. A is wrong and dangerous: expiry is the whole point of a short-lived token; a valid signature on an ancient token still lets a stolen credential live forever. B inverts the risk model — a processor moving money is precisely where the strongest proof (mTLS) belongs, not the weakest. D is false: reading Key Vault with a managed identity is the recommended pattern and is what line four correctly describes. Move the line-three secret into the vault and reference it, and the checklist is coherent.
The trap is treating identification and authentication as the same word. Concede the true part first: the key does a real job — it names the consumer, drives per-partner limits, and lets you meter and revoke. That is identification, and it is worth keeping. But naming is not proving. A subscription key is a static bearer string with no expiry, no signature, and no claims; whoever holds it is trusted, and it accumulates in logs, shell history, and repos. For a read-only catalogue that trade is fine. This API amends orders — it moves money and commitments — and there "whoever holds the string is trusted" is the sentence you do not want read back in the post-incident review.
Then make the upgrade concrete, not ceremonial. OAuth with validate-jwt changes what the gateway checks: not "do you hold a string I recognise" but "do you carry a signed, unexpired token, from the issuer I trust, minted for this API, bearing the role this operation requires." Expiry alone bounds the blast radius of a leak from forever to minutes; the signature makes forgery a cryptographic problem, not a copy-paste one; the role claim means a token good for reading cannot write. None of that is ceremony — each line is a specific attack the key cannot answer.
Close by matching proof to stakes, not by maximising it. You are not arguing for mTLS on the catalogue or tokens on a health check. You are saying: keep the key for identity and metering, and add a validated token on the operations that change state, because the cost of the token is a few lines of policy and the cost of not having it is a leaked string amending orders for as long as nobody notices. The key tells you who is knocking; the token is why you open the door.
Open by insisting a door has two sides. "Most people secure the front and forget the back — but a backend reachable around the gateway makes the front-door effort decorative, so I design both together." That framing is the senior tell; it shows you know the failure mode before the interviewer names it.
Rank the front door by stakes. "For a public read, a subscription key identifies and meters the consumer — enough. For anything that changes state, I add OAuth with validate-jwt: signature, audience, issuer, expiry, and a required role, all checked at the gateway so an unauthenticated request never reaches the backend. For a machine-to-machine partner moving money, I require a client certificate — mTLS — because possession of a private key can't be pasted into a log the way a string can. I match the proof to the stakes rather than putting the strongest thing everywhere."
Then lock the back door and put every secret in one place. "Behind the gateway, APIM authenticates to the backend with its own managed identity — the authentication-managed-identity policy fetches an Entra token, the backend accepts only that identity, and there is no stored secret to leak. Where a real secret is unavoidable, it lives in Key Vault and the policy references it through a Named Value — never inline in policy XML, never in a template, never in the repo. One rule ties it together: secrets belong in the vault, referenced by an identity, and the only road to the backend is through this desk." That last line — identity on both faces, secrets in one vault — is the whole answer in a sentence.
Five things worth carrying out of this part
- A gateway is a door with two sides: the front proves the caller to APIM, the back proves APIM to the backend. Secure one and forget the other and you have a doorframe, not a door.
- A subscription key identifies a consumer; it does not authenticate one. It is a static bearer string — a name badge. Keep it for metering and revocation, not for anything that moves money.
- Match the front-door proof to the stakes: key for a public read, OAuth2 with validate-jwt (signature, audience, issuer, expiry, role) for state changes, client certificate / mTLS for a machine partner moving money.
- Lock the back door with a managed identity: the authentication-managed-identity policy fetches an Entra token, the backend accepts only that identity, and there is no stored secret to leak.
- Secrets belong in Key Vault, referenced by a Named Value and read with a managed identity — never inline in policy XML, never in a template, never in source control.
- The negotiate-client-certificate detail is genuinely fiddly and tier-dependent: for APIM to receive a client certificate, the host must be configured to request one during the TLS handshake, and the exact setting differs across the Consumption tier, custom domains, and the self-hosted gateway (which requires the client to present its certificate in the initial handshake rather than renegotiating). If a correct-looking mTLS policy reports "no certificate," suspect the negotiate setting before you suspect your policy. ↩
- Treat the specific mechanisms here as current-but-moving. Azure's identity surface evolves — managed-identity behaviour, Key Vault reference handling, and the exact JWT claim set Entra emits have all shifted over releases, and vendor defaults change faster than any class can. The direction is settled and safe to memorise for an interview: signed short-lived tokens over static strings, identities over stored secrets, vault references over inline secrets. Verify the exact policy attributes against current Microsoft Learn before you ship them to production. ↩