在使用OAuth协议时,您需要从要委托给的服务中获取一个秘密字符串。如果您在web应用程序中执行此操作,您可以简单地将秘密存储在数据库或文件系统中,但是在移动应用程序(或桌面应用程序)中处理它的最好方法是什么?
将字符串存储在应用程序中显然并不好,因为有人很容易找到它并滥用它。
另一种方法是将其存储在您的服务器上,让应用程序在每次运行时获取它,而不是将其存储在手机上。这几乎同样糟糕,因为您必须在应用程序中包含URL。
我能想到的唯一可行的解决方案是首先像往常一样获得访问令牌(最好是使用应用程序内部的web视图),然后通过我们的服务器路由所有进一步的通信,服务器会将秘密附加到请求数据并与提供者通信。话又说回来,我是一个安全新手,所以我真的很想听听一些有见识的人对此的看法。在我看来,大多数应用程序似乎都不会为了保证安全性而走这么远(例如,Facebook Connect似乎假设你把秘密放在你的应用程序的字符串中)。
另一件事:我不相信在最初请求访问令牌时涉及这个秘密,所以这可以在不涉及我们自己的服务器的情况下完成。我说的对吗?
发布于 2009-12-20 05:44:57
是的,这是我们自己面临的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
发布于 2014-05-03 23:07:10
使用OAUth 2.0,您可以将秘密存储在服务器上。使用服务器获取访问令牌,然后将其移动到应用程序,您可以直接从应用程序调用资源。
在API1.0(推特)中,进行OAuth调用时需要密码。通过服务器代理调用是确保秘密不被泄露的唯一方法。
两者都需要某种机制,以便您的服务器组件知道它是您的客户端在调用它。这往往是在安装时完成的,并使用特定于平台的机制在对服务器的调用中获得某种应用程序id。
(我是OAuth 2.0规范的编辑)
发布于 2010-04-03 08:58:00
这里有一些需要考虑的事情。谷歌提供了两种OAuth的方法...对于注册域名并生成唯一密钥的web应用程序,以及使用“匿名”密钥的已安装应用程序。
也许我在阅读中忽略了一些东西,但似乎与已安装的应用程序共享您的webapp的唯一密钥可能比在官方安装的应用程序方法中使用“匿名”更安全。
https://stackoverflow.com/questions/1934187
复制相似问题