对于 secret 客户端，会为客户端分配一些范围，并且登录用户必须同意这些范围。由于访问 token 的身份验证代码交换涉及客户端 secret ，因此没有人可以模拟它们并利用它们的范围。
但是当谈到 native 应用程序上的 pkce 流程时，如果我有其他人的 clientId(clientId 不被视为私有(private)信息)，它有很多范围，我可以使用他们的 clientId 启动流程。 是什么阻止黑客在 PKCE 流程中使用某些知名的 clientId 并访问其所有范围？
最佳答案
原生回调方法
如果你看RFC8252 ，某些类型的回调 URL 可以由多个应用程序注册，这意味着只需窃取客户端 ID 即可冒充真正的应用程序，如您所说。
这仍然需要恶意应用程序诱骗用户登录，然后才能检索 token 。当然，每个应用程序应该只使用它需要的范围，并且更喜欢只读范围。之后，这取决于 native 应用程序的类型。
移动
移动应用程序可以使用Claimed HTTPS Schemes通过 https 回调 URL 来克服这个问题。它由 Android 上的应用程序链接或 iOS 上的通用链接提供支持。即使恶意应用程序使用客户端 ID，它也无法接收带有授权码的登录响应，因为它将通过这样的 URL 接收，并且移动操作系统只会将其传递给已证明域所有权的应用程序通过深度链接重新登录过程:
桌面
对于桌面应用程序来说存在差距，因为只能使用环回和私有(private) URI 方案回调 URL。它依赖于用户避免安装恶意应用程序。例如，仅安装来自需要代码签名的商店的应用程序，这也会告知用户发布者是谁。如果用户安装恶意应用程序，那么他们可能会遇到更深层次的问题。
证明
一种较新的技术是在身份验证开始之前使用某种形式的客户端身份验证。对于 secret 客户端，使用推送授权请求，它使用应用程序的客户端凭据，因此默认情况下 native 客户端无法使用它。
移动应用程序可能会在身份验证过程中提供其 Google/Apple 签名 key 的所有权证明，并且有一个围绕此的拟议标准。
关于oauth-2.0 - Oauth pkce 流程冒充别人的客户端，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/73942098/