移动应用中的OAuth秘密

是的,这是我们面临的OAuth设计问题。我们选择通过自己的服务器代理所有调用。OAuth在桌面应用程序方面并没有完全消失。如果不改变OAuth,我发现这个问题没有完美的解决方案。

如果你想一想,问我们为什么有秘密,主要是为了提供和禁用应用程序。如果我们的秘密被泄露,那么提供商只能真正撤销整个应用程序。因为我们必须在桌面应用程序中嵌入我们的秘密,我们有点完蛋了。

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

如果顶级提供者提供一个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

https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

使用OAuth2.0,您可以将机密存储在服务器上。使用服务器获取访问令牌,然后移动到应用程序,您可以从应用程序直接呼叫资源。

在OAuth 1.0(Twitter)中,进行API调用需要保密。通过服务器代理调用是确保机密不被泄露的唯一方法。

(我是OAuth 2.0规范的编辑)

一种解决方案是将OAuth秘密硬编码到代码中,但是 不 就像一根普通的绳子。以某种方式混淆它-将它分割成段,按偏移量移动字符,旋转它-执行任何或所有这些操作。破解程序可以分析字节码并找到字符串,但混淆代码可能很难理解。

这不是一个万无一失的解决方案,而是一个便宜的解决方案。

不要将秘密存储在应用程序中。

https

然后,如果您需要从服务(facebook、google、twitter等)获取任何敏感信息,应用程序将询问您的服务器,并且只有在正确连接的情况下,您的服务器才会将其提供给应用程序。

注

OAuth是浏览器中比桌面/移动设备上更好的协议。

授权码授权类型有一个新的扩展名为 代码交换验证密钥(PKCE)

PKCE(RFC 7636)是一种保护不使用 客户的秘密。

它主要用于本地和移动应用程序,但这种技术可以 授权服务器支持,因此仅在 某些提供者。

从…起 https://oauth.net/2/pkce/

有关更多信息,您可以阅读全文 RFC 7636 或 this short introduction .

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

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

使用OAuth 2.0,您可以简单地使用客户端流获取访问令牌,然后使用该访问令牌对所有进一步的请求进行身份验证。那你根本不需要秘密。

https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

我对OAuth没有太多的经验,但不是每个请求都不仅需要用户的访问令牌,还需要应用程序使用者密钥和密码吗?因此,即使有人偷了一个移动设备并试图从中提取数据,他们也需要一个应用程序密钥和密码才能真正做任何事情。

我同意费利克斯的观点。OAuth虽然比Basic Auth好,但要成为移动应用程序的好解决方案,还有很长的路要走。我一直在使用OAuth将手机应用程序验证为Google应用程序引擎应用程序。您无法在移动设备上可靠地管理消费者机密这一事实意味着默认情况下使用“匿名”访问。

Google App Engine OAuth实现的浏览器授权步骤会将您带到一个包含以下文本的页面: “现场<一些网站>正在请求访问下面列出的产品的Google帐户“

等

这需要<一些网站>从您提供的回调url中使用的域名/主机名,如果您使用自定义方案拦截回调,则可以是Android上的任何内容。 因此,如果你使用“匿名”访问,或者你的消费者机密被泄露,那么任何人都可以编写一个消费者,欺骗用户访问你的gae应用程序。

对于一般不懂技术的用户来说,这是非常可怕的事情。我不希望有一个高的注册完成率与这样的东西的方式。

这篇博文澄清了消费者秘密如何与已安装的应用程序不起作用。 http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

在这里,我回答了在移动应用程序中存储oAuth信息的安全方法

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

严格来说,Facebook还没有实现OAuth,但他们已经实现了一种方法,让你不必在iPhone应用程序中嵌入你的秘密: https://web.archive.org/web/20091223092924/http://wiki.developers.facebook.com/index.php/Session_Proxy

至于OAuth,是的,我越想它,我们就有点吃饱了。大概 this

这些解决方案都不能阻止黑客嗅探从其移动设备(或模拟器)发送的数据包,以查看http头中的客户端机密。

一种解决方案是拥有一个动态秘密,该秘密由一个使用专用双向加密密钥加密的时间戳构成&算法。然后,服务解密该秘密并确定时间戳是否为+/-5分钟。

这样,即使机密被泄露,黑客最多也只能使用5分钟。

我还试图为移动OAuth身份验证和在应用程序包中存储机密提供一个解决方案。

我突然想到了一个疯狂的想法:最简单的想法是将秘密存储在二进制文件中,但不知怎么搞混了,或者,换句话说,你存储了一个加密的秘密。所以,这意味着你必须存储一个密钥来解密你的秘密,这似乎让我们走了一整圈。但是,为什么不使用已经存在于操作系统中的密钥呢?也就是说,它是由操作系统定义的,而不是由应用程序定义的。

这样行吗?

除此之外,您可以始终依赖基于UNIX的Android安全模型:只有您的应用程序才能访问您写入文件系统的内容。只需将信息写入应用程序的默认SharedReferences对象。

为了获得这个秘密,你必须获得安卓手机的root访问权限。