MSAL iOS无法复用AccessToken及在WKWebView中共享Cookie问题咨询

以下三种方案均可实现避免WKWebView二次登录的需求，按推荐优先级排序：

方案1：共享MSAL SSO Cookie给WKWebView（最优解，无需适配Web端） #

MSAL完成原生登录后，相关身份认证Cookie默认存储在系统HTTPCookieStorage中，只要让WKWebView和系统共享Cookie池即可直接复用登录状态：

• 初始化WKWebView时按如下配置：

let webConfig = WKWebViewConfiguration()
// 禁用隐私模式，使用全局默认数据存储
webConfig.websiteDataStore = WKWebsiteDataStore.default()
// 提前将MSAL生成的Cookie注入WebView存储
if let allCookies = HTTPCookieStorage.shared.cookies {
    for cookie in allCookies {
        webConfig.websiteDataStore.httpCookieStore.setCookie(cookie)
    }
}
let webView = WKWebView(frame: .zero, configuration: webConfig)

• 唯一要求：Web应用和原生端MSAL的租户、客户端ID、重定向URI配置完全一致，即可直接识别MSAL的SSO Cookie，无需二次登录。

方案2：请求头传递Access Token（需Web端少量适配） #

如果两端身份域不一致无法共享Cookie，可以把原生端MSAL获取到的Access Token注入请求头传递给Web端：

• 加载Web请求时添加Authorization头：

var webRequest = URLRequest(url: URL(string: "你的Web应用访问地址")!)
// 从MSAL缓存中取有效Access Token
if let validToken = msalCurrentAccount.accessToken {
    webRequest.setValue("Bearer \(validToken)", forHTTPHeaderField: "Authorization")
}
webView.load(webRequest)

• 要求Web端适配逻辑：优先读取请求头Authorization字段的Token做身份校验，校验通过后主动生成Web端自身的会话Cookie，后续Web内跳转无需再登录。

方案3：URL参数传递Token（兜底方案，不推荐生产环境用） #

如果Web端不方便修改请求头校验逻辑，可以把Token拼在Web应用访问URL的参数中，Web端加载时读取URL参数的Token完成身份校验、生成会话即可。该方案存在Token泄露风险，仅建议在内网测试场景临时使用。

通用踩坑提示 #

• 不要使用WKWebView的私有数据模式WKWebsiteDataStore.nonPersistent()，该模式下不会持久化存储任何Cookie，每次打开都是全新会话，必然触发二次登录。
• 若Token过期，可直接在原生端调用MSAL的静默刷新接口获取新Token，重新注入WebView即可，不需要用户手动操作。

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