OAuth - 防止共享消费者密钥/秘密和访问令牌列表的安全性
我一直致力于建立一个服务提供商，并发现，要代表用户发出请求，似乎需要的只是消费者密钥/秘密和令牌密钥/秘密。
是什么阻止消费者向我的服务提供商注册，让一些用户授权访问他们的某些数据，然后将访问令牌和消费者信息提供给第三方？
这是否归结为信任问题，我们必须相信我们的消费者不会这样做？我们有什么方法可以通过监控来阻止此类活动吗？我们希望提供 OAuth 解决方案，但我们不想过度担心恶意消费者。
感谢您的任何见解。
I have been working on setting up a service provider and saw that, to make a request on behalf of a user, all that seems to be needed is the Consumer Key/Secret and the Token Key/Secret.
What stops a consumer from registering with my service provider, getting some users to authorize access to some of their data, and then giving the access token and consumer information away to a 3rd party?
Does this come down to a trust issue that we have to put trust in our consumers that they wouldn't do this? Is there any way we can prevent this kind of activity via any monitoring? We want to provide an OAuth solution but we don't want to have to worry extensively about a malicious consumer.
Thanks for any insight.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Twitter 的 OAuth 实现涉及四种令牌。
在 Web 应用程序中，最终用户永远无法访问令牌 1 和 2。 2 因为它们永远不会传输给客户端。与 Twitter API 的通信是服务器到服务器的。在这种情况下，风险较小。
对于桌面应用程序，“消费者”密钥通常以某种方式嵌入到二进制文件中。这是 Twitter 的 OAuth 实现中公认的安全问题。一个有决心的人可以反编译/破解/取消混淆任何二进制文件来获取您的消费者密钥。
因此，回答您的问题：就桌面/移动应用程序而言，这绝对是一个信任问题。对于网络应用程序来说，情况就不那么严重了。
There are four tokens involved in Twitter's OAuth implementation.
In the case of a web application, the end user never has access to tokens 1 & 2 because they're never transmitted to the client. The communication with the Twitter API is server-to-server. In this scenario, there's less risk.
In the case of a desktop application, the "Consumer" keys are usually embedded in the binary in some way. This is an acknowledged security problem with Twitter's implementation of OAuth. A determined person can decompile/crack/unobfuscate just about any binary to get your Consumer Keys.
So, to answer your question: In the case of desktop/mobile apps, it's absolutely a question of trust. In the case of web apps, it is less so.