绕过Azure B2C重定向URI限制的合规方案探讨

现有方案推荐 #

在你列出的方案中，多应用注册是最符合Azure B2C安全最佳实践的选择：

• 可按域名/站点组划分应用注册，实现权限隔离，降低单应用泄露的影响范围；
• 适配Optimizely CMS的多站点架构，每个站点组可独立配置认证参数，管理逻辑更清晰；
• 虽未减少URI配置总量，但对比通配符URI、自定义流等方案，安全性和可维护性更有保障。

其他方案的局限性：

• State参数：跨顶级域名时会因跨域Cookie限制陷入重定向循环，无法覆盖你的多顶级域名场景；
• 通配符URI：Azure B2C仅支持特定子域名的通配符（如*.example.com/signin-oidc），不允许跨顶级域名的通配符，且大范围通配符会扩大攻击面，官方明确不推荐；
• 自定义认证流封装：大幅增加系统复杂度，引入跨域凭证传递的安全风险，偏离Azure B2C原生设计，后期维护成本极高。

额外可行方案 #

1. 统一认证入口+后端安全重定向 #

只注册一个中心域名的重定向URI（例如auth.yourhubdomain.com/b2c-callback），所有站点的认证流程都指向这个入口：

• 用户从任意站点发起认证请求时，前端将原站点域名加密后存入state参数，或后端通过会话记录原始请求域名；
• Azure B2C认证完成后回调到统一入口，后端解密state中的原域名，校验该域名是否在预先配置的允许列表内；
• 验证通过后，后端将用户重定向回原站点的认证完成页面。
  该方案仅需1个重定向URI即可覆盖所有域名，同时通过加密state和域名白名单避免开放重定向攻击，完全符合安全规范。

2. 同顶级域名分类+子域名通配符URI #

如果你的站点包含多个同顶级域名的子域名，可以针对每个顶级域名注册一个子域名通配符URI（例如*.example.com/signin-oidc、*.anotherdomain.net/signin-oidc）：

• Azure B2C支持这种限定顶级域名的通配符配置，能大幅减少同顶级域名下的URI注册数量；
• 跨顶级域名的站点则结合统一认证入口方案，进一步压缩总URI数量。

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