A vendor-neutral IAM cheat sheet for authentication, authorization, federation, OAuth, OIDC, SAML, least privilege, workload identity, secrets, privileged access, and zero trust.
Use this page for rapid identity and access review after reading the full Identity and Access Management guide. The goal is to identify the access layer being tested, choose the least risky credential pattern, and avoid confusing sign-in, permission, governance, and evidence.
| Concept | Primary question | Common wrong inference |
|---|---|---|
| Authentication | Can the principal prove identity? | Strong authentication grants broad permission. |
| Authorization | Is the requested action allowed? | A valid login means every action should work. |
| Federation | Can one identity provider authenticate users for another system? | Federation removes target-system authorization. |
| SSO | Can users use one sign-in experience across systems? | SSO means everyone can access every app. |
| Delegation | Can an app act with scoped permission without a password? | The app should receive the user’s password. |
| Least privilege | What is the smallest practical access for the task? | Read-only or temporary access is always safe. |
| Privileged access | Which powerful actions need extra control? | MFA alone justifies permanent admin. |
| Workload identity | How does a service prove identity? | Internal workloads do not need identity. |
| Secrets management | How are credentials and keys created, stored, used, rotated, and revoked? | A vault fixes poor permission design by itself. |
| Zero trust | How is each request verified by identity, device, context, policy, and telemetry? | A private network is automatically trusted. |
If the prompt says a principal cannot obtain a session, start with authentication or federation. If the principal has a session but receives access denied, start with authorization. If the action succeeds but nobody can explain who did it, start with accounting and privileged-access evidence.
| Prompt clue | Strong first thought |
|---|---|
| User sign-in plus identity claims for a modern app | OIDC |
| Scoped API access delegated to an app | OAuth 2.0 |
| Enterprise browser SSO to SaaS | SAML or OIDC, depending on platform support |
| Corporate directory signs users into cloud accounts | Federation with role or group mapping |
| CI/CD pipeline obtains cloud credentials without stored keys | Workload federation or OIDC trust |
| One object upload without reusable credentials | Presigned or scoped time-limited operation |
OIDC is authentication identity. OAuth is delegated authorization. SAML is common enterprise federation. They can coexist in one architecture.
| Requirement | Strong control |
|---|---|
| Map permissions to job functions | RBAC |
| Use tags, department, device, network, or risk context | ABAC or conditional policy |
| Let a resource enforce who can access it | Resource policy |
| Prevent broad actions across an organization | Guardrail, boundary, or organization policy |
| Reduce permanent administrator access | Privileged access management and JIT |
| Remove stale entitlements | Access review and lifecycle workflow |
| Prevent shared machine secrets | Workload identity and short-lived credentials |
Remember that guardrails usually limit what can be granted. They do not grant permission by themselves.
| Dimension | Ask |
|---|---|
| Action | Which exact operations are required? |
| Resource | Which resources, projects, accounts, namespaces, tables, secrets, or keys are in scope? |
| Condition | Which device, network, MFA, tag, time, region, or approval condition is required? |
| Time | Should access be permanent, temporary, session-based, or just-in-time? |
| Evidence | Can the action be attributed to an individual or workload? |
| Review | Who owns the access and when does it expire or get re-certified? |
The strongest answer often narrows more than one dimension.
| Environment | Prefer |
|---|---|
| Virtual machine | Instance or managed identity |
| Container or pod | Task, pod, or service account identity |
| Serverless function | Execution role or managed identity |
| CI/CD pipeline | Workload federation with issuer, audience, repository, branch, and environment constraints |
| Data pipeline | Dedicated service identity with scoped data and key permissions |
| Cross-system integration | Dynamic credential, certificate, or short-lived token where supported |
Avoid embedded long-term keys in source code, container images, local config files, and build logs.
| Requirement | Strong pattern |
|---|---|
| Routine administration | Dedicated admin identity, scoped role, strong authentication |
| Rare powerful action | Just-in-time elevation with approval or eligibility |
| Emergency access | Monitored break-glass process, tested and reviewed |
| Production change | Time-limited access tied to change window and evidence |
| Sensitive command execution | Session recording or command logging |
| Global administrator/root access | Minimal use, MFA, no routine keys, alerting, review |
If the answer shares a privileged account, stores root credentials casually, or disables logging, it is probably a distractor.
| Object | Handle as |
|---|---|
| Password | Human/account authentication secret |
| API key | Scoped application credential or identifier |
| Access token | Short-lived bearer credential for API access |
| Refresh token | High-value renewal credential |
| Certificate private key | Identity proof or signing/decryption secret |
| Encryption key | Cryptographic control requiring key policy and separation of duties |
| Database credential | Application-to-data authentication, often vault-managed or dynamic |
When a secret leaks, identify scope, revoke or rotate, redeploy safely, search for copies, and review activity during the exposure window.
| Trap | Corrective rule |
|---|---|
| “MFA fixes authorization.” | MFA proves identity more strongly; policy still limits actions. |
| “SSO means access is governed.” | SSO centralizes sign-in; entitlements still need review. |
| “Temporary credentials can be broad.” | Lifetime and scope are separate controls. |
| “Internal network equals trusted.” | Zero trust evaluates request context, not location alone. |
| “A valid token authorizes every API.” | Check audience, scope, claims, resource policy, and service policy. |
| “Vault storage fixes leaked design.” | Remove embedded-secret patterns where workload identity is available. |
| “Break-glass is normal admin access.” | Emergency access should be rare, monitored, protected, and reviewed. |
| “Guardrails grant access.” | Guardrails constrain grants; an allow still needs to exist. |