Security, Identity, and Access Control
Security, Identity, and Access Control covers authentication, authorization, secret handling, and tenant isolation. The exam asks you to choose a flow, scope a token, and explain why a shortcut fails under attack.
Identity and tokens
- OAuth 2.0 handles delegated authorization; OIDC adds identity on top. Use Authorization Code with PKCE for user-facing clients, client credentials for service-to-service, and never implicit.
- Access tokens are short-lived (5–15 minutes) and audience-bound. Refresh tokens are long-lived, rotated, and stored securely server-side.
- Validate signature, issuer, audience, and expiry on every request. Never decode-only and trust the claims.
- Scopes are coarse capability grants; enforce fine-grained authorization (RBAC/ABAC) server-side from subject, resource, and action - never from anything the client sends.
Secrets and data
- Secrets live in a managed vault, are injected at runtime, and rotate on schedule - never in git, images, or CI logs.
- Encrypt in transit with TLS 1.2+ and at rest with KMS; envelope encryption lets data keys rotate without re-encrypting the whole corpus.
- Multi-tenant isolation: derive the tenant from the authenticated principal, not from a request parameter, and enforce it at the data layer with row-level security where available.
Worked example
Service A calls Service B. A static API key in an environment variable is long-lived, shared, and hard to attribute. Replace it with client credentials: A authenticates with its own client ID and a vault-sourced secret, receives a 10-minute token with audience service-b and scope orders:read, and B validates issuer, audience, and scope on each call. Compromise of A's secret now yields at most 10 minutes of access to one audience, and every call is attributable in the audit log.
Traps
- Confusing authentication with authorization: a valid token does not mean permission for this record.
- Trusting a tenant_id or role sent in the request body.
- Tokens in URLs, query strings, or logs.
- One shared admin credential used by every service.
- Encryption without key rotation or access control on the key itself.
- No audit trail for privileged actions.