用户名和密码放在共享首选项中是安全的。 在连接到服务器时使用 https 也应该足够好了。

我想他们使用的是基于“令牌”的安全系统，所以密码实际上从来不存储在任何地方，只是第一次使用来进行身份验证。因此，应用程序最初发布用户名/密码(通过 ssl) ，服务器返回应用程序存储的令牌。对于后续的同步尝试，首先发送令牌，服务器检查它是否有效，然后允许发布其他数据。

令牌应该有一个过期时间，以便服务器可以重新请求身份验证尝试。

如果你从 Android 框架中连接到同步适配器，那么你就可以对所有内容进行同步和验证。

Http://developer.android.com/training/sync-adapters/creating-sync-adapter.html

基本上这些著名的使用 OAuth 协议(1)/框架(2)。尽管它必须是一个标准，但是每个标准对于这个协议/框架都有不同的实现。因此，我们必须非常小心，当谈到整合。

例如: Dropbox 仍然使用 OAuth 1，并且最近提供了对 OAuth 2的支持。

回到答案，正如彼得潘所说，它是一种基于令牌的身份验证方法，是一次性的事物，不在等式之内。在某些情况下，这些令牌已经过期，或者该权限已经授予开发人员。

这背后有趣的事情是，可以定义资源访问范围，而不是允许客户端应用程序保留用户名和密码，这是危险的。

这是它是如何工作的基本说明。

我会更新的答案后，我得到更多的细节，因为我在这个领域的工作了这些天:)

我正在搜索完全相同的东西，发现谷歌方式，一些像彼得潘说，但通过谷歌 API。尝试这个链接和谷歌你的方式通过它，我也开始！我会发布新的信息，而我在它！

Http://developer.android.com/google/auth/http-auth.html

我是一个新手，但我会尽量给出合乎逻辑的解决方案给出的问题。

有两个选择, [1]对于每个 URI，在用户输入的凭据将被验证并且用户将访问资源的地方将执行 http 认证。

[2]另一种方法是，用户进行身份验证，并在每次身份验证时生成一个唯一的令牌。使用生成的令牌，用户将访问资源。

虽然我不确定哪种方法最适合移动应用程序。

身份验证示例 是一个很好的起点。Android 在帐户管理器中存储凭据，您可以在 Android 的设置中查看帐户。这将自动存储令牌，如果过期或丢失，提示用户凭据，刷新令牌等。我发现这个示例的 http 部分缺少或者陈旧。扩展 android 的 AccountAuthenticatorActivity 是解析序列化数据到布局并返回到 Internet 的一个很好的帮助器。

如果我只使用基于用户名/密码的身份验证，它们就不够安全了吗？

不，因为您只标识了 谁正在访问 API 服务器，而不是 什么正在访问它。

访问 API 服务器的人和事的区别

为了更好地理解 谁和 什么在访问 API 服务器方面的区别，让我们使用以下图片:

意向通信频道代表了移动应用程序正如你所期望的那样被合法用户使用，没有任何恶意的意图，使用一个未被篡改的移动应用程序版本，并且直接与 API 服务器通信而不受到中间人的攻击。

实际的渠道可能代表几种不同的情况，比如一个有恶意意图的合法用户可能使用重新打包的移动应用版本，一个黑客使用真正的移动应用版本，而中间人攻击它，以了解移动应用和 API 服务器之间的通信是如何进行的，以便能够自动攻击你的 API。许多其他情况也是可能的，但是我们不会在这里逐一列举。

我希望到现在为止你可能已经知道为什么 谁和 什么不一样了，但是如果不一样的话，过一会儿你就会明白了。

谁是移动应用程序的用户，我们可以通过几种方式对其进行身份验证、授权和识别，比如使用 OpenID Connect 或 OAUTH2流。

哇哦

通常，OAuth 代表资源所有者向客户机提供对服务器资源的“安全委托访问”。它指定资源所有者授权第三方访问其服务器资源而不共享其凭据的过程。专为处理超文本传输协议(HTTP)而设计的 OAuth 基本上允许授权服务器在获得资源所有者的批准后，向第三方客户端发出访问令牌。然后，第三方使用访问令牌访问资源服务器承载的受保护资源。

OpenID 连接

OpenID Connect 1.0是 OAuth 2.0协议之上的一个简单标识层。它允许客户端基于授权服务器执行的身份验证来验证最终用户的身份，并以可互操作和类 REST 的方式获取关于最终用户的基本配置文件信息。

虽然用户身份验证可以让 API 服务器知道 谁正在使用该 API，但它不能保证请求来自您所期望的 什么，即移动应用程序的原始版本。

现在我们需要一种方法来识别 什么正在调用 API 服务器，这里的事情变得比大多数开发人员想象的更加棘手。什么是向 API 服务器发出请求的东西。它真的是移动应用程序的一个真实实例吗? 还是一个机器人、一个自动化脚本或者一个攻击者使用 Postman 这样的工具在 API 服务器上手动探查？

出乎你的意料，你可能最终会发现，它可能是一个合法用户使用重新打包版本的移动应用程序或自动脚本，试图游戏化和利用应用程序提供的服务。

为了识别 什么，开发人员倾向于使用一个 API 密钥，通常他们会在移动应用程序的代码中硬编码这个密钥。一些开发人员在移动应用程序的运行时计算密钥，因此它成为一个运行时的秘密，而不是前一种方法，当一个静态的秘密嵌入到代码中。

上面的文章摘自我写的一篇题为 为什么你的手机应用程序需要 API 密钥？的文章，您可以阅读完整的 给你，这是关于 API 键的一系列文章中的第一篇文章。

在客户端设备中存储敏感数据

出于安全原因，我不能把用户名/密码保存在设备里？ 我是否应该在注册时为每个用户发布一个 GUID，将其保存在他们的设备中，并在每次 API 请求期间检索？

你在设备中保存的任何东西，即使加密了，也可以在运行时通过 Frida 或 Xposed 等工具进行反向工程。

弗里达

将您自己的脚本注入到黑盒进程中。钩住任何函数，监视加密 API 或跟踪私有应用程序代码，不需要源代码。编辑，点击保存，并立即看到结果。所有这些都没有编译步骤或程序重新启动。

暴露了

Xsted 是一个模块框架，它可以改变系统和应用程序的行为，而无需触及任何 APK。这很好，因为这意味着模块可以在不同版本甚至不需要任何更改的 ROM 上工作(只要原始代码不变)

在一个设备中，攻击者控制他也可以使用一个代理来执行一个人在中间攻击，以提取任何秘密，你可以用来识别 什么或 谁，如我在文章 用攻击中的人偷取 API 密钥所示:

虽然我们可以使用高级技术，比如 JNI/NDK，来隐藏移动应用程序代码中的 API 密钥，但它不会阻止某人为了窃取 API 密钥而执行 MitM 攻击。事实上，MitM 攻击很容易被非开发人员实现。

那么现在怎么办... 我是否注定无法保护我的 API 服务器免受滥用? ? ？没有宁静，所以... 希望仍然存在! ! ！

可能的解决方案

有人能告诉我著名的安卓应用如 Facebook，FourSquare 或 Twitter 使用什么方法来验证每一个从他们的移动应用到他们的服务器的请求吗？

对不起，我没有足够的知识在这个应用程序能够阐明你，但我可以向你指出一些其他的方法。

还有哪些模式是可用的，哪些模式是最有效和安全的，我只需要一个流程流就可以了。

因此，任何在客户端运行并需要一些秘密来访问 API 的东西都可能以不同的方式被滥用，您可以在关于 Mobile API 安全技术的 这个系列文章中了解更多信息。本文将教您如何使用 API 密钥、用户访问令牌、 HMAC 和 TLS 固定来保护 API，以及如何绕过它们。

为了解决 什么访问你的移动应用的问题，你需要使用上面提到的移动 API 安全技术系列文章中提到的一个或全部解决方案，并且承认它们只能使未经授权访问你的 API 服务器更难绕过，但并非不可能。

一个更好的解决方案可以使用移动应用程序认证解决方案，这将使 API 服务器知道只接收来自真正的移动应用程序的请求。

移动应用程序认证

使用移动应用程序认证解决方案将使 API 服务器知道 什么正在发送请求，从而允许仅响应来自真正的移动应用程序的请求，同时拒绝来自不安全来源的所有其他请求。

移动应用认证解决方案的作用是在运行时保证你的移动应用没有被篡改，没有运行在一个根设备上，没有被像 xPose 或 Frida 这样的框架检测，没有被 MitM 攻击，这是通过在后台运行一个 SDK 来实现的。运行在云端的服务将挑战应用程序，并且基于响应，它将证明移动应用程序和设备的完整性，因此 SDK 将永远不会对任何决定负责。

在成功地验证移动应用程序完整性时，会发出一个短时间的 JWT 令牌，并使用一个只有 API 服务器和云中的移动应用程序认证服务才知道的秘密进行签名。在移动应用程序认证失败的情况下，JWT 令牌使用 API 服务器不知道的机密进行签名。

现在，应用程序必须随每个 API 调用发送请求头中的 JWT 令牌。这将允许 API 服务器只在它可以验证 JWT 令牌中的签名和过期时间时提供请求，并在验证失败时拒绝它们。

一旦移动应用程序认证服务使用的秘密不为移动应用程序所知，即使应用程序被篡改，在植入设备中运行，或者通过中间人攻击的目标连接进行通信，也不可能在运行时对其进行逆向工程。

移动应用程序认证服务已经作为 SAAS 解决方案存在于 Aporov (我在这里工作) ，它为几个平台提供 SDK，包括 iOS、 Android、 React Natural 和其他平台。集成还需要在 API 服务器代码中进行一个小小的检查，以验证云服务发出的 JWT 令牌。这个检查对于 API 服务器能够决定服务什么请求和拒绝什么请求是必要的。

结论

最后，为了保护你的 API 服务器而使用的解决方案必须根据你试图保护的东西的价值和对这类数据的法律要求来选择，就像欧洲的 GDPR 法规一样。

你想多走一段路吗？

OWASP 流动保安计划-十大风险

OWASP 移动安全项目是一个集中的资源，旨在为开发人员和安全团队提供建立和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类，并提供发展控制，以减少其影响或利用的可能性。