iOS13/14下MSAL认证后WKWebView/SFSafariViewController如何实现SSO免二次验证

核心问题根因 #

出现二次验证本质是被系统的Web存储隔离机制卡了：

• 你当前用webViewParamaters?.webviewType = .authenticationSession配置走的ASWebAuthenticationSession，有独立的存储上下文：iOS15之前它的存储完全独立，既不和Safari共享，也不和SFSafariViewController、自定义WKWebView互通；iOS13之后如果没手动开prefersEphemeralWebBrowserSession，iOS15及以上版本才会把它的存储和系统Safari打通，但依然跟你自己实例化的自定义WKWebView存储不互通
• 你App本地存的access token是给后端API接口做鉴权用的，Web站点本身的登录校验逻辑认的是自己域下下发的会话Cookie，根本不会读取你App本地存的这个令牌

可落地的无二次验证实现方案 #

• 统一Web组件的存储域（维护成本最低）
  把后续打开同MSAL托管站点的组件，换成和认证流程同存储上下文的组件：
  • 不需要额外做认证逻辑，直接用ASWebAuthenticationSession的普通网页加载能力打开目标站点，它会自动携带之前MSAL认证时存下的共享Cookie，直接跳过登录页
  • 如果必须用WKWebView承载页面，初始化时必须绑定WKWebsiteDataStore.default()持久化存储，不要用.nonPersistent()隔离存储，也不要给WKWebView配置独立的processPool——但要注意，这种配置下的存储和ASWebAuthenticationSession的存储不互通，之前认证时存的Cookie不会自动同步过来，需要做一次手动Cookie注入
• 手动同步认证Cookie到自定义Web组件
  如果你必须保留现有WKWebView/SFSafariViewController的组件逻辑，可以在Web组件发起首次加载前完成Cookie同步：
  • 从系统默认的Cookie存储中，匹配目标MSAL站点域下的所有会话Cookie（一般是ESTSAUTH*、.AspNetCore.Cookies、.MSALShared这类和微软认证相关的键）
  • 把匹配到的Cookie逐个通过WKHTTPCookieStore.setCookie()注入到你自己的WKWebView对应的存储中，等所有Cookie写入完成再加载目标站点URL
  • 注意：不要直接把拿到的access token塞进Cookie或者URL参数里，MSAL托管的站点不会识别这种传参方式的认证状态，还可能触发安全拦截
• 触发Web端静默授权
  如果目标Web站点本身也接入了同一套MSAL应用配置，可以在加载站点URL时追加prompt=none查询参数，站点收到请求后会基于自身域下的现有认证状态静默完成登录，不会弹出登录页——但这个方案的前提是Web组件的存储里已经有有效的会话Cookie，不然还是会跳转回完整登录页

常见踩坑点 #

• 如果之前MSAL认证时手动设置了prefersEphemeralWebBrowserSession = true，那认证过程产生的Cookie根本不会持久化到共享存储，不管换什么Web组件都要重新登录，这种情况只能在打开目标站点时补走一次完整的静默认证流
• 不要尝试给SFSafariViewController做自定义Cookie注入，它的存储是和当前App沙箱隔离的，没有公开API可以写入自定义Cookie
• 不同processPool下的WKWebView哪怕绑定同一个WKWebsiteDataStore，存储也是完全隔离的，跨pool通信同步Cookie的成本极高，不建议使用

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