OpenID Connect：OAuth 2.0协议之上的简单身份层
OpenID Connect是什么？OpenID Connect(目前版本是1.0)是OAuth 2.0協議(可參考本人此篇：OAuth 2.0 / RCF6749 協議解讀)之上的簡單身份層，用 API 進行身份交互的框架，允許客戶端根據授權服務器的認證結果最終確認用戶的身份，以及獲取基本的用戶信息；它支持包括Web、移動、JavaScript在內的所有客戶端類型；它是可擴展的協議，允許你使用某些可選功能，如身份數據加密、OpenID提供商發現、會話管理
OpenID Connect vs?OpenID 2.0：OpenID Connect完成很多與OpenID 2.0相同的任務，是API-friendly，定義了可選的簽名和加密的機制；OAuth 1.0a和OpenID 2.0的集成需要擴展，而OpenID Connect協議本身就建立在OAuth 2.0之上
部分名詞解釋：
1. Relying Party(RP)：依賴方，通常是第三方應用程序(客戶端)
2. OpenID Provider(OP)：OpenID 提供方，通常是一個 OpenID 認證服務器，它能為依賴方提供斷言以證實用戶擁有某個標識
3. End-User(EU)：終端用戶，指持有賬號的人OpenID Connect協議構成：
下邊兩條是 Web RPs 實現者的獨立參考指南:
協議遷移規范:
OpenID Connect 工作組已啟動新的工作計劃:
OpenID Connect Profile for SCIM Services?– (Optional) Defines how to use SCIM with OpenID Connect
OpenID Connect Federation?– (Optional) Defines how sets of OPs and RPs can establish trust by utilizing a Federation Operator
OpenID 2.0 to OpenID Connect Migration 1.0?– Defines how to migrate from OpenID 2.0 to OpenID Connect
Basic Client Implementer’s Guide?– Simple subset of the Core functionality for a web-based Relying Party using the OAuth code flow
Implicit Client Implementer’s Guide?– Simple subset of the Core functionality for a web-based Relying Party using the OAuth implicit flow
Core?– 定義 OpenID Connect 核心功能:?認證建立在OAuth 2.0之上，使用聲明與終端用戶進行信息交互
Discovery?– (Optional) Defines how Clients dynamically discover information about OpenID Providers
Dynamic Registration?– (Optional) Defines how clients dynamically register with OpenID Providers
OAuth 2.0 Multiple Response Types?– 定義了幾種新的OAuth 2.0響應類型
OAuth 2.0 Form Post Response Mode?– (Optional) Defines how to return OAuth 2.0 Authorization Response parameters (including OpenID Connect Authentication Response parameters) using HTML form values that are auto-submitted by the User Agent using HTTP POST
Session Management?– (Optional) Defines how to manage OpenID Connect sessions, including postMessage-based logout functionality
Front-Channel Logout?– (Optional) Defines a front-channel logout mechanism that does not use an OP iframe on RP pages
Back-Channel Logout?– (Optional) Defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out
OpenID Connect的工作流程：下以EU獲取UserInfo為例來說明，
1. RP(客戶端)發送一個認證請求給OP； 2. OP對EU進行身份認證并獲得授權； 3. OP發送ID Token給RP，通常也同時發送Access Token(為兼容OAuth 2.0。ID Token其實可以取代Access Token用來完成授權)； 4. RP使用Access Token發送一個請求UserInfo EndPoint； 5. UserInfo EndPoint返回EU的Claims。下邊是關于“ID Token 與 Access Token”的描述來自?User Authentication with OAuth 2.0?[UserInfo Endpoint]：
It should be noted that clients are not required to use the access token, since the ID Token contains all the necessary information for processing the authentication event.?However, in order to provide compatibility with OAuth and match the general tendency for authorizing identity and other API access in parallel, OpenID Connect always issues the ID token along side an OAuth access token.ID Token：它是一種JWT(JSON Web Token)格式數據，主要由以下幾部分構成：
1. iss：必須。Issuer Identifier，OP的唯一標識，一個區分大小寫的https URL，不包含query和fragment組件 2. sub：必須。Subject Identifier，iss提供的EU的標識，在iss范圍內唯一，最長為255個ASCII個字符，區分大小寫 3. aud：必須。Audience(s)，標識ID Token的受眾，必須包含OAuth2的client_id，分大小寫的字符串數組 4. exp：必須。Expiration time，超過此時間的ID Token會作廢 5. iat：必須。Issued At Time，JWT的構建的時間 6. auth_time：AuthenticationTime，EU完成認證的時間。如果RP發送AuthN請求的時候攜帶max_age的參數，則此Claim是必須的 7. nonce：RP發送認證請求的時候提供的隨機字符串，用來減緩重放攻擊，也可以用來關聯客戶端Session。如果nonce存在，客戶端必須驗證nonce 8. acr：可選。Authentication Context Class Reference，表示一個認證上下文引用值，可以用來標識認證上下文類 9. amr：可選。Authentication Methods References，表示一組認證方法 10. azp：可選。Authorized party，結合aud使用。只有在被認證的一方和受眾（aud）不一致時才使用此值，一般情況下很少使用形如：
{"iss": "https://server.example.com","sub": "24400320","aud": "s6BhdRkqt3","nonce": "n-0S6_WzA2Mj","exp": 1311281970,"iat": 1311280970,"auth_time": 1311280969,"acr": "urn:mace:incommon:iap:silver" }?關于協議定義Claims的更多信息參考：http://openid.net/specs/openid-connect-core-1_0.html#Claims。ID Token必須使用JWS進行簽名，如果要用JWE加密也必須先進行JWS簽名
JSON Web Signature (JWS)：JSON數據進行數字簽名或MACed后再經base64url編碼。
JWS Compact Serialization如下連接序列：Header.Payload.Signature
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
1. JWS Protected Header{"typ":"JWT","alg":"HS256"}編碼后：eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 2. JWS Payload{"iss":"joe","exp":1300819380,"http://example.com/is_root":true}編碼后：eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 3. JWS SignatureSigning Input value：eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQHMAC SHA-256 key：{"kty":"oct","k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"}JWS Signature：dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk 4. JWS Compact SerializationeyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9. eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXkJWS JSON Serialization包含如下幾個部分：
1. "protected", with the value BASE64URL(UTF8(JWS Protected Header)) 2. "header", with the value JWS Unprotected Header 3. "payload", with the value BASE64URL(JWS Payload) 4. "signature", with the value BASE64URL(JWS Signature)General JWS JSON Serialization：
{"payload":"<payload contents>","signatures":[{"protected":"<integrity-protected header 1 contents>","header":<non-integrity-protected header 1 contents>,"signature":"<signature 1 contents>"},...{"protected":"<integrity-protected header N contents>","header":<non-integrity-protected header N contents>,"signature":"<signature N contents>"}] }Flattened JWS JSON Serialization：
{"payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ","protected":"eyJhbGciOiJFUzI1NiJ9","header": {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},"signature": "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q" }JSON Web Encryption (JWE)：
JWE Compact Serialization如下連接序列：
BASE64URL(UTF8(JWE Protected Header)) || '.' ||BASE64URL(JWE Encrypted Key) || '.' ||BASE64URL(JWE Initialization Vector) || '.' ||BASE64URL(JWE Ciphertext) || '.' ||BASE64URL(JWE Authentication Tag)JWE JSON Serialization包含如下幾個部分：
- 1. "protected", with the value BASE64URL(UTF8(JWE Protected Header))2. "unprotected", with the value JWE Shared Unprotected Header3. "header", with the value JWE Per-Recipient Unprotected Header4. "encrypted_key", with the value BASE64URL(JWE Encrypted Key)5. "iv", with the value BASE64URL(JWE Initialization Vector)6. "ciphertext", with the value BASE64URL(JWE Ciphertext)7. "tag", with the value BASE64URL(JWE Authentication Tag)8. "aad", with the value BASE64URL(JWE AAD)
General JWE JSON Serialization：
- {"protected":"<integrity-protected shared header contents>","unprotected":<non-integrity-protected shared header contents>,"recipients":[{"header":<per-recipient unprotected header 1 contents>,"encrypted_key":"<encrypted key 1 contents>"},...{"header":<per-recipient unprotected header N contents>,"encrypted_key":"<encrypted key N contents>"}],"aad":"<additional authenticated data contents>","iv":"<initialization vector contents>","ciphertext":"<ciphertext contents>","tag":"<authentication tag contents>"
}
Flattened JWE JSON Serialization：
- {"protected":"<integrity-protected header contents>","unprotected":<non-integrity-protected header contents>,"header":<more non-integrity-protected header contents>,"encrypted_key":"<encrypted key contents>","aad":"<additional authenticated data contents>","iv":"<initialization vector contents>","ciphertext":"<ciphertext contents>","tag":"<authentication tag contents>"
}
Base64編碼：Base64是基于64個可打印字母表(Table 1: The Base64 Alphabet)來表示數據的方法，可用于二進制數據如圖片、視頻、音頻數據的轉換表示，可查看RFC2045～RFC2049，上面有MIME(Multipurpose Internet Mail Extensions)的詳細規范：
1. 每3個字節一組，再按6bits(2 ^ 6 = 64)為一組分成4組，即3 * 8bits = 4 * 6bits； 2. 以6bits的值為索引查找字母表中對應的字符。最后3字節變成4字節，長度增加33%； 3. 對于不足3字節的情況用\x00字節補足，最后用尾部加“=”的個數來表示缺少的字節數，即Base64編碼的尾部最多有1~2個“=”。在RFC 2045中還規定，輸出每行不超過76字符(CRLF結尾)：
The encoded output stream must be represented in lines of no more than 76 characters each. All line breaks or other characters not found in Table 1 must be ignored by decoding software.?由于+和/字符在URL中傳遞是不安全的，因此又出現了以-和_來替換+和/的Base64URL編碼：
由于“=”字符也可能出現在Base64編碼中，但“=”用在URL、Cookie里面會造成歧義，所以很多Base64編碼把“=”去掉。至于去掉“=”后如何解碼呢？正常Base64編碼后的序列字符數一定是4的倍數，如果結果不是，則可反推去掉了多少個“=”?
相關參考：
1.?OIDC(OpenId Connect)身份認證授權(核心部分)
2.?RFC 7515 - JSON Web Signature (JWS)
3.?RFC 7516 - JSON Web Encryption (JWE)?
相關文章:?
Thinktecture IdentityServer：.NET開源OpenID和OAuth解決方案
教你實踐ASP.NET Core Authorization（免看文檔教程）
雙重OAuth 2.0架構
[認證授權] 1.OAuth2授權
[認證授權] 2.OAuth2授權（續） & JSON Web Token
基于OAuth2的認證（譯）
IdentityServer4(OAuth2.0服務)折騰筆記
[認證授權] 4.OIDC（OpenId Connect）身份認證授權（核心部分）
原文地址：http://www.cnblogs.com/XiongMaoMengNan/p/7381326.html
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
以上是生活随笔為你收集整理的OpenID Connect：OAuth 2.0协议之上的简单身份层的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ASP.NET Core 运行原理解剖[
- 下一篇： Docker打包 Asp.Net Cor