Handling authorization_error with hosted pages

e.alic · March 9, 2018, 4:48pm

I recently migrated from embedded lock v10 to Auth0 9.2.2 and lock 11.3.1 with hosted pages.

I have a simple rule that validates if a new user has validated their email address and within my customized hosted page I have added per documentation:

lock.on(‘authorization_error’, function (error) {
lock.show({
flashMessage: {
type: ‘error’,
text: error.error_description
}
});
});

Previously when I was using the embedded lock, if a new user tried to log in, the message would flash and inform the user they need to verify their email while still within the lock widget and would not allow them past that point. Now however the user is being redirected back to my client page with the error as part of the response, giving the look and feel as if they logged in properly (because they get past the log in Auth0 widget).

I would like the error message to flash like before and not redirect the user back to the client if there is any kind of authorization_error. Is this not possible?

sonnh · September 20, 2018, 2:22pm

I also experiencing this problem with lock 11.9.1 and hosted pages. It seems like Auth0 did not support flashing error in hosted page.

Joe_Tillotson · September 26, 2018, 12:19am

Hey @e.alic, did you hear anything back on this or learn anything in subsequent research? I’ve always felt that the inability to take the user back directly to a Host Login Page (HLP) for an authorization error is a real pain and a real weakness of the platform. IOW, being able to fail authentication via a rule would be extremely valuable.

We have updated all of our clients (both Native and web SPA) to properly redirect our users back to our HLP for a set of authorization-related errors (email not verified, email not present (FB) being 2 examples).

Sending the user back to the client (with an authz error), and then having the client send the user (immediately back) to the HLP which then has to properly recognize the error code and respond to it is, like I mentioned above, a huge pain.

marco1 · October 1, 2018, 2:40am

Thanks for your input , I’m currently testing the auth0 solution and was trying to do the same.

This platform is great but for me being able to stop the login flow and display error message from the hosted page is a basic functionality that should be there. I don’t understand why they don’t offer this yet. …

We don’t control every application (zendesk for exemple) so it’s not possible to display error message or redirect the user in that case

If any one of you have workaround this scenario it will help me a lot

Cheers

Joe_Tillotson · October 2, 2018, 4:29pm

Well, I believe (again, this is just what I believe, not necessarily the ultimate truth) that Auth0’s philosophy on this matter is as follows currently:

If the user cannot authenticate (i.e. their credentials are invalid) then that generates an error that can be handled by a HLP (aka universal login)
If on the other hand, something within subsequent rule processing invalidates the user’s ‘authorization flow’, then this must be returned to the client, and handled by the client.

I am strongly guessing that very early in their history, the architects at Auth0 decided that this was an important distinction that they wanted to maintain.

As we’ve said before, I would find it immensely useful if there was an ability, within a rule, to return a response that would effectively result in a ‘failed authentication’ (e.g. classic case: user has not verified their email address) - so that the HLP would receive the response, not the client.

It is my (very) strong belief however that this is not possible today.

marco1 · October 2, 2018, 6:53pm

Well, for me its a very limited functionality and can compromise security very easily (at least in our current use case)

Current scenario is this :

Auth0 is configure with an Enterprise samlp connection for our staff to login into ZenDesk using our actual SSO provider
ZenDesk is configure as a SSO integration endpoint within auth0
We want external user being able to signup so the signup form is activated
When new user signup they are automatically redirected in Zendesk and a account is being created by ZenDesk
if we force email verification, the user if redirect back to the logout url and the error code is lost as ZenDesk is not aware of it

Even worst, by default if someone else signup with one of our existing SAMLP admin email address, the user is redirect in ZenDesk with full administrative privilege

My understanding is that with non-hosted page I could change the response type to token and handle all the redirection from there and show custom error message… But the goal was to used the hosted page and get rid of hosting our own login page

For now, I can probably blacklist our staff domain apart if use from the samlp provider and block the authentication without any error displayed, which sound like a bit nasty but will probably work until we put in place our own login page or have Auth0 offer that feature.

I understand that they dont want to break current customer behavior, but its as simple as adding a global settings flag at the tenant level that will make our rule block the authentication flow and return to the login page and display our error message properyly

Did I miss something as I’m new to Auth0 ?

Thanks in advance

marco1 · October 2, 2018, 6:59pm

Any feedback from auth0 will be very helpful as well

@James.Morrison any thought ?

James.Morrison · October 2, 2018, 8:43pm

Hey there @e.alic, @sonnh, @Joe_Tillotson, and @marco1! Let me see what I can find out for you. Thanks!

James.Morrison · October 2, 2018, 9:59pm

After talking with our support team, we recommend for the cases where the errors can’t be handled (e.g. such as redirecting to a 3rd party application after the login step) you may want to consider the redirection option.

You can also build a server (e.g. with Webtask) and provide a UI for the user with the error message they need to show.

Please let me know if you this helps answer your questions or if you have additional questions I may be able to help with!

marco1 · October 3, 2018, 5:55pm

Hi James,

Thanks for coming back to us

The redirect part is indeed interesting … I will used this to redirect the user in our website

I still dont understand why Auth0 hesitate to support the display of custom error message from the hosted login page. For me this is a common feature that lots of people will need. Pushing this responsibility (logic) to every underlying application is weird and error prone for most of the use case without mentioning all the synchronisation require to upgrade those app when the logic should be adjusted.

Is it something you guys plan in the future ? If not can you guys elaborate on this design choice ?

Again thanks for your time, really appreciated

andres.aguiar · October 8, 2018, 10:24pm

Hi,

The way OIDC works is by redirecting users to a page where they are authenticated, and in case there is an unexpected error in the authentication process, forward it to the callback URL so the application can handle it.

In the Auth0 server, rules are run after the user is authenticated, so it’s not possible for us to display errors in the login dialog itself (e.g. you could enter username/password, get prompted MFA, and then get an error from a rule), so those errors are sent to the application.

That said, there are some specific scenarios like email-validation that Auth0 could handle better. Instead of creating a rule for it, we could have a ‘required validated emails’ toggle that will prevent users with unvalidated emails to log-in, show a specific screen as part of the authentication flow telling you that the email is not validated and giving you the option of sending the email again. This is something we are discussing but haven’t prioritized yet.

We could also have a generic ‘error handling’ step in the flow that could display the message and send you back to the login page, but we’d prefer to better understand customer scenarios and see if we can provide a better experience. For example, if we did this for email verification, the end-user will not be able to get the email sent again.

If you have other concrete scenarios where you see this need we’d love to hear about them.

Thanks

Andres

zatziky · November 3, 2018, 8:48pm

Here’s how we solved the redirection in our case.

Frontend
After an error happens in Auth0 rules, it redirects to our frontend. We catch the error and immediately login again providing an errorMessage.

login('error message')

function login(errorMessage = null) {
    if (!errorMessage) {
      this.auth0.authorize()
      return
    }

    this.auth0.authorize({
      authParamsMap: {errorMessage}
    })
  }

Hosted Login Page

    if(errorMessage){        
        lock.show({
          flashMessage:{
           type: 'error',
           text: errorMessage
          }
        });      
    } else {
      lock.show();
    }
  </script>
</body>
</html>

Joe_Tillotson · November 7, 2018, 6:24pm

“If you have other concrete scenarios where you see this need we’d love to hear about them.”

Thank you for your reply on this topic. I can contribute perhaps a few ideas. We currently handle any ‘authentication blocking scenarios’ like user “zatziky” is highlighting below:

our rules return a specific error code (e.g. “email_not_verified”)
all of our clients (apps) look for these specific error codes, and if found…
… take user back to our HLP, passing this error code as a CGI param

At this point, our HLP displays a helpful message to the user (i.e. “Your email has not been verified. Please click here to re-send an email allowing you to verify…”)

While this works, it is a real pain for all of our 10+ applications (web, Android, iOS) to perform this action correctly. If our company had just one app, I probably wouldn’t care much about this issue.

So while I understand that ‘how Auth0 works today’ is heavily influenced by the general design of OIDC grant types (flows), it would be a great differentiator if Auth0 did provide a way for specific error scenarios to return immediately to a central (hosted) web page, rather than first requiring a trip back to the app/client callback.

Here is my list of what we have to support today, in order of ‘typical-ness’:

User’s email is not verified (we treat these users as nobodies)
User’s social account does not have an email address (e.g. Facebook account)
The authorization service is not available - good example of this: when the Auth0 authorization extension times out. In this case, we can’t get the user’s roles & permissions, so we want the user to try logging in again

system · December 7, 2018, 6:24pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.