我目前正在使用Hawk作为 API 的身份验证方案。基本上，当前流程（强制 SSL）涉及：
- 用户在应用程序上输入电子邮件/密码
- 应用程序使用电子邮件作为盐执行 1000 轮 PBKDF2，将结果与电子邮件一起发送以进行注册
- 服务器使用 scrypt (64k/8/1) 和随机的 32 字节 salt 对密码进行哈希处理，并将加盐密码存储在用户帐户中
- 服务器创建一个 hawk 共享密钥并将其发送回（id 和共享密钥），以便客户端可以在密码正确的情况下创建适当的标头有效负载。
但是，在阅读有关实施的讨论时，出现了一些问题：
我想不出这有什么问题，但由于它很有创意，安全人员不喜欢它。主要问题是您创建的新模式不像正常流程那样容易理解。您应该将其视为/实现为两个系统。一个接受用户名/密码并返回一个令牌（无论是 cookie 还是 rsvp），另一个接受该令牌并获得新的凭据，绑定到使用它的任何人。如果您没有公共 API 或多个应用程序，您的解决方案会走捷径。
抱歉，如果它太笨拙，但是如何添加另一层（如我所见的间接级别）更有益？
查看生产中的 hawk 实现，例如：Mozilla 的onepw 协议，我注意到它们返回一个会话令牌，然后使用 HKDF 派生该令牌以组成 hawk 凭据。