URL variables in redirects and callbacks aren't consistent with use-case.

Help
, ,
1

We have configured a single page in our application to handle the redirects for the following Auth0 scenarios:

  1. New account created, requires email verification
  2. New account confirmed
  3. Forgot password, successfully confirmed new password

Each of those scenarios directs the user to our SSO handler page, which will conditionally display different messaging depending on the URL variable Auth0 sends along in the URL. However, we’re seeing something unexpected. Here are the URL variables that are coming through:

1. New account created, requires email verification

  • emailverification=false

  • useremail=###

  • client=###

  • state=###

2. New account confirmed

  • supportSignUp=true

  • supportForgotPassword=true

  • email=###

  • message=###

  • success=true

3. Forgot password, successfully confirmed new password

  • email=###

  • success=true

  • message=###

Why does the “Forgot password” confirmation URL not include the variable ‘supportForgotPassword=true’ but the New Account Confirmation URL does include that variable?

2

To my knowledge, neither the supportSignUp and supportForgotPassword are documented (at least I could not find anything on those) so the reason they are present may just be due to an implementation detail of that particular endpoint. As a side note, what use case would they unblock if they were indeed present also for the forgot password case?

If you want to provide different treatment depending on what actions the most foolproof way would be to have distinct URL’s in your application to handle the different scenarios. They could use common logic but that logic would be accessed with different URL’s. The reason I suggest this is that based on the information you provided and the fact that the two parameters above are not documented and subject to change then you would no longer be able to distinguish between two of the scenarios if those parameters were no longer passed to you.