非标准OIDC流程:这有多安全？

Question

我被告知，在客户端，有一个应用程序声称使用OIDC对用户进行身份验证。然而，这是通过一个非标准流来完成的，从安全的角度来看，这是很难评估的。

它从一个前端SPA开始，启动带有openid作用域的OAuth2隐式授予。需要注意的是，这不是OIDC隐式授予，因为只返回一个access_token。然后，在与后端API的通信中使用令牌，后者使用令牌从userinfo端点请求属性。当用户从userinfo返回时，该用户被视为身份验证。

我的第一个评估是，只要对userinfo端点上的TLS证书进行验证，这应该是可以的。但是，我不愿意向客户说明这一点，因为流程似乎缺少OIDC的一些关键部分，而且我从未见过任何人在任何地方推广这个流。

Answer 1

我在描述的流中看不到漏洞。然而，许多更聪明、更有能力的人在标准方面工作，比如OIDC。这可能是他们设计它的原因。因此，我认为使用非标准流是危险的，即使这个问题对我们来说并不是显而易见的。

Answer 2

此流可能易受access_token注入影响。

据我从您对流的描述中可以看出，没有理由使用带有一些自定义添加的隐式授予，而不是授权代码授予，后者比隐式流更安全。隐式授予将在OAuth 2.1中删除用于好的理由。

对于带有后端的SPA，BFF (前端后端)模式可能很有趣，其中后端执行所有OAuth内容，并且不向前端泄漏令牌--这比在前端处理刷新令牌更安全。