问移动应用中的OAuth秘诀

EN

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

如果你仔细想想，问我们为什么有秘密，主要是为了提供和禁用应用程序。如果我们的秘密被泄露，那么提供商只能真正撤销整个应用程序。因为我们必须在桌面应用程序中嵌入我们的秘密，所以我们在某种程度上搞砸了。

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

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

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

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

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

推特和Yammer的解决方案是一个身份验证pin解决方案：https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

使用OAUth 2.0，您可以将秘密存储在服务器上。使用服务器获取访问令牌，然后将其移动到应用程序，您可以直接从应用程序调用资源。

在API1.0(推特)中，进行OAuth调用时需要密码。通过服务器代理调用是确保秘密不被泄露的唯一方法。

两者都需要某种机制，以便您的服务器组件知道它是您的客户端在调用它。这往往是在安装时完成的，并使用特定于平台的机制在对服务器的调用中获得某种应用程序id。

(我是OAuth 2.0规范的编辑)

这里有一些需要考虑的事情。谷歌提供了两种OAuth的方法...对于注册域名并生成唯一密钥的web应用程序，以及使用“匿名”密钥的已安装应用程序。

也许我在阅读中忽略了一些东西，但似乎与已安装的应用程序共享您的webapp的唯一密钥可能比在官方安装的应用程序方法中使用“匿名”更安全。