Can I show errors raised in rules in the login page?

Knowledge Articles
1

Question: Can I show errors raised in rules in the login page?

Sometimes you have a rule that denies authorization, like this:

function (user, context, callback) {
  if (someCondition) {
    return callback(new UnauthorizedError('You are now allowed.'));
  }
  return callback(null, user, context);
]

Can that error be displayed in the login window?

Answer: No (how’s that for a spoiler?)

At least at the time of writing this, by the time rules run the authentication step (which is the responsibility of the login page) already happened. Which means that any attempt of going back to the login page would be fighting the natural flow.

Any error you raise in rules is an error that will go back to the application, to the callback URL. If the application requested the authentication using SAML, it will receive a SAML response with the error. If the application used OIDC/OAuth2 (as in all of our quickstarts) it will receive an error in the standard OAuth2 way, with an error and error_description result values.

Say your callback URL is https://myapp.com/callback and you are using the standard response mode of query, you’d get:

https://myapp.com/callback?error=access_denied&error_description=[The message you put in the error]

It’s the application the one in charge of showing that error to the user, like:

There was an error processing your login: [The error message goes here]. Click here to try again.

Retrying

The “Click here to try again” requires a close look. If you are using the default session configuration and your application requests a new authorization to Auth0, Auth0 will already know who the user is, so the login page will not be presented by default and rules will execute right away. Unless the circumstances changed somehow, it is likely that the rule will deny authorization again.

So, if your app just makes a new authorization/authentication request, it is likely that you’ll end up in a meaningless loop (with or without pausing to show the error to the user).

So, what’s an application to do? After ideally explaining to the user what can be done to fix the error, the application can either:

  • add a directive in the request to force the display of the login page, so that the user can use a different identity. This means a prompt=login parameter to the OIDC/OAuth2 request (the details of how to do that will depend on the SDK being used), or a ForceAuthn="true" attribute in a SAML request.
  • log the user out of Auth0 (https://auth0.com/docs/api/authentication#logout) before sending a new request.

Either of the above will force the display of the login page, so that the user has the opportunity to use a different identity if necessary.

But what about redirect rules?

Redirect rules are meant to put an additional step in the authorization process, but not to interrupt it because of an authorization policy or error condition. So they are not the appropriate solution for this.

And what about Lock’s events?

Lock, the UI widget, offers the authorization_error event that would lead you to think that they can be used to show an error from rules.

However, this event is only triggered if Lock is embedded in your application (as opposed to being used in the hosted login page) and, in addition, Lock is also the piece of software that is handling the authentication results in your application. This is an architecture that is best avoided on new developments, in favor of the Universal Login approach, where login happens on the Auth0 domain.

15 Likes