基于SPNEGO的Kerberos认证：安全上下文复用与请求处理疑问

我正在为Linux客户端应用实现基于SPNEGO的Kerberos认证，用于向Windows IIS服务器发起请求认证，已查阅RFC4559文档。现存在以下技术疑问：

问题1：是否需要为每个HTTP请求通过gss_init_sec_context创建新安全上下文？该操作开销如何？Curl为单次请求创建上下文，但仅执行单请求。 #

不需要为每个请求创建新安全上下文。gss_init_sec_context的开销分两种场景：

• 首次创建：需要与KDC完成AS/TGS票据请求交互，涉及网络往返、加密解密运算，开销较高；
• 上下文复用：仅需基于已有会话状态生成轻量验证信息，几乎无额外开销。

Curl的单次请求模式是因为它设计为无状态的单次请求工具，而长期运行的客户端应复用已建立的安全上下文，直到上下文过期（可通过gss_init_sec_context返回的过期时间判断）。

问题2：如何在PUT/POST请求中使用该认证方式？无法从gss_init_sec_context结果预判服务器返回HTTP 200还是401 Negotiate续期，不知何时发送请求体。 #

注：相关文档指出，使用SPNEGO HTTP认证处理PUT/POST等带用户数据的请求时，需先完成客户端与服务器的认证，当gss_init_sec_context返回状态表明安全上下文已建立，再向服务器发送数据。

正确流程分为两步：

1. 预握手请求：发送不带请求体的PUT/POST请求（可设置Content-Length: 0或仅发送请求头），触发服务器返回401 Negotiate挑战；
2. 完成认证并发送数据：用服务器返回的挑战令牌反复调用gss_init_sec_context，直到主状态返回GSS_S_COMPLETE（安全上下文完全建立）；随后发送带完整请求体的PUT/POST请求，同时在请求头中携带最终生成的Negotiate响应令牌。

这种方式避免了提前发送请求体导致的资源浪费，只有上下文建立完成后，服务器才会处理带数据的请求。

问题3：每次请求都执行协商认证效率低下，为何不能像OAuth2.0那样一次认证后令牌复用？ #

SPNEGO/Kerberos本身支持上下文复用，逻辑和OAuth2的令牌复用类似，只是机制不同：

• OAuth2复用的是应用层的Bearer令牌；
• SPNEGO复用的是包含会话密钥和状态信息的安全上下文，只要上下文未过期，后续请求无需重新执行完整的Kerberos协商流程，直接用已有上下文生成Negotiate令牌即可。

如果出现每次都要协商的情况，大概率是未正确维护上下文状态——客户端需持久化上下文句柄，直到其过期或服务器拒绝复用，而非每次请求都重新创建。IIS默认支持上下文复用，正确维护上下文可大幅降低认证开销。

额外实现参考代码 #

Windows平台（SSPI接口）

securityInterface->InitializeSecurityContext(
    &credentials, 
    hasContext ? &securityContext : NULL,  // 复用已有上下文（存在时）
    const_cast<TCHAR*>(servicePrincipalName.c_str()),  // 目标服务的SPN
    ISC_REQ_REPLAY_DETECT | ISC_REQ_SEQUENCE_DETECT | ISC_REQ_CONFIDENTIALITY | ISC_REQ_DELEGATE,  // 请求安全属性：防重放、防乱序、数据保密、委托权限
    0,
    SECURITY_NATIVE_DREP,  // 使用本地系统的数据表示格式
    (inboundData != NULL) ? &inboundBufferDesc : NULL,  // 服务器返回的挑战令牌（首次请求为NULL）
    0,
    &securityContext,  // 输出的安全上下文句柄
    &outboundBufferDesc,  // 生成的Negotiate响应令牌
    &contextAttr,  // 返回的实际生效安全属性
    &expiration);  // 上下文的过期时间

macOS平台（GSS-API接口）

OM_uint32 return_flags{0};
// 请求的安全属性：双向认证、防重放、防乱序、数据保密
OM_uint32 request_flags{GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | GSS_C_SEQUENCE_FLAG | GSS_C_CONF_FLAG};
OM_uint32 minor_status{0};
OM_uint32 major_status = gss_init_sec_context(
    &minor_status, 
    GSS_C_NO_CREDENTIAL,  // 使用系统默认的用户凭证
    (gss_ctx_id_t*)context,  // 复用已有上下文（存在时）
    (gss_name_t)name,  // 目标服务的名称（SPN）
    GSS_KRB5_MECHANISM,  // 指定使用Kerberos作为底层认证机制
    request_flags, 
    0,  // 不指定过期时间，由KDC决定
    GSS_C_NO_CHANNEL_BINDINGS,  // 不使用通道绑定
    (gss_buffer_desc*)input_token_x,  // 服务器返回的挑战令牌（首次请求为NULL）
    nullptr,
    (gss_buffer_desc*)output_token,  // 生成的Negotiate响应令牌
    &return_flags,  // 返回的实际生效安全属性
    nullptr);  // 可按需获取上下文过期时间

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