移动应用中的OAuth机密

使用OAuth协议时，您需要从要委派给该服务的秘密字符串。如果您是在Web应用程序中执行此操作，则可以仅将秘密存储在数据库或文件系统中，但是在移动应用程序（或与此相关的桌面应用程序）中处理秘密的最佳方法是什么？

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

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

我能想到的唯一可行的解​​决方案是，首先正常获取访问令牌（最好使用应用程序内部的Web视图），然后将所有进一步的通信路由到我们的服务器，这会将秘密添加到请求数据中并进行通信。与提供者。再说一次，我是安全菜鸟，所以我真的很想听听一些知识渊博的人们对此的看法。在我看来，大多数应用程序都不会采用这些长度来保证安全性（例如，Facebook Connect似乎假定您将秘密信息直接放入应用程序中的字符串中）。

另一件事：我不认为最初请求访问令牌涉及秘密，因此可以在不涉及我们自己的服务器的情况下完成。我对么？

是的，这是我们面临的OAuth设计问题。我们选择通过自己的服务器代理所有呼叫。对于桌面应用程序，OAuth并未完全被淘汰。如果不更改OAuth，就找不到完美的解决方案。

如果您考虑一下并提出问题，为什么我们会有秘密，这主要是用于提供和禁用应用程序。如果我们的秘密被泄露，那么提供商只能真正撤消整个应用程序。由于我们必须在台式机应用程序中嵌入秘密，因此我们有点困惑。

解决方案是为每个桌面应用程序设置不同的秘密。OAuth并没有使这个概念变得容易。一种方法是让用户自行创建一个秘密，然后自行将密钥输入到桌面应用程序中（某些facebook应用程序做了很长时间的相似操作，让用户自行创建facebook来设置自定义测验，然后废话）。对于用户而言，这不是很好的体验。

我正在为OAuth委派系统的提案。概念是，使用从提供商那里获得的我们自己的密钥，我们可以将自己的委托密钥发布给我们自己的桌面客户端（基本上每个桌面应用程序一个），然后在身份验证过程中，将该密钥发送到顶层提供者，它会回电话给我们并与我们重新验证。这样，我们就可以撤销发布给每个桌面客户端的秘密。（从SSL借用了很多方法）。整个系统对于增值Web服务以及将呼叫传递到第三方Web服务都是完美的。

如果顶级提供程序提供了用于生成和撤消新的委托机密的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

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

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

使用OAuth 1.0（Twitter），进行API调用需要密码。通过服务器代理呼叫是确保机密不被泄露的唯一方法。

两者都需要某种机制，使您的服务器组件知道客户端正在调用它。这通常是在安装过程中完成的，并使用特定于平台的机制在对服务器的调用中获取某种类型的应用程序ID。

（我是OAuth 2.0规范的编辑）

一种解决方案是将OAuth密码硬编码到代码中，而不是将其作为纯字符串。以某种方式进行模糊处理-将其拆分为段，按偏移量移动字符，旋转它-执行任何或所有这些操作。破解者可以分析您的字节码并找到字符串，但是混淆代码可能很难弄清楚。

这不是万无一失的解决方案，而是一种廉价的解决方案。

根据漏洞利用的价值，某些天才破解者可能会花更长时间寻找您的秘密代码。您需要权衡以下因素：先前提到的服务器端解决方案的成本，鼓励破解者花费更多精力查找秘密代码的动机以及可以实现的混淆的复杂性。

不要将机密存储在应用程序内部。

您需要有一个可以由应用程序通过https（显然）访问的服务器，并将机密存储在该服务器上。

当某人想要通过您的移动/桌面应用程序登录时，您的应用程序将简单地将请求转发到服务器，服务器将附加该机密并将其发送给服务提供商。然后，您的服务器可以告诉您的应用程序是否成功。

然后，如果您需要从服务（facebook，google，twitter等）中获取任何敏感信息，则应用程序会询问您的服务器，并且只有在正确连接后，服务器才会将其提供给应用程序。

除了将其存储在服务器上之外，实际上没有任何其他选择。客户端上没有什么是安全的。

注意

就是说，这只会保护您免受恶意客户端的侵害，而不会保护客户端免受恶意您的侵害，而不保护客户端免受其他恶意客户端的侵害（网络钓鱼）...

OAuth是浏览器中比台式机/移动设备更好的协议。

授权代码授予类型有一个新扩展，称为代码交换证明密钥（PKCE）。有了它，您不需要客户机密。

PKCE（RFC 7636）是一种保护不使用客户端机密的公共客户端的技术。

它主要由本机和移动应用程序使用，但是该技术也可以应用于任何公共客户端。它需要授权服务器的额外支持，因此仅在某些提供程序上受支持。

来自https://oauth.net/2/pkce/

有关更多信息，您可以阅读完整的RFC 7636或此简短介绍。

这是要考虑的事情。Google为网络应用程序提供了两种OAuth ...方法，用于注册域并生成唯一密钥的Web应用程序，以及用于使用密钥“匿名”的已安装应用程序的OAuth...。

也许我在阅读中有所遗漏，但是似乎与在已安装的应用程序中共享Web应用程序的唯一密钥相比在正式安装的应用程序方法中使用“匿名”更为安全。

使用OAuth 2.0，您可以简单地使用客户端流程获取访问令牌，然后使用该访问令牌对所有其他请求进行身份验证。然后，您根本不需要任何秘密。

有关如何实现此功能的详细说明，请参见：https：//aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

我没有大量的OAuth经验-但是不是每个请求都不仅需要用户的访问令牌，还需要应用程序使用者密钥和机密吗？因此，即使有人窃取了移动设备并试图从中提取数据，他们也将需要应用程序密钥和机密才能真正执行任何操作。

我一直以为OAuth的目的是使每个具有混搭功能的Tom，Dick和Harry不必将您的Twitter凭据存储在明文中。我认为尽管有其局限性，它仍然可以很好地解决该问题。此外，它并不是真正为iPhone设计的。

我同意Felixyz。OAuth虽然比Basic Auth更好，但要成为移动应用程序的良好解决方案还有很长的路要走。我一直在使用OAuth验证手机应用程序到Google App Engine应用程序的身份。您无法可靠地管理移动设备上的消费者机密这一事实意味着默认设置是使用“匿名”访问。

Google App Engine OAuth实施的浏览器授权步骤将带您进入一个包含以下文本的页面：“网站<some-site>正在请求访问以下所列产品的Google帐户”

YourApp（yourapp.appspot.com）-与Google无关

等等

它使用您提供的回调URL中使用的域名/主机名中的<some-site>，如果您使用自定义方案来拦截回调，则在Android上可以是任何名称。因此，如果您使用“匿名”访问方式或您的消费者秘密被盗用，那么任何人都可以编写一个消费者来欺骗用户，让其无法访问您的gae应用。

Google OAuth授权页面上也确实包含许多警告，警告的严重性分为3级，具体取决于您使用的是“匿名”，消费者秘密还是公共密钥。

对于技术上不精通的普通用户而言，这是非常可怕的东西。我不希望这种方式的注册完成率很高。

这篇博客文章阐明了消费者机密在安装的应用程序中如何真正发挥作用。 http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

我还试图提出一种用于移动OAuth身份验证的解决方案，并通常在应用程序捆绑包中存储机密信息。

一个疯狂的主意打了我一下：最简单的主意是将机密存储在二进制文件中，但是以某种方式混淆了，换句话说，就是存储了一个加密的机密。因此，这意味着您必须存储一个密钥来解密您的秘密，这似乎使我们花了整整一周的时间。但是，为什么不只使用操作系统中已经存在的密钥，即它是由操作系统而不是由您的应用程序定义的。

因此，要澄清我的想法是，选择操作系统定义的字符串，无论哪个字符串都没有关系。然后使用此字符串作为密钥加密您的秘密，并将其存储在您的应用程序中。然后在运行时，使用密钥（仅是OS常量）解密变量。窥视您的二进制文件的任何黑客都将看到一个加密的字符串，但没有密钥。

那行得通吗？

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

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

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysinios应用程序

Facebook尚未严格执行OAuth（至今），但他们已为您提供了一种不将您的秘密嵌入iPhone应用程序的方法：https : //web.archive.org/web/20091223092924/http : //wiki。 developers.facebook.com/index.php/Session_Proxy

对于OAuth，是的，我想得越多，我们就有点塞满了。也许这会解决它。

这些解决方案均不能阻止坚定的黑客嗅探从其移动设备（或仿真器）发送的数据包，以查看http标头中的客户端机密。

一种解决方案可能是拥有一个动态秘密，该秘密由使用私有2向加密密钥和算法加密的时间戳组成。然后，该服务解密机密并确定时间戳是否为+/- 5分钟。

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

正如其他人提到的那样，将机密本地存储在设备上应该没有真正的问题。

最重要的是，您始终可以依赖Android的基于UNIX的安全模型：只有您的应用程序才能访问您写入文件系统的内容。只需将信息写入应用程序的默认SharedPreferences对象即可。

为了获得秘密，必须获得对Android手机的root访问权限。