究竟什么是“Authentication”：从密码的局限到 FIDO2、Passkeys 与 IdP Architecture
Source: Dev.to
请提供您希望翻译的具体文本内容，我将为您翻译成简体中文。
Source: …
我们如何确认屏幕另一端的人真的是“他们”？
密码时代
多年来，互联网身份验证依赖于 密码——一种 共享密钥。
- 用户输入密码。
- 密码（或其哈希）通过网络发送到服务器。
- 服务器将其与存储在服务器端的字符串（或哈希）进行匹配。
范式转变：FIDO2（WebAuthn）
FIDO2（WebAuthn） 引入的身份验证范式通过使用 公钥密码学，从根本上解决了密码模型的问题。
范式转变的关键点
- 密码会泄露，因为它们会被传输。
- 在 FIDO2 中，只有在设备内部生成的 公钥 会注册到服务器。私钥永不离开设备。
- 登录时，服务器发送一个 挑战；设备使用其私钥对挑战进行 签名 并返回签名。
- 因此服务器仅充当 公钥电话簿。即使该电话簿泄露，单凭公钥也无法登录，危害极小。
- 使用 FIDO2，网络上被窃取秘密的风险被消除。
如果私钥像普通文件一样存储在 HDD/SSD 上，病毒可以轻易复制它。这时，特殊硬件芯片——TPM（可信平台模块） 或 Secure Enclave——就发挥作用。
硬件防御墙
- 私钥在焊接在主板上的 “不可打开的保险箱”(TPM) 中生成并存储。
- 即使是操作系统或管理员/根权限也无法直接读取保险箱内的私钥。
- 从外部只能请求芯片 “对该数据进行签名”。
- 芯片仅在成功的生物特征认证（指纹、面部等）后执行签名并返回结果。
由于这种设计，无论多强大的恶意软件都无法提取私钥。
结合 TPM 与 FIDO2，实现了 “不可破解的强身份验证”。物理安全密钥如 YubiKey 就是典型例子。
安全与便利的融合：Passkeys
历史总是碰到同一道墙：“太安全的东西对人类来说难以使用。”
Apple、Google 和 Microsoft 设计了 Passkeys 作为一种折中和突破。
- Passkeys 基于 FIDO2，但它们允许私钥 安全同步（备份）到云端（例如 iCloud Keychain）。
- 私钥 永不以明文同步；端到端加密（E2EE）确保即使是平台提供商也看不到其内容。
- 这带来了极致的可用性：“即使你换了新手机，只需使用相同的 Apple ID/Google 账户登录，就可以从一开始就使用指纹认证登录网站。”
这种做法使 FIDO 技术迅速传播到大众。
目录骨干：LDAP 与 Active Directory
到目前为止，我们已经讨论了 前端和设备端：如何验证用户的身份。
在公司或组织内部集中管理所有员工账户信息的核心是 LDAP（轻量目录访问协议），其最著名的实现是 Microsoft 的 Active Directory（AD）。
常见误解
“LDAP 是一种老旧的认证方式，现在已经被 SAML 和 OIDC 取代了，对吗？”
这 半对半错。
- LDAP 是一种协议，同时它也是一个 高速数据库，用于表示组织的 层级结构（树）。
LDAP 与关系型数据库的比较
| 方面 | LDAP | 关系型数据库（如 MySQL、PostgreSQL） |
|---|---|---|
| 数据模型 | 目录（树形结构） | 表 |
| 典型条目 | uid=bob，包含 mail、title、userPassword 等属性 | 表中的一行，包含列 |
| 操作 | 针对 读取/搜索 进行优化（例如 Bind 用于验证 DN 与密码） | 读取和写入均有优化 |
| 性能 | 能以超高速处理 每分钟数千次 Bind 操作 | 取决于索引、查询复杂度 |
由于 LDAP 针对 读取（搜索） 而非写入进行优化，它能够高效地处理大规模的认证负载。
LDAP 作为 “真相来源”
尽管现代前端应用很少直接与 LDAP 通信，LDAP 仍然是全球无数企业中身份信息的权威数据存储。
从设备验证到联合
假设身份验证在设备上完成，并且已确认数据存在于 LDAP 中。**应用程序用于与认证基础设施（目录）通信的语言（协议）**随着时间的推移而演进。与过去的“老派” LDAP bind 不同，如今我们通常使用 联合协议，例如 SAML、OAuth 2.0 和 OpenID Connect (OIDC)，将认证结果传递给下游服务。
“…ology 被淘汰”，更准确的说法是“因为对话对象和位置改变，语言必须随之改变”。
关键问题：
如果 LDAP 仍然作为内部数据库使用，那么并不是所有东西都被 OIDC 替代了，对吗？
对“内部通信”和“外部通信”使用不同的协议
LDAP 协议时代（完全紧耦合）
- 过去，内部应用会接收用户的 ID/密码，并 直接 在内部网络上查询 LDAP 服务器：
“这个密码正确吗？” - 在云时代，允许外部 SaaS 查询内部 LDAP 服务器已成为 安全上不可行 的事。
SAML 时代（外部松耦合的开端）
- 应用与 LDAP 已经 解耦。
- 认证基础设施（IdP）在后台通过查询 LDAP 验证用户身份，然后向外部 SaaS 通过浏览器发送 SAML 断言（XML 令牌），声明 “此人肯定是员工 Alice”。
- 这实现了 SSO，且从未向 SaaS 发送密码。
- 然而，SAML（XML） 对于智能手机等客户端来说过于笨重。
OIDC 时代（现代事实标准）
- 在 SAML 概念之上构建，但使用 OAuth 2.0 扩展，支持通过现代 Web 标准 JSON 和 REST API 进行通信。
- OpenID Connect（OIDC） 轻量、与 SPA 和移动应用完美配合，现已成为 SSO 前门（外部通信） 的事实标准。
混合架构的真实情况
“那么，SAML 和 LDAP 在 OIDC 时代已经死了吗？” – 不。 它们依然活跃。
- 面向前端 的交互（用户和应用）使用现代 OIDC。
- 后端 系统仍然依赖 传统 LDAP 或专用连接器代理。
- 复杂的混合模式仍然存在，例如在 OIDC 中嵌入 SAML 断言（RFC 7522：SAML 2.0 Bearer Assertion Profile）。
简而言之，用户可见层 已经演进为干净的基于 JSON 的 OIDC，而 “幕后血管” 仍然充斥着 LDAP 和 SAML。
综合全部
- 前端革命: FIDO2 / Passkeys
- 不可变后端力量: LDAP
- 现代通信标准: OIDC
所有这些都由 身份提供者 (IdP)（例如 Okta、Entra ID、Auth0）绑定在一起。
IdP 价值主张: “完全外包认证职责。”
第 1 部分的汇总
IdP 通过浏览器向用户的设备（TPM）请求使用 FIDO2/Passkeys 的安全签名。加密通信的繁重工作全部由 IdP 处理。
第 2 部分的汇总
IdP 的后端与企业的 LDAP/AD 之间保持 高带宽通道。如果退休员工从 LDAP 中被移除，IdP 会立即检测到并阻止访问。
第 3 部分的汇总
在所有检查完成后，IdP 将结果——“此人已成功认证且拥有有效权限”——封装成 OIDC 的 精美 JSON 令牌（ID Token） 并发送给目标应用程序。
对开发者的意义
- 无需自行实现 密码‑哈希逻辑、生物识别认证 或 LDAP 连接器。
- 只需 “完全交给使用 OIDC 的 IdP”。
- 您可以快速构建提供以下功能的应用程序：
- 最高便利性（Passkeys）
- 基于企业策略的强大安全性（AD 联合）
Why Each Piece Exists
| 问题 | 解决方案 |
|---|---|
| 密码泄露 | Public‑Key Cryptography (FIDO2) |
| 密钥被盗 | Hardware safe (TPM) |
| 便利性丧失 | Cloud Sync (Passkeys) |
| 企业目录查询 | LDAP (still behind the scenes) |
| 轻量、安全的外部通信 | OIDC (modern language) |
| 编排 | IdP (the conductor) |
常见问题：
- “为什么在 OAuth 或 OIDC 文章中从未提到 FIDO？”
- “为什么 SAML 和 LDAP 没有并列讨论？”
答案： 每种技术在身份验证金字塔的不同层级执行完全不同的任务。
要点
- FIDO2/Passkeys → 前端身份验证
- LDAP → 后端目录服务
- OIDC → 外部通信协议
- IdP → 中央编排者
理解这种层次结构会改变你阅读 RFC 和规范的方式——并使看似复杂的身份验证格局变得更加清晰。