Sample Use Cases: Rules with Authorization

With rules, you can modify or complement the outcome of the decision made by the pre-configured authorization policy to handle more complicated cases than is possible with role-based access control (RBAC) alone. Based on the order in which they run, rules can change the outcome of the authorization decision prior to the permissions being added to the Access Token. They can also allow you to customize the content of your tokens.

Let's say you have an application that you want to make sure is only accessible during weekdays. To do this, you would create the following rule:

function (user, context, callback) {

  if (context.clientName === 'APP_NAME') {
    const d = Date.getDay();

    if (d === 0 || d === 6) {
      return callback(new UnauthorizedError('This app is only available during the week.'));
    }
  }

  callback(null, user, context);
}

If a user attempts to access the application during the weekend, access will be denied, even if they authenticate and have the appropriate privileges.

Let's say you want to allow access to an application, but only for users who are accessing the application from inside your corporate network. To do this, you would create the following rule:

function (user, context, callback) {
  const ipaddr = require('ipaddr.js@1.9.0');
  const corp_network = "192.168.1.134/26";
  const current_ip = ipaddr.parse(context.request.ip);

  if (!current_ip.match(ipaddr.parseCIDR(corp_network))) {
    return callback(new UnauthorizedError('This app is only available from inside the corporate network.'));
  };

  callback(null, user, context);
}

If the user is outside the corporate network, they will be denied access even if they successfully authenticate and have the appropriate privileges.

Let's say you want to deny access to all users who are calling an API. This means that you need to deny access depending on the audience value for your API, which you can find in the API Audience field of your API in Dashboard > Applications > APIs. To do this, you would create the following rule:

function (user, context, callback) {
  /*
   *  Denies access to user-based flows based on audience
   */
  var audience = '';
  audience = audience
              || (context.request && context.request.query && context.request.query.audience)
              || (context.request && context.request.body && context.request.body.audience);
  if (audience === 'http://todoapi2.api' || !audience) {
    return callback(new UnauthorizedError('end_users_not_allowed'));
  }
  return callback(null, user, context);
}

In this case, the audience value for the API is http:://todoapi2.api, so this is the audience we will refuse. If anyone tries to access the API with this audience value, they will be denied access and receive an HTTP 401 response.

If you enable RBAC for APIs along with "Add Permissions in the Access Token" (or enable RBAC via the Management API and set the Token Dialect to access_token_authz), you will receive user permissions in your Access Tokens. To add user roles to tokens, you would use the context.authorization object when you create the following rule:

function (user, context, callback) {
  const namespace = 'http://demozero.net';
  const assignedRoles = (context.authorization || {}).roles;

  let idTokenClaims = context.idToken || {};
  let accessTokenClaims = context.accessToken || {};

  idTokenClaims[`${namespace}/roles`] = assignedRoles;
  accessTokenClaims[`${namespace}/roles`] = assignedRoles;

  context.idToken = idTokenClaims;
  context.accessToken = accessTokenClaims;

  callback(null, user, context);
}

Although the Delegated Administration Extension (DAE) and the Authorization Core feature set are completely separate features, you can use the Authorization Core feature set to create and manage roles for the DAE if you use a rule.

1. Create DAE roles using the Authorization Core feature set. The names of the roles you create must match the names of the pre-defined DAE roles.

2. Assign the DAE roles you created to the appropriate users using the Authorization core feature set.

3. Add user roles to the DAE namespace in the ID Token. To do so, create the following rule, remembering to replace the CLIENT_ID placeholder value with your application's Client ID:

   function (user, context, callback) {
       if (context.clientID === 'CLIENT_ID') {
           const namespace = 'https://example.com/auth0-delegated-admin';
           context.idToken[namespace] = {
               roles: (context.authorization || {}).roles
           };
       }
       callback(null, user, context);
   }

   Was this helpful?

   Yes /No
   Auth0 returns profile information in a structured claim format as defined by the OpenID Connect (OIDC) specification. This means that custom claims added to ID tokens or access tokens must conform to guidelines and restrictions to avoid possible collisions.