Implementing Authentication and Authorization Technologies
Authentication proves who a subject is; authorization decides what that subject may do. The DSST exam tests the distinction, the strength and failure modes of each factor, and how federation protocols fit together.
Core rules
- The classic factors are knowledge (password, PIN), possession (token, smart card, phone), and inherence (fingerprint, face). Location and behavior are risk signals, not classic factors.
- MFA requires two or more different categories; two passwords are not MFA. 2FA is MFA with exactly two factors.
- Store passwords with a salted, slow, memory-hard hash such as bcrypt, scrypt, or Argon2id. Never encrypt passwords or use fast hashes such as MD5 or SHA-1; a salt defeats precomputed tables and a pepper adds a secret.
- Harden sessions: unpredictable identifiers, Secure, HttpOnly, and SameSite cookies, idle and absolute timeouts, rotation after privilege changes, and invalidation at logout.
- OAuth 2.0 is delegated authorization: a client receives an access token to call an API on a user's behalf. It is not an authentication protocol. OpenID Connect adds an ID token and userinfo endpoint for authentication.
- SAML 2.0 exchanges signed XML assertions between an identity provider and a service provider for browser SSO. Kerberos issues ticket-granting tickets in AD domains. RADIUS centralizes network AAA; TACACS+ separates the three A functions and encrypts the entire payload.
- Access control models: discretionary (owner grants), mandatory (labels and clearances, as in SELinux), role-based (job roles), and attribute-based (context and attributes). Add least privilege, separation of duties, and need to know.
- FIDO2/WebAuthn security keys are origin-bound and resist real-time phishing; TOTP codes are better than SMS but can still be relayed by an adversary-in-the-middle proxy.
Worked example
A mobile app accepts an OAuth 2.0 access token from a provider and treats it as proof that the user is signed in. That is unsafe: access tokens are bearer credentials for API authorization, they can represent a client rather than a user, and scopes do not assert identity. The correct design uses OpenID Connect, validates the ID token's signature, issuer, audience, expiry, and nonce, and only then creates a local session. Reasoning: the token's purpose and audience must match the decision being made.
Traps that cost marks
Marks are lost by calling OAuth an authentication protocol, confusing hashing with encryption, calling any two credentials MFA, ignoring role explosion in RBAC, forgetting that SSO concentrates risk, and assuming biometric templates can be revoked like a password.