Azure App Service如何配置浏览器身份验证实现访问管控

你提到的临时浏览器身份验证能力完全可以在Azure生态内实现，不需要改动核心业务代码，以下是4种可直接落地的方案，按推荐优先级排序：

方案1：Azure Front Door 前置管控（零代码改造成本最低） #

• 先将现有App Service的公网直接访问权限关闭，仅允许Azure Front Door的服务标识/官方IP段访问App Service，所有公网流量统一经过Front Door入口
• 内部回归测试阶段，直接在Front Door上开启内置的HTTP Basic身份验证规则，或配置WAF自定义规则：仅携带正确认证凭证、或来源IP属于公司办公网出口段的请求允许转发到后端App Service，其余请求直接返回401未授权
• 内部审批通过需要对公网开放时，直接在Front Door控制台删除身份验证规则、移除IP限制即可，全程不需要重启应用、不需要改动Spartacus代码，切换操作1分钟内生效
• 该方案实现的效果和你预期的浏览器身份验证逻辑完全一致：
  

方案2：App Service 内置Easy Auth临时授权 #

• 基础设施团队提到App Service不支持该能力属于认知偏差，App Service自带的身份验证/授权功能（Easy Auth）完全可以实现需求，不需要额外部署服务
• 开启App Service身份验证，绑定企业现有Azure AD租户，测试阶段配置授权策略：仅被分配了「部署后测试」自定义角色的企业内部账号可以访问站点，所有未授权的请求会被Azure AD直接拦截在应用外层，根本触达不到Spartacus的业务逻辑，哪怕用户持有原业务系统的账号凭证也无法访问
• 测试完成后，直接将授权策略调整为允许匿名访问，或临时关闭Easy Auth即可恢复公网开放，操作无业务侵入性。

该方案适配内部用户统一使用企业AD账号的场景，不需要额外发放独立的访问凭证。

方案3：临时反向代理层做认证 #

• 如果暂时不想调整现有网络架构，可以在同个App Service Plan下部署一个轻量Nginx/Caddy反向代理应用，测试阶段将生产域名临时指向该反向代理，后端转发到原Spartacus应用
• 在反向代理配置中开启HTTP Basic认证，仅给内部测试人员发放账号密码，认证通过才转发请求。以Nginx为例，核心配置仅需3行：

auth_basic "内部测试中，暂未对公网开放";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass https://<your-spartacus-app-service>.azurewebsites.net;

• 测试完成后将生产域名切回原App Service，删除临时反向代理实例即可，全程不改动原有生产应用的配置。

方案4：Spartacus 临时路由守卫 #

• 如果基础设施层调整暂时排不上期，可以直接在Spartacus代码中加一个临时全局路由守卫：测试阶段配置开关打开时，所有路由访问首先触发Basic认证弹窗，前端将凭证提交给后端轻量校验接口，校验通过才允许加载应用内容，校验不通过直接返回403
• 测试完成后删除该临时守卫代码，发布补丁版本即可。

注意：该方案需要搭配App Service层的IP白名单限制，避免公网用户绕过前端校验直接访问后端接口。

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