Identity, Access, and Authentication
Identity, Access, and Authentication tests how systems prove identity and enforce permissions. CJCA questions cover factors, federation protocols, access models, and credential storage.
Core rules
- Authentication factors: something you know, have, or are. MFA requires two different factor types; two passwords are not MFA.
- Authorization models: RBAC assigns permissions by role; ABAC uses attributes such as department, time, or device posture. Least privilege and periodic access reviews apply to both.
- Password storage must use a slow, salted hash such as bcrypt, scrypt, or Argon2, not fast hashes or reversible encryption.
- Federation: SAML exchanges assertions for web SSO; OAuth 2.0 delegates authorization; OpenID Connect (OIDC) adds authentication on top of OAuth 2.0. Kerberos issues tickets in Windows/AD environments; LDAP is a directory protocol, not an authentication protocol by itself.
- PAM controls privileged accounts with vaulting, session recording, and just-in-time access.
Worked example
An application wants “Sign in with Google” and needs the user’s verified identity. The correct choice is OIDC, because it provides an ID token with authentication claims. OAuth 2.0 alone is an authorization framework for delegated access and should not be used as proof of identity. The app should validate the token signature, issuer, audience, and expiry, and should never collect or store the user’s Google password.
Traps
OAuth is not authentication. SAML is not the same as OAuth. MFA fatigue attacks push repeated prompts until a user approves; number matching and phishing-resistant factors reduce this. Hashing is not encryption. A role assignment is authorization, not authentication.