Quiz

B — Object-level authorization in order-service.

The caller is authenticated: the token is valid, so 401 would be wrong. The failure is authorization: only order-service knows who owns order 123, so it must compare the owner with the identity the gateway forwarded and answer 403 Forbidden (or 404) otherwise. This is Broken Object Level Authorization, the first item of the OWASP API Security Top 10 (2023).

C — Authorization Server.

The Authorization Server authenticates the user, obtains their consent, and issues tokens. The Resource Server validates tokens but never creates them. The Client requests tokens on behalf of the Resource Owner.

B — It prevents authorization code interception attacks.

Public clients cannot securely store a client_secret. PKCE generates a random code_verifier, hashes it to a code_challenge (SHA-256, base64url), and sends the challenge with the authorization request. Only the original client can complete the token exchange because only it knows the verifier. PKCE does not replace the secret of a confidential client — current best practice (RFC 9700) recommends PKCE for confidential clients as well.

aud (audience) — must contain the client_id of the receiving application. If a token's aud does not match, the client must reject it to prevent token substitution attacks where a token issued for one app is replayed against another. Resource servers apply the same rule to access tokens: reject any token whose aud is not their own API.

Use the refresh_token to request a new access_token from the Authorization Server. The app should not ask the user to log in again just because an access token expired — that is what refresh tokens are for. The refresh token is long-lived, stored securely by the client, and sent only to the Authorization Server. Only when the refresh token itself is expired or revoked must the user log in again. (A resource server that receives the expired token simply answers 401; it does not refresh anything.)

It publishes the Authorization Server's public signing keys so Resource Servers and the Gateway can validate JWT signatures locally, without calling the auth server on every request. Each key has a kid, and each JWT header names the kid that signed it. Key rotation is handled by updating the JWKS — services re-fetch on an unknown kid, so they always use current keys without redeployment.

ID Token = who the user is (identity). Access Token = what the client is allowed to do (authorization). The ID Token is consumed by the Client to learn about the user and establish a session; its audience is the client. The Access Token is sent to Resource Servers to authorize API calls; the client should treat it as opaque and never parse it. APIs must not accept ID tokens.

Client Credentials grant. The calling service authenticates with its own credentials (client_id and client_secret, or a signed assertion) to obtain an access token scoped to what it needs, such as stock:read. No user context is involved, making it the correct choice for machine-to-machine communication such as background jobs, scheduled tasks, or inter-service data pipelines.

B — Faster and more available, but revocation waits for exp.

With asymmetric keys the gateway only needs the public key from the JWKS, so no secret is copied (C is wrong) and no call is made per request. The price is revocation: a self-contained JWT stays valid until it expires, so logout is not immediate (D is wrong). That is why locally validated access tokens are kept short-lived and paired with refresh tokens; /auth/solve is a form of token introspection, which gives immediate revocation at the cost of a hop per request.

Its own X.509 certificate (and a proof that it holds the matching private key). In standard TLS only the server is authenticated to the client. In mTLS both server and client present certificates, so each side knows the other's identity — for example the SPIFFE ID spiffe://cluster.local/ns/store/sa/order-service. mTLS only proves who is calling; an authorization policy still decides whether that caller may call.

Even a call from service A to service B within the same Kubernetes cluster must present a valid identity credential and be authorised against a policy. Internal network location does not grant trust — every request is treated as potentially hostile. This prevents lateral movement after a breach, where an attacker who has compromised one service cannot freely reach others.

B — The CNI plugin does not enforce NetworkPolicy.

The Kubernetes API stores NetworkPolicy objects on any cluster, but enforcement is done by the network plugin. Calico and Cilium enforce policies; the default minikube network does not. Start minikube with --cni=calico to see the policy take effect.

Secrets are stored as base64-encoded strings in etcd, and base64 is not encryption — it can be trivially decoded (echo c3RvcmU= | base64 -d prints store). Without etcd encryption at rest and strict RBAC on Secrets, any principal allowed to read Secrets — or to create a pod that mounts them — can read them in plain text. Production systems enable encryption at rest, keep secret manifests out of Git, and often use an external secrets manager such as HashiCorp Vault or AWS Secrets Manager.

B — Unique, short-lived, automatically revoked credentials.

With a static password shared by every replica, a leak is valid until someone notices and rotates it — and rotating breaks everyone. With dynamic secrets, Vault creates a database user per lease (for example, one hour) and drops it at expiry; the audit log shows which workload used which credential.