Identityserver4 为什么混合流是identityserver中Web应用程序的默认推荐选项？

我已经使用identity server 4构建了自己的identity server。我经常在示例甚至管理UI中看到的一件事是，对于web应用程序（通常是MVC），Hybrid是默认的授予类型（flow）。我只是不明白这有什么好处

响应类型：代码令牌

即使响应类型为“code”，id_令牌仍会在无论如何交换的代码/令牌上返回

id_令牌在客户端通常不有用，因为客户端必须首先处理JWT，并且大部分信息可以发送到视图

即使对于SPA，如果我将响应类型设置为仅代码，我仍然会获得一个id_令牌（通过oidc客户端）

---

在初始响应上发送的id_令牌对视图足够重要的地方，我缺少了什么用例？我正在使用授权\代码授权类型，但我很好奇什么时候应该使用hybrid。

据我所知，目前首选的流程是使用PKCE的代码。在.Net Core 2中，hybrid是默认的，可能是因为.Net Core 2不包含对PKCE的内置支持，但新的.Net Core 3包含，用IS4文档的话说：

“PKCE已经是本机应用程序和SPA的官方推荐，并且随着ASP.NET Core 3的发布，OpenID连接处理程序默认也支持PKCE。”

之所以使用混合，是因为它解决了问题，但它带来了以下缺点：

1。”id_令牌通过字体通道传输，可能会泄漏其他（个人可识别）数据“

2.“所有授权步骤（如加密）都需要由客户实施。这将导致更复杂的客户端库实现。”

随着PKCE的引入，PKCE也解决了替换问题，PKCE成为了更简单的解决方案。这是Scott Brady的观点：

“使用混合流响应类型的代码id_令牌曾经是最佳实践，因为这在将代码交换为令牌（通过nonce和c_散列参数）之前给了我们一些要验证的东西。但是，由于我们现在使用的是PKCE，因此注入代码来模拟另一个用户不再是一种风险。因此，我们可以安全地从浏览器中删除所有PII（身份令牌）。”

希望这能回答你的问题，因为我对此事的理解相当平庸。使用的链接：

---

编辑：似乎有一个类似的问题需要回答。

情况不再如此。他们几天前更新了。或者检查链接是否更改。建议SPA使用PKCE是正确的。我的问题更多地是关于MVC web应用程序，这在很大程度上是服务器端的，这就是为什么代码更合适的原因。因此还有一个问题，Web应用程序在初始响应的客户端上有id_令牌（代码+id_令牌）有什么好处？PKCE现在也推荐用于MVC，请参见此处。不幸的是，我无法深入了解令牌和流的原因和方式，也许@RuardvanElburg可以帮助您。@MichaelChan id_令牌是作用域的一部分，由作用域：openid配置文件请求（默认情况下，IdentityServer添加作用域）。根据设计，IdentityServer返回一个最小的id_令牌，仅包含子声明。此id_令牌用于验证。登录时以及注销时（如果提供）。不需要使用或扩展令牌。其思想是客户端可以在UserInfo端点处请求其他信息。