Azure AD B2C 在客户端凭据的 /oauth2/v2.0/token 端点中缺少随机数

Question

I have an API which is using Azure AD B2C for authentication and on success returning access_token . Request is as follows:

POST /{tenant}/oauth2/v2.0/token        
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id={client-id}
&scope=https://{tenant}/{app_id}/.default
&client_secret=sampleCredentia1s
&grant_type=client_credentials

But when I pass nonce as a query parameter, it is not returning in JWT token. Can you please share how to return a nonce in access_token for validating token against token replay attacks?

Answer 1

• You are right that the nonce is a strategy used to mitigate token replay attacks. Your application can specify a nonce in an authorization request by using the nonce query parameter. The value you provide in the request is emitted unmodified in the nonce claim of an ID token only. This claim allows your application to verify the value against the value specified on the request. Your application should perform this validation during the ID token validation process. Thus, the nonce value is typically a randomized, unique string that can be used to identify the origin of the request.

• Also, the nonce will be returned in the id_token and you can validate it when you decode and validate the id_token. But state is returned in the response, not in the token. Also, nonce should be validated at the client side. Please note that the generated nonce must be persisted in your web application using any of the following methods, ie, HttpOnly session cookie and HTML5 local storage value.

 Example --> ‘ window.localStorage.setItem('nonce', randomString(16)); ‘

The nonce parameter value needs to include per-session state and be unguessable to attackers. To achieve this for Web Server Clients, you need to store a cryptographically random value as an HttpOnly session cookie and use a cryptographic hash of the value as the nonce parameter. In that case, the nonce in the returned ID Token is compared to the hash of the session cookie to detect ID Token replay by third parties. A related method applicable to JavaScript Clients is to store the cryptographically random value in HTML5 local storage and use a cryptographic hash of this value shown as above.

• For validating the ID_token, find the below parameters passed in the application where the token must be validated and decoded as usual. Its nonce claim must contain the exact same value that was sent in the request: -

      ‘ var jwt = '...'; // validated and decoded ID Token body
       if (jwt.nonce === window.localStorage.getItem('nonce')) {
              // Nonce is OK
        } else {
         // Nonce is not OK! Token replay attack might be underway
       } ‘

Please find the below example of the implicit flow containing nonce and state as a parameter of the request that would be sent by the user to the Authorization Server in response to a corresponding HTTP 302 redirect response by the Client: -

    ‘ GET /authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj HTTP/1.1
    Host: server.example.com ‘

Also, find the below example of the authorization request sent in the browser URL using nonce as a parameter: -

  ‘ https://${yourDomain}/oauth2/default/v1/authorize?client_id=0oabv6kx4qq6
     h1U5l0h7&response_type=id_token 
      token&scope=openid&redirect_uri=https%3A%2F%2Fwww.example.com&state=state- 
      296bc9a0-a2a2-4a57-be1a-d0e2fd9bb601&nonce=foo ‘