OpenIddict是否违反OAuth及OpenID Connect协议规范？

我在OpenIddict的官方文档中未找到相关说明，于是查看了OpenIddict的官方示例代码：

// If the consent is implicit or if an authorization was found,
// return an authorization response without displaying the consent form.
case ConsentTypes.Implicit:
case ConsentTypes.External when authorizations.Any():
case ConsentTypes.Explicit when authorizations.Any() && !request.HasPrompt(Prompts.Consent):

// Create the claims-based identity that will be used by OpenIddict to generate tokens.
...

从这段代码能得出两个结论：

• 授权服务器允许将客户端配置为无需资源所有者同意（ConsentTypes.Implicit）
• 授权服务器允许第三方代资源所有者做出同意决定（ConsentTypes.External）

接着我查阅了相关协议规范：

OpenID Connect核心规范中关于同意的内容：
一旦终端用户完成认证，授权服务器必须在向依赖方释放信息前获取授权决定。当请求参数允许时，这可以通过与终端用户的交互式对话完成，明确告知用户需要同意的内容

OAuth 2.0 RFC规范中关于授权码流程的内容：
(B) 授权服务器通过用户代理认证资源所有者，并确认资源所有者是否同意或拒绝客户端的访问请求

OpenID Connect核心规范中授权码流程步骤说明：
4. 授权服务器获取终端用户的同意/授权

问题解答 #

1. 是否违反协议规范？
   OpenIddict的实现并没有违反规范——规范里的“必须获取授权决定”并没有强制要求必须通过交互式用户确认来完成。规范明确提到“当请求参数允许时，这可以通过交互式对话完成”，反过来也意味着允许非交互式的授权决定方式，比如预配置的隐式同意、第三方代授权（只要这种方式符合授权服务器的安全策略）。

2. 隐式同意的安全问题与责任边界
   隐式同意确实存在安全风险，但这并不是OpenIddict实现的问题，而是客户端注册环节的管控责任。授权服务器的管理员应该根据客户端的信任级别来决定是否允许使用Implicit或External同意类型：

• 对于高度信任的内部客户端（比如同一组织的内部应用），使用隐式同意可以提升用户体验，无需每次都确认授权；
• 对于第三方外部客户端，则应该强制使用Explicit同意类型，确保用户明确知晓并授权访问。

3. 为什么允许第三方代授权？
   ConsentTypes.External场景的设计是为了支持一些特定的业务需求：比如企业内部的身份管理系统已经完成了用户的授权审批，授权服务器可以信任该系统的决定，无需再向用户重复确认。这种模式需要严格的信任背书，只有当授权服务器明确信任第三方授权源时才应该启用，并非随意允许第三方代用户做决定。

内容的提问来源于stack exchange，提问作者Andriy