Auth0.js: redirectUri not respected in hosted login page for some WebAuth methods

[javiercejudo]

The redirectUri option is not respected in the hosted login page for WebAuth.prototype.login and WebAuth.prototype.passwordlessLogin

What was the expected behavior?

redirectUri option should be used regardless of whether using the hosted login page. This is already the case if not using the hosted login page, meaning it works ok for the else branch here:

https://github.com/auth0/auth0.js/blob/v9.16.0/src/web-auth/index.js#L843-L849

Reproduction

Given an SPA application with the classic Universal Login experience

1. Create a WebAuth client

// auth0Config is the usual JSON.parse(decodeURIComponent(escape(window.atob('@@config@@'))))

const webAuth = new auth0.WebAuth(
  Object.assign(
    {
      overrides: {
        __tenant: auth0Config.auth0Tenant,
        __token_issuer: auth0Config.authorizationServer.issuer,
      },
      domain: auth0Config.auth0Domain,
      clientID: auth0Config.clientID,
      redirectUri: auth0Config.callbackURL,
      responseType: auth0Config.extraParams.response_type,
    },
    auth0Config.internalOptions
  )
)

1. Send a login request with its own redirectUri option

webAuth.login(
  {
    realm: auth0Config.connection,
    username: '[email protected]',
    password: 'fake-password',
    // the below option should be used, but it is not in hosted login pages
    redirectUri: 'https://example.com/callback-url',
  },
  err => { /* error handling code */ }
)

The same issue applies for passwordlessLogin:

webAuth.passwordlessLogin(
  {
    connection: 'email',
    email: '[email protected]',
    verificationCode: '1234',
    // the below option should be used, but it is not in hosted login pages
    redirectUri: 'https://example.com/callback-url',
  },
  err => { /* error handling code */ }
)

Environment

• Version of Auth0.js used: 9.16.0
• Which browsers have you tested in?: Chrome
• Other modules/plugins/libraries that might be involved: N/A

[stevehobbsdev]

Thanks @javiercejudo for your patience here. Just wanted to let you know I can reproduce what you're seeing. Let me report back once I've debugged this further.

[stevehobbsdev]

Thanks once again for your patience. After playing around with this for a bit I believe it's a server-side issue. Because it's running inside the ULP, the ULP takes whatever is passed to the /authorize endpoint as it's redirect URL and effectively ignores what is sent to /usernamepassword/login. This is consistent with how the ULP works generally, but I agree it's a bit odd.

I have raised an issue internally with the appropriate team to confirm that's the expected behaviour, but in the meantime to ensure you redirect correctly in all cases, the right redirect URI should be specified when redirecting to the hosted login page.

I will update here when I hear back from the internal team.

[pbazydlo]

hey @stevehobbsdev that's exactly the issue we're seeing on our side as well. We can't do it at the point of calling /authorize, because that would change the entire login flow for us (some parameters for callback are provided as part of login)

[stevehobbsdev]

Thanks @pbazydlo. I've raised this with the appropriate server team to see whether it's a bug or is the intended behaviour, will let you know once I know more.

[stevehobbsdev]

👋🏻 I've gotten a response back from the server team around this issue and I'm sorry to be the bearer of bad news, but the issue you're experiencing is entirely expected.

Essentially the server respects the values for not just redirect_uri, but also for other things like scope and audience that are passed to the authorization endpoint, and not to be changed mid-flow. It's also a tricky one to mitigate as you're able to pass in arbitrary values to /usernamepassword/login for the benefit of the rules engine.

Trying to change the actual redirect URI mid flow in this way is unfortunately not a supported scenario.

@pbazydlo As this looks to affect you rather deeply, from an architecture standpoint I would reach out to your technical account manager (if you have one) or reach out to our community forums who may be able to help you with your use case.