认证框架

Kerberos、LDAP、SAML、WebAuthn 与 RADIUS 并不是依次替代的五代登录协议。它们分别组织票据、目录操作、跨系统断言、公钥凭据和网络准入，可以在同一套系统内协作。比较时先问：谁验证凭据，谁作授权决定，哪个组件最终执行该决定？

密码是否出现只是比较维度之一。密钥如何注册、如何撤销，账号怎样恢复、已建立会话如何失效，同样决定系统行为。

Kerberos：票据不是能反复发送的完整登录证明

KDC 包括 AS 与 TGS 两种逻辑职责。客户端先通过 AS 交换取得 TGT，再以 TGT 向 TGS 请求目标服务的票据，最后向服务发送 AP 请求。票据通常可缓存到有效期内使用，不是每读取一次文件就重新访问 TGS。

基于密码的初始交换不发送原始密码，但会使用密码派生的长期密钥，并通常包含预认证。Kerberos 也支持 PKINIT 等公钥初始认证，不能把“所有登录都只派生一次密码密钥”写成协议定律。RFC 4120、PKINIT

服务解密票据后还要核对目标 principal、有效期、authenticator 中的身份与时间等，并防止重复使用同一认证器。⁠时间戳只限制可接受窗口，窗口内仍可能重放⁠，因此不能用“时间未过期”替代重放缓存或协议允许的其他重放防护。允许的时钟偏差由实现和策略控制，不是全世界统一固定五分钟。

AP-REP 可提供双向认证，证明服务也掌握会话密钥。基础验证可不在线访问 KDC，但具体部署可能还有授权数据验证和其他依赖。对称密钥能被服务本身使用，所以“能解密就从密码学上证明只有 KDC 能签发”也不准确。

缓存既提高可用性，也带来撤销延迟：KDC 暂时不可达时，已有有效服务票据可能继续使用，申请新票据或续期则受影响。服务长期密钥泄露会影响该服务的票据信任；TGS 密钥泄露的范围更大。票据认证完成后，服务仍需根据主体和授权数据判断是否能读取某个目录或执行某个动作。

还在允许时间内，为什么第二次要拒绝？

在同一时刻递送两次，第二次即使时间正确仍是重放。生成新的认证器后，主体仍为alice，却可以再次验证。把接收时刻拉远则触发另一项时间检查，两个拒绝理由应分开记录。

LDAP：目录查询与连接身份是两层状态

LDAP 条目有 DN，如 uid=alice,ou=people,dc=example,dc=com；search 指定 base DN、scope、filter 和属性集合。DN 是目录位置标识，可以随重命名或移动而改变；目录账户的长期关联要依据部署所提供的稳定标识设计。RFC 4511

常见 search-then-bind 流程是：应用以有限权限服务身份搜索用户，确认恰好匹配一条记录，然后使用返回的 DN 和用户密码进行认证。直接把用户输入拼成 DN 不一定符合目录结构，搜索得到多条结果也不能任意取第一条。

登录界面应拒绝空密码进入用户名/密码认证路径。使用 StartTLS 时，要确认升级和服务端证书验证完成才提交凭据；不能把升级失败后继续 bind 当作等价路径。EXTERNAL 可利用外部已建立的安全身份，但证书身份到目录授权身份仍要映射。RFC 4513

bind 会改变连接的认证状态。在共享搜索连接上临时绑定成某个用户，会影响后续请求；认证连接和服务查询连接应有清晰生命周期。重新 bind 失败也不能假定原服务账号权限仍保留。

Filter 转义与 DN 转义不是同一规则

(uid=alice*) 中的星号有模式含义，若用户名真的包含星号，需要按 filter 语法编码。下面将 UTF-8 值中的每个字节转义，形式较冗长，但便于直接检查不会注入 filter 结构；实际应用使用 LDAP 库的 filter 值编码函数。

def filter_value(text):
    return ''.join('\\' + format(b, '02x') for b in text.encode('utf-8'))

assert filter_value('a*(b)\\') == r'\61\2a\28\62\29\5c'
assert filter_value('中') == r'\e4\b8\ad'
assert filter_value('\0') == r'\00'
query = '(uid=' + filter_value('alice*') + ')'
assert query == r'(uid=\61\6c\69\63\65\2a)'
print('Filter 值按字节编码通过；不用于 DN 或属性名')

此函数只处理属性值，不能拿来允许用户任意选择搜索 base、属性名或过滤器操作符。RFC 4515

SAML：采信的是哪个签名元素、哪一次请求

在常见 SP 发起的 Web SSO 中，SP 保存请求 ID，经浏览器将 AuthnRequest 送到 IdP；IdP 完成适用的用户认证后，通常通过浏览器 POST 将 Response 送至 SP 的 ACS。SP 验证响应和断言，再创建自己的 session。浏览器携带的 Base64 XML 不是天然可信内容，也不意味着已经加密。SAML Profiles

XML Signature Wrapping 的核心问题是“验签检查 A，业务却读取 B”。仅在文档中找到一个有效签名还不够；应使用成熟 SAML 库，并确保被消费的断言与签名验证结果是同一个结构对象。对元素 ID、解析和允许的签名结构也要按库和 profile 的要求处理。

NameID 是主体标识，不是要一次性消费的登录随机数。 它的格式和 issuer 等限定共同影响身份映射；持久 NameID 可以用于多次登录。防重放应关联请求 ID、断言/响应 ID 和有效期，不能把某个用户第一次登录后永久标成“NameID 已使用”。

IdP 发起的非请求响应登录没有同样的原始 SP 请求可匹配，需要显式采用该 profile 的处理政策；不能为了兼容就把所有回调的 InResponseTo 检查关掉。RelayState 常用于恢复应用状态，也不能直接成为任意站外跳转地址。SAML Core

下面只演示已经完成验签和其他条件验证后的一次性消费，实际服务须在共享存储中原子检查并登记，并保留到相应接受窗口结束。

seen = set()
def consume(issuer, assertion_id, expires, now):
    key = (issuer, assertion_id)
    if now >= expires or key in seen:
        return False
    seen.add(key)
    return True

assert consume('idp-a', 'assertion-1', 200, 100)
assert not consume('idp-a', 'assertion-1', 200, 101)
assert consume('idp-a', 'assertion-2', 200, 101)  # 同用户可再次登录。
assert not consume('idp-a', 'assertion-3', 200, 200)
print('断言重复与到期边界通过；NameID 不参与一次性消耗')

WebAuthn：凭据作用域、字节签名与用户验证

注册时，RP 发出 challenge，浏览器和认证器完成 navigator.credentials.create()，RP 验证注册结果并将 credential ID、公钥、用户句柄及所需状态关联保存。认证时使用 navigator.credentials.get()，验证器必须知道该凭据属于哪个本地账户；新增凭据本身也需要可靠的注册授权。

认证签名的输入是 authenticatorData || SHA256(clientDataJSON) 的原始字节。clientDataJSON 中包含 ceremony 类型、challenge、origin 等；authenticatorData 包含 RP ID 哈希、flags 与计数器等。不能把原始 JSON 解析后重新序列化再计算摘要，因为空白和字段顺序的变化会改变字节。

RP 应核对预期 challenge、允许的 origin、RP ID 哈希、credential 与账户关系，以及策略要求的 UP/UV 标志，再按凭据公钥和算法验证签名。UP 表示用户在场交互，UV 表示完成本地用户验证；触摸一下设备不总是等同于指纹或 PIN 验证。WebAuthn 验证过程

import hashlib
import json
import struct
rp_id = 'example.com'
raw_client_data = json.dumps({
    'type': 'webauthn.get', 'challenge': 'example-only',
    'origin': 'https://login.example.com'
}, separators=(',', ':')).encode()
# 无扩展的最小 authenticatorData：32 B 哈希 + 1 B flags + 4 B 计数。
auth_data = hashlib.sha256(rp_id.encode()).digest() + bytes([0x05])
auth_data += struct.pack('>I', 0)
signed_bytes = auth_data + hashlib.sha256(raw_client_data).digest()
assert len(auth_data) == 37 and len(signed_bytes) == 69
assert auth_data[32] & 0x01 and auth_data[32] & 0x04  # UP、UV
assert hashlib.sha256(raw_client_data).digest() != hashlib.sha256(
    json.dumps(json.loads(raw_client_data), indent=2).encode()).digest()
print('签名输入 69 B；此处检查编码，不代替真实验签与事务验证')

RP ID 通常是有效域名，origin 则包含协议、主机和适用的端口。login.example.com 在符合规则时可使用 example.com 作为 RP ID，但 RP 仍须限定允许的 origin；不能把二者直接字符串相等作为唯一检查。

Passkey 不等于“永远困在一台硬件里”

Passkey 可以是同步凭据，也可以绑定于单个设备。同步提供方在其保护机制下将凭据用于多个设备，与设备绑定密钥的生命周期不同；WebAuthn 不规定所有私钥必须位于不可导出的硬件安全单元。生物识别也不是必需条件，用户验证可以通过设备 PIN 等方式完成，RP 通常不接收原始生物特征。FIDO Passkeys

没有实现计数器的认证器可以一直返回 0；其他情况下出现不增长，也可能涉及复制、故障或并发响应乱序，应按规范与风险策略处理。challenge 的一次性使用仍是事务新鲜性的核心之一。

域名作用域让仿冒站点不能像收集密码或 OTP 那样取得用于真实 RP 的认证结果。但账户恢复、已经登录的 session 和终端环境仍有自己的信任边界；移除密码并不自动让薄弱恢复流程变强。

签名正确，为什么还是不能登录？

初始RP ID是example.com，origin却是其登录子域，二者并不要求直接字符串相等。取消UV但保留UP，说明触摸在场不等于完成本策略要求的用户验证；其他字段正确也不能补偿。

RADIUS 与 EAP：认证服务器决定，NAS 执行

典型 802.1X 中，终端通过 EAPOL 与 AP/交换机交互，NAS 把 EAP 消息装进 RADIUS 属性送往认证服务器。EAP 是可扩展认证框架，EAP-TLS 才是其中使用 TLS 的方法；不能把所有 EAP 都叫加密隧道。RADIUS/EAP、EAP-TLS 1.3

RADIUS Access-Request 可得到 Access-Challenge、Access-Accept 或 Access-Reject。多轮 challenge 使用 State 等属性关联认证过程；Accept 可能包含 VLAN、过滤或会话时限等授权属性。认证通过但 VLAN 没有正确落地，应该核对 NAS 的执行与属性支持，而不是只重新输入密码。

经典 RADIUS/UDP 常用 1812 认证、1813 计费，基础头部 20 B，包括 Code、Identifier、Length 和 16 B Authenticator；Authenticator 的具体构造取决于消息类型，不能统一称为“随机数”或“全包加密”。共享秘密与传统属性保护不等于整个报文有现代传输机密性。RFC 2865

RADIUS/TLS 或 DTLS 保护 NAS/代理与服务器之间的传输，和终端到 EAP 服务器的 EAP-TLS 是两个边界。RFC 9765 定义的 RADIUS/1.1 是实验性规范⁠，通过 TLS/DTLS 上的 ALPN 协商移除其模式中的共享秘密、MD5 包认证和属性混淆机制；不能宣称所有既有 UDP RADIUS 已因此升级。RADIUS/1.1

RADIUS 服务器可以使用本地配置、证书、目录或其他身份源，并非必须把账号数据放在 LDAP/AD。计费记录描述会话事件和统计，也不天然构成精确一次的账本，应用需处理重发、缺失和会话关联。

TACACS+ 常用于设备管理中的认证、逐命令授权和计费。其传统协议头明文、body 采用基于共享秘密的混淆，不能简化成“全程现代加密”；是否适合替代某个 RADIUS 部署取决于设备功能和管理需求。RFC 8907

将它们组合成身份系统

一个企业可以用 LDAP 保存目录，以 Kerberos 访问域服务，让 IdP 通过 WebAuthn 认证用户，再向 Web 应用签发 SAML 或 OIDC 结果；办公网络则由 RADIUS/EAP 做接入。这些组件共享人员生命周期，却不自动共享同一份会话状态。

员工离职后，目录停用、票据剩余有效期、IdP 会话、应用 session、已登记 passkey 和网络接入会话会分别变化。完整设计应明确每类状态的持有者、有效期与撤销传播方式。协议选型之后，仍需把这条身份生命周期串起来。