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