OAuth 2.0承载令牌配置文件与MAC令牌配置文件

我今天看到的几乎所有实施都是基于OAuth 2.0 Bearer Token Profile。 当然，今天它是RFC提出的标准。 OAuth 2.0承载令牌配置文件带来了一种简化的身份验证方案。 本规范描述了如何在HTTP请求中使用承载令牌来访问OAuth 2.0受保护的资源。 拥有承载令牌的任何一方（“承载者”）都可以使用它来访问关联的资源（不证明拥有加密密钥）。 为了防止滥用，需要保护无记名令牌在存储和运输中不被泄露。 在深入研究OAuth 2.0 MAC配置文件之前，让我们快速概述OAuth 2.0消息流。 OAuth 2.0主要分为三个阶段。

1.申请授权拨款。

2.交换访问令牌的授权授予。

3.使用访问令牌访问资源。

令牌类型在哪里起作用？ OAuth 2.0 核心规范不要求任何令牌类型。 同时，令牌请求者（客户端）无法随时确定所需的令牌类型。 完全由授权服务器决定在访问令牌响应中返回哪种令牌类型。 因此，当授权服务器返回OAuth 2.0访问令牌时，令牌类型将在阶段2中起作用。

访问令牌类型为客户端提供成功利用访问令牌发出受保护资源请求所需的信息（以及特定于类型的属性）。 如果客户端不了解令牌类型，则不得使用访问令牌。

每个访问令牌类型定义都指定了发送给客户端的其他属性（如果有）以及“ access_token”响应参数。 它还定义了HTTP身份验证方法，该方法用于在发出受保护的资源请求时包括访问令牌。

例如，无论使用哪种授权类型，以下是访问令牌响应的结果。

HTTP/1.1 200 OK

Content-Type: application/json;charset=UTF-8

Cache-Control: no-store

Pragma: no-cache

{

'access_token':'mF_9.B5f-4.1JqM',

'token_type':'Bearer',

'expires_in':3600,

'refresh_token':'tGzv3JOkF0XG5Qx2TlKWIA'

}

上面是针对Bearer的-以下是针对MAC的。

HTTP/1.1 200 OK

Content-Type: application/json

Cache-Control: no-store

{

'access_token':'SlAV32hkKG',

'token_type':'mac',

'expires_in':3600,

'refresh_token':'8xLOxBtZp8',

'mac_key':'adijq39jdlaska9asud',

'mac_algorithm':'hmac-sha-256'

}

在这里，您可以看到MAC访问令牌响应具有两个附加属性。 mac_key和mac_algorithm。 让我重新表述一下-“每个访问令牌类型定义都指定了与“ access_token”响应参数一起发送给客户端的其他属性（如果有）。

该MAC令牌配置文件定义了HTTP MAC访问认证方案，提供了一种通过部分加密验证请求来进行认证的HTTP请求的方法，该方法涵盖了HTTP方法，请求URI和主机。 在上面的响应中，access_token是MAC密钥标识符。

与Bearer不同，MAC令牌配置文件永远不会通过网络传递其最高机密。

access_token或MAC密钥标识符是标识用于计算请求MAC的MAC密钥的字符串。 该字符串通常对客户端是不透明的。 服务器通常为每组MAC凭证分配特定的范围和生存期。 标识符可以表示用于检索授权信息（例如，从数据库中）或以可验证的方式（即，由某些数据和签名组成的字符串）自包含授权信息的唯一值。

mac_key是用作MAC算法密钥的共享对称密钥。 服务器将不会重新发出先前发布的MAC密钥和MAC密钥标识符组合。 现在，让我们看看第三阶段会发生什么。 下面显示了使用Bearer Token时Authorization HTTP标头的外观。

Authorization: Bearer mF_9.B5f-4.1JqM

这在客户端增加了非常低的开销。 它只需要传递阶段2中从授权服务器获得的确切access_token。 在MAC令牌配置文件下，这就是它的样子。

Authorization: MAC id='h480djs93hd8',

ts='1336363200',

nonce='dj83hs9s',

mac='bhCQXTVyfj5cmA9uKkPFx1zeOXM='

这需要更多的注意。 id是第二阶段的MAC密钥标识符或access_token。 TS中的请求的时间戳。 该值是客户端在发出每个请求到从固定时间点（例如，格林尼治标准时间1970年1月1日00:00:00）经过的秒数时设置的正整数。 在具有相同时间戳和MAC密钥标识符组合的所有请求中，此值都是唯一的。 随机数是客户端生成的唯一字符串。 该值在所有具有相同时间戳和MAC密钥标识符组合的请求中都是唯一的。 客户端使用MAC算法和MAC密钥来计算请求mac 。 这是派生标准化字符串以生成HMAC的方式。 规范化的请求字符串是多个HTTP请求元素到单个字符串中的一致，可复制的串联。 通过将请求规范化为可复制的字符串，客户端和服务器都可以在完全相同的值上计算请求MAC。 通过按顺序将以下HTTP请求元素串联在一起来构造字符串，每个HTTP请求元素后跟一个换行符（％x0A）：

1. 为请求计算的时间戳值。
2. 为请求生成的现时值。
3. 大写的HTTP请求方法。 例如：“ HEAD”，“ GET”，“ POST”等。
4. 由[RFC2616] 5.1.2节定义的HTTP请求URI。
5. HTTP请求中包含的主机名（使用小写的“主机”请求标头字段）。
6. 使用“主机”请求标头字段包含在HTTP请求中的端口。 如果报头字段不包括端口，则必须使用方案的默认值（例如，HTTP为80，HTTPS为443）。
7. 如果请求中包含“ ext”“授权”请求标头字段属性的值（这是可选的），否则为空字符串。

每个元素后跟一个换行符（％x0A），包括最后一个元素，即使元素值是空字符串也是如此。 您使用MAC承载–使用access_token标识最终用户或资源所有者。 无论您使用哪个令牌概要文件，都可以针对access_token进行授权，限制，监视或任何其他服务质量操作。

参考： Facile登录博客上的OAuth 2.0承载令牌配置文件与我们的JCG合作伙伴 Prabath Siriwardena的MAC令牌配置文件 。

翻译自: https://www.javacodegeeks.com/2013/01/oauth-2-0-bearer-token-profile-vs-mac-token-profile.html