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.

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., Azure AD
3. IdP authenticates user (username + MFA)
4. IdP sends signed XML assertion to SP
5. SP validates assertion signature, grants access

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.

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.

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?