client_id 的 OAuth2 安全注意事项答案

【问题标题】：OAuth2 security considerations for client_idclient_id 的 OAuth2 安全注意事项
【发布时间】：2012-01-06 01:33:29
【问题描述】：

在移动平台使用带有 OAuth2 的用户代理流时，授权服务器无法验证应用程序的 client_id。

因此，任何人都可以通过复制 client_id 来冒充我的应用程序（并代表我获取所有访问令牌），这适用于 Facebook、Foursquare 等...

这不是由 OAuth2 管理的吗？还是我错过了什么？

对于 Web 应用程序（Web 服务器流），访问令牌存储在服务器端，客户端使用密钥进行身份验证。

【问题讨论】：

【解决方案1】：

没有好的答案。本机应用程序回调通常通过自定义注册的 URI 方案发生（例如：回调重定向 URI 类似于：myapp://oauth?code=xyz123）。不幸的是，任何应用都可以声明对给定协议方案的所有权并接收回调。

这个问题与试图用“受信任的客户端”锁定任何协议非常相似。想想 IM 网络为锁定第 3 方客户端而战（在 2000 年代初期）。最终他们放弃了——因为部署的任何客户端和协议端点都可以由第三方开发人员进行逆向工程。

注意：OAuth WG 邮件列表上也有一些关于此主题的积极讨论：http://www.ietf.org/mail-archive/web/oauth/current/msg08177.html

【讨论】：

感谢链接和解释，这在当前草稿中很明显：tools.ietf.org/html/draft-ietf-oauth-v2-22#section-1.3.2。希望这会改变，否则我们别无选择，只能信任授权服务器来检测（有可能吗？）任何对 client_id 的恶意使用......
对。实际上，除了将 client_id 用于资源服务器上的异常事务（RS - 目标 OAuth 保护的 RESful API）之外，检测对 client_id 的恶意使用是非常棘手的。

【解决方案2】：

通常 client_id 与站点的 URL 相关联 - OAuth 响应/重定向将仅发送到注册的 URL。因此攻击者将无法在自己的站点上接收请求的结果（除非您的页面和攻击者的页面在同一个域中）。

【讨论】：