What Exactly is 'Authentication': From the Limits of Passwords to FIDO2, Passkeys, and IdP Architecture

Source: Dev.to

How do we confirm that the person on the other side of the screen is actually “them”?

The Password Era

For many years, internet authentication has relied on the mechanism of passwords – a shared secret.

1. The user enters a password.
2. The password (or its hash) is sent over the network to the server.
3. The server matches it against a string (or hash) stored on the server side.

The Paradigm Shift: FIDO2 (WebAuthn)

The authentication paradigm introduced by FIDO2 (WebAuthn) fundamentally resolves the problems of the password model by using public‑key cryptography.

Key Points of the Paradigm Shift

• Passwords leak because they are transmitted.
• In FIDO2, only the public key generated inside the device is registered with the server. The private key never leaves the device.
• During login, the server sends a challenge; the device signs the challenge with its private key and returns the signature.
• The server therefore acts only as a phonebook of public keys. Even if this phonebook is leaked, the public key alone cannot be used to log in, making it harmless.
• With FIDO2, the risk of secrets being stolen over the network is eliminated.

If the private key were stored as a normal file on an HDD/SSD, a virus could easily copy it. This is where special hardware chips—TPM (Trusted Platform Module) or Secure Enclave—come into play.

Hardware Defense Wall

1. The private key is generated and stored inside an “unopenable safe” (TPM) welded to the motherboard.
2. Even the OS or Administrator/root privileges cannot directly read the private key inside.
3. From the outside you can only ask the chip to “sign this data.”
4. The chip performs the signature only after successful biometric authentication (fingerprint, face, etc.) and returns the result.

Because of this design, no malware—no matter how powerful—can extract the private key.

With the combination of TPM and FIDO2, an “unbreakable strong authentication” is achieved. Physical security keys like YubiKey are prime examples.

The Fusion of Security and Convenience: Passkeys

History always hits the same wall: “Something too secure is hard for humans to use.”

Apple, Google, and Microsoft devised Passkeys as a compromise and breakthrough.

• Passkeys are FIDO2‑based, but they allow the private key to be safely synced (backed up) to the cloud (e.g., iCloud Keychain).
• The key is never synced in plaintext; end‑to‑end encryption (E2EE) ensures that even the platform provider cannot see its contents.
• This yields ultimate usability: “Even if you buy a new smartphone, by simply logging in with the same Apple ID/Google account, you can log into sites using fingerprint authentication right from the start.”

This approach caused FIDO technology to spread rapidly to the general public.

The Directory Backbone: LDAP & Active Directory

Up to this point we’ve discussed the front‑end and device side: how to verify the identity of the user.

The heart that centrally manages the account information of all employees within a company or organization is LDAP (Lightweight Directory Access Protocol), whose most famous implementation is Microsoft’s Active Directory (AD).

Common Misunderstanding

“LDAP is an old authentication method, so it’s been replaced by SAML and OIDC now, right?”

This is half correct and half wrong.

• LDAP is a protocol, and at the same time it is a high‑speed database that represents the hierarchical structure (tree) of an organization.

LDAP vs. RDBMS

Because LDAP is optimized for reading (searching) rather than writing, it can handle massive authentication loads efficiently.

LDAP as the “Source of Truth”

Although modern front‑end applications rarely speak LDAP directly, LDAP remains the authoritative data store for identity information in countless enterprises worldwide.

From Device Verification to Federation

Suppose identity verification is done on the device and it is confirmed that the data exists in LDAP. The language (protocol) used by applications to talk to the authentication infrastructure (directory) has evolved with the times. Rather than the “old‑school” LDAP bind, today we commonly use federation protocols such as SAML, OAuth 2.0, and OpenID Connect (OIDC) to convey the authentication result to downstream services.

“…ology being driven out,” it is more accurate to say that “because the conversation partner and location changed, the language had to change”.

Key question:
If LDAP continues to use as the internal database, then not everything has been replaced by OIDC, right?

Use Different Protocols for “Internal Communication” and “External Communication”

LDAP Protocol Era (Complete Tight Coupling)

• In the past, an internal application received a user’s ID/password and directly queried the LDAP server over the internal network:
  “Is this password correct?”
• In the cloud era, allowing an external SaaS to query the internal LDAP server became a security impossibility.

SAML Era (The Beginning of External Loose Coupling)

• The application and LDAP were decoupled.
• The authentication infrastructure (IdP) verified the user’s identity behind the scenes by consulting LDAP, then issued a SAML assertion (an XML token) stating “this person is definitely employee Alice” to the external SaaS via the browser.
• This enabled SSO without ever sending the password to the SaaS.
• However, SAML (XML) proved too heavyweight for smartphones and similar clients.

OIDC Era (The Modern De‑Facto Standard)

• Built on the concepts of SAML but expanded using OAuth 2.0, allowing communication via modern web standards JSON and REST APIs.
• OpenID Connect (OIDC) is lightweight, pairs perfectly with SPAs and mobile apps, and is now the de‑facto standard for the front‑door (external communication) of SSO.

The Realistic Truth of Hybrid Architectures

“So, did SAML and LDAP die in the OIDC era?” – No. They are very much alive.

• Front‑facing interactions (users & apps) use modern OIDC.
• Back‑end systems still rely on legacy LDAP or dedicated connector agents.
• Complex hybrid patterns exist, e.g., embedding a SAML Assertion inside OIDC (RFC 7522: SAML 2.0 Bearer Assertion Profile).

In short, the user‑visible layer has evolved to clean JSON‑based OIDC, while the “veins behind the scenes” still pulse with LDAP and SAML.

Putting It All Together

• Frontend revolution: FIDO2 / Passkeys
• Immutable backend power: LDAP
• Modern communication standard: OIDC

All of these are bound together by the Identity Provider (IdP) (e.g., Okta, Entra ID, Auth0).

IdP value proposition: “Complete outsourcing of authentication responsibilities.”

The Culmination of Part 1

The IdP, via the browser, requests the user’s device (TPM) for a secure signature using FIDO2/Passkeys. The heavy lifting of encrypted communication is handled entirely by the IdP.

The Culmination of Part 2

The IdP’s backend maintains a thick pipe to the enterprise’s LDAP/AD. If a retired employee is removed from LDAP, the IdP detects it instantly and blocks access.

The Culmination of Part 3

After all checks, the IdP packages the result—“this person is definitely authenticated and has valid permissions”—into a beautiful JSON token (ID Token) of OIDC and delivers it to the target application.

What This Means for Developers

• No need to implement password‑hashing logic, biometric authentication, or LDAP connectors yourself.
• Simply “Leave it entirely to the IdP using OIDC.”
• You can rapidly build applications that provide:
  • Highest convenience (Passkeys)
  • Robust security rooted in corporate policies (AD federation)

Why Each Piece Exists

Common questions:

• “Why is FIDO never mentioned in OAuth or OIDC articles?”
• “Why are SAML and LDAP not discussed side‑by‑side?”

Answer: Each technology performs a completely different job at a distinct layer of the authentication pyramid.

Takeaway

Keep the entire map in mind:

1. FIDO2/Passkeys → front‑end authentication
2. LDAP → back‑end directory service
3. OIDC → external communication protocol
4. IdP → the central orchestrator

Understanding this hierarchy changes how you read RFCs and specifications—and makes the seemingly complex authentication landscape much clearer.