自定义授权标头

Question

我知道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提供了任意名称,只是为了说明我的授权模式是什么,名称与原始名称不匹配.所以不要打扰模式上的foccus名称.

我的问题是:不遵循对流方式是一件坏事吗？创建自定义授权标题是不好的(如果这是为什么？).

我发现这种方式更简单,可以提供授权和传递令牌的安全方式,所有这些令牌都可以再次在平台中重新生成.

许多设备和移动应用程序已经在使用这个Schema,但它全部都在开发环境下,而且还没有生产.我担心这种非传统的方式可能会影响API的用户.希望社区的想法可以帮助我改善这一点.

编辑:26/03/2017

我想知道它是否会更好以及为什么以协议中描述的方式实现,因为当需要多个授权时比在有自定义标头并且想要检索其值时更难从Headers获取.

遵循协议,您应该使用授权标头,如下所示:

Authorization: <type> <value>

例:

GET - /api/login/{id}

授权:用户USER_TOKEN

但是我无法看到我在这之后得到的东西,因为当获取它的值时会出现一个String或者在示例中它会返回User Token.

使用自定义标头更容易验证令牌.多种授权也会在协议方式下令人头疼.

Answer 1

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

使用RFC7234中Authorization: <type> <value>定义的公共头的主要目的是确保本机实现这些头的处理的客户端和HTTP代理行为正确.

RFC7234的4.2节说:

转发请求的代理不得修改该请求中的任何授权字段.有关HTTP缓存处理授权字段的详细信息和要求,请参见[RFC7234]的第3.2节.

代理可以修改,省略,记录或缓存您的其他Authorization-*标头.

RFC7234,第3.2节说,请求/响应Authorization头不得缓存(特定情况除外).

RFC7235,第5.1.2节,第7点还说明了使用以下标题以外的新身份验证方案Authorization:

因此,通过强制使用Cache-Control请求指令(例如,"no-存储",[RFC7234]的第5.2.1.5节)或响应指令(例如,"私有").

那你该怎么办...？如果您完全控制系统的两端,那么定义一个可能有多个参数来覆盖一个或多个令牌类型的任意组合的新类型值并不是不合理的,只需避免使用该,字符:

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

替代方案更多地依赖于服务器和客户端实现,并且将使用a ,作为多个标头的备用版本列表形式:

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

根据服务器和客户端的不同,可能会被视为:

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

这里的问题是" MAY "(许多额外的重点)被视为相同.有讨论的建议是,各种版本的Apache和NGINX都不会对此进行一致的处理,并且旧的HTTP RFC对于预期的行为非常不清楚.