Android应用集成MSAL、Keycloak与Azure AD实现共享设备模式SSO求助

方案1：Azure AD认证后通过Keycloak令牌交换获取合法令牌（优先推荐） #

这是最贴合需求的方案，既利用MSAL实现Authenticator共享设备SSO，又保留后端Keycloak令牌验证逻辑：

• 配置Keycloak信任Azure AD：在Keycloak后台添加Azure AD为OIDC类型的身份提供商，配置Azure租户ID、客户端ID、密钥等信息，确保Keycloak能验证Azure颁发的令牌合法性。
• MSAL完成Azure AD认证：应用中正常使用MSAL对接Azure AD，完成认证后获取Azure的id_token和access_token。
• 调用Keycloak令牌交换接口：向Keycloak的/realms/{realm}/protocol/openid-connect/token端点发起请求，参数设置：
  • grant_type = urn:ietf:params:oauth:grant-type:token-exchange
  • subject_token = 从MSAL获取的Azure id_token
  • subject_token_type = urn:ietf:params:oauth:token-type:id_token
  • 同时带上Keycloak客户端的认证信息（客户端ID+密钥，或客户端断言）
• 接口返回Keycloak的access_token和refresh_token，后续接口请求直接使用这些令牌，完全符合后端验证机制。
• 优势：无需跳转Keycloak页面，全程API交互，用户体验流畅；避开MSAL无法对接Keycloak的限制，同时满足Authenticator SSO要求。

方案2：强制MSAL使用系统浏览器（仅特殊场景） #

如果必须保留系统浏览器认证方式，可调整MSAL的浏览器策略：

• 在MSAL的AuthenticationRequestParameters中设置browserLaunchMode为BROWSER_LAUNCH_MODE_SYSTEM，或在PublicClientApplication的配置中指定系统浏览器的包名，强制绕过Authenticator的WebView代理。
• 注意：此方法可能削弱Authenticator的共享设备SSO能力，因为Authenticator依赖自身的认证会话管理，需充分测试兼容性。

方案3：Keycloak作为Azure AD代理（复杂度较高） #

将Keycloak作为统一认证入口，配置其使用Azure AD作为身份提供商，同时适配Authenticator的移动SSO：

• 在Keycloak中启用OIDC客户端的mobile特性，配置正确的重定向URI、应用包名和签名哈希，让Authenticator能识别并拦截Keycloak的认证请求。
• 此方案需调整前端认证流程，可能需要结合AppAuth和MSAL，复杂度较高，仅在方案1无法实施时考虑。

内容的提问来源于stack exchange，提问作者gworky