如何确保应用托管方无法访问合作方Azure SQL Server数据库并完成身份认证？

针对你的需求，完全可以在Azure环境中构建一套托管方无权限访问合作方敏感数据的身份认证与数据访问方案，结合OAuth 2.0 Token Introspection和Azure原生服务即可实现，核心思路是让合作方完全掌控身份认证与数据库权限，托管方仅做请求转发与合法性验证。

核心架构设计 #

1. 身份认证流转：合作方自主掌控IDP #

• 合作方使用自身的Azure AD作为身份提供商（IDP），用户访问托管Web应用时，应用引导用户跳转到合作方Azure AD完成登录授权，获取两个关键令牌：
  • ID Token：仅用于托管应用验证用户身份合法性，不包含数据库访问权限；
  • Access Token：由合作方Azure AD签发，受众（aud）限定为其自有Azure SQL Server，且仅授予必要的数据库查询权限（如db_datareader）。
• 托管应用全程不存储合作方Azure AD的任何密钥，仅作为OAuth 2.0授权码流程的代理，不参与令牌的签发与权限配置。

2. OAuth 2.0 Token Introspection的Azure落地 #

• 合作方Azure AD原生支持Token Introspection端点（可通过Azure AD应用注册配置启用），托管应用在收到用户请求后，调用该端点验证Access Token的有效性：
  • 验证令牌是否未过期、签名合法、受众与权限范围符合要求；
  • 若使用加密JWT（JWE），托管应用无法解密令牌内容，仅能通过Introspection确认合法性，彻底避免获取合作方的权限细节或敏感信息。
• 极简API实现：可通过Azure Functions或**Azure API Management（APIM）**搭建轻量级验证层，专门处理Token Introspection请求，与主Web应用解耦，降低维护复杂度。

3. Azure SQL Server的权限隔离配置 #

• 合作方需为其Azure SQL Server启用Azure AD身份验证，并将授权用户/安全组添加为数据库用户，分配最小必要的查询权限；
• 托管应用转发数据库请求时，将用户的Access Token作为身份凭据，使用Active Directory Access Token认证模式连接SQL Server：
  • SQL Server直接与合作方Azure AD验证令牌合法性，无需托管应用提供用户名密码；
  • 托管应用全程无法获取数据库的访问权限，仅能转发合法用户的请求。

关键安全保障 #

• 零知识访问：托管方无法接触合作方的数据库凭据、令牌明文内容，仅能验证请求合法性；
• 权限最小化：合作方签发的Access Token仅包含访问自身数据库的必要权限，且有效期短，降低泄露风险；
• 可审计性：合作方可通过Azure AD日志、SQL Server审计日志监控所有访问请求，确保数据访问全程可追溯。

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