| 目錄 |
|
OpenID Connect 1.0 是 OAuth 2.0 協議之上的簡單身份層。它使客戶端能夠根據授權服務器執行的身份驗證來驗證最終用戶的身份，并以可互操作和REST 風格的方式獲取有關最終用戶的基本資料信息。
該規范定義了一種機制，供 OpenID Connect 依賴方發現最終用戶的 OpenID 提供方并獲取與其交互所需的信息，包括其 OAuth 2.0 端點位置。
1.
簡介
1.1. 要求符號和約定
1.2.
術語
2.
OpenID 提供方頒發者發現
2.1.
標識符規范化
2.1.1. 用戶輸入標識符類型
2.1.2.
標準化步驟
2.2. 非規范性示例
2.2.1.
使用電子郵件地址語法的用戶輸入
2.2.2.
使用 URL 語法的用戶輸入
2.2.3.
使用主機名和端口語法的用戶輸入
2.2.4.
使用“acct”URI 語法的用戶輸入
3.
OpenID 提供方元數據
4.
獲取 OpenID 提供方配置信息
4.1.
OpenID 提供方配置請求
4.2.
OpenID 提供方配置響應
4.3.
OpenID 提供方配置驗證
5.
字符串操作
6.
實現注意事項
6.1.
兼容性說明
7.
安全注意事項
7.1. TLS 要求
7.2.
冒充攻擊
8.
IANA 注意事項
8.1.
眾所周知的 URI 注冊表
8.1.1. 注冊表內容
8.2.
OAuth 授權服務器元數據注冊表
8.2.1.
注冊內容
9.
參考文獻
9.1.
9.2
規范性參考文獻
參考文獻
附錄 A.
致謝
附錄 B.
通知
§
作者地址
| 目錄 |
OpenID Connect 1.0 是 OAuth 2.0 [RFC6749]（Hardt, D., Ed.，“OAuth 2.0 授權框架”，2012 年 10 月。） 協議之上的簡單身份層 。它使客戶端能夠根據授權服務器執行的身份驗證來驗證最終用戶的身份，并以可互操作和REST 風格的方式獲取有關最終用戶的基本資料信息。
為了讓 OpenID Connect 依賴方為最終用戶使用 OpenID Connect 服務，RP 需要知道 OpenID 提供方在哪里。 OpenID Connect 使用 WebFinger（Jones, P.、Salgueiro, G.、Jones, M. 和 J. Smarr，“WebFinger”，2013 年 9 月。） [RFC7033] 為最終用戶查找 OpenID 提供方。第 2 節（OpenID 提供方頒發者發現） 描述了該過程 。
一旦識別出 OpenID 提供方，就會從眾所周知的位置以 JSON [RFC8259]（Bray, T., Ed.，“JavaScript 對象表示法 (JSON) 數據交換格式”，2017 年 12 月。）文檔的形式檢索該 OP 的配置信息，包括其 OAuth 2.0 端點位置。第 4 節（獲取OpenID提供方配置信息） 描述了該過程 。
該規范的先前版本是：
| 目錄 |
關鍵詞“必須”、“不得”、“必需”、“應”、“不應”、“應該”、“不應該”、“推薦”、“不推薦”、“可以”和“可選”本文檔中的“應按照RFC 2119（Bradner, S.，“RFC 中用于指示需求級別的關鍵詞”，1997 年 3 月。） [RFC2119] 中的描述進行解釋。
在本規范的 .txt 版本中，引用值表明它們應按字面意思理解。在協議消息中使用這些值時，不得將引號用作值的一部分。在本規范的 HTML 版本中，按字面意思取值是通過使用 這種固定寬度字體 來指示的。
本規范中JSON Web 簽名 (JWS)（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 簽名 (JWS)”，2015 年 5 月。） [JWS] 和JSON Web 加密 (JWE)（Jones, M. 和 J. Hildebrand，“JSON Web 加密 (JWE)”，2015 年 5 月。） [JWE] 數據結構 的所有使用 均利用 JWS 緊湊序列化或 JWE 緊湊序列化；不使用 JWS JSON 序列化和 JWE JSON 序列化。
| 目錄 |
本規范使用定義的術語“授權碼”、“授權端點”、“授權服務器”、“客戶端”、“客戶端身份驗證”、“客戶端密鑰”、“授權許可類型”、“響應類型”和“令牌端點” OAuth 2.0（Hardt, D., Ed.，“OAuth 2.0 授權框架”，2012 年 10 月。） [RFC6749]定義的術語“聲明名稱”、“聲明值”和“JSON Web 令牌 (JWT)”由JSON Web 令牌 (JWT) [JWT] 定義，以及（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 令牌 (JWT)”，2015 年 5 月。）OpenID Connect Core 1.0（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0”，2023 年 12 月。） 定義的術語 [ OpenID.Core] 和 OAuth 2.0 多重響應類型編碼實踐（de Medeiros, B., Ed.、Scurtescu, M.、Tarjan, P. 和 M. Jones，“OAuth 2.0 多重響應類型編碼實踐”，2014 年 2 月。） [OAuth.Responses]。
本規范還定義了以下術語：
- 資源
- WebFinger 中請求的目標實體。
- 主持人
- 托管 WebFinger 服務的服務器。
- 標識符
- 在特定上下文中唯一表征實體的值。
- 注意：本規范定義了各種標識符，設計用于不同的上下文。示例包括使用 https 方案的 URL 和電子郵件地址。
讀者重要提示：本節中的術語定義是本規范的規范部分，對實現提出了要求。本說明書文本中的所有大寫單詞，例如“標識符”，均引用這些定義的術語。每當讀者遇到它們時，都必須遵循本節中的定義。
| 目錄 |
OpenID 提供方頒發者發現是確定 OpenID 提供方位置的過程。
頒發者發現是可選的；如果依賴方通過帶外機制知道OP的頒發者位置，則它可以跳過此步驟并繼續到 第4節（獲取OpenID提供方配置信息） 。
使用WebFinger（Jones, P.、Salgueiro, G.、Jones, M. 和 J. Smarr，“WebFinger”，2013 年 9 月。） [RFC7033] 執行頒發者發現需要以下信息：
- 資源
- 作為發現請求主題的目標最終用戶的標識符。
- 主持人
- 托管 WebFinger 服務的服務器。
- 相對
- 標識所請求位置的服務類型的 URI。
OpenID Connect 在WebFinger [RFC7033] 中 使用以下可發現的 rel 值 ： （Jones, P.、Salgueiro, G.、Jones, M. 和 J. Smarr，“WebFinger”，2013 年 9 月。）
| 相對類型 | 統一資源標識符 |
|---|---|
| OpenID Connect 頒發者 | http://openid.net/specs/connect/1.0/issuer |
為了開始發現 OpenID 端點，最終用戶向依賴方提供標識符。任何 Web 輸入表單都必須采用跨站點請求偽造 (CSRF) 預防 [OWASP.CSRF]（OWASP，“跨站點請求偽造預防備忘單”。） 。
RP 將規范化規則應用于標識符以確定資源和主機。然后，它使用 資源 參數向主機的 WebFinger [RFC7033] 端點發出 HTTP GET 請求 ，以獲取所請求服務的位置。還建議在請求中 使用 值為 http://openid.net/specs/connect/1.0/issuer的rel 參數 ，以將響應范圍縮小到所需的特定鏈接關系類型。 （Jones, P.、Salgueiro, G.、Jones, M. 和 J. Smarr，“WebFinger”，2013 年 9 月。）
所有 WebFinger 通信必須以第 7.1 節（TLS 要求） 中描述的方式使用 TLS 。 WebFinger 端點應支持使用 跨源資源共享 (CORS)（Opera Software ASA，“跨域資源共享”，2010 年 7 月。） [CORS] 和/或其他適當的方法，以使 JavaScript 客戶端和其他基于瀏覽器的客戶端能夠訪問它。
頒發者位置必須在 WebFinger 響應中作為links數組元素的href 成員 的值返回，該元素 具有rel 成員值 http://openid.net/specs/connect/1.0/issuer。 （根據WebFinger [RFC7033] 第 7 節，獲取 WebFinger 響應可能首先涉及遵循一些重定向。） （Jones, P.、Salgueiro, G.、Jones, M. 和 J. Smarr，“WebFinger”，2013 年 9 月。）
返回的頒發者位置必須是 URI RFC 3986（Berners-Lee, T.、Fielding, R. 和 L. Masinter，“統一資源標識符 (URI)：通用語法”，2005 年 1 月。） [RFC3986]，其方案組件必須是https、主機組件以及可選的端口和路徑組件，并且沒有查詢或片段組件。請注意，由于根據用戶輸入標識符確定的主機和資源值（如第 2.1 節（標識符標準化） 中所述）用作 WebFinger 請求的輸入，該請求可以使用完全不同的方案、主機、端口和路徑返回頒發者值，因此可以假定用戶輸入標識符字符串和結果頒發者位置之間的關系。
| 目錄 |
標識符規范化的目的是根據用戶輸入標識符確定規范化的資源和主機值。然后將它們用作 WebFinger 請求參數來發現頒發者位置。
用戶輸入標識符應該是 RFC 3986（Berners-Lee, T.、Fielding, R. 和 L. Masinter，“統一資源標識符 (URI)：通用語法”，2005 年 1 月。） [RFC3986] 中定義的 URL 或 URI 相對引用。用戶輸入標識符必須包含權限組件。
注意：URI 相對引用包含一個看起來像userinfo@host 形式的電子郵件地址的字符串 。這是 URI 的有效權限組件，但不包括 RFC 5322 [RFC5322] 的 addr-spec 語法 中允許的各種可能的額外字符串。 （Resnick, P., Ed.，“互聯網消息格式”，2008 年 10 月。）
標識符規范化規則可以通過附加規范進行擴展，以允許使用其他標識符類型，例如電話號碼或 XRI（Reed, D. 和 D. McAlpin，“可擴展資源標識符 (XRI) 語法 V2.0”，2005 年 11 月。） [XRI_Syntax_2.0]。
| 目錄 |
用戶輸入標識符可以分為以下類型，需要不同的規范化過程：
注意：用戶輸入標識符可以采用userinfo@host 的形式 。對于最終用戶來說，這通常被視為電子郵件地址。然而，它也是 acct URI [RFC7565]（Saint-Andre, P.，“‘acct’URI 方案”，2015 年 5 月。） 的有效用戶部分“@”主機部分，并且本規范將其視為排除RFC 5322 [RFC5322] 的 addr-spec中允許的各種額外字符串。（Resnick, P., Ed.，“互聯網消息格式”，2008 年 10 月。）
| 目錄 |
任何其他類型的字符串都被解釋為以下形式之一的 URI ：方案“://”authority path-abempty [“?”查詢] [“#”片段] 或 權限路徑-abempty [“？”查詢] [“#”片段] 或 方案“：”無根路徑， 符合 RFC 3986（Berners-Lee, T.、Fielding, R. 和 L. Masinter，“統一資源標識符 (URI)：通用語法”，2005 年 1 月。） [RFC3986]，并根據以下規則進行規范化：
本例中的 WebFinger（Jones, P.、Salgueiro, G.、Jones, M. 和 J. Smarr，“WebFinger”，2013 年 9 月。） [ RFC7033] 資源是生成的 URI，WebFinger 主機是權限組件。
注意：由于RFC 3986 [RFC3986] 中 權限 的定義是 [ userinfo "@" ] host [ ":" port ] ，因此擁有像 userinfo@host:port 這樣的 用戶輸入標識符是合法的，例如 alice@example。 com：8080 。 （Berners-Lee, T.、Fielding, R. 和 L. Masinter，“統一資源標識符 (URI)：通用語法”，2005 年 1 月。）
| 目錄 |
| 目錄 |
要以電子郵件地址joe@example.com 的形式查找給定用戶輸入的頒發者，WebFinger 參數如下：
| WebFinger參數 | 值 |
|---|---|
| resource | acct:joe@example.com |
| host | example.com |
| rel | http://openid.net/specs/connect/1.0/issuer |
請注意，在這種情況下， acct: 方案 [RFC7565]（Saint-Andre, P.，“‘acct’URI 方案”，2015 年 5 月。） 被添加到標識符之前。
RP 將發出以下 WebFinger 請求來發現頒發者位置（行內換行僅用于顯示目的）：
GET /.well-known/webfinger
?resource=acct%3Ajoe%40example.com
&rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: application/jrd+json
{
"subject": "acct:joe@example.com",
"links":
[
{
"rel": "http://openid.net/specs/connect/1.0/issuer",
"href": "https://server.example.com"
}
]
}
| 目錄 |
要查找給定 URL https://example.com/joe 的頒發者，WebFinger 參數如下：
| WebFinger參數 | 值 |
|---|---|
| resource | https://example.com/joe |
| host | example.com |
| rel | http://openid.net/specs/connect/1.0/issuer |
RP 將發出以下 WebFinger 請求來發現頒發者位置（行內換行僅用于顯示目的）：
GET /.well-known/webfinger
?resource=https%3A%2F%2Fexample.com%2Fjoe
&rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: application/jrd+json
{
"subject": "https://example.com/joe",
"links":
[
{
"rel": "http://openid.net/specs/connect/1.0/issuer",
"href": "https://server.example.com"
}
]
}
| 目錄 |
如果用戶輸入的格式為 host:port ，例如 example.com:8080，則假定它是 URL 的權限部分。
要查找給定主機名example.com:8080 的頒發者 ，WebFinger 參數如下：
| WebFinger參數 | 值 |
|---|---|
| resource | https://example.com:8080/ |
| host | example.com:8080 |
| rel | http://openid.net/specs/connect/1.0/issuer |
RP 將發出以下 WebFinger 請求來發現頒發者位置（行內換行僅用于顯示目的）：
GET /.well-known/webfinger
?resource=https%3A%2F%2Fexample.com%3A8080%2F
&rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
HTTP/1.1
Host: example.com:8080
HTTP/1.1 200 OK
Content-Type: application/jrd+json
{
"subject": "https://example.com:8080/",
"links":
[
{
"rel": "http://openid.net/specs/connect/1.0/issuer",
"href": "https://server.example.com"
}
]
}
| 目錄 |
要以帳戶 URI acct:juliet%40capulet.example@shopping.example.com 的形式查找給定用戶輸入的頒發者 ，WebFinger 參數如下：
|
|---|
RP 將發出以下 WebFinger 請求來發現頒發者位置（行內換行僅用于顯示目的）：
GET /.well-known/webfinger
?resource=acct%3Ajuliet%2540capulet.example%40shopping.example.com
&rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
HTTP/1.1
Host: shopping.example.com
HTTP/1.1 200 OK
Content-Type: application/jrd+json
{
"subject": "acct:juliet%40capulet.example@shopping.example.com",
"links":
[
{
"rel": "http://openid.net/specs/connect/1.0/issuer",
"href": "https://server.example.com"
}
]
}
注意：站點通常使用電子郵件地址作為這些站點帳戶的本地標識符，即使電子郵件地址中的域不受站點控制。例如，站點 example.org可能有一個名為joe@example.com 的本地帳戶 。本規范使用[RFC7565]定義的 acct: URI來表示 WebFinger 發現期間的此類帳戶。這樣的示例是 acct:joe%40example.com@example.org。最終用戶可以輸入joe@example.com@example.org 等值 來啟動此類帳戶的發現。 （Saint-Andre, P.，“‘acct’URI 方案”，2015 年 5 月。）
| 目錄 |
OpenID 提供方具有描述其配置的元數據。 OpenID Connect 使用這些 OpenID 提供方元數據值：
- 頒發者
- 必需。使用 https方案的URL ，不帶 OP 斷言為其頒發者標識符的查詢或片段組件。如果支持頒發者發現（請參閱第 2 節（OpenID 提供方頒發者發現） ），則該值必須與 WebFinger 返回的頒發者值相同。這也必須與 該頒發者頒發的 ID 令牌中的 iss Claim 值相同。
- 授權端點
- 必需。 OP 的 OAuth 2.0 授權端點的 URL [OpenID.Core]（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0”，2023 年 12 月。）。該 URL 必須使用https 方案，并且可以包含端口、路徑和查詢參數組件。
- 令牌端點
- OP 的 OAuth 2.0 令牌端點的 URL [OpenID.Core]（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0”，2023 年 12 月。）。這是必需的，除非僅使用隱式流。該 URL 必須使用https 方案，并且可以包含端口、路徑和查詢參數組件。
- 用戶信息端點
- 推薦。 OP 的 UserInfo 端點的 URL [OpenID.Core]（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0”，2023 年 12 月。）。該 URL 必須使用https 方案，并且可以包含端口、路徑和查詢參數組件。
- jwks_uri
- 必需。 OP 的 JWK Set [JWK]（Jones, M.，“JSON Web 密鑰 (JWK)”，2015 年 5 月。）文檔的 URL，必須使用https方案。這包含 RP 用于驗證來自 OP 的簽名的簽名密鑰。 JWK 集還可以包含服務器的加密密鑰，RP 使用該密鑰來加密對服務器的請求。當簽名和加密密鑰都可用時，引用的 JWK 集中的所有密鑰都需要使用（公鑰使用）參數值，以指示每個密鑰的預期用途。盡管某些算法允許將相同的密鑰用于簽名和加密，但不建議這樣做，因為它的安全性較低。 JWK x5c 參數可用于提供所提供密鑰的 X.509 表示形式。使用時，裸密鑰值必須仍然存在并且必須與證書中的值匹配。 JWK 集不得包含私有或對稱密鑰值。
- 注冊端點
- 推薦。 OP 的動態客戶端注冊端點 [OpenID.Registration]（Sakimura, N.、Bradley, J. 和 M. Jones，“OpenID Connect 動態客戶端注冊 1.0”，2023 年 12 月。）的 URL ，必須使用https 方案。
- 支持范圍
- 推薦。 JSON 數組，包含 此服務器支持的 OAuth 2.0（Hardt, D., Ed.，“OAuth 2.0 授權框架”，2012 年 10 月。） [RFC6749] 范圍值列表。服務器必須支持openid 范圍值。即使使用此參數，服務器也可以選擇不公布某些支持的范圍值，盡管 [OpenID.Core]（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0”，2023 年 12 月。） 中定義的范圍值應該列出（如果支持）。
- 支持的響應類型
- 必需。 JSON 數組，包含 此 OP 支持的OAuth 2.0 response_type 值列表 。 動態 OpenID 提供方必須支持 code 、 id_token和id_token 令牌 響應類型值。
- 響應模式_支持
- 可選。 JSON 數組，包含 此 OP 支持的 OAuth 2.0 response_mode 值列表 ，如 OAuth 2.0 多重響應類型編碼實踐（de Medeiros, B., Ed.、Scurtescu, M.、Tarjan, P. 和 M. Jones，“OAuth 2.0 多重響應類型編碼實踐”，2014 年 2 月。） [OAuth.Responses] 中指定。如果省略，動態 OpenID 提供方的默認值為 ["query", "fragment"] 。
- grant_types_supported
- 可選。 JSON 數組，包含此 OP 支持的 OAuth 2.0 授權許可類型值列表。動態 OpenID 提供方必須支持 authorization_code 和 隱式 授權許可類型值，并且可以支持其他授權許可類型。如果省略，默認值為 ["authorization_code", "implicit"] 。
- acr_值_支持
- 可選。 JSON 數組，包含此 OP 支持的身份驗證上下文類引用列表。
- 支持的主題類型
- 必需。 JSON 數組包含此 OP 支持的主題標識符類型列表。有效類型包括 pairwise 和 public 。
- id_token_signing_alg_values_supported
- 必需。 JSON 數組，包含 OP 支持的 JWS 簽名算法（ alg值）列表，用于 ID 令牌對 JWT [JWT]（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 令牌 (JWT)”，2015 年 5 月。）中的聲明進行編碼。必須包含RS256算法。值none 可以受支持，但不得使用，除非使用的響應類型未從授權端點返回 ID 令牌（例如使用授權碼流程時）。
- id_token_encryption_alg_values_supported
- 可選。 JSON 數組，包含 OP 支持的 JWE 加密算法（ alg值）列表，用于 ID 令牌對 JWT [JWT]（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 令牌 (JWT)”，2015 年 5 月。） 中的聲明進行編碼。
- id_token_encryption_enc_values_supported
- 可選。 JSON 數組，包含 OP 支持的 JWE 加密算法（ enc值）列表，用于 ID 令牌對 JWT [JWT]（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 令牌 (JWT)”，2015 年 5 月。） 中的聲明進行編碼。
- userinfo_signing_alg_values_supported
- 可選。 JSON 數組，包含 UserInfo 端點支持的 JWS [JWS]（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 簽名 (JWS)”，2015 年 5 月。）簽名算法（alg值）[JWA]（Jones, M.，“JSON Web 算法 (JWA)”，2015 年 5 月。）列表，用于對 JWT [JWT]（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 令牌 (JWT)”，2015 年 5 月。） 中的聲明進行編碼 。 可以包含 值 none 。
- 用戶信息_加密_alg_values_supported
- 可選。 JSON 數組，包含 UserInfo 端點支持的 JWE [JWE]（Jones, M. 和 J. Hildebrand，“JSON Web 加密 (JWE)”，2015 年 5 月。）加密算法（alg值）[JWA]（Jones, M.，“JSON Web 算法 (JWA)”，2015 年 5 月。）列表，用于對 JWT [JWT]（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 令牌 (JWT)”，2015 年 5 月。） 中的聲明進行編碼 。
- 用戶信息_加密_enc_values_supported
- 可選。 JSON 數組，包含 UserInfo 端點支持的 JWE 加密算法（ enc值）[JWA]（Jones, M.，“JSON Web 算法 (JWA)”，2015 年 5 月。）列表，用于對 JWT [JWT]（Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 令牌 (JWT)”，2015 年 5 月。） 中的聲明進行編碼 。
- request_object_signing_alg_values_supported
- 可選。 JSON 數組，包含 請求對象 OP 支持的JWS 簽名算法（ alg值）列表，這些算法在OpenID Connect Core 1.0（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0”，2023 年 12 月。） [OpenID.Core] 的第 6.1 節中進行了描述。當請求對象按值傳遞（使用request參數）和按引用傳遞（使用request_uri參數）時，都會使用這些算法。服務器應該不支持 RS256 。
- request_object_encryption_alg_values_supported
- 可選。 JSON 數組，包含 請求對象的 OP 支持的JWE 加密算法（ alg 值）列表。 當請求對象按值傳遞和按引用傳遞時，都會使用這些算法。
- request_object_encryption_enc_values_supported
- 可選。 JSON 數組，包含 請求對象的 OP 支持的JWE 加密算法（ enc 值）列表。 當請求對象按值傳遞和按引用傳遞時，都會使用這些算法。
- token_endpoint_auth_methods_supported
- 可選。 JSON 數組，包含此令牌端點支持的客戶端身份驗證方法列表。選項包括 client_secret_post 、 client_secret_basic 、 client_secret_jwt 和 private_key_jwt ，如OpenID Connect Core 1.0（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0”，2023 年 12 月。） [OpenID.Core]第 9 節中所述。其他身份驗證方法可以由擴展定義。如果省略，則默認為client_secret_basic —— OAuth 2.0（Hardt, D., Ed.，“OAuth 2.0 授權框架”，2012 年 10 月。） [RFC6749] 的第 2.3.1 節中指定的 HTTP Basic 身份驗證方案。
- token_endpoint_auth_signing_alg_values_supported
- 可選。 JSON 數組，包含 令牌端點支持的 JWT [JWT]簽名的 JWS 簽名算法（ alg 值）列表，用于在令牌端點對private_key_jwt 和 client_secret_jwt身份驗證方法的客戶端進行身份驗證。服務器應該支持RS256。 不得使用 值none 。 （Jones, M.、Bradley, J. 和 N. Sakimura，“JSON Web 令牌 (JWT)”，2015 年 5 月。）
- 顯示值支持
- 可選。 JSON 數組，包含 OpenID 提供方支持的 顯示參數值列表。這些值在OpenID Connect Core 1.0（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0”，2023 年 12 月。） [OpenID.Core] 的第 3.1.2.1 節中進行了描述。
- 支持的聲明類型
- 可選。 JSON 數組，包含 OpenID 提供方支持的聲明類型列表。這些聲明類型在 OpenID Connect Core 1.0（Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“OpenID Connect Core 1.0”，2023 年 12 月。） [OpenID.Core]的第 5.6 節中進行了描述。本規范定義的值包括正態值 、 聚合值和分布值。如果省略，則實現僅支持普通 聲明。
- 支持的索賠
- 推薦。 JSON 數組，包含 OpenID 提供方可以為其提供值的聲明的聲明名稱列表。請注意，出于隱私或其他原因，這可能不是詳盡的列表。
- 服務文檔
- 可選。包含開發人員在使用 OpenID 提供方時可能想要或需要知道的人類可讀信息的頁面 URL。特別是，如果 OpenID 提供方不支持動態客戶端注冊，則需要在本文檔中提供有關如何注冊客戶端的信息。
- 聲明_區域設置_支持
- 可選。返回的聲明中的值支持的語言和腳本，表示為 BCP47（菲利普斯，A.，埃德。和 M. Davis 編輯，“識別語言的標簽”，2009 年 9 月。） [RFC5646] 語言標簽值 的 JSON 數組 。 并非所有語言和腳本都必須支持所有聲明值。
- ui_locales_supported
- 可選。用戶界面支持的語言和腳本，表示為 BCP47（菲利普斯，A.，埃德。和 M. Davis 編輯，“識別語言的標簽”，2009 年 9 月。） [RFC5646] 語言標記值 的 JSON 數組 。
- 聲明_參數_支持
- 可選。布爾值，指定OP是否支持使用 claims參數，true表示支持。如果省略，則默認值為false 。
- 請求參數支持
- 可選。布爾值，指定OP是否支持使用 請求參數，true表示支持。如果省略，則默認值為false 。
- request_uri_parameter_supported
- 可選。布爾值，指定 OP 是否支持使用 request_uri參數，true表示支持。如果省略，則默認值為true 。
- 需要_請求_uri_注冊
- 可選。布爾值，指定 OP 是否需要 使用 request_uris注冊參數預先注冊任何 request_uri 值。當值為true時，需要預注冊。如果省略，則默認值為false 。
- op_policy_uri
- 可選。 OpenID 提供方向注冊客戶端的人員提供的 URL，以了解 OP 關于依賴方如何使用 OP 提供的數據的要求。注冊過程應該向注冊客戶端的人顯示此 URL（如果給出）。
- op_tos_uri
- 可選。 OpenID 提供方向注冊客戶端的人員提供的 URL，用于閱讀 OpenID 提供方的服務條款。注冊過程應該向注冊客戶端的人顯示此 URL（如果給出）。
令牌端點、UserInfo 端點、 jwks_uri 端點、動態客戶端注冊端點以及客戶端直接訪問的任何其他端點應支持使用 跨源資源共享 (CORS)（Opera Software ASA，“跨域資源共享”，2010 年 7 月。） [CORS] 和/或其他適當的方法來啟用 JavaScript 客戶端和其他基于瀏覽器的客戶端來訪問它們。不建議在授權端點使用 CORS，因為它是由客戶端重定向到的，而不是直接訪問的。
還可以使用其他 OpenID 提供方元數據參數。有些是由其他規范定義的，例如 OpenID Connect Session Management 1.0（de Medeiros, B.、Agarwal, N.、Sakimura, N.、Bradley, J. 和 M. Jones，“OpenID Connect 會話管理 1.0”，2022 年 9 月。） [OpenID.Session]。
| 目錄 |
使用第 2 節（OpenID 提供方頒發者發現） 中所述的發現的頒發者位置 或通過其他方式，可以檢索 OpenID 提供方的配置信息。
支持發現的 OpenID 提供方必須在通過將字符串/.well-known/openid-configuration 連接到頒發者 而形成的路徑上提供可用的 JSON 文檔 。 .well-known的語法和語義在RFC 5785（Nottingham, M. 和 E. Hammer-Lahav，“定義眾所周知的統一資源標識符 (URI)”，2010 年 4 月。） [RFC5785]中定義，并且在頒發者值不包含路徑組件時適用于該值。openid-configuration 必須指向符合此規范的 JSON 文檔，并且必須使用 application/json內容類型返回。openid-configuration 端點 應該支持使用 跨源資源共享（CORS）（Opera Software ASA，“跨域資源共享”，2010 年 7 月。） [CORS]和/或其他適當的方法來使JavaScript客戶端和其他基于瀏覽器的客戶端能夠訪問它。
| 目錄 |
OpenID 提供方的配置信息必須使用 HTTP GET 請求在先前指定的路徑中 檢索 。
RP 將向頒發者 https://example.com 發出以下請求 以獲取其配置信息，因為頒發者不包含路徑組件：
GET /.well-known/openid-configuration HTTP/1.1 Host:example.com
如果 Issuer 值包含路徑組件，則 必須在附加 /.well-known/openid-configuration之前刪除任何終止 / 。 RP 將向 Issuer https://example.com/issuer1 發出以下請求 以獲取其配置信息，因為 Issuer 包含路徑組件：
GET /issuer1/.well-known/openid-configuration HTTP/1.1 Host:example.com
使用路徑組件可以支持每個主機多個頒發者。這在某些多租戶托管配置中是必需。 .wellknown的使用是為了支持每個主機多個頒發者；與RFC 5785（Nottingham, M. 和 E. Hammer-Lahav，“定義眾所周知的統一資源標識符 (URI)”，2010 年 4 月。） [RFC5785]中的使用不同 ，它不提供有關主機的一般信息。
| 目錄 |
響應是一組有關 OpenID 提供方配置的聲明，包括所有必要的端點和公鑰位置信息。成功的響應必須使用 200 OK HTTP 狀態代碼，并使用application/json內容類型返回一個 JSON 對象，該對象包含一組聲明作為其成員，這些聲明是第 3 節（OpenID 提供方元數據） 中定義的元數據值的子集 。其他索賠也可能被退回。
返回多個值的聲明表示為 JSON 數組。具有零個元素的聲明必須從響應中省略。
錯誤響應使用適用的 HTTP 狀態代碼值。
以下是非規范響應示例：
HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer":
"https://server.example.com",
"authorization_endpoint":
"https://server.example.com/connect/authorize",
"token_endpoint":
"https://server.example.com/connect/token",
"token_endpoint_auth_methods_supported":
["client_secret_basic", "private_key_jwt"],
"token_endpoint_auth_signing_alg_values_supported":
["RS256", "ES256"],
"userinfo_endpoint":
"https://server.example.com/connect/userinfo",
"check_session_iframe":
"https://server.example.com/connect/check_session",
"end_session_endpoint":
"https://server.example.com/connect/end_session",
"jwks_uri":
"https://server.example.com/jwks.json",
"registration_endpoint":
"https://server.example.com/connect/register",
"scopes_supported":
["openid", "profile", "email", "address",
"phone", "offline_access"],
"response_types_supported":
["code", "code id_token", "id_token", "id_token token"],
"acr_values_supported":
["urn:mace:incommon:iap:silver",
"urn:mace:incommon:iap:bronze"],
"subject_types_supported":
["public", "pairwise"],
"userinfo_signing_alg_values_supported":
["RS256", "ES256", "HS256"],
"userinfo_encryption_alg_values_supported":
["RSA-OAEP-256", "A128KW"],
"userinfo_encryption_enc_values_supported":
["A128CBC-HS256", "A128GCM"],
"id_token_signing_alg_values_supported":
["RS256", "ES256", "HS256"],
"id_token_encryption_alg_values_supported":
["RSA-OAEP-256", "A128KW"],
"id_token_encryption_enc_values_supported":
["A128CBC-HS256", "A128GCM"],
"request_object_signing_alg_values_supported":
["none", "RS256", "ES256"],
"display_values_supported":
["page", "popup"],
"claim_types_supported":
["normal", "distributed"],
"claims_supported":
["sub", "iss", "auth_time", "acr",
"name", "given_name", "family_name", "nickname",
"profile", "picture", "website",
"email", "email_verified", "locale", "zoneinfo",
"http://example.info/claims/groups"],
"claims_parameter_supported":
true,
"service_documentation":
"http://server.example.com/connect/service_documentation.html",
"ui_locales_supported":
["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
}
| 目錄 |
如果本規范中定義的任何驗證過程失敗，則必須中止任何需要未能正確驗證的信息的操作，并且不得使用未能正確驗證的信息。
返回的頒發者 值必須與用作 /.well-known/openid-configuration 前綴以 檢索配置信息的頒發者 URL 相同。這也必須與 該頒發者頒發的 ID 令牌中的 iss Claim 值相同。
| 目錄 |
處理某些 OpenID Connect 消息需要將消息中的值與已知值進行比較。例如，提供方配置響應中的成員名稱可能會與特定成員名稱（例如 Issuer ）進行比較。然而，比較 Unicode [UNICODE]（Unicode 聯盟，“Unicode 標準”。） 字符串具有重大的安全隱患。
因此，JSON 字符串和其他 Unicode 字符串之間的比較必須按如下指定進行：
| 目錄 |
該規范定義了依賴方和選擇實施發現的 OpenID 提供方所使用的功能。所有這些依賴方和 OpenID 提供方必須實現本規范中列出的“必需”或“必須”描述的功能。本規范沒有定義 Discovery 實現的其他實現注意事項。
| 目錄 |
注意：本規范原始版本中先前描述的潛在兼容性問題現已得到解決。
| 目錄 |
| 目錄 |
實現必須支持 TLS。應該實施哪個版本會隨著時間的推移而變化，并且取決于實施時的廣泛部署和已知的安全漏洞。實施應遵循 BCP 195 [RFC8996] （Moriarty, K. 和 S. Farrell，“棄用 TLS 1.0 和 TLS 1.1”，2021 年 3 月。） [RFC9325]（Sheffer, Y.、Saint-Andre, P. 和 T. Fossati，“安全使用傳輸層安全 (TLS) 和數據報傳輸層安全 (DTLS) 的建議”，2022 年 11 月。） 中的指南 ，該指南提供了提高使用 TLS 的已部署服務的安全性的建議和要求。
為了防止信息泄露和篡改，必須使用 TLS 以及提供機密性和完整性保護的密碼套件來應用機密性保護。
每當使用 TLS 時，都必須根據 RFC 6125（Saint-Andre, P. 和 J. Hodges，“在傳輸層安全 (TLS) 環境中使用 X.509 (PKIX) 證書表示和驗證互聯網公鑰基礎設施中基于域的應用程序服務身份”，2011 年 3 月。） [RFC6125] 執行 TLS 服務器證書檢查。
| 目錄 |
在發出 OpenID 提供方配置請求時， TLS 證書檢查必須由 RP 執行，如 第 7.1 節（TLS 要求） 中所述。檢查服務器證書對于頒發者 URL 是否有效，可以防止中間人攻擊和基于 DNS 的攻擊。這些攻擊可能會導致 RP 被誘騙使用攻擊者的密鑰和端點，從而冒充合法的頒發者。如果攻擊者可以做到這一點，他們就可以訪問受影響 RP 上任何現有用戶的帳戶，這些用戶可以使用他們模擬的 OP 登錄。
攻擊者還可能嘗試通過發布包含使用被模擬 OP 的頒發者 URL 的 頒發者聲明的發現文檔來模擬 OpenID 提供方，但具有自己的端點和簽名密鑰。如果 RP 接受，這將使其能夠作為 OP 發行 ID 令牌。為了防止這種情況，RP 必須確保他們用于配置請求的頒發者 URL與 RP 收到的 OP 元數據文檔中的頒發者聲明值完全匹配，并且這也與ID 令牌中的iss 聲明值完全匹配應該是來自該頒發者。
| 目錄 |
| 目錄 |
本規范將第 4 節（獲取OpenID提供方配置信息） 中定義的眾所周知的 URI 注冊到 由 RFC 5785 [RFC5785] 建立的 IANA“眾所周知的 URI”注冊表 [IANA.well‑known]中。（IANA，“眾所周知的 URI”。）（Nottingham, M. 和 E. Hammer-Lahav，“定義眾所周知的統一資源標識符 (URI)”，2010 年 4 月。）
| 目錄 |
| 目錄 |
本規范在[RFC8414] 建立的 IANA“OAuth 授權服務器元數據”注冊表 [IANA.OAuth.Parameters]（IANA，“OAuth 參數”。） 中注冊以下元數據名稱。 （Jones, M.、Sakimura, N. 和 J. Bradley，“OAuth 2.0 授權服務器元數據”，2018 年 6 月。）
| 目錄 |
| 目錄 |
| 目錄 |
| [CORS] | Opera Software ASA，“跨源資源共享”，2010 年 7 月。 |
| [IANA.眾所周知] | IANA，“眾所周知的 URI。” |
| [JWA] | Jones, M.，“ JSON Web 算法 (JWA) ”，RFC 7518，DOI 10.17487/RFC7518，2015 年 5 月。 |
| [JWE] | Jones, M. 和 J. Hildebrand，“ JSON Web 加密 (JWE) ”，RFC 7516，DOI 10.17487/RFC7516，2015 年 5 月。 |
| [JWK] | Jones, M.，“ JSON Web 密鑰 (JWK) ”，RFC 7517，DOI 10.17487/RFC7517，2015 年 5 月。 |
| [JWS] | Jones, M.、Bradley, J. 和 N. Sakimura，“ JSON Web 簽名 (JWS) ”，RFC 7515，DOI 10.17487/RFC7515，2015 年 5 月。 |
| [智威湯遜] | Jones, M.、Bradley, J. 和 N. Sakimura，“ JSON Web 令牌 (JWT) ”，RFC 7519，DOI 10.17487/RFC7519，2015 年 5 月。 |
| [OAuth.響應] | de Medeiros, B., Ed.、Scurtescu, M.、Tarjan, P. 和 M. Jones，“ OAuth 2.0 多重響應類型編碼實踐”，2014 年 2 月。 |
| [OpenID.核心] | Sakimura, N.、Bradley, J.、Jones, M.、de Medeiros, B. 和 C. Mortimore，“ OpenID Connect Core 1.0 ”，2023 年 12 月。 |
| [OpenID.注冊] | Sakimura, N.、Bradley, J. 和 M. Jones，“ OpenID Connect 動態客戶端注冊 1.0 ”，2023 年 12 月。 |
| [RFC2119] | Bradner, S.，“ RFC 中用于指示需求級別的關鍵字”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997 年 3 月。 |
| [RFC3986] | Berners-Lee, T.、Fielding, R. 和 L. Masinter，“統一資源標識符 (URI)：通用語法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005 年 1 月。 |
| [RFC5322] | Resnick, P., Ed.，“互聯網消息格式”，RFC 5322，DOI 10.17487/RFC5322，2008 年 10 月。 |
| [RFC5646] | 菲利普斯，A.，埃德。和 M. Davis，Ed.，“用于識別語言的標簽”，BCP 47，RFC 5646，DOI 10.17487/RFC5646，2009 年 9 月。 |
| [RFC5785] | Nottingham, M. 和 E. Hammer-Lahav，“定義眾所周知的統一資源標識符 (URI) ”，RFC 5785，DOI 10.17487/RFC5785，2010 年 4 月。 |
| [RFC6125] | Saint-Andre, P. 和 J. Hodges，“在傳輸層安全 (TLS) 環境中使用 X.509 (PKIX) 證書表示和驗證互聯網公鑰基礎設施中基于域的應用程序服務身份”，RFC 6125， DOI 10.17487/RFC6125，2011 年 3 月。 |
| [RFC6749] | Hardt, D., Ed.，“ OAuth 2.0 授權框架”，RFC 6749，DOI 10.17487/RFC6749，2012 年 10 月。 |
| [RFC7033] | Jones, P.、Salgueiro, G.、Jones, M. 和 J. Smarr，“ WebFinger ”，RFC 7033，DOI 10.17487/RFC7033，2013 年 9 月。 |
| [RFC7565] | Saint-Andre, P.，“ ‘acct’URI 方案”，RFC 7565，DOI 10.17487/RFC7565，2015 年 5 月。 |
| [RFC8259] | Bray, T., Ed.，“ JavaScript 對象表示法 (JSON) 數據交換格式”，STD 90、RFC 8259、DOI 10.17487/RFC8259，2017 年 12 月。 |
| [RFC8996] | Moriarty, K. 和 S. Farrell，“棄用 TLS 1.0 和 TLS 1.1 ”，BCP 195、RFC 8996、DOI 10.17487/RFC8996，2021 年 3 月。 |
| [RFC9325] | Sheffer, Y.、Saint-Andre, P. 和 T. Fossati，“安全使用傳輸層安全 (TLS) 和數據報傳輸層安全 (DTLS) 的建議”，BCP 195、RFC 9325、DOI 10.17487/RFC9325， 2022 年 11 月。 |
| [統一碼] | Unicode 聯盟，“ Unicode 標準”。 |
| [美國15] | Whistler, K.，“ Unicode 規范化形式”，Unicode 標準附件 15，2023 年 8 月。 |
| 目錄 |
| [IANA.OAuth.參數] | IANA，“ OAuth 參數”。 |
| [OWASP.CSRF] | OWASP，“跨站點請求偽造預防備忘單”。 |
| [OpenID.Discovery.Errata1] | Sakimura, N.、Bradley, J.、Jones, M. 和 E. Jay，“ OpenID Connect Discovery 1.0 包含勘誤集 1 ”，2014 年 11 月。 |
| [OpenID.Discovery.Final] | Sakimura, N.、Bradley, J.、Jones, M. 和 E. Jay，“ OpenID Connect Discovery 1.0（最終版） ”，2014 年 2 月。 |
| [OpenID.會話] | de Medeiros, B.、Agarwal, N.、Sakimura, N.、Bradley, J. 和 M. Jones，“ OpenID Connect 會話管理 1.0 ”，2022 年 9 月。 |
| [RFC8414] | Jones, M.、Sakimura, N. 和 J. Bradley，“ OAuth 2.0 授權服務器元數據”，RFC 8414，DOI 10.17487/RFC8414，2018 年 6 月。 |
| [XRI_Syntax_2.0] | Reed, D. 和 D. McAlpin，“可擴展資源標識符 (XRI) 語法 V2.0 ”，2005 年 11 月。 |
| 目錄 |
OpenID 社區感謝以下人員對此規范做出的貢獻：
安德魯·阿諾特 (andarno@microsoft.com)，微軟
德克·巴爾凡茲 (balfanz@google.com)，谷歌
卡斯帕·比林 (cb@peercraft.com)，Peercraft
John Bradley (ve7jtb@ve7jtb.com)、Yubico（曾在 Ping Identity）
Johnny Bufu (johnny.bufu@gmail.com)，獨立人士（曾在 Janrain）
Brian Campbell (bcampbell@pingidentity.com)，Ping Identity
布萊恩·庫克 (romeda@gmail.com)，獨立人士
布雷諾·德·梅代羅斯 (breno@google.com)，Google
Pamela Dingle (Pamela.Dingle@microsoft.com)，微軟（曾在 Ping Identity）
Vladimir Dzhuvinov (vladimir@connect2id.com)，Connect2id（曾在 Nimbus Directory Services）
George Fletcher (gffletch@aol.com)，第一資本（曾在 AOL）
迪克·哈特 (dick.hardt@gmail.com)，獨立人士
Roland Hedberg (roland@catalogix.se)，獨立人士（曾于于默奧大學）
埃德蒙·杰伊 (ejay@mgi1.com)，伊魯米拉
Michael B. Jones (michael_b_jones@hotmail.com)，自助咨詢（曾在 Microsoft）
Torsten Lodderstedt (torsten@lodderstedt.net)，獨立人士（曾供職于德國電信）
Nov Matake (nov@matake.jp)，獨立
Chuck Mortimore (charliemortimore@gmail.com)，迪士尼（曾在 Salesforce）
Anthony Nadalin (nadalin@prodigy.net)，獨立人士（曾供職于 Microsoft）
Axel Nennker (axel.nennker@telekom.de)，德國電信
約翰·潘澤 (jpanzer@google.com)，Google
Justin Richer (justin@bspk.io)，定制工程（曾在 MITRE）
Nat Sakimura (nat@nat.consulting)，NAT.Consulting（曾在 NRI）
歐文·謝潑德 (owen.shepherd@e43.eu)，獨立
Andreas Åkre Solberg (Andreas.Solberg@sikt.no)，Sikt（曾在 UNINET）
Kick Willemse (k.willemse@evidos.nl)，Evidos BV
| 目錄 |
版權所有 (c) 2023 OpenID 基金會。
OpenID 基金會 (OIDF) 向任何貢獻者、開發者、實施者或其他相關方授予非排他性、免版稅、全球版權許可，以復制、分發、執行和展示本實施者草案或最終規范、準備衍生作品、分發、執行和展示僅用于 (i) 制定規范，以及 (ii) 根據此類文件實施實施者草案和最終規范，前提是注明材料來源為 OIDF，但此類來源并不表示認可由 OIDF 制定。
本規范中描述的技術來自各種來源的貢獻，包括 OpenID 基金會的成員和其他人。盡管 OpenID 基金會已采取措施幫助確保該技術可供分發，但它對可能聲稱與實施或使用該技術相關的任何知識產權或其他權利的有效性或范圍不持任何立場。本規范或此類權利下的任何許可可能或可能不可用的范圍；它也不代表它已做出任何獨立努力來確定任何此類權利。 OpenID 基金會和本規范的貢獻者不做出（并特此明確否認任何）與本規范相關的保證（明示、暗示或其他方式），包括適銷性、不侵權、特定用途的適用性或所有權的暗示保證。規范，并且實施該規范的全部風險由實施者承擔。 OpenID 知識產權政策要求貢獻者提供專利承諾，不會針對其他貢獻者和實施者提出某些專利主張。 OpenID 基金會邀請任何感興趣的各方提請其注意可能涵蓋實踐本規范所需的技術的任何版權、專利、專利申請或其他專有權利。
| 目錄 |
| 納特·薩基穆拉 | |
| NAT咨詢 | |
| 電子郵件： | nat@nat.consulting |
| 約翰·布拉德利 | |
| 尤比科 | |
| 電子郵件： | ve7jtb@ve7jtb.com |
| 邁克爾·瓊斯 | |
| 自發行咨詢 | |
| 電子郵件： | michael_b_jones@hotmail.com |
| 埃德蒙·杰伊 | |
| 伊爾米拉 | |
| 電子郵件： | ejay@mgi1.com |