Authentication, MFA, SSO and Federated Identity

Why This Topic Matters
Authentication is the gateway to every other security control. If an application cannot reliably establish who or what is making a request, then authorization, accountability, auditing and non-repudiation all collapse. For the CSSLP, authentication sits squarely inside Domain 1 (Secure Software Concepts) as a core security design principle, and it reappears in Domains 3 (Secure Software Architecture and Design), 4 (Secure Software Implementation) and 5 (Secure Software Testing). Broken authentication consistently ranks near the top of the OWASP Top 10 (Identification and Authentication Failures), and credential-based attacks remain the leading initial access vector in real-world breaches. A CSSLP is expected to understand not just the mechanisms but the design trade-offs: usability versus assurance, centralization versus single point of failure, and convenience versus least privilege.

Core Definitions You Must Know
Identification is the act of claiming an identity (entering a username, presenting a certificate). Authentication is proving that claim. Authorization is deciding what the authenticated entity may do. Accountability is tying actions back to the authenticated identity through logging and auditing. The exam frequently tests whether you can keep these four concepts separate; a question describing a user entering a password is about authentication, a question about a user being denied access to a file after logging in is about authorization.

Authentication Factors
The classic factor categories are:
1. Something you know (Type 1): passwords, passphrases, PINs, security questions.
2. Something you have (Type 2): smart cards, hardware tokens, OTP generators, mobile authenticator apps, FIDO2 security keys.
3. Something you are (Type 3): biometrics such as fingerprint, iris, face, voice.
Some frameworks add somewhere you are (geolocation, network location) and something you do (behavioral biometrics such as typing cadence). For exam purposes, these are usually treated as contextual or adaptive attributes rather than true independent factors.

Multi-Factor Authentication (MFA)
MFA requires two or more factors from different categories. This is the most common trap on the exam: a password plus a PIN is not MFA because both are something you know. A password plus a one-time code from an authenticator app is MFA. Two-factor authentication (2FA) is simply MFA with exactly two factors.

Key MFA mechanisms:
- OTP (One-Time Passwords): HOTP (counter-based, RFC 4226) and TOTP (time-based, RFC 6238). TOTP codes typically rotate every 30 seconds and are generated from a shared secret seeded at enrollment.
- SMS and voice OTP: widely deployed but considered weak because of SIM swapping, SS7 interception and phishing. NIST SP 800-63B restricts (but does not fully prohibit) out-of-band authentication via the public switched telephone network.
- Push notifications: convenient but vulnerable to MFA fatigue or prompt bombing attacks unless number matching or contextual information is included.
- Hardware tokens and smart cards: strong possession factors, often combined with a PIN to unlock (making the card itself a two-factor device).
- FIDO2 / WebAuthn / passkeys: public-key cryptography bound to the origin domain, making them phishing-resistant. Private keys never leave the authenticator. This is currently the gold standard for phishing-resistant MFA and is explicitly favored in NIST and CISA guidance.
- Biometrics: evaluated by False Acceptance Rate (FAR, Type II error, the more dangerous one), False Rejection Rate (FRR, Type I error) and the Crossover Error Rate (CER or EER) where FAR equals FRR. A lower CER indicates a more accurate system. Biometric templates cannot be reissued if compromised, so they should be stored as irreversible templates and ideally matched locally on the device.

Adaptive and Risk-Based Authentication
Modern systems step up authentication requirements based on context: new device, unusual geolocation, impossible travel, anomalous time of day, or high-value transaction. This supports the CSSLP principle of psychological acceptability (security should not unduly burden legitimate users) while maintaining strong assurance when risk is elevated.

Single Sign-On (SSO)
SSO allows a user to authenticate once and gain access to multiple independent applications without re-entering credentials. Within a single organization this is often achieved with Kerberos (Active Directory environments) or a centralized Identity Provider (IdP) issuing tokens.

Benefits: reduced password fatigue and reuse, centralized enforcement of policy and MFA, simplified provisioning and deprovisioning, consolidated audit logs, better user experience.
Risks: the IdP becomes a single point of failure and a single point of compromise (the keys to the kingdom). Session hijacking has broader impact. Mitigations include hardening the IdP, enforcing MFA at the IdP, short token lifetimes, token binding, and re-authentication for sensitive operations (step-up).

Kerberos deserves a mention: it uses a Key Distribution Center (KDC) composed of an Authentication Service (AS) and Ticket Granting Service (TGS). The client obtains a Ticket Granting Ticket (TGT), then requests service tickets. It relies on symmetric cryptography and tightly synchronized clocks (typically within five minutes) to prevent replay. Weaknesses include the KDC as a single point of failure and attacks such as Kerberoasting, Pass-the-Ticket and Golden Ticket.

Federated Identity
Federation extends SSO across organizational and trust boundaries. The user authenticates with their home Identity Provider (IdP), and a Service Provider (SP) or Relying Party (RP) in another domain trusts assertions from that IdP. The user never shares their password with the SP. Federation depends on a pre-established trust relationship, usually anchored in exchanged certificates or metadata.

Key protocols:
- SAML 2.0 (Security Assertion Markup Language): XML-based. The IdP issues a signed assertion containing authentication, attribute and authorization decision statements. Common in enterprise web SSO. Vulnerabilities historically include XML Signature Wrapping and improper signature validation, so the SP must validate signatures, audience, issuer and timestamps.
- OAuth 2.0: an authorization delegation framework, not an authentication protocol. It issues access tokens that let a client act on a user's behalf against a resource server with limited scope. Roles: Resource Owner, Client, Authorization Server, Resource Server. The Authorization Code flow with PKCE is the recommended flow for public clients; the Implicit flow is deprecated. Exam tip: if a question says OAuth proves who the user is, that is a red flag; OAuth alone does not authenticate the user to the client.
- OpenID Connect (OIDC): an identity layer built on top of OAuth 2.0 that adds an ID token (a signed JWT) containing claims about the authenticated user. OIDC is what makes OAuth usable for authentication. Social login (Sign in with Google, Microsoft, Apple) is OIDC-based.
- JWT (JSON Web Token): a compact, URL-safe token format with header, payload and signature. Secure handling requires validating the signature with the expected algorithm (reject alg: none), checking expiration (exp), issuer (iss) and audience (aud), and never placing secrets in the payload since it is only base64-encoded, not encrypted, unless JWE is used.
- WS-Federation and Shibboleth: older or education-sector federation implementations you may see referenced.

Identity Lifecycle and Supporting Controls
Authentication does not stand alone. Secure software must address:
- Provisioning and deprovisioning: SCIM (System for Cross-domain Identity Management) automates account lifecycle across federated systems. Orphaned accounts are a major risk.
- Credential storage: passwords must never be stored in plaintext or reversibly encrypted. Use a slow, salted, adaptive hashing function such as bcrypt, scrypt, Argon2 or PBKDF2 with appropriate work factors.
- Password policy: NIST SP 800-63B now favors length over complexity, screening against breached password lists, no forced periodic rotation without evidence of compromise, and allowing paste and password managers.
- Session management: generate session identifiers with cryptographically secure randomness, regenerate the session ID after login (prevents session fixation), set Secure, HttpOnly and SameSite cookie attributes, enforce idle and absolute timeouts, and provide reliable logout that invalidates server-side state.
- Account lockout and throttling: defend against brute force and credential stuffing while avoiding self-inflicted denial of service; rate limiting, progressive delays and CAPTCHA are alternatives to hard lockout.
- Secure credential recovery: recovery flows are often weaker than the primary login and must be designed to the same assurance level.
- Machine and service authentication: APIs, microservices and non-human identities use mutual TLS (mTLS), client certificates, API keys (weak alone), signed requests, or workload identity federation. Secrets must be kept out of source code and managed through a vault.

NIST SP 800-63 Assurance Levels
The exam may reference the Digital Identity Guidelines. IAL (Identity Assurance Level 1 to 3) covers identity proofing at enrollment. AAL (Authenticator Assurance Level 1 to 3) covers authentication strength: AAL1 permits single factor, AAL2 requires MFA, AAL3 requires a hardware-based phishing-resistant authenticator with verifier impersonation resistance. FAL (Federation Assurance Level 1 to 3) covers the strength of assertion protection in federation, with FAL3 requiring holder-of-key assertions.

Mapping to Secure Design Principles
The CSSLP wants you to connect authentication to foundational principles:
- Least privilege: tokens should carry minimal scopes; authenticated does not mean authorized for everything.
- Defense in depth: MFA plus adaptive risk plus session controls plus monitoring.
- Fail secure: if the IdP or MFA service is unreachable, the system should deny access rather than fall back to password-only (unless an explicit, risk-accepted break-glass process exists).
- Complete mediation: every request must be checked; do not rely on a one-time check at login for long-lived sessions.
- Economy of mechanism: prefer proven libraries and standard protocols over custom authentication code.
- Open design: the security of Kerberos, SAML, OIDC and FIDO2 rests on published standards and key secrecy, not on obscurity.
- Separation of duties: separate the IdP, the application and the audit function so no single compromise is total.
- Psychological acceptability: SSO and passkeys exist precisely because unusable security gets bypassed.

Common Attacks and Their Countermeasures
- Credential stuffing and password spraying: MFA, breached-password screening, rate limiting, anomaly detection.
- Phishing and adversary-in-the-middle proxies (which can capture OTP codes and session cookies): phishing-resistant FIDO2/WebAuthn, origin binding, short session lifetimes.
- MFA fatigue: number matching, limiting prompt frequency, alerting on denied prompts.
- SIM swapping: avoid SMS as the sole second factor for high-value accounts.
- Session hijacking and fixation: regenerate IDs, bind sessions to attributes, secure cookie flags, TLS everywhere.
- Token theft and replay: short-lived access tokens, refresh token rotation, sender-constrained tokens (DPoP, mTLS), audience validation.
- SAML signature wrapping and JWT algorithm confusion: strict schema validation, allow-listing algorithms, using well-maintained libraries.
- Golden Ticket and Kerberoasting: protect the KRBTGT account, rotate it, use strong service account passwords or group managed service accounts.

Exam Tips: Answering Questions on Authentication, MFA, SSO and Federated Identity
1. Separate identification, authentication, authorization and accountability. Read the scenario and ask which step is actually failing or being described. Many distractors are correct statements about the wrong concept.
2. Count the factor categories, not the number of credentials. Two items from the same category (password and security question) are single-factor. The exam loves this trap.
3. OAuth is authorization; OIDC is authentication. If an answer claims OAuth 2.0 by itself authenticates users, it is almost certainly a distractor. SAML and OIDC provide authentication assertions.
4. When asked for the strongest or most phishing-resistant option, favor FIDO2/WebAuthn, hardware security keys or PKI smart cards over TOTP apps, and favor TOTP apps over SMS. SMS is almost never the best answer when a stronger option is listed.
5. SSO and federation questions hinge on trust and single point of failure. If asked about the primary risk of SSO, think compromise of the IdP or a single credential granting broad access. If asked about the primary benefit, think centralized policy enforcement and reduced credential sprawl.
6. Know who issues what. In SAML the IdP issues assertions to the SP. In OAuth the Authorization Server issues access tokens that the Client presents to the Resource Server. In OIDC the ID token proves authentication to the client. In Kerberos the KDC issues TGTs and service tickets.
7. Biometric metrics: FAR (Type II) is the security-critical error because it lets an impostor in; FRR (Type I) is a usability problem; CER is the comparison metric and lower is better. If a question asks which error is worse for security, choose false acceptance.
8. Fail secure wins. If MFA or the IdP is unavailable, the secure design denies access rather than silently downgrading to a weaker method.
9. Prefer standards and libraries over custom code. The CSSLP consistently rewards answers that use vetted protocols (SAML, OIDC, FIDO2) and established libraries over roll-your-own authentication.
10. Think lifecycle. Questions about contractors leaving, mergers, or cloud SaaS onboarding often point to provisioning and deprovisioning (SCIM, federation) rather than to the login mechanism itself.
11. Password storage questions have one right family of answers: salted, slow, adaptive hashing (bcrypt, scrypt, Argon2, PBKDF2). Encryption, plain hashing (MD5, SHA-1, unsalted SHA-256) and obfuscation are wrong.
12. Watch for the word best or most. Several answers may be technically valid controls; pick the one that most directly addresses the stated risk at the appropriate layer. For example, against credential stuffing, MFA beats a stronger password complexity rule.
13. NIST 800-63B modern guidance may contradict older intuition: no mandatory periodic password changes, length over complexity, check against breached lists, allow password managers. If an answer reflects outdated complexity-and-rotation dogma, be cautious.
14. Apply the manager mindset. CSSLP questions often expect you to think like the person responsible for the overall secure development lifecycle: choose the answer that integrates authentication requirements early (requirements and design phases), documents them, and verifies them in testing, rather than bolting them on at deployment.

Quick Reference Summary
- Factors: know, have, are (plus context: where, do).
- MFA: two or more different categories; phishing-resistant MFA is FIDO2/WebAuthn or PKI.
- SSO: one login, many apps; centralized policy, single point of failure.
- Federation: SSO across trust boundaries via IdP to SP assertions.
- SAML: XML assertions, enterprise SSO. OAuth 2.0: delegated authorization. OIDC: authentication layer on OAuth with ID tokens. Kerberos: ticket-based, symmetric, time-sensitive.
- Store passwords with salted adaptive hashes; manage sessions securely; deprovision promptly; fail secure.
- NIST 800-63: IAL for proofing, AAL for authentication strength, FAL for federation assertion strength.

Master the vocabulary, keep the concepts distinct, and always ask what the question is really testing: the mechanism, the risk, the principle or the lifecycle phase. That discipline will carry you through authentication questions on the CSSLP exam.