6.1.2. Authentication Factors and MFA

💡 First Principle: Organizations don't operate in isolation — employees use cloud services from dozens of vendors, partners need controlled access to shared systems, and customers authenticate to external portals. Federation extends identity trust across organizational and technical boundaries without requiring each service to maintain its own credential store. SSO lets users authenticate once and access multiple services without re-authenticating.

Single Sign-On (SSO):

The user authenticates once to a central identity provider; that authentication is shared with all relying applications. The user experience is seamless; the security benefit is centralized authentication policy — MFA enforcement, session timeout, anomaly detection — applied consistently across all integrated applications. The trade-off is risk concentration: a compromised IdP (or a stolen IdP session) opens every application that trusts it, so the IdP needs the strongest controls — phishing-resistant MFA, privileged-access protection and monitoring. Federation is never automatic: a service provider accepts assertions only from IdPs it has been explicitly configured to trust (exchanged metadata and signing certificates).

SSO architectures:

Kerberos: The dominant enterprise SSO protocol for Windows/Active Directory environments.

Kerberos key facts:

• Tickets have time stamps — clock skew > 5 minutes breaks authentication (requires NTP synchronization)
• TGT lifetime typically 8 hours; Service ticket lifetime typically 10 minutes
• KDC (Key Distribution Center) = AS + TGS; compromise of KDC = compromise of all Kerberos realm

Golden Ticket attack: An attacker who obtains the KRBTGT account's password hash can forge arbitrary TGTs (Ticket Granting Tickets) for any user, including non-existent "super-users." The forged ticket is valid because it's signed with the real KRBTGT hash. Defense: regular KRBTGT password rotation (twice, because Kerberos uses the previous password too), privileged access protection for domain controllers.

SAML (Security Assertion Markup Language): XML-based federation protocol for web applications. Used for enterprise SSO to cloud applications (Salesforce, Workday, AWS console).

SAML flow:

1. User accesses service provider (SP) — e.g., Salesforce
2. SP redirects user to identity provider (IdP) — e.g., Microsoft Entra ID
3. IdP authenticates user (username + MFA)
4. IdP sends signed XML assertion to SP
5. SP validates assertion signature, grants access

Golden SAML attack: The federation equivalent of a Golden Ticket. An attacker who steals the IdP's token-signing private key (for example from an AD FS server) can forge SAML assertions for any user with any attributes, including admin roles; the SP accepts them because the signature is valid, and MFA is bypassed because the IdP is never asked. Defense: keep signing keys in an HSM, protect the IdP as a Tier 0 asset, rotate the signing certificate after any suspected compromise, and alert on SP sign-ins with no matching IdP authentication event.

OAuth 2.0: Authorization framework (NOT authentication) that allows a resource owner to grant limited access to their resources to a third party without sharing credentials. "Login with Google" for a third-party app uses OAuth 2.0 to grant the app access to Google profile data. Access tokens are short-lived and paired with longer-lived refresh tokens that are presented only to the authorization server. The Authorization Code grant is the recommended flow (tokens are exchanged server-to-server, not exposed in the browser), with PKCE protecting public clients such as mobile and single-page apps.

OpenID Connect (OIDC): Authentication layer built on top of OAuth 2.0. Adds an ID Token (JWT) that carries user identity claims. OIDC = OAuth 2.0 + identity. Modern applications use OIDC for authentication; OAuth 2.0 for authorization.

SAML vs. OAuth 2.0/OIDC: SAML carries XML assertions (authentication plus attribute statements) over browser redirects and suits enterprise web SSO. OAuth 2.0 and OIDC use lightweight JSON tokens (usually JWTs) and suit REST APIs and native mobile apps. Neither is inherently more secure: SAML's XML signatures have their own flaw class (XML signature wrapping), and both depend on correct token validation. When a legacy SAML-only application must coexist with OIDC-based APIs, an identity broker (such as Entra ID, Okta or Keycloak) speaks both protocols so neither side has to change.

FIDO2 / WebAuthn: Passwordless authentication standard. Uses public key cryptography — the private key never leaves the device (stored in hardware security key or TPM). Resistant to phishing (credential is domain-bound, won't work on a lookalike site) and credential theft (no reusable secret to steal).

Federation trust models:

⚠️ Exam Trap: OAuth 2.0 is an authorization framework, not an authentication protocol. "Sign in with Google" that uses OAuth 2.0 alone can be vulnerable to token substitution attacks — an attacker intercepts a valid OAuth token for one application and replays it against another. OpenID Connect adds the ID Token which binds the authentication to a specific relying party (audience claim), preventing this. Always use OIDC (not raw OAuth) for authentication.

Reflection Question: A company is evaluating Kerberos versus SAML for SSO to their new cloud-based HR application. The HR application is hosted by a SaaS vendor and does not support Kerberos. What protocol should be used, why is Kerberos unsuitable for this scenario, and what security configuration must the company require from the SaaS vendor to ensure the identity assertion cannot be forged or replayed?