Authentication Frameworks

Kerberos (symmetric key + tickets), SAML (federated identity + XML assertions), WebAuthn (public key + local biometrics) — three authentication frameworks addressing three distinct scenarios: intra-domain, cross-domain, and phishing resistance. LDAP and RADIUS provide directory and network access at the infrastructure layer.

Overview

The question "authentication" always answers is the same — how to prove you are you — but different protocols place the "proof" in different places, leading to several generations:

Understanding one main thread is enough: passwords are a liability. They are reused, phished, subjected to credential stuffing, and leaked during transmission and storage. Each subsequent generation of protocols tries to make passwords appear less often — Kerberos ensures passwords are only used once locally to derive keys and never traverse the network; SAML/OIDC ensures passwords are only given to one IdP; WebAuthn completely replaces passwords with non-exportable private keys stored on the device. The essence of selection is: to what extent can passwords be eliminated given your existing infrastructure and threat model.

Kerberos — Ticket-based Single Sign-On

The foundation of AD domain login. The core idea: the user derives a key from their password only once during login, and thereafter accesses services entirely using time-limited symmetric encryption tickets, so the password never traverses the network.

Why designed this way: The service can verify the client without contacting the KDC or storing user passwords — as long as it can decrypt the "ticket encrypted with its own key", it proves the ticket was issued by the KDC. Costs and threats:

• Clock Synchronization: Authenticators rely on timestamps to prevent replay attacks; global clock skew usually must be < 5 minutes (hence AD's strong reliance on NTP).
• KDC is a high-value single point of failure: Obtaining the krbtgt account hash allows forging arbitrary TGTs (Golden Ticket); obtaining a service key allows forging that service's tickets (Silver Ticket).
• Kerberoasting: Service tickets are encrypted with keys derived from service account passwords. Attackers can request them and brute-force weak passwords for service accounts offline — hence service accounts should use strong random passwords / gMSA.

LDAP — Directory and Bind Authentication

LDAP (RFC 4511) is primarily a hierarchical directory (cn=alice,ou=users,dc=example,dc=com), storing people, groups, devices, and their attributes. Its "authentication" is the bind operation: presenting a DN + password to the server to exchange for a "pass/fail" result.

Key positioning: LDAP itself is not an SSO protocol; it is "credential verification + identity data source", often hidden behind SAML/OIDC/RADIUS as storage. Active Directory ≈ LDAP (directory) + Kerberos (authentication) + DNS (location) combination.

SAML 2.0 — Enterprise Web SSO

The browser SSO standard of the XML era (Okta, Azure AD, enterprise intranets). The SP (Service Provider) outsources authentication to the IdP (Identity Provider), which returns a digitally signed Assertion.

Security points (SAML's pitfalls are almost all in signature verification):

• XML Signature Wrapping (XSW): Attackers shift validly signed elements and inject forged assertions. The SP must strictly verify that "the signature covers exactly the element being trusted" and fix schema parsing — this is the most common source of CVEs in SAML implementations.
• Must verify Audience (this assertion is for me), NotOnOrAfter (not expired), Recipient and InResponseTo (anti-replay/anti-injection), and treat NameID as single-use.
• Why it still survives: Pure browser redirects, no JS required, best compatibility with legacy enterprise IdPs. New projects should prefer OIDC.

WebAuthn / Passkeys — Phishing-resistant Passwordless

FIDO2/WebAuthn (W3C) replaces passwords with a pair of asymmetric keys: the private key is generated and locked in the device's secure element, non-exportable, while the server only stores the public key.

Its only truly important property is phishing resistance: the signature binds origin/RP ID, and the browser will only use example.com credentials for example.com. Even if the user is tricked into examp1e.com, the authenticator won't find matching credentials and cannot produce a valid signature — a guarantee that passwords, OTPs, and push notifications cannot provide. Other concepts:

• Attestation: Proves "this is a genuine authenticator of a specific model"; consumption scenarios generally do not verify this (privacy + compatibility).
• Discoverable credential (resident key): Stores the user handle in the authenticator, enabling login "without entering a username first" — this is the basis of Passkeys.
• Passkey = Syncable discoverable credentials: Synced across devices via iCloud Keychain / Google Password Manager, greatly improving usability, but trust shifts to that cloud account; pure hardware keys (device-bound) do not sync, are stronger, but are easier to lose.

RADIUS — Network Access AAA

RADIUS (RFC 2865) does not manage "logging into a website", but rather "can you access this network" — WiFi (WPA2/3-Enterprise), VPN, switch ports (802.1X). It performs AAA: Authentication, Authorization, Accounting.

Key points: RADIUS itself is just an AAA frontend; identity data usually remains in LDAP/AD; it decouples the "access layer" from the "identity layer". When fine-grained authorization and auditing by command are needed (network device operations), use TACACS+ (per-command authorization, full encryption) instead.

Selection

In practice, they are layered and used together rather than being mutually exclusive: a typical combination is WebAuthn/OIDC for user login frontend + LDAP/AD for identity source + Kerberos/RADIUS for intranet and access.

References

• Kerberos: RFC 4120 · MIT Kerberos Documentation · "Kerberos: The Definitive Guide"
• WebAuthn: w3c.github.io/webauthn · webauthn.guide · passkeys.dev
• SAML: OASIS SAML 2.0 Core · "On Breaking SAML" (XSW attack paper)
• Unified Platform: Keycloak (covers OIDC/SAML/LDAP/Kerberos brokering, worth setting up and reading)

Keywords: Kerberos, KDC, TGT, Golden Ticket, Kerberoasting, LDAP, bind, SAML, Assertion, XML Signature Wrapping, WebAuthn, Passkey, FIDO2, phishing-resistant, RADIUS, EAP, 802.1X, TACACS+