andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

josh-cunningham

I’ve been working on the web since 2007 as an engineer, designer, strategist, user interface consultant, team lead, project manager, and product builder. I’m currently the lead engineer on our Marketplace team helping partners design, build, and publish integrations to the Auth0 platform. I’m fascinated by current trends in digital identity, how we communicate asynchronously in our personal and professional lives, how software gets made on a team, and note-taking techniques.

Lead Ecosystem Engineer

Josh Cunningham

Are you considering migrating your Auth0 Rules to Auth0 Actions? Here are some guidelines to do it successfully.

<div class="alert alert-danger alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>We are deprecating Auth0 Rules and Hooks by November 18, 2024. To learn more about what's changing, check out the <a href="https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/">deprecation announcement blog post</a>.</strong>
</div>

<AmpContent>
<amp-youtube
    data-videoid="B5pzpPqPbbM"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div class='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/B5pzpPqPbbM' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

Auth0 Actions offer many advantages over Rules. If you are using Rules to customize your Auth0 integration experience, you should consider migrating to Actions. Learn how to plan and implement this migration.



## Comparing Auth0 Rules and Actions

One of Auth0's strengths is its focus on extensibility, i.e., the ability for the user to customize the standard behavior of Auth0's identity solutions. [Auth0 Rules](https://auth0.com/docs/customize/rules) was the first tool that enabled users to run custom code to extend Auth0 authentication. Rules are serverless code blocks executed right after successful authentication but before tokens are issued.

To satisfy the widest range of extensibility needs, Auth0 has constantly worked on improving this tool. Recently, it consolidated the acquired experience on customization and provided developers with [Auth0 Actions](https://auth0.com/actions), a solid environment for most code-based customization needs.

Auth0 Actions offer a lot of benefits over Rules. So, if you are about to start your customization, Actions are the recommended tool. On the other hand, if you have already implemented your customization through Rules, you are strongly encouraged to migrate to Actions. Let's look at a few advantages you can get by switching to Actions:

- Rules let you handle just the authentication flow. **Auth0 Actions let you handle multiple flows**: authentication, pre and post user registration, password change, client credential exchange, phone message sending.
- Rules don't have an integrated version control system. Actions do. **You can modify an Action without affecting the one in production**, create multiple versions, and restore a previous one. 
- Unlike Rules, the Actions editor supports code hints, all npm packages, and isolated secrets management. **The developer experience is significantly improved**.

Read [this blog post for a quick introduction to Auth0 Actions](https://auth0.com/blog/introducing-auth0-actions/).

> While Auth0 Actions bring you an improved customization environment, Rules and Hooks are still available, and they all can live together. <u>Just remember that Rules and Hooks are executed before Actions.</u>

You can use Actions to replace your Rules, but be aware of some limitations:

- In Rules, you can share data with other Rules in the pipeline by adding properties to the `user` and `context` objects. These properties are accessible in subsequent Rules. In Actions, you can't do this, although changes to the user's metadata can be accessed by subsequent Actions.
- Rules can [modify SAML assertions or attributes](https://auth0.com/docs/authenticate/protocols/saml/saml-configuration/customize-saml-assertions). Actions can't.
- Rules have [limited access to the Auth0 Management API](https://auth0.com/docs/customize/rules/use-management-api) and [the `global` and `auth0` objects](https://auth0.com/docs/customize/rules/rules-best-practices/rules-environment-best-practices#global-object). Actions can't, but have an alternative approach for doing similar tasks, as you will learn in the following.

Take a look at [the full list of limitations of the current implementation](https://auth0.com/docs/customize/actions/limitations).

With these caveats in mind, let's take a look at how you can convert your Rule into an Auth0 Action.

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>No-Code Solution</strong><br> 
  When migrating from Rules to Actions, a developer may also want to consider a no-code Integration - including Actions Integrations - from the <a href="https://auth0.com/resources/whitepapers/broken-auth-checklist">Auth0 Marketplace</a>. These Partner-built integrations solve common identity use cases such as consent management, progressive profiling, and user verification, enabling developers to go-to-market faster while reducing development and maintenance costs associated with custom code.<br> 
</div>

## Code Conversion Guidelines

Auth0 Rules allow you to customize the authentication flow. That means you can convert a Rule into an Auth0 Action handling [the Post Login trigger of the Login Flow](https://auth0.com/docs/customize/actions/triggers/post-login).

> This article will not guide you step-by-step through creating an action or migrating a rule. It assumes that you have a basic understanding of how to create a Rule and how to create an Action.
> If not, please refer to Auth0 documentation about [Rules creation](https://auth0.com/docs/customize/rules/create-rules) and [Actions writing](https://auth0.com/docs/customize/actions/write-your-first-action).
> In both cases, you need an Auth0 account. If you don't have it, <a href="https://a0.to/blog_signup"  data-amp-replace="CLIENT_ID"  data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)"> you can get one for free</a>.

The Actions editor for the Post Login trigger looks like the following:

![Auth0 Action editor](https://images.ctfassets.net/23aumh6u8s0i/29HiQQis75pvxp6arSitxM/4927a37ca2557f8567bd838b8c8cb6c0/auth0-action-editor.png)

Conceptually, to migrate your Rule, you need to move the body of the function that implements it into the body of the following function:

```javascript
exports.onExecutePostLogin = async (event, api) => {
};
```

This is not just a matter of copy and paste. You need to apply some changes to make the conversion effective. So, let's focus on the specific changes you should apply to your Rule's code.

> You can have multiple Rules handling your authentication flow. You can map these Rules to as many Actions by keeping the same order. This will ensure you keep the same functionality.

### Mapping parameters

An Auth0 Rule is a JavaScript function with three parameters: `user`, `context`, and `callback`. The `onExecutePostLogin()` function implementing the Action has two parameters: `event` and `api`. Besides the different names, how can you map those parameters? How can your Action retrieve the same data from the parameters as your Rule?

Actually, the design of Actions brought you consolidation of the data passed by the running environment to the Action function. As a general rule, all read-only properties of the `user` and `context` objects in Rules have been moved to the `event` object in Actions. Any interaction with the running environment, like failing a login or updating user metadata, is implemented through methods of the `api` object.

Please refer to the documentation to learn more details about [the `event` object](https://auth0.com/docs/customize/actions/triggers/post-login/event-object) and [the `api` object](https://auth0.com/docs/customize/actions/triggers/post-login/api-object).

### Accessing user data

In Rules, you get data about the current user by accessing the `user` object parameter. In Actions, you need to access the `event.user` object. Here you can find the same data as the `user` object except the attributes added by an external identity provider or custom database script.

To give you an example, if you have the following Rule implementation:

```javascript
function myRule(user, context, callback) {
	const userEmail = user.email;
	const userId = user.user_id;
	
	// ... additional code
}
```

You can convert it into an Action implementation as follows:

```javascript
exports.onExecutePostLogin = async (event, api) => {
	const userEmail = event.user.email;
	const userId = event.user.user_id;
	
	// ... additional code
};
```

> Notice that while the `user.app_metadata` object could be undefined in Rules, the counterpart `event.user.app_metadata` will always be defined in Actions.

### Accessing context data

In Rules, the `context` object stores data about the current login session. In Actions, you can find the same data in the `event` object.

Consider the following Rule function:

```javascript
function myRule(user, context, callback) {
	const clientId = context.clientID;
	const clientMetadata = context.clientMetadata || {};
	
	const connectionId = context.connectionID;
	const connectionMetadata = context.connectionMetadata || {};
	
	const protocol = context.protocol;
	
	const tenant = context.tenant;
	
	// ... additional code
}
```

In an Action, it will become as shown below:

```javascript
exports.onExecutePostLogin = async (event, api) => {
	const clientId = event.client.client_id;
	const clientMetadata = event.client.metadata;
	
	const connectionId = event.connection.id;
	const connectionMetadata = event.connection.metadata;
	
	const protocol = event.transaction.protocol;
	
	const tenant = event.tenant.id;
	
	// ... additional code
};
```

As you can see, some properties of the `context` object have become properties of a few objects attached to the `event` object. For example, you have the `client` object, the `connection` object, and so on. In other words, the login session data has been refactored to be more clearly organized.

Be aware that some property names have different spellings. For example, `clientID` becomes `client_id`, `connectionMetadata` becomes `connection.metadata`, etc.

Please compare the documentation of [the `context` object in Rules](https://auth0.com/docs/customize/rules/context-object) and [the `event` object in Actions](https://auth0.com/docs/customize/actions/triggers/post-login/event-object) to learn more about the differences.

### Dealing with dependencies

Auth0 Rules allow you to include dependencies to power up your code. You can leverage thousands of npm packages, but not all the packages available in the [npm registry](https://www.npmjs.com/). If you need a package that is not available for Rules (or even just a specific version of an npm package), you need to request it to Auth0.

In Actions, you can add dependencies for all the available packages in the npm registry, which means over one million.

Also, unlike Rules, in Actions you don't need to specify the package version in the code. That means, for example, that in Rules you have to declare a dependency this way:

```javascript
function myRule(user, context, callback) {
	const axios = require("axios@0.22.0");
	
	// ... additional code
}
```

In Actions, you specify the package version just in the editor's module manager and your code looks like the following:

```javascript
const axios = require("axios");

exports.onExecutePostLogin = async (event, api) => {
	// ... additional code
};
```

Notice that you import the dependency outside the function's body, more in the style of a Node.js module.

### Converting Rules' callbacks

In Rules, you use the `callback` parameter to pass back the result of your processing. For example, in order to pass the control to the Auth0 authentication process, which will possibly run the next Rule, you should invoke the `callback()` function by passing the current `user` and `context` objects. In case you want to stop the current login process, you need to call the `callback()` function with an error instance.

With Actions, everything is more straightforward. To pass control, simply use `return`. To stop the login process, call the `api.access.deny()` method.

Consider the following Rule function:

```javascript
function myRule(user, context, callback) {
	const userAppMetadata = user.app_metadata || {};

	if (userAppMetadata.condition === "success") {
		// This Rule succeeded, proceed with next Rule.
		return callback(null, user, context);
	}
	
	if (userAppMetadata.condition === "failure") {
		// This Rule failed, stop the login with an error response.
		return callback(new Error("Failure message"));
	}
	
	// ... additional code
}
```

This code succeeds or fails based on the value of the `condition` property of the `app_metadata` object. You can convert this code into the following Action function:

```javascript
exports.onExecutePostLogin = async (event, api) => {
	if (event.user.app_metadata.condition === "success") {
		// This Action succeeded, proceed with next Action.
		return;
	}
	
	if (event.user.app_metadata.condition === "failure") {
		// This Action failed, stop the login with an error response.
		return api.access.deny("Failure message");
	}
	
	// ... additional code
};
```

In summary, you should replace any instance of `callback()` in your Rule with a call to `api.access.deny()`, in case of failure, or with `return`, in case of success. You can also omit the `return` statement if your code runs to the end of the function's body.

## Conversion Examples

Now that you have some general guidelines to convert the code of your Rules into Actions, let's take a look at some examples.

### Adding custom claims to a token

One of the most common use cases for Rules is the ability to add custom claims to a token, either an ID token or an access token. For example, the following code snippet shows a Rule adding two custom claims to the ID token:

```javascript
function myRule(user, context, callback) {
  const namespace = 'https://myapp.example.com/';
  
  context.idToken[namespace + 'favorite_color'] = user.user_metadata.favorite_color;
  context.idToken[namespace + 'preferred_contact'] = user.user_metadata.preferred_contact;
  callback(null, user, context);
}
```

This Rule can be converted into an Action as follows:

```javascript
exports.onExecutePostLogin = async (event, api) => {
  const namespace = 'https://myapp.example.com/';
  
  api.idToken.setCustomClaim(
    `${namespace}/favorite_color`,
    event.user.user_metadata.favorite_color
  );
  
  api.idToken.setCustomClaim(
    `${namespace}/preferred_contact`,
    event.user.user_metadata.preferred_contact
  );
};
```

While the Rule assigns the values directly to the `context.idToken` object, in the Action you have to use the `api.idToken.setCustomClaim()` method. Notice how the invocation of `callback()` disappears in the Action.

### Updating metadata

You can manage users' and applications' metadata using Rules. The following example shows how to store the font size preference in the user's metadata:

```javascript
function myRule(user, context, callback){
  user.user_metadata = user.user_metadata || {};
  user.user_metadata.preferences = user.user_metadata.preferences || {};
  user.user_metadata.preferences.fontSize = 12;

  // persist the user_metadata update
  auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
    .then(function(){
      callback(null, user, context);
    })
    .catch(function(err){
      callback(err);
    });
}
```

The corresponding Action's code looks like the following:

```javascript
exports.onExecutePostLogin = async (event, api) => {
  const userPreferences = event.user.user_metadata.preferences || {};
  
  userPreferences.fontSize = 12;
  
  // persist the user_metadata update
  api.user.setUserMetadata("preferences", userPreferences);
};
```

While the Rule's code needs to access the `auth0.users.updateUserMetadata()` method, which returns a promise, the Action's code just assigns the metadata value by using the `api.user.setUserMetadata()` method. Notice how simplified the Action's code is compared to the Rule's one.

> In Rules, each invocation of `auth0.users.updateUserMetadata()` makes an HTTP request to the [Auth0 Management API](https://auth0.com/docs/api/management/v2). Instead, all the invocations of `api.user.setUserMetadata()` occurring in one or more Actions will result in a single API call at the end of the Actions execution. This contributes to mitigating the risk of [rate limit](https://auth0.com/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy/management-api-endpoint-rate-limits) errors.

### Redirecting users

When you need to redirect the user to a different page to complete the login process and then resume authentication, your Rule may look as shown below:

```javascript
function myRule(user, context, callback) {
  if (context.protocol === "redirect-callback") {
    // User was redirected to the /continue endpoint
    user.app_metadata.wasRedirected = true;
    return callback(null, user, context);
  } else if (
    context.protocol === "oauth2-password" ||
    context.protocol === "oauth2-refresh-token" ||
    context.protocol === "oauth2-resource-owner"
  ) {
    // User cannot be redirected
    return callback(null, user, context);
  }

  // User is logging in directly
  if (!user.app_metadata.wasRedirected) {
    context.redirect = {
        url: "https://example.com",
    };
    callback(null, user, context);
  }
}
```

This Rule and any other previous Rule will run twice: before the redirection and on the response. Typically, you need to put the logic for handling the redirection and the response in the same Rule. Also, you need to manually check if the current protocol is eligible for a user redirect.

The conversion of this Rule into an Action becomes as follows:

```javascript
exports.onExecutePostLogin = async (event, api) => {
    if (!event.user.app_metadata.wasRedirected && api.redirect.canRedirect()) {
        api.redirect.sendUserTo("https://example.com");
    }
};

exports.onContinuePostLogin = async (event, api) => {
    api.user.setAppMetadata("wasRedirected", true);
};
```

You have different functions handling the redirection (`onExecutePostLogin()`) and the response (`onContinuePostLogin()`). Also, the burden to check if the current protocol is eligible for a user redirect is assigned to the `api.redirect.canRedirect()` method. Also, notice that Actions use the `api.redirect.sendUserTo()` method to redirect users instead of the `context.redirect` object.

To learn more about [user redirect with Actions, check out the documentation](https://auth0.com/docs/customize/actions/triggers/post-login/redirect-with-actions).

## Plan Your Migration Strategy

At this point, you should have a clearer understanding of the main differences between the code used in Rules and Actions. However, knowing how to translate a Rule into an Action is not the only thing you should care about. You also need to plan a strategy to migrate your code from Rules to Actions in order to avoid issues in the production environment.

Check out [the documentation for guidelines to define your Rules to Actions migration strategy](https://auth0.com/docs/customize/actions/migrate-from-rules-to-actions#complete-the-migration).

## Summary

This article gave you the foundations to set up your migration process from Auth0 Rules to Actions. You learned the main reasons to migrate and the basic differences between coding for Rules and coding for Actions.

A few conversion examples showed you how Actions generally simplify the code. You can find more conversion examples and additional information in [the Auth0 Rules to Actions migration guide](https://auth0.com/docs/customize/actions/migrate-from-rules-to-actions).

Migrating Auth0 Rules to Auth0 Actions

5e074956ee8ba1fea26e30d28c190495?s=300 avatar

5e074956ee8ba1fea26e30d28c190495?s=300

Full stack developer creating content at Auth0. I love taking a deep dive into hard-to-understand concepts and creating content that makes them easier to grasp. In my free time you can usually find me reading, hanging out with my dogs, or curling in the squat rack.

Former Developer Content Manager

Holly Guevara

Learn how to implement consent management with Auth0 Marketplace


  
## What is Consent Management?

With the [growing number of security breaches](https://auth0.com/blog/the-11-biggest-data-breaches-of-2020-so-far/) over the past decade, it's no surprise that privacy concerns and accompanying legislation have become hot topics. This has also prompted a huge shift in how websites and applications obtain user consent for collecting their data, otherwise known as **consent management**.

Implementing consent management for your users can quickly become a monumental task. First, you have to understand the privacy regulations that affect your users. You may serve users from all over the world, so the exact regulations will vary. After you understand *what* you need to implement, then comes the *how*.

Managing user opt-ins, email consent, communications, data storage, and more on your own can become overwhelming. Luckily, there are a few companies out there that have made consent management their bread and butter!

Let's look at some of the ways you can implement **[consent management](https://auth0.com/blog/what-you-need-to-understand-about-consent-management)** in your application using the **Auth0 Marketplace**.

<include src="AvocadoLabsPromo" description="Join us on Monday, October 5th, 2020 at 9 am  PT as we talk about our strategy behind building the Auth0 Marketplace and the opportunity it delivers." buttonText="Register now!" buttonLink="https://avocadolabs.dev/events/avocado-labs-community-4/?utm_source=auth0_blog&amp;utm_medium=intro_marketplace"/>

<blockquote style="margin:50px 0 60px 0;">For more background on consent management, check out the <a href="https://auth0.com/blog/what-you-need-to-understand-about-consent-management">What You Need to Understand About Consent Management</a> blog post.</blockquote>

## Add Consent Management to your Application

### Meet OneTrust

[OneTrust](https://www.onetrust.com/) is a leader in privacy and consent management solutions. Using the [OneTrust integration in Auth0 Marketplace](https://marketplace.auth0.com/integrations/onetrust-consent-management), you can:

- Add consent data to each of your users' profiles
- Make sure you're in compliance with the various privacy regulations that affect your users
- Enhance your application's transparency with dynamic preference centers customized for each user

Integrating OneTrust into your application is simple. Head over to the [OneTrust integration page](https://marketplace.auth0.com/integrations/onetrust-consent-management), and click on the "Installation" tab.

![OneTrust Auth0 Marketplace integration](https://images.ctfassets.net/23aumh6u8s0i/3eoDj4Ag1QsexeuJIfG1Ew/c78aaed5c88a2e2280da5bd5d3721bdf/onetrust-installation)

This will take you step-by-step through how to configure an [Auth0 rule](https://auth0.com/docs/rules), which will automatically send Auth0 user emails to a OneTrust Collection Point during login.

If you have any questions along the way, please use the "**Get Support**" link on the OneTrust integration page.

### Meet MyLife Digital

[MyLife Digital](https://mylifedigital.co.uk/) is another great option for implementing universal consent and preference management. With the [MyLife Digital Auth0 Marketplace integration](https://marketplace.auth0.com/integrations/mylife-digital-progressive-consent), you can easily add consent collection to your user login flow for new and existing users.

Navigate over to the [MyLife Digital Auth0 Marketplace integration page](https://marketplace.auth0.com/integrations/mylife-digital-progressive-consent), and click on the "Installation" tab.

![MyLife Digital Auth0 Marketplace integration](https://images.ctfassets.net/23aumh6u8s0i/5OpYJUzgqnPpLU6Ey9Lwpx/4175ca3a241ec7c68860bc6079c4385b/mylife-digital-installation)

The instructions here will walk you through how to set up an Auth0 rule that runs at login and/or signup. Once the user signs in, the rule will redirect them to the MyLife Digital Consentric widget, where they'll be presented with consent options. After they select their options, the Auth0 authentication flow will continue.

If you have any questions or need assistance with the implementation, click on the "**Get Support**" link on the [MyLife Digital integration page](https://marketplace.auth0.com/integrations/mylife-digital-progressive-consent-capture).

## Conclusion

As you've seen, there's a lot that goes into managing user consent, but that doesn't mean implementing it has to be difficult! With the OneTrust or MyLife Digital integrations, adding consent management to your application is a breeze.

If you'd like to learn more about consent management and why you should implement it, check out our [What You Need to Understand About Consent Management](https://auth0.com/blog/what-you-need-to-understand-about-consent-management) blog post.


Consent Management with Auth0 Marketplace

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing.<br/><br/> Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Let your defenses down, and you could be giving money away.


In 2016, consumers lost [$16 billion](https://www.cnbc.com/2017/02/01/consumers-lost-more-than-16b-to-fraud-and-identity-theft-last-year.html) due to online fraud, up from $15 billion in 2015. Such crimes affected more than 15.4 million consumers.

None of this takes into account the enormous damages to companies' reputations when their security systems are breached.

Many organizations have taken initial steps to protect themselves against these types of losses (e.g., trying to keep pace with software updates) — but far more can be done.

## What Is Online Fraud Protection?

Online fraud protection encompasses an array of methods for preventing the theft of your organization’s most sensitive data. General forms can include, but are not limited to:

1. **Educating your employees about phishing:** Sophisticated email attacks can be indistinguishable from real emails. This can result in staggering breaches of end-user data. It's important to make sure that each member of your team understands [this](https://auth0.com/blog/the-new-trend-of-artisanal-spam/).
2. **Limiting the disclosure of sensitive information:** The more you distribute your company's EIN, the more surface area you're creating for possible attacks. Limit disclosure to only those cases, when it's absolutely necessary. In addition, try to communicate it over the phone or in-person rather than over a stored medium.
3. **Sign up for alerts with your local Secretary of State:** If anyone attempts to change your business's registration information, you can receive an email quickly from your local Secretary of State, notifying you of the update. If it's not something you authorized, you can have the fraud immediately rolled back.

Despite widespread education on these steps, hackers still manage to worm their way into companies at alarming rates.

## The Worst Cases of Identity Theft in Recent History

[When a data breach occurs](https://auth0.com/blog/data-breaches-by-the-numbers/), cyberthieves have the ability to open bank accounts, lines of credit, new credit cards, and even drivers' licenses in the name(s) of those they've scammed. This can happen within a day — or sooner.

![When a data breach occurs, cyberthieves have the ability to open bank accounts, lines of credit, etc.](https://images.ctfassets.net/23aumh6u8s0i/69tS9PWDrwY2lbWKNXZbwC/d60a82408d3b5b1b33663727dd3a3cfe/equifax-breach-laptop-lg)

([Image Source](https://www.creditcards.com/credit-card-news/images/equifax-breach-laptop-lg.png))

In September 2017, criminals stole sensitive data, including names, birthdates, physical addresses, and Social Security numbers from a yet-to-be-determined number of drivers' licenses from Equifax customers. These hackers also stole 209,000 credit card numbers and 182,000 documents, also containing identifying information.

This is the tip of the iceberg. Other major breaches in the past few years include:

* **Yahoo:** 2013 *and* 2014 (both disclosed 2016); 3.5 billion accounts exposed in total (all Yahoo users); names, birthdates, phone numbers, email addresses, encrypted or unencrypted security questions and answers, and hashed passwords — now available for sale.
* **Myspace:** 2016; 360 million users threatened; more than 427 million passwords made vulnerable.

In the cases of Equifax and Myspace, hackers were able to carry out their breaches, due to outdated systems (e.g., a vulnerability in one of Equifax's web applications allowed access to the credit reporting agency’s most critical data). With Yahoo, an employee opened a spear-phishing email. From here, the hacker was able to explore the company's network, install a backdoor into its server, and obtain a copy of the user database.

## Three Extra Steps You Can Take to Protect Your Company

[Rules](https://auth0.com/blog/5-ways-to-make-your-app-more-secure-in-less-than-20-minutes/) are snippets of JavaScript code, which run as part of a customized login process on Auth0 servers. Rules allow customers to limit logins to a specific region, add information to a user profile (e.g., their security role), and/or check the last time a user reset their password.

![Rules (https://auth0.com/blog/5-ways-to-make-your-app-more-secure-in-less-than-20-minutes/) are snippets of JavaScript code, which run as part of a customized login process on Auth0 servers](https://images.ctfassets.net/23aumh6u8s0i/35QmtnrOwvXpSyD3FdNvoj/25eb462933a2eddb3ef9bd7ad6ec35c1/flow.png)

Rules can be helpful in several ways.

* **They are easy to create & run:** Implementation is simply via a few lines of JavaScript in our Webtask sandbox — with no extra technical debt or product development needed.
* **They can provide real-time updates:** Depending on the service for which you are implementing Rules, you can get real-time updates of user sign-ins, along with any data you sent via the API.
* **They offer sequencing:** Any number of Rules can be run on a single log in. You can run each of the three Rules below (and more) every time a user logs in.
* **They bring improved reporting accuracy:** Server-side events complete with a much higher degree of confidence than client-side ones. (Client-side attempts can be blocked by firewalls, errant browser extensions, or code errors.)

### Rule 1: User Fraud Score

This Auth0 Rule is particularly helpful if you have built an online marketplace, such as Etsy or Airbnb. Protecting your buyers and sellers from fraud in this ecosystem is critical to maintaining its trustworthiness and ensuring more transactions happen there. This Rule will calculate a fraud score for every user, based on their email address and IP address.

```javascript
function (user, context, callback) {
  // score fraudscore once (if it's already set, skip this)
  user.app_metadata = user.app_metadata || {};
  if (user.app_metadata.socure_fraudscore) return callback(null, user, context);

  var SOCURE_KEY = 'YOUR SOCURE API KEY';

  if(!user.email) {
    // the profile doesn't have email so we can't query their api.
    return callback(null, user, context);
  }

  // socurekey=A678hF8E323172B78E9&email=jdoe@acmeinc.com&ipaddress=1.2.3.4&mobilephone=%2B12015550157
  request({
    url: 'https://service.socure.com/api/1/EmailAuthScore',
    qs: {
      email:  user.email,
      socurekey: SOCURE_KEY,
      ipaddress: context.request.ip
    }
  }, function (err, resp, body) {
    if (err) return callback(null, user, context);
    if (resp.statusCode !== 200) return callback(null, user, context);
    var socure_response = JSON.parse(body);
    if (socure_response.status !== 'Ok') return callback(null, user, context);

    user.app_metadata = user.app_metadata || {};
    user.app_metadata.socure_fraudscore = socure_response.data.fraudscore;
    user.app_metadata.socure_confidence = socure_response.data.confidence;
    // "details":[
    //     "blacklisted":{
    //        "industry":"Banking and Finance",
    //        "reporteddate":"2014-07-02",
    //        "reason":"ChargeBack Fraud"
    //     }
    // ]
    user.app_metadata.socure_details = socure_response.data.details;

    auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
      .then(function(){
        context.idToken['https://example.com/socure_fraudscore'] = user.app_metadata.socure_fraudscore;
        context.idToken['https://example.com/socure_confidence'] = user.app_metadata.socure_confidence;
        context.idToken['https://example.com/socure_details'] = user.app_metadata.socure_details;
        callback(null, user, context);
      })
      .catch(function(err){
        callback(null, user, context);
      });
  });
}
```

(Auth0 Rule for [Socure](https://auth0.com/rules/socure_fraudscore))

Fraud Score works with [Socure](http://socure.com/), a cloud service that aggregates data from social media, offline identity verification services, and publicly available data, to determine if a user is real or fake. By putting users with high fraud scores on a watch list, and/or requiring additional verification before they can transact, Fraud Score can help protect your app and users. In addition, Fraud Score will deliver the information by the point of registration, instead of following a series of fraudulent transactions on the site.

### Rule 2: Checking Fraud with minFraud

minFraud identifies possible fraud in online transactions, as well as suspect account logins and signups, using geolocation, IP address, email, device and proxies. The minFraud rule will send the user’s IP address, email address, and username (both in MD5 format) to MaxMind’s minFraud API. In turn, the API will return the risk score for the transaction. This data can be leveraged within the Rule to block any login with a high-risk score.

```javascript
/**
 * @title Fraud Prevention
 * @overview Send the user's IP address, user agent, email address and username in MD5 to MaxMind's MinFraud API.
 *
 * This rule will send the user's IP address, user agent, email address (in MD5) and username (in MD5) to MaxMind's MinFraud API. This API will return information about this current transaction like the location, a risk score, ...
 *
 * > Note: You will need to sign up here to get a license key https://www.maxmind.com/
 *
 */

function (user, context, callback) {
  const querystring = require('querystring');
  const request = require('request');
  const crypto = require('crypto');

  const MINFRAUD_API = 'https://minfraud.maxmind.com/app/ccv2r';

  const data = {
    i: context.request.ip,
    user_agent: context.request.userAgent,
    license_key: configuration.MINFRAUD_LICENSE_KEY,
    emailMD5: user.email &&
        crypto.createHash('md5').update(user.email).digest("hex") || null,
    usernameMD5: user.username &&
        crypto.createHash('md5').update(user.username).digest("hex") || null
  };

  request.post(MINFRAUD_API, { form: data, timeout: 3000 }, (err, res, body) => {
    if (!err && res.statusCode === 200) {
      const result = querystring.parse(body, ';');

      console.log(`Fraud response: ${JSON.stringify(result, null, 2)}`);

      if (result.riskScore && (result.riskScore * 100) > 20) {
        return callback(new UnauthorizedError('Fraud prevention!'));
      }
    }

    if (err) {
      console.log(`Error while attempting fraud check: ${err.message}`);
    }
    if (res.statusCode !== 200) {
      const message = err && err.message;
      console.log(`Unexpected error while attempting fraud check: ${message}`);
    }

    // If the service is down, the request failed, or the result is OK just continue.
    return callback(null, user, context);
  });
}
```

See this rule [here](https://github.com/auth0/rules/blob/master/src/rules/fraud-prevention-with-minfraud.js).

### Rule 3: Force Email Verification

As expected, this Rule denies any user who hasn’t verified their email address from logging in. This Rule is particularly helpful when working with multiple emails, which belong to networks, e.g., `@university.edu` or `@company.edu`. (The tactic of requesting these network emails is one of many critical ones, which help SaaS companies grow rapidly.)

```javascript
function (user, context, callback) {
  if (!user.email_verified) {
    return callback(new UnauthorizedError('Please verify your email before logging in.'));
  } else {
    return callback(null, user, context);
  }
}
```

(Auth0 Rule for [forcing email verification](https://auth0.com/rules/email-verified))

Without this email verification step, chances are high you could show an impostor sensitive company information. To ensure a user actually owns the email address and belongs to the network, signified by their email address, have your app email the user with a unique, obscure, automatically generated link to a page. This will force them to prove that they have access to the email account by logging in and clicking on the link to verify.

While a range of options is available for corporations and institutions to verify the identity of their users, Auth0 offers teams the chance to integrate their advanced options into existing SaaS tools.

## Stay Ahead of Cybercriminals In 2018

In 2018, identity theft will continue to rise as it has for decades. Cybercriminals only become more advanced in their techniques of usurping others’ identities; losses from these crimes have worsened.

Be sure your company isn't part of the headlines — and doesn't suffer significant financial losses. Auth0 Rules can deliver simple fixes — halting staggering problems before they arise.


The $6 Billion Reason Your Business Needs Advanced Fraud Protection

di6-Pbxw

Guest Author

Esteban Herrera

Learn how to leverage Pusher to get realtime authentication events from Auth0.



[Auth0](https://auth0.com) is a service that allows you to easily authenticate the users of your application using methods like social network logins and [passwordless systems](https://auth0.com/passwordless).

[Pusher](https://pusher.com) is a platform that allows you to build scalable realtime apps via WebSockets with a simple Publish/Subscribe model and other features.

Together, they make a powerful combination. For example, imagine if you could notify other systems when a login happens in realtime and with just a few lines of code. This is possible when you use Auth0 and Pusher together.

In this tutorial, we'll set up a [Auth0 rule](https://auth0.com/docs/rules) that will send login/signup events to Pusher so they can be shown in a feed in realtime. This is what we'll be building:

![Auth0 Pusher App](https://images.ctfassets.net/23aumh6u8s0i/HEeFqSaPj9boLjY4t89XB/d4fb518b0440562e5a33249ec6c07261/getting-authentication-events-in-realtime-with-auth0-and-pusher-final-app)

First, there's a login app that sends log in/signup requests to Auth0. If the user authenticates successfully, a rule is executed. This rule is a JavaScript function that sends the user information to a Pusher channel so another app can show it in a feed in realtime. We'll use [Create React App](https://github.com/facebookincubator/create-react-app) to create this feed application.

For reference, you can find the source code of the Auth0 rule in this [gist](https://gist.github.com/eh3rrera/00ee1aeb462777736f4e441694662c5d) and the source code of the feed in this [GitHub repo](https://github.com/eh3rrera/auth0-pusher-feed).

Let's get started.

## Setting up your Pusher application

Create a free account at [https://pusher.com/signup](https://pusher.com/signup).

When you create an app, you'll be asked to enter some configuration options:

![Pusher Account](https://images.ctfassets.net/23aumh6u8s0i/4gY7QTuougYeyPPjId2Mfr/e42e448dd5cc83bc40af1e3812bd5950/getting-authentication-events-in-realtime-with-auth0-and-pusher-create-pusher-app)

Enter a name for your app and choose *React* as your front-end tech. There's no need to choose a back-end tech for now. This will give you some sample code to get you started:

![Getting Started with Pusher](https://images.ctfassets.net/23aumh6u8s0i/3BatB7qibkanZRqL3oPeg8/28b9b54b4f263a04051feb61df525f57/getting-authentication-events-in-realtime-with-auth0-and-pusher-getting-started)

But don't worry, this won't lock you into this specific set of technologies as you can always change them. With Pusher, you can use any combination of libraries.

Next, copy your cluster ID (next to the app title, in this example `mt1`), App ID, Key, and Secret information as we'll need them later. You can also find them in the *App Keys* tab.

## Setting up an Auth0 rule

Create a free account at [https://auth0.com/signup](https://auth0.com/signup).

> [Auth0 offers a generous **free tier**](https://auth0.com/pricing) to get started with modern authentication.

Next, create a client. Give it a name and choose the Single Page Web Application type.

![Setting up Auth0 Client](https://images.ctfassets.net/23aumh6u8s0i/6qFuzdUapqebxBxcjKTuqq/618c73cc99d798275096c6ca3bec8d4e/getting-authentication-events-in-realtime-with-auth0-and-pusher-create-auth0-client)

For the tech, choose React.

![Setting up Auth0 Quickstart](https://images.ctfassets.net/23aumh6u8s0i/2MsPsaGP8j7KIzcM5ZXYHy/9cc5b398aeabdac1a906fb557a774535/getting-authentication-events-in-realtime-with-auth0-and-pusher-auth0-choose-tech)

This will give a sample project and some instructions to get you started. Download the project.

![Downloading Auth0 Quickstart](https://images.ctfassets.net/23aumh6u8s0i/1dUU7kJ5KypGPyDQiF27hI/eb728a3d47e4a3fd854174b2eb31ba63/getting-authentication-events-in-realtime-with-auth0-and-pusher-auth0-sample-proj)

Next, go to the *Settings* tab and in the *Allowed Callback URLs* text field, enter *http://localhost:3000/login* (or whatever host and port you're planning to use to host your login app). This is required so Auth0 can authenticate users in your app and send a callback with the success or error.

![Auth0 Client Configuration](https://images.ctfassets.net/23aumh6u8s0i/5lLP8EjEmzeT8jwchQvwpP/6e2a43b95260c6797fe6a33be1f6c8ee/getting-authentication-events-in-realtime-with-auth0-and-pusher-set-allowed-callback)

A database to store your users is enabled by default. You see it in the *Connections->Database* section.

![Auth0 Database Connection](https://images.ctfassets.net/23aumh6u8s0i/1FoyWo83TrP0feqxHBJbdQ/d6b3dd267d0d796892d2f44f202cf773/getting-authentication-events-in-realtime-with-auth0-and-pusher-connections-db)

Also, for social logins, only Google is enabled by default with some sample development keys. You can see it in the *Connections->Social* section.

![Auth0 Social Connections](https://images.ctfassets.net/23aumh6u8s0i/3jYxZmVSCP1sUxhbezpkWs/537b6c19a2f7d9455cddd86cf035f832/getting-authentication-events-in-realtime-with-auth0-and-pusher-connections-social)

Now go to the *Rules* section.

![Auth0 Rules](https://images.ctfassets.net/23aumh6u8s0i/4B3dtmy6UvsQFbHlmPwT7f/8bb54eb4a820fca359f3c0c23742d6cd/getting-authentication-events-in-realtime-with-auth0-and-pusher-rules-first-time)

Rules are JavaScript functions that are executed in Auth0 every time a user authenticates to your application to extend Auth0's capabilities. You can learn more about them in the intro of this section or in the [rules documentation](https://auth0.com/docs/rules).

When creating a rule, you can choose one of many pre-defined templates depending on what you want to do.

![Auth0 Rules Templates](https://images.ctfassets.net/23aumh6u8s0i/61a49YXQ4v5KxZ5MqHz8dr/437013ad071604c2cde507de6e060d80/getting-authentication-events-in-realtime-with-auth0-and-pusher-pick-rule-template)

You can click on as many templates as you like to see their code; the rule won't be saved until you explicitly save it. For our purposes, we're going to choose the *empty rule* template.

![Auth0 Creating a rule](https://images.ctfassets.net/23aumh6u8s0i/72EM6NqdGLEGrStkHAuX1Q/7577f550910425e9616c320882c1f6ea/getting-authentication-events-in-realtime-with-auth0-and-pusher-create-rule)

The function has the following arguments:

- `user`. The object with the user information. This will vary depending on the identity provider the user used to authenticate, but you can see the general structure of this object [here](https://auth0.com/docs/user-profile/user-profile-structure).
- `context`: An object containing information of the authentication. You can find a complete list of context properties [here](https://auth0.com/docs/rules/context).
- `callback`. A function to send the result of the function and the (potentially modified) user and context objects back to the login app. It's important to always call this function, or else the script will timeout.

So let's start by requiring the Pusher module:

``` javascript
function (user, context, callback) {
  var Pusher = require('pusher@1.2.1');

  callback(null, user, context);
}
```
The code of this function runs in a JavaScript sandbox on [webtask.io](https://webtask.io/) where you can use ECMAScript 5 and some supported sandbox modules (see the modules supported [here](https://tehsis.github.io/webtaskio-canirequire)). Luckily, Pusher is of them.

Now, remember your Pusher app info? We'll need it here to create the Pusher instance:

``` javascript
function (user, context, callback) {
  ...

  var pusher = new Pusher({
    appId: '<INSERT_YOUR_PUSHER_APP_ID>',
    key: '<INSERT_YOUR_PUSHER_APP_KEY>',
    secret: '<INSERT_YOUR_PUSHER_APP_SECRET>',
    cluster: '<INSERT_YOUR_PUSHER_APP_CLUSTER>',
    encrypted: true
  });

  callback(null, user, context);
}
```
The next line introduces the concept of user metadata:

``` javascript
function (user, context, callback) {
  ...

  user.app_metadata = user.app_metadata || {};

  callback(null, user, context);
}
```
If we want to store additional information about a user, Auth0 recommends to do it in a property of the user object called `app_metadata`.

We'll want to make a distinction between a sign up and a log in, however, since Auth0 doesn't have a way to tell us this. We'll have to set a flag manually, so this line creates an empty object if `app_metadata` is empty (which will be the case at sign up).

Moving on, let's define the channel where we will be publishing and the default event (when the user signs up). Events are the primary method of packaging messages in Pusher. Learn more about them [here](https://pusher.com/docs/client_api_guide/client_events).

``` javascript
function (user, context, callback) {
  ...

  var channel = 'auth0';
  var event = 'user-signedUp';

  callback(null, user, context);
}
```
We're going to send the user object to Pusher, so let's create a [deep copy](https://blog.imaginea.com/deep-copy-in-javascript/) of this object (so neither this or the original object can be affected by later modifications) and add the name of the country where the user is logging in from the context object:

``` javascript
function (user, context, callback) {
  ...

  var userClonedObj = JSON.parse(JSON.stringify(user));
  userClonedObj.country = context.request.geoip.country_name;

  callback(null, user, context);
}
```
Next, we check if there's a `signedUp` flag because this would mean that the event is a log in and we'd have to change the event name. If it doesn't exist, the event is a sign up so we set it and update the user object with the function `auth0.users.updateAppMetadata`.

``` javascript
function (user, context, callback) {
  ...

  if (user.app_metadata.signedUp) {
    event = 'user-loggedIn';
  } else {
    user.app_metadata.signedUp = true;
    auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
  }

  callback(null, user, context);
}
```
Finally, we send the object to Pusher.

``` javascript
function (user, context, callback) {
  ...

  pusher.trigger(channel, event, userClonedObj);

  callback(null, user, context);
}
```

You can check the full code of the function in this [gist](https://gist.github.com/eh3rrera/00ee1aeb462777736f4e441694662c5d).

Now, let's test the integration with Pusher. Open the debug console of your app on the [Pusher dashboard](https://dashboard.pusher.com) in another window/tab. Then, back to your rule, click the *Try this rule* button with some dummy data.

![Testing Auth0 Rule](https://images.ctfassets.net/23aumh6u8s0i/6aqJQKSeLqby54ApYvETO4/0d2720da2fe9d2a77a005c6ae6be0c71/getting-authentication-events-in-realtime-with-auth0-and-pusher-try-rule)

In the [Pusher dashboard](https://dashboard.pusher.com), you'll see the event when it's sent to Pusher:

![Pusher debug](https://images.ctfassets.net/23aumh6u8s0i/6OKD5mDi4m5JaPh1DkftFv/95c1b1ddee81752c66185ee035976ba3/getting-authentication-events-in-realtime-with-auth0-and-pusher-debug-pusher)

Now let's set up a sample login page with Auth0.

## Setting up a login page with Auth0

For this tutorial, we're just going to use the demo project you downloaded when the Auth0 client was created (if you don't have it, return to the *Clients* section and go to the *Quick start* tab).

Unzip it, `cd` into it, and execute `npm install` to download the dependencies. Then, execute `npm start` and open in a browser `http://localhost:3000`. Something like this should be shown:

![Auth0 Lock](https://images.ctfassets.net/23aumh6u8s0i/3gpaPPcUB46Nz7uHm33Dsz/a654eb53c98b54d5c4ffd9ccefb8835f/getting-authentication-events-in-realtime-with-auth0-and-pusher-login-01)

Leave it open, we'll return to it in a few moments.

## Creating a realtime feed with Pusher and React

We'll use [Create React App](https://github.com/facebookincubator/create-react-app) to create this feed application. You can install (or update) it with:

``` bash
npm install -g create-react-app
```
And create the project with:

``` bash
create-react-app auth0-pusher-feed
```
Next, `cd` into your app's directory and install the Pusher module with either NPM or Yarn:

``` bash
yarn add pusher-js
or
npm install --save pusher-js
```
Let's modify the file `src/App.css` to give a custom style to our application:

``` css
.App {
  text-align: center;
}

.App-header {
  background-color: #222;
  padding: 20px;
  color: white;
}

.evts {
  list-style: none;
  max-width: 600px;
  margin: 0 auto;
  padding: 1.5em 2em;
}

.evts .evt {
  margin-bottom: 1.1em;
  padding-top: 1.5em;
  line-height: 1.5em;
}

.evts .evt + .evt {
  border-top: 1px solid #000;
}

.evts .evt-name {
  color: #172935;
  font-weight: bold;
  margin-bottom: 1em;
}

.evts .evt-email {
  font-weight: bold;
}

.evts .evt-date {
  margin-top: 0.5em;
  font-style: italic;
}

.evts .evt-from {
  font-style: italic;
}
```
Now go to `src/App.js` and change the `render` method to:

``` javascript
render() {
    return (
      <div className="App">
        <div className="App-header">
          <h2>Realtime Feed with Auth0 + Pusher</h2>
        </div>
        <Events events={this.state.events} />
      </div>
    );
}
```
Our React app will have an `Events` component that will be the container of `Event` components:

![React app structure](https://images.ctfassets.net/23aumh6u8s0i/4cFXmLtg1yIL7KcjBG67iz/7c14530a3403a9da8b8cfac1bdb38f18/getting-authentication-events-in-realtime-with-auth0-and-pusher-react-structure)

So let's import the modules we'll use:

``` javascript
...
import Events from './Events';
import Pusher from 'pusher-js';

class App extends Component {
  ...
}
```
In the component's constructor, define an array to hold the authentication events as the state and bind the function that will update this array:

``` javascript
class App extends Component {
  constructor(props) {
    super(props);
    this.state = {
      events: [],
    };
    this.updateEvents = this.updateEvents.bind(this);
  }
  ...
}
```
In [componentDidMount()](https://facebook.github.io/react/docs/react-component.html#componentdidmount), let's set up Pusher, subscribe to the `auth0` channel and bind the events `user-signedUp` and `user-loggedIn` (these identifiers were defined in the Auth0 rule):

``` javascript
class App extends Component {
  ...
  componentDidMount() {
    this.pusher = new Pusher('<INSERT_YOUR_PUSHER_APP_KEY>', {
      cluster: '<INSERT_YOUR_PUSHER_APP_CLUSTER>',
      encrypted: true,
    });

    this.channel = this.pusher.subscribe('auth0');
    this.channel.bind('user-signedUp', this.updateEvents);
    this.channel.bind('user-loggedIn', this.updateEvents);
  }
  ...
}
```
For this simple example, we're going to show the messages of the sign up and log in events in the same feed. This way, the `updateEvents` function just has to insert the object we're receiving at the beginning of the `events` array:

``` javascript
class App extends Component {
  ...
  updateEvents(data) {
    this.setState({
      events: [ data, ...this.state.events ],
    });
  }
  ...
}
```
The events are passed as a property of the `Events` component, which translates it to`Event` components:

``` javascript
import React, { Component } from 'react';
import Event from './Event';

export default class Events extends Component {

  render() {
    const eventsMapped = this.props.events.map((result, index) => {
      const key = this.props.events.length - index;
      return <Event event={result} key={key} />
    });

    return <div className={'evts'}>
             {eventsMapped}
           </div>;
  }
}
```
Finally, this `Event` component just extracts the properties we want to show and renders them:

``` javascript
import React, { Component } from 'react';

export default class Event extends Component {

  render() {
    const {email, updated_at, country} = this.props.event;
    const event = this.props.event.app_metadata.signedUp ? 'Log In:' : 'Sign Up:';
    return (
        <li className={'evt'}>
          <div className={'evt-name'}>{event}</div>
          <div className={'evt-email'}>{email}</div>
          <div className={'evt-date'}>{updated_at}</div>
          <div className={'evt-from'}>From {country}</div>
        </li>
    );
  }
}
```
At this point, if we want to run it, we'll have a problem because the login app is already listening on the port 3000. We can solve this by creating a `.env` file to specify another port, let's say 5000:

``` bash
PORT=5000
```
And that's it, let's test it.

## Testing the application

Make sure the login and the feed apps are running by executing `npm start` on both.

Click on the *Login* button and sign up with either your Google account or by entering an email/password:

![React quickstart login](https://images.ctfassets.net/23aumh6u8s0i/1KzSx1Ps8E3q0qqQJ1GkKm/76d68dbd55c9bee3509d82866fc1f8bd/getting-authentication-events-in-realtime-with-auth0-and-pusher-login-popup)

When you log in or sign up in one app, the event will be shown in the other one.

![React app final](https://images.ctfassets.net/23aumh6u8s0i/HEeFqSaPj9boLjY4t89XB/d4fb518b0440562e5a33249ec6c07261/getting-authentication-events-in-realtime-with-auth0-and-pusher-final-app)

> Auth0 provides the simplest and easiest to use [user interface tools to help administrators manage user identities](https://auth0.com/user-management) including password resets, creating and provisioning, blocking and deleting users. [A generous **free tier**](https://auth0.com/pricing) is offered so you can get started with modern authentication.

## Conclusion

In this tutorial, we have seen how to integrate two services to implement complex functionality that would have been difficult to implement manually.

We learned how to implement a basic authorization mechanism with Auth0 and extend it with rules. We also learned how to create realtime applications with Pusher's publish/subscribe model.

Of course, you can extend these applications by adding more login options, publishing more information, chaining other rules, or by using charts, for example, to present the information in other ways.

Remember that you can find the code of the feed in this [repo](https://github.com/eh3rrera/auth0-pusher-feed) and you can learn more about [Auth0](https://auth0.com/docs) or [Pusher](https://pusher.com/docs/) in their documentation and by creating free accounts for both services.


Get Realtime Authentication Events with Auth0 and Pusher

diegopoza

System Engineer, geek, foodie, technology lover, speaker.

Sr Manager, Developer Advocacy

Diego Poza

Using Auth0 Rules, all your SaaS tools can become part of your authentication procedure



At Auth0 we do what we do best—user authentication.  SaaS is all about these types of specialities. Any SaaS company should concentrate on what it does best, and outsource the rest. You should use SaaS providers for your analytics, your customer communication, your storage, and, of course, your user authentication.

This makes it all the more important that any SaaS provider you use integrates with others, sharing data, and providing both you and your customers with a seamless experience. That’s why we developed [Rules](https://auth0.com/docs/rules).

## What Are Rules?

Rules are Javascript code snippets that run as part of a customized login process on Auth0 servers.

![How rules work](https://images.ctfassets.net/23aumh6u8s0i/3X9mYmKdLN5YJIpXikBfOZ/38fc334ebbd71a1a4112ade6ab5cf6ba/rules-diagram)

* Step 1: Your app initiates an authentication request to Auth0.
* Step 2: Auth0 routes the request to an Identity Provider through a configured connection.
* Step 3: The user authenticates successfully.
* Step 4: The `user` object representing the logged in user is passed through the Rules pipeline and returned to the app.

This entire process is executed as part of the Auth0 authentication process—no extra infrastructure or code is needed on your servers. Each Rule is passed 3 parameters:

1. A `User` object that comes from the identity provider
2. A `Context` object which contains information about the current login, such as the device used, or where the login was attempted.
3. A `Callback` indicating whether the Rule was successfully completed or not.

With just this information, you can use Rules to handle specific requirements of your app, and pass important user data to any of your SaaS providers. For authentication, you could:

* Limit logins to a specific region
* Add information to a user profile, such as their security role
* Check the user's last password reset

Using your other SaaS providers, you could:

* Enrich the customer profile using external sources
* Add login events and user information to your analytics platform
* Trigger external events such as email campaigns or Slack notifications

Each of these would run immediately up on login.

## Why Use Rules?
The following are some of the reasons of why you should use rule.

1. **Improved reporting accuracy:** Events that are triggered server-side complete with a much higher degree of confidence than those that are attempted client-side, which can be blocked by firewalls, errant browser extensions, or code errors
2. **Real-time updates:** Depending on the service you are implementing with Rules, you can get real-time updates of user sign-ins, along with any data you sent via the API.
3. **Easy to create & run:** Implementation is through just a few lines of Javascript in our webtask sandbox. No extra technical debt or product development required.
4. **Sequencing:** Any number of Rules can be run on log in. That means that you can run each of the 4 Rules, and more, below each time a user logs in.


## Some examples of how to integrate your SaaS tools with Auth0
Let's see some of the most popular SaaS tools that are used by our users.

### Send New User Emails Through Mailgun
<div class="" style="text-align: center;"><img style="margin: 0;" src="https://images.ctfassets.net/23aumh6u8s0i/7pk7OMhEep6M2nojo28yUb/63b5af713154e0edba84d570190835f0/Mailgun" alt="Mailgun" />
</div>


[Mailgun](http://www.mailgun.com/) is a set of APIs that allow you to send, receive, and track email through code. It manages the delivery process to improve delivered rates, and produces analytics of why emails weren’t delivered.

If you’re using Mailgun for your email delivery, you can set up a Rule that will send new users an initial email when they first sign up

The persistent property `SignedUp` tracks whether this is the first login or subsequent ones.

```
function (user, context, callback) {
  user.app_metadata = user.app_metadata || {};
  if (user.app_metadata.signedUp) {
    return callback(null, user, context);
  }

  const request = require('request');

  request.post( {
    url: 'https://api.mailgun.net/v3/{YOUR MAILGUN ACCOUNT}/messages',
      auth:
      {
        user: 'api',
        pass: configuration.MAILGUN_API_KEY
      },
    form: {
      'to': 'admin@example.com',
      'subject': 'NEW SIGNUP',
      'from': 'admin@example.com',
      'text': 'We have got a new sign up from: ' + user.email + '.'
    }
  }, function(err, response, body) {
    if (err) return callback(err);
    if (response.statusCode !== 200) return callback(new Error('Invalid operation'));

    user.app_metadata.signedUp = true;
    auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
      .then(function(){
        callback(null, user, context);
      })
      .catch(function(err){
        callback(err);
      });
  });
}
```

The same type of Rule can easily be changed to [send an email to an administrator](https://github.com/auth0/rules/blob/master/src/rules/mailgun.js) on that initial sign in.

Find this rule [here](https://github.com/auth0/rules/blob/master/src/rules/mailgun.js).

### Tracks Logins In MixPanel
<div class="" style="text-align: center;"><img style="margin: 0;" src="https://images.ctfassets.net/23aumh6u8s0i/7Eh1Ul4ndgBu5SIJiDVc7Q/14e22613eb16bc4eae46f3ece65a8ec2/Mixpanel" alt="Mixpanel" />
</div>

Analytics are only as powerful as the underlying data. Adding an analytics Rule to your signing in process allows you to not only track individual logins with your preferred analytics SaaS provider, but also pass your analytics user-specific data to use.

<include src="TweetQuote" quoteText="Analytics are only as powerful as the underlying data."/>

This Rule sends [MixPanel](https://mixpanel.com/) a `Sign In` event and includes the application the user is signing in to as a property.

```
function (user, context, callback) {

  const mpEvent = {
    "event": "Sign In",
    "properties": {
        "distinct_id": user.user_id,
        "token": configuration.MIXPANEL_API_TOKEN,
        "application": context.clientName
    }
  };

  const base64Event = Buffer.from(JSON.stringify(mpEvent)).toString('base64');

  request.get({
    url: 'http://api.mixpanel.com/track/',
    qs: {
      data: base64Event
    }
  }, (err, res, body) => {
      // don’t wait for the MixPanel API call to finish, return right away (the request will continue on the sandbox)`
      callback(null, user, context);
  });
}
```

This event will immediately be available in your Mixpanel dashboard, and available to analyze.

Find this rule [here](https://github.com/auth0/rules/blob/master/src/rules/mixpanel-track-event.js).

### Creates A New Lead In Salesforce On First Login
<div class="" style="text-align: center;"><img style="margin: 0;" src="https://images.ctfassets.net/23aumh6u8s0i/4kkgTIFYLbcSQ3VHyZ9cPE/15875c8b171a5f090430f676dc54013a/Salesforce" alt="Salesforce" />
</div>

Customer Relationship Management (CRM) tools are a mainstay of modern sales. However, they have a common weakness—the salespeople.  Salespeople often forget to update their CRM, impacting the sales analytics for the company as well as their own sales pipeline.

Automating as much of the data entry process as possible is therefore important for sales teams. This Rule automates the generation of a new Lead in the Salesforce CRM when a user logs in to your app for the first time.

It checks whether this is the first login, then calls the Salesforce API to record the contact as a new Lead. It is using Salesforce REST APIs and the `resource owner` flow to obtain an `access_token`.

```
function (user, context, callback) {
  user.app_metadata = user.app_metadata || {};
  if (user.app_metadata.recordedAsLead) {
    return callback(null,user,context);
  }

  const MY_SLACK_WEBHOOK_URL = 'YOUR SLACK WEBHOOK URL';
  const slack = require('slack-notify')(MY_SLACK_WEBHOOK_URL);

  //Populate the variables below with appropriate values
  const SFCOM_CLIENT_ID = configuration.SALESFORCE_CLIENT_ID;
  const SFCOM_CLIENT_SECRET = configuration.SALESFORCE_CLIENT_SECRET;
  const USERNAME = configuration.SALESFORCE_USERNAME;
  const PASSWORD = configuration.SALESFORCE_PASSWORD;
  getAccessToken(
    SFCOM_CLIENT_ID,
    SFCOM_CLIENT_SECRET,
    USERNAME,
    PASSWORD,
    (response) => {
      if (!response.instance_url || !response.access_token) {
        slack.alert({
          channel: '#some_channel',
          text: 'Error Getting SALESFORCE Access Token',
          fields: {
            error: response
          }
        });

        return;
      }

      createLead(
        response.instance_url,
        response.access_token,
        (err, result) => {
        if (err || !result || !result.id) {
          slack.alert({
            channel: '#some_channel',
            text: 'Error Creating SALESFORCE Lead',
            fields: {
              error: err || result
            }
          });

          return;
        }

        user.app_metadata.recordedAsLead = true;
        auth0.users.updateAppMetadata(user.user_id, user.app_metadata);
      });
    });

  //See http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_objects_lead.htm
  function createLead(url, access_token, callback){
    //Can use many more fields
    const data = {
      LastName: user.name,
      Company: 'Web channel signups'
    };

    request.post({
      url: url + "/services/data/v20.0/sobjects/Lead",
      headers: {
        "Authorization": "OAuth " + access_token
      },
      json: data
      }, (err, response, body) => {
        return callback(err, body);
      });
  }

  //Obtains a SFCOM access_token with user credentials
  function getAccessToken(client_id, client_secret, username, password, callback) {
    request.post({
      url: 'https://login.salesforce.com/services/oauth2/token',
      form: {
        grant_type: 'password',
        client_id: client_id,
        client_secret: client_secret,
        username: username,
        password: password
      }}, (err, respose, body) => {
        return callback(JSON.parse(body));
      });
  }

  // don’t wait for the SF API call to finish, return right away (the request will continue on the sandbox)`
  callback(null, user, context);
}
```

This Rule also includes another benefit of using Rules: easy error handling. If the Rule can’t complete, it sends an error message to a designated Slack channel, so the sales team knows an error has occurred and can update Salesforce manually.

Find this rule [here](https://github.com/auth0/rules/blob/master/src/rules/creates-lead-salesforce.js).

### Checking Fraud With MinFraud
<div class="" style="text-align: center;"><img style="margin: 0;" src="https://images.ctfassets.net/23aumh6u8s0i/4eWQePJxWGFoO9PLOYwECu/1898fb8e93d65aa5fa776a80a7b10e1e/Minfraud" alt="Minfraud" />
</div>

MinFraud identifies possible fraud in online transactions, as well as suspect account logins and signups. The service uses factors such as geolocation, IP address, email, device and proxies to determine the likelihood a transaction is fraudulent.

This rule will send the user’s IP address, email address, and username (both in MD5 format) to MaxMind’s MinFraud API. The API will return the risk score for the transaction and this information can be leveraged within the Rule to block a login with a high risk score.

```
function (user, context, callback) {
  const querystring = require('querystring');
  const request = require('request');
  const crypto = require('crypto');

  const MINFRAUD_API = 'https://minfraud.maxmind.com/app/ccv2r';

  const data = {
    i: context.request.ip,
    user_agent: context.request.userAgent,
    license_key: configuration.MINFRAUD_LICENSE_KEY,
    emailMD5: user.email &&
        crypto.createHash('md5').update(user.email).digest("hex") || null,
    usernameMD5: user.username &&
        crypto.createHash('md5').update(user.username).digest("hex") || null
  };

  request.post(MINFRAUD_API, { form: data, timeout: 3000 }, (err, res, body) => {
    if (!err && res.statusCode === 200) {
      const result = querystring.parse(body, ';');

      console.log(`Fraud response: ${JSON.stringify(result, null, 2)}`);

      if (result.riskScore && (result.riskScore * 100) > 20) {
        return callback(new UnauthorizedError('Fraud prevention!'));
      }
    }

    if (err) {
      console.log(`Error while attempting fraud check: ${err.message}`);
    }
    if (res.statusCode !== 200) {
      const message = err && err.message;
      console.log(`Unexpected error while attempting fraud check: ${message}`);
    }

    // If the service is down, the request failed, or the result is OK just continue.
    return callback(null, user, context);
  });
}
```

Find this rule [here](https://github.com/auth0/rules/blob/master/src/rules/fraud-prevention-with-minfraud.js).

## Wrapping up: Customizing Rules

These are only a few examples. Any of these Rules can be customized to your other SaaS tools and your apps needs. Using the Auth0 Dashboard, you can use these or any other template to start using Rules in your app right now, or you can build your own unique Rule for your SaaS. The power is there for you to use it.

![Auth0 provides lots of rule templates for you](https://images.ctfassets.net/23aumh6u8s0i/1fNZnT7jGdQNx37jn1Co3v/c15a5c3ed2501b8c958e715c1ca31f02/rule-templates)

[Unlock B2B SaaS growth with modern identity management. Download free eBook here.](https://resources.auth0.com/unlock-b2b-saas-growth-iam/)


"auth0-rules"