使用 OAuth 协议(protocol)时，您需要从您要委托(delegate)的服务中获取一个 secret 字符串。如果您在 Web 应用程序中执行此操作，您可以简单地将 secret 存储在您的数据库或文件系统中，但是在移动应用程序(或桌面应用程序)中处理它的最佳方法是什么？
将字符串存储在应用程序中显然不好，因为有人很容易找到并滥用它。
另一种方法是将其存储在您的服务器上，并让应用程序在每次运行时获取它，而不是将其存储在手机上。这几乎同样糟糕，因为您必须在应用程序中包含 URL。
我能想到的唯一可行的解决方案是首先正常获取访问 token (最好使用应用程序内的 WebView )，然后通过我们的服务器路由所有进一步的通信，这会将 secret 附加到请求中数据并与提供者通信。再说一次，我是一个安全菜鸟，所以我真的很想听听一些知识渊博的人对此的看法。在我看来，大多数应用程序都不会用这些长度来保证安全性(例如，Facebook Connect 似乎假设您将 key 放入应用程序中的字符串中)。
另一件事:我不认为最初请求访问 token 涉及 secret ，因此可以在不涉及我们自己的服务器的情况下完成。我说的对吗？
最佳答案
是的，这是我们自己面临的 OAuth 设计的问题。我们选择通过我们自己的服务器代理所有调用。 OAuth 在桌面应用程序方面并未完全淘汰。在不更改 OAuth 的情况下，我发现的问题没有完美的解决方案。
如果您考虑一下并问我们为什么有 secret 的问题，主要是为了提供和禁用应用程序。如果我们的 secret 被泄露，那么提供商只能真正撤销整个应用程序。由于我们必须在桌面应用程序中嵌入我们的 secret ，我们有点搞砸了。
解决方案是为每个桌面应用设置不同的密码。 OAuth 不会让这个概念变得简单。一种方法是让用户自己创建一个 secret ，然后自己将 key 输入到您的桌面应用程序中(一些 Facebook 应用程序在很长一段时间内都做了类似的事情，让用户去创建 Facebook 来设置他们的自定义测验和废话)。这对用户来说不是很好的体验。
我正在为 OAuth 的委托(delegate)系统提出建议。这个概念是，使用我们从提供商那里获得的我们自己的 key ，我们可以向我们自己的桌面客户端(基本上每个桌面应用程序一个)发布我们自己的委托(delegate) key ，然后在身份验证过程中我们将该 key 发送到顶层回拨给我们并与我们重新验证的提供商。这样我们就可以撤销我们发布给每个桌面客户端的自己的 secret 。 (从 SSL 中借鉴了很多它的工作原理)。整个系统对于增值网络服务以及将调用传递给第三方网络服务都是完美的。
如果顶级提供商提供 API 来生成和撤销新的委托(delegate) secret ，则该过程也可以在没有委托(delegate)验证回调的情况下完成。 Facebook 通过允许 Facebook 应用程序允许用户创建子应用程序来做类似的事情。
网上有一些关于这个问题的讨论:
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-based https://www.yammer.com/api_oauth_security_addendum.html
关于iphone - 移动应用程序中的 OAuth secret ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1934187/