Kerberos认证通过后客户端与服务端的交互机制及HTTP场景问询

Kerberos完成初始认证后，客户端是通过**服务票据（Service Ticket）+ 认证器（Authenticator）**与服务端建立信任交互的，针对HTTP场景，确实需要在请求头中携带特定格式的令牌，具体流程如下：

核心前置：认证完成后客户端拿到的关键凭证 #

在Kerberos的Client Service Request阶段结束后，客户端会从KDC获取到两个核心内容：

• 服务票据（Service Ticket）：由KDC用服务端的密钥加密，包含客户端身份标识、会话密钥、票据有效期等信息，只有目标服务端能解密。
• 会话密钥（Session Key）：KDC同时发给客户端和服务端的对称密钥，用于后续客户端和服务端之间的加密通信。

客户端发起服务请求的具体操作 #

当客户端通过HTTP访问目标服务时：

1. 客户端生成认证器（Authenticator）：用会话密钥加密自身身份标识、当前时间戳（防止重放攻击）等信息。
2. 将服务票据和认证器打包成SPNEGO格式的令牌，再做Base64编码。
3. 在HTTP请求头中添加：

   Authorization: Negotiate <Base64编码后的SPNEGO令牌>
   

服务端的验证与处理流程 #

服务端收到请求后：

1. 解码请求头中的SPNEGO令牌，分离出服务票据和认证器。
2. 用自身的密钥解密服务票据，取出会话密钥和客户端身份信息。
3. 用会话密钥解密认证器，验证时间戳（确保请求未过期）和客户端身份的一致性。
4. 验证通过后，服务端就会处理客户端的业务请求；如果需要双向认证，服务端还可以用会话密钥加密一个确认信息返回给客户端。

后续请求的复用逻辑 #

只要服务票据未过期，客户端后续请求可以直接复用该票据和会话密钥，无需再次向KDC申请新的服务票据；当票据快过期时，客户端可以用之前获取的TGT（Ticket Granting Ticket）向KDC申请新的服务票据，无需重新走完整的初始认证流程。

内容的提问来源于stack exchange，提问作者NShiny