iframe场景下angular-oauth2-oidc访问sessionStorage报DOMException问题

1. angular-oauth2-oidc 是否默认内置使用sessionStorage #

是。该包初始化OAuthService时，默认的存储实现就是sessionStorage，这也是移除自身业务所有sessionStorage调用后依然报错的根因——报错来自包内部的默认存储工厂逻辑，和业务代码无关，错误栈中createDefaultStorage的调用记录可以直接对应这个默认逻辑。
当页面被放在iframe中加载、且浏览器开启第三方Cookie/存储拦截（当前Chrome、Safari等主流浏览器默认都会开启第三方上下文存储限制）时，iframe内的页面对sessionStorage/localStorage的访问会被直接拒绝，就会抛出你看到的DOMException。

2. 第三方Cookie被拦截场景下的可行解决方案 #

不需要要求用户手动放开浏览器权限，可按实现优先级选择以下落地方案：

• 自定义存储实现替换默认sessionStorage
  初始化OAuthModule时，跳过默认的storage配置，自行实现带访问能力检测的存储类，检测到存储访问被拦截时自动降级到内存存储。参考实现：

  import { OAuthStorage } from 'angular-oauth2-oidc';
  
  export class SafeOauthStorage implements OAuthStorage {
    private memoryStore = new Map<string, string>();
    private get availableStorage(): Storage | null {
      try {
        // 提前检测当前上下文是否有sessionStorage访问权限
        const testKey = '__oauth_storage_probe__';
        window.sessionStorage.setItem(testKey, '1');
        window.sessionStorage.removeItem(testKey);
        return window.sessionStorage;
      } catch (e) {
        // 访问被拦截时返回null，降级走内存存储
        return null;
      }
    }
  
    getItem(key: string): string | null {
      return this.availableStorage ? this.availableStorage.getItem(key) : (this.memoryStore.get(key) ?? null);
    }
  
    setItem(key: string, value: string): void {
      this.availableStorage ? this.availableStorage.setItem(key, value) : this.memoryStore.set(key, value);
    }
  
    removeItem(key: string): void {
      this.availableStorage ? this.availableStorage.removeItem(key) : this.memoryStore.delete(key);
    }
  }
  
  // 模块初始化时替换默认存储提供者
  @NgModule({
    imports: [
      OAuthModule.forRoot({
        resourceServer: {
          allowedUrls: ['你的业务后端接口前缀'],
          sendAccessToken: true
        }
      })
    ],
    providers: [
      { provide: OAuthStorage, useClass: SafeOauthStorage }
    ]
  })
  export class AuthModule {}
  

  注意：纯内存存储的局限是iframe刷新后认证状态会丢失，如果你的场景允许iframe刷新后重新走静默认证流程，这个方案实现成本最低。
• 认证链路全走同域代理
  改用授权码模式+PKCE流程，把所有IdP（身份提供方）的认证回调、token刷新接口都通过同域服务代理转发，让所有认证相关的请求、存储访问都落在第一方上下文下，从根本上避开第三方存储限制，是稳定性最高的方案。
• 认证逻辑上移到顶层父窗口
  如果父窗口是可控的第一方页面，不要在iframe内承载完整认证逻辑，需要认证时通过postMessage通知顶层父窗口发起认证，认证完成后再把token通过安全的跨文档消息传递给iframe，iframe本身不做任何认证存储、跳转操作，所有认证状态由顶层第一方上下文统一维护。

注意：不要尝试直接用localStorage替换默认的sessionStorage，第三方上下文下localStorage的访问权限和sessionStorage完全一致，同样会被浏览器拦截，替换后依然会报相同的访问拒绝错误。

内容的提问来源于stack exchange，提问作者Harish Kumar Gupta