我已经阅读了很多关于不同流程（授权代码、隐式、混合和一些扩展，例如 PKCE）的信息。现在我正在使用 PKCE 进行授权代码流。
PKCE 确保发起者与将授权代码交换为访问令牌的用户是同一用户。这很好。
如果在没有 client_secret 的情况下使用此流程（建议用于 SPA/Javscript 应用程序），则无法保证客户端是已知/原始客户端。因此，用户给予的“同意”是没有价值的。嗯？
我正在开发一个 nativate 客户端（一个公共的可下载二进制文件）。在二进制文件中烘焙时不能将机密视为机密，例如可以对其进行反编译。
现在我处于怀疑状态。更好的是，在二进制文件中烘焙秘密，以便有一些额外的保证客户端是已知客户端，或者停止请求“同意”并将相同的 client_id 提供给全世界，只依赖于用户凭据。
还是我的故事有问题？
【问题讨论】：
非常好的问题，让我意识到我的理解存在差距。处理这种风险是重定向 uri 的作用。在 web / https 情况下，唯一可行的方法是编辑用户的主机文件。我是本地案例，它不太完美，您的问题将在下面介绍。一般来说，我们最好的选择是遵循建议/标准——但它们有很多问题！ https://web-in-security.blogspot.com/2017/01/pkce-what-cannot-be-protected.html?m=1
【讨论】：
对于阅读此案例的其他人，我已经阅读了更多内容。 冒充客户并不容易解决。
RFC8252 似乎是最适用于原生应用程序建议的文章 - https://www.rfc-editor.org/rfc/rfc8252 “声称的‘https’方案”被认为是最佳解决方案（IOS、Android 和 UWP 应用程序）。
由于我正在使用本机 Windows、非 UWP 应用程序，因此我无法使用它。据我所知，“基于应用 SID 的 Web 身份验证代理”对于我的情况是可能的。
另一种方法是接受客户为未知/未识别，并在客户每次访问个人数据时请求“同意”。
【讨论】：