移动应用程序中的 OAuth 秘密 [英] OAuth secrets in mobile apps

问题描述

使用 OAuth 协议时，您需要从要委托给的服务中获取一个秘密字符串.如果您在 Web 应用程序中执行此操作，您可以简单地将机密存储在您的数据库或文件系统中，但是在移动应用程序(或桌面应用程序)中处理它的最佳方法是什么?

When using the OAuth protocol, you need a secret string obtained from the service you want to delegate to. If you are doing this in a web app, you can simply store the secret in your data base or on the file system, but what is the best way to handle it in a mobile app (or a desktop app for that matter)?

将字符串存储在应用程序中显然不好，因为有人很容易找到并滥用它.

Storing the string in the app is obviously not good, as someone could easily find it and abuse it.

另一种方法是将其存储在您的服务器上，并让应用程序在每次运行时获取它，而不是将其存储在手机上.这几乎同样糟糕，因为您必须在应用中包含 URL.

Another approach would be to store it on your server, and have the app fetch it on every run, never storing it on the phone. This is almost as bad, because you have to include the URL in the app.

我能想到的唯一可行的解​​决方案是首先像往常一样获取访问令牌(最好使用应用程序内的 Web 视图)，然后通过我们的服务器路由所有进一步的通信，这会将密钥附加到请求中数据并与提供者进行通信.再说一次，我是一个安全新手，所以我真的很想听听一些知识渊博的人对此的看法.在我看来，大多数应用程序都不会以这些长度来保证安全性(例如，Facebook Connect 似乎假设您将机密放入应用程序中的字符串中).

The only workable solution I can come up with is to first obtain the Access Token as normal (preferably using a web view inside the app), and then route all further communication through our server, which would append the secret to the request data and communicate with the provider. Then again, I'm a security noob, so I'd really like to hear some knowledgeable peoples' opinions on this. It doesn't seem to me that most apps are going to these lengths to guarantee security (for example, Facebook Connect seems to assume that you put the secret into a string right in your app).

另一件事:我不相信最初请求访问令牌时涉及秘密，因此可以在不涉及我们自己的服务器的情况下完成.我说得对吗?

Another thing: I don't believe the secret is involved in initially requesting the Access Token, so that could be done without involving our own server. Am I correct?

推荐答案

是的，这是我们自己面临的 OAuth 设计问题.我们选择通过我们自己的服务器代理所有调用.OAuth 在桌面应用程序方面并没有完全被淘汰.我在不更改 OAuth 的情况下发现的问题没有完美的解决方案.

Yes, this is an issue with the OAuth design that we are facing ourselves. We opted to proxy all calls through our own server. OAuth wasn't entirely flushed out in respect of desktop apps. There is no prefect solution to the issue that I've found without changing OAuth.

如果您考虑一下并询问我们为什么拥有机密的问题，主要是为了提供和禁用应用程序.如果我们的秘密被泄露，那么提供商只能真正撤销整个应用程序.由于我们必须在桌面应用程序中嵌入我们的秘密，我们有点搞砸了.

If you think about it and ask the question why we have secrets, is mostly for provision and disabling apps. If our secret is compromised, then the provider can only really revoke the entire app. Since we have to embed our secret in the desktop app, we are sorta screwed.

解决方案是为每个桌面应用程序设置不同的密码.OAuth 并没有让这个概念变得简单.一种方法是让用户自己创建一个秘密，然后自己将密钥输入到您的桌面应用程序中(一些 facebook 应用程序做了类似的事情很长一段时间，让用户去创建 facebook 来设置他们的自定义测验和废话).对于用户来说，这不是一个很好的体验.

The solution is to have a different secret for each desktop app. OAuth doesn't make this concept easy. One way is have the user go and create an secret on their own and enter the key on their own into your desktop app (some facebook apps did something similar for a long time, having the user go and create facebook to setup their custom quizes and crap). It's not a great experience for the user.

我正在研究 OAuth 委托系统的提案.这个概念是使用我们从提供商那里获得的自己的密钥，我们可以向我们自己的桌面客户端发布我们自己的委托密钥(基本上每个桌面应用程序一个)，然后在身份验证过程中我们将该密钥发送到顶级回调给我们并与我们重新验证的提供商.这样我们就可以撤销我们发布给每个桌面客户端的自己的秘密.(从 SSL 借用了很多这是如何工作的).整个系统将非常适合增值网络服务以及将调用传递给第三方网络服务.

I'm working on proposal for a delegation system for OAuth. The concept is that using our own secret key we get from our provider, we could issue our own delegated secret to our own desktop clients (one for each desktop app basically) and then during the auth process we send that key over to the top level provider that calls back to us and re-validates with us. That way we can revoke on own secrets we issue to each desktop client. (Borrowing a lot of how this works from SSL). This entire system would be prefect for value-add webservices as well that pass on calls to a third party webservice.

如果顶级提供商提供 API 来生成和撤销新的委托机密，也可以在没有委托验证回调的情况下完成该过程.Facebook 正在做类似的事情，允许 Facebook 应用程序允许用户创建子应用程序.

The process could also be done without delegation verification callbacks if the top level provider provides an API to generate and revoke new delegated secrets. Facebook is doing something similar by allowing facebook apps to allow users to create sub-apps.

网上有一些关于这个问题的讨论:

There are some talks about the issue online:

http://blog.atebits.com/2009/02/fixing-oauth/http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14

Twitter 和 Yammer 的解决方案是身份验证 pin 解决方案:https://dev.twitter.com/oauth/pin-basedhttps://www.yammer.com/api_oauth_security_addendum.html

Twitter and Yammer's solution is a authentication pin solution: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

这篇关于移动应用程序中的 OAuth 秘密的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！