client_id 的 OAuth2 安全注意事项 [英] OAuth2 security considerations for client_id

问题描述

将用户代理流程与 OAuth2 用于移动平台时，授权服务器无法验证应用程序的 client_id.

When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application.

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

So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,...

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

This is not managed by OAuth2 ? Or I missed something ?

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

For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.

推荐答案

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

There's no good answer. Native app callbacks typically happen via custom registered URI schemes (e.g.: callback redirection URI is something like: myapp://oauth?code=xyz123). Unfortunately, any app can claim ownership of a given protocol scheme and receive the callback.

这个问题与试图锁定任何具有可信客户端"的协议非常相似.想想 IM 网络为锁定 3rd 方客户而战(2000 年代初期).最终他们放弃了——因为无论是客户还是部署的协议端点可以由第 3 方开发人员进行逆向工程.

This problem is very synonymous with trying to lock down any protocol with "trusted clients". Think of the IM networks battle to lock out 3rd party clients (in early 2000's). Eventually they gave up - since whatever client & protocol endpoints are deployed could be reverse engineered by 3rd party developers.

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

Note: There is also some active discussion on this topic on the OAuth WG mailing list: http://www.ietf.org/mail-archive/web/oauth/current/msg08177.html

这篇关于client_id 的 OAuth2 安全注意事项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！