Univeral Login (Classic) and Blocked Users

Help
1

We are in the process of converting from a self-hosted login page to universal login. In the self-hosted version (lock version 11.2.2), when a user is blocked they see the error on the login screen. However, in universal login, the user is sent to the redirect screen with the error message and code. Is the behavior supposed to be different in universal login?

Error: unauthorized
Description: user is blocked

Universal Login Lock Configuration:

{
  "auth": {
    "redirectUrl": "_omitted_",
    "responseType": "code",
    "params": {
      "protocol": "oauth2",
      "response_type": "code",
      "scope": "openid profile email",
      "_csrf": "zNZUEurg-yHrReFQrLIzwzUnL5-hXVWclNUo",
      "_intstate": "deprecated",
      "state": "_omitted_"
    }
  },
  "container": "login-container",
  "configurationBaseUrl": "https://cdn.auth0.com/",
  "overrides": {
    "__tenant": "_omitted_",
    "__token_issuer": "_omitted_"
  },
  "assetsUrl": "",
  "allowedConnections": null,
  "rememberLastLogin": true,
  "languageDictionary": {
    "title": "",
    "login": {
      "headerText": "Please enter your credentials"
    },
    "error": {
      "login": {
        "lock.unauthorized": "Custom message about a blocked user",
        "blocked_user": "User is blocked."
      }
    },
    "databaseEnterpriseLoginInstructions": ""
  },
  "theme": {
    "logo": "_omitted_",
    "primaryColor": "#ec7d23"
  },
  "allowSignUp": false,
  "prefill": null,
  "closable": false,
  "defaultADUsernameFromEmailPrefix": false,
  "redirect": false
}
3

Hi @sjungers,

Just to make sure, are you referring to the error and error_description query string params that are appended to the redirect after a failed login?

When this happens, the application is meant to use these params to display a user-friendly message. This redirect pattern follows the OIDC protocol.

For example, in the Auth0 React SDK Quickstarts: Login you can see how the error message is handled in the App.js file.

4

Hi @stephanie.chamblee ,

Thank you for the reply.

When we host the login page trying to authenticate a user that is blocked results in the error message “User is Blocked” displaying on the login page. There is no redirect. When we switch to universal login, that same user is redirected to the redirect URL supplied by the calling application with the error and error_description parameters.

We can handle it in the redirect; I’m just curious why the behavior changed when we went from self-hosted login to universal login. As far as I can tell there are no significant differences in the lock configuration between our hosted version and the universal login version.

5

Is the “User is Blocked” error thrown in a rule?

If so, the error isn’t shown on the Universal Login page because Rules are executed after successful authentication has taken place. In order to follow the OIDC redirect flow, the Universal Login experience will redirect the user back to the application where they initialized the login process.

The lock dock offers two options for customizing errors thrown by rules:

If you are returning custom error codes from a rule or a custom database script, you can handle custom errors:

  • In your application’s redirect URL by reading the error and error_mesage query string parameters.
  • By redirecting the user back to your hosted pages with a custom error message and displaying the message with a flash message.
6

Hi @stephanie.chamblee,

Doesn’t Auth0 handle blocked user validation during login? We don’t have any rules that throw errors during the login transaction.

Regardless of whether or not we threw an error in the rule, the self-hosted version of lock behaves differently than the universal login version and I’m trying to understand why.

In the self-hosted lock version, the call to authenticate returns directly to the UI with the error. When we switched to universal login the authenticate call succeeds, and the user is redirected to the callback URL with the error and error_message parameters. So, without any other changes (that we know of) that could cause the change in behavior, why is moving to universal login causing this change in behavior.

In my original request, I posed the lock configuration for Auth0 in universal login. Below is the configuration from our local, hosted login page.

var lock = new Auth0Lock('...omitted...', '...omitted...', {
    auth: {
        redirectUrl: '...omitted...',
        responseType: 'code',
        sso: false,
        params: {
            state: '${state}',
            scope: 'openid profile email', // Learn about scopes: https://auth0.com/docs/scopes
        }
    },
    container: 'login-container',
    closable: false,
    avatar: null,
    allowSignUp: false,
    allowForgotPassword: false,
    languageDictionary: {
        title: "",
        login: {
            headerText: "Please enter your credentials"
        }
    },
    theme: {
        logo: "",
        primaryColor: "#ec7d23"
    }
});
lock.show();

The primary difference between the two configurations is the fact that we’re no using SSO. Is that causing the change in behavior?

7

You are correct! I was mistaken about the rules piece when it comes to blocked users. Sorry for any confusion that might have caused!

If you take a look at the Block and Unblock Users docs, it notes:

If a blocked user tries to access an application, they will be redirected to the application with the error message user is blocked in the URL.

The change in behavior is due to using the Universal Login instead of an embedded login. There are many security benefits to using the Universal Login (Centralized Universal Login vs. Embedded Login), but a difference is that certain errors (e.g. blocked users, errors thrown in rules, etc.) will result in redirects back to the application by design. Unfortunately, it is not possible to display the “blocked user” error on the Universal Login page itself.

You can submit a feature request in our new Feedback category which is reviewed by the product team regularly: Feedback - Auth0 Community

8

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