Azure App Service EasyAuth令牌合法性验证方案及POST方式可行性咨询

核心诉求解析 #

你担心EasyAuth被误禁用后应用完全暴露，想要在应用内对请求头中的x-ms-token-aad-id-token和x-ms-token-aad-access-token做二次兜底验证，这个思路非常稳妥——前置认证层虽能处理大部分场景，但应用内的额外验证能补上配置失误的漏洞。

关于POST https://{sitename}/.auth/login/aad的验证方式 #

你提到的这个方法确实是简单可靠的二次验证方案，理由如下：

• 直接复用App Service内置的AAD验证逻辑，不用手写复杂的JWT校验规则（比如签名验证、签发者/受众校验、过期时间检查等），完全借助平台能力完成验证，省心又准确。
• 验证流程直观：将x-ms-token-aad-id-token中的令牌发送至该端点，会返回验证结果（合法用户信息或错误提示），只需判断返回状态码和内容即可确定令牌有效性。
• 这套逻辑与前置认证共用同一配置，不会出现规则不一致的问题，几乎无维护成本。

更轻量化的本地验证方案 #

如果觉得调用内部端点的开销偏大，也可在应用内直接做JWT本地校验，步骤如下：

• 解析x-ms-token-aad-id-token中的JWT，拆分出header、payload和signature。
• 从AAD公开密钥端点动态拉取对应算法的公钥（记得做缓存，避免频繁请求）。
• 重点验证以下关键字段：
  • iss（签发者）：必须与你的AAD租户签发URL一致（例如https://login.microsoftonline.com/{你的租户ID}/v2.0）。
  • aud（受众）：必须是你的App Service对应的客户端ID或应用ID URI。
  • exp（过期时间）：必须晚于当前时间，防止使用过期令牌。
  • nbf（生效时间）：必须早于当前时间。

兜底验证的最佳实践 #

• 前置检查：应用启动时读取环境变量WEBSITE_AUTH_ENABLED，若值不为True，直接拒绝所有未验证请求，从根源堵住EasyAuth被禁用的风险。
• 统一生效：将验证逻辑封装为全局中间件或过滤器，对所有需要保护的接口统一生效，避免重复代码。
• 日志记录：记录验证失败的请求日志，便于后续排查异常（如令牌篡改、EasyAuth被意外关闭等情况）。

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