Invalid Signature Error on jwt.io and in backend

Help
, , , ,
1

I have problem with my application auth token getting from Auth0Lock. If we run following example as index.html on domain http://auth0-test.com (CORS allowed), we get token which gets error on https://jwt.io site. It is also not working on my backend Symfony2 app in firebase/php-jwt/Authentication/JWT.php by line “throw new SignatureInvalidException(‘Signature verification failed’);”

Example is:

<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <base href="/">
  </head>
  <body>
    <script src="https://cdn.auth0.com/js/lock/10.0/lock.js"></script>
    <script>
      var clientId = 'XJYhRRAIWhUnxbzBvE4OB7k9tECNRWaT';
      var domain = 'spheru.eu.auth0.com';                                                                                                                                                                            
      var options = {
        autoclose:      true,
        closable:       true,
        language:       'en',
        auth: {
          redirect:     false,
          params: {
            scope: 'openid user_id email nickname name picture'
          }
        }
      }

      var lock = new Auth0Lock(clientId, domain, options);
      lock.on("authenticated", function(authResult) {
        alert(authResult.idToken);
        console.log(authResult.idToken);
      });
      lock.show();
    </script>
  </body>
</html>

Have You any idea what can be problem? Maybe I have something wrong on my settings?

2

I think we are having the same issue (New Client but token validation fails in PHP SDK - Auth0 Community). If you find the answer to your situation please let me know.

3

No, I think that no. If I understand correctly, your token was valid in jwt.io but your backend does not verified them correctly. I may not touch backend at all in my example - only frontend app using Auth0Lock with some my client settings (maybe wrong) generates invalid token! WHY?

4

Assuming you’re using HS256 as the JWT signature algorithm then this may indeed have a similar root cause to the question linked in the comments. The use of HS256 implies that the token is validated using the client secret associated with the client application.

The way the client secret was issued and provided to developers has changed within Auth0 sometime ago, more specifically, the client secret used to be Base64Url encoded and delivered to you with that encoding. This meant that in order to be used for validation the secret would need to be decoded first (some libraries assumed this encoding and did the decoding automatically while others didn’t so the right way to pass to the library depends on the library itself).

Currently, the client secret generated for new clients is no longer provided to you in Base64Url encoding so depending on the client application and validation library you need to take this under consideration. When you access your client application settings in the Dashboard, below the client secret field you’ll receive an indication if the secret is being provided to you encoded or nor encoded.

The jwt.io tool supports receiving secrets encoded or not encoded so when you try to validate an HS256 token with this tool be sure to check/uncheck the available checkbox as applicable. If by toggling that configuration checkbox you’re able to validate the token then you need to apply the same kind of configuration to your backend depending on your library.

If you can’t modify the backend configuration then you may have a problem. You can for an existing client application that currently has a Base64Url encoded secret rotate/generate a new one that will not be encoded. However, if your library expects an encoded secret and you currently don’t have one then this would require at least a configuration change in the backend in order to provide an encoded version of the current secret.

5

Hello,

Thank a lot for full detailed explanation. I have changed some in my backend and now it is working :slight_smile: