请问 oauth 的 app secret 为啥要保密？

[Agromania]

oauth应用都有个key，还有个secret，为啥要保密？被别人知道了他能拿来做什么坏事呢？

[wormcy]

v2ex用户都有个用户名，还有个密码，为啥要保密？被别人知道了他能拿来做什么坏事呢？

[zts1993]

伪造请求啊。。。。。

[Agromania]

@wormcy 登录了以后可以获得个人信息，发的帖子，从帖子信息有可能可以分析出性格爱好，购物历史，工作，住址，键盘型号……
可以狂点“感谢回复者”……
可以发小广告使自己受益 并导致这个账号被封……

[halfcrazy]

https://github.com/halfcrazy/understanding-csrf/blob/master/README_zh.md#salt%E4%B8%8D%E9%9C%80%E8%A6%81%E5%8A%A0%E5%AF%86

[Agromania]

@zts1993 我就是想不明白，伪造了请求，然后呢。

现实一点的场景，有个应用A，他用了QQ的OAuth。
我用A的app id和app secret和我自己的QQ号授权拿到了我自己的access_token，发了一条腾讯微博，除了微博来源显示来自A，以及我消耗了A的api调用次数，究竟我还能做点什么坏事呢？

[zts1993]

@Agromania 别人的权限可能比你大， 你可以获取更多的敏感信息，或者做一下管理操作。。。一些你觉得无所谓的坏事，其实已经造成很严重的影响了。。。

[Agromania]

@halfcrazy CSRF跟这个场景完全不一样吧，攻击方式和利用信任也不一样，受害者也不一样
CSRF的受害者是在不知情的情况下在B站上提交了指向A站的Form的用户

[Agromania]

@zts1993 我可能理解的不对，但是我理解的是这样，

OAuth服务提供者X OAuth应用A 最终用户John

攻击者Bob自己的OAuth应用B
攻击者Bob自己的应用C（没有申请X的app）

攻击者Bob


首先最终用户要有X上的受信账号
1. 用户John向应用A申请通过X授权，把自己在的X上的用户id告诉A，
2. A通过自己的app id - secret和John的用户id， 把John的意愿告诉X（引导John到X的登录授权页面）
3. X向用户John告知A请求你授权，授权后，A可以访问你的a, b, c数据
4. 用户John登录X
5. X告诉A, John已经授权你了（回调地址, access_token）
6. A通过access_token可以访问John的a,b,c数据

现在攻击者Bob来了，他通过某种方式盗取了A的app id 和secret，Bob做了一个应用C，使用了A的app id和secret，但是John不知道应用C也不使用应用C，

现在Bob他能干嘛呢？

[Agromania]

所以是不是Bob还必须要用钓鱼的方式，在John访问应用A的时候劫持到自己的仿冒应用C，引导John授权，拿到access_token，然后Bob就可以访问和操作John的a,b,c数据了？

再假设如果应用A的权限只是一般应用的权限，Bob自己也申请了一个应用B，也可以访问X上用户的a,b,c数据，那上面这么复杂的攻击还有其他的意义和利益吗？



我知道这个secret应该是非常重要的东西，但是我实在是想不出来严重的场景……

[nopy]

这个key能保证是你请求的内容，如果被别人盗用发点什么东西，让警察叔叔来抓你吗?

[loading]

例如QQ，我能向你妈要钱！

[Agromania]

@nopy 但是oauth的授权机制要求最终用户来授权才行啊，比如你通过qq号登录京东商城，（京东在这里是app，qq是oauth service provider）
我做了个小黑站，我偷了京东的腾讯开放平台app id 和 key，然后呢？你又不来我的小黑站授权，我把我的小黑站授权地址（其实和京东的授权地址一模一样）发给你其实回调地址还是跳转的京东，我好像也做不了啥能让警察叔叔抓你，或者抓刘强东的事情啊……我实在是想不明白。

[Agromania]

@loading 求解。HOW

[nopy]

@Agromania 这个东西是可以授权的，如果你拿到了一个应用的secret key，那么曾经授权过这个应用的所有账号 都可以让你来“使用”。

比如在新浪微博实现定时微博这个功能以前，都是第三方通过API来实现的，用户授权定时微博应用，然后到指定的时间这个应用 通过这个授权来发微博。

[jeansfish]

https://github.com/jeansfish/RFC6749.zh-cn/blob/master/Section10/10.2.md

在不能保证secret key的安全的情况下，redirect uri可以提供更进一步的验证。

[Agromania]

好吧，还是伟大的StackOverflow靠谱，
搜到了这个问题：
http://stackoverflow.com/questions/7121966/should-i-obfuscate-oauth-consumer-secret-stored-by-android-app

回答和我想的差不多，仅仅能做的一种攻击场景是：
应用A和应用B都是用户很多的app，都可以通过QQ授权登录。B用了A的app id和key。B的用户通过QQ登录了B，B拿到了自己的用户的QQ信息，B拿这些信息干了坏事，QQ发现有第三方应用在干坏事，一查，是A的id和secret，就把A封了。

然后这篇文章的第三段和第四段
http://arstechnica.com/security/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong/
说app的secret只能是和user agent一样，以一种比较不可信的方式告诉oauth是哪个应用在请求用户的数据，不能也不应该作为安全相关的使用和可信的判断标准，因为app secret很难保护，尤其是客户端app。

果然。我说我想不出这个东西有啥严重的，跟密码不是一个级别的吧

[jeansfish]

https://github.com/jeansfish/RFC6749.zh-cn/blob/master/Section10/10.1.md

app和js应用是不能使用secret 在本地做客户端验证的。

严格按照协议来做的话，还是能避免一些风险的，毕竟制定协议的时候肯定经过了很多考虑

[GhostFlying]

@Agromania 理论上客户端是应该使用implicit_grant，这样就不用secret了，反正也没意义

[llbbzh]

说实话，weico之类的第三方微博客户端、twitter客户端都要把app_secret保存在apk里面的，这就足以说明app_secret也不是什么见不得人的东西

[nopy]

@Agromania 想起来前几天 微信屏蔽了支付宝的接口，腾讯也屏蔽了网易云音乐的分享接口……嗯 还有这个效果