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

转载于:https://my.oschina.net/u/2401395/blog/2877136