【发布时间】:2020-03-02 00:42:58
【问题描述】:
我正在尝试了解客户机密的用途。是为了防止有人创建冒充我的服务器的假服务器吗?如果不是,那是什么?它还能防止其他任何东西吗?
【问题讨论】:
标签: client-server identityserver4 identityserver3
我正在尝试了解客户机密的用途。是为了防止有人创建冒充我的服务器的假服务器吗?如果不是,那是什么?它还能防止其他任何东西吗?
【问题讨论】:
标签: client-server identityserver4 identityserver3
客户端密钥用于标识需要访问令牌才能代表用户访问资源的应用程序。只有在身份验证服务中注册的客户端才能请求访问。不仅用户身份验证是必要的,客户端应用程序也必须是合法的。否则有人可能会冒充客户端应用程序。
这种类型的客户端授权只能由机密客户端使用([OAuth2 客户端类型][2])。
机密
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
公开
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
authentication via any other means.
当与无法保证此机密(即隐式)机密性的客户端一起使用流时,无法验证客户端的身份。在这些情况下,它可以通过重定向 URI 进行验证。作为一项附加措施,它应该限制刷新令牌的暴露。
出于安全原因,官方不再推荐使用隐式流,对这类客户端的推荐是授权码+PKCE扩展。 [参见 OBBA 文档][1]
对于在基于浏览器的应用程序中授权用户,当前最佳做法是
o 将 OAuth 2.0 授权代码流与 PKCE 一起使用 扩展
o 需要 OAuth 2.0 状态参数
o 推荐重定向 URI 的精确匹配,并要求 重定向 URI 的主机名与应用程序 URL 的主机名匹配 来自
o 不要在前端通道中返回访问令牌
[1]:https://datatracker.ietf.org/doc/html/draft-parecki-oauth-browser-based-apps-02) [2]:https://www.rfc-editor.org/rfc/rfc6749#section-2.1
【讨论】:
有时您有一些由客户端调用的 ApiResources,并且流程中没有任何用户。例如使用 instagram 的 api 获取 instagram 的帖子。现在 instagram 想要控制客户端行为,因此客户端应该在任何 api 调用之前获得 instagram 授权。在这种情况下,您需要为每个客户端定义一些秘密来识别它们。 这是客户秘密使用的示例。
【讨论】: