OAuth 2.0 指定了存取資源的存取令牌，但它沒有提供提供身份信息（ID Token）的標準方法，這就是 OpenID Connect（ODIC）出現的原因。
. （身份、認證）+ OAuth 2.0 = OpenID Connect
. OIDC 是第三代OpenID 技術，它與 OAuth 2.0 對齊並從 XML 切換到 JSON。
. OIDC 通過ID 令牌處理身份和身份驗證，而 OAuth 2.0 通過存取/承載令牌處理授權。
. 由於 OIDC 建立在 OAuth 2.0 之上，因此OpenID 提供程序與OAuth 2.0 授權服務器基本相同。
身份令牌(ID Token)
-理解 ID Token 由 Takahiko Kawasaki
不記名令牌（Bearer Token）
擁有不記名令牌（“持有者”）的任何一方都可以使用它來存取相關資源（無需證明擁有加密密鑰）。為了防止濫用，需要保護不記名代幣在存儲和運輸過程中不被洩露。
來源：RFC 6750
Microsoft.AspNetCore.Authentication.JwtBearer是一個軟體組件，用於處理 .NET 5.0 中的承載令牌。
OpenID Connect (OIDC) 和 OAuth 2.0
OpenID Connect 是一種基於 OAuth 2.0 系列規範的可互操作的身份驗證協議。它使用簡單的 REST/JSON 消息流，其設計目標是“讓簡單的事情變得簡單，讓複雜的事情成為可能”。與之前的任何身份協議相比，開發人員集成起來非常容易。
OpenID Connect 使開發人員無需擁有和管理密碼文件即可跨網站和應用程序驗證其用戶。對於應用程序構建器，它為以下問題提供了一個安全的可驗證答案：“當前使用與我連接的瀏覽器或本機應用程序的人的身份是什麼？”
OpenID Connect 允許所有類型的客戶端（包括基於瀏覽器的 JavaScript 和本機移動應用程序）啟動登錄流程並接收有關登錄用戶身份的可驗證斷言。
（身份、認證）+ OAuth 2.0 = OpenID Connect
來源：OpenID Connect 常見問題和問答
OpenID 的早期版本（Earlier Versions of OpenID）
OpenID Connect 是第三代 OpenID 技術。第一個是最初的 OpenID，這是一個有遠見的工具，從未獲得太多商業採用，但讓行業領導者思考什麼是可能的。OpenID 2.0考慮得更周全，提供了出色的安全性，並且在正確實施時運行良好。然而，它受到一些設計限制——其中最重要的是依賴方可以是網頁而不是本機應用程序；它還依賴於XML，導致一些採用問題。
OpenID Connect 的目標是對開發人員更加友好，同時擴展可以使用的用例集。它已經在這方面取得了成功；有大規模運行的生產部署。任何有足夠經驗通過 HTTP 發送和接收 JSON 消息的程序員（現在大多數是這樣）應該能夠使用標準的加密簽名驗證庫從頭開始實現 OpenID Connect。幸運的是，大多數甚至不必走那麼遠，因為有很好的商業和開源庫來處理身份驗證機制。
來源：OpenID Connect 常見問題和問答
OAuth 2.0 抽象協議流程（OAuth 2.0 Abstract Protocol Flow）
OAuth 2.0 Abstract Protocol Flow
OIDC 協議流程（OIDC Protocol Flow）
OpenID Connect協議，在抽象的，遵循下列步驟。
- RP（客戶端）向 OpenID 提供者（OP）發送請求。
- OP 對最終用戶進行身份驗證並獲得授權。
- OP 使用 ID 令牌和通常的存取令牌進行響應。
- RP 可以向 UserInfo Endpoint 發送帶有存取令牌的請求。
- UserInfo 端點返回有關最終用戶的聲明。
這些步驟如下圖所示：
OIDC Protocol Flow
參考
. RFC 6749：OAuth 2.0 授權框架
. RFC 6750：OAuth 2.0 授權框架：不記名令牌的使用
. OAuth 2.0
. 歡迎使用 OpenID Connect
. OpenID Connect 常見問題和問答
. OAuth 2.0 / OpenID Connect 說明
. 了解 ID 令牌
. 將標識提供程序存取令牌傳遞到 Azure Active Directory B2C 中的應用程序
. AccessToken Vs ID Token Vs Refresh Token – 什麼？為什麼？什麼時候？
資料來源： Wentz Wu QOTD-20210622
