Identity & Access Management (IAM) Cheat Sheet
Covers IAM core concepts including authentication protocols, RBAC/ABAC models, and provisioning lifecycle for enterprise access control.
2 PagesIntermediateFeb 12, 2026
Core IAM Concepts
Foundational terms distinguishing identity and access functions.
- Authentication (AuthN)- Verifying who a user or system is (e.g. password, MFA, certificate)
- Authorization (AuthZ)- Determining what an authenticated identity is allowed to do
- Provisioning- Creating and configuring accounts and access when a user joins/changes roles
- De-provisioning- Revoking access promptly when a user leaves or changes roles
- SSO- Single Sign-On; one login session grants access across multiple applications
- Federation- Trust relationship allowing identity from one domain to be used in another
Access Control Models
Different strategies for determining who can access what.
- RBAC- Role-Based Access Control; permissions assigned to roles, users assigned to roles
- ABAC- Attribute-Based Access Control; decisions based on user/resource/environment attributes
- DAC- Discretionary Access Control; resource owner decides who gets access
- MAC- Mandatory Access Control; access governed by fixed system-wide policy (e.g. classification labels)
- PoLP- Principle of Least Privilege; grant only access strictly required for the role
SSO Protocol Basics
Simplified flow comparison of two common federated identity protocols.
text
# SAML (XML-based, common in enterprise SSO)1. User requests app -> App redirects to IdP2. IdP authenticates user, generates signed SAML assertion3. Browser POSTs assertion to app's Assertion Consumer Service (ACS)4. App validates signature, creates session# OpenID Connect (JSON/OAuth2-based, common in modern web/mobile)1. App redirects to IdP's /authorize endpoint2. User authenticates, IdP redirects back with an authorization code3. App exchanges code for an ID token (JWT) at the /token endpoint4. App validates the JWT signature and claims
IAM Best Practices
Habits that reduce identity-related risk in an organization.
- Enforce MFA everywhere- Especially for privileged and remote access accounts
- Just-in-time access- Grant elevated privileges only for the duration needed, then auto-revoke
- Regular access reviews- Periodically recertify that granted access is still required
- Centralize identity- Use a single IdP rather than app-specific credential stores
- Audit logging- Log all authentication and privilege-change events for investigation
OAuth 2.0 Grant Types (When to Use Which)
Token request shapes for the grant types you'll actually encounter in enterprise IAM.
text
# Authorization Code + PKCE — web/mobile apps with a user presentPOST /token grant_type=authorization_code code=SPLXlOBeZQQYbYS6WxSbIA code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk redirect_uri=https://app.example.com/callback client_id=abc123# Client Credentials — service-to-service, no user contextPOST /token grant_type=client_credentials client_id=service-a client_secret=*** scope=orders:read# Refresh Token — extend a session without re-prompting loginPOST /token grant_type=refresh_token refresh_token=tGzv3JOkF0XG5Qx2TlKWIA# Device Code — input-constrained devices (CLI, smart TV)POST /device_authorization -> returns user_code + verification_uri
SCIM User Provisioning Payload
The standard protocol IdPs use to automatically create/update/deactivate accounts in downstream apps.
json
POST /scim/v2/Users{ "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], "userName": "[email protected]", "name": { "givenName": "Jane", "familyName": "Smith" }, "emails": [{ "value": "[email protected]", "primary": true }], "active": true, "groups": [{ "value": "finance-team" }]}# Deactivation on termination (PATCH, not DELETE, preserves audit trail)PATCH /scim/v2/Users/2819c223{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [{ "op": "replace", "path": "active", "value": false }]}
Validating an ID Token / Access Token (JWT)
The checks a resource server must perform beyond just verifying the signature.
python
import jwtfrom jwt import PyJWKClientjwks_client = PyJWKClient("https://idp.example.com/.well-known/jwks.json")signing_key = jwks_client.get_signing_key_from_jwt(token)claims = jwt.decode( token, signing_key.key, algorithms=["RS256"], # never allow 'none' or accept alg from the token header audience="api://orders-service", issuer="https://idp.example.com/", options={"require": ["exp", "iat", "aud", "iss"]},)# Still application-level checks after signature/claims pass:assert claims["scope"].split().__contains__("orders:read")assert claims.get("amr") and "mfa" in claims["amr"] # step-up auth was actually performed
ABAC Policy Expression (Cedar-style)
Attribute-based rule combining subject, resource, and environment attributes into a single decision.
text
permit( principal, action == Action::"viewInvoice", resource)when { principal.department == resource.owningDepartment && principal.clearanceLevel >= resource.sensitivityLevel && context.network.isCorporate == true && context.time.isBusinessHours == true};
IAM Anti-Patterns to Eliminate
Common real-world failures that quietly accumulate identity risk.
- Shared service accounts- Multiple humans or scripts using one credential makes audit attribution impossible; use per-identity workload credentials instead
- Standing admin access- Permanent privileged roles instead of just-in-time elevation dramatically widen the breach blast radius
- Local/app-specific accounts alongside SSO- Break-glass accounts that bypass the IdP become forgotten, unmonitored backdoors
- Role explosion- Hundreds of near-duplicate RBAC roles created ad hoc become impossible to audit; consolidate with attribute-based rules instead
- Long-lived API keys- Static secrets checked into config never expire on their own; prefer short-lived tokens via workload identity federation
- No entitlement review cadence- Access granted for a project that quietly outlives the project itself ("privilege creep")
Pro Tip
Automate de-provisioning by tying it to your HR system's termination event — manual offboarding is the single most common source of orphaned accounts that attackers find and exploit months later.
Was this cheat sheet helpful?
Explore Topics
#IdentityAccessManagementIAM#IdentityAccessManagementIAMCheatSheet#Cybersecurity#Intermediate#CoreIAMConcepts#AccessControlModels#SSOProtocolBasics#IAMBestPractices#Security#InfrastructureAsCode#CheatSheet#SkillVeris
