Mitigate replay attacks when using the Implicit Grant

Heads up! As part of our efforts to improve security and standards-based interoperability, we have implemented several new features in our authentication flows and made changes to existing ones. For an overview of these changes, and details on how you adopt them, refer to Introducing OIDC Conformant Authentication.

When using the Implicit Grant, a cryptographic nonce must be sent on authentication requests in order to mitigate replay attacks as required by the OpenID Connect specification. The nonce is generated by the client, sent as a nonce query string parameter in the authentication request, and included in the ID token response from Auth0. This allows clients to correlate the ID token response from Auth0 with the initial authentication request.

Generate a cryptographically random nonce

Modern browsers can use the Web Crypto API to generate cryptographically secure random strings for use as nonces.

function randomString(length) {
    var bytes = new Uint8Array(length);
    var random = window.crypto.getRandomValues(bytes);
    var result = [];
    var charset = '0123456789ABCDEFGHIJKLMNOPQRSTUVXYZabcdefghijklmnopqrstuvwxyz-._~'
    random.forEach(function (c) {
        result.push(charset[c % charset.length]);
    return result.join('');

Persist nonces across requests

The generated nonce must be persisted in your web application using any of the following methods:

  • HttpOnly session cookie
  • HTML5 local storage value

For example:

window.localStorage.setItem('nonce', randomString(16));

Validate the ID token

Once Auth0 responds with an ID token, this token must be validated and decoded as usual. Its nonce claim must contain the exact same value that was sent in the request. If not, authentication should be rejected by the application.

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