OAuth2.0 - 四种受权模式(4 - 客户端凭证模式)

4.4. Client Credentials Grant(客户端凭证模式)

    客户端模式（Client Credentials Grant）指客户端以本身的名义，而不是以用户的名义，向"受权服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以本身的名义要求"服务提供商"提供服务，其实不存在受权问题。

     当客户端请求访问其控制下的受保护资源或先前与受权服务一块儿安排的其余资源全部者的资源时，客户端能够仅使用自身客户端凭证（或其余支持的身份验证手段）向"受权服务提供商"请求访问令牌。

    !注意：客户端凭据授予类型(client credentials grant type)必须仅在机密(可信)客户端使用。

客户端模式

它的步骤以下：

• （A）客户端向受权服务器进行身份认证，并从 token endpoint 请求一个访问令牌。
• （B）受权务器确验证客户端，若是有效，向客户端发出访问令牌。

 

4.4.1. Authorization Request and Response(受权请求及响应)

------------------------------------------------------------------------------------------------

    Since the client authentication is used as the authorization grant, no additional authorization request is needed.

    因为客户端认证被用做 authorization grant ，因此不须要额外的受权请求。

 

4.4.2. Access Token Request(访问令牌请求)

------------------------------------------------------------------------------------------------

    The client makes a request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:

    客户端经过创建一个特定的请求并把该请求发送给令牌端点(token endpoint)来获取访问令牌。 该特定请求的内容要求：在HTTP request entity-body中以UTF-8字符编码并按 "application/x-www-form-urlencoded"(附录B中)规定的格式添加如下参数：

• grant_type: 表示受权类型，值为"client_credentials"，必选项。

• scope: 表示权限范围，如 3.3. 节中所描述的访问请求的范围，可选项。

   

    The client MUST authenticate with the authorization server as described in Section 3.2.1.

    客户端必须如在3.2.1节中描述的那样使用受权服务器进行身份认证。

    

    For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only):

    例如，客户端创建以下传输层安全性(transport-layer security)（带有只用于显示目的的额外的换行符）的HTTP请求：

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

    

    The authorization server MUST authenticate the client.

    受权（认证）服务器必须以某种方式认证客户端身份。

 

4.4.3. Access Token Response(访问令牌响应)

------------------------------------------------------------------------------------------------

    If the access token request is valid and authorized, the authorization server issues an access token as described in Section 5.1. A refresh token SHOULD NOT be included. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2.

    若是访问令牌请求是有效的并已被受权的，则受权服务器发出如5.1节中所描述的访问令牌。 不该包括刷新令牌。 若是客户端身份验证请求失败或无效，受权服务器将返回如5.1节中所描述的错误响应。

An example successful response:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"example",
    "expires_in":3600,
    "example_parameter":"example_value"
}

 

Appendix B. Use of application/x-www-form-urlencoded Media Type

附录B. 使用 Media Type(Media类型): application/x-www-form-urlencoded

------------------------------------------------------------------------------------------------

    At the time of publication of this specification, the "application/x-www-form-urlencoded" media type was defined in Section 17.13.4 of [W3C.REC-html401-19991224] but not registered in the IANA MIME Media Types registry (http://www.iana.org/assignments/media-types). Furthermore, that definition is incomplete, as it does not consider non-US-ASCII characters.

    To address this shortcoming when generating payloads using this media type, names and values MUST be encoded using the UTF-8 character encoding scheme [RFC3629] first; the resulting octet sequence then needs to be further encoded using the escaping rules defined in [W3C.REC-html401-19991224].

    When parsing data from a payload using this media type, the names and values resulting from reversing the name/value encoding consequently need to be treated as octet sequences, to be decoded using the UTF-8 character encoding scheme.

    For example, the value consisting of the six Unicode code points (1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN), (3) U+0026 (AMPERSAND), (4) U+002B (PLUS SIGN), (5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would be encoded into the octet sequence below (using hexadecimal notation):

20 25 26 2B C2 A3 E2 82 AC

and then represented in the payload as:

+%25%26%2B%C2%A3%E2%82%AC