自定义授权 Header
Custom Authorization Header
我知道 Stack Overflow 上有足够的内容来解决这个问题，但我的主题与其他主题不同。 （有点相同但不相等）
我想听听社区对我所做事情的看法，看看我是否可以在某些地方进行改进。
我目前正在为我的登录端点使用 BASIC 授权，因为它不需要复杂性，而且它是通过 https 进行的，所以它很好。
示例：
GET - /api/login
Authorization : Basic BASE64String(username:password)
我的一些端点需要令牌才能被授予对资源的访问权限。我通过 Headers 和 Https-Secured.
发送这些代币
问题是我没有使用常规方法进行这些授权。下面是一些示例：
示例 1：
GET - /api/hardware/{PUBLIC_TOKEN}/getMe
Authorization-Hardware : PRIVATE_TOKEN
此 EndPoint 不需要 Authorization-Hardware Header，但如果包含更多内容，则由 API 完成。 （此处不相关）
示例 2：
GET - /api/login/{id}
Authorization-Person : USER_TOKEN
否则，此端点是必需的，包括 Authorization-Person Header 和用户令牌以访问资源。 （注意这里Token是如何生成的无关紧要）
要访问 API 端点，需要 HTTPS 请求。
我为上面的自定义 Headers 和端点指定了任意名称，只是为了说明我的授权架构是什么，名称与原始名称不匹配。所以不要打扰名称，只关注架构。
我的问题是：不遵循传统的方式是一件坏事吗？创建自定义授权 Headers 在某种程度上是不好的（如果是为什么？）。
我发现这种方式更容易提供授权和传递令牌的安全方式，所有这些令牌都可以再次 re-generated 在平台中。
很多设备和一个移动应用程序已经在使用这个模式，但它都在开发环境下，还没有在生产环境中。我担心这种 non-conventional 的执行方式可能会影响将来 API 的用户。希望社区的想法可以帮助我改进这一点。
编辑：2017 年 3 月 26 日
我想知道它是否会更好，以及为什么要按照协议中描述的方式实施，因为当需要多个授权时，从 Headers 中获取它比你拥有时更难自定义 Header 并希望检索其值。
按照协议，您应该像这样使用授权 Header：
Authorization: <type> <value>
示例：
GET - /api/login/{id}
Authorization : User USER_TOKEN
但我只是看不出我在这之后得到了什么，因为当获取它的值时会出现一个字符串，或者在示例情况下它会 return 用户令牌。
使用自定义 Header 可以更轻松地验证令牌。遵循协议方式，多重授权也会让人头疼。
TL;DR 一些 header 名称如 Authorization 有关于缓存以及代理和客户端处理的特殊规则；除非您修改每个代理和客户端，否则您的自定义 header 名称不会获得特殊行为。
使用 RFC7234 中定义的通用 Authorization: <type> <value> header 的要点主要是确保客户端和 HTTP 代理本机实现对这些 header 的处理行为正确。
RFC7234 第 4.2 节说：
A proxy forwarding a request MUST NOT modify any Authorization fields
in that request. See Section 3.2 of [RFC7234] for details of and
requirements pertaining to handling of the Authorization field by
HTTP caches.
代理 可以 修改、省略、记录或缓存您的其他 Authorization-* headers.
RFC7234, section 3.2 表示 requests/responses Authorization header 不得缓存（特定情况除外）。
RFC7235, section 5.1.2, point 7 还对使用 headers 而不是 Authorization 的新身份验证方案说了这句话：
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").
那么你应该怎么做...？如果你完全控制系统的两端，那么定义一个可能有多个参数的新类型值来覆盖一种或多种令牌类型的任意组合并不是不合理的，只是避免 , 字符：
Authorization: MyAuth User=USER_TOKEN/Hardware=HWTOKEN/Person=PERSONTOKEN/Basic=...
替代方案更多地取决于服务器和客户端实现，并且将使用 , 作为多个 headers:
的替代版本列表形式
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 对预期行为非常不清楚。
我知道 Stack Overflow 上有足够的内容来解决这个问题，但我的主题与其他主题不同。 （有点相同但不相等）
我想听听社区对我所做事情的看法，看看我是否可以在某些地方进行改进。
我目前正在为我的登录端点使用 BASIC 授权，因为它不需要复杂性，而且它是通过 https 进行的，所以它很好。
示例：
GET - /api/login
Authorization : Basic BASE64String(username:password)
我的一些端点需要令牌才能被授予对资源的访问权限。我通过 Headers 和 Https-Secured.
发送这些代币问题是我没有使用常规方法进行这些授权。下面是一些示例：
示例 1：
GET - /api/hardware/{PUBLIC_TOKEN}/getMe
Authorization-Hardware : PRIVATE_TOKEN
此 EndPoint 不需要 Authorization-Hardware Header，但如果包含更多内容，则由 API 完成。 （此处不相关）
示例 2：
GET - /api/login/{id}
Authorization-Person : USER_TOKEN
否则，此端点是必需的，包括 Authorization-Person Header 和用户令牌以访问资源。 （注意这里Token是如何生成的无关紧要）
要访问 API 端点，需要 HTTPS 请求。
我为上面的自定义 Headers 和端点指定了任意名称，只是为了说明我的授权架构是什么，名称与原始名称不匹配。所以不要打扰名称，只关注架构。
我的问题是：不遵循传统的方式是一件坏事吗？创建自定义授权 Headers 在某种程度上是不好的（如果是为什么？）。
我发现这种方式更容易提供授权和传递令牌的安全方式，所有这些令牌都可以再次 re-generated 在平台中。
很多设备和一个移动应用程序已经在使用这个模式，但它都在开发环境下，还没有在生产环境中。我担心这种 non-conventional 的执行方式可能会影响将来 API 的用户。希望社区的想法可以帮助我改进这一点。
编辑：2017 年 3 月 26 日
我想知道它是否会更好，以及为什么要按照协议中描述的方式实施，因为当需要多个授权时，从 Headers 中获取它比你拥有时更难自定义 Header 并希望检索其值。
按照协议，您应该像这样使用授权 Header：
Authorization: <type> <value>
示例：
GET - /api/login/{id}
Authorization : User USER_TOKEN
但我只是看不出我在这之后得到了什么，因为当获取它的值时会出现一个字符串，或者在示例情况下它会 return 用户令牌。
使用自定义 Header 可以更轻松地验证令牌。遵循协议方式，多重授权也会让人头疼。
TL;DR 一些 header 名称如 Authorization 有关于缓存以及代理和客户端处理的特殊规则；除非您修改每个代理和客户端，否则您的自定义 header 名称不会获得特殊行为。
使用 RFC7234 中定义的通用 Authorization: <type> <value> header 的要点主要是确保客户端和 HTTP 代理本机实现对这些 header 的处理行为正确。
RFC7234 第 4.2 节说：
A proxy forwarding a request MUST NOT modify any Authorization fields in that request. See Section 3.2 of [RFC7234] for details of and requirements pertaining to handling of the Authorization field by HTTP caches.
代理 可以 修改、省略、记录或缓存您的其他 Authorization-* headers.
RFC7234, section 3.2 表示 requests/responses Authorization header 不得缓存（特定情况除外）。
RFC7235, section 5.1.2, point 7 还对使用 headers 而不是 Authorization 的新身份验证方案说了这句话：
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").
那么你应该怎么做...？如果你完全控制系统的两端，那么定义一个可能有多个参数的新类型值来覆盖一种或多种令牌类型的任意组合并不是不合理的，只是避免 , 字符：
Authorization: MyAuth User=USER_TOKEN/Hardware=HWTOKEN/Person=PERSONTOKEN/Basic=...
替代方案更多地取决于服务器和客户端实现，并且将使用 , 作为多个 headers:
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 对预期行为非常不清楚。