如果 OpenID Connect 提供商不支持未加密的 ID 令牌和用户信息，它是否可以通过认证？
Can an OpenID Connect Provider be certified if it does not support unencrypted ID Tokens and Userinfo?
我正在开发一个提供程序，外部因素要求始终对 id 令牌和用户信息进行加密。服务器本身是而且必须是零知识的（听起来很奇怪）。
据我了解，core spec does not forbid this. Dynamic client registration is also supported but all id_token_encrypted*/userinfo_encrypted* client metadata parameters are overridden by the server if they were not provided. According to the spec 服务器允许这样做。
然而 discovery spec 似乎并不支持这个想法，因为没有办法告诉客户未加密的响应不会被 returned。
conformance testing tool 似乎也假定响应未加密。为了能够 运行 测试，我不得不为这个特定的客户破例。现在我只 return 签署了回复，但即使通过了，也不是真的。
这是否会阻止我获得验证，或者我可能会使用这个稍微修改过的服务器通过验证，同时要求真实客户端支持加密？
我认为您必须支持签名的 ID 令牌。这是 OpenID Connect 规范强制要求的。
15.1. Mandatory to Implement Features for All OpenID Providers
Signing ID Tokens with RSA SHA-256
OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm (an
alg value of RS256), unless the OP only supports returning ID Tokens
from the Token Endpoint (as is the case for the Authorization Code
Flow) and only allows Clients to register specifying none as the
requested ID Token signing algorithm.
这也在 ID Token 部分突出显示
ID Tokens MUST be signed using JWS [JWS] and optionally both signed and then encrypted using JWS [JWS] and JWE [JWE] respectively
进一步说 none 类型只有
ID Tokens MUST NOT use none as the alg value unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow) and the Client explicitly requested the use of none at Registration time.
加密的 JWT (JWE) 是可选的。因此，要让您的 OpenID Connect 提供商获得认证，您必须支持签名。
此外，通读 OpenID Connect Conformance Profiles v3.0 作为认证指南。
如果不支持未加密的 RSA SHA-256 签名 ID 令牌，则无法进行认证。但是，您可以验证软件实现，然后在部署时禁用特定算法。
编辑：唯一的例外是支持 "none" 但这与您的情况无关
The discovery spec however doesn't seem to support the idea since there is no way to tell the client that unencrypted responses will not be returned.
虽然发现无法传达此信息，但 Dynamic Registration 规范允许 IdP 这样做。
将带有预定义值的 userinfo_encrypted_response_alg 和 userinfo_signed_response_alg 返回给客户端注册请求是一种说明 IdP 策略的方式。
相关部分：
The Authorization Server MAY reject or replace any of the Client's requested field values and substitute them with suitable values.
我正在开发一个提供程序，外部因素要求始终对 id 令牌和用户信息进行加密。服务器本身是而且必须是零知识的（听起来很奇怪）。
据我了解，core spec does not forbid this. Dynamic client registration is also supported but all id_token_encrypted*/userinfo_encrypted* client metadata parameters are overridden by the server if they were not provided. According to the spec 服务器允许这样做。
然而 discovery spec 似乎并不支持这个想法，因为没有办法告诉客户未加密的响应不会被 returned。
conformance testing tool 似乎也假定响应未加密。为了能够 运行 测试，我不得不为这个特定的客户破例。现在我只 return 签署了回复，但即使通过了，也不是真的。
这是否会阻止我获得验证，或者我可能会使用这个稍微修改过的服务器通过验证，同时要求真实客户端支持加密？
我认为您必须支持签名的 ID 令牌。这是 OpenID Connect 规范强制要求的。
15.1. Mandatory to Implement Features for All OpenID Providers
Signing ID Tokens with RSA SHA-256
OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm (an alg value of RS256), unless the OP only supports returning ID Tokens from the Token Endpoint (as is the case for the Authorization Code Flow) and only allows Clients to register specifying none as the requested ID Token signing algorithm.
这也在 ID Token 部分突出显示
ID Tokens MUST be signed using JWS [JWS] and optionally both signed and then encrypted using JWS [JWS] and JWE [JWE] respectively
进一步说 none 类型只有
ID Tokens MUST NOT use none as the alg value unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow) and the Client explicitly requested the use of none at Registration time.
加密的 JWT (JWE) 是可选的。因此，要让您的 OpenID Connect 提供商获得认证，您必须支持签名。
此外，通读 OpenID Connect Conformance Profiles v3.0 作为认证指南。
如果不支持未加密的 RSA SHA-256 签名 ID 令牌，则无法进行认证。但是，您可以验证软件实现，然后在部署时禁用特定算法。
编辑：唯一的例外是支持 "none" 但这与您的情况无关
The discovery spec however doesn't seem to support the idea since there is no way to tell the client that unencrypted responses will not be returned.
虽然发现无法传达此信息，但 Dynamic Registration 规范允许 IdP 这样做。
将带有预定义值的 userinfo_encrypted_response_alg 和 userinfo_signed_response_alg 返回给客户端注册请求是一种说明 IdP 策略的方式。
相关部分：
The Authorization Server MAY reject or replace any of the Client's requested field values and substitute them with suitable values.