Quiz

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, and sends the challenge with the authorization request. Only the original client can complete the token exchange because only it knows the verifier.

aud (audience) — must match 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.

Use the refresh_token to request a new access_token from the Authorization Server. The client should never 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 and stored securely by the client, used solely for this silent renewal.

It publishes the Authorization Server's public signing keys so Resource Servers and the Gateway can validate JWT signatures without calling the auth server on every request. Key rotation is handled by updating the JWKS — services re-fetch on a cache miss, ensuring they always use current keys without requiring 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 display user information and establish a session. The Access Token is sent to Resource Servers to authorize API calls and is opaque to the end user.

Its own X.509 certificate. In standard TLS only the server is authenticated to the client. In mTLS both server and client present certificates, creating mutual identity verification and ensuring that even if a valid access token is stolen, it cannot be replayed from an unknown workload.

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.

Secrets are stored as base64-encoded strings in etcd, and base64 is not encryption — it can be trivially decoded. Without etcd encryption at rest and strict RBAC on the Secret resource, any principal with kubectl get secret access can read all secrets in plain text. Production systems should use envelope encryption or an external secrets manager such as HashiCorp Vault or AWS Secrets Manager.

Client Credentials grant. The calling service authenticates with its own client_id and client_secret to obtain an access_token scoped to the specific downstream service. 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.