2

有一个行为不端的 OpenID Connect“兼容”iDP（它现在应该保持无名） - 在使用范围 openid 和任何包含 id_token 的 response_type 时会引发错误。这肯定是一个已报告的错误。

当范围包括 openid 并且 response_type 只是“token”时，相同的 iDP 也会在隐式流中返回 id_token。这弄乱了广泛使用的 oidc-client npm 包，它报告了一个错误“Not expecting id_token in response”——根据 OIDC 规范，它是严格正确的

但这带来了一个有趣的问题：

鉴于 OIDC 规范第 1 节的基本前提：

OpenID Connect 将身份验证作为 OAuth 2.0 授权过程的扩展来实现。客户端通过在授权请求中包含 openid 范围值来请求使用此扩展。

并且第 3.2.2.1 节说

注意：虽然 OAuth 2.0 还为隐式流定义了令牌响应类型值，但 OpenID Connect 不使用此响应类型，因为不会返回任何 ID 令牌。

因此，将两者一起使用是否应该是错误的？或者 openid 在范围内的事实是否应该导致实现默认将 id_token “添加”到隐式流的 response_type ？

4

1 回答 1

1

如我所见，OpenID Connect 提供者应该返回一个错误。它应该使用OAuth 2.0 规范为隐式错误响应invalid_request定义的错误代码。

请求缺少必需参数、包含无效参数值、包含多次参数或格式错误。

但从规范的角度来看，错误响应不是必需的/强制性的。它只是说带有令牌的响应类型无效。

注意：虽然 OAuth 2.0 还为隐式流定义了令牌响应类型值，但 OpenID Connect 不使用此响应类型，因为不会返回任何 ID 令牌。

我认为提到的 OpenID Connect 提供者只尊重范围值并将请求作为 OpenID Connect 请求提供服务。因此，您会得到一个 id 令牌作为响应。

于 2018-07-20T10:42:48.460 回答