首页 > 解决方案 > 我应该在本机、公共可下载的应用程序中使用 client_secret 吗?

问题描述

我已经阅读了很多关于不同流程的信息(授权代码、隐式、混合和一些扩展,例如 PKCE)。现在我正在使用 PKCE 进行授权代码流。

PKCE 确保发起者与交换访问令牌的授权代码的用户是同一用户。这很好。

当在没有 client_secret 的情况下使用此流程时(建议用于 SPA/Javscript 应用程序),不保证客户端是已知/原始客户端。因此,用户给予的“同意”是没有价值的。呃?

我正在开发一个原生客户端(一个公共可下载的二进制文件)。在二进制文件中烘焙时不能将机密视为机密,例如可以对其进行反编译。

现在我在怀疑。更好的是,在二进制文件中烘焙秘密,以便有一些额外的保证层,客户端是已知客户端,或者停止请求“同意”并将相同的 client_id 提供给全世界,只依赖用户凭据。

还是我的故事有问题?

标签: oauth-2.0identityserver4

解决方案


Very good question and made me realise a gap in my understanding. It is the role of the redirect uri to deal with this risk. In the web / https case the only hack that could work would be to edit the hosts file of the user. I'm the native case it is less perfect and your question is covered below. Generally our best bet is to follow recommendations / standards - but they have plenty of problems! https://web-in-security.blogspot.com/2017/01/pkce-what-cannot-be-protected.html?m=1


推荐阅读