4 回答

• 2

  这是一个有效/实际的安全问题吗？

  对于官方客户端A，我的OAuth2提供商可能会发出“超级”类型/范围令牌，该令牌授予对我的API的公共和私有部分的访问权限

  在一般情况下，您永远不能依赖授予该用户保密的用户的身份验证令牌 . 例如，用户可能正在运行root电话，并读取令牌，获得对私有API的访问权限 . 如果用户的系统遭到入侵，则同上（攻击者可以在这种情况下读取令牌） .

  换句话说，没有任何经过身份验证的用户可以同时访问的“私有”API，因此Android在其设计中通过默默无闻的目标忽略此安全性是合理的 .

  恶意应用程序...可以访问我应用程序存储的OAuth2令牌

  对于恶意应用程序案例，恶意应用程序无法使用客户端令牌听起来更合理，因为我们希望Android的权限系统能够隔离恶意应用程序（前提是用户读取/关心权限他们他们安装时接受） . 但是，正如您所说，用户需要接受（Android系统提供的）访问请求才能使用您的令牌 .

  鉴于此，Android解决方案似乎没问题 - 应用程序无法在不询问的情况下静默使用用户的身份验证，但用户可以明确允许应用程序重新使用以前的身份验证到服务，这对用户来说很方便 .

  可能的解决方案评论

  “秘密”authTokenType ......似乎不太安全

  同意 - 它只是通过默默无闻的另一层安全;听起来任何希望分享您的身份验证的应用程序都必须查找authTokenType的内容，因此采用这种方法只会让这个假想的应用程序开发人员更加尴尬 .

  使用OAuth2令牌发送客户端ID /密码... [以]验证服务器端应用程序是否为授权客户端

  在一般情况下这是不可能的（所有服务器获取的是协议中的一系列消息 - 无法确定生成这些消息的代码） . 在这个特定的例子中，它可以防止（非根）替代客户端/恶意应用程序的更有限的威胁 - 我不熟悉AccountManager来评论（同样适用于您的自定义身份验证令牌解决方案） .

  建议

  您描述了两种威胁 - 用户不希望访问其帐户的恶意应用程序，以及您（开发人员）不希望使用API部分的替代客户端 .

  • 恶意应用：考虑您提供的服务的敏感程度，以及它是否具有保护功能（安装权限，访问请求屏幕） . 如果它更敏感，请考虑您是否在网上银行中使用Android 's AccountManager is appropriate. To strongly protect the user against malicious use of their account, try two factor authentication for dangerous actions (c.f. adding a new recipient'帐户详细信息 .

  • 备用客户端：没有试图仅供官方客户端访问的秘密API;人们会绕过这个 . 无论用户使用何种（未来）客户端，都要确保所有面向公众的API都是安全的 .

  回复于 2024-04-20T12:47:39+08:00
• 1

  你的观察是正确的 . Authenticator将使用与安装应用程序相同的UID运行 . 当另一个应用程序连接到客户经理并获取此身份验证器的令牌时，它将绑定到您提供的身份验证服务 . 它将作为您的UID运行，因此新帐户将与此身份验证器相关联 . 当app调用getAuthToken时，将发生绑定，Authenticator仍将在同一UId中运行 . 默认的内置权限检查帐户的UID，以便不同的身份验证器无法访问来自不同身份验证器的其他帐户 .

  您可以使用“调用UID”为addAccount和GetAuthToken解决此问题，因为客户经理服务会将其添加到捆绑包中 . 您的身份验证器实现可以检查一下 .

  @Override
      public Bundle getAuthToken(AccountAuthenticatorResponse response, Account account,
              String authTokenType, Bundle loginOptions) throws NetworkErrorException {
          Log.v(
                  TAG,
                  "getAuthToken() for accountType:" + authTokenType + " package:"
                          + mContext.getPackageName() + "running pid:" + Binder.getCallingPid()
                          + " running uid:" + Binder.getCallingUid() + " caller uid:"
                          + loginOptions.getInt(AccountManager.KEY_CALLER_UID));
            ...
  }
  

  我建议遵循授权流程而不是将客户端密钥存储在您的本机应用程序中，因为其他开发人员可以提取该秘密 . 您的应用不是网络应用，不应该有秘密 .

  添加帐户时，您也可以查询callingUId . 您需要在 addAccount 相关活动 setUserData ，该活动将作为您应用的UID运行，因此它可以调用 setUserData .

  getUserData 和 setUserData 使用内置的sqllite数据库，因此您不需要自己构建缓存 . 您只能存储字符串类型，但您可以解析json并为每个帐户存储额外信息 .

  当不同的第三方应用查询帐户并使用您的帐户调用getAuthtoken时，您可以在帐户'userdata中查看UID . 如果未列出调用UID，则可以执行提示和/或其他操作以获得权限 . 如果允许，您可以向帐户添加新的UID .

  Sharing tokens between apps ：每个应用程序通常都注册了不同的clientid，他们不应该共享令牌 . 令牌用于客户端应用程序 .

  Storage ：AccountManager未加密您的数据 . 如果您需要更安全的解决方案，则应加密令牌然后存储它 .

  回复于 2024-04-20T12:47:39+08:00
• 1

  我面临着一个app的架构问题 .

  我得到的解决方案是将oauth令牌与app供应商令牌（例如facebook提供给应用程序的令牌）和设备ID（ android_id ）相关联或散列 . 因此，只有授权的应用程序才能使用来自客户经理的令牌 .

  当然，它只是一个新的安全层，但没有防弹 .

  回复于 2024-04-20T12:47:39+08:00
• 10

  我估计@Michael完美地回答了这个问题;然而，为了让那些寻求快速回答的人更加明智和简短，我正在写这篇文章 .

  你对android AccountManager 的安全性的关注是正确的，但这就是OAuth的意思，android AccountManager 依赖于它 .

  换句话说，如果您正在寻找一种非常安全的身份验证机制，这对您来说不是一个好的选择 . 您不应该依赖任何缓存的令牌进行身份验证，因为如果用户的设备上存在任何安全漏洞，例如无意中授予入侵者访问权限，运行root设备等，则可以轻松向入侵者透露这些令牌 .

  在更安全的身份验证系统中，OAuth的更好替代方案，例如在线银行应用程序使用公钥和私钥进行非对称加密，每次使用服务时都要求用户输入密码 . 然后使用设备上的公钥加密密码并将其发送到服务器 . 在这里，即使入侵者知道加密密码，他也无法做任何事情，因为他无法使用该公钥解密它并且只需要服务器的私钥 .

  无论如何，如果想要使用android的 AccountManager 系统以及保持高级别的安全性，那么可以通过不在设备上保存任何令牌来实现 . 然后可以像这样覆盖 AbstractAccountAuthenticator 中的 getAuthToken 方法：

  @Override
  public Bundle getAuthToken(AccountAuthenticatorResponse response, Account account, String
          authTokenType, Bundle options) throws NetworkErrorException {
      AuthenticatorManager authenticatorManager = AuthenticatorManager.authenticatorManager;
      Bundle result;
      AccountManager accountManager = AccountManager.get(context);
      // case 1: access token is available
      result = authenticatorManager.getAccessTokenFromCache(account, authTokenType,
              accountManager);
      if (result != null) {
          return result;
      }
      final String refreshToken = accountManager.getPassword(account);
      // case 2: access token is not available but refresh token is
      if (refreshToken != null) {
          result = authenticatorManager.makeResultBundle(account, refreshToken, null);
          return result;
      }
      // case 3: neither tokens is available but the account exists
      if (isAccountAvailable(account, accountManager)) {
          result = authenticatorManager.makeResultBundle(account, null, null);
          return result;
      }
      // case 4: account does not exist
      return new Bundle();
  }
  

  在这种方法中，情况1，情况2和情况4都不成立，因为没有保存的令牌，即使 account 在那里 . 因此，只返回案例3，然后可以在相关的回调中设置以打开 Activity ，其中用户输入用户名和密码进行身份验证 .

  我不确定是否正在进一步描述这一点，但my website posts on AccountManager可能有助于以防万一 .

  回复于 2024-04-20T12:47:39+08:00