Share via

使用 MSAL 在 Android 上启用跨应用 SSO

  • 项目

有了单一登录 (SSO)，用户只需输入一次凭据，这些凭据将能自动应用于多个应用程序上。

Microsoft 标识平台和 Microsoft 身份验证库 (MSAL) 可帮助你在自己的一套应用中启用 SSO。 利用中转站功能和 Authenticator 应用程序，可以在整个设备上扩展 SSO。

本操作指南介绍了如何配置应用程序所使用的 SDK，以便向客户提供 SSO。

先决条件

本操作指南假定你知道如何执行以下操作：

SSO 的方法

应用程序可通过两种方式，使用适用于 Android 的 MSAL 来实现 SSO：

  • 通过中转站应用程序

  • 通过系统浏览器

    为了实现设备范围的 SSO、帐户管理和条件访问等权益，建议使用中转站应用程序。 但是，它要求用户下载其他应用程序。

通过中转身份验证的 SSO

建议使用 Microsoft 的某一个身份验证中介来参与设备范围的 SSO，并保证符合组织条件访问策略的要求。 与中介集成可提供以下优势：

  • 设备 SSO
  • 对以下功能进行条件访问：
    • Intune 应用保护
    • 设备注册 (Workplace Join)
    • 移动设备管理
  • 设备范围的帐户管理
    • 通过 Android AccountManager 和帐户设置
    • “工作帐户”- 自定义帐户类型

在 Android 上，Microsoft 身份验证中介是随附在 Microsoft Authenticator 和 Intune 公司门户应用中的一个组件。

下图演示了应用、MSAL 与 Microsoft 身份验证中转站之间的关系。

Diagram showing how an application relates to MSAL, broker apps, and the Android account manager.

安装托管中介的应用

设备所有者随时可以从应用商店（通常是 Google Play 商店）安装中介托管应用。 但是，某些 API（资源）受条件访问策略的保护，这些策略要求设备：

  • 已注册（已加入工作区），和/或
  • 已在设备管理中注册，或
  • 已在 Intune 应用保护中注册

如果某个设备上尚未安装中介应用，当应用尝试以交互方式获取令牌时，MSAL 会立即指示用户安装一个中介应用。 然后，应用需要引导用户完成相关步骤，使设备符合所需的策略。

安装和卸载中介的影响

已安装中介时

在设备上安装中介后，所有后续交互式令牌请求（对 acquireToken() 的调用）将由该中介处理，而不是由 MSAL 在本地处理。 以前提供给 MSAL 的任何 SSO 状态不会提供给中转站。 因此，用户需要重新进行身份验证，或者从设备已知的现有帐户列表中选择一个帐户。

安装中介无需用户再次登录。 仅当用户需要解决 MsalUiRequiredException 时，下一个请求才会发送到中介。 引发 MsalUiRequiredException 的原因有很多，需要以交互方式解决。 例如：

  • 用户更改了与其帐户关联的密码。
  • 用户的帐户不再符合条件访问策略。
  • 用户撤销了应用与其帐户关联的许可。

多个中转站 - 如果设备上安装了多个中转站，则第一个安装的中转站始终是活动中转站。 仅单个中介可以在设备上处于活动状态。

已卸载中介时

如果只安装了一个中转站托管应用，并且移除了该应用，则用户需要再次登录。 卸载活动中介会从设备中删除相应的帐户和关联的令牌。

如果 Intune 公司门户已安装并作为活动中介运行，此外还安装了 Microsoft Authenticator，则在卸载 Intune 公司门户（活动中介）后，用户需要再次登录。 用户再次登录后，Microsoft Authenticator 应用就会成为活动代理。

与中介集成

为中介生成重定向 URI

提示

本文中的步骤可能因开始使用的门户而略有不同。

必须注册与中介兼容的重定向 URI。 中介的重定向 URI 应该包含应用的包名称，以及应用签名的 base64 编码表示形式。

重定向 URI 的格式为：msauth://<yourpackagename>/<base64urlencodedsignature>

可以使用 keytool 通过应用的签名密钥生成 Base64 编码的签名哈希，然后使用该哈希生成重定向 URI。

Linux 和 macOS：

keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64

Windows:

keytool -exportcert -alias androiddebugkey -keystore %HOMEPATH%\.android\debug.keystore | openssl sha1 -binary | openssl base64

使用 keytool 生成签名哈希后，请使用 Azure 门户生成重定向 URI：

  1. 至少以云应用程序管理员身份登录到 Microsoft Entra 管理中心。
  2. 如果你有权访问多个租户，请使用顶部菜单中的“设置”图标 ，通过“目录 + 订阅”菜单切换到包含应用注册的租户。
  3. 浏览到“标识”>“应用程序”>“应用注册”。
  4. 选择你的应用程序，然后选择“身份验证”>“添加平台”>“Android”。
  5. 在“配置 Android 应用”窗格打开时，输入你之前生成的“签名哈希”，然后输入“包名称” 。
  6. 选择“配置”按钮。

会为你生成重定向 URI，并将其显示在“Android 配置”窗格的“重定向 URI”字段中。

有关对应用进行签名的详细信息，请参阅 Android Studio 用户指南中的对应用进行签名。

将 MSAL 配置为使用中介

若要在应用中使用中介，必须证明你已配置中介重定向。 例如，通过在 MSAL 配置文件中包含以下设置，来包含中介启用的重定向 URI，并指示已注册该中介：

"redirect_uri" : "<yourbrokerredirecturi>",
"broker_redirect_uri_registered": true

MSAL 通过两种方式来与中介通信：

  • 中介绑定服务
  • Android AccountManager

MSAL 首先使用中介绑定服务，因为调用此服务不需要任何 Android 权限。 如果绑定到绑定服务失败，MSAL 将使用 Android AccountManager API。 仅当已为应用授予 "READ_CONTACTS" 权限时，MSAL 才使用此 API。

如果收到 MsalClientException 和错误代码 "BROKER_BIND_FAILURE"，可以采取两种做法：

  • 要求用户禁用 Microsoft Authenticator 应用和 Intune 公司门户的超级优化。
  • 要求用户授予 "READ_CONTACTS" 权限

验证中转站集成

虽然可能无法立即弄清楚中介集成是否正在运行，但你可以使用以下步骤进行检查：

  1. 在 Android 设备上，使用中介完成某个请求。
  2. 在 Android 设备上的设置中，查找与进行身份验证时所使用的帐户相对应的新建帐户。 该帐户的类型应为“工作帐户”。

如果要重复测试，可以从设置中删除该帐户。

通过系统浏览器的 SSO

Android 应用程序可以选择使用 WEBVIEW、系统浏览器或 Chrome 自定义选项卡进行身份验证用户体验。 如果应用程序未使用中转站身份验证，则需要使用系统浏览器，而不是本机 Webview 来实现 SSO。

授权代理

为授权代理选择特定的策略非常重要，这是应用可以自定义的附加功能。 建议使用“WEBVIEW”。 若要了解有关其他配置值的详细信息，请参阅了解 Android MSAL 配置文件。

MSAL 支持使用 WEBVIEW 或系统浏览器授权。 下图显示了使用 WEBVIEW 或使用包含或不包含自定义标签页的系统浏览器进行授权的大致形式：

MSAL login examples

SSO 影响

如果应用程序使用 WEBVIEW 策略，而不将中转身份验证集成到其应用中，则用户将不会获得跨设备或在本机应用与 Web 应用之间的单一登录体验。

应用可以与 MSAL 集成，以使用 BROWSER 进行授权。 与 WEBVIEW 不同，BROWSER 与默认系统浏览器共享 Cookie jar，可以减少与自定义标签页集成的 Web 应用或其他本机应用中的登录次数。

如果应用程序使用具有中转站（例如 Microsoft Authenticator 或 Intune 公司门户）的 MSAL，并且用户在其中某一个应用中拥有一个有效的登录名，则用户可以获得跨应用程序的 SSO 体验。

注意

具有中转站的 MSAL 利用 WebView，并为使用 MSAL 库和参与中转身份验证的所有应用程序提供单一登录 (SSO)。来自中转站的 SSO 状态不会扩展到不使用 MSAL 的其他应用。

WebView

若要使用应用中 WebView，请在传递给 MSAL 的应用配置 JSON 中添加以下行：

"authorization_user_agent" : "WEBVIEW"

使用应用中 WEBVIEW 时，用户可以直接登录到应用。 令牌保留在应用的沙盒内部，不能在应用 Cookie jar 的外部使用。 因此，除非应用与 Authenticator 或公司门户集成，否则用户无法获得跨应用程序的 SSO 体验。

但是，WEBVIEW 确实提供用于自定义登录 UI 外观的功能。 有关如何进行这种自定义的详细信息，请参阅 Android WebView。

浏览器

尽管我们提供了使用浏览器和自定义选项卡策略的选项，但还是建议使用 WEBVIEW。 可以在自定义配置文件中使用以下 JSON 配置显式指定此策略：

"authorization_user_agent" : "BROWSER"

使用此方法可通过设备的浏览器提供 SSO 体验。 MSAL 使用共享的 Cookie jar，使其他本机应用或 Web 应用能够使用 MSAL 设置的持久会话 Cookie 在设备上实现 SSO。

浏览器选择试探法

由于 MSAL 无法指定可在众多 Android 手机上使用的确切浏览器包，因此 MSAL 实施浏览器选择试探法，以尝试提供最佳的跨设备 SSO。

MSAL 主要从包管理器中检索默认浏览器，并检查它是否在已测试的安全浏览器列表中。 如果不在，MSAL 将退回到使用 Web 视图，而不是从安全列表启动其他非默认浏览器。 始终会选择默认浏览器，无论其是否支持自定义选项卡。 如果浏览器支持自定义选项卡，MSAL 将启动自定义选项卡。自定义标签页的外观更接近应用中 WebView，允许基本的 UI 自定义。 有关详细信息，请参阅 Android 中的自定义标签页。

如果设备上没有浏览器包，MSAL 将使用应用中 WebView。 如果设备默认设置未更改，则每次登录时应启动同一浏览器，以确保提供 SSO 体验。

已测试的浏览器

我们已对以下浏览器进行测试，以确定它们是否可以正确重定向到配置文件中指定的 "redirect_uri"：

设备 内置浏览器 Chrome Opera Microsoft Edge UC 浏览器 Firefox
Nexus 4 (API 17) 通过 通过 不适用 不适用 不适用 不适用
Samsung S7 (API 25) 通过1 通过 通过 通过 失败 pass
Vivo (API 26) 通过 通过 通过 通过 通过 失败
Pixel 2 (API 26) 通过 通过 通过 通过 失败 通过
Oppo pass 不适用2 不适用 不适用 不适用 不适用
OnePlus (API 25) 通过 通过 通过 通过 失败 通过
Nexus (API 28) 通过 通过 通过 通过 失败 通过
MI 通过 通过 通过 通过 失败 通过

1Samsung 的内置浏览器是 Samsung Internet。
2无法在 Oppo 设备设置中更改默认浏览器。

后续步骤

使用适用于 Android 设备的共享设备模式，可以对 Android 设备进行配置，使其可由多名员工轻松共享。