Part 1 — The Foundations of Modern Authentication: How Identities Prove Themselves

Part 1 — The Foundations of Modern Authentication: How Identities Prove Themselves

Authentication is the first gate every attacker wants to pick. If you misunderstand how your identities authenticate, you've already lost the perimeter—even if you think you don't have one.

The Evolution of Identity

• On-Prem Era (AD & Kerberos): Trust assumed inside the network. You authenticated once to a Domain Controller and inherited that trust everywhere through Kerberos tickets and NTLM hashes.
• Federation Era (SAML, WS-Fed): Enterprises needed cross-domain trust for SaaS apps. They began trading XML "assertions" instead of passwords.
• API & Cloud Era (OAuth 2.0 / OIDC / JWT): Identities became tokenized, stateless, and transportable. Apps no longer needed to know the password—just verify a signed token.
• Zero-Trust Era (Continuous Auth): Every access attempt re-validated context—device posture, geolocation, risk score. The identity boundary replaced the network boundary.

Security takeaway: each step removed implicit trust and increased dependency on cryptographic proofs instead of network location.

Authentication vs. Authorization

• Authentication: Proving who you are. ("Here's my credential; verify me.")
• Authorization: Deciding what you can do. ("Now that I know you, here's what you can access.")

Mixing the two is a classic design failure—e.g., assuming a valid JWT equals admin rights. Always decouple identity proof from privilege enforcement.

Kerberos Deep Dive

Kerberos is the backbone of traditional Active Directory authentication.

1. AS-REQ / AS-REP: Client asks the Key Distribution Center (KDC) for a Ticket Granting Ticket (TGT).
2. TGS-REQ / TGS-REP: Client presents the TGT to get a Service Ticket for a specific resource (SPN).
3. AP-REQ / AP-REP: Service validates the ticket and grants access.

Why it matters:

• Tickets are encrypted with symmetric keys; compromise of the KDC key = total domain takeover.
• Attackers abuse Kerberoasting (dump service tickets and crack offline) or Golden Ticket attacks (forge TGTs using the KRBTGT key).

Mitigation:Tiered admin model, protected LSASS, constrained delegation, short-lived tickets, monitor 4624/4768/4769 logs.

LDAP Essentials

Lightweight Directory Access Protocol underpins AD's directory queries.

• Bind: authentication step (simple bind = plaintext unless over LDAPS).
• Search: retrieves objects and attributes (users, groups, devices).

Risks:

• LDAP Injection: unsanitized user input building filter strings (e.g., (&(uid=" + user + ")(password=" + pass + ")))
• Weak binds: anonymous or simple binds without TLS expose credentials.

Defenses: enforce LDAPS, sanitize filters, and least-privilege directory queries.

SAML — Federation's XML Dinosaur

Security Assertion Markup Language uses XML assertions to federate identities between an Identity Provider (IdP) and Service Provider (SP).

Flow:

1. User requests SP.
2. SP redirects to IdP.
3. IdP authenticates user, signs SAML Assertion.
4. SP validates signature and issues its session.

Common failures:

• Signature wrapping attacks when XML parsers fail to validate canonicalization.
• Accepting unsigned or replayed assertions.
• Clock skew allowing expired assertions.

Hardening:Always verify XML signature after canonicalization, enforce audience and expiry validation, use POST bindings, and prefer SHA-256 or higher.

OAuth 2.0 and OIDC — Modern Cloud Auth

OAuth 2.0 handles authorization—granting scoped access without sharing passwords.OpenID Connect (OIDC) extends it for authentication by issuing ID Tokens.

Grant types:

• Authorization Code (web apps)
• PKCE (mobile / public clients)
• Client Credentials (service to service)
• Device Code (IoT)

Security pitfalls:

• Misusing the implicit flow (tokens in redirect URIs).
• Over-scoped access tokens ("read+write" when "read" suffices).
• Not validating aud, iss, and signature of ID Token.

Defense: enforce PKCE, short-lived tokens, refresh-token rotation, and audience validation.

JWT — The Token DNA

JSON Web Token = header.payload.signature

• Header: algorithm + type
• Payload: claims (sub, exp, aud, etc.)
• Signature: HMAC or RSA/ECDSA over the first two parts

Common developer traps:

• Accepting "alg":"none" tokens.
• Reusing symmetric keys across tenants.
• Failing to check exp and nbf.

Security posture:

• Use asymmetric signing (RS256/ES256).
• Validate every claim.
• Keep tokens short-lived; use refresh tokens sparingly.
• Log token issuance and revocation.

MFA & Passwordless

• MFA: Combine knowledge (password) + possession (token/phone) or inherence (biometric).
• TOTP/Authenticator Apps: RFC 6238 one-time codes; protect seed secrets.
• WebAuthn/FIDO2: Public-key challenge-response, phishing-resistant, no shared secrets.

Threats: MFA fatigue, SIM swap, push bombing.Countermeasures: Number-matching, hardware keys (YubiKey), device attestation.

SSO in Practice

Single Sign-On relies on federated trust between IdPs and SPs.The IdP authenticates once and issues tokens/assertions to multiple SPs.

Security design:

• Central IdP (e.g., Entra ID, Okta, Ping) with MFA enforced.
• SPs validate signatures and audiences only from trusted IdPs.
• Implement global logout and token revocation.

Failure case: a compromised IdP account equals breach of every connected app—your blast radius depends on your conditional-access rigor.

Attack Surface Mapping

The Threat Lens — How Every Protocol Can Be Abused

Every authentication protocol is a trust negotiation.

• Kerberos: the crown jewels if KDC compromised.
• LDAP: lateral-movement enabler via weak binds.
• SAML: fragile XML parsing.
• OAuth/OIDC: over-scoped tokens and consent abuse.
• JWT: unsigned or long-lived tokens.

Your defense posture:

1. Use secure defaults and reject legacy protocols.
2. Centralize identity logging and analytics.
3. Enforce MFA and conditional access everywhere.
4. Rotate signing keys, revoke compromised sessions.
5. Treat the IdP as Tier 0 — defend it like your domain controller.

✅ Key Takeaway

Authentication isn't a login screen; it's a chain of cryptographic proofs and delegated trust.Understand the protocol flows, and you'll know exactly where to instrument controls, where to monitor, and where attackers hide.

Next in the series →Part 2 — "Bridging the Worlds: IAM in Cloud and Hybrid Architectures"We'll dissect how these protocols coexist across AWS, Azure Entra ID, and on-prem AD—and how to secure the federation links that tie them together.