Oauth 2.0 隐式授权工作流相对于仅为身份验证授予授权代码的缺点？

我想不出使用授权码授权与隐式流仅用于身份验证目的的优势对于经典web应用程序来说是什么

比如说，有一个web应用程序通过第三方Iaas提供商进行身份验证。web应用只需要知道用户（由某个ID标识）是否经过身份验证。web应用程序不会访问任何第三方服务，因此不需要任何访问令牌进行授权

---

在本例中，我看不出从IaaS直接将用户id（JWT令牌）获取到web浏览器比通过web后端获取相同的用户id更不安全？在这两种情况下，都将设立一个会议。如果在这种情况下使用隐式授权，我会失去什么？

取决于web应用程序的运行位置。如果它完全在浏览器上运行（例如，它是一个javascript应用程序或SPA），那么我会使用

隐式
流，因为
授权代码
授权是针对机密客户端优化的

如果您的web应用程序在服务器上运行，那么使用
授权码
授权会更安全，因为令牌将直接从IaaS提供商（身份验证服务器）发送到web应用程序服务器（客户端），而不是通过用户（资源所有者）浏览器
 隐式流是一种传统流，在浏览器只能调用同一源服务器的时期。使用隐式流时的一个问题是，它在重定向中返回访问令牌。重定向可以是包含访问令牌的浏览器历史记录的一部分。此外，如果多个设备历史记录与浏览器同步，则会增加安全风险

而在授权代码流中（使用PKCE）没有访问令牌作为Url的一部分，这使其更加安全

有关更多详细信息，请参阅
授权代码
授权不需要安全客户端。智能手机上的本机应用程序可以（现在也可以）使用这种授权类型，而这些应用程序可能根本不安全。正确的问题是：
客户端是否完全**在web浏览器中运行
。如果答案是“是”，则使用隐式授权类型，否则使用
授权代码
（PKCE用于本机应用）。有关更好的解释，请参阅或（优秀书籍）有一个运行在浏览器中的客户端，它向运行在我的服务器上的web服务器发出请求。每个文件都建议使用授权代码。在这种情况下，我仍然不明白它是如何比隐性拨款更安全的。例如，在授权授予的情况下，一旦客户机经过身份验证，服务器将与客户机建立会话，它仍然可能包含相同的用户id。因此，似乎只是向授权服务器添加了一个双往返？@MikhailY它更安全，因为id/Access令牌不需要转到最终用户的浏览器。@MikhailY服务器不设置与客户端的任何会话。授权代码用于获取访问令牌（用于执行API调用）。未发布
用户id
。身份验证是通过OpenID连接扩展完成的。用户的ID在
ID\u令牌中，而不是在访问令牌中。@FlorentMorselli正确，这就是问题所在。为了获取id_令牌，为什么隐式流比授权代码授权流更糟糕？