核心结论 #

在你的单页JavaScript客户端中验证nonce，而且必须是在收到Azure AD返回的id_token之后、使用任何令牌（包括id_token和access_token）之前完成验证。

为什么是客户端验证？ #

Nonce的核心作用是防止重放攻击——因为隐式流直接把令牌通过URL哈希返回给前端，这个过程存在被恶意拦截并重放的风险。nonce是客户端生成的随机唯一值，你把它发给Azure AD后，AD会将其嵌入到id_token的payload里返回给你。客户端验证这个返回的nonce和自己之前生成的一致，就能确认这个令牌是针对当前授权请求的，不是被重放的旧令牌。

具体验证步骤 #

• 第一步：生成并存储Nonce
  在构造你的授权请求URL之前，用浏览器的安全随机数API（比如crypto.randomUUID()）生成一个足够随机的nonce值，然后把它存在客户端的sessionStorage里（别用localStorage，持久化存储会增加重放风险）。

• 第二步：将Nonce加入授权请求
  在你的授权链接里添加nonce参数，比如：

  https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=id_token+token&redirect_uri=http%3A%2F%2Flocalho...&nonce=你的随机值
  

  Azure AD会把这个nonce包含在后续返回的id_token payload中。

• 第三步：接收令牌后验证Nonce
  当Azure AD重定向回你的redirect_uri后，从URL的哈希片段（#后面的部分）提取id_token。解码它的payload（注意：解码只是读取内容，必须同时验证id_token的签名确保令牌未被篡改），取出其中的nonce字段，和你存在sessionStorage里的原始nonce做精确对比。

• 第四步：根据验证结果处理

  • 如果两个nonce完全匹配：可以继续使用id_token（用于身份信息）和access_token（请求资源服务器）。
  • 如果不匹配：立即丢弃所有令牌，终止授权流程——这很可能是重放攻击或恶意请求，不能信任这些令牌。

额外注意事项 #

• 不要在你的Azure App Service资源服务器上验证nonce：资源服务器无法获取客户端最初生成的nonce值，而且nonce的验证是客户端和授权服务器之间的信任环节，和资源服务器无关。
• 生成nonce必须用安全的随机方法：别自己写简单的随机字符串生成逻辑，浏览器的crypto API是最优选择，能保证足够的随机性。
• 验证完成后清除存储的nonce：避免同一个nonce被重复使用，降低攻击风险。

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