HTTP 授权标头中 auth-scheme 的用途答案

【问题标题】：Purpose of auth-scheme in HTTP Authorization headerHTTP 授权标头中 auth-scheme 的用途
【发布时间】：2016-09-19 06:57:38
【问题描述】：

我对@987654330@ 有疑问。我偶然发现了 JSON Web Tokens 和官方页面之一：

他们使用

Authorization: Bearer <token>

过去，我熟悉Authorization: JWT <token>，并认为这是正确的，直到今天，我阅读了JWT官方网页，他们改用Bearer <token>。

我正在测试 Knock Rails gem：https://github.com/nsarno/knock，并且使用这个库，我能够使用随机身份验证方案向我的 Rails API 发出 Postman 请求：

我什至可以完全摆脱 auth-scheme：

但是，当我从 Authorization 标头中删除我的 JWT 令牌时，它会按预期返回 401 Unauthorized 响应，所以我知道它正在...工作？

所以我开始思考...... auth-scheme 有什么目的吗？

图书馆或网络服务器是否应该尊重/尊重/强制在授权标头中正确使用 auth-scheme？

我在寻求答案的过程中偶然发现了这篇 Stackoverflow 帖子：

显示官方格式为：

credentials = auth-scheme #auth-param

给出的例子更离奇：

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

我不知道这是否属于编程问题。我可以盲目地关注/使用第三方库。

auth-scheme 的目的是什么？

我不是密码学/计算机安全专家。

也许有人可以阐明这个问题（或者可能不是问题？）？

【问题讨论】：

【解决方案1】：

授权方案只是向服务器指示所遵循的凭据类型。客户端可以使用basic方案

Authorization: Basic <base64(username:password)>

或bearer方案

Authorization: Bearer <base64(JWT)>

或Hawk 方案

Authorization: Hawk id="...", ts="...", nonce="...", ext="...", mac="..."

或者它可以与服务器达成一致的任何其他方案。

【讨论】：

是的，auth-scheme就是告诉服务器后面的token是什么，这个很明显。更重要的问题是服务器是否应该强制执行它？
@Zhang 如果服务器只接受 JWT 令牌作为授权，则可以原谅，忽略 auth 方案标识符。但是如果服务器支持多种身份验证方案，它需要标识符才能分辨出它后面的内容。
听起来很明智 :) 我想我担心的是，如果服务器不使用收到的令牌强制执行身份验证方案，它是否会在未来构成安全问题。
我没有看到安全问题。只要通过的凭据得到验证。但是我也没有看到省略标识符有什么好处。