3.1 使用受權碼流驗證（Authentication using the Authorization Code Flow）
本節描述如何使用受權碼流執行驗證。當使用受權碼流時，會從令牌終結點返回的全部令牌。瀏覽器
受權碼流返回受權碼給客戶端,這個受權碼能夠直接交換一個ID Token和一個Access Token。這給User Agent提供了不暴露任何令牌的好處，由於可能還有其餘惡意的應用程序訪問User Agent。受權服務器也能夠在驗證客戶端以前經過Access Token交換的受權碼。受權碼流適合那些能夠安全地在客戶與密鑰受權服務器之間進行客戶密碼維護的場景。安全
3.1.1 受權碼流步驟（Authorization Code Flow Steps）
受權碼流通過如下步驟。服務器
一、客戶準備一個包含所需的驗證請求的請求參數。cookie
二、客戶端發送請求到受權服務器。app
三、受權服務器驗證用戶。ui
四、受權服務器得到用戶贊成/受權。編碼
五、受權服務器給終端用戶發送回一個受權碼給客戶端。加密
六、客戶端使用受權碼向令牌終結點請求一個響應。url
七、客戶端接收到包含一個ID Token和Access Token響應body。spa
八、客戶端驗證ID Token和檢索終端用戶的 Subject標識符。
3.1.2 受權終結點（Authorization Endpoint）
受權終結點對終端用戶的驗證。是經過發送User Agent到受權服務器的驗證和受權的終結點，其請求參數在OAuth 2.0中定義，額外的參數和參數值定義在OpenID Connect中定義。
受權終結點的通訊必須使用TLS。參看16.17節中關於TLS的更多信息。
3.1.2.1驗證請求（Authentication Request）
一個驗證請求是OAuth 2.0由受權服務器的終端用戶驗證的受權請求。
受權服務器必須支持使用受權終結點在RFC 2616中定義的HTTP GET和POST方法。客戶可使用HTTP GET或POST方法來發送受權請求到受權服務器。若是使用HTTP GET方法，請求參數的序列化是使用每URI查詢字符串序列化（13.1節）。若是使用HTTP POST 方法，請求參數序列化使用表單序列化形式（13.2節）。
OpenID Connect使用下面的OAuth 2.0受權碼流的請求參數：
scope
必需的。OpenID Connect請求必須包含 openid scope值。若是 openid scope值不存在，其行爲是徹底不肯定的。可能存在其餘scope值。對不能理解 scope實現值應該被忽略。參看（5.4 和 11 這個規範定義的額外的scope值部份）。
response_type
必需的。決定受權處理的流程，並從終結點返回什麼樣的參數是由OAuth 2.0響應類型值所決定。當使用受權碼流，其值是 code。
client_id
必需的。OAuth 2.0 對受權服務器有效的客戶端標識符。
redirect_uri
必需的。將由響應發送的重定向URL。此URI必須是精確匹配客戶端預先註冊的OpenID提供者的重定向URI值，匹配執行的描述在 6.2.1節 (RFC3986) (簡單的字符串比較)。當使用此流程，重定向URI應該使用 https 方案; 但它也可使用 http方案，在這種OP容許使用 http 重定向URL提供方式狀況下，如何提供客戶端類型保密，在OAuth 2.0 2.1節中定義。重定向的URI可能使用一個替代方案，好比，例如，當目的是識別本機應用程序一個回調時。
state
推薦。不透明值，在維護請求和回調之間狀態時使用。通常來講，是經過瀏覽器一個cookie加密值，以下降跨站請求僞造(CSRF XSRF)。
OpenID Connect也使用OAuth 2.0請求參數，此定義在 OAuth 2.0有多個響應類型編碼實踐。
response_mode
可選的。通知受權服務器從受權終結點返回參數使用的機制。不推薦使用這個響應模式參數，而將其請求設定爲響應類型指定的默認模式。
此規範還定義瞭如下請求參數:
nonce
可選的。字符串值，用於關聯客戶端會話的ID Token，以減輕重播攻擊。該值在驗證ID Token請求中不會修改。Nonce必須有足夠的複雜度去防止攻擊者猜想值。實現說明，請參閱 15.5.2節 。
display
可選的。驗證和受權服務器的ASCII字符串值，指示如何顯示在經由終端用戶贊成的用戶界面頁面上，定義的值是:
page
受權服務器應該顯示的驗證和贊成UI與一個完整的User Agent頁面一致的視圖。若是沒有指定顯示參數，就採用默認顯示模式。
popup
受權服務器應該顯示驗證和一致的用戶贊成界面的一個彈出User Agent窗口。彈出User Agent窗口應該適當的大小，在整個窗口中不該掩蓋login-focused對話框呈現。
touch
受權服務器應該在利用可觸摸設備中顯示的驗證和一致的用戶贊成界面。
wap
受權服務器應該在「功能手機」中顯示的驗證和一致的用戶贊成界面。
受權服務器也可能試圖檢測User Agent功能，並呈現一個適當的顯示。
prompt
可選的。空格分隔的，區分大小寫的ASCII字符串值列表，指定是否受權服務器提示終端用戶重認證和贊成。定義的值是:
none
受權服務器不能顯示任何驗證或贊成的用戶頁面。若是一個終端用戶尚未通過驗證或客戶端沒有預配置請求贊成聲明或不知足其餘條件處理請求時返回一個錯誤。一般的錯誤代碼是login_required ，interaction_required ，或定義在 3.1.2.6節的另外的代碼 。能夠用於檢查現有的受權 和/或 贊成的方法。
login
受權服務器應該提示終端用戶重認證。若是終端用戶不能重認證,必須返回一個錯誤，一般 login_required 。
consent
受權服務器應該提示終端用戶准許，而後返回信息到客戶端。若是不能得到准許,它必須返回一個錯誤，一般 consent_required 。
select_account
受權服務器應該提示用戶選擇一個賬戶。這在一個終端用戶有多個帳戶的受權服務器上在當前會話中進行多個賬戶選擇。若是不能得到一個由終端用戶選擇的賬戶，必須返回一個錯誤，一般 account_selection_required 。
提示參數能被客戶端使用，以確保終端用戶在當前會話中存在或者請求意圖。若是這個參數不包含任何其餘值，則返回錯誤。
max_age
可選的。驗證最大過時時間。指定容許存續時間，以秒爲單位，是自上次經過OP終端用戶激活驗證的存續時間，若是存續時間大於這個值，OP必須積極嘗試對終端用戶進行從新確認。(max_age 請求參數對應 OpenID 2.0 PAPE (OpenID.PAPE)的 max_auth_age 請求參數)。當使用max_age,返回的ID Token中必須包括一個 auth_time 聲明值。
ui_locales
可選的。終端用戶界面的首選語言和腳本，表示爲一個BCP47 RFC5646語言標記值的空格分隔的列表，按偏好排序。如,值「fr-CA fr en」表明了一種偏好：加拿大的法語、法語(沒有指定一個區域)，其次是英語(沒有指定一個區域)。若是OpenID提供者不支持部分和全部請求的區域設置不該該產生錯誤。
id_token_hint
可選的。以前由受權服務器簽發的ID Token，做爲暗示，傳遞給終端用戶與客戶驗證的當前或過去會話。若是終端用戶已經被登陸的ID Token登確認或已登陸的請求,那麼受權服務器返回一個確定的響應； 不然，它應該返回一個錯誤，如 login_required 。在可能的狀況下，當 prompt=none 時應該使用id_token_hint，如不是則應返回一個 invalid_request 錯誤；固然，服務器應該在容許的狀況下響應成功，即便它不存在。受權服務器不該當在ID Token使用id_token_hint值時坐視不理。
若是RP接收到被OP加密的ID Token，並使用它做爲id_token_hint ，客戶端必須解密簽名ID Token中包含加密ID Token。客戶可能使用認證服務器能解密的鍵值重加密簽名ID Token，和用從新加密ID Token方式加密id_token_hint值。
login_hint
可選的。關於終端用戶可能使用登陸標識符登陸(若是有必要)提示給受權服務器。這種暗示能夠被RP使用，若是它首先尋問終端用戶的電子郵件地址(或其餘標識符)，而後想經過這個值做爲一個發現受權服務提示。建議提示值匹配用於發現的值。這個值多是一個電話號碼的格式指定 phone_number 聲明。由OP決定是否使用這個參數。
acr_values
可選的。請求的驗證上下文類引用值。指定了被請求處理驗證請求受權服務器使用的 acr空格分隔的字符串值，值的出現按優先順序排列。做爲 acr 聲明值返回知足執行驗證的驗證上下文類，第二節指定，acr 聲明請求是主動聲明的參數。
其餘參數可能會被髮送。部分參看 3.2.2 ，3.3.2 ，5.2 ，5.5 ，6 ，7.2.1 ，由該規範定義的額外的受權請求參數和參數值。
下面是一個非規範的例子，由客戶機的 HTTP 302重定向響應，User Agent驗證請求受權終結點觸發器:
HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
下面是請求非規範化的例子，這將是由User Agent發送到受權服務器，響應的HTTP 302重定向響應客戶端上面:
GET /authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com
3.1.2.2驗證請求驗證（Authentication Request Validation）
受權服務器必須驗證收到的請求以下:
一、受權服務器必須根據OAuth 2.0規範驗證全部的 OAuth 2.0參數。
二、驗證scope參數存在，而且包含 openid scope值。(若是沒有 openid scope值，請求可能仍然是一個有效的OAuth 2.0的要求，但不是一個OpenID Connect請求。)
三、受權服務器必須驗證全部必需的參數存在，以及他們的使用符合本規範。
四、若是sub(主題)聲明請求一個特定的值的ID Token，受權服務器只會發送一個確定的響應，若是終端用戶確認sub值是具備一個與受權服務器活躍的會話或已經經過驗證的請求的結果。受權服務器沒必要爲不一樣的用戶回覆ID 令牌或Access Token，即便他們有活動的會話與受權服務器。若是有這樣的要求，可以使用 id_token_hint 參數或經過請求一個特定的在5.5.1節描述的聲明值。若是聲明參數支持實現。
OAuth 2.0 (RFC6749)指明受權服務器應該忽略未識別的請求參數。
若是受權服務器遇到任何錯誤，它必須返回一個錯誤的響應,參看 3.1.2.6節 。
3.1.2.3受權服務器驗證用戶（Authorization Server Authenticates End-User）
若是請求是有效的，根據使用的請求參數值，受權服務器嘗試對終端用戶進行驗證或肯定終端用戶驗證。受權服務器所使用的對終端用戶進行驗證的方法(如用戶名和密碼,會話cookie,等等)。超出了本規範的範圍。受權服務器根據請求參數值使用和所使用的驗證方法顯示驗證用戶界面。
在下列狀況下受權服務器必須嘗試驗證終端用戶：
- 終端用戶沒有進行驗證。
- 驗證請求包含登陸提示參數值。在這種狀況下，受權服務器必須重驗證終端用戶，即便終端用戶已經經過驗證。
受權服務器在下列狀況下不該與用戶交互：
- 驗證請求沒有任何包含登陸提示參數值。在這種狀況下，若是一個終端用戶不是已經經過認證或不能隱式的經過驗證，受權服務器必須返回一個錯誤。
與終端用戶交互時，受權服務器必須採起適當的措施防範跨站點請求僞造和「點擊劫持」如OAuth 2.0 [RFC6749] 10.12和10.13章節描述的那樣。
3.1.2.4受權服務器得到用戶贊成/受權（Authorization Server Obtains End-User Consent/Authorization）
一旦對終端用戶進行驗證，在對依賴方科放信息以前受權服務器必須得到一個受權決定。當使用的請求參數被許可，就能夠與終端用戶經過交互式對話，使它清楚已贊成或經過創建經過條件處理請求下贊成，其餘方式(例如：經過之前的管理許可)。在 2 和 5.3信息發佈機制部分描述。
3.1.2.5成功的驗證響應（Successful Authentication Response）
一個驗證響應，是從RP發出的受權請求，並由OP的受權終結點響應的OAuth 2.0受權響應消息。
當使用受權碼流，受權響應返回由OAuth 2.0 (RFC6749) 4.1.2節中定義的參數，經過添加查詢參數 redirect_uri 中指定的受權請求，使用application/x-www-form-urlencoded格式，除非指定不一樣的響應模式。
下面是一個成功的響應使用此流程非規範化的例子:
HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA
&state=af0ifjsldkj
實現例子中關於受權碼內容,參看15.5.1節 。