【开发笔记】摘要认证 SHA-256 校验 response 算法

虽然现在应该很少人自己撰写生成 SHA-256 编码的摘要请求，但是在年岁久远的商务内部系统，很多事情只能自己来（踩过坑的你会懂的 T_T）

HTTP 认证

尽管网路连线方式在 2022 年的今天，相较 20 年前应运了不少新的技术问世。不过在多数情况下，终端用户目前所采用的连线方式，基本上还是以 HTTP 的请求－反馈为主。

当然说到连线传输，不能不提到的就是认证方式。从早期 Basic Authentication 和 Digest Authentication，后来 Twitter 引领风骚的 OAuth，再到目前方兴未艾的 JSON Web Tokens (JWT)，都是建构 HTTP 请求与伺服器互动取得讯息过程中，不可或缺的一环。

SHA-256 / MD5 编码的摘要认证

比较起来虽然起始年代已经久远，时至今日 Basic 和 Digest 认证还是有其运用上的价值。其中 Digest 认证经历了后续的安全性加强，在保护能力上提供了更佳明文攻击与密码分析的防御能力。

实作流程上，无论是 SHA-256 或是 MD5 编码， response 算法包含的变量，都会受到 qop 宣告所影响。

# 当 qop 未指定时，response 计算带上 nonce 即可
response = H(A1:nonce:A2)

# 当 qop 指定为 auth 或 auth-int，response 计算还需要带上其他属性的变量如下：
response = H(A1:nonce:nc:cnonce:qop:A2)

# 留意 H(...) 可以是 MD5 或是 SHA-256 编码

至于 A1 第一条哈希值的计算都是固定的，也就是：

A1 = H(username:realm:password)

而 A2 第二条哈希值的计算同样会受到 qop 指定的内容所影响

# 当 qop 指定为 auth 时
A2 = H(method:digest-uri)

# 当 qop 指定为 auth-int 时
A2 = H(method:digest-uri:H(entity-body))

总有需要自己算的时候

可能有人会疑问，这些验证过程不是有现成的程式库可以引用吗？在一些主要的执行平台上或许如此。但总有这样的时候，特别是在年岁已经比较久远的内部系统，对于 realm，nonce，nc 有额外客制化的定义时，就算有程式库可以引用也是没戏。所以稍微了解复习一下这些富有历史的基本校验方式也是不错的，没准哪天就会遇到了。