在OAuth 2.0隐式流程中应在哪里验证随机数？

Question

我有以下架构。

哪里：

• 客户端-是单页JavaScript应用程序。
• 授权服务器-是Azure AD。
• 资源服务器-是使用Azure AD身份验证的Azure应用服务。
• 所有通信均使用HTTPS保护。

我正在使用隐式流从Azure AD访问JWT访问令牌。

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%2Flocalhost%2Fmyapp%2F
&scope=openid%20https%3A%2F%2Fgraph.microsoft.com%2Fmail.read
&response_mode=fragment
&state=12345
&nonce=678910

然后，此JWT令牌将作为承载授权传递到资源服务器。同一令牌可以在到期之前多次重用。

作为Authorize请求的一部分，我传递了state和一个nonce值。

目前，我使用简单的JavaScript验证客户端上的状态if：

function isValid() {
    if (token.state !== expectedState) {
        return false;
    }

    ...
}

如果我正确理解，nonce是为了防止重放攻击-我认为这意味着针对资源服务器，也可能针对客户端。

我不确定应该在哪里（或是否）验证随机数。

在服务器上看起来不正确，整个令牌都在验证中，并且令牌可以重用（在其有效期内）。

在客户端上，这似乎是一个更好的位置，但这与验证状态有什么不同吗？

Answer 1

我不确定应该在哪里（或是否）验证随机数。

当然，您应该验证随机数。因为nonce 是必填项，它将被返回并包含在中id_token。验证时id_token，您只需验证现时声明。使用随机数可以减轻令牌重发攻击（想要使用令牌重发攻击的人不会知道该随机数，因此每个令牌都具有不同的随机数以标识请求的来源）。

对于AAD v2端点的随机数，有明确的解释：

nonce （需要）

应用程序生成id_token的请求中包含的值，该值将作为索赔包含在结果中。然后，该应用可以验证该值以减轻令牌重放攻击。该值通常是一个随机的，唯一的字符串，可用于标识请求的来源。

因此，您只需验证id_token即可验证现时。

但这与验证状态有什么不同吗？

是的，随机数的影响与状态不同。首先，随机数将在中返回id_token，您可以在解码和验证时对其进行验证id_token。但是state在响应中返回，而不是在令牌中返回。而且，state与随机数具有不同的含义和作用。

state （推荐的）

请求中包含的值也将在令牌响应中返回。它可以是您希望的任何内容的字符串。通常使用随机生成的唯一值来防止 跨站点请求伪造攻击。状态还用于在身份验证请求发生之前在应用程序中对有关用户状态的信息进行编码，例如用户所在的页面或视图。

另外，重播攻击与跨站点请求伪造攻击不同。您可以参考有关这两种攻击的更多详细信息。然后，您将了解nonce令牌中为什么存在令牌以及state响应中为什么存在令牌。

是否在客户端验证随机数（令牌）

对于id_token，是的，仅应从客户端进行验证。对于具有隐式流的SPA，我们可以使用ADAL.js来验证nonce，id_token其中包含nonce减轻令牌重播攻击的声明。

希望这可以帮助！