Auth0.js: Using leeway breaks Universal Login with Custom Login Form

[kengreeff]

We are using the auth0/omniauth-auth0 gem to validate rails users. This gem adds a default leeway of 60 seconds.

All url params are strings which causes the js to crash:

leeway: "60"
nonce: "NONCE"
protocol: "oauth2"
response_type: "code"
scope: "openid profile email offline_access"
state: "STATE"
_csrf: CSRF"
_intstate: "deprecated"

with the following warning:

assert.js:6 Uncaught Error: leeway is not valid
    at attribute (assert.js:6)
    at Object.check (assert.js:33)
    at new WebAuth (index.js:44)

leeway is checked using the following code:

leeway: {
  optional: true,
  type: 'number',
  message: 'leeway is not valid'
},

This fails as the type of leeway is string, and not number.

[stevehobbsdev]

@kengreeff Thanks for raising and apologies for the delay. The library validation is correct in that leeway _should_ be a number as it's typically a value in seconds.

Can you tell me more about the relationship between the bits that are using omniauth-auth0 and auth0.js? The leeway param is something that's passed in, so it sounds like if you have a leeway that is a string, it should be converted to a number before setting it as an option. But I feel like I'm missing a bit of context here.

[kengreeff]

@stevehobbsdev the leeway param is passed through in the query string from what I can see. As far as I know all query params are always strings, unless you explicitly coerce them in to other types

[kengreeff]

We are not setting the leeway param and it is defaulting to the 60 seconds as per the omniauth-auth0 gem. If you check that code you will see it is set as a number.

Thanks for your assistance :)

[stevehobbsdev]

@kengreeff Thanks for the additional context.

There is nowhere within Auth0.js that reads the leeway value from the querystring, it must be passed in through the options object as described in the initialization section of the readme. I just have a couple more questions to try and piece together what you are working with (even better would be if you can send us a very small reproducable sample that demonstrates this problem):

• Can you show us how you are initializing Auth0.js?
• Can you describe the journey between whatever is using the Omniauth gem to whatever is using the Auth0.js library?
• Are you using the Classic Login Experience, possibly with a custom template?
• Are you using any custom Rules?

[kengreeff]

Hi @stevehobbsdev we are just visiting the auth route that omnniauth provides. It initializes the request phase and redirects to the auth0 domain.

From my knowledge params are passed using url encoded form params. Your docs ask to make requests like this also.

When we land on the auth0 login screen (custom template which works with the auth0 react which is missing the leeway param) - it crashes due to the failed assertion.

Tenant is realbase-dev if that helps you find out more detail.

[kengreeff]

Maybe the bug is in the default custom template provided in auth0, as that is where the js is initialized.

But it would probably be a good idea to coerce leeway in to a number in the js library anyway?

[stevehobbsdev]

Thanks. I'm unable to reproduce what you're seeing using my own tenant. I have reached out to your account manager to request the custom template that you're using and more information about your tenant to investigate further.

Another question - I would assume you get the same issue if you just manually tack on the leeway value into the querystring as opposed to getting your Ruby app to set it for you?

But it would probably be a good idea to coerce leeway in to a number in the js library anyway?

We wouldn't like to make any assumptions about the data you're passing in. The library expects a numeric value, so one should be supplied.

[kengreeff]

Ok, looks like this is a problem caused by the Custom Login Form template provided by Auth0 in the universal login screen.

var config = JSON.parse(
  decodeURIComponent(escape(window.atob('@@config@@')))
);

var params = Object.assign({
  overrides: {
    __tenant: config.auth0Tenant,
    __token_issuer: config.authorizationServer.issuer
  },
  domain: config.auth0Domain,
  clientID: config.clientID,
  redirectUri: config.callbackURL,
  responseType: 'code'
}, config.internalOptions);

The config.internalOptions contains the leeway param supplied in the URL and it is a string:

{
  leeway: "60"
  nonce: "a103cf257....."
  protocol: "oauth2"
  response_type: "code"
  scope: "openid profile email offline_access"
  state: "g6Fo2SAtTlVRSlZOWTR5....."
  _csrf: "k2PDEiHB...."
  _intstate: "deprecated"
}

This is merged with the options and passed in to the library here:

var webAuth = new auth0.WebAuth(params);

So I guess the template code could be updated to handle this, or force leeway to be an integer in the library.

[stevehobbsdev]

@kengreeff Right, now that I see you're using the Custom Login Form template, as opposed to the Lock template, I can reproduce the issue - apologies for the confusion.

We will update the template. I've used the following code, if you'd like to make the same change on your template before we merge the changes.

This can go before the var params = Object.assign({.. call (on line 112 if you're using the default unmodified template):

var leeway = config.internalOptions.leeway;
if (leeway) {
  var convertedLeeway = parseInt(leeway);

  if (!isNaN(convertedLeeway)) {
    config.internalOptions.leeway = convertedLeeway;
  }
}

I'll provide an update shortly about the template update.

_Edit: updated the template slightly_

[stevehobbsdev]

I have raised a request to update the template with the above change, and will hopefully soon be merged.

Closing this for now but will report back once the templates are live. In the meantime, please integrate the above change into your copy of the template as described.

[kengreeff]

Thanks @stevehobbsdev - we are back in action!

[stevehobbsdev]

@kengreeff Perfect! I can report that changes to the default template have been merged now too.