api - 自定义授权 header

Question

我知道这个问题在 Stack Overflow 上有足够的内容，但我的主题与其他主题不同。 (有点相同但不相等)

我想听听社区对我所做事情的看法，看看我是否可以在某些地方进行改进。

我目前正在为我的登录端点使用 BASIC 授权，因为它不需要复杂性并且它通过 https，所以它很好。

示例:

GET - /api/login

Authorization : Basic BASE64String(username:password)

我的一些端点需要 token 才能被授予对资源的访问权限。我通过 Headers 和 Https-Secured 发送这些 token 。

问题是我没有使用传统的方法来进行这些授权。下面是一些示例:

示例 1:

GET - /api/hardware/{PUBLIC_TOKEN}/getMe

Authorization-Hardware : PRIVATE_TOKEN

此端点不需要授权硬件 header ，但如果包含更多内容，则由 API 完成。 (此处不相关)

示例 2:

GET - /api/login/{id}

Authorization-Person : USER_TOKEN

否则这个端点是必需的，包括授权人员 header 和用户 token 以访问资源。 (注意这里Token是如何生成的无关紧要)

要访问 API 端点，需要 HTTPS 请求。

我为上面的自定义 header 和端点指定了任意名称，只是为了说明我的授权架构是什么，这些名称与原始名称不匹配。所以不要打扰名称，只关注架构。

我的问题是:不遵循传统的方式是一件坏事吗？创建自定义授权 header 在某种程度上是不好的(如果是为什么？)。

我发现这种方式更容易提供授权和传递 token 的安全方式，所有这些 token 都可以在平台中重新生成。

许多设备和移动应用程序已经在使用此架构，但它们都在开发环境下，尚未投入生产。我担心这种非常规的做法会影响 future API 的用户。希望社区的想法可以帮助我改进这一点。

编辑:2017 年 3 月 26 日

我想知道它是否会更好以及为什么以协议(protocol)中描述的方式实现，因为当需要多个授权时比您拥有自定义 header 并想要检索时更难从 header 中获取它的值(value)。

按照协议(protocol)，您应该像这样使用授权 header :

Authorization: <type> <value>

示例:

GET - /api/login/{id}

Authorization : User USER_TOKEN

但我只是看不出我在这之后得到了什么，因为当获取它的值时会出现一个字符串，或者在示例情况下它会返回用户 token 。

使用自定义 header 可以更轻松地验证 token 。遵循协议(protocol)方式，多重授权也会让人头疼。

Answer 1

TL;DR 一些 header 名称，例如 Authorization有关于缓存以及代理和客户端处理的特殊规则；除非您修改每个代理和客户端，否则您的自定义 header 名称不会获得特殊行为。

使用共同点Authorization: <type> <value> RFC7234 中定义的 header 主要是为了确保 native 实现对这些 header 的处理的客户端和 HTTP 代理行为正确。

RFC7234 第 4.2 节说:

A proxy forwarding a request MUST NOT modify any Authorization fieldsin that request. See Section 3.2 of [RFC7234] for details of andrequirements pertaining to handling of the Authorization field byHTTP caches.

代理可能修改、省略、记录或缓存您的其他Authorization-*标题。

RFC7234, section 3.2说请求/响应 Authorization header 不得缓存(特定情况除外)。

RFC7235, section 5.1.2, point 7此外还有关于使用 Authorization 以外的 header 的新身份验证方案的说法:

Therefore, new authentication schemes that choose not to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response directives (e.g., "private").

那么你应该怎么做...？如果你完全控制系统的两端，那么定义一个可能有多个参数的新类型值来覆盖一种或多种 token 类型的任意组合并不是不合理的，只是避免了 ,字符:

Authorization: MyAuth User=USER_TOKEN/Hardware=HWTOKEN/Person=PERSONTOKEN/Basic=...

替代方案更多地取决于服务器和客户端的实现，并且会使用 ,作为多个 header 的替代版本列表形式:

Authorization: User USER_TOKEN, Hardware=HWTOKEN, Person=PERSONTOKEN, Basic=...

这取决于服务器和客户端，可能被视为相同:

Authorization: User USER_TOKEN
Authorization: Hardware HWTOKEN
Authorization: Person PERSONTOKEN
Authorization: Basic ...

这里的问题是“可以”(大量强调)被同等对待。有讨论表明，不同版本的 Apache 和 NGINX 并没有一致地对待这一点，而且旧的 HTTP RFC 对预期行为非常不清楚。