我知道Stack Overflow上的这个问题有足够的内容，但我的主题与其他主题不同。 （有点相同但不相等）
我希望听到社区对我所做的事情的看法，并想知道我是否可以在某处改善。
我目前正在为我的登录EndPoint使用BASIC授权，因为它不需要复杂性，而且不需要https，所以它的方式很好。
示例：
GET - / api / login
授权：基本BASE64String（用户名：密码）
我的一些EndPoints要求令牌被授予对资源的访问权限。这些令牌我通过Headers和Https-Secured发送。
问题是我没有使用传统方法来执行这些授权。以下是一些例子：
示例1：
GET - / api / hardware / {PUBLIC_TOKEN} / getMe
授权 - 硬件： PRIVATE_TOKEN
此EndPoint不需要授权 - 硬件标头，但如果包含更多内容则由API完成。 （这里不相关）
示例2：
GET - / api / login / {id}
授权人： USER_TOKEN
此EndPoint是必要的，包括具有用户令牌的授权人头以访问资源。 （请注意，如何生成令牌与此无关）
要访问API EndPoints，必须提供HTTPS请求。
我给上面的自定义标题和EndPoints提供了任意名称，只是为了说明我的授权模式是什么，这些名称与原始名称不匹配。因此，请不要仅仅关注模式中的名称。
我的问题是：不遵循对流方式是一件坏事吗？创建自定义授权标题是不好的（如果这是为什么？）。
我发现这种方式更简单，可以提供授权和传递令牌的安全方式，所有这些令牌都可以在平台中重新生成。
许多设备和移动应用程序已经在使用这个架构，但它全部都在开发环境下，而且尚未生产。我担心这种非传统的方式可能会影响API的用户。希望社区的想法可以帮助我改善这一点。
编辑：26/03/2017
我想知道它是否会更好以及为什么以协议中描述的方式实现，因为当需要多个授权时比在有自定义标头并且想要检索时更难从Headers中获取它的价值。
遵循协议，你应该像这样使用授权标题：
Authorization: <type> <value>
示例：
GET - / api / login / {id}
授权：用户 USER_TOKEN
但我无法看到我在此之后获得的内容，因为在获取其值时会出现一个字符串，或者在示例中它将返回用户令牌。
使用自定义标头更容易验证令牌。多种授权也会在协议方式下令人头疼。
答案 0 :(得分：8)
TL; DR某些标题名称（例如Authorization）有关于缓存的特殊规则以及代理和＆amp;客户处理;您的自定义标题名称不会获得特殊行为，除非您修改了每个代理和＆amp;客户端。
使用RFC7234中定义的公共Authorization: <type> <value>标头主要是为了确保客户端＆amp;本机实现这些标头处理的HTTP代理行为正确。
RFC7234的第4.2节说：
转发请求的代理不得修改任何授权字段 在那个请求中。有关和的详细信息，请参见[RFC7234]的第3.2节 有关处理授权字段的要求 HTTP缓存。
代理可能修改，省略，记录或缓存其他Authorization-*标题。
RFC7234, section 3.2表示请求/响应Authorization标头不得缓存（特殊情况除外）。
RFC7235, section 5.1.2, point 7此外还有关于使用Authorization以外的标头的新身份验证方案的说法：
因此，选择不在授权头字段中携带凭证的新认证方案（例如，使用新定义的头字段）将需要通过强制使用任一高速缓存控制请求指令来明确禁止高速缓存（例如， “无存储”，[RFC7234]第5.2.1.5节）或响应指令（例如，“私有”）。
那你该怎么做......？如果您完全控制系统的两端，那么定义一个可能有多个参数来覆盖一个或多个令牌类型的任何组合的新类型值并不是不合理的，只需避免使用,字符：
Authorization: MyAuth User=USER_TOKEN/Hardware=HWTOKEN/Person=PERSONTOKEN/Basic=...
替代方案取决于服务器＆amp;客户端实现更多，并将使用,作为多个标头的备用版本列表形式：
Authorization: User USER_TOKEN, Hardware=HWTOKEN, Person=PERSONTOKEN, Basic=...
取决于服务器＆amp;客户，可能会被视为：
Authorization: User USER_TOKEN
Authorization: Hardware HWTOKEN
Authorization: Person PERSONTOKEN
Authorization: Basic ...
这里的问题是“ MAY ”（许多额外的重点）被视为相同。有讨论建议各种版本的Apache＆amp; NGINX不会始终如一地对待这一点，并且旧的HTTP RFC对于预期的行为非常不清楚。