--- title: 认证框架 url: https://doc.liz6.com/networking/12-security-protocols/03-authentication-frameworks locale: zh area: networking tags: - networking - 安全协议 date: 2026-06-30 modified: 2026-07-16 description: Kerberos(对称密钥+票据)、SAML(联合身份+XML 断言)、WebAuthn(公钥+本地生物识别)——三种认证框架分别解决域内、跨域、防钓鱼三个不同场景。LDAP 和 RADIUS 则在基础设施层提供目录和网络准入。 --- # 认证框架 > Kerberos(对称密钥+票据)、SAML(联合身份+XML 断言)、WebAuthn(公钥+本地生物识别)——三种认证框架分别解决域内、跨域、防钓鱼三个不同场景。LDAP 和 RADIUS 则在基础设施层提供目录和网络准入。 ## 概述 "认证"要回答的问题永远是同一个——**怎么证明你是你**，但不同协议把"证明"放在了不同的位置上，由此分出几个世代： | 协议 | 年代 | 凭据形态 | 信任放在哪 | 主战场 | |---|---|---|---|---| | Kerberos | 1988 | 对称票据 | 中心 KDC | 企业内网 / AD | | LDAP bind | 1993 | 用户名+密码 | 目录服务器 | 内部目录 / 后端存储 | | SAML 2.0 | 2005 | 签名 XML 断言 | IdP | 企业 Web SSO | | RADIUS | 1991 | 共享密钥 + EAP | AAA 服务器 | 网络接入 (WiFi/VPN) | | WebAuthn | 2019 | 非对称密钥对 | 用户设备 | 抗钓鱼的无密码登录 | 理解一条主线就够了：**密码是负债**。它会被复用、钓鱼、撞库、在传输和存储中泄露。后面每一代协议都在想办法让密码少出现一次——Kerberos 让密码只在本地参与一次派生、再不上网；SAML/OIDC 让密码只交给 IdP 一个地方；WebAuthn 干脆用设备里不可导出的私钥彻底取代密码。选型的本质是：**在你已有的基础设施和威胁模型下，密码能被消除到什么程度**。 ## Kerberos — 票据制单点登录 AD 域登录的底座。核心思想：用户只在登录时用密码派生一次密钥，之后全程靠**有时限的对称加密票据**访问各服务，密码再不经过网络。 Kerberos 三阶段:登录一次,之后全靠票据 角色:KDC = AS(认证服务器)+ TGS(票据授予服务器);客户端;服务 ① AS-REQ/REP · 登录一次 Client → AS: “我是 alice” AS → Client: TGT(TGS密钥 加密)+ 会话密钥(密码派生 密钥加密) → 密码本身从不上网 ② TGS-REQ/REP · 每访问一次 Client → TGS: 出示 TGT, “我要访问 fileserver” TGS → Client: 服务票据 (fileserver密钥加密) + 新会话密钥 ③ AP-REQ/REP · 访问服务 Client → fileserver: 服务票据 + authenticator(时间戳, 防重放) fileserver 解票据 → 信任 KDC 背书 →(可选)AP-REP 双向认证 服务端无需联系 KDC、无需存用户密码就能验证客户端——只要能解开"用自己密钥 加密的票据",就证明票据是 KDC 签发的。密码只在登录一次时参与派生,之后再不上网。 为什么这样设计：服务端**无需联系 KDC、无需存用户密码**就能验证客户端——它只要能解开"用自己密钥加密的票据"，就证明票据是 KDC 签发的。代价与威胁： - **时钟同步**：authenticator 靠时间戳防重放，全域时钟偏差通常须 < 5 分钟（所以 AD 强依赖 NTP）。 - **KDC 是高价值单点**：拿到 `krbtgt` 账户的哈希即可伪造任意 TGT（**Golden Ticket**）；拿到某服务密钥可伪造该服务票据（Silver Ticket）。 - **Kerberoasting**：服务票据用服务账户密码派生的密钥加密，攻击者可请求后离线爆破弱口令的服务账户——所以服务账户要用强随机密码 / gMSA。 ## LDAP — 目录与 bind 认证 LDAP（RFC 4511）首先是一个**层级目录**（`cn=alice,ou=users,dc=example,dc=com`），存人、组、设备及其属性。它的"认证"就是 **bind** 操作：拿 DN + 密码去服务器换一个"通过/拒绝"。 LDAP 应用接入:search-then-bind 两步 ① 服务账户 bind 应用用服务账户 bind → search 出 alice 的完整 DN ② 用户 DN + 密码 bind 再用 alice 的 DN + 她输入的密码 做一次 bind → 成功即密码正确 bind 方式对比 simple bind DN + 明文密码 必须跑在 LDAPS/StartTLS 之上, 否则口令裸奔 SASL bind GSSAPI(Kerberos)/ EXTERNAL(mTLS) 不传密码,更强 LDAP 本身不是 SSO 协议——是"凭据校验 + 身份数据源",常被藏在 SAML/OIDC/RADIUS 背后当存储。 定位要点：LDAP 本身**不是 SSO 协议**，它是"凭据校验 + 身份数据源"，常被藏在 SAML/OIDC/RADIUS 背后当存储。Active Directory ≈ LDAP（目录）+ Kerberos（认证）+ DNS（定位）三件套的组合。 ## SAML 2.0 — 企业 Web SSO XML 时代的浏览器 SSO 标准（Okta、Azure AD、企业内网）。SP（服务方）把认证"外包"给 IdP（身份方），IdP 返回一份**带数字签名的断言（Assertion）**。 SAML 2.0 SP-initiated 流程(HTTP 重定向 + 表单 POST 绑定) 1 User → SP:访问受保护资源 2 SP → Browser:重定向到 IdP,携带 AuthnRequest(HTTP-Redirect binding) 3 IdP 验证用户(可能复用已有会话)→ 生成 Assertion 4 IdP → Browser → SP:自动 POST 表单回传 Response(HTTP-POST binding) 5 SP 验证 XML 签名 + 条件 → 建立本地会话 Assertion 关键字段 <Issuer> 谁签发(须在 SP 信任列表) <Subject><NameID> 用户标识 <Conditions NotBefore=".." NotOnOrAfter=".."> 有效期 → 防重放 <AttributeStatement> email / groups / role 等 <ds:Signature> XML-DSig 签名(覆盖断言或整个 Response) 安全要点（SAML 的坑几乎都在验签）： - **XML Signature Wrapping (XSW)**：攻击者把合法签名的元素挪位、再注入伪造断言。SP 必须严格校验"签名覆盖的正是被采信的那个元素"，并固定 schema 解析——这是 SAML 实现最常见的 CVE 来源。 - **必须校验** `Audience`（这份断言是给我的）、`NotOnOrAfter`（未过期）、`Recipient` 与 `InResponseTo`（防重放/防注入），并对 `NameID` 做一次性消费。 - 它为什么还活着：纯浏览器重定向、无需 JS、与老牌企业 IdP 兼容性最好。新项目则首选 OIDC。 ## WebAuthn / Passkeys — 抗钓鱼的无密码 FIDO2/WebAuthn（W3C）用一对**非对称密钥**取代密码：私钥生成后锁在设备安全单元里、不可导出，服务器只存公钥。 WebAuthn:非对称密钥对取代密码,私钥不出设备 注册 · navigator.credentials.create Server → challenge(随机) 认证器 为(RP ID=example.com)生成密钥对, 私钥留本地 → 返回 credential_id + public_key +(可选)attestation Server 存 credential_id ↔ public_key 认证 · navigator.credentials.get Server → challenge + 允许的 credential_id 认证器 用户验证(指纹/PIN)→ 用私钥对 (challenge + origin + RP ID)签名 Server 用公钥验签 + 核对 challenge + origin 签名绑定 origin/RP ID——认证器只认得对的域名,这是密码、OTP 都给不了的抗钓鱼保证。 它**唯一真正重要的性质是抗钓鱼**：签名里绑定了 `origin`/RP ID，浏览器只会把 `example.com` 的凭据用于 `example.com`。哪怕用户被骗到 `examp1e.com`，认证器也找不到匹配凭据、签不出可用结果——这是密码、OTP、推送通知都给不了的保证。其余概念： - **attestation**：证明"这是某型号正品认证器"，消费场景一般不校验（隐私 + 兼容）。 - **discoverable credential（resident key）**：把用户句柄也存进认证器，实现"无需先输用户名"的登录——这正是 **Passkey** 的基础。 - **Passkey = 可同步的 discoverable 凭据**：经 iCloud Keychain / Google Password Manager 跨设备同步，可用性大增，但信任随之转移到那个云账户；纯硬件密钥（device-bound）不同步、更强但易丢失。 ## RADIUS — 网络接入的 AAA RADIUS（RFC 2865）管的不是"登录网站"，而是"**能不能上这张网**"——WiFi（WPA2/3-Enterprise）、VPN、交换机端口（802.1X）。它做 AAA：Authentication、Authorization、Accounting。 RADIUS:网络接入层的 AAA 前台 NAS AP / 交换机 / VPN 网关 RADIUS 服务器 Authentication/Authorization/Accounting UDP 1812/1813 shared secret(NAS↔服务器) EAP 隧道承载真正的认证方法 EAP-TLS = 证书双向认证(最强) PEAP/TTLS = TLS 隧道里再跑 MSCHAPv2 等 常回查 LDAP / AD / Kerberos 802.1X 三方 终端(supplicant) 交换机(authenticator) RADIUS(server) RADIUS 只是 AAA 前台,把接入层和身份层解耦——真正的账号数据留在 LDAP/AD/Kerberos。 要点：RADIUS 自己只是个 AAA 前台，身份数据通常还在 LDAP/AD 里；它把"接入层"和"身份层"解耦。需要按命令做细粒度授权与审计（网络设备运维）时，用 **TACACS+**（逐命令授权、全程加密）替代。 ## 选型 | 需求 | 首选 | 关键理由 | |---|---|---| | AD 域内服务互认 | Kerberos | 票据 SSO, 密码不上网 | | 内部目录 / 作为后端身份源 | LDAP(S) | 是数据源而非 SSO, 藏在别的协议背后 | | 企业 Web SSO（老牌 IdP） | SAML 2.0 | 纯浏览器、兼容性最好 | | 现代 App / 移动端 / 联邦登录 | [OIDC](/networking/12-security-protocols/02-oauth2-and-openid-connect.md) | JSON/JWT, 比 SAML 轻 | | 抗钓鱼的用户登录 | WebAuthn/Passkey | origin 绑定, 消除密码 | | WiFi / VPN / 端口准入 | RADIUS + EAP | 网络接入层 AAA | | 网络设备逐命令授权审计 | TACACS+ | 细粒度 + 全加密 | 实践里它们是分层叠用而非二选一：典型组合是 **WebAuthn/OIDC 做用户登录前台 + LDAP/AD 做身份源 + Kerberos/RADIUS 管内网与接入**。 ## 参考 - **Kerberos**: RFC 4120 · MIT Kerberos 文档 · "Kerberos: The Definitive Guide" - **WebAuthn**: w3c.github.io/webauthn · webauthn.guide · passkeys.dev - **SAML**: OASIS SAML 2.0 Core · "On Breaking SAML"（XSW 攻击论文） - **统一平台**: Keycloak（同时讲 OIDC/SAML/LDAP/Kerberos brokering，值得搭起来读） *Keywords: Kerberos, KDC, TGT, Golden Ticket, Kerberoasting, LDAP, bind, SAML, Assertion, XML Signature Wrapping, WebAuthn, Passkey, FIDO2, phishing-resistant, RADIUS, EAP, 802.1X, TACACS+*