无需修改应用代码的Docker容器Microsoft AD SSO接入方案咨询

完全可以在容器外部通过前置认证代理的方式实现需求，不需要修改原有Spark Java应用的任何代码，这种架构是行业内无侵入改造身份认证的通用方案，以下是具体的免费替代方案：

开箱可用的开源方案 #

• OAuth2 Proxy：这是当前最主流的开源反向代理认证工具，原生适配Azure AD作为身份源，完全免费。部署时你只需将它和原有Web应用放在同一个Docker网络内，所有公网流量先经过OAuth2 Proxy：它会自动完成Azure AD SSO全流程校验，限制只有你指定的租户用户可以登录，认证通过后才会把请求转发给后端Spark应用，还支持自定义HTTP头传递用户身份信息供后端使用。配置仅需三步：在Azure AD注册企业应用、配置租户ID和回调地址、将代理的上游地址指向你的应用容器即可。
• NGINX开源版 + auth_request模块：如果你偏好NGINX作为入口，NGINX开源版自带auth_request模块，无需购买付费解决方案。你可以搭配一个轻量的开源认证服务，也可以自己写简单的认证逻辑：NGINX收到请求后先向认证服务发起身份校验，未登录用户会被自动跳转到Azure AD登录页，校验通过后才会转发流量到后端应用。

轻量自行开发方案 #

如果不想引入第三方工具，也可以自行开发一个极简的认证网关，百行代码级即可实现：

1. 网关作为公网唯一入口，和后端应用同属内部Docker网络，后端应用不暴露公网端口
2. 未携带有效会话Cookie的请求自动重定向到Azure AD授权端点，配置租户参数限制仅你的租户用户可发起授权
3. 拿到Azure AD返回的授权码后兑换ID Token，校验签发方、租户ID等信息无误后种下有效会话Cookie
4. 后续携带有效Cookie的请求直接转发到后端Spark应用，所有认证、会话逻辑全部在网关层处理，后端应用无感知。

额外注意：部署时必须确保原有Web应用仅能通过内部网络被代理层访问，禁止直接对公网暴露端口，避免出现绕过认证的安全漏洞。

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