IdentityServer4是基於OpenID Connect and OAuth 2.0框架，OpenID Connect Core 1.0是IdentityServer4最重要的文檔

By 道法自然 2018年

摘要

OpenID Connect Core 1.0是一個在OAuth 2.0 [RFC6749]協議之上簡單的身份層。它使客戶驗證基於由授權服務器驗證終端用戶的身份,以及獲得互操作的基本概要信息和終端用戶REST-like方式。

這個規範定義了 OpenID Connect核心功能：驗證基於OAuth 2.0和使用聲明式的終端用戶的信息交流程。它還描述了使用OpenID Connect的安全和隱私問題。

1 介紹（Introduction）

作為背景，OAuth 2.0授權框架 (OAuth 2.0 Authorization Framework [RFC6749]) 和 OAuth 2.0無記名令牌用法 (OAuth 2.0 Bearer Token Usage [RFC6750]) 規範為第三方應用程序獲得和使用有限的HTTP訪問資源提供了一個總體框架。他們定義了獲取和使用令牌訪問資源的訪問機制，沒有定義標準方法提供身份信息。值得註意的是，如果對OAuth 2.0不加以了解,就不能實現提供終端用戶的驗證信息功能。讀者應該熟悉這些規範。

OpenID Connect擴展實現了OAuth 2.0驗證授權過程。使用這個擴展客戶端授權請求，要求包括請求的openid scope值。在一個 JSON Web Token (JWT)中返回執行驗證的一個稱之為ID Token信息(見第二節 )。OAuth 2.0實現OpenID驗證服務器連接,也被稱為OpenID提供者(OPs)。OAuth 2.0客戶端使用OpenID Connect 也被稱為依賴方(RPs)。

這個規範假定依賴方已經獲得 OpenID提供者的配置信息,包括它的授權終結點和令牌終結點位置。這些信息通常是通過發現獲得（OpenID Connect Discovery 1.0 OpenID Discovery)中描述，或通過其他機制可以獲得。

同樣，這個規範假定依賴方已經獲得需要使用OpenID提供者提供的足夠多的憑證和信息。這通常是通過OpenID Connect Dynamic Client Registration 1.0中描述動態註冊，或通過其他機制可以獲得。

1.1 符號和約定要求（Requirements Notation and Conventions）

關鍵詞“必須”、“不能”、“需要”、“應當”,“不得”，“應該”、“不應該”,“推薦”,“不推薦”、“可能”和“可選的” 文檔中描述將被解釋為 RFC 2119 [RFC2119]。

在.txt版本的文檔中，應該從字面上理解這些詞的意思。當在協議消息中使用這些詞，引述不能作為值的一部分。在本文檔的HTML版本，值按字面所示 的固定寬度字體使用。

本規範中JSON Web Signature (JWS)和JSON Web Encryption (JWE)的數據結構使用JWS壓縮序列化或JWE壓縮序列化; 不使用JWS JSON序列化和 JWE JSON序列化。

1.2 術語（Terminology）

該規範使用術語“訪問令牌（Access Token）”,“授權碼（Authorization Code）”，“授權終結點（Authorization Endpoint）”、“授權許可（Authorization Grant）”、“授權服務器（Authorization Server）”，“客戶端（Client）”、“客戶端驗證（Client Authentication）”、“客戶標識符（Client Identifier）”,“客戶端密鑰（Client Secret）”，“許可類型（Grant Type）”、“受保護資源（Protected Resource）”,“重定向URI（Redirection URI）”、“刷新令牌（Refresh Token）”，“資源所有者（Resource Owner）”、“資源服務器（Resource Server）”、“響應類型（Response Type）”,“令牌終結點（Token Endpoint）” 定義為 OAuth 2.0 (RFC6749)，術語“聲明名稱（Claim Name）”、“聲明值（Claim Value）”,“JSON Web Token(JWT)”，“JWT聲明集”,“嵌套JWT” 定義為 JSON Web Token(JWT) JWT，術語“Header Parameter”和“JOSE Header” 定義為 JSON Web Signature (JWS)，“用戶代理”一詞的定義 RFC 2616 [RFC2616]，和定義的術語“響應模式（Response Mode）” OAuth 2.0多個響應類型編碼實踐 [OAuth.Responses]。

此規範還定義了以下術語：

Authentication（驗證）

提供在實體和提供身份兩者間建立足夠的信任操作。

Authentication Request（驗證請求）

OAuth 2.0授權請求通過擴展參數和範圍定義，為OpenID Connect從授權服務器到終端用戶認證請求，是OpenID Connect提供者，對於客戶端,是OpenID Connect依賴。

Authentication Context（驗證上下文）

在依賴方需要的信息之前，對驗證響應權利做出決定。這種上下文可以包括但不限於,實際的驗證方法或保障級別等 ISO/IEC 29115 (ISO29115) 實體驗證保障級別。

Authentication Context Class(驗證上下文類)

驗證方法或程序集，相當於在一個特定的上下文。

Authentication Context Class Reference（驗證上下文類引用）

驗證上下文類標識符。

Authorization Code Flow（授權碼流程）

OAuth 2.0流程包含從授權終結點返回的授權碼和從令牌終結點返回的所有令牌。

Authorization Request（授權請求）

OAuth 2.0定義的授權請求 (RFC6749) 。

Claim（聲明）

信息斷言一個實體。

Claim Type（聲明類型）

用於代表聲明值的語法。這個規範定義了正常、合並和分離的聲明類型。

Claims Provider（聲明提供者）

可返回的關於實體的服務器聲明。

Credential（憑證）

作為可使用身份或其他資源權利證據的數據呈現。

End-User（終端用戶）

參與的人。

Entity（實體）

確定在一個上下文中單獨、獨特的存在的東西。終端用戶就是一個實體例子。

Essential Claim（基本聲明）

指定客戶端必要的聲明，以確保終端用戶流程暢授權的特定任務體驗。

Hybrid Flow（混合流程）

OAuth 2.0流程包含有從授權終結點返回授權碼，授權終結點返回的授權令牌,和從其他令牌終結點返回的令牌。

ID Token（令牌標識）

JSON Web Token(JWT)包含關於驗證事件。它可能包含其他聲明。

Identifier（標識符）

描述一個實體在一個特定上下文的唯一值。

Identity（身份）

一組相關實體屬性。

Implicit Flow（隱式流程）

OAuth 2.0 流程從授權終結點返回的所有令牌，但不調用令牌終結點和授權碼。

Issuer（發行人）

實體中關於發行人的聲明。

Issuer Identifier（發布者標識符）

可驗證發行人的標識符。發布者標識符是一個區分大小寫的https 格式的URL，包含scheme、主機和可選端口號和路徑組件，但沒有任何查詢或片段組件。

Message（消息）

OpenID依賴和OpenID提供者之間的請求或響應，。

OpenID Provider (OP，OpenID提供者）

OAuth 2.0驗證服務器為終端用戶和提供聲明給認證事件與終端用戶的依賴方賦予驗證的能力。

Request Object（請求對象）

JWT包含一組請求參數聲明。

Request URI（請求URI）

包含請求對象的資源引用的URL。請求URI包含必需由授權服務器檢索的內容。

Pairwise Pseudonymous Identifier（成對匿名標識符(PPID))

不能關聯的依賴方實體身份和實體的另一個PPID依賴方的標識。

Personally Identifiable Information（個人身份信息(PII)）

可以用來識別自然人的信息（a），這些信息涉及誰,或 (b)是可能直接或間接有關涉及這些信息自然人。

Relying Party (RP)(依賴方)

需要用戶驗證和OpenID提供者的聲明之OAuth 2.0客戶機應用程序。

Sector Identifier（企業標識符）

主機組件依賴方所使用的URL的組織，這是一個輸入的計算成對Subject標識符的依賴方。

Self-Issued OpenID Provider（自發行OpenID提供者）

解決自簽名ID令牌的個人的，自托管OpenID提供者。

Subject Identifier（子標識符）

當地獨特的,在客戶端使用的，從不在終端用戶的發行人重新分配標識符。

UserInfo Endpoint（用戶信息終結點）

受保護的資源。當面對客戶提供訪問令牌時，返回關於終端用戶授權、許可等信息。用戶信息終結點URL必須使用 https 方案和可能包含的端口號、路徑和查詢參數組件。

Validation（驗證）

目的是為了檢查完整性或構造的正確性操作。

Verification（驗證）

目的是為了測試或證明真理、事實、值的準確性操作。

Voluntary Claim（自願聲明）

要求指定的客戶端是可用的但不是終端用戶要求的特定任務必不可少的。

重要提示:本節術語定義是本規範的實現實施需求的規範部分。在本規範的文本中所有的大寫的單詞,如 “Issuer Identifier”。只要讀者遇到引用這些定義術語時，必須遵循在本節中所見的對這些術語定義。

更多的背景使用的一些術語，參看網絡安全術語表第2版 (RFC4949)，ISO/IEC 29115實體驗證保證 (ISO29115)和 ITU-T X.1252 [X.1252]。

1.3 概述（Overview）

OpenID Connect協議,抽象層面,遵循以下步驟。

1、RP(客戶端)發送一個請求到OpenID提供者(OP)。

2、OP驗證終端用戶和獲得授權。

3、OP 應答ID令牌和通用的訪問令牌。

4、 RP可以使用訪問令牌給用戶令牌終結點發送請求。

5、用戶信息終結點返回終端用戶聲明。

原文：https://openid.net/specs/openid-connect-core-1_0.html

OpenID Connect Core 1.0（一）介紹