Daniel Krzyczkowski

Founder of Tech Mind Factory. Works as a Cloud & Identity Engineer, helping organizations design, build, and deploy modern identity solutions and secure cloud applications.



Tech Mind Factory

Automate Auth0 configuration with GitHub Actions. Manage tenants across dev, test, and prod environments with CI/CD.

Scaling Identity: Implementing CI/CD with the Terraform and GitHub Actions

Meina Liu

Meina Liu is a Technical Product Marketing Manager Intern with a focus on the convergence of identity, security, and artificial intelligence (AI). Currently studying Computer Science on the AI track at Stanford University, she works at the intersection of engineering and go-to-market strategy. Over the past year on the Auth0 team, she built deep-dive demos, technical architectures, and authored blogs for features ranging from Actions to Fine Grained Authorization (FGA), and more. She is passionate about leveraging her engineering background to build solutions that help developers integrate secure identity infrastructure with ease.

Technical Product Marketing Manager Intern 

Auth0 Multiple Custom Domains and Auth0 Actions create a seamless, branded login experiences across multiple applications from a single tenant.

Multi-Brand Identity Simplified with Auth0 Multiple Custom Domains

Khush Kaushal 

Khush Kaushal is Senior Software engineer with a focus on building intelligent, secure identity systems. He works at the intersection of large-scale authentication infrastructure and applied ML, developing models and features that enhance fraud detection, risk-based authentication, and adaptive access control. With deep expertise in full-stack development, distributed systems, and production ML pipelines, he is passionate about creating AI-driven solutions that make digital identity both seamless for users and robust against evolving threats.

Senior Software Engineer

Khush Kaushal

Matthew-w

Director, Threat Intelligence

Mathew Woodyard

Learn how to mitigate the risks of Bulletproof Hosting providers using Auth0 Actions and threat intelligence signals to secure your identity infrastructure.

Bulletproof Hosting Defense: Mitigating the Proxy Threat with Threat Intelligence

Sam Yapkowitz

I began my career in enterprise software development and got exposure to lots of different frameworks and methodologies. I quickly realized my passion was in the architecture and design of solutions to unique problems. I now get to use these skills to help my customers build high-quality experiences using Okta. When not at work you can find me on the golf course, playing Rocket League or watching football with my friends.

Senior Solutions Engineer

Learn how to implement an effective, low-friction honeypot trap using Auth0 Universal Login and Actions to stop spam registration bots.

Honeypots: A Simple Trap for Spam Registration Bots

brandon-warner

Solutions Engineer, Auth0

Brandon Warner

Discover how Auth0's Actions Transaction Metadata simplifies authentication flows by providing a dedicated, efficient way to store and pass variables between Actions, reducing API usage and improving performance.

Introducing Transaction Metadata for Auth0 Actions

raphael-do-vale

Raphael has more than two decades of experience in developing enterprise systems including coding, project planning, architecture, and specification. His technology stack includes Java, Spring, Python, Relational Databases, JavaScript, DevOps, and Artificial Intelligence. He has a PhD and Master's degree in the Semantic Web, winning awards during his studies. He also worked with Description Logic, Prolog, RDF, and OWL tech.

Raphael do Vale

This tutorial demonstrates how to implement asynchronous authorization in a LangGraph application using Auth0 and the CIBA flow for secure, human-in-the-loop actions

Implementing Asynchronous Human-in-the-Loop Authorization in Python with LangGraph and Auth0

Michelle Agroskin

Michelle Agroskin is a Staff Product Marketing Manager for Okta. She leads the Customer Identity AI, Authorization, and Consumer portfolios; driving go-to-market strategy, messaging, launches, and strategic growth initiatives.

She lives in NYC and in her free time, loves to travel the world and try new restaurants!

Staff Product Marketing Manager, Auth0

Secure AI agents need more than context. MCP + Auth0 combines identity and control for safe, scalable, autonomous actions.

AI agents are moving from helpful assistants to autonomous actors. They don’t just summarize documents or answer questions—they take actions on our behalf: managing calendars, filing support tickets, and even completing purchases.

To do any of that, they need context. Who is the user? What are they allowed to do? What’s happening in the session?

Today, delivering that context to an agent is messy and ad hoc. That’s where the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2025-03-26/index) comes in—a new specification designed to standardize how context is passed to AI models.

At Auth0, we believe **MCP is necessary but insufficient**.

It’s a great first step, but it **must be paired** **with robust identity and access controls**. Without them, AI agents operate on blind trust, which is a massive security and privacy risk.

This is where identity standards like OAuth 2.0 and OIDC, alongside tools like Auth0, come in.

## The Rise of Capable AI Agents (and Why Context Matters)

AI agents are growing more capable. Developers are building agents that can:

* Query internal systems and databases
* Execute transactions
* Act as customer support reps or internal assistants
* Chain together APIs and services to complete user goals

However, to act effectively and safely, these agents need access to **context**—structured information about the user, their permissions, their past behavior, and their intent. Without context, the agent is just guessing.

Today, there’s no standard way to pass that context. Developers are building custom solutions—often without a strong security model.

## MCP: A Powerful Foundation for Context

MCP is a crucial step toward solving this. Created by Anthropic, MCP provides a standardized payload format for delivering relevant information to AI agents—user identity hints, permissions, claims, and more.

We applaud the teams defining this specification. Standardization helps agents interoperate, improves developer experience, and lays the groundwork for more powerful agent behavior.

But here’s the catch:

> MCP does not secure the payload. It defines _what_ context can be sent—not _who_ can send it, whether they’re authorized, or what the agent can do with it.

This creates significant risk:

* **Anyone** could invoke an agent.
* **Any context** could be injected—true or not.
* **Any action** could be taken on behalf of a user.

MCP is the envelope. But we still need to know who can send it and what the recipient can do with it.

## The Critical Missing Layer: Identity 

Passing sensitive data or enabling agent actions without robust authentication and authorization is dangerous. We can think of MCP without security the same way as an API endpoint without security – both are just communication protocols, and security must be layered on top. The lack of security could cause:

* **Impersonation** – Malicious actors pretending to be someone else (i.e., who is really invoking the agent and providing context?)
* **Data leakage** – Agents receiving context they shouldn’t have access to (i.e., is the context provider authorized to share this specific user data?)
* **Privilege escalation** – Tricking an agent into acting beyond its scope (i.e., can the agent be tricked into performing actions the user isn’t authorized to do?)
* **Compliance violations** – handling sensitive data without proper controls (GDPR, CCPA, HIPAA, etc.)

These aren’t hypothetical. AI agents will soon be responsible for customer interactions, business workflows, and system integrations. We can’t afford to leave their security to chance. MCP needs a robust mechanism to verify the *source* of the context and authorize *what* context is shared and *what* actions the agent can subsequently take. 

Security must be built in—not bolted on.

## Identity Protocols Are the Key

Thankfully, we don’t need to invent a new solution.

> Established identity standards—OAuth 2.0 and OpenID Connect (OIDC)—are perfectly suited to solve this problem.

They are mature, well-understood standards for delegated **authorization** and **authentication** and provide the exact tools MCP needs:

* **OIDC**: Authenticates the entity (user, system, or service) interacting with the agent.
* **OAuth 2.0**: Authorizes what context can be shared and what the agent can do on the user’s behalf—using scopes, access tokens, and delegated permissions.

This makes it possible to:

* Ensure **only authenticated users or systems** can invoke the agent.
* Use **granular scopes** to control what context is sent in the MCP payload.
* Define what downstream **actions** an agent is allowed to take—based on token claims.

As Aaron Parecki notes in [his breakdown of OAuth for MCP](https://aaronparecki.com/2025/04/03/15/oauth-for-model-context-protocol), these protocols map cleanly onto the challenges MCP doesn’t solve.

## Auth0 Is the Bridge

This is where **Auth0 fits in.**

> **Auth0 is uniquely positioned to operationalize secure MCP implementations.** Our platform brings OAuth 2.0 and OIDC to agents to enable more secure and scalable workflows. 

We’re investing in new capabilities designed specifically for AI security, including:

* **User authentication** to easily implement secure login experiences for AI agents, from interactive chatbots to background workers.
* **Token Vault** to securely call APIs like Google, Slack, Spotify, and Github on users’ behalf while seamlessly integrating an application with other products.
* **Async Authorization** to enable autonomous agents to work independently while maintaining user control by getting explicit user approval for critical actions. 
* **Fine-grained authorization for RAG** to enforce granular permissions for document retrieval and helps ensure AI agents only access authorized content. 

![Capabilities and Features](https://images.ctfassets.net/23aumh6u8s0i/6SiMeLDwE0oAw9dSJnQOkF/40ebf7b7f1033880123f93597342ffe2/Capabilities_and_features.png)

And because this builds on existing identity infrastructure, you get the benefits of:

* Developer familiarity
* Reduced integration overhead
* Centralized policy management
* Better auditability and compliance

We make securing AI agents feel like a natural extension of your current Auth0 implementation—not a one-off hack.

## A Real-World Scenario

Let’s walk through what this looks like in practice:

1. A user logs into your customer support portal—powered by Auth0.
2. The app requests an access token with scopes like `read:user_profile`, `read:recent_orders`.
3. Auth0 authenticates the user and issues a signed token containing relevant claims.
4. The application constructs an MCP payload using claims from the token.
5. The AI agent receives the payload, verifies the token, and uses only the authorized context to respond.
6. Later, the user says, “Reorder my last purchase.” The agent requests a new token with the scope `execute:reorder`, prompting the user to re-consent via OAuth.
7. Auth0 issues the new token. The agent performs the action—securely, transparently, and with the user’s permission.

Every step is authenticated. Every action is authorized. Check out more examples on our [documents page](https://auth0.com/ai/docs).

## The Bottom Line: Secure AI Starts with Identity

AI agents are the next interface frontier—but only if we get security right.

> MCP is foundational—but without an Identity solution, it’s not safe for real-world use.

Auth0 provides the missing layer—bringing identity, permissioning, and governance to the world of AI agents. Our platform makes it possible to adopt MCP without compromising on trust, compliance, or control.

[Learn more](http://auth0.com/ai) about securing AI interactions, read our [documentation](https://auth0.com/ai/docs), and [contact us](https://auth0.com/contact-us) to discuss your AI security needs.


MCP + Auth0: An Agentic Match Made in Heaven

I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Staff Developer Advocate

Juan Cruz Martinez

Learn how to leverage Auth0 Actions to create custom MFA (Multi-Factor Authentication) workflows, enforce enrollment of users based on specific conditions, and validate user authentication.

Multi-factor authentication (MFA) is an essential security measure that helps to protect your organization's data and assets. By requiring users to provide an additional authentication factor, such as a security token or fingerprint, in addition to their username and password, MFA can significantly reduce the risk of unauthorized access.

However, implementing MFA can sometimes create friction in the user experience, potentially leading to frustration and reduced productivity. Additionally, not all users or scenarios may require the same level of security, making a one-size-fits-all MFA approach impractical.

Auth0 Actions is a powerful feature that allows you to customize and extend the functionality of Auth0. With Actions, you can create custom workflows that trigger in response to specific events, such as user login or registration. This enables you to tailor your MFA implementation to meet your organization's specific needs.

For example, you can use Actions to:

- **Enforce MFA based on user roles or permissions**: You can require certain users, such as administrators or those with access to sensitive data, to use MFA while allowing others to bypass it.
- **Implement risk-based authentication**: You can use Actions to assess the risk level of a login attempt based on factors such as the user's location, device, and IP address. If the risk is high, you can then require the user to provide an additional factor of authentication.

## Prepare your Tenant

Before diving into customizing your Multi-Factor Authentication (MFA) flows, let's make sure we have the essentials in place. This quick guide will walk you through the initial setup steps:

- **Activate MFA**: Head over to your Auth0 Dashboard (<a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID"  data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Get a free account</a> if you don't already have one) and navigate to [Security > Multi-factor Auth](https://manage.auth0.com/#/security/mfa). Here, you'll be able to activate MFA for your tenant.

- **Choose Your Factors**: [MFA comes in various forms](https://auth0.com/blog/not-all-mfa-is-created-equal/). Decide which factors suit your security needs and enable them on the same Multi-factor Auth page. You might choose options like push notifications, SMS codes, or even biometrics.
    ![Auth0 Dashboard > Security > Multi-factor Auth](https://images.ctfassets.net/23aumh6u8s0i/5NSKKAcGSjkj40ZkTmUlDD/3165f217e14e7a85b9f0304695fdf9d5/MFA_Auth.png)

- **Enable Customization**: To personalize your MFA flows, toggle on the "Customize MFA Factors using Actions" setting. This is like unlocking a secret level – it opens the door to fully customized experiences for your users.
    ![Auth0 Dashboard > Security > Multi-factor Auth > Additional Settings](https://images.ctfassets.net/cdy7uua7fh8z/2hv0ELTkkka3t230SXfxw/46def5395652b2451cfc9e0ad01a371a/MFA_actions.png)

> Actions with `enrollWith` or `enrollWithAny` commands override any existing policies or rules that enable or disable MFA in a tenant.

## Understand the APIs

Once you've enabled Multi-Factor Authentication (MFA) in your Auth0 tenant, you can go beyond the basic settings and create truly customized enrollment flows using Auth0 Actions. Actions are snippets of code that run at specific points in the user's authentication journey, giving you granular control over your authentication workflow and, in particular, how MFA is presented.

To customize your MFA experiences, Auth0 Actions provides a set of APIs designed for enrollment and requiring authentication challenges. Here's a breakdown of the four key APIs you can use: 

### `enrollWith(factor, options)`

Initiates MFA enrollment for a specific factor (e.g., `otp`, `push-notification`, `webauthn-roaming`, etc. Visit the docs to learn about [all supported values](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow/api-object#:~:text=api.authentication.enrollWith(factor%2C%20options)).

Example:

```javascript
api.authentication.enrollWith({type: 'otp'})
```

### `enrollWithAny(factors)`

Similar to `enrollWith` but prompts the user to select an MFA factor to enroll in from the supplied list.

Example:

```javascript
api.authentication.enrollWithAny([{type: 'otp'}, {type: 'webauthn-roaming'}])
```

### `challengeWith(factor, options)`

Challenge the user with one or more specified multifactor authentication factors. This method presents the default challenge first, then allows the user to select a different option if additional factors have been supplied. If the user has not enrolled in any of the factors supplied (including both the default and any additional factors), the command fails.

Example:

```javascript
api.authentication.challengeWith({type: 'otp'})
```

### `challengeWithAny(factors)`

Trigger a MFA challenge and allow the user to select their preferred factor from the supplied list.

Example:

```javascript
api.authentication.challengeWithAny([{type: 'otp'}, {type: 'webauthn-roaming'}])
```

## Create a New Auth0 Action

To begin, let's create a new [Auth0 Action](https://auth0.com/docs/customize/actions/actions-overview). Actions are serverless functions that run in a secure Auth0 environment.

To create an Action, log into your [Auth0 Dashboard](https://manage.auth0.com/#/actions/flows), select Actions from the left sidebar menu, then select Flows. This page shows the different flows you can customize. For our use case, we’ll choose the “Login” flow.

![The “Actions” page of the Auth0 dashboard.](https://images.ctfassets.net/23aumh6u8s0i/3Es0FEV0EEyNeKgN6LXEeM/67763781d697663da79113ba381e8610/actions_flows.png)

This will take you to the “Login” flow page, where you can install, create, and add Actions to the flow.

![The “Login” flow page of the Auth0 dashboard.](https://images.ctfassets.net/23aumh6u8s0i/5dveq8h22H0Nje8Rub6sa9/7071335d4db1571af98440e527f1b999/actions_login_flow.png)

The screen has two main sections: the diagram in the center of the page shows the login flow and the Actions panel.

On the diagram, we can see the default login flow, which contains two states.

- **Start:** The user completed the login form and is ready to log in.
- **Complete:** The system issues the user’s credentials (an ID token and, if required, an access token).

You can drag and drop Actions in between these states to add custom logic to the login flow or deny the login request before the tokens are issued.

On the right panel, we have the Actions panel with two tabs.

- **Installed**: Pre-installed Actions from the [Auth0 Actions Marketplace](https://marketplace.auth0.com/features/actions)
- **Custom:** Actions created for this tenant

To create an Action, click the plus icon on the Actions panel and select "Build from scratch".

![Create a custom Action using the Actions panel](https://images.ctfassets.net/23aumh6u8s0i/3TABItaKOdq9dpsUIdQIpx/47d5010f5642123942ba3b7afd710300/actions_login_flow_create_menu.png)

After that, a modal window will appear to enter the information for our Action: you’ll have to provide a name, and you can leave the trigger and runtime as the default values. For my Action, I’ll name it “Require webauthn MFA for admins”.

![Enter the Action name and click create](https://images.ctfassets.net/23aumh6u8s0i/H6zvDcXGyg2a773gW790H/07ce6e74ee07f115d0e58d6e3863642f/actions_login_flow_create_dialog.png)

After clicking on "Create", you’ll be taken to the Action’s code editor, where you can write the code for your Action, install packages, test it, and more:

![Auth0 Actions code editor page](https://images.ctfassets.net/23aumh6u8s0i/6OzG8Oe3XU8lFnzLIr5Ver/4644c79782edaa0d279d4cf2112ae32c/actions_editor.png)

An Action can make use of two JavaScript functions to alter the Login flow:

- `onExecutePostLogin`: defines what should happen immediately after the user provides login credentials that Auth0 verified. This method receives two parameters, `event` and `api`.
    - `event`: contains details about the login request, such as the user and the context.
    - `api`: contains methods to manipulate the login’s behavior.
- `onContinuePostLogin`: defines what should happen when control returns to the Login Action after a redirect to another web page. It’s used only when the user returns after being redirected, which is why it’s commented out by default.

For this tutorial, we’ll focus on the `onExecutePostLogin` method.

## Writing the Actions Code

Next, we'll write the Action's code that will require users under the Admin's group to use `webauthn` as an additional authentication step. If the user isn't already enrolled with `webauthn`, the first time they login they will be prompted to do so.

The action will make use of the APIs `challengeWith` and `enrollWith`, in addition to using the user's property `enrolledFactors` to determine if the user has an MFA factor enrolled already.

Here's the actual code:

```javascript
exports.onExecutePostLogin = async (event, api) => {
    // Check if the user is an admin, enforce webauthn
    if (event.authorization?.roles?.includes('Admin')) {
        // Check if the user is already enrolled with webauthn
        if (event.user.enrolledFactors && event.user.enrolledFactors.some(m => m.type === 'webauthn-roaming')) {
            api.authentication.challengeWith({type: 'webauthn-roaming'})
        } else {
            api.authentication.enrollWith({type: 'webauthn-roaming'})
        }
    }
};
```

## Attach an Auth0 Action to the Login Flow

After coding and testing your Actions, it’s time to deploy and use them as part of the login flow. Once you are ok with your testing results, you can hit the `Deploy` button on the top right corner of the screen. This will take the existing code and settings and generate a function snapshot you can use in your login flow.

If you ever need to change the code on the function, all changes will automatically be saved as a new draft, and if you want the changes to become effective, you’ll have to deploy your latest version once again.

Once your code is deployed, it doesn’t mean it is actively used as part of your login flow. To check for that, please refer back to the [login flow screen](https://manage.auth0.com/#/actions/flows/login/), where the login diagram is shown. If you don’t see your Action as part of the diagram, it means that, even if your Action is deployed, it has not yet been activated. To activate the Action as part of the flow, click on the “Custom” tab on the Actions panel, locate your Action by name, and simply drag and drop the box over the login diagram between the "Start" and "Complete" steps. After that, you can apply changes using the “Apply” button on the top right corner of the screen.

![Apply an Auth0 Action to the Login Flow](https://images.ctfassets.net/23aumh6u8s0i/5IKiEeHy8WharqTOjJnSLh/eb5025dfd22de94c2446ccc22f1b524d/actions_attach_to_flow.gif)

## Test Your New Authentication Flow

Now, you can try your new Action by logging into your Auth0-powered application using both admin and non-admin accounts. When you log using any method (e.g. username/password, or social login) with a non-admin user, you'll get direct access to your application or continue with the authentication flow as you have it specified for your tenant.

When you log in using an admin user (a member of the group "Admin", as we defined it on the Action), you'll be prompted to either register or validate your account with webauthn. The screen may look something like this:

![Auth0 MFA Validation Step](https://images.ctfassets.net/23aumh6u8s0i/7duWHgEkhhz2e7rLgLJV1X/d174ce044c7a8011f660cd83be1cc815/mfa_validate.png)

## Conclusion

Auth0 Actions provides a versatile and powerful toolkit to revolutionize your organization's MFA implementation. By harnessing the flexibility of Actions, you can create personalized, risk-based, and context-aware MFA workflows that enhance security without compromising user experience.

The ability to tailor MFA requirements based on user roles, risk assessments, and specific applications empowers you to implement a layered security approach. This means that you can enforce stricter MFA for high-risk scenarios, such as administrative access or sensitive data handling while offering a streamlined experience for regular users.

As you explore the possibilities of Auth0 Actions, remember that Customization is key. By experimenting with different workflows and conditions, you can fine-tune your MFA implementation to perfectly align with your organization's unique security requirements and user expectations.

Thanks for reading!

Using Actions to Customize Your MFA Factors

This guide shows you how to permit or deny login requests by utilizing deny or allow lists. With step-by-step instructions, you'll create a new Auth0 Action, work with lists, and delegate list management to an external API.

Auth0 provides a robust set of tools and features to enhance authentication and authorization in applications. One such feature is Auth0 Actions, which allows you to customize and extend the behavior of the Auth0 platform. This article will explore using Auth0 Actions to permit or deny login requests based on specific criteria, such as a denied and allowed list.

## Prerequisites

Before diving into the implementation, there are a few prerequisites to ensure you have in place. 

- **Auth0 account.** If you don’t have one already, you can <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account</a>.
- **Basic JavaScript knowledge**: Auth0 Actions are functions you can program using JavaScript. In this tutorial, I’ll provide you with the examples. However, to further customize them for your use case, it is important to have basic JavaScript knowledge.

## Create a New Action

To begin, let's create a new [Auth0 Action](https://auth0.com/docs/customize/actions/actions-overview). Actions are serverless functions that run in a secure Auth0 environment.

To create an Action, log into your [Auth0 Dashboard](https://manage.auth0.com/#/actions/flows), select Actions from the left sidebar menu, then select Flows. This page shows the different flows you can customize. For our use case, we’ll choose the “Login” flow.

![The “Actions” page of the Auth0 dashboard.](https://images.ctfassets.net/23aumh6u8s0i/6Urd7xOI45T2kfVRnSYVfg/2deba4f6affc4cf234e5874d99999ba2/select_the_login_flow.png)

This will take you to the “Login” flow page, where you can install, create, and add Actions to the flow.

![The “Login” flow page of the Auth0 dashboard.](https://images.ctfassets.net/23aumh6u8s0i/7lgp4OyGh5EigXd8W6yZ8n/6c9dd5f1b3a162d8654fd97dcb629369/login_flow_page.png)

The screen has two main sections, the diagram in the center of the page shows the login flow and the Actions panel.

On the diagram, we can see the default login flow, which contains two states.

- **Start:** The user completed the login form and is ready to log in.
- **Complete:** The system issues the user’s credentials (an ID token and, if required, an access token).

You can drag and drop Actions in between these states to add custom logic to the login flow or to even deny the login request before the tokens are issued.

On the right panel, we have the Actions panel with two tabs.

- **Installed**: Pre-installed Actions from the [Auth0 Actions Marketplace](https://marketplace.auth0.com/features/actions)
- **Custom:** Actions created for this tenant

To create an Action, click the plus icon on the Actions panel and select "Build Custom".

![Create a custom Action using the Actions panel](https://images.ctfassets.net/23aumh6u8s0i/4AlGcWH9I7XWxYaG9BGpgt/7bc82776e321c1fe97b3e91a06667439/add_action.png)

After that, a modal window will appear to enter the information for our Action: you’ll have to provide a name, and you can leave the trigger and runtime as the default values. For my Action, I’ll name it “Validate User Login”.

![Enter the Action name and click create](https://images.ctfassets.net/23aumh6u8s0i/54faDAu75f8xpX1WjMnblt/717dd9e1d20658fedcc03e8271f64143/create-auth0-action-modal.png)

After clicking on "Create", you’ll be taken to the Action’s code editor, where you can write the code for your Action, install packages, test it, and more:

![Auth0 Actions code editor page](https://images.ctfassets.net/23aumh6u8s0i/5qe9QL6Iefmin0HFmRyQ5A/376010f5d460bbc7c034ad644f0543e7/auth0-actions-code-editor.png)

An Action can make use of two JavaScript functions to alter the Login flow:

- `onExecutePostLogin`: defines what should happen immediately after the user provides login credentials that Auth0 verified. This method receives two parameters, `event` and `api`.
    - `event`: contains details about the login request, such as the user and the context.
    - `api`: contains methods to manipulate the login’s behavior.
- `onContinuePostLogin`: defines what should happen when control returns to the Login Action after a redirect to another web page. It’s used only when the user returns after being redirected, which is why it’s commented out by default.

For this tutorial, we’ll focus on the `onExecutePostLogin` method.

## Working with a Deny List

A deny list is a common way to block specific users or IP addresses from logging in. To implement a deny list using Auth0 Actions, you can leverage the context available to the Action's code through the `event` parameter. The `event` object contains information about the incoming authentication request, such as user details and IP address. By accessing this object, you can compare the values against your deny list and take appropriate action just as denying the authentication request.

Before we start writing the code for our deny list, we need to know how to cancel the user’s login request. For that, we make use of the `api` parameter as follows:

```javascript
api.access.deny('reason');
```

With a single line of code, we can deny the login request. The `deny` method expects a single parameter `reason`, which is a human-readable explanation for the rejection.

Now, let’s start updating our function to support a deny list:

```javascript
// Array containing the email addresses that are blocked from logging on.
const denyList = ['myemail@example.com']

exports.onExecutePostLogin = async (event, api) => {
  if (denyList.find(email => email === event.user.email)) {
    api.access.deny("Your email address is blocked from logging in to our systems.");
  }
};
```

In this simple function, we have a hardcoded list of email addresses that are forbidden from logging in to our system, and the `onExecutePostLogin` simply looks if the user’s email address on the login event is in the list. If so, it denies the user’s access.

Once you add the code to the Action’s editor, it’s time for testing, and the best way to do it while in development mode is with the test panel.

You can access the test panel by clicking the play button on the editor’s sidebar, as shown below:

![Access the Auth0 Actions test panel by clicking the play button on the left sidebar](https://images.ctfassets.net/23aumh6u8s0i/5aZkR41jz9C6UjtuZizGCm/26ec7df5b28c78639e4701a1624a2dad/actions-test-panel.png)

Once you expand the panel, you can customize a test event object to your needs; for example, you can look for the `user` object, which contains all user properties such as `given_name`, but more importantly for our use case, `email`.

By clicking the "Run" button at the bottom of the test panel, Auth0 will execute the Action on the given data and output the test results on the test result window. If the given user is not part of our denied list, you’ll see the following test output:

![Auth0 Action’s test result for a successful execution](https://images.ctfassets.net/23aumh6u8s0i/2pX163YMm8dq9OPvbMIXz9/37f82cec86640e560a4bb2fd3543074d/auth0-action-ok-test-result.png)

On the contrary, if you update the event JSON to include one of the denied user email addresses, you’ll receive the following test output:

![Auth0 Action’s test result for a denied request](https://images.ctfassets.net/23aumh6u8s0i/7xGybOaomBF6ghtsP6l0i8/485440622fc08629927fae8eb3b820e8/auth0-action-denied-test-result.png)

Finally, once you complete your testing, you can deploy the function so it is available to add to the login flow.

## Working with an Allow List

On the other hand, an allow list specifies the users or IP addresses that are explicitly permitted to log in. Like working with a deny list, you can access the necessary information using the `event` object. Compare the values against your allow list and proceed with the login flow only if the user or IP address is found on the list. Otherwise, you can deny access by rejecting the authentication request.

Similarly to the deny list, the allow list will use the `deny` method to reject all requests except those from users in the allow list.

Here is the new code:

```javascript
// Array containing the email addresses that are allowed to log in.
const allowList = ['myemail@example.com', 'j+smith@example.com']

exports.onExecutePostLogin = async (event, api) => {
  if (!allowList.find(email => email === event.user.email)) {
    api.access.deny("Your email address is not authorized to log into our systems.");
  }
};```

Running the tests, as previously explained, should give similar results following the corresponding logic.

## Delegate List to an API

If you have many entries in your denied or allowed list, storing and managing the list in an external system, such as a database or an API, might be more practical. With Auth0 Actions, you can delegate the list retrieval and verification to an external API. Within your Action's code, make the necessary API calls to verify the user's status and subsequently reject or allow the authentication request.

For this exercise, we'll assume that you already have an API endpoint that, given a user's email address, will return if the user is authorized to access. Here is an example of what such an API could look like:

```bash
curl https://myaccessapi.com/users/is_authorized?email=myemail@example.com
{
  is_authorized: false
}
```

Given this simple example, let’s update our code:

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

exports.onExecutePostLogin = async (event, api) => {
  const auth_result = await axios.get(`https://myaccessapi.com/users/is_authorized?email=${event.user.email}`)
  if (!auth_result.is_authorized) {
    api.access.deny("Your email address is blocked from logging in to our systems.");
  }
};
```

Note that for calling an API, we are using the `axios` library, which is already available in your Actions environment. If you need access to other dependencies, you can simply add npm dependencies as part of your Actions bundle. You can learn more about dependencies on Actions on the [official documentation](https://auth0.com/docs/customize/actions/manage-dependencies).

## Attach an Auth0 Action to the Login Flow

After coding and testing your Actions, it’s time to deploy and use them as part of the login flow. Once you are ok with your testing results, you can hit the `Deploy` button on the top right corner of the screen. This will take the existing code and settings and generate a function snapshot you can use in your login flow.

If you ever need to change the code on the function, all changes will automatically be saved as a new draft, and if you want the changes to become effective, you’ll have to deploy your latest version once again.

Once your code is deployed, it doesn’t mean it is actively used as part of your login flow. To check for that, please refer back to the [login flow screen](https://manage.auth0.com/#/actions/flows/login/), where the login diagram is shown. If you don’t see your Action as part of the diagram, it means that, even if your Action is deployed, it has not yet been activated. To activate the Action as part of the flow, click on the “Custom” tab on the Actions panel, locate your Action by name, and simply drag and drop the box over the login diagram between the "Start" and "Complete" steps. After that, you can apply changes using the “Apply” button on the top right corner of the screen.

![Apply an Auth0 Action to the Login Flow](https://images.ctfassets.net/23aumh6u8s0i/eHb4lOXaXYvG3EdaVt6xM/aed46e987226df5b8ff5d41b03fd882c/apply-action-to-flow.gif)

## Summary

This article explored how to leverage Auth0 Actions to permit or deny login requests. By using a deny list or an allow list, you can enhance the security of your application and control access based on specific criteria. We also discussed delegating the list management to an external API, providing scalability and flexibility. With Auth0 Actions, you have the power to customize the login flow and add an additional layer of security to your application.

The examples I provided throughout the article are a good starting point. However, you can further customize them to meet your needs. For instance, you could use allow/deny lists by domains instead of emails or by IP addresses, country, day and time, etc.

Always thoroughly test your implementation and consider any potential edge cases specific to your application's requirements. By using Auth0 Actions effectively, you can ensure a robust and secure authentication experience for your users.

Thanks for reading!

Permit or Deny Login Requests Using Auth0 Actions

KonradProfilePicture

Konrad is a Community and Online Support Content Manager at Auth0 by Okta with more than 10 years of experience building, fostering and managing various technical developer communities. Outside of work he enjoys caravanning with his family, doing long distance bikepacking trips and spending time with positively crazy people.

Community and Online Support Content Manager

Konrad Sopala

Join the Auth0 Community and learn directly from the experts with the online AMA series.

The Auth0 Community Team is excited to invite you to our next interactive online AMA session on Thursday, January 18, 2024, featuring Actions, Rules, and Hooks subject matter experts.

## Ask Me Anything - Rules & Hooks and Why Actions Matter!

Have problems migrating from Rules & Hooks to Actions? Want to know more context about the deprecation? Looking for information on best practices, helpers and how to utilize Actions most effectively? No matter what kind of Actions, Rules, or Hooks questions you might have, we’ve got you covered! Oliver Wang, one of our product managers, will answer all your burning questions related to Rules & Hooks and share more why Actions matter!

## How Will the AMA Session Work?

From today to Wednesday, January 17, 2024, you can ask your questions by replying to [this community topic](https://community.auth0.com/t/auth0-community-ask-me-anything-rules-hooks-and-why-actions-matter/124043) using the ‘Reply’ Button. Then, mark your calendars for Thursday, January 18, between 7 am and 9 am PT, when our product experts will provide you with comprehensive written answers.

## Learn About Past AMAs

We kicked off our first AMA in July, all about [how to get the most out of the Auth0 Community and all the self-service resources available at your fingertips](https://community.auth0.com/t/auth0-by-okta-community-ask-me-anything-with-getting-self-help/110551/20). In September, we hosted an [AMA on Auth0 Terraform Provider](https://community.auth0.com/t/auth0-by-okta-community-ask-me-anything-with-auth0-terraform-provider/115670/34) to show you all the capabilities of this tool. The next one was about [self-service subscriptions and billing](https://community.auth0.com/t/auth0-by-okta-community-ask-me-anything-with-self-service-subscriptions-and-billing/119444/17). If you want to read more about previous AMA sessions, you can check them out [here](https://community.auth0.com/c/community/community-interactive-q-a-series/107).

## Stay Tuned for More

This session is part of a bi-monthly AMA online event series that invites Auth0 Community users to engage with various Okta subject matter experts. We will update [this page](https://community.auth0.com/c/community/community-interactive-q-a-series/107) with more events, so bookmark it for future reference. You can also check out recaps from previous AMAs via the link above.

[Hope to see you there!](https://community.auth0.com/c/community/community-interactive-q-a-series/107)

Auth0 Community AMA: Rules & Hooks and Why Actions Matter

joey devilla headshot 900px

I’m a Senior Developer Advocate at Auth0, and I like to work on various technologies. I’ve developed software for all sorts of platforms, from CD-ROM and the PalmPilot to my current area of focus, mobile phones, IoT devices, and AI. When I’m not looking for strange new platforms to write software for, I’m playing a strange old instrument — the accordion!

Senior Developer Advocate

Joey deVilla

Detect hackers with Auth0 Actions and special accounts designed to catch them in the act.

Use Honeytokens and Auth0 Actions to Catch Malicious User Logins

A quickly implemented Auth0 Action can enhance security by requiring users to log in from trusted IP addresses or blocks.

Ensure Users Log in from Trusted Networks with Auth0 Actions

carla_urrea

I've been working as a software engineer since 2014, particularly as a backend engineer and doing system design. I consider myself a language-agnostic developer but if I had to choose, I like to work with Ruby and Python.  

After realizing how fun it was to create content and share experiences with the developer community I made the switch to Developer Advocacy. I like to learn and work with new technologies. 

When I'm not coding or creating content you could probably find me going on a bike ride, hiking, or just hanging out with my dog, Dasha. 

Carla Urrea Stabile

Auth0 Actions allow you to customize your registration flows to fit your needs. Let's learn how to add a default role to a user when they sign up to your application.

When building an application requiring access control, you might have the need to use roles and permissions. In this blog post, you'll learn roles and permissions, the difference between the two, and how to assign a default role for your users using Auth0 Actions. 

<AmpContent>
<amp-youtube
    data-videoid="rWiviV1ziJw"
    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/rWiviV1ziJw' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## Roles and Permissions

The first step to add authorization to your application is to add authentication. Once you guarantee that only authenticated users can access it, you should have more control over who can access what. 

In an organization, [a role defines what a user can or can't do](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#What-are-Roles). Roles are often used to reflect the organizational structure, departments, etc. In relatively small authorization systems, using roles is a fast way to manage access control of resources. 

A [permission](https://auth0.com/blog/permissions-privileges-and-scopes/#What-Are-Permissions) is a declaration of an action that can be executed on a resource.

[In Auth0, a role is a collection of permissions](https://auth0.com/docs/manage-users/access-control/rbac#roles) that you can apply to users, which can facilitate how you add, remove, and manage permissions because you handle them as a group rather than assigning them to users individually. For example, you could have a role `author`, and as permissions, you could have `create:article`, `edit:article`, and so on.  

### Creating and Assigning Roles with Auth0

For this blog post you'll need an Auth0 account and a [registered API with Auth0](https://auth0.com/docs/get-started/apis), if you don't have one, you can <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for free</a>.

<include src="SignupCTA" text="Get an Auth0 Account for free." linkText="Get started →" />

### Create a Role on Auth0

From the [Auth0 Dashboard](https://manage.auth0.com/), click on **User Management** on the sidebar, then **Roles**. Click the **+ Create Role** button to create a new role. Let's say we want a default role for users, so you can name it `default_role` and add a meaningful description, then click on **Create**.

![Create a new Role Auth0](https://images.ctfassets.net/23aumh6u8s0i/4GuPwI9qt9FxfM0H8w4mcR/702130453889177b12c87989c9cd4d62/Screenshot_2023-10-20_at_18.11.42.png)

## Assigning Roles with Auth0 Actions

Now that you have the role, you need to be able to send it to your application. A simple way to do this with Auth0 is by adding the user's role using the [Management API](https://auth0.com/docs/manage-users/access-control/configure-core-rbac/rbac-users/assign-roles-to-users#management-api)

Adding roles to sign-up is not a built-in feature, so adding an [Auth0 Action](https://auth0.com/docs/customize/actions) to the **Login Flow** is a way to do it. An Action is a JavaScript function that allows you to customize the standard behavior of different Auth0 flows. 

> Note: you'll use the Login Flow and not Post User Registration flow. 

The Post User Registration flow is triggered after a user is added to a Database or Passwordless Connection. The actions that you use in this flow are non-blocking; they run asynchronously, which means the Auth0 pipeline will continue to run without waiting for the Action to finish its execution. 

![Post User Registration Flow Diagram](https://images.ctfassets.net/23aumh6u8s0i/7HbRIH2EDFHblUTh9v20Fx/0c75bd64d3cff33f34f18c638847aa7e/post-user-registration-flow.png)

What about the other connections? Well, if your user's sign up using a Social Connection, the Post User Registration flow will not be triggered, but the Login Flow will, because in Auth0, whenever a user signs up, they are immediately logged in afterward. 

In the Login Flow, the post-login trigger will be executed after a user logs in and when a Refresh Token is requested, which is exactly what you need because you want your action to execute regardless of the database connection used. 

![Login Flow Diagram](https://images.ctfassets.net/23aumh6u8s0i/6Thx4RkK5XheYYUwzXrkPP/4906424ad7476516cef5615db5a6659b/Login_Flow__1_.png)

You can check out the official docs to learn more about [Actions Flows and Triggers.](https://auth0.com/docs/customize/actions/flows-and-triggers)

From the Auth0 Dashboard, click on **Actions** and then **Library**. Next, click on the **Build Custom** button. In the modal that opens up, add a name for the action, select the **Login/Post Login** trigger, and then click on **Create**.

![Create new Action](https://images.ctfassets.net/23aumh6u8s0i/4se18ePBFxTJmNaljcZlsw/e143d7bbb0897ee026500cec6865daf9/auth0-create-action.png)

[The Actions editor will open](https://auth0.com/docs/customize/actions/write-your-first-action#create-an-action), and inside the `onExecutePostLogin` function, add the following code: 

```js
/**
* Handler that will be called during the execution of a PostLogin Flow.
*
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
*/
exports.onExecutePostLogin = async (event, api) => {

  // Check if the user has a role assigned
  if (event.authorization && event.authorization.roles && event.authorization.roles.length > 0) {
    return;
  }

  // Create management API client instance
  const ManagementClient = require("auth0").ManagementClient;

  const management = new ManagementClient({
    domain: event.secrets.DOMAIN,
    clientId: event.secrets.CLIENT_ID,
    clientSecret: event.secrets.CLIENT_SECRET,
  });

  const params =  { id : event.user.user_id };
  const data = { "roles" : ["YOUR_ROLE_ID"] };

  try {
    await management.users.assignRoles(params, data);
  } catch (e) {
    console.log(e);
  }
};
```

Let's take a look at what this code does, starting with the first `if` statement: 

```js
if (event.authorization && event.authorization.roles && event.authorization.roles.length > 0) {
  return;
}
```

You are checking that the user has a role assigned, which, in the particular use case of this blog post, means the user has logged in previously. **Remember you care about the user's first login, and in Auth0, that happens right after they sign up.**

[You're using the `event` object from the Login Flow](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow/event-object). The `event.authorization` object contains information describing the authorization granted to the user who is logging in, and one of its properties is `roles`, an Array of strings that contains the names of the user's assigned roles. 

Then, by using the `auth0` NPM package, you create a new Management API client instance and initialize it with the values for `domain`, `clientId`, and `clientSecret`:

```js
const ManagementClient = require("auth0").ManagementClient;

const management = new ManagementClient({
  domain: event.secrets.domain,
  clientId: event.secrets.cliendId,
  clientSecret: event.secrets.clientSecret,
});
```

For this code to work, you must install the [`auth0` NPM package](https://www.npmjs.com/package/auth0). You can do so using the [dependency manager on the sidebar in your Actions Code Editor.](https://auth0.com/docs/customize/actions/manage-dependencies#add-a-dependency-using-the-actions-code-editor)

You also need to add the values for `domain`, `clientId`, and `clientSecret` to the [Actions' Secret Manager](https://auth0.com/docs/customize/actions/write-your-first-action#add-a-secret). You can find the values for these variables in your [Auth0 Application Settings page](https://auth0.com/docs/get-started/applications/application-settings).  

Next, you're initializing the payload to send it to the management API. To add a role to a user, you'll use the method [`assignRoles`](https://auth0.github.io/node-auth0/classes/management.UsersManager.html#assignRoles), which associates a role with a user. The first parameter is an object with the user's ID, and the second is an object with an array of `roles`. 

```js
const params =  { id : event.user.user_id };
const data = { "roles" : ["YOUR_ROLE_ID"] };
```

Note here you're passing `YOUR_ROLE_ID`; here, you'd need to pass the role ID, which you can find on the Auth0 Dashboard by navigating on the sidebar to **User Management> Roles**. Select the role you want to see details of, and you'll see the Role ID.

![Role Details Screen](https://images.ctfassets.net/23aumh6u8s0i/27FKFQMJ8MJOerHoIjtl3M/4f9c43afed9cc9eeea16fda94cb165ea/Screenshot_2023-10-20_at_17.53.37.png)

Finally, you're making the call to the Management API's method `assignRoles` and passing the parameters you initialized in the previous step:

```js
try {
  await management.users.assignRoles(params, data);
} catch (e) {
  console.log(e);
}
```

You can **test the action within the editor** using the user ID of a test user you have already created but has no role assigned yet. After logging in, the user should have the role assigned!

Once you're happy with your action, you can go ahead and click on the **Deploy** button in the top-right corner. 

The last step is to **add your action to the Login Flow**. From the Auth0 Dashboard sidebar, go to Actions > Flows > Login. 

Once in the Login Flow view, click on **Custom** on the right side to add the action you just created. Then, drag your action into the Login Flow and place it between the Start and Complete steps.  

![Login Flow - drag and drop role action](https://images.ctfassets.net/23aumh6u8s0i/590X9hg6UI8FpkOlty1hD4/1abcac0f26e411ed69e3c08db3ff1e9d/Screenshot_2023-10-20_at_18.04.36.png)

## Summary 

In this blog post, you learned about roles and permissions and that in Auth0, a role is a collection of permissions. 

Then, you implemented an Auth0 Action to assign users a default role after signing up. For that, you added the `auth0` NPM package, created secrets using the Actions Code Editor, and tested and deployed your action. 

Assigning a Default Role to Users on Sign-Up with Auth0 Actions

Oliver Wang

A product manager at Auth0 focuses on  Ecosystem and Extensibility.  With an engineering background, Oliver always puts developers' experience first.  He has mixed industrial experience as a Product Manager, Software Engineer and Data Analyst. This diverse profile unites different team members to deliver value to our customers. Besides work, you can catch him up on a ski hill in the Canadian Rockies.

Product Manager, Ecosystem

Three new capabilities are all now available in Auth0 Actions.

## Do More with Actions

You can now unlock deeper identity customization with Auth0 by Okta. Starting today, you can use advanced features in Auth0 Actions, which include SAML Mapping, Root-Level User Attributes, and Access Token Scope. These new capabilities enable you to seamlessly upgrade from Rules to Actions - our flagship extensibility product.


## Allow Deep Customization with Three New Capabilities in Actions

Our new functionalities bring unique benefits to developers and their customers alike. We dive deeper into these below.

### SAML mapping and configuration

The Security Assertion Markup Language (SAML) is essential for sharing authentication and authorization data between various identity and service providers. Our latest update integrates SAML mapping and configuration into Actions, streamlining the handling of user data and facilitating integration with SAML-based identity providers.

Developers can now map user attributes and claims from SAML assertions directly to user profiles using Actions. This integration simplifies the management of user attributes, ensuring a seamless flow of data between different identity providers and their applications. As a result, you can create context-aware, personalized experiences, bolstering your identity pipeline. Learn more about SAML in our [Docs](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow/api-object).

### Access Token scope

Access tokens are crucial for token-based authentication, allowing an application to access an API. With our upgrade, developers can freely add or remove claim scopes with custom APIs, enhancing their ability to meet their overall security needs. Learn more about Access Token in our [Docs](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow/api-object).

### Root-Level user attributes

The normalized Auth0 user profile includes both root attributes and profile attributes from various identity providers. Our latest update provides a comprehensive exposure to these attributes, enabling developers to better customize their identity solutions. This means you can make more use of standard properties such as `user.roles`, `user.groups`, and `user.permissions` to understand customer profiles and protect user interests better. Learn more about User Attributes in our [Docs](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow/event-object).

## Migrating to Actions: It’s All about out-of-Box Customization

In today's shifting digital landscape, off-the-shelf identity solutions are often insufficient. Given unique organizational needs and ever-changing regulations, customization and flexibility are critical. Auth0 Actions offers an opportunity for deep customization, benefiting customers, partners, and developers alike.

We encourage you to move from Rules and Hooks to Actions for improved developer experiences and ongoing feature enhancements. By using Actions, you can directly integrate third-party solutions, bypassing the need for custom code and benefiting from improved caching performance. Embrace simplicity and flexibility in identity management— transition to Auth0 Actions today.

We are here to help. Visit our [Move to Actions](https://auth0.com/extensibility/movetoactions) page for more migration information and learn more about SAML, Access Token, and User Attributes in our [Docs](https://auth0.com/docs/).


Unlock Deeper Customization in Actions with Three New Capabilities

Nathan Chan

Nathan is a Sr. Solutions Engineer at Okta connecting the dots between technology and GSI partners. When not working, he is an avid fan of the New York Yankees.

Auth0 Actions and Integrations can combine to increase security and improve visibility

**TL;DR:** Last-mile customization can transform an out-of-the-box solid solution into the one you need for your business right now. But did you know that the same extensibility (the ability to write custom authentication workflows and integrate no-code third-party applications) can be used to increase security? You can use extensibility to create a layered defense. This post will show you how.

## Why You Should Build In Security

According to [the 2022 Verizon Data Breach Investigation Report (DBIR)](https://www.verizon.com/business/resources/reports/dbir/), 82% of security incidents involved a human element. Threat actors overwhelmingly rely upon social engineering and phishing attacks, not to mention simple everyday errors, in their quest to plunder company data. And so, identity is now the first line of defense. 

Identity plays a massive role in security. Customer Identity Access Management (CIAM) solutions like Auth0 are designed to strengthen your defensive posture with out-of-the-box security features, like the ability to detect brute force attacks and warn users when their credentials have been leaked. 

These features address the security needs of many companies. But no two businesses are the same. Some, particularly those in highly-regulated markets, need even higher levels of vigilance. Their threat profile requires them to introduce additional friction into the authentication process beyond what their CIAM platform offers by default. 

Auth0 makes it easy to add that protection. Because it's designed for extensibility, users can build custom functionality or create custom workflows by writing their own Actions or installing no-code integrations from the Auth0 Marketplace. In turn, businesses can create a robust, layered defense, allowing them to meet their own security needs.

This post will focus on the concept of a layered defense. We'll explain it on a high level and then look at the practical side of things. You'll learn how Auth0's extensibility features allow for the custom authentication workflows and rules that are fundamental to a layered defense. 


## What is a Layered Defense?

It's often useful to describe technical concepts with a real-world metaphor. Let's imagine you just bought a new house. It's beautiful. Your dream home, even. But there's a catch. It's a big one. As you unloaded your possessions from the moving truck, your new neighbor warned you about a recent spate of break-ins. You want to keep your family safe, so you begin adding new security features. 

Fortunately, the front door is made of thick, solid wood. Your windows are the strong double-glazed kind. And so, you look elsewhere to make changes. 

With boxes piled around your feet, you begin to install locks on your internal doors. A video doorbell and CCTV cameras come next. You deploy motion detectors around the ground-floor windows and even start thinking seriously about buying a dog. With each new security feature, your home becomes more resistant to burglars. You started from a good place, thanks to your solid wood doors and double-glazed windows. But you know that no security system is invulnerable. And so, you built upon those strong beginnings. 

In a business technology context, a layered defense involves taking the strong underpinnings of a product and enhancing them further. No security product is perfect. Risk levels vary between businesses, and some may be enticing enough to convince an attacker to systematically test your defenses in the hope of finding a weakness they can exploit.

As you add additional layers of security, introducing new surveillance and mitigation measures, you reduce the likelihood of an attacker finding a loophole. You introduce redundancies. If an attacker circumvents one protection, they're blocked by another. 

Let's return to the home example. Suppose a burglar smashes their way through your sturdy, double-glazed windows. They must still face the motion detection sensors, the CCTV system, and the dog. Their odds of successfully robbing your home while remaining undetected are still vanishingly thin. 


## Protect The Gateway, Protect the Application 

Risk varies wildly between industries. But it's also contextual. 

A logistics company might want to re-authenticate users when they perform a potentially-unauthorized action — like changing the delivery address of a package whilst it's in transit. Banks often will challenge users when they add a new payee or send a wire transfer to a new account. Many applications add friction when they detect suspicious behavior, like when a user logs in from a new location or from a new previously-unseen device.

There's a reason for this. Identity is the most logical place to add extra protections. It's a necessary component for accessing an application. It's the part responsible for session management. Identity is how you can block and revoke access.

CIAM tools like Auth0 make this process even easier, as they're inherently centralized. There's one place to look for suspicious login activity and one place to act. If you rely on a custom identity system, which in turn relies on several external components, it becomes a lot harder to take swift action against the potentially-harmful activity and even more time-consuming to add new security features. 

If you're curious, we've explored this issue at length in the past. On so many levels — but especially security — it makes more sense to [use a purpose-built CIAM tool over an in-house identity system](https://auth0.com/resources/whitepapers/build-vs-buy-evaluating-identity-management). For a deeper look into the build-vs-buy debate, check out [this white paper](https://auth0.com/resources/whitepapers/build-vs-buy-evaluating-identity-management).

Okta provides low-code and pro-code tools to build a robust, multi-layered, and context-aware defense. We also make it really easy. Read on to learn more about Auth0 Actions and Integrations and how they can combine to bolster your security posture.


## How Actions Power Your Layered Defense

Actions are small, tenant-specific scripts written for the Node.js framework that execute at specific points during the authentication workflow. They're a quick, effective, and versatile way to add custom functionality to the stock Auth0 platform. 

The Auth0 platform defines several contexts where an Action can be executed. We call these flows. Put simply; flows describe linear user interactions within an authentication context. Things like changing a password, creating a new user account, or logging in. 

Flows define the broader authentication and access control pipeline. They represent a linear user or machine interactions within an authentication. Examples include account creation, password changes, or logging in.

Within flows, you'll find something called 'triggers.' These identify specific parts of the pipeline where you can introduce custom business logic.

Flows are either blocking (synchronous) or non-blocking (asynchronous), depending on the context. In practice, the vast majority of the Actions-based layered defense measures will be blocked as you halt the authentication process until a specific condition is met. 

For a good example of this, look at the login flow. It's here you'll check the location or IP range of the user or ask them to verify their identity with multi-factor authentication (MFA).


## Putting Code First

The Auth0 platform treats code like a first-class citizen. In practice, this means we deliver a modern developer experience and try to limit the number of restrictions placed on customer Actions. 

Because Actions are proper node.js applications, they can use the majority of third-party libraries available within the public NPM registry, provided they don't rely on any native add-ons. In short, if a dependency doesn't require you to compile anything, it'll likely work. We support two ways of adding dependencies to an Action: through our web interface or via the Auth0 Management API. 

Developers can build Actions using their preferred text editor (Vim or Emacs, we don't judge). We also provide a browser-based editor with native syntax highlighting. And, because version control is at the heart of good software development, the Auth0 platform allows you to track changes over time and quickly revert to the last known good version of an Action. 

We designed Actions to be easy to test, debug, and audit throughout the entire lifecycle. Using the browser-based editor (or the Auth0 Management API), developers can test their actions using dummy payloads. This feature simulates real-world usage without the need to deploy the action to a live environment. 

The Auth0 platform also lets developers test the more granular elements of their application. Developers can run unit tests using the framework of their choice. Our documentation primarily focuses on Jest, the most popular JavaScript unit testing tool. This makes it easy to verify the bits of your code that don't primarily interact with the Auth0 platform, like custom logic that posts a Slack notification when a user fails to authenticate. 

Once an action is live, administrators and developers have access to tenant logs, allowing them to easily identify and debug failed interactions. Logs are hugely valuable from a security perspective. They act as the canary in the coal mine, warning when a third party is attempting to gain unauthorized access and providing valuable intelligence when investigating a security incident. 

But logs can also provide useful clues with respect to your application's usability and stability. We record failed sign-ups and machine-to-machine messages, along with the other typical user interactions, to provide engineers with vital diagnostic information. 


## The Rules for Writing Actions

In short, Actions are a really powerful way to introduce custom business logic to your identity. That said, to make sure everyone can take advantage of them, we have a few basic rules. 

We limit Actions to ten external dependencies, and each action should be no more than 100kb in size. This size limit excludes any external NPM modules. Additionally, each flow cannot exceed more than 20 attached actions. 

These rules are intended to ensure your users have a smooth experience. That's because larger, more complicated scripts add latency to your application. We, therefore, require every flow to complete in under ten seconds. Flows that exceed this limit are executed and will return an error.

Additionally, each Auth0 tenant is limited to a maximum of 100 actions. This number includes both deployed and undeployed actions. We also limit the number of versions to 50 per action. Should you exceed this figure, Auth0 will automatically delete the oldest available version. For more information, check out our guidelines.

Remember: Actions are designed to be small, purpose-built scripts. As any software engineer can (and will) tell you, simplicity is always better than complexity.


## A Look at Integrations

We've already introduced Actions. They're great for adding custom business logic to identity workflows. But what if you don't want to reinvent the wheel? Fortunately, Auth0 has a solution for that, allowing you to incorporate third-party services while limiting the need for custom code. 

Integrations are ready-to-use extensions that allow you to integrate third-party applications and services into your identity workflows. 

Let's put it another way. As a developer, you use libraries to work more effectively. These pre-written packages of code allow you to focus on building value. Libraries solve problems that millions of programmers face — like interfacing with databases, generating data visualizations, or sending emails and texts to customers. 

Integrations work the same way. They solve problems that you, and countless other engineers, face. Problems like how to share access logs with Splunk or Sumo Logic or how to verify identity documents and passwords. Like a programming library, Integrations are ready to use and, in many cases, can be implemented with just a click. 

You can find and install integrations from the Auth0 Marketplace. Each comes with helpful guidance on how to activate them within your tenant and the best practices for use. If you get stuck, you can find more information on our documentation page. 


## Building a Layered Defense Strategy with Actions

Okay, so we've explained what a Layered Defense strategy means and learned how to customize identity workflows within Auth0. Now let's look at some scenarios for how this could work in practice. 

The stock Auth0 experience comes with several security features by default. It automatically blocks suspected brute force attacks, as well as suspected bot activity. It warns users when their passwords appear on the dark web. It makes it easy to add features like multi-factor authentication (MFA), including biometric-based MFA.

Like the house in the earlier metaphor, Auth0 offers strong foundations to build upon. But what if you wanted to expand further?

A good start would be to require MFA for all users accessing your application beyond the confines of the company network. You also decide to block login attempts from specific countries where your business doesn't have a presence and are often the source of attempted attacks. After writing a few lines of code, you have an action that's ready and waiting to be attached to the login flow. 

You also decide to limit the potential window when a successful attack could occur by blocking authentication attempts that take place overnight. Again, this can be accomplished with just a few lines of code.

Context matters. It's the thing that lets you distinguish between legitimate and malicious activity. It's the tool that lets you evaluate risk. Just like a bank may temporarily block your debit card if you withdraw cash from a country you've never visited before, a layered defense strategy allows you to add friction based on the criteria that you define.

And because Auth0 Actions are JavaScript applications, you have the flexibility to define the circumstances where you may wish to add friction or even deny access. 


## Bringing Integrations Into the Mix

Auth0 is one of many security tools your business relies on. You use a SIEM platform to manage, retain, and analyze logs. As your application is built with a microservices architecture, you rely upon a gateway to manage API requests and identify malicious activity. You use a mobile device management (MDM) system to keep track of company-issued laptops and smartphones. 

Naturally, you want to integrate these tools into your identity platform. And so, you head to the Auth0 marketplace. With just a few clicks, the security tools you use are working together in harmony. 

And, because Auth0 allows you to customize most parts of the identity lifecycle, from registration to authentication, developers quickly add additional functionality and quickly onboard new third-party products and services. For example, they could implement sophisticated behaviors that minimize the risk of fraudulent or malicious account creation. 

We make it easy to integrate your application with tools like Deduce, a behavioral intelligence platform that detects suspicious user activity in real-time. And, with a few lines of code, developers can redirect flagged accounts to services like ID DataWeb, where users are asked to prove their identity with their passport or driving license.

With each step, you add another layer to your defensive posture. You become stronger. More resilient. Better able to withstand threats. Less attractive to a would-be attacker. 


## You Know Your Risk Best

Don't get us wrong — Auth0 is designed to deliver the best security outcomes from Day One. Its [out-of-the-box security features](https://auth0.com/blog/how-auth0-makes-your-apps-more-secure/) can protect against brute force and credential stuffing attacks, and we actively monitor for suspicious or anomalous behaviors. 

But we also know that every company is different, with different risks and compliance requirements. And so, we make it easy to customize the included security features and add new functionality and friction beyond that. Flexibility goes hand-in-hand with security. Only you know the risks you face and the measures you need to take in order to protect your application, your data, and your users. 

Want to keep the conversation going? [Reach out to our team](https://auth0.com/contact-us) to learn more about how Actions and our network of integrations can help secure your business while delivering an unbeatable user experience for your customers and employees.

How To Build A Layered Defense By Extending Auth0

Dan McCorriston

Senior Product Marketing Manager

Auth0’s Actions gives developers customizable, extensible capabilities, as well as low and no-code options.

**TL; DR:** Few developers have expertise in all areas of both technology and business needs. There’s just not enough time, so many look for solutions that let them focus on their core competencies. The Auth0 platform, for example, solves most identification management needs, which frees the developer from learning how to code a CIAM solution from scratch.

But every developer, and their solution, has their own unique set of scenarios they need to solve. They want to have a rapid implementation of an authentication solution yet also provide the capability to build custom code to solve common identity extensibility use cases – like payments, subscription management, or signing terms of services.

Auth0’s Actions toolset - which launched last year - gives developers customizable, extensible capabilities, as well as the option of low and no-code Actions Integrations through the Auth0 Marketplace.

# What’s New

![Auth0 Actions](https://images.ctfassets.net/23aumh6u8s0i/6U3nuyVYlbcg9i0C36khkU/61a068d638a5ee2753facbcf5924e55c/Marketplace_Partner_Spotlight_Separator_V01A_3x.png)

## Marketplace for Private Cloud

Auth0 is excited to announce that the Auth0 Marketplace is now available to our Private Cloud customers. What that means is all Auth0 customers that utilize our Private Cloud product have to access SSO, Social Connections, and Log Streaming Integrations and will soon also be able to access Actions Integrations.

## What is Private Cloud?

Auth0 Private Cloud provides the flexibility and agility offered by cloud deployments but allows a customer to maintain the control and security they need to protect their customers and their businesses. Many customers that have high security and regulatory concerns - those in the financial services industry, for example - may require certain standards of uptimes, updates, failovers, and support for their deployments. The Auth0 Private Cloud deployment models come in both Standard and Managed levels, depending on the customer’s requirements.

Now that Private Cloud customers have access to the Auth0 Marketplace, Ecosystem Partners have a new and expanded pool of potential customers to reach through building and publishing Actions Integrations into the Marketplace. There’s never been a better time to become an Ecosystem Partner and market your Action Integration through the Auth0 Marketplace.

## Wait... There’s More

Auth0 is always delivering more tools, features, and options for developers to give them the support and capabilities they need to customize their customer’s experience through pro-code flexibility. We’re very excited about the latest iteration of our extensibility toolset  - Actions - which will soon be our unifying extensibility toolset, taking over from Rules and Hooks. Actions enable developers to write custom code hosted by Auth0 that extends the behavior of their authentication flows to fit virtually any use case.

Some key features include:

* Version Control which enables you to draft, review, and test custom code and flow configurations within a single user interface.
* Flow editor and Monaco Editor with Syntax Highlighting, giving you the capability to visually drag and drop Actions to build custom identity flows as well as write JavaScript functions with validation, IntelliSense code completion, and type definitions.
* Serverless extensibility so your code is hosted and maintained by Auth0.
* Developers can also look through our catalog of no-code Actions Integrations in the Auth0 Marketplace to help save coding time and expense.

<br>

![Auth0 Actions](https://images.ctfassets.net/23aumh6u8s0i/16QlWAA6ZN2lnMATb3RbMu/3e305e33068ab6a5afb1419500972b4c/Marketplace_Partner_Spotlight_Separator_V01B_3x.png)
<br>

## Why It Matters

Soon, Auth0 will deprecate Rules and Hooks, with Actions being the sole unifying extensibility toolset. The date has not been set, but you can plan ahead and start your migration now. Migrating to Actions is an easy step-by-step process that you can follow along in this [new guide in Docs](https://auth0.com/docs/customize/actions/migrate-from-rules-to-actions) as well as guidance from our [developer community](https://community.auth0.com/t/guide-migrate-your-custom-rules-to-auth0-actions/68915).

Auth0 Actions: Looking Back, What’s Ahead?

Build an Actions Integration and connect with Auth0 customers

## Why Should You Become an Ecosystem Partner?

Whether you’re a developer of a newly launched solution, or part of a larger, enterprise-level organization, you want to get your product in front of potential customers. Therefore, developing and growing your reach through an Extensibility Ecosystem strategy is a vital part of any organization’s overall strategy.

At Auth0, we consider extensibility to be one of our essential product capabilities. While our endless options for integrations are an excellent way to customize your own unique solution, it can be difficult and time-consuming for our customers to figure out how to implement them.

Enter the [Auth0 Marketplace](https://marketplace.auth0.com/).

We built the Marketplace as a way to connect our customers with service providers and builders who implement these types of integrations regularly. Listing your integration with Auth0 promotes your company with our customers who are looking to do more with their authentication pipeline.

![Ecosystem](https://images.ctfassets.net/23aumh6u8s0i/5rRXDrFl5g647jL7dPbjR/c7d099307234ef118b05e3c6f1215fda/Marketplace_Partner_Spotlight_Separator_V02A_3x.png)


## What is an Ecosystem Partner?

More and more SasS companies are offering developer customers the flexibility and capability to stay within their own ecosystem as much as possible in order to find solutions that fit their own and their customers’ needs. A rich and diverse catalog of integrations can give developers all the low and no-code capabilities they need to build out their own customer journey.

**Auth0** provides an authentication and authorization service built on open standards like OIDC, OAuth2, SAML, and others. But, more than that, we provide tools so our customers can outsource user centralization and management alongside components of application security, and we also help connect networks of applications to a single source of identity.

An important part of this is enabling partners, such as yourself, to create an ecosystem of integrations that can be used to enhance and extend what we already provide. We do this by providing extensibility points and methods to allow customization. This means more functionality for customers with less maintenance burden for them.

Almost 90% of our customers extend the Auth0 platform for their unique requirements. By working with you to solve common identity problems and use cases, we can expedite the time it takes our customers to implement their identity workflows.

Joining Auth0 as an ecosystem partner by building and marketing your Action Integration has some very important opportunities to take advantage of.

### Opportunities:

#### Audience Reach
Auth0 has more than 90k active tenants in production. Some customers have multiple tenants, and some only have one, but this is a large reach of potential customers for your Action Integration. Once your Action Integration is in the Marketplace, customers will have the opportunity to discover, consider, and install your integration into their customer identification flow.

#### Co-marketing
Once you’ve successfully published your Action Integration into the Marketplace, take the next step to expand your reach through GTM initiatives. While we encourage you to drive some GTM initiatives on your own, we also have many opportunities for you to market your integration with us. From blogs and newsletters to demand generation and webinar programs, we have multiple opportunities to help you market your integration.

#### Early to market
The earlier you create your Action Integration and are published to the Marketplace, the better chance you have of creating your own virtuous cycle of early adopters of your integration, marketing your case study, and growing your customers through the ecosystem.

#### Take advantage of Actions technology
Auth0’s new universal extensibility toolset - Actions - is the latest advancement on our commitment to delivering best-in-class extensibility to developers. Developers can take advantage of the easy-to-use interface, drag and drop functionality, version control, a serverless environment, pre-production testing, and debugging.

## How Do You Start?

If you want to learn more about becoming an ecosystem partner and building an Action Integration, visit [Integrate with Auth0](http://autho.com/integrate) to learn more. Here are the main steps you’ll take on your journey to becoming a partner:

## Develop a Use Case for a Customer Need

Some of the considerations you should make when developing a use case for your integration are:

* What does your service do, and how will this help our end customer? (ex. low conversion rates caused by interrupted security measures like MFA, spam signups and content submission, too much or unhelpful log data).
* Do you target specific industries and customer types? (ex. B2C, B2B)

Some of the most popular categories are:

* Identity proofing where customers need to prove they are who they claim to be
* Multi-Factor Authentication, where customers are required to use more than one step to prove their identity
* Consent Management that asks, records, and stores a customer’s approval or denial to use their information.

<br>
![Ecosystem](https://images.ctfassets.net/23aumh6u8s0i/5J18zBKKTWj49BiFo9cjfz/6363b6e28cf2492c47507b71666e8ca2/Marketplace_Partner_Spotlight_Separator_V02B_3x.png)
<br>

There are dozens of other use cases and perhaps many we haven’t thought of. If you’ve got a great solution that fits into the identity flow, let us know.

#### Start building your Action Integration
Get build support once you have created your solution use case. There are step-by-step instructions on how to develop your Action Integration. As your start building, you can get support from our comprehensive documentation, blogs, and forums. Live developer support is available for certain build scenarios.

#### Get published in the Auth0 Marketplace
Once your code has been tested and gone through the QA process, you are ready to deploy your Action Integration to the Auth0 Marketplace. Your integration will not only be discoverable in the Marketplace but easily found and installed from the developer dashboard.

#### Go To Market Opportunities
Now it’s time to find some customers and get them to install your Action Integration. Auth0 will partner with you on a Go-to-Market plan through newsletter, direct email, and social media marketing, as well as drive customers to webinars and demo content. Your success is our success.

There are more details and information at [Integrate with Auth0](http://auth0.com/integrate), so check it out to find out how to become an Auth0 ecosystem partner.

Become an Ecosystem Partner

darin-laframboise

Expert in Ecosystem strategies. Expert in driving product roadmaps and building long-term growth strategies. Can make quick, data-minded, impact-focused decisions to keep projects on track. Deep background in analytics and data engineering.

Director, Product Management

Darin LaFramboise

Actions Integrations reduce the amount of custom code you need to write, maintain, and update. 

[Actions launched recently](https://auth0.com/blog/actions-now-generally-available/) as the next evolution of extensibility with Auth0, picking up where our legacy extensibility tools Rules and Hooks leave off. Actions unifies the Auth0 extensibility experience in one place. With it, we took the power of Rules and Hooks and created a greatly improved developer experience with features such as an industry-standard VS Code style editor, typescript, draft mode, version control, improved secret management, and an expanded library of NPM modules. Actions gives developers the ability to customize Auth0 using the full spectrum of coding options from pro-code to [low-code](https://auth0.com/blog/what-is-low-code-how-low-code-can-speed-digital-transformation/), with the addition of no-code Actions Integrations.

Actions Integrations, as our new zero-code layer, offers an easy experience to extend Auth0 with partner-built innovations with no coding required. Now you can implement key integrations such as Identity Verification or Consent Management to your workflow without writing or maintaining a single line of code, the provider of the integration takes care of that. To use Actions Integrations, simply install an integration from the Auth0 Marketplace and drag-and-drop it into your Actions workflow. Then with only a few configuration settings, the integration is part of your tenant.

Actions Integrations, currently in Beta, are now available through the [Auth0 Marketplace](https://marketplace.auth0.com/) and in Actions in the Auth0 Dashboard. This marks an essential milestone in how you can leverage innovations from Marketplace Partners into your Customer Identity Access Management (CIAM) workflows. Through Actions and Marketplace, we are creating an ecosystem of sustainable, and ever-growing plug-and-play partner integrations that allows developers to solve many identity extensibility scenarios faster and without extra code.

Pro-Code custom Actions will continue to be a core feature of Auth0, with all the support you’ve come to expect. By adding Actions Integrations to our offerings, we give you the option to replace the custom code for common solutions with no-code integrations and leave the custom code layer for unique use cases to you. This reduces your overall maintenance and risks associated with custom code.

## Plug & Play Extensibility

### Endless innovation, centrally maintained

Satisfy your identity requirements right out-of-the-box without having to write custom code. Actions Integrations are reusable modules that are centrally maintained by a vetted Marketplace Partner. Integrations are designed to be maintained by the Partners with updates propagating automatically to all instances.This results in faster time-to-market while greatly reducing maintenance costs and resource drain associated with code updates that can result in having to rebuild Rules and Hooks.

### Common use cases

Actions Integrations exist for the most common use cases of custom extensibility. These currently include:

*   **ID DataWeb:** Real time and self service global identity verification
*   **Eva:** Second-factor voice biometric 
*   **Scaled Access:** Delegated user access management
*   **One Trust:** Consent and user preferences management
*   **Incognia:** Mobile identity proofing with address verification
*   **Incognia:** Mobile login with location behavioral biometrics
*   **SecZetta:** Real-time, risk-based authentication
*   **Yoonik:** Second-factor facial biometric
*   **Infobip:** Global SMS messaging
*   **Amazon:** Simple Notification Service (SNS) for microservices and serverless applications by Amazon
*   **ClickSend:** Global SMS messaging
*   **Cumul.io:** Self-service data visualization platform
*   **DataGuard:** Consent and user preference management
*   **Esendex: SMS authentication
*   **Mitto:** Global SMS messaging
*   **Plivo:** SMS authentication
*   **Telesign:** Global SMS messaging
*   **Vonage:** Global SMS messaging

<br>

With [Auth0 Marketplace](https://marketplace.auth0.com/), we are building partnerships to deliver innovations that further reduce your need to code features from scratch. After the public launch of Actions Integrations, we will continue to grow our Marketplace catalog, adding more services and modules to help you expand and customize your CIAM implementation.

We encourage you to start using Actions integrations to satisfy any of the common use cases that apply to you. And of course, if you encounter any questions or have any comments, please direct them to our team of identity specialists.

Auth0 No-Code Actions Integrations Now Available in Beta

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

Learn some guidelines to migrate your Auth0 Hooks to Auth0 Actions successfully.

Migrating Auth0 Hooks to Auth0 Actions

tyler-clark

Tyler works as a developer advocate engineer at Auth0. He's worked as an engineer at small to enterprise level companies and loves everything about tech. You'll frequently find him ether out with his family, playing sports, or coding something. He's also an instructor on <a target='_blank' rel='noopener noreferrer' href='https://egghead.io'><strong><b>egghead.io</b></strong></a>, and his profile is online at <a target='_blank' rel='noopener noreferrer' href='https://tylerclark.dev'><strong><b>tylerclark.dev</b></strong></a>.

Senior Developer Advocate Engineer

Tyler Clark

william_johnson

  Will Johnson is a Developer Advocate at Auth0. He loves teaching topics in a digestible way to empower more developers. He writes blog posts, records screencasts, and writes eBooks to help developers. He's also an instructor on <a target='_blank' rel='noopener noreferrer' href='https://egghead.io'><strong><b>egghead.io</b></strong></a>.


Developer Advocate

Will Johnson

Easily add custom identity functionality to your application with Auth0 Actions

At Auth0, we believe that extensibility is one of our most important product features.

Identity for one customer is not always the same thing for the next. Every customer has specific needs, and a vast majority want to customize our core product to solve their requirements. We are committed to continually looking for ways to enhance our product capability to answer this call.

## Answering the Call

Because every project has a unique use case, we’ve learned over the years that sometimes, just simply building features into our core product is not the right approach. Instead, we are continuously brainstorming new tools that will allow you to customize your identity solution as needed.

[Auth0 Rules](https://auth0.com/docs/rules) was our first publicly available tool that looked to answer extensibility needs. Rules are serverless code blocks that can be customized to extend Auth0's core capabilities.

They execute after authentication but before identity tokens are issued. Our documentation offers a great list of [Rule templates](https://auth0.com/docs/rules/examples) that make it easy to tackle common scenarios out of the box. They can be chained together for modular coding and turned off individually.

Rules are powerful and solve many authentication use cases. We learned through iteration that customers want customization capabilities beyond the login flow.

In response to this learning, we introduced [Auth0 Hooks](https://auth0.com/docs/hooks).

Hooks allow custom behavior using a similar custom code setup as Rules. However, they can be executed against several extensibility points. This includes the client credentials exchange as well as pre and post-registration.

Through several learning iterations, we discovered that even though Hooks can run on more extensibility points than Rules, customers want even more capability from our extensibility platform.

That is why we are excited to announce our next-gen extensibility platform &mdash; [**Auth0 Actions**](https://auth0.com/actions)!

## What Are Auth0 Actions?

Actions are just another tool in your identity solution toolbelt to meet your application needs.

**Actions are functional services that fire during specific events across multiple identity flows.**

This behavior works as a trigger system. The triggers that kick off an Action are extensibility points such as post-login or client credential exchange. The Actions platform is designed for Auth0 to continuously add additional triggers as our core product develops.

![Actions Flow Editor View](https://images.ctfassets.net/23aumh6u8s0i/40Ke9dC8zYj95UqqeT5gsl/f1c699b8fd452749df02f7e0eabc6c86/flow-editor)


## Action Features

The Actions platform comes with:

✋ **Drag N Drop Functionality** &mdash; The flow editor lets you visually build custom workflows with drag and drop Action blocks for complete control.

💻 **Monaco Code Editor with Quick-hints** &mdash; Designed with developers in mind, you can easily write JavaScript functions with validation, intelligent code completion, and type hints.

You can also securely store and use secrets within your custom functions. Once they are saved, they cannot be read in plain text in the code again.

We have also improved the functionality of your code by allowing access to the entire library of NPM packages and modules.

🏢 **Serverless (Function as a Service, FaaS) Environment** &mdash; We host your custom Action functions and process them when desired. The functions are stored and run on our own infrastructure. This improves overall performance and security for our customers.

💾 **Version Control** &mdash; Everything you love about Git and version control is now available for your custom Actions. You can store a history of individual Action changes and the power to revert back to previous versions as needed.

📁 **Pre-Production Testing** &mdash; Outside of Actions, custom extensible code cannot be tested unless rolled to your production environment. We are happy to announce that with Actions, your personal Actions can be drafted, reviewed, and tested before deploying into production

🐛 **Debugging** &mdash; Nothing is worse than getting an error and not having the ability to track down the problem. Actions provide the ability to determine causality by tracking state changes.

> Note: If you are a pro user wondering how this affects Rules and Hooks, don’t worry, as Actions will function separately.

We want to win you over with Actions!

## Create Your First Auth0 Action

Let’s walk through creating your first Action! We'll create an action that will limit access to your application to only Monday through Friday.

Login to your [Auth0 account](https://auth0.com/auth/login). If you don't have one, <a href="https://auth0.com/signup"  data-amp-replace="CLIENT_ID"  data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)"> you can get it for free</a>. In the left sidebar, there's a section titled “Actions.” Click on that. You’ll see two subcategories, “Flows” and “Library.” Click **Flows**.


<img class="img-responsive" src="https://images.ctfassets.net/23aumh6u8s0i/WwtSYEr7NC3sG0hEaHCIC/5100e0b44cb56f6c27fc488a0f60c047/actions-side-menu.png" alt="Dashboard Side Navbar" style="width:50%;margin:auto;"/>

Flows represent a high-level operation within Auth0. The current flows you can add Actions to are “Login,” “Machine to Machine," "Pre User Registration," "Post User Registration," Post Change Password," and "Send Phone Message." For this example, click **Login**.

![Auth0 Actions Choose Flow page](https://images.ctfassets.net/23aumh6u8s0i/p9AvhsMphPqG3GNZlrhhV/e372f5fa71e5450c5aa1dcb98d1402f9/choose_flow.png)

Once you click on **Login**, you should see the following page:

![Flow Editor View](https://images.ctfassets.net/23aumh6u8s0i/6o7moxnQ43hcRSITcMBnYL/88cb46f824ff5fa38ff133abbcd4072c/flow_editor.png)

This is the flow editor. It shows the entire authentication flow for your logging in. You get drag and drop functionality to customize the flow. If your solution has any Rules already set up, you will see them in this view. Any Rules that are defined will be triggered first, and then they will flow into your Actions.

In the top right corner of this view there is a small question mark icon. Clicking this will show a pop-over walkthrough of this view.

Click on the **+** option on the right side, then click **Build Custom** on the pop-in menu.

On the "Create Action" menu, name this Action “Weekdays Only” and click **Create**.

Now, we're in the new and improved Actions code editor, where we can customize our new "Weekdays Only" action.

![Actions Code Editor](https://images.ctfassets.net/23aumh6u8s0i/7ebjO9pO2KJGC0v4efvcT0/12c28949281e6462bc13cd0b76313cc6/code_editor.png)

On the upper right side, we have buttons for "Version history," "Save Draft," and "Deploy."

Unlike with Rules and Hooks, the code editor holistically supports:

- Testing
- Secret management
- Virtually any NPM module
- Linting
- Quick hints

Also, `async` / `await` is set up by default, so you do not need to use callbacks.

In order to see the custom hint functionality, press `CMD` + `space` (`CTRL` + `space` on Windows). Also, by simply hovering over objects such as `event` and `api,` you will see their documentation in a pop-up.

Notice on the left side of the editor is a couple of icons. The play icon is how we can test our Action before deploying it; more on that in a little bit. 

The key icon is how we can add and use secrets in our Actions. For example, when working with APIs, [such as the Slack API](https://auth0.com/blog/send-slack-message-after-sign-up-with-auth0-actions/), we want to make sure we do not expose any API keys accidentally. This is where we can store it once, keep it secure, and reference it in our Actions editor.

Finally, the last box icon is where you add NPM modules in our Actions.

### Write custom code for Actions

Let’s write the code for our Action. We will write an Action that restricts access to the application only during weekdays after logging in.

The code editor has the async JavaScript method `onExecutePostLogin` pre-populated. Any code we write in this function will run after a user logs in.

By default, Actions apply to all applications in your Auth0 tenant.

First, we'll create a variable called `dayOfWeek` and set it to the return value of `new Day.getDay()`. 

The `getDay()` method returns the day of the week according to local time represented by a number (0 = Sunday, 1 = Monday, etc.)

```js
exports.onExecutePostLogin = async (event, api) => {
    const dayOfWeek = new Date().getDay();
};
```

Let's create an `if` statement to check which day of the week our user is logging in on. We'll check if our `dayOfWeek` variable is 0 (Sunday) or 6 (Saturday)

If `dayOfWeek` is equal to 0 or 6, we'll deny the user access with the `api` object with `api.access.deny` and pass in the string "This app is only available during the week."

> Learn more about the API object by [reading the Auh0 Actions API object docs](https://auth0.com/docs/customize/actions/triggers/post-login/api-object)

```js
 exports.onExecutePostLogin = async (event, api) => {
     const dayOfWeek = new Date().getDay();
     
     if (dayOfWeek === 0 || dayOfWeek === 6) {
       api.access.deny("This app is only available during the week.");
     }
};
```

> If you're logging in during the week and want to see this message, change the number in the `if` statement to match what day of the week it is.

### Test Auth0 Actions

We can test it before pushing it to production to ensure this Actions code works. We do this by pressing the play icon on the left sidebar and clicking "Run" at the bottom. This will run our code and display the output on the bottom of the editor. We also can test different scenarios by updating the test data.

Click **Save draft**. We can also revert this action to a previously saved or deployed version by pressing the "Version Control" button on the top of this page. We would see all saved versions with a push-button revert process.

Now that we’ve successfully tested our Action, we can deploy it by clicking on **Deploy**. If an action is not deployed, it does not appear in our flow Action list.

### Add Action to login flow

Now, let’s actually add the Action just created to our flow. Click on the “Flows” tab on the left side navigation and click "Login."

This will take us back to our flow builder, and our "Weekdays Only" Action is now available. Drag the Action and drop it between "Start" and "Complete" in the login flow.

Once we’ve added our Action to the Flow, click **Save**, then **Apply**.

![Flow Editor View with Action](https://images.ctfassets.net/23aumh6u8s0i/7hPHunduk20gvFZ0eeD6LO/7783f7dd4b7270ff2a64b90a87042d74/flow_added.png)

Now let’s try it out.

You can give this a quick test drive without running your full app, by going to the right side menu in the Auth0 dashboard and clicking **Getting Started**. On the _Getting Started_ page, click **Try it out** in the _Try your Login box_ section.

![Auth0 Dashboard Getting Started Page](https://images.ctfassets.net/23aumh6u8s0i/2hH0xeMqhhrXVWg7KzQB3E/827ff6cd4a4124c9fea9aaa1c1b7acca/try_it_out.png)

After you click **Try it out**, you'll be brought to a login screen where you can enter an email and password. Proceed to log in. Once the credentials are entered, you'll see a _Bummer! Something failed_ page with the error `"access_denied"` and an error description of `"This app is only available during the week." `

![Bummer! something failed page](https://images.ctfassets.net/23aumh6u8s0i/6NiXpqFMq2wscQhqUGgR9z/6e3ea82c5f291b0eb3baac5dff82fcd0/failed.png)

And that's all! 

With Auth0 Actions, we were able to:

- Quickly create a reusable custom Action with a built-in user-friendly code editor
- Test, save, and rollback to different versions of the flow
- Attach it to a trigger

Go ahead and add some on your own and let us know what you think in the comments below!

> There are some limits to using Auth0 Actions. To view the most up to date limitations, head over to the [Actions docs](https://auth0.com/docs/customize/actions/limitations).


## What's Coming?

Actions will be an iterative platform that we will continually improve upon. Our vision for Actions includes expanding the number of triggers (extensibility points) you can use to customize Auth0 and introducing new ways to reuse code, so you don’t have to keep writing and maintaining large amounts of custom code.

We'd love to hear what you think about Actions. Be sure to comment **let us know of any future integrations you'd like to see**.

This is just the beginning of Auth0 Actions, and we can't wait to see where we can take it with your feedback!

Introducing Auth0 Actions

ben-dechrai

A technologist with a staunch focus on security and privacy. I love helping developers find the joy of experimentation, and designing unconventional solutions for the purposes of learning something new.

Ben Dechrai

Extend your Auth0 identity workflows with Actions - powerful customisation capabilities with an improved developer experience.

We're excited to announce the **general availability of [Actions](https://auth0.com/docs/actions)**, which simplifies your custom workflows for **extending** Auth0 and offers an improved developer experience from Rules and Hooks!


<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/UesFSY1klrI' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

<AmpContent>
  <amp-iframe width="480" height="270"
    sandbox="allow-scripts allow-same-origin"
    layout="responsive"
    frameborder="0"
    src="https://www.youtube.com/embed/UesFSY1klrI">
  </amp-iframe>
</AmpContent>

## What Is Actions?

One of the core capabilities that Auth0 brings you is the power of **serverless extensibility**.

You might have used [Rules](https://auth0.com/docs/rules/) already to execute custom code after your users log in, or [Hooks](https://auth0.com/docs/hooks) which offer similar functionality around certain other extensibility points. If you have, you'll be forgiven for trying to remember which area to use for what purposes, or wonder why the experience of each is so different.

This is where [Actions](https://auth0.com/docs/actions) comes in.

> Auth0 Actions provides a unified view across secure, tenant-specific, self-contained functions that allow you to customize the behavior of Auth0. Each action is bound to a specific triggering event on the Auth0 platform, which executes custom code when that event is produced at runtime.

## Rules and Hooks Got Us Here

Rules are a really powerful feature of Auth0 and are possibly one of the biggest reasons we stand out from the crowd. They allow you to run custom code after the user logs in and before your tenant hands them back to your application. Being able to augment claims in ID and Access Tokens, call external APIs, or control MFA processes, to name just a few examples, is a game-changer for many.

If you've used them extensively, we're sure you've experienced some limitations.

For starters, we keep a curated list of around 2,000 npm packages that you can use in your scripts. Keeping the list up-to-date and adding new packages is constant work for us and frustration for you.

And a newly saved rule is immediately active, affecting the next user to log in - there's no easy way to test it before this time.

Hooks was our first attempt to improve the experience. The main difference was an improved code editor, and the ability to search for npm packages available in the curated list. You also got access to a more integrated code testing interface with direct access to logs.

By focusing on events outside of the authentication workflow, Hooks added five extensibility points you could tap into:

- Client Credentials Exchange,
- Post Change Password,
- Post User Registration,
- Pre User Registration, and
- Send Phone Message

There are still a few disadvantages, though. Each hook can only have one active script, and you still have the issue of needing to make custom code live to test it.

And of course, now your custom code is split between two locations in the dashboard.

Further, neither Rules nor Hooks have version history. While this is easily solved by using the [Deploy Command-Line Interface (CLI) Tool](https://auth0.com/docs/deploy/deploy-cli-tool), we wanted to provide this ability directly in the dashboard.

## The Difference with Actions

Compare Rules and Hooks with the benefits of Actions, and it's clear this is a major evolution.

![Extensibility Feature Comparison](https://images.ctfassets.net/kbkgmx9upatd/2AtB5N5Y44fftQrQPkt1e6/79b0c00e3f96455ea96f3276fb2dc67e/extensibility-feature-comparison-v2.png)

Actions unites and improves on Rules and Hooks and you'll find everything you need in the two menu items under the Actions header in the dashboard navigation: Flows, and Custom Actions.

Flows is where you can configure the workflows, with the six events you had access to before now available through six triggers (and a potential for more to be added):

![Flows Screen](https://images.ctfassets.net/23aumh6u8s0i/6K2dRDVqbcmqiNMV98IpQO/8dcd45c02d9153924c1cc069529cfc8a/flows.png)

The Custom Actions section provides a common and consistent coding interface that provides all the functionality you need to create your custom functions.

> It's important to remember that Rules and Hooks are still available and will execute before their counterparts in Actions.

### A New Editor

There are many benefits you'll enjoy from Actions, not least being the usefulness of the code editor. We've added contextual assistance and inline docs, so you'll be prompted with suggestions as you type. Whereas you were previously much more reliant on the documentation for Rules and Hooks, you should find development time drops!

<img src="https://tinygif.com/images/2021/05/10/editor-writing.gif" alt="editor-writing.gif" border="0" />
<p align="center">Contextual assistance and inline docs in the new code editor</p>


And when you're ready to test your script, you can save it as a draft and test it right on that screen. You'll get feedback before you even deploy the functions: faster development and more confidence. You'll be nailing this in no time.

<img src="https://tinygif.com/images/2021/05/10/editor-testing.gif" alt="editor-testing.gif" border="0" />
<p align="center">In-editor testing interface</p>

### Consistent Function Signatures

> This is our third-generation extensibility platform, built from the ground up. We've developed a new programming model, which means the underlying objects, data, and APIs available to you in the custom actions are now consistent across each action type. We couldn’t have done this without all the feedback we've received from you since we moved Actions into Beta, so a massive thanks to you!

Each custom action you create will include boilerplate code with a function that gets called when executed. All of these functions will receive an `event` object as their first parameter: a read-only object containing all the inputs and context about this event.

The Post Login, Machine to Machine, and Pre User Registration triggers will also receive an `api` object containing all the outcomes that can take place. Think of this as an encapsulation of the side-effects you are able to perform by modifying the context object used in Rules and Hooks, refactored into documented function calls.

<table border="1">
  <tr bgcolor="lightgrey">
    <th>Capabilities in the <code>api</code> object</th>
    <th style="text-align:center">Post Login </th>
    <th style="text-align:center">Machine toMachine </th>
    <th style="text-align:center">Pre User Registration</th>
  </tr>
  <tr>
    <td>Deny User Access</td>
    <td style="text-align:center">✅</td>
    <td style="text-align:center">✅</td>
    <td style="text-align:center">✅</td>
  </tr>
  <tr>
    <td>Add claims to Access and ID Tokens</td>
    <td style="text-align:center">✅</td>
    <td style="text-align:center">✅</td>
    <td style="text-align:center"></td>
  </tr>
  <tr>
    <td>Set <code>user_metadata</code> and <code>app_metadata</code></td>
    <td style="text-align:center">✅</td>
    <td style="text-align:center"></td>
    <td style="text-align:center">✅</td>
  </tr>
  <tr>
    <td>Conditionally enable multi-factor authentication</td>
    <td style="text-align:center">✅</td>
    <td style="text-align:center"></td>
    <td style="text-align:center"></td>
  </tr>
  <tr>
    <td>Redirect users</td>
    <td style="text-align:center">✅</td>
    <td style="text-align:center"></td>
    <td style="text-align:center"></td>
  </tr>
</table>
<p style="text-align:center;font-style:italic">Operations available in the <code>api</code> object are dependent on the event triggered</p>

You'll notice in the table above that the Post Login trigger can perform a redirect during the authentication flow. Previously, after a redirect to another website during the login flow, the user would be redirected back to your tenant and all the rules and hooks would execute again.

Instead, Actions streamlines the process of getting the user back into the workflow for this trigger by introducing an `onContinuePostLogin` function. When the user returns from a redirect, the Post Login auth flow picks up from where it left off, and you no longer need to ensure idempotency manually.

Here's what a Post Login Action looks like, compared to the single function of a Rule.

![The difference between the Rules and Actions editors](https://images.ctfassets.net/23aumh6u8s0i/2qYhTtK7IgTJqR28pamsOP/4b242867f1d24a5db216ea66b7392c59/rules-v-actions.png)

### Modules, Secrets, and Version Control

Just like Hooks, Actions allows you to define secrets that can be accessed from your custom code, but now you can include **over 1,000,000 npm packages** in your script. That's right, you can now specify any package and even the version from the npm index, so long as there are no native bindings or C modules that need to be built.

<img src="https://tinygif.com/images/2021/05/10/editor-modules.gif" alt="editor-modules.gif" border="0" />
<p align="center">Adding one of 1,000,000 npm modules to an action</p>

And last but not least, you now have version control, allowing you to revert to any previously deployed version of the custom script.

### Adding Deployed Actions to Flows

When you have your first deployed Action, you're going to have to add it to one of the Flows. Selecting "Login" from the Actions > Flow screen will show you the login flow, at which point you can drag your Actions from the right-hand pane into that flow. Arrange multiple Actions as desired, click the "Apply" button, and you're set!

<img src="https://tinygif.com/images/2021/05/10/flow-editor.gif" alt="flow-editor.gif" border="0" />
<p align="center">Adding an Action to a Flow is a simple as drag-and-drop</p>

### Debugging and Management

We've touched on testing before making custom code live, but once your Actions are in use, you'll be glad to know the tenant logs will now include Actions-related details where applicable. Any log entry that is associated with an Action will now include an "Action Details" area, which shows not only any generated output, you'll also get some itemized stats on how long it took to execute the Action.

Naturally, as with everything else in your tenant, the things you can do through the dashboard can also be done through the [Management API](https://auth0.com/docs/api), via the [Management API SDK Libraries](https://auth0.com/docs/libraries#mgmt), and the [Deploy Command-Line Interface (CLI) Tool](https://auth0.com/docs/deploy/deploy-cli-tool).

## What's Next?

We're so excited to get Auth0 Actions into everyone's hands - we'd love to hear what you think. Be sure to comment below with your thoughts or questions.

This is just the beginning of Auth0 Actions. There's so much more to come, and we can't wait to see where we can take it with your feedback!

<include src="asides/AboutAuth0" />

Auth0 Actions Is Now Generally Available

With Auth0’s Actions, it’s easy to ensure that users can sign up for an account only between a specific start date and end date.

Some applications have a limited lifetime. A website or app for limited-time events such as a conference, convention, or concert will only be useful when the event takes place. Since there’s no point in allowing people to sign up for an account after the event is over, you may want to limit registration to a specific set of dates.

It usually takes a considerable amount of work to limit the dates when new users could register an account. However, if you’re using Auth0 to authenticate your users, this task became a lot easier thanks to Actions!

Actions are a new feature that allows you to extend Auth0 beyond what it can do “out of the box”. They’re Node.js functions that you can add to various flows within Auth0’s processes, including logging in, changing passwords, and signing up for a new account. You write and store these functions in the Auth0 dashboard, where they’re part of your tenant’s settings, and Auth0’s servers execute them.

In this article’s exercise, you’ll learn how to write an Action that limits when users can sign up for an account for a specific application. If a user signs up for an account outside the defined valid registration period, their attempt to sign up will be canceled, and they will see a message explaining why.


## Prerequisites

You’ll need the following for this exercise:

- **Auth0 account:** Actions are an Auth0 feature, which means you need an Auth0 account to use them. <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">You can sign up for free,</a> and the process is pretty painless.
- **Any application that uses your Auth0 tenant to provide Universal Login.** Any web-based, mobile, or desktop application will do, just as long as it is one of your tenant’s applications. You’ll need it to log in and see how defining Actions changes how login works. If you don’t have any applications that use Auth0 for authentication, you can download one from the [Auth0 Quickstarts](https://auth0.com/docs/quickstarts/) page.


## Create a New Action

The first step in creating a new Action is navigating to the appropriate authentication flow. Do this by selecting **Actions** from the left-side menu, then select **Flows** from the sub-menu that appears:

![The Auth0 dashboard’s “Getting Started” page, with instructions to select “Actions” and “Flows” from the left side menu.](https://images.ctfassets.net/23aumh6u8s0i/6Fm12KNWxp84G1d0fo7Mwe/5a5e2ed7081685188631b9bd24210534/select_actions_then_select_flows.png)

You’ll be at the *Choose Flow* page, where you can select the flow for your Action. In this case, we want to create an Action that runs immediately after the user submits an email address and password to sign up for an account. Do this by selecting the **Pre User Registration** flow:

![The “Choose Flow” page, with an instruction to select “Pre User Registration”.](https://images.ctfassets.net/23aumh6u8s0i/1FuLu1sJEPZAkqr1NrCrs7/8687dc2967b23e8a8047e98fdcdb9b72/select_pre_user_registration.png)

This will take you to the *Pre User Registration* flow page, which contains a flowchart depicting the pre-user registration flow in the center of the page, and a column labeled *Add Action*, which lists Actions you can add to the flow.

It’s time to create an Action to add to the flow. Do this by clicking the **+** button in the *Add Action* column, then select **Build Custom** from the menu that appears:

![The “Pre User Registration” page, with instructions to click the “+” button, then select “Build Custom”.](https://images.ctfassets.net/23aumh6u8s0i/6oAnPkD7GIzbH7Xum2x4ra/03191b4a3cd51bbdc39e1cc073b65c6e/click_the_plus_button_then_build_custom.png)

The *Create Action* dialog box will appear. Give the Action an appropriate name in the **Name** field. I chose **Limit App 001 registration to Jan 2022**. Leave the **Trigger** and **Runtime** menus at their default settings, and click the **Create** button:

![The “Create Action” dialog box.](https://images.ctfassets.net/23aumh6u8s0i/185ogMV4v4tNO9darSqBPj/94ed284bac44add5983108887c3611f0/create_action.png)

You’ll be taken to the code editor for your newly created Action:

![The code editor for the newly created Action.](https://images.ctfassets.net/23aumh6u8s0i/4s2yJTUGUYJvQGWr7khSdV/389419f0fa32a28ff1968e33d4dfb1f9/code_editor.png)


## Write Code for the Action

Let’s write a quick specification for the Action before we code it.

The Action should:

- Only affect sign-ups for a given application. In this exercise, we’ll call it “App 001”. It should not affect sign-ups for any other applications in the tenant.
- Limit registration so that users can sign up for an account only between a given start date and end date. For this exercise, let’s limit registration to January 2022.
- If a user tries to sign up before or after the registration period above, their attempt should fail, and they should be shown a message explaining why.

Here’s the code that implements that specification. It limits registration to the month of January 2022. You should adjust the start and end dates for the registration period as you see fit:

```javascript
exports.onExecutePreUserRegistration = async (event, api) => {
  if (event.client.client_id === /* CLIENT ID GOES HERE */) {
    // Remember, Date objects are GMT by default!
    const startDate = new Date(/* START DATE/TIME GOES HERE */) 
    const endDate = new Date(/* END DATE/TIME GOES HERE */)
    const now = new Date()

    if (now < startDate || now > endDate) {
      const LOG_MESSAGE = "APP 001 registration outside January 2022"
      const USER_MESSAGE = "Registration for this app is limited to January 2022."
      api.access.deny(LOG_MESSAGE, USER_MESSAGE)
    }
  }
}
```

You’ll need to customize the code above for your situation:

- Replace the `/* CLIENT ID GOES HERE */` comment with the application’s client ID that this Action should apply to. The Auth0 dashboard’s *Applications* list (select **Applications** → **Applications** from the menu on the left side of the page) shows the client ID of every application in your tenant.

![Copying a client ID from the “Applications” page.](https://images.ctfassets.net/23aumh6u8s0i/3p7mcb0rAUFt1zl8eSV8Uf/2234916fcfe8217c85d685fdd20fe10d/copy_client_id.png)

- Replace the `/* START DATE/TIME GOES HERE */` comment with the date and time of the start of the valid registration period. Since we want to limit registration to January 2022, use a start date value of “2021-01-01T00:00:00”.
- Replace the `/* END DATE/TIME GOES HERE */` comment with the date and time of the start of the valid registration period. For this exercise, use an end date value of “2021-01-31T23:59:59”.

Auth0 calls the `onExecutePreUserRegistration()` function just after the user has provided an email address and password to sign up for an account but before the account is created. Any code entered into this function can examine the credentials provided by the user or use any other information to decide if the registration should take place or be canceled.

`onExecutePreUserRegistration()` takes two parameters, whose properties you can use to perform tasks prior to the user being registered:

1. `event`: An object that contains details about the request to register a new user. The Action uses `event` ’s `client.client_id` property to identify the application that triggered it. Remember, the limited registration period should apply only to App 001.
2. `api`: An object with methods that you can use to change the behavior of the Pre User Registration flow. The Action uses `api`’s `access.deny()` method to cancel registration. `access.deny()` has two parameters:
  - `reason`: A string containing an *internal-facing* reason why registration is being canceled. This value will appear in your tenant’s logs.
  - `userMessage`: A string containing an *external-facing* reason why registration is being canceled. This value will be displayed to the user to explain why they can’t sign up for a new account.

With the code entered, click the **Deploy** button to save it. 


## Add the Action to the Flow

Now that you now have a working Action, it’s time to incorporate it into the flow.

Go back to the *Pre User Registration* page. There are a couple of ways to do this:

- Select **Actions** → **Flows** from the menu on the left side of the page, then click on **Pre User Registration**.
- If it’s onscreen, click on the **Back to Flow** link. It will be near the upper left corner of the code editor).

Once you’re on the *Pre User Registration* page, you should see the Action you just created in the *Add Action* column:

![The “Pre User Registration” flow, with an instruction to start dragging the newly-created action.](https://images.ctfassets.net/23aumh6u8s0i/7fNARXSPtCo7Gt0gwinM9h/682c304760f28e3dc3c250f484885b44/pre_user_registration_flow_1.png)

Drag the Action into the flow, as shown in the screenshots above and below.

![The “Pre User Registration” flow, with an instruction to drag the newly-created action into the flow.](https://images.ctfassets.net/23aumh6u8s0i/p6eeehO3r4ZHl2kMrRSSu/90a3d139cca604a9c7430ead524dc1e1/pre_user_registration_flow_2.png)

Click the **Apply** button near the upper right corner of the page. The change you just made to the flow will not take effect until you do so.


## Try to Sign Up for an Account

At this point, your Action is now part of the Pre User Registration flow. Whenever a user submits their email address and password to sign up for a new account, your Action will be triggered and execute its code.

Run the app that you wrote the Action for. Sign up for a new account instead of logging in when you reach the login screen. As long as the current date is outside your Action’s start date and end date, you should be able to enter any valid email address and password because the registration will never happen. You should see the following instead:

![The login box for the application, with a message under the “Password” field that says “Registration for this app is limited to January 2022.”](https://images.ctfassets.net/23aumh6u8s0i/w362yU7dfAnTDbLT42YHU/a2dcb648b06602cd95583cd5c2bbf591/sign-in_canceled.png)


## Experiment!

Now that you know the basics of restricting new registrations, you might want to try some different test conditions, such as:

- **Limiting sign-ups to users in specific countries.** There may be legal, business, or security reasons for letting only users in specific countries sign up for an account. The `event` object provides a lot of information about the request to create a new user account, including the user’s geographical location based on their IP address, which you can access using `event.request.geoip.countryName`. Check out our article, [*Country-Based Access with Auth0 Actions*](https://auth0.com/blog/country-based-access-with-auth0-actions/), to see how you can apply this technique to logins.
- **Disallowing sign-ups from certain IP addresses.** If you see a lot of malicious activity from certain IP addresses, you can block their sign-up requests. This is another use case where the `event` object comes in handy. Use `event.request.ip` to determine the address of the user attempting to register and deny their registration if it appears in a list of known malicious addresses.
- **Limiting sign-ups to weekdays.** You can use JavaScript’s `getDay()` function to see if the current date/time falls is a weekend day. Keep in mind that while Saturday (for which `getDay()` returns `6`) and Sunday (for which `getDay()` returns `0`) constitute the weekend in most places, some regions have different weekend days. Once again, you may also have to account for time zone differences.

Limit User Registration to Specific Dates with Auth0 Actions

enes-akar

Enes Akar is Co-Founder of Upstash, which is a Serverless Data Platform for Redis and Kafka. He 10+ years experience on distributed systems. He used to work for Confluent and Hazelcast before Upstash.

CEO at Upstash

Enes Akar

Use Auth0 Actions to send authentication events to Apache Kafka.

In this post, you’ll learn how to integrate Auth0 with [Apache Kafka](https://kafka.apache.org/) using Actions. You’ll do this by writing an Action that pushes information from new user registrations to a Kafka cluster. By doing this, you open a number of analytics and user experience possibilities, including:

*   Processing sign-up events (with [Apache Flink](https://flink.apache.org/) or [Spark](https://spark.apache.org/)) to notify your business and sales team when a new user signs up for an account.
*   Trigger processes such as sending a welcome email or Slack message in response to a user signing up.
*   Using a [Kafka connector](https://docs.snowflake.com/en/user-guide/kafka-connector-overview.html) to move the user data gathered from the sign-up process to a database or data warehouse to feed reporting and analytics applications.
*   Feeding new user data to your CRM application.

![Kafka](https://images.ctfassets.net/23aumh6u8s0i/47eyPrCR712YD4KWSRvG80/8150b144cf5cbb5747096d3f3af8bea4/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

## Why Apache Kafka?

Apache Kafka is a distributed messaging platform that receives data as events in real-time from sources such as sensors, mobile devices, databases, applications, and services (including Auth0) and makes that data available to target systems. It supports both publish/subscribe and distributed queue scenarios. Kafka gives you the flexibility to perform both stream processing and batch processing with your data. Kafka’s replication feature and durability allow you to use it as a persistent hub for your data.

## Auth0 Actions

Auth0 Actions are serverless Node.js functions that are triggered by certain events that take place when signing up for an Auth0 user account or authenticating with Auth0. Using Actions, you can customize and extend Auth0’s capabilities with your custom logic that you can add to events such as login, registration, changing passwords, and more. Auth0 Actions are stateless, so you’ll need an external store if you use them to collect data. Check [this article](https://auth0.com/docs/customize/actions/actions-overview) to learn more about Actions.

In this post, we will write an Auth0 Action which will be triggered by the Post User Registration flow, which happens after a user has completed signing up for an account.

## Create a Kafka Cluster

Because Auth0 Actions are stateless, we need a Kafka service that does not require stateful connections. We will use [Upstash’s Kafka service](https://upstash.com/kafka), which has a REST API and is designed for serverless environments and a free plan suitable for this project.

If you don’t already have an Upstash account, [sign up for one](https://console.upstash.com/login). The process is very quick, especially if you sign up using an Amazon, GitHub, or Google account. You’ll be taken to the [Upstash console](https://console.upstash.com/) immediately afterward:

![Cluster](https://images.ctfassets.net/23aumh6u8s0i/7i8OxJQwxFJZYOAKZGvS1f/d89275afb1698cc4f7c498eb100fb12d/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Select **Kafka** in the menu bar at the top of the page. You’ll be taken here:

![Cluster](https://images.ctfassets.net/23aumh6u8s0i/4shEb8jySPGei6xBcZ0DPK/6e056b1ae7fa8e0a9a60f7f67d047506/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

In order to use Kafka, you need a cluster, which is a set of one or more servers running Apache Kafka. Click the **Create Cluster** button. This form will appear:

![Cluster](https://images.ctfassets.net/23aumh6u8s0i/6LZJRtkgqpHLUPxpdoesuj/08d7a77dc2da2ef54e57f3dea316eaf7/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Provide the following information for each of its fields:

*   **Name:** Pick a name that will make it easy to recognize, such as “Auth0 Actions Test.”
*   **Region:** Select the region closest to you.
*   **Type:** Select **Single Zone**

Click the **Create** button to continue. You’ll see the form’s second page:

![Create](https://images.ctfassets.net/23aumh6u8s0i/130Z4nzMY3elKtmElpZz4o/d25551d11ae2615697e6b724199cac47/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

You need to provide a name for a _topic,_ which is how Kafka organizes events. If you think of events as being like files, topics are like directories. Enter the topic name **user-events-topic** into the **Name** field and click the **Send Request** button.

Upstash will create the cluster and immediately take you to its **Details** page:

![Details](https://images.ctfassets.net/23aumh6u8s0i/1iU7Q3GmamqgUbJQGVOOeF/fbf5724310a40936c0937a0e3d4baeca/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Scroll down to the **REST API** section, where you’ll see controls to copy the values for `UPSTASH_KAFKA_REST_URL`, `UPSTASH_KAFKA_REST_USERNAME`, and `UPSTASH_KAFKA_REST_PASSWORD`, which you will use in the next step.

![REST API](https://images.ctfassets.net/23aumh6u8s0i/3FEKvlN77iwUh0V8RBQ6aC/265f34f90d4d38ad09f64b5662a7dc79/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Keep this page open in a browser tab or window; you’ll need it shortly.

## Implement the Action

You will need an Auth0 account for this step. If you don’t already have an account, [you can sign up for one for free.](https://auth0.com/signup)

### Create a new action

Log into the Auth0 dashboard. On the left menu, select **Actions** → **Library**, then click the **Build Custom** button. This will open the **Create Action** pop-up:

![reate Action](https://images.ctfassets.net/23aumh6u8s0i/541DakfFmVUUMnBG9vHwr9/f60d4fe3cd82639f39f835a32b9c4a51/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Provide a name for the Action (I used **sendKafka**).  

Since the goal is to send a message to Kafka after a user has signed up for an account, the action should be triggered by the Post User Registration event. Select **Post User Registration** from the **Trigger** menu, then click the **Create** button.

You should now see the code editor:

![reate Action](https://images.ctfassets.net/23aumh6u8s0i/4QTUZab91hhnUek6nbydtm/789ab00bcbde339441a01d02ec0018c5/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

### Define the Action’s secrets

To send messages to the Kafka cluster, the Action needs the `UPSTASH_KAFKA_REST_URL`, `UPSTASH_KAFKA_REST_USERNAME` and `UPSTASH_KAFKA_REST_PASSWORD` values for your Kafka cluster, which you can copy from the Upstash console. You could simply use these values to define constants, but it’s more secure to keep them hidden. You can do this with Actions’ **_Secrets_** feature, which lets you securely store sensitive values and access them as properties of the `event.secrets` object.

Let’s start with the first value, `UPSTASH_KAFKA_REST_USERNAME`. Switch to the browser tab or window with the Upstash console and click on the icon beside `UPSTASH_KAFKA_REST_USERNAME` to copy its value. Then switch back to the Action code editor and click the “Secrets” icon:

![Secrets](https://images.ctfassets.net/23aumh6u8s0i/25t3LnePJf5WZEZlXWUNWk/d8eb298b643cc246f4edd5e9f16e8dc3/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

A new column with the title **Secrets** will appear in the code editor:

![Secrets](https://images.ctfassets.net/23aumh6u8s0i/5Mpielp1PpUBKdggFN95Ez/ff08915ea004c8a7eb894aa92bc1faec/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Click the **Add Secret** button. A pop-up will appear, and you will be able to define your first secret value:

![Add Secret](https://images.ctfassets.net/23aumh6u8s0i/6dxqg239qUPjaKFocZeGcT/c0acea0519808c411846200a23fee411/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Enter `UPSTASH_KAFKA_REST_URL` into the **Key** field, paste the value you copied from the Upstash console into the **Value** field, and click the **Create** button. This will create a property named `event.secrets.UPSTASH_KAFKA_REST_URL`, which you will be able to use in your Action.

Click the **Add Secret** button again. This time, define the `UPSTASH_KAFKA_REST_USERNAME` secret by copying its value from Upstash and filling out the **Define Secret** form as shown below:

![Add Secret](https://images.ctfassets.net/23aumh6u8s0i/g1QnSJwEekRL6u2lbcWoa/12a993bf7846febff07fbe3a4962f3e4/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Click the **Create** button, then click the **Add Secret** button one more time. Define the `UPSTASH_KAFKA_REST_PASSWORD` secret by copying its value from Upstash and filling out the **Define Secret** form as shown below…

![Define Secret](https://images.ctfassets.net/23aumh6u8s0i/35dYyYGnD9CrFlUNPhigqB/afd68d74bc539e86f607af23a956dab9/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

…then click the **Create** button. The **Secrets** column should now contain a list of three secrets:

![Create](https://images.ctfassets.net/23aumh6u8s0i/1wkGPTskvMIU8BHQUXdlTn/6090399c09c0cecebf448949444b5fa7/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

### Add the node-fetch module to the Action

You can import any npm module into an Action, which makes them very powerful. This action uses the [node-fetch](https://www.npmjs.com/package/node-fetch) module to send events to the Kafka cluster, so you’ll need to add it as a dependency. You can do this with the **_Modules_** feature.

Click the “Modules” icon, which is just below the “Secrets” icon:

![Modules](https://images.ctfassets.net/23aumh6u8s0i/1FIkQiyIwiEnMuLceyRqWm/229bfc23e1b8b9fb8c1f804fbfa672a4/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

A new column with the title **Modules** will appear in the code editor:

![Modules](https://images.ctfassets.net/23aumh6u8s0i/6D6vSKdIZwkhIk26zhpMfv/f6c18c676a69f6c519ba9b30166034e9/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Click the **Add Module** button. A pop-up will appear:

![Add Module](https://images.ctfassets.net/23aumh6u8s0i/7KbTmaZmZNNUDiMnqgvPF9/c1fa1efdc6285f5f51405f8a924df68c/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Enter **node-fetch** into the **Name** field and **2** into the **Version** field. Do _not_ select the latest version (3 at the time of writing), as it does not allow `require()` to import it.

Click the **Create** button. The **Modules** column should now list the _node-fetch_ module:

![Create](https://images.ctfassets.net/23aumh6u8s0i/3Uvbaeb6xNhGQWcE2T8Ru4/2dd6b53db2bf15ab2f23e020416e366c/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

### Write the Action

Now that you have provided the prerequisites, it’s time to write the Action!

Paste the code below into the editor:

```
const fetch = require('node-fetch');
 
exports.onExecutePostUserRegistration = async (event) => {
  const address = event.secrets.UPSTASH_KAFKA_REST_URL
  const user = event.secrets.UPSTASH_KAFKA_REST_USERNAME
  const pass = event.secrets.UPSTASH_KAFKA_REST_PASSWORD
  const auth = Buffer.from(`${user}:${pass}`).toString('base64')
  const topic = 'user-events-topic'

  const userData = JSON.stringify(event.user);
  const x = await fetch(`${address}/produce/${topic}`, {
    method: 'POST',
    headers: {'Authorization': `Basic ${auth}`},
    body: JSON.stringify({"value" : userData})
  })
  const response = await x.json();
  console.log(response)
};
```

This Action uses the `onExecutePostUserRegistration()` function provided by Auth0. The function is called when the user has finished signing up for an account. It takes a single parameter, `event`, whose `user` property is an object containing information about the newly-registered user, such as their email address and user ID.

This code retrieves the secret values stored in the Action’s Secrets and uses them to connect to the Kafka cluster. It takes the `user` object, converts it into a raw JSON string, and sends it to the topic named `user-events-topic` in the Kafka cluster. The user data to the Kafka topic using the Upstash REST API.

### Test the Action

Now, we can run the function by clicking on the **Test** icon on the editor’s sidebar:

![Test](https://images.ctfassets.net/23aumh6u8s0i/6UPSQybrGeZRu0kj6qzpsQ/13cf0a64078bd41880c5352ef585dc04/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

A new column with the title **Test** will appear in the code editor:

![Test](https://images.ctfassets.net/23aumh6u8s0i/6iPKb04fleyOW1kndgekn5/8a43590a9482e388757f5cecf628b227/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Click the **Run** button to run the test. A **Test Results** pane will appear in the lower section of the code editor:

![Run](https://images.ctfassets.net/23aumh6u8s0i/3NNpjQElJ4qrQQAGPSZ5mj/750f79ace5041fb987f839115067ea2b/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

You should see something similar to the output below in the **Logs** section:

```
Logs:
[
  {
    topic: 'user-events-topic',
    partition: 0,
    offset: 317,
    timestamp: 1641950606804
  }
]
```

You now have a working Action. It’s time to deploy it!

## Deploy the Action

Click the **Deploy** button located near the upper right corner of the page. This saves your Action and makes it the current version in your library,

Now that your Action is in the Library, you need to add it to the Post User Registration flow. Navigate to the flow by selecting **Actions** from the left side menu, then **Flows** →**Post User Registration**. You’ll see this:

![Deploy](https://images.ctfassets.net/23aumh6u8s0i/MTvdp0U3YWpwQ3zP0PNvm/cd660cc3c68f8c1b3f85738f4b764915/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

In the **Add Action** section on the right side of the page, select the **Custom** tab to see the Actions you have created:

![Deploy](https://images.ctfassets.net/23aumh6u8s0i/2ws2KlG9D05TFenL1KkHz5/3665c18f8042ba8f30ae2772c48fc206/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

You should see the **sendKafka** action. Drag and drop it to the area between the **Start** and **Complete** nodes in the flow as shown below:

![sendKafka](https://images.ctfassets.net/23aumh6u8s0i/6xO4IuP3sJXiURYYFYQDqt/4ba5fb18546c69890af0c71cefe55f27/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Now that you have added your Action to the flow apply the change by clicking the **Apply** button near the upper right corner of the page.

## Test the Action

Now that the Action is deployed, it’s time to test it!

### Create a new user

The Action you just created runs whenever a new user signs up, so one way to test it is to create a new user using the Auth0 dashboard.

In the Auth0 dashboard’s left menu, select **User Management** → **Users** → **Create User** and create a new user:

![User Management](https://images.ctfassets.net/23aumh6u8s0i/4oVUjX54aRwTPCOu4bBqXu/6e6bd39df85e29061f918af92681067f/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

After creating the user, switch to the Upstash browser tab or window, select the **Topics** tab, and then select the **user-events-topic** topic:

![Topics](https://images.ctfassets.net/23aumh6u8s0i/5KBLE6L4v4AVlNb5RsQPKX/208f1e1ba0c3820de192cf4d928c99d7/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

This will display the statistics for your Kafka topic:

![Topics](https://images.ctfassets.net/23aumh6u8s0i/6bYnLjjiKI1uQ8hTl7hQnQ/3c318e37ea74536beaa3923054b2c1f8/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Each time you create a new user, a new message is pushed to the Kafka topic, increasing its count —which appears under **Messages** —by one.

You can check the Kafka topic by using the **Consumer** curl script in the **REST API** section under the **Details** tab:

![Details](https://images.ctfassets.net/23aumh6u8s0i/54opQIKp8N757l82HmPrle/199a88de3d5caad79126da557fd76d26/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

![Details](https://images.ctfassets.net/23aumh6u8s0i/7HtICJcX8nk92VgX7O244c/053a270c39a0fb52ea759e85b476812b/Uploaded_from_Send_Auth0_Events_to_Kafka_for_Realtime_Processing_)

Run the curl script in your command line console. The result should look something like this:

```
[ {
  "topic" : "user-events-topic",
  "partition" : 0,
  "offset" : 316,
  "timestamp" : 1641948554609,
  "key" : "",
  "value" : "{\"email\":\"exampleuser@example.com\",\"tenant\":\"test-upstash\",\"user_id\":\"auth0|61de2511fd334200aq221d\",\"app_metadata\":{},\"user_metadata\":{},\"email_verified\":false,\"phone_verified\":false}",
  "headers" : [ ]
} ]%
```
## Conclusion

Auth0 Actions enable developers to inject custom logic into the user lifecycle, adding additional behavior and features to the login process. In this article, we used Auth0 Actions to produce events for Kafka triggered by new user registrations. Once stored in Kafka, there are endless possibilities for how you can leverage the data.

Use Auth0 Actions to Send User Info to Apache Kafka When They Register

Here’s a collection of Actions that you can write quickly to perform useful tasks.

[Actions](https://auth0.com/docs/actions) make it possible for you to customize the way Auth0 works. They do this by letting you insert scripts — called *Actions* — into various Auth0 workflows to add functionality and enhance your users’ experience.

Actions can be complex, but they don’t need to be. In this article, I’ll show you a handful of Actions that can you can enter in a minute or two, but perform tasks that you’ll find useful in the day-to-day running of your applications.


## Redirect Users to a “Downtime” Page

Sooner or later, your application will have downtime. If all goes well, it will be *scheduled* downtime, but there will likely be *unscheduled* downtime too. In either case, it’s useful to have a web page where you can redirect users to inform them that your application is unavailable and provide additional details.

You can do this by adding the following Action to the [Login flow](https://manage.auth0.com/#/actions/flows/login/), replacing `{SYSTEM DOWNTIME PAGE URL}` with the location of the web page explaining the downtime:

```javascript
// Login flow

exports.onExecutePostLogin = async (event, api) => {
  api.redirect.sendUserTo("{SYSTEM DOWNTIME PAGE URL}");
};
```

When your application is down, drag this Action into your tenant’s Login flow. It uses the `api.redirect.sendUserTo()` method to redirect the user to the given URL after they log in.

Keep in mind that users will see the downtime page only after logging in successfully.


## Temporarily Disable New Account Sign-ups

It *is* possible to have too much of a good thing. You generally want many users signing up to use your application, but there can be times when you need to stop registration to scale up your systems or allow your staff to catch up.

If you’re ever in this kind of situation, one of the measures you can take is to disable sign-ups temporarily. You can do this by creating a new Action named “Refuse New Sign-ups” in the [Pre User Registration flow](https://manage.auth0.com/#/actions/flows/pre-user-signup/):

```javascript
// Pre User Registration flow

exports.onExecutePreUserRegistration = async (event, api) => {
  api.access.deny('too_many_signups', "We’re not accepting sign-ups at the moment.");
};
```

This Action uses the `api.access.deny()` method, which cancels the user registration process and any subsequent Actions. It takes two arguments:

* `reason`: This is a string that provides an internal reason why you’re denying the user’s attempt to sign up for an account. This is for the benefit of the application’s developers and administrators and will appear in the tenant’s logs. We recommend that this be a short label rather than a sentence.
* `userMessage`: This is also a string, and it’s the *user-facing* reason why they’re not able to sign up for an account. You want this message to be user-friendly, and we recommend that this be a full sentence. 

With the “Refuse New Sign-ups” Action deployed and added to the Pre User Registration flow, this is what the user will see when they attempt to sign up:

![“Sign up” screen displaying the message “We’re not accepting sign-ups at the moment.”](https://images.ctfassets.net/23aumh6u8s0i/1vuCHpnYHpEWrtbjREPvBN/32ae15dbc0db8e5f02d2bc7e25f9bb54/refuse_sign-up_action_1.png)

While the login box shows the “We’re not accepting sign-ups at the moment” message, you can see that the message is dwarfed by the big red box containing password requirements. 

At the moment, there’s no way to “turn off” that big red box, which was created before we had Actions and the Pre User Registration flow. For now, you should use messages that are at least two sentences long in order for them to be more easily seen:

![“Sign up” screen displaying a longer version of the mesage “We’re not accepting sign-ups at the moment.”](https://images.ctfassets.net/23aumh6u8s0i/2Cafl2dxdCzPCF1Po4mNcH/47721e5f44f0cd693432cf189c7384ba/refuse_sign-up_action_2.png)


## Initialize a New User’s Metadata

Every Auth0 user account stores information about the user as metadata, which your application access. Two kinds of metadata are stored:

1. **User metadata:** A set of attributes about the user that *don’t* affect the app’s core functionality. The user *can* view and modify this information, which typically comprises user preferences and settings.
2. **App metadata:**  A set of attributes about the user that *do* affect the app’s core functionality.  The user *cannot* view and modify this information, which includes things such as their status and state within the application, or any other settings that determine what features or activities are available to the user.

You can use an Action in the Pre User Registration flow to set the user’s user and app metadata to their initial values. In the example below, the Action sets values in both a newly-created user’s user metadata and app metadata:


```javascript
// Pre User Registration flow

exports.onExecutePreUserRegistration = async (event, api) => {
  api.user.setUserMetadata("ui_color", "default");
  api.user.setUserMetadata("use_verbose_messages", false);  
  api.user.setAppMetadata("is_new_user", true);
  api.user.setAppMetadata("reward_status", 0)
};
```

The code above uses two methods — `api.user.setUserMetadata()` and `api.user.setAppMetadata()` — to initialize the new user’s user and app metadata respectively.

With this Action inserted into the Pre User Registration flow, every new user — whether created by clicking the **Sign up** link in the login box, or through the Auth0 dashboard or management API — will have the following user and app metadata:

![A user account’s user and app metadata displaying the initialized metadata after the Action is run.](https://images.ctfassets.net/23aumh6u8s0i/2h5wwSK8OlMj6k0uqQMLw8/eacb8b3157c4bebc9b65b38de5d244f7/new_user_metadata.png)


## Email the User after a Password Change

It’s good to email the user immediately after the password to their account changes. If the user made the change, the email is a reminder of when they last updated their password. If the user *didn’t* make the change, it could be a sign that an unwanted party has access to their account. 

You can set up this kind of email notification by adding an Action to the [Post Change Password flow](https://manage.auth0.com/#/actions/flows/post-change-password/), as shown below:

```javascript
// Post Change Password flow

function sendGmail(username, password, emailAddress, subject, message) {
  try {
    const send = require('gmail-send')({
      user: username,
      pass: password,
      to: emailAddress,
      subject: subject,
    });
    send({
      text: message,  
    }, (error, result, fullResult) => {
      if (error) console.error(error);
      console.log(result);
    })
  } catch (err) {
    console.log(`Error sending email to ${emailAddress}:`, err.message)
  }
}

exports.onExecutePostChangePassword = async (event) => {
  sendGmail(
    event.secrets.GMAIL_USERNAME,
    event.secrets.GMAIL_PASSWORD,
    event.user.email,
    "Your password has been changed",
    `
This is a quick message to let you know that your password has been changed. If you made this change,
you can ignore this email. If you DIDN’T make this change, please contact the administrator.
    `
  );
};
```

This is a more complex Action than the previous examples. It requires more setup, which I’ve outlined below.


### Wait… a *Gmail* account?

While you shouldn’t use Gmail as an email server for a production app, I find that a Gmail account dedicated to testing can be useful for prototyping.

To set up such an account, [sign up for a new Gmail account](https://accounts.google.com/signup). Don’t enable two-factor authentication on this account, because doing so makes the next step in the process unavailable.

[Go to the home page for your newly-created account](https://myaccount.google.com/) and select *Security* from the menu on the left side of the page. Scroll down until you see the *Less secure app access* section and click on the *Turn on access (not recommended)* link. Set the *Allow less secure apps* switch to the ON position.

You will now be able to use this Gmail account to send emails on behalf of your Action.

Please remember you should use this account for testing purposes only! For a production application, use a dedicated email-sending API.

> Don’t forget that [Gmail has an API](https://developers.google.com/gmail/api) that provides authorized access to the data in a user’s Gmail account and can be used to perform several actions, including reading, sorting, sending, and backing up mail, as well as managing user settings such as aliases, signatures, filtering, and forwarding.


### Store your secrets

The `onExecutePostChangePassword()` function delegates the sending of email to another function, `sendGmail()`. When the time comes to move the Action out of the prototyping phase, I can have `onExecutePostChangePassword()` call a different function with the same parameters that accesses an email API that’s more suitable for production.

You may have noticed that I didn’t hard-code the Gmail account’s username and password values into the Action. Instead, they appear to be properties of the `event.secrets` object. These are ***secrets*** — values that are securely stored in the *Secrets* section of the action.

To manage an Action’s secrets, click on the key icon on the left side of the Action editor. This will open the *Secrets* panel, where you can add, edit, and delete values that you want to keep secret:

![The “Secrets” panel and its controls.](https://images.ctfassets.net/23aumh6u8s0i/1wINrTk7gpX8oZsg4WbpUg/2f8c8b27c033256d2280790d911a8045/secrets_panel.png)

When you click the *Add Secret* button, a pop-up appears, allowing you to define a secret as a key-value pair:

![The “Define Secret” dialog box.](https://images.ctfassets.net/23aumh6u8s0i/N8Y5cvyvcAL8ybLaKkzmz/6f7d7fa02932b4f1755595608dfa1c4a/define_secret.png)

Once defined, you can access secrets as properties of the `event.secrets` object. The two secrets that I defined — `GMAIL_USERNAME` for the username of my prototyping Gmail account and `GMAIL_PASSWORD` for its password — can be accessed in the Action code as `event.secrets.GMAIL_USERNAME` and `event.secrets.GMAIL_PASSWORD`.


### Add modules

The `sendGmail()` function uses the `require()` function to include the `gmail-send` npm module to send email notifications to the user through Gmail. But how do you make `gmail-send` available to your Action?

You do it using the *Modules* panel, which you can access by clicking on the package icon on the left side of the Action editor:

![The “Modules” panel and its controls.](https://images.ctfassets.net/23aumh6u8s0i/5x4ommIbuuJMF4Y5da7JFG/a55ecf98020fa510ab0e3bd9349b2891/modules_panel.png)

The *Modules* panel lets you bring in functionality from any combination of modules in npm’s vast collection. 

To add a module to your Action, click the *Add Module* button. A pop-up will appear, allowing you to specify an npm module to include and optionally, which version:

![The “Add Module” dialog box.](https://images.ctfassets.net/23aumh6u8s0i/2EbQuMtGl1ELWQiPrZxZ2d/d592ca4a09e572aa19a48d9f63c396f3/add_module.png)

I added the latest version of the `gmail-send` module to the Action.


## Conclusion

As I mentioned in the beginning, Actions don’t need to be lengthy or complicated to achieve useful results. Sometimes a single line is all you need!

You should use the Actions provided above as a “jumping-off point” for writing your own custom Actions to meet your users’ needs. Use your imagination, and don’t be afraid to experiment!


Quick Tips and Tricks for Auth0 Actions

How to use Auth0 Actions to let users access your application or website for a trial period.

Managing Trial Periods with Auth0 Actions

How to deal with logins that must meet specific criteria based on the user’s country? Let's see how you can do this.

If your application needs conditional access based on the user’s country, you can easily achieve it with a simple Auth0 Action. Let’s see how you can do it.

## Why a Country-based Login?

Controlling user access based on the country where they're located when they log in to your application may have different reasons. To mention just a few of them:

- *Legal reasons*. Laws are different around the world. This leads to adapting access to services or content offered by your application so that it does not break the laws of a particular country. For example, think of online gambling: it is illegal in some countries. Also, think of the liability requirements of [GDPR](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) for Europe: you must comply with them in order to offer your services to European citizens.
- *Business reasons*. A company may decide not to offer their services or product to a country for business reasons: maybe because the cost of delivering that product or service in a given country is not affordable, or because the pricing strategy may depend on the country. You can even consider copyright licenses: think of the availability of video on-demand services due to copyright restrictions, for example.
- *Security reasons*. You may consider accesses coming from a given country dangerous because most traffic is statistically malicious.

Depending on the reason you want to control user access and on the services or content offered by your application, you can apply different restriction levels. You can range from blocking access to your application ([geo-blocking](https://en.wikipedia.org/wiki/Geo-blocking)) to adapting your services or content to that country's audience.

> Be aware that the most common technique to geolocate a user is based on their IP address. However, blocking users based on their IP address can be easily circumvented through VPNs or anonymizer services.

## Using Auth0 Actions

This article will focus on how you can use [Auth0 Actions](https://auth0.com/actions) to detect the user's country and how to block them or require a second authentication factor. Auth0 Actions are JavaScript functions running in a Node.js environment executed when specific events happen in a few internal Auth0 Flows, such as the Login Flow, the Change Password Flow, the User Registration Flow, etc.

Each Flow is made up of one or more triggers. For example, the Login Flow runs when a user logs in. This Flow has a post-login trigger: an event fired after the user logs in. You can handle this event through one or more Actions. You can think of Actions as event handlers that run when a specific event fires in an Auth0 Flow.

The following is a graphical representation of an Action (*AddRoles*) that will be executed in the Login Flow after the user logs in:

![Auth0 Action in the Login Flow](https://images.ctfassets.net/23aumh6u8s0i/1pJn7J2p7cICewJkSv4Ecj/4030cd2fa04c3df43e8c29b3c537b68c/auth0-action-in-login-flow.png)

In the following, you will use the post-login trigger of the Login Flow to detect the user's country and apply your control strategy.

To learn more, you can check out this blog post for [a quick introduction to Auth0 Actions](https://auth0.com/blog/introducing-auth0-actions/).

## Blocking Logins from a Country

Let's assume you want to block users coming from a given country. As I said, you need to create an Auth0 Action to handle the post-login trigger. So, head to your [Auth0 dashboard](https://manage.auth0.com/). If you don't have an Auth0 account yet, you can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free one</a>.

Select *Actions* on the left side menu and then [*Flows*](https://manage.auth0.com/#/actions/flows). You should land on the following page:

![Auth0 Flows in the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/4rUFsGdm1cYpgP6jS8xF98/ed055e37e3cb144cc7f5d540095b9ab3/auth0-flows-dashboard.png)

Click the *Login* Flow and enter the Flow editor, as shown below:

![Auth0 Flow editor](https://images.ctfassets.net/23aumh6u8s0i/4uIJUK8GRjAkfo5eksSffh/0c62aeb77c6178fba58b1bdc30a21491/auth0-flow-editor.png)

Here, you can add a custom Action by clicking the *Build Custom* menu item in the Add Action section of the Flow editor:

![Add Custom Action menu](https://images.ctfassets.net/23aumh6u8s0i/WD1Alxdh14g8jrzztaD58/9597f8fd5a522f02b5816fdc525b4f60/add-custom-action-menu.png)

This allows you to assign a name to the Action you are going to create and to access the Action editor:

![Auth0 Action editor](https://images.ctfassets.net/23aumh6u8s0i/5uI0EGTobmSMBbTcifj6dL/382a78976db5dd4f250759f6f8c47b53/auth0-action-editor-block-users-by-country.png)

Replace the code in the editor with the following:

```javascript
exports.onExecutePostLogin = async (event, api) => {
  if (event.request.geoip.countryCode === "AQ") {
    const countryName = event.request.geoip.countryName;
    
    api.access.deny(`Users from ${countryName} are not allowed!`);
  };
};
```

This code defines the `onExecutePostLogin()` method, which handles the post-login trigger. It receives two parameters: `event` and `api`.

The `event` parameter provides some information about the current running environment. For example, it allows you to access the current user's data, the current request, the tenant, etc. For more details about [the Pre User Registration `event` object, check out the documentation](https://auth0.com/docs/actions/triggers/pre-user-registration/event-object).

The `api` parameter provides methods for changing the behavior of the Flow. For example, it allows you to deny access to your application or set specific metadata for the user or the application. For more details about [the Pre User Registration `api` object, check out the documentation](https://auth0.com/docs/actions/triggers/pre-user-registration/api-object).

In your Action, you used the `event.request.geoip` object to get geolocation information about the user logging in. In particular, you checked the `countryCode` property, which can have one of the [ISO country codes](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes) as a value. In the example, you want to block users coming from Antarctica, whose country code is `AQ`. The `geoip` object also provides you with other information about the user's country. For example, you used the `countryName` property to get the full name of the country. Check out [the post-login `event` object documentation](https://auth0.com/docs/customize/actions/triggers/post-login/event-object) for more details.

If the user's country is Antarctica, access is denied through the `api.access.deny()` method. The string passed to the `deny()` method briefly explains the reason for the denied access.

Click the *Save Draft* button to store the Action you just created.

To test this Action, you should... move to Antarctica and try to log in to your application from there. This approach is a bit expensive and ineffective 🙂. Alternatively, you can test the Action by using the *Test* button on the upper-left corner of the Action editor. It opens a sliding window whose content is the `event` object that will be passed to the Action:

![Testing Auth0 Action](https://images.ctfassets.net/23aumh6u8s0i/1VA1JtGrCB9hzt5fasJC0p/0b758ea2dea47ebb8e3ee10e7d5b08ca/testing-auth0-action.png)

You can modify the `geoip` object's properties to simulate a request coming from Antarctica and click the *Run* button. At this point, you will get a window showing a result similar to the following:

![geoip test result](https://images.ctfassets.net/23aumh6u8s0i/dqH3FqfMGOJUGh2Jeg84x/e442c573c846355a336edfd734eb3084/geoip-test-result.png)

## Requesting MFA from a Country

In addition to or instead of blocking users, you may want to enforce [Multi-Factor Authentication (MFA)](https://auth0.com/docs/secure/multi-factor-authentication) for users logging in from specific regions. First, you must have [configured MFA in your Auth0 dashboard](https://auth0.com/docs/secure/multi-factor-authentication/enable-mfa). This lets you define what additional factor you want to use. The next step is to force MFA when a user logs in from specific regions.

For example, assume you want to enforce MFA for North American users. You can create an Action with the following code:

```javascript
exports.onExecutePostLogin = async (event, api) => {
  if (event.request.geoip.continentCode === "NA") {
    api.multifactor.enable("any");
  };
};
```

In this case, you used the `continentCode` property of the `geoip` object. If a user logs in to your application from one of the North American countries, you force MFA by invoking the `api.multifactor.enable()` method. The `"any"` string passed to the method tells Auth0 to use any of the configured factors. Alternatively, you can pass a string identifying a specific provider. Check out [the documentation to learn the  available values for MFA providers](https://auth0.com/docs/customize/actions/triggers/post-login/api-object).

> To make your Action available to the Login Flow in your production environment, you have to click the *Deploy* button and drag the newly created Action into the Flow editor, as explained in [the introduction to Auth0 Actions](https://auth0.com/blog/introducing-auth0-actions/#Creating-Your-First-Auth0-Action).

## Recap

In conclusion, throughout this article, you learned the main reasons you may want to control user access to your application on a country-based criterion and how you can implement it with Auth0 Actions. You learned the geolocation features of the `event.request.geoip` object and how to leverage them to block users or enable MFA when they come from specific countries.

However, remember that while the geolocation approach is pretty straightforward, it is not infallible.


Country-Based Access with Auth0 Actions

Use Auth0 Actions with webhooks to send a Slack message after a new user signs up.

Having a new person sign up for your website is an exciting experience. You feel a rush of energy every time someone chooses your service, enters their email and password into a "Log in" form, and clicks "Sign Up." Get that jolt of excitement in real-time by creating an Auth0 Action to send a message to Slack when a new user registers an account.

## What You Need

* Auth0 Account. If you do not have one, you can sign up for a <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">free Auth0 account</a>.

* Application in our Auth0 tenant. Any web-based, mobile, or desktop application will work. If you don't have any applications that use Auth0, you can download one from the [Auth0 Quickstarts](https://auth0.com/docs/quickstarts/) page.

* Slack account. If you belong to a Slack workspace, you already have one. If you don't have a Slack account, don't worry — you can create one after creating a Slack workspace.

* Slack workspace. You need access to a Slack workspace where the admins will approve your app, or one where you're an admin. If neither of these apply to you, follow the steps in the next section, where you'll set up a Slack workspace under your administrative control.


## Create a Slack Workspace

To approve apps in Slack, you need admin permissions. If you don't have a Slack workspace that you are the admin of, you can create your own free Slack workspace that will give you admin privileges. Go to the Slack [Get Started page](https://slack.com/get-started#/createnew). 

Enter your email address and click **Continue**, or continue with Apple or Google. Check your email for a confirmation code. Enter your code, then click **Create a Workspace**. Go through the following pages to name the workspace and a channel. You can skip inviting people for this example. Congrats! Now you have a workspace, and you can create a Slack webhook.

## Create a Slack Webhook

To post messages into Slack from outside sources, you need a webhook URL. [Webhooks](https://en.wikipedia.org/wiki/Webhook) enable apps to "talk" to each other when something new happens. In this post, you'll take the email address the user entered into the Auth0 login box and send it to Slack as a message.

First, you'll need an app in your Slack workspace to send the webhook information to your Slack channel. Go to [api.slack.com](https://api.slack.com) and click **Create an app**.

![Slack API homepage](https://images.ctfassets.net/23aumh6u8s0i/1r6NCn0k67X5fm6n418hPm/2bccddd6addc4eab2a8d312ad130adca/api.slack.com.png)

This will bring up the _Create an App_ modal. Click **From scratch**. 

The next modal you'll see is _Name app & choose workspace_. Fill in an app name; you can use "slack-test" if you can't come up with something better. You can always change the name later when you think of something else. 

Then select the workspace that you want to connect the app to. Make sure this is the correct app because you can't change the app's workspace later. After you pick a workspace, click **Create App**.

![Slack Name app & create workspace modal](https://images.ctfassets.net/23aumh6u8s0i/2gEJlNDHCE4pAVsnVK5pQ5/3820f59a4a5517fc32bfaff0dae304e6/name_app_workspace_page.png)

You'll be taken to the Basic Information page. This page is where you turn on the ability to use webhooks and get your webhook URL. On the left side of the page, Click **Incoming Webhooks**. Click the toggle button on, and Slack will create a bot user if you don't already have one.

![Slack Activate Incoming Webhooks page](https://images.ctfassets.net/23aumh6u8s0i/7GDOR9bo5twAIA9dyfSzx6/4d594a84e30394351cf05e8a0fb35611/turn_on_webhooks.png)

The page will refresh, and a shiny new section, _Webhook URLs for Your Workspace,_ will appear. To activate the webhook and create the URL used in your Auth0 Action, scroll to the bottom of the page and click **Add New Webhook to Workspace**. This button makes a shortcut to install Slack apps, and using it means you don't have to write any code to generate a webhook URL.

![Slack Add New Webhook to Workspace section](https://images.ctfassets.net/23aumh6u8s0i/234YTEWqT0T66SvEvnXb3p/8f64036f18b0a291e21a84eef10679ce/add_webhook_to_workspace.png)

This next screen lets you know that your app wants to access the workspace. It will ask you what channel you want the app to post and give you a drop-down to choose what channel in your workspace you want the app to post in. Once you have selected the channel, click **Allow**.

![Slack app permissions page](https://images.ctfassets.net/23aumh6u8s0i/1Xv1RqErttgUYQyCDEQzVn/babd1c8c1e20a3ad2dfdb8a3edf8131f/permissions_page.png)

You're taken back to the _Incoming Webhooks_ page. You'll now see the webhook URL has been filled in with a value, with the channel you selected for it and the date it was added. Copy and save the webhook URL somewhere safe; you'll need that later when you create a new Auth0 Action.

![Slack webhooks URL section](https://images.ctfassets.net/23aumh6u8s0i/4VU8xMikQhXe20WvoNgMg6/0a5e8a29057ca51f305c45ef7af23a4b/webhooks_url.png)

> Your webhook URL contains a secret. Don't share it online, including public Git repositories.

Now that you have your webhook URL created for Slack, you need to head to [Auth0.com](https://auth0.com/), sign in, and create an Auth0 Action that will send Slack messages.

## Create Post User Registration Action

Auth0 Actions allow you to customize events like login and registration to add behaviors that go beyond the default Auth0 features. Actions have an in-browser code editor where you can write Node.js code that is stored and runs on infrastructure owned and maintained by Auth0.

Create your Action by clicking **Actions > Library** on the left side of the Auth0 Dashboard.

![Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/1z3vTIqDIBzrT29Q3xI6IW/f7918c0dbcbac8bfc0583ad4f56b76c1/action_library.png)

This page lists the Actions that have already been installed, and there's a **Custom** tab for actions you created. On the upper right side, click **Build Custom**. You'll see the _Create Action_ modal, which asks to name your Action, assign when you want it to run, and which Node.js version you wish to use.

First, give your Action a name like "Slack Message." Next, select the event that will cause the Action to run from the **Trigger** drop-down. For this example, select **Post User Registration**. Leave the **Runtime** selection set to the recommended version (Node 16 at the time of writing). Finally, with all those details filled in, click **Create**.

![Auth0 Create Action Modal](https://images.ctfassets.net/23aumh6u8s0i/5Y0Jsw8yiTyxk8oFDd2rxX/bf1ffda407d666b3e9b6c2552df4ff3f/create_action_modal.png)

You'll now see the in-browser code editor where you write the code that will run when your Action is triggered. Take a look around the code editor first. You'll see a "play button" icon for testing your Action before deploying it on the left. Under that, you'll see a key icon to enter secrets (such as webhook URLs). The box icon is where you click to add modules from NPM.

Above the code editor and to the right, there are three buttons. **Version history** lets you see and revert back to previous versions of the Action. Next is **Save Draft**; if you're not ready to finalize everything in your Action, you can save it as a draft to work on later. Lastly, there's **Deploy**, which you use when you've tested your Action and it's ready for prime time!

The code editor is pre-populated with the appropriate code for the kind of Action you're writing. In this case, it contains the `onExecutePostUserRegistration` function. Inside this function, you'll write the code to run after the user registers a new account.

![Actions Code Editor](https://images.ctfassets.net/23aumh6u8s0i/2ch3BgnVO8yVTMQUV5zld9/265f5d7076d825e224736fb8e4add861/actions_code_editor.png)

### Add webhook URL as a Secret

Time to use that webhook URL you've been keeping safe! Click the key icon on the left side of the code editor. This will open the side menu; click the blue **Add Secret** button. This opens up the **Define Secret** modal, which has fields for the name of the secret and the value it will hold. 

Name the secret `SLACK_WEBHOOK_URL` in the key field, then paste your Slack webhook URL into the value field. Now click **Create**.

![Auth0 Actions Define Secrets Modal](https://images.ctfassets.net/23aumh6u8s0i/3a0jfV88wbvNLC0f7WiypP/754705989067ae70d60cc1e5e8c21b37/define_secret_modal.png)

The page will refresh, and you'll see your secret has been added to the _Secrets_ menu.

> When secrets are created, their values are never revealed. Auth0 encrypts and stores all secrets securely.

### Add npm package

With Actions, you can choose from over 1,000,000 public npm packages and add their functionality to your Action. This action will use the 'slack-notify' npm package. It's a Node.js wrapper around the Slack webhook API that makes it easy to send notifications to Slack from external applications.

Click the box icon to bring up the _Modules_ side menu and click the blue **Add Module** button. In this modal, you add the name and version of the npm package. Enter **slack-notify** for the name. The name has to match the package's name as listed in npm, so make sure you check its name to be sure you're providing the correct one. The version is set to the latest by default. Now click **Create**, and all the pieces to write the code that will send a message to Slack will be in place.

![Auth0 Actions add module modal](https://images.ctfassets.net/23aumh6u8s0i/2w6qekeLIQ9Uz0csHjBbsu/83e7cdf29cc6a511afa9de96921fdf0d/add_module_modal.png)

### Write custom logic

The in-dashboard code editor works like your own editor that you know and love. The code that you enter into it is hosted and maintained by Auth0. Whenever you want to make changes to your Action in the future, you can do so without touching your codebase.

First, you'll add the slack-notify npm package at the top of the code editor by typing `const initSlackNotify = require(slack-notify).`

Next, you'll see the `onExecutePostUserRegistration` function. This async JavaScript function will run after a user is registered and saved to the database. Create a `slack` variable and pass the slack-notify module with your secret webhook URL inside this function.

Every Action has an `event` object that has information related to the trigger. You'll use it to get access to the webhook URL you stored as a secret earlier. The code will look like this:

```js
const slack = initSlackNotify(event.secrets.SLACK_WEBHOOK_URL)
```

Then, below the `slack` variable, create a `message` variable that will include the text to be sent to the Slack channel. Set it to a template string with the text "New User" and the user's email address. The `event` object has the newly registered user's email address. You can display it by passing `event.user.email` to the template.

```js
const message = `New User: ${event.user.email}`
```

Lastly, write the code to actually send the message. The slack-notify npm package has 3 different notification methods bundled already: `bug,` `success,` and `alert`.

* `bug` - used for errors.
* `alert` - used for when something important happens.
* `success` -  used for when messages go through with no errors.

You'll use the `success` method in this example. Within the `success` method, pass in an object with a key of `text` (which is one of the built-in custom fields of the slack-notify package) set its value to the `message` variable.

```js
slack.success({
    text: message
  })
};
```

With this code, when a new user successfully signs up, a message with the user's email will be sent to Slack. 

You should make sure it works as intended before deploying it. You can do this inside the Auth0 dashboard without having to leave the site. Click **Save Draft** in the upper right corner before starting the test.

Here is the complete code for the Action:

```js
const initSlackNotify = require('slack-notify')

exports.onExecutePostUserRegistration = async (event) => {
  const slack = initSlackNotify(event.secrets.SLACK_WEBHOOK_URL);
  const message = `New User: ${event.user.email}`

  slack.success({
    text: message
  })
};
```

## Test the Action, Then Deploy It

With Actions, you can run tests right in the browser without making any changes in your app or "live-testing" with users. Click the "play button" icon on the left side of the code editor. With this section open, you can see the contents of the event object in case you want to use some of the other information. At the bottom of the page, click the **Run** button at the bottom of the screen. The "Test Results" screen slides up, and the _Commands_ and _Error_ fields should be empty.

![Auth0 Actions Test Results](https://images.ctfassets.net/23aumh6u8s0i/WvnMTcD6Vy7g1dA3ppecN/5a0e10a1dcfee7b03b24b83c9bbd796a/actions_test_results.png)

Go to the Slack workspace you created earlier, and see the new message with the sample email address provided by the test event object.

![Slack test message](https://images.ctfassets.net/23aumh6u8s0i/4FjY3CKPEtfhejwhf2fWqP/d124c092d3a71d7b6a444e0cf75d43fe/slack-test-message.png)

With everything in working order, click **Deploy**. This will record the Action and give it a version number. This way, you can continue to make changes to the Action without affecting the deployed version. 

Now that the Action is deployed, it's time to add it to your Auth0 tenant so you'll get notified when a new user signs up for your site!

## Add the Action to the Post User Registration Flow

The last thing to do is attach your new Action to a flow. Flows are different points in the Auth0 lifecycle, from logging in to saving a new user to the database. When you add an Action to one or more of these points, the Actions will trigger in the order in which they are listed.

You'll use the _Post User Registration_ flow in this tutorial. On the left side of the screen, click **Actions > Flows**. This will display all the currently available flows. Select **Post User Registration**, which executes after a user is added to the tenant’s user database.

![Auth0 Actions Choose Flow page](https://images.ctfassets.net/23aumh6u8s0i/6yrPstgkYrypbQvBm3rl36/1e4994a13aea747e09854d79ea5aab99/choose_flow.png)

The following pages show the Actions drag and drop flow visualizer. Here you can add one or more Actions that will run in order after the selected trigger. The Actions are on the right; this section has a tab for installed Actions from the Auth0 marketplace and a custom tab for Actions you created. Click **Custom**, then drag and drop your Slack action between the _Start_ and _Complete_ points.

![Auth0 Actions Flow visualizer](https://images.ctfassets.net/23aumh6u8s0i/3FULQXi17MPJEnpIcAFo7B/50c27ca253d113dc8dac29a215b04ae1/actions_flow.png)

Once that is done, click **Apply**. Now the Action is ready for prime time and real users! 

Sign up a new user on any of the sites in your Auth0 tenant, and you should see that user’s email address appears in Slack.

> You could also use the _Try your Login_ box option in the Auth0 dashboard's _Getting Started_ page.

## Conclusion

Actions offer you new opportunities to build authentication experiences that are truly unique to you and your application. The access to npm packages lets you add custom code and reduce maintenance for you. Testing your code in the browser without running a local build saves you time. The drag-and-drop editor lets you add a new feature without touching your own codebase, because the Actions code is hosted by Auth0!

Now that you know to create a custom Action, check out the [_Actions Triggers_ page](https://auth0.com/docs/customize/actions/triggers) in the Auth0 docs to see what other kinds of Actions you could develop.

Send Slack Message After New User Sign Up with Auth0 Actions

jess-author

Jessica Temporal is a Senior Developer Advocate at Auth0 and co-founder of the first Brazilian data science podcast called <a target='_blank' href='https://pizzadedados.com'><strong>Pizza de Dados</strong></a>. She’s the author of <a target='_blank' href='https://www.amazon.com/dp/B0CDNX6NS7/ref=sr_1_1?&_encoding=UTF8&tag=jesstempora0e-20&linkCode=ur2&linkId=efc4229f6b816609dfce4f185781d99a&camp=1789&creative=9325' ><strong>The Big Git Microbook</strong></a>, creator of <a target='_blank' href='https://gitfichas.com/en'><strong>GitFichas.com</strong></a>, and a part of <a target='_blank' href='https://www.linkedin.com/learning/instructors/jessica-temporal'><strong>LinkedIn Learning</strong></a> instructors team. Jessica helped develop the AI that identifies possible unlawful expenses from Brazilian politicians. She is part of the PyLadies initiative that works to improve diversity and inclusion in technology. In her free time, she likes to knit, play video games, use her 3D printer, and is learning to create 3D models.

Sr. Developer Advocate

Jessica Temporal

Learn how to create a new custom action that will add a custom claim to your Auth0-issued ID Token

Did you know that you can use Actions to customize the user ID token? Well, if you need to add custom claims to your users' ID tokens, you came to the right place! With this tutorial, you'll learn how to use the power of Actions to include custom claims to users' ID tokens.

If you prefer, you can also watch the videos below with me explaining to add custom claims to your users' ID tokens using Actions 👇!

<AmpContent>
<amp-youtube
    data-videoid="DpGRU9mttDw"
    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/DpGRU9mttDw' frameborder='0' allowfullscreen></iframe></div>

</NonAmpContent>

## Auth0 Issued ID Tokens and Custom Claims

[ID Tokens](https://auth0.com/docs/secure/tokens/id-tokens) are commonly used in token-based authentication to pass user information to a client application. At Auth0, ID Tokens follow the [JSON Web Token (JWT)](https://auth0.com/docs/secure/tokens/json-web-tokens) standard; this means that all ID tokens Auth0 issues are JWTs.

Claims are pieces of information about a given subject. In the case of ID Tokens, claims will contain information about the user, such as the user's name. Using custom claims can give your ID token extra information that can improve your application, for example, storing a user ID from a third party or system.

In this example, you'll see how to use Actions to make a request to an external API and store back the obtained information as a custom claim to ID token payload to be used on the sample application.

## The Sample Application

Before you begin, you will need a sample code to customize.

>  For this blog post, you will use the React single-page application (SPA) sample. Keep in mind that <u>you can use what you'll learn here and apply it to your app no matter what language or framework it uses</u>.

You can clone the sample application from GitHub with the following command:

```bash
git clone https://github.com/auth0-blog/assign-random-dog.git
```

After the cloning finishes, follow the [README.md file](https://github.com/auth0-blog/assign-random-dog/blob/main/README.md) instructions to configure it to use Auth0. You'll need an Auth0 account, and if you don't have it, <a href="https://auth0.com/signup"  data-amp-replace="CLIENT_ID"  data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">you can get one for free here</a>.

After configuring the sample application, you can go into the app root folder and run it with the following command:

```bash
npm start
```

Open your browser and access [https://localhost:3000/](https://localhost:3000/). You should get the following page:

![Sample app home page](https://images.ctfassets.net/23aumh6u8s0i/1KGVVbq1ML8VZkXFhPgAWJ/205d7b2cac63ab7c718aa74d2c1d056a/starter-react-app)

## What Are Auth0 Actions?

If you are new to this neck of the woods, this might be your first time hearing about Actions, don't worry; I got you covered, but if you are familiar with Actions, feel free to jump to the next section.

As mentioned, you will use Actions to add a custom claim to your users' ID tokens, and Actions are the new way to extend Auth0 functionalities. They are JavaScript functions running in a Node.js environment executed when specific events happen in some internal Auth0 flows.

 For example, Actions can be triggered when a user authenticates or changes their password. Today, you'll build an Action that will run after a user logs into your application, and as a result, the ID token will have a new custom claim. You can imagine this process as shown in the image below:

![Post login registration Auth0 Action](https://images.ctfassets.net/23aumh6u8s0i/3bMftYmivpwjXYRrQCS1fo/575d293ccfe8dfdada67eea035f85084/login-flow-with-assign-random-dog-action.png)

The Action code itself is implemented inside the Auth0 Dashboard, with an in-browser editor that allows you to write the code and use a prepared test environment to test your code. Also, you can deploy the code and use the versioning tool, but you will see more of that later.

>  You can check out these blog posts for [a quick introduction to Auth0 Actions](https://auth0.com/blog/introducing-auth0-actions/) and how they [compare with the deprecated Rules and Hooks](https://auth0.com/blog/actions-now-generally-available/).

## Implementing The Assign Random Dog Action

Having fun while learning new things makes everybody's life easier! For your custom claim, you will call an external API to grab a random dog picture to be displayed every time the user navigates to their user profile. Right now, your profile page looks like this:

![image of the profile page for the react sample showing the id token](https://images.ctfassets.net/23aumh6u8s0i/6aJLZd3bQM1upkXkszdidq/bfe3e6c3b4d444c7e6caf93f81261668/profle-page-react-sample-spa-showing-id-token-of-the-user.png)

And you want to make it look like this:

![image of the profile page for the react sample showing the id token and a random dog picture](https://images.ctfassets.net/23aumh6u8s0i/75eMhiO9yzow8C9Z3b2hor/006aceb5662bb41d70f0e0f4e07a98a8/updated-profile-page-to-display-the-dog-picture.png)

The API you will use is the [Dog API](https://dog.ceo/dog-api), which claims to be _"the internet's biggest collection of open source dog pictures."_ This API has a "random" endpoint that gives back JSON containing the URL for a dog picture it chooses randomly from its database. That URL will be the value of your custom claim.

Let's go back to the [Auth0 Dashboard](https://manage.auth0.). Choose _Actions_ on the left-hand side menu, and you should see two options there:

1. **Flows:** the processes that can be extended with Actions. Each Flow is made up of one or more triggers and represents the logical pipeline through which information moves during a single point in the Auth0 journey, for example, the _Login_ Flow;
1. **Library:** contains all your Actions. They can be either ready-to-use [Actions built by third parties and published in the Auth0 Marketplace](https://marketplace.auth0.com/features/actions) or custom Actions, like the one we are building today.

So click on _Flows_ and choose the _Login_ flow. This will take you to the following page, where you can see your current login flow. There you will be able to edit the flow and add your custom action:

![image of the page for the login flow where you can adjust the flow and add Actions](https://images.ctfassets.net/23aumh6u8s0i/1fnnTVUuTmerNDjqA0fF9c/aa26492109ec1521e38c5ce0488454ce/login-flow-action-page.png)

On the right-hand side, you'll see the list of your Actions. The ones that come from the marketplace and the custom ones you implement yourself.

![image of the Actions menu on the flow page](https://images.ctfassets.net/23aumh6u8s0i/6wIs79eD5UC4GQwY49JeGQ/632a1db6c9949144157648f6f26af717/actions-menu-on-login-flow-page.png)

Click on the **+** sign button on the top right-hand corner, and you'll see a menu that will either take you to the marketplace if you select _Browse Actions_ or will allow you to create a new Action if you select _Build Custom_. The latter is the option you'll want. It will then display a _Create Action_ form. Now you can give your Action a name that represents what it does. For example, you could use _"Assign random dog"_ to the action you are creating:

![image of the create new action form filled with the assigned new dog name](https://images.ctfassets.net/23aumh6u8s0i/2s1L6MHln402rQRrd7zsIo/776766567106baaee161667655a26331/create-new-action-assign-random-dog.png)

You can keep the default values for the other two fields. These fields define the flow where the action can work, in this case, the _Login Flow_, and which Node.js runtime will be used to run the Action. Click the _Create button_ in the form, this will create your Action, and you will see the in-browser editor.

![image showing the in-browser editor for Actions](https://images.ctfassets.net/23aumh6u8s0i/1Navuh8xu0m94CKGT9Xgz0/a08f24e24f063e3127ba828c841c850c/assign-random-dog-actions-in-browser-editor.png)

Take a closer look and see the editor already has some code and comments to help you write code for your Action. Let's take a moment to understand what it says.

First of all, since you are editing an Action that will run during login, it can be an event that occurs _post login_ or an event that happens after the user _resumes the login after an external redirect_. For this case, you need a _post-login_ event so you can focus on that part of the code copied below:

```javascript
/**
* Handler that will be called during the execution of a PostLogin flow.
*
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
*/
exports.onExecutePostLogin = async (event, api) => {
};
```

The function `onExecutePostLogin` receives the `event` and the `api` parameters.

The `event` object carries information about the login context, for example, which authorization was granted to the user while logging in. For more details on this, [refer to the post-login `event` object documentation](https://auth0.com/docs/customize/actions/triggers/post-login/event-object).

The `api` object, on the other hand, has methods for changing the behavior of the flow, like denying access to the app if you want more details on this object [refer to the post-login `api` object documentation](https://auth0.com/docs/customize/actions/triggers/post-login/api-object).

For the Action to work, you will also need to install `axios`, an NPM package that will make the request to the _Dog API_ `random` endpoint. A cool feature of Actions is that you can add almost any NPM package as long as it can be installed without relying on native add-ons. So let's do this first and then go back to the code.

Notice that there are three tabs on the left-hand side of the editor:

- The ▶️ icon: where you can run a test suite to see if your action is performing as expected;
- The 🔑 icon: where you can access the secret storage menu; 
- The 📦 icon: where you can install NPM modules.

Since you need to install `axios` on the environment for your Action to work properly, click on the 📦 icon, and you'll see a sidebar inside the editor with the _Add Module_ button. Click the _Add Module_ button, and you'll see a form where you can put the name of the module you want to add, like this:

![image showing the add module form](https://images.ctfassets.net/23aumh6u8s0i/6Y06KN0mPllDHs7fZ2vMAJ/b4e1bb4112650ed2866a4fdffb445fdd/adding-axios-package-on-actions-modules-page.png)

Now `axios` is available for you to use on your action. If you click the 📦 icon, the modules sidebar will be hidden, and you can go back to full editor space. Now substitute the code in the editor with the following code:

```javascript
exports.onExecutePostLogin = async (event, api) => {
  const axios = require("axios");

  const randomDog = await axios.get("https://dog.ceo/api/breeds/image/random");

  if (event.authorization) {
    api.idToken.setCustomClaim("https://dogfy.com/random_dog", randomDog.data.message);
  }
};
```

Inside the function, the logic is as follows:

1. First, you import the `axios` package into the variable `axios` so you can use it;
1. Second, you make a `GET` request to the `random` endpoint of the Dog API and restore the resulting response in the `randomDog` variable;
1. Finally, if the event is an _authorization_ flow, you use the `api.idToken.setCustomClaim` to create your custom claim.

The third and last step uses the `setCustomClaim` method to create the custom claim and give it the value returned from the Dog API. There are two important things to notice here:

1. The first one is that your custom claim name should always try to avoid clashes with standard claims, one way to achieve this is by using the URI format to name that claim. For example, here, we used `"https://dogfy.com/" + "random_dog"` to set the name of your claim, and the URL doesn't even need to be a real-life URL. [You can read more about naming custom claims here](https://auth0.com/docs/secure/tokens/json-web-tokens/create-namespaced-custom-claims).
2. The second thing to notice is that to access the URL for the dog picture, you use `randomDog.data.message` because the JSON containing the URL is located inside `data` on the response structure.

Now that you've got your code, you can go ahead and click the *Deploy* button on the top left corner, which will save the Action and make it available for use. After deploying your Action, you need to go back to the flow to add it. On the right-hand main menu, choose _Actions_, then _Flows_, and pick the _Login_ flow; now, if you look at your _Add action_ section, and if you click on the _Custom_ tab, you should see your Action in there:

![image of the Add action section showing the action under the Custom tab](https://images.ctfassets.net/23aumh6u8s0i/2niMVNWCOOGLBXX41aBHqf/888096695e7902859ddde3c27af044fe/custom-action-being-displayed-on-add-action-section.png)

With that said, it is time to drag your Action, drop it on the Flow, and don't forget to click _Apply_ to make your Action part of your _Login_ flow.

![gif showing the drag and drop of the action into the flow and its deployment](https://images.ctfassets.net/23aumh6u8s0i/3uf5YKYg6kbcnbNgeTPetO/553b988408dc4063a4484f787eaf44b5/drag-and-drop-new-action-into-the-login-flow.gif)

You can test to see if the change worked by logging out of your application then logging back in once more. You should see on the _Profile_ page that the ID token content was updated and the new custom claim is there:


![image of the profile page for the react sample showing the id token the new custom claim](https://images.ctfassets.net/23aumh6u8s0i/1lDrIOzfo8Mp2nWv9W0I19/34299cfc6cfafe925e2953c94cb789ce/updated-profile-page-react-spa-with-custom-claim.png)

## Updating Your Application to Use the Custom Claim

Now that we have the URL for the dog picture is time to update the profile page to display it. Let's see how to do that.

> Since the sample application is built with React, the steps described in this subsection are strictly related to this library. <u>This step aims to update the profile page to display a cute dog picture</u>, so feel free to adapt this step to your needs.

On the project source code, navigate to the file `Profile.js` inside `src/views` directory. Then add the code highlighted below:

```javascript
import React from "react";
import { Container, Row, Col } from "reactstrap";

import Highlight from "../components/Highlight";
import Loading from "../components/Loading";
import { useAuth0, withAuthenticationRequired } from "@auth0/auth0-react";

export const ProfileComponent = () => {
  // ...existing code...

      <Row>
        <Highlight>{JSON.stringify(user, null, 2)}</Highlight>
      </Row>

    // 👇 new code
    {user["https://dogfy.com/random_dog"] &&  <div style={{textAlign: 'center'}}>
    <h2>Our Doggy!</h2 >
    <img
        src={user["https://dogfy.com/random_dog"]}
        alt="Random dog"
        className="img-fluid profile-picture mb-3 mb-md-0"
      />
    </div>}
    // 👆 new code

    </Container>
  );
};

// ...existing code...
```

This code will add a picture from the ID token to the profile page whenever there is a `"https://dogfy.com/random_dog"` claim. Your page should automatically reload itself and display the current dog picture:

![image showing the new profile page displaying the dog picture](https://images.ctfassets.net/23aumh6u8s0i/75eMhiO9yzow8C9Z3b2hor/006aceb5662bb41d70f0e0f4e07a98a8/updated-profile-page-to-display-the-dog-picture.png)

With that done, your application is ready. 🎉 Congratulations! 

You can check out [the complete code changes, access this link](https://github.com/auth0-blog/assign-random-dog/tree/profile-page-updated) or switch to the branch `profile-page-updated` on your sample app.


## Recap

You just implemented a brand new Action to be used during the Login flow 🎉. Let's recap what you've learned:

1. You set up a SPA using Auth0;
1. You learned what Actions are and how you can use them to expand Auth0's functionalities;
1. You implemented an Action that makes a call to an external API, and that creates a custom claim with data from the response;
1. Finally, you deployed that custom action and updated your app to use the custom claim.

Keep in mind that this was a colorful way to show how you can use Actions to make a call to an external resource and add a custom claim on the user's ID token. Now you can let your imagination fly and use the knowledge you acquired today to add useful information to your user's ID tokens.

Are you ready to add more custom claims to your user's ID tokens? Let me know in the comments 😉.

Adding Custom Claims to ID Tokens with Auth0 Actions

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

Learn how to use Auth0 Actions to redirect users to an announcement web page and back to the application (or just redirect them to Rick Astley’s video).

Use Actions to Show Users an Announcement after Logging in (Or Rickroll Them)

Learn how to customize the user registration experience with Auth0 Actions.

Did you know that you can customize some of the features Auth0 provides? You can do it with Actions. Are you looking for an example? Let me show you how to customize the user experience when they register with an application.

## Auth0 and User Registration

Using Auth0 to secure your application offers a lot of simplification right from the user's initial visual impression: the login page. The [Auth0 Universal Login](https://auth0.com/docs/login/universal-login) page not only relieves you of the burden of authenticating users but also of the task of managing their self-registration. In fact, in the default configuration, if the user doesn't have an account to access your application, they have the opportunity to register themselves through the *Sign up* link highlighted in the following picture:

![Auth0 Universal Login page with user registration](https://images.ctfassets.net/23aumh6u8s0i/6VizfIqgyfJkvIBtrOqrYt/f17bdf6d9f3d8f19f0d33cb1f880c9d4/auth0-universal-login-page.png)

Following that link, the user can provide an email address and a password to start the registration and authentication process in no time.

All this happens without any intervention on your side. It's all-inclusive!

## Customize the User Registration Experience

That's pretty fine, but maybe you are wondering how to customize the user registration experience, for example, by sending a custom welcome email message. Say you want to thank the user for registering and make them aware of the terms and conditions for using the application. This is what you are going to learn right in this article!

You will learn that you can extend Auth0 standard flows and customize them for your needs. In particular, you will use [Auth0 Actions](https://auth0.com/docs/actions) to send your welcome email message after the user signs up for your application.

Let's start!

## The Sample Application

For this purpose, you will use a sample application that will let you experience the proposed solution firsthand.

> The sample application you are going to use in this article is built with C# and requires [.NET](https://dotnet.microsoft.com/en-us/download) installed on your machine. However, <u>the user registration customization you are going to implement is independent of your application's specific programming language and framework.</u>

To get that sample application, clone it from GitHub with the following command:

```bash
git clone https://github.com/auth0-blog/acme-aspnet-mvc.git
```

After you download the application, follow the instructions in the [README file](https://github.com/auth0-blog/acme-aspnet-mvc/blob/main/README.md) to configure it in order to use Auth0. Of course, 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>.

> If you want to learn more about how the sample application was built, you can check out [this blog post](https://auth0.com/blog/add-authentication-aspnet-core-mvc).

After configuring the sample application, you can run it with the following command:

```bash
dotnet run
```

Pointing your browser to the [https://localhost:7095/](https://localhost:7095/) address, you should get the following page:

![Sample app home page](https://images.ctfassets.net/23aumh6u8s0i/5yO9ER9JsSrsFGXj5e1w6e/3c4f71b3286b43249d0e89a3e7e44c70/acme-homepage-login.png)

## What Are Auth0 Actions?

As said, you are going to use Auth0 Actions to customize the user registration process.

Auth0 Actions are JavaScript functions running in a Node.js environment executed when specific events happen in some internal Auth0 flows.

For example, you can run one or more Auth0 Actions when a user authenticates or change their password. You can run them before or after the user registers or when you send an SMS to your provider for multi-factor authentication. You can see Actions as event handlers that run when a specific Auth0 event fires. For example, in our specific case, you want to handle the event that fires right after the user registers with Auth0. When this event happens, you want to run your code to send a customized welcome email message. You can imagine this event handling as shown by the following picture:

![Post user registration Auth0 Action](https://images.ctfassets.net/23aumh6u8s0i/5RPXK0K8xtuQTljcOSYYFH/5e6705b448cfc558a31533aee1d819ce/post-registration-auth0-action.png)

To implement this behavior, you are going to use the Auth0 Dashboard, which provides you with an editor, a test environment, an integrated deployment environment, and a versioning tool.

You can check out these blog posts for [a quick introduction to Auth0 Actions](https://auth0.com/blog/introducing-auth0-actions/) and how they [compare with the deprecated Rules and Hooks](https://auth0.com/blog/actions-now-generally-available/).

## Implement the Email Sender Action

Let's start implementing our customization. Go to your [Auth0 Dashboard](https://manage.auth0.com/) and select [Library under the Actions item](https://manage.auth0.com/#/actions/library) from the left side menu. You will access a page where all your Actions are located. If you have never created any Actions, the page will appear as in this picture:

![Auth0 Actions Library page](https://images.ctfassets.net/23aumh6u8s0i/3BA4BOqfV2JXCZbcmhMBrA/08201459e1b678f8fef5501e8663ba8e/auth0-actions-library-page.png)

You can create your own Action or install a [third-party Action from the Auth0 Marketplace](https://marketplace.auth0.com/features/actions). In the first case, you will start by clicking the *Build Custom* button, and the resulting Action will be listed in the *Custom* tab. In the second case, you will start by clicking the *+ Add Action* button, selecting one of the ready-to-use available Actions, and the new Action will be listed in the *Installed* tab.

### Create a new Action

For the current project, you will build a custom Action. So, click the *Build Custom* button and fill the pop-up form. You should provide a friendly name for the Action and select the trigger that will run it, i.e., the event you are going to handle with this Action. For our project, you should select the *Post User Registration* trigger, as shown below:

![Create custom Action dialog](https://images.ctfassets.net/23aumh6u8s0i/6TzhULLz688fdjQxJqm8Yb/02a5f3c416c5b4a31c358171308dd0d6/create-custom-action-dialog.png)

Once you click the *Create* button, you enter the Action editor, where you find the following code:

```javascript
exports.onExecutePostUserRegistration = async (event) => {
};
```

This is the JavaScript function that will be executed after the user registers with your application. This function will be exported in the Node.js environment running on the Auth0 side.

As you can see, the function has an `event` parameter, which provides some information about the current running environment. For example, it allows you to access the current user's data, the current request, the tenant, etc. For more details about [the Post User Registration event object, check out the documentation](https://auth0.com/docs/actions/triggers/post-user-registration/event-object).

To go straight to the solution, replace the current code in the Action editor with the following:

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

exports.onExecutePostUserRegistration = async (event) => {
  try {
    axios.post('https://api.sendgrid.com/v3/mail/send',
      {
        personalizations: [{
          to: [{ email: event.user.email }]
        }],
        from: { email: 'no-reply@acme-demo-corporation.com' },
        subject: 'Welcome to ACME Corporation website',
        content: [{
          type: 'text/html',
          value: `Hello ${event.user.name},<br>
          Welcome to our website!<br>
          As an ACME user, you can take advantage of our catalog and services.
          Please, take a look at our <a href="https://acme-demo-corporation.com/terms-and-conditions">terms and conditions</a>.<br>
          <br>          
          Kind regards,<br>
          ACME Corporation<br>`
        }]
      },
      {
        headers: {
          'Authorization': 'Bearer ' + event.secrets.SENDGRID_API_KEY
        }
      }
    );
  } catch (err) {
    console.log(`Error sending email to ${event.user.email}:`, err.message)
  }
};
```

This code uses [Axios](https://axios-http.com/) as the HTTP client that makes requests to the [SendGrid API](https://sendgrid.com/solutions/email-api/) to send your welcome email message.

> The Action implemented in this example uses SendGrid to send emails. Of course, you can adapt the code to use your favorite email provider.

Basically, the Action's code sends an HTTP POST message to SendGrid's `mail/send` endpoint with some data that define the email. To learn more about the specific SendGrid API, check out [the official documentation](https://sendgrid.api-docs.io/v3.0/mail-send/v3-mail-send).

### Configure your Action

Looking at the Action's code, there are a couple of things you should pay attention to:

- You get the user's email and name by accessing `event.user.email` and `event.user.name`, respectively.
- You use the `event.secrets.SENDGRID_API_KEY` property to access the API key required by SendGrid to authorize your requests.

While the user's data are automatically provided by Auth0 through the `event` parameter, you need to manually configure the SendGrid API key as a secret. For this purpose, click the key icon on the left side of the Action editor and then click the *Add Secret* button in the sliding panel that opens. You should get a pop-up window similar to the following:

![Configure Auth0 Action secret](https://images.ctfassets.net/23aumh6u8s0i/7hI5RucTwqPP6XTDBPZEDt/773ed0952c252f848c415e346108c040/configure-auth0-action-secret.png)

Fill the form with `SENDGRID_API_KEY` in the *Key* field and your SendGrid API key in the *Value* field.

To complete the Action configuration, you need to make the Axios library available to the Node.js environment. So, click the cube icon on the left side of the Action editor and then click the *Add Module* button in the sliding panel that opens. This time you should see a pop-up window like the following:

![Add Auth0 Action dependency](https://images.ctfassets.net/23aumh6u8s0i/7clXWV3UNjHqaeNWs36cyq/2966b30f21df9f257db625845c908769/add-auth0-action-dependency.png) 

Fill the form with the `axios` string in the *Name* field. Unless you want to install a specific version of the library, you don't need to specify anything else.

Save your current work by clicking the *Save Draft* button.

### Test your Action

Now your Action is ready to run. However, before putting it into production, it is appropriate to do some tests and make sure that everything works as expected.

Click the triangle icon on the left side of the Action editor. A panel opens with an event instance as shown in the following picture:

![Testing an Auth0 Action](https://images.ctfassets.net/23aumh6u8s0i/7fXpzlolnINotm8DRlaQsz/287e377b8184c048c6353764c3e18a62/test-auth0-action.png)

This event object is the argument that will be passed to your Action when you click the *Run* button at the bottom of the test panel. Before running the test, you have the opportunity to modify that event object. For example, you can detect the `user` object within the event and change its `email` property with your personal email address. This way, by running the test, you can  receive the email sent by the Action and verify that it works.

So, change the user's email address in the event object and click the *Run* button. If everything works as it should, you should see a window at the bottom right, as this picture shows:

![Test results of an Auth0 Action](https://images.ctfassets.net/23aumh6u8s0i/5y06GPj4vRRMYBiaSXM895/1e3bd365d3c177ff0e773754927f744d/test-result-auth0-action.png)

This new window gives you some feedback on test execution. Of course, your test is successful if you receive the expected email in your mailbox.

### Deploy your Action

So far, your Action lives just in your development environment. You can't still use it in production. To make it available to your Auth0 production environment, you need to deploy it. That is easily achievable by clicking the *Deploy* button above the Action editor.

Separating the development and production environments is crucial, especially when you already have a working Action in production and need to apply some changes. You can apply your changes to the Action and test them in the editor without worrying about breaking the production environment. When you are confident with the changes, you can deploy the new version of the Action to update it in production.

Also, the Action editor keeps track of the various versions of your Action. You can see them by clicking the *Version history* button. You will see the list of your current and previous versions as in the following picture:

![Auth0 Action version history](https://images.ctfassets.net/23aumh6u8s0i/5Yi9izjH5jgVP1zW7VPYQY/5d64d0d6a2733be39956412e9dc474f3/auth0-action-version-history.png)

Through this list, you can inspect the Action's previous versions, and, if needed, you can revert the current version with one of them.

### Add your Action to the Post User Registration Flow

Once deployed, your Action will be available in the *Custom* tab of the [Action's Library page of the Auth0 Dashboard](https://manage.auth0.com/#/actions/library). The next step to achieve the goal stated at the beginning of this article is to make the just-created Action run right after the user registers with your app.

For this purpose, select [*Flows* under the *Actions* item](https://manage.auth0.com/#/actions/flows) from the left side menu of the Auth0 Dashboard. You will see a page showing the possible flows you can configure:

![Auth0 flows](https://images.ctfassets.net/23aumh6u8s0i/2kEyKU7ezUFe8xQjAazjCO/7ee44da12d808eaf393bf8aa409a5397/auth0-flows.png)

For your goal, you will choose the *Post User Registration* flow. You will enter the flow editor, which provides you with a visual diagram of the flow, as in the following picture:

![Auth0 flow editor](https://images.ctfassets.net/23aumh6u8s0i/3NTsE7zdq101rOObLXMjZE/3ca40fe50dcb291d13a88dd2a1ae001e/auth0-flow-editor.png)

On the right side of the editor, you have the list of the available Actions. As with the Library page, you have the Actions classified as *Installed* and *Custom*. You will find your *Send Welcome Message* Action in the *Custom* tab. All you need to do at this point is to drag the *Send Welcome Message* box from the right side of the editor and drop it in the middle of the flow diagram, between the *Start* and the *Complete* node. Your final result will look like the following picture:

![Post user registration Auth0 flow with Action](https://images.ctfassets.net/23aumh6u8s0i/58igmA2MYoMejsd9dAN1Mm/fe160aaddb6913b4736cecc2699be266/post-user-registration-auth0-flow-with-action.png)

Keep in mind that, in general, you can add as many Actions as you need to an Auth0 Flow.

## The New User Registration at Work

Now, everything is ready. Move back to [your sample application](https://localhost:7095/), click the *Login* link on the upper right corner of the page, and click the *Sign up* link in the Auth0 Universal Login page:

![Auth0 Universal Login page with user registration](https://images.ctfassets.net/23aumh6u8s0i/6VizfIqgyfJkvIBtrOqrYt/f17bdf6d9f3d8f19f0d33cb1f880c9d4/auth0-universal-login-page.png)

Create a new user by providing an email and a password. After a minute, you should receive the welcome email message you created in the *Send Welcome Message* Action.

That's all! Now you have the basic knowledge to create your own Auth0 Actions to customize the various Auth0 flows.

## Recap

At the end of this article, I'm sure you learned a lot of things. You learned what Actions are and how to create them to customize your user experience with their registration process. Although this article focused on a specific example of Action, you learned features that are valid for Auth0 Actions in general. For example, you learned how to manage dependencies and store secrets for an Action, test it and deploy it into production, check the Action's version history and possibly revert to a previous version, and add an Action to an Auth0 flow.

By using Auth0 Actions, you will be able to customize the default Auth0 behavior to fulfill your specific needs.

Customize User Registration Experience with Auth0 Actions

jameeka_aron

Jameeka has over 20 years of Information Technology and Cyber Security experience. She is a versatile leader, successfully leading teams as both a CISO and CIO across various industries including; Aerospace & Defense, Apparel, Retail, and Manufacturing at both Fortune 100 and privately held companies and many spaces in between. <br>
She is highly skilled in Business Engagement (International and U.S. based) Audit, Compliance, Vulnerability, Risk and Identity Management, Digital Transformation, Mergers, Acquisitions, Divestitures, and leading Cross-Functional and Matrixed teams.

CISO

Jameeka Aaron

CISO Jameeka Green Aaron on Auth0’s actions around this insidious vulnerability

On Thursday, December 9, 2021, a vulnerability in the Java logging library Log4j was disclosed and assigned the CVE ID [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228), also nicknamed Log4Shell. The Cybersecurity and Infrastructure Agency (CISA) also released an [alert](https://www.cisa.gov/uscert/ncas/current-activity/2021/12/10/apache-releases-log4j-version-2150-address-critical-rce) on the 10th of December.

This is an incredibly serious vulnerability that has had security teams in every industry on high alert, working around-the-clock to ensure that their systems are secure. At a high level, Log4J allows Remote Code Execution (RCE) on an affected server, granting an attacker full control. A detailed explanation was published by [LunaSec](https://www.lunasec.io/docs/blog/log4j-zero-day/).

Security is our top priority at Auth0 and we recognize the critical role our platform plays for our customers. Since the vulnerability came to light, Auth0 teams across Engineering, Product, Customer Success, and Security, led by our Detection and Response team have been all hands on deck to evaluate any potential impact on our platform. This is one of the most dangerous vulnerabilities that our industry has seen and we have treated it with that level of seriousness. It also has the potential to be very widespread and takes time to methodically review code and systems. We started with our most critical assets and worked outwards, gaining more assurance as we progressed.

As we stated in our tweet last [weekend](https://twitter.com/auth0/status/1470086301902721024), we did not see direct impact then, nor do we now, after continuous assessment and monitoring. We can confirm that there were no signs of exploitation, and the Log4j library is not used in our core service code base. 

Auth0 does use a very small number of third-party components that were vulnerable to Log4Shell. We have been working closely with our partners throughout the incident response process, firstly to apply patches as soon as they are released, and secondly to identify if they could have been used as a potential path to compromise our service. Again, our review has not shown any signs of abuse from the vulnerability.

The speed of response from our teams and our existing security architecture was essential here. Using our existing security tooling, we were able to scan our entire code base and containers for the affected library and quickly get assurance that we were not affected. We also deployed WAF rules on our edge for an extra layer of protection and then focused our efforts on assuring our supply chain. Finally our Red Team has been trying to actively use the vulnerability against the Auth0 platform, further increasing our levels of assurance through offensive testing.

This vulnerability is very serious. We recommend that all of our customers continue to closely review and monitor their own systems and third-party components for the vulnerability and any signs of compromise. And critically make sure you are running the latest versions of any impacted software (please see [Okta’s blog](https://sec.okta.com/articles/2021/12/log4shell) for details of the impact to the Okta products).

Subsequently other vulnerabilities have been reported in Log4j ([CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) and [CVE-2021-45105](https://nvd.nist.gov/vuln/detail/CVE-2021-45105)) and we expect there to be more as the library gets further attention from security researchers. We will continue to closely monitor and investigate the situation, and provide prompt notification if the situation changes.

Auth0’s Response to Log4J

Use Auth0 Actions to enable SMS-based MFA with Plivo.

Logging into a website with your username and password is a straightforward way to log in and access your content. You've been doing it for years, you've created several passwords, and it works. Logging in with **just** a password isn't as secure for your users as it used to be. Hackers can steal passwords from one site and use [credential stuffing](https://auth0.com/blog/what-is-credential-stuffing/) to pose as your user and gain access to other sites. It's common for your users to re-use passwords since they have several to remember across all their applications. You can help keep your users' data secure by offering another layer of protection by enabling Multi-factor Authentication (MFA).

> To learn more, read [this guide about MFA and its different methods on the Auth0 blog](https://auth0.com/blog/multifactor-authentication-mfa/).


You've likely experienced MFA in real life. For example, if you start working for a new company, they may ask for your ID card and a birth certificate. Those are two different *factors* of identification. It helps verify you are who you say you are to make sure your paycheck goes to you and lowers the success rate of someone posing as you.

In this blog post, you'll learn how to implement SMS-based MFA with Auth0 Actions and [Plivo](https://www.plivo.com/).

## Prerequisites

- An Auth0 account
- A Plivo account
- A Plivo phone number

If you do not have a Plivo account or an Auth0 account, you can sign up for a [free Plivo account](https://console.plivo.com/accounts/register/) and a <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">free Auth0 account</a>.

If you already have an application created in your Auth0 account, you can skip to [Create Action for MFA](#Create-Action-for-MFA).


## Set up & Configure a React App Application with Auth0

In the Auth0 dashboard, create a new application by clicking on **Applications > Applications > Create Application**. On the next screen, create a name for your application and select **Single Page Web Applications** since you're using a React app. 


![Auth0 Create Application Page](https://images.ctfassets.net/23aumh6u8s0i/7ffrE0TIKPuvwAmyAHETGV/3704b624e8b568fba9288b1c6236872d/auth0-create-application-page.png)


The next screen will ask you, "What technology are you using for your web app?" Select **React**.


![Auth0 Technology Selection Page](https://images.ctfassets.net/23aumh6u8s0i/3Is0KXk07ueIJadkrrHnbl/804f4ad53e8af5b28916481b92778fdc/auth0-technology-selection-page.png)


To get up and running quickly, you can download a sample [React application integrated with Auth0 on GitHub](https://github.com/auth0-samples/auth0-react-samples/tree/master/Sample-01).
Once it is downloaded, type `cd auth0-react-samples` on your terminal, then run `npm install` to install the dependencies.

## Configure Auth0 Credentials

For the authentication flow to work, the project needs your Auth0 domain and client ID. In your code editor, copy the content of `src/auth_config.json.example` into a new file in the same src folder called `auth_config.json`, and replace the values with your own Auth0 application credentials:

```js
{
  "domain": "{YOUR AUTH0 DOMAIN}",
  "clientId": "{YOUR AUTH0 CLIENT ID}",
}
```
You can get the client ID and domain from the settings tab on your new application page.

![Auth0 Application Settings Page](https://images.ctfassets.net/23aumh6u8s0i/1GFtgZeJursgHKHzNXQFVh/7496cb3bc06a7411096386c3109be8ed/auth0-application-settings.png)

Next, scroll down to the Application URIs section to fill in Allowed Callback URLs, Allowed Logout URL, and Allowed Web Origins. This example is running locally, so enter `http://localhost:3000` into each field. When you're finished, scroll to the bottom of the page and click _Save Changes_.

![Auth0 Dashboard Application URIs section](https://images.ctfassets.net/23aumh6u8s0i/6kXeY9LVo5sincLcxSdrk1/e25a7bfd89bcda641f6c6625ad143aa5/Screen_Shot_2021-12-03_at_8.37.26_AM.png)


## Create Action for MFA

With an application linked to the Auth0 dashboard, you can create an Action that will run globally for all applications in your Auth0 tenant. Actions are functions written in Node.js that you set to run at specific events based on your users' actions. Actions let you write custom code that fits your needs and integrates third-party vendors with Auth0 to work together. This post is going to focus on integrating with Plivo. 

To get started with Actions, you need to add an Action to your library. On the Auth0 dashboard side menu, click **Actions > Library**.

![Auth0 Actions Selection](https://images.ctfassets.net/23aumh6u8s0i/6q9LRH1DvQMiF3mU7t6Wy7/8481bc4376718299a2806a165e49ed56/auth0-action-selection.png)


On the Library Page, click **Add Action**. On the Browse Actions page, search for **Plivo** and click on it. On the next page, click on **Add Integration**.
You'll then be met with a prompt telling you, "Plivo will need access to: Read and share user profile information" if you agree, click **Continue**.

## Access and Add Plivo Credentials

This will bring up a page to enter your Plivo credentials such as Plivo authorization ID, Plivo phone number, and Plivo authorization token. You can find the authorization ID and Token on the Account and Payments section of your Plivo dashboard.

![Plivo Accounts and Payments Page](https://images.ctfassets.net/23aumh6u8s0i/3Dttg4mSQ9R20tnFzsRuVr/01c5fe787a262c6e5793642703785064/plivo-accounts-and-payments.png)

Access your Plivo phone number by clicking on **Phone Numbers** on the left side menu. If you don't have a Plivo phone number, you can rent one [following these instructions on the Plivo Docs](https://www.plivo.com/docs/numbers/guides/buy-a-number/).

> Make sure you add the phone number in the E.164 format(ex. +15554443232)

Then click **Create**, and you'll go to the Library page. You can create an Action Flow from here. You'll learn how to use flows next.

## Create Send Phone Message Flow

You should now see the Plivo Action on the installed tab of the Library page. Click the three dot menu on the right and select **Add to flow**. 

![Actions Library Page](https://images.ctfassets.net/23aumh6u8s0i/5IbEG0QKPAbyIoi9buA2NL/ba6df3e83c1cc498b248eafd48fc5362/auth0-add-to-flow.png)


This will take you directly to the **Send Phone Message** flow. Flows are the steps your application takes when using Auth0 as your identity provider. You'll see the **Start** and **Complete** trigger points in the flow in Action flow visualizer in the middle of the screen. On the ride side of the screen, you'll see the **Add Action** section. This will show a list of installed Actions like the Plivo one we created, and there is also a tab for custom Actions.

![Auth0 Actions Visualizer](https://images.ctfassets.net/23aumh6u8s0i/ITasqHfe5OIyRImhGGxis/0a125823cda2f4ee84c2f19d5f6b97ae/auth0-actions-flow-visualizer.png)

You can drag and drop the Actions to the point in the flow that you want them to trigger. Grab the Plivo Action and drop it in between **Start** and **Complete**, then click **Apply**.

![Auth0 Actions Flow Visulizer](https://images.ctfassets.net/23aumh6u8s0i/YYUxv5wmVMjjcFA6ictqN/0683342bf45d6a9e0661e7cbd0febd7e/auth0-actions-added.png)

Now, when an SMS message is requested, your application will signal Pilvo to send an SMS message. But how do you trigger the message request? You have to turn on SMS-based Multi-factor Authentication.

## Turn on MFA in Auth0 Dashboard

On the left side menu in the Auth0 dashboard, click **Security > Multi-factor Auth**. 

![Auth0 MFA page](https://images.ctfassets.net/23aumh6u8s0i/4UUXYlr7UjlSqt3mxPoyrq/17d0e5470369da629062de484fb59862/auth0-mfa-page.png)


In the **Factors** section, scroll down and click **Phone Message**. Click the toggle on the upper right side of the screen to enable Phone Message. With this turned on, it requests a phone message be sent to your users with a code to verify their login. 

Under **Choose a delivery provider**, select **Custom**, since you created the Plivo "Send Phone Message" hook to handle sending an SMS to users. For **Choose a delivery method**, choose **SMS**. 


![Auth0 Phone Message Screen](https://images.ctfassets.net/23aumh6u8s0i/3lfkktB82h2DkLrnl8OCBy/1fa9fb6ec90eb3519b6cc48546cbaeae/auth0-phone-message-screen.png)


Scroll to the bottom of the page and click **Save** to save these settings.

Return to the **Multi-factor Authentication** page and scroll down to the **Define policies** section. This section tells Auth0 when you want the Phone Message MFA request to trigger. For this example, select **Always** to ensure your users have an extra layer of protection each time they log in. Then click **Save**.

You will then be asked, "Are you sure you want to continue?" This prompt also lets you know that all users will be required to enroll in MFA and that all applications in your Auth0 tenant will now use MFA. Click **Continue**. 

You have everything set up to require your users to receive an SMS message with a verification code from Plivo after logging in. But it's always a good idea to test out new features after you add them.

## Test Your MFA Login Flow

Run your sample application locally by launching the `npm run dev` command in the project's root folder. Then, head your browser to the [http://localhost:3000](http://localhost:3000) address and click **Login** on the home page. On the login page, enter your email and password. Next, you'll be prompted to add a phone number to secure the account. This is what your users will see the next time they log in after you enable MFA.

You can select the code for your country on the first line, then type in your phone number and click **Continue**. You'll revieve an SMS message with a verification code. Enter that code into the input box on your application.

You've successfully added another factor of protection for your users!

## Test MFA flow in Auth0 Dashboard

Another way you can test the MFA flow is by using the Auth0 dashboard. You can test Actions you created without having to run your entire application.

Click **Getting Started** at the top of the left menu on the Auth0 dashboard. You'll go to the **Getting Started** page, where you'll see the option to **Try your Login box**. Clicking **Try it out** will bring you to the login box that your app will use. 

![Auth0 Dashboard Getting Started page](https://images.ctfassets.net/23aumh6u8s0i/6x1ti069gOiQQEfKMxJOkA/1a574fcaa21a63c27af49c46f945ac5d/auth0-try-login-box.png)

Log in as one of the users in your tenant (If you don't have any users, click **Sign up**).

Once logged in, you'll be asked to provide a phone number. Enter the number for your mobile phone. You'll receive an SMS message from your Plivo phone number with a six-digit code. Enter this code into the Auth0 login box and click **Continue**. You'll be greeted with the **It Works** page, confirming that your MFA Action worked!

![Auth0 It Works web page](https://images.ctfassets.net/23aumh6u8s0i/2TPUwfu11Te9Yb27M3920C/34f3bc3c726eeb0b76cc971c7fd1f5c3/auth0-it-works-screen.png)

## Conclusion

Congrats! You just added another layer of protection to keep your users' data safe. First, you included the Plivo integration from Actions Library. You then created a "Send Phone Message" flow using the Plivo integration and the Actions drag and drop interface. After that, you enabled the Action by turning on MFA in the Auth0 dashboard. Finally, you tested everything out using "Try your Login box" in the Auth0 dashboard.


Enable SMS MFA with Plivo and Auth0 Actions

Developers from around the world created awesome new Actions

Auth0 was excited to host our first Actions Hackathon on Oct 28, 2021. Teams from around the globe participated in a day-long event that saw hackers take their best shot at creating their versions of the newest Auth0 extensibility feature - Actions.

## But, What Even Is Actions Anyway?

We are always looking for new tools and solutions that allow you to customize your identity solution. Our first extensibility tool was Auth0 Rules, serverless code blocks that can be customized to extend Auth0's core capabilities. Next up was Auth0 Hooks, similar to Rules but can be executed against several extensibility points.

Auth0 Actions is the next evolution in our extensibility toolset. An Action is a functional service that fires after specific triggers across an identity flow; these could be events such as a post-login or client credential exchange.

## Okay, so Let’s Get down to the Winning Teams and What They Built

The Hack kicked off Thursday morning with six developer teams.

After a roughly four-hour coding session, the teams came back to make their presentations to the judges. And the judges picked the top two winners.

## Facial Recognition and Vaccination Status

Second place was awarded to the **A-Team**, a team consisting of just one person! Augustine Correa from Mumbai utilized two Auth0 Actions: Yoonik, the Face Authentication Action found in the [Auth0 marketplace](https://marketplace.auth0.com/integrations/yoonik-face-authentication), and a custom one built by the team during the Hackathon named “Vaccination Status.” This action was designed to interface with India’s COVID19 vaccination portal and verify the vaccination status of the person logging in.

India is enforcing vaccine mandates for entry to enclosed physical spaces. The A-Team’s Login Flow solution ascertains a registrant’s vaccination status and ensures the integrity of the process with a non-contact biometric authentication.

“For app developers, Auth0 Actions has a comforting familiarity with our current software practices,” reflected Augustin. “While we channel our efforts to code the unique functionality of our app, we incorporate packages for everything else. This assembly of components enables rapid development of high-quality software.”

## Authenticate Your VPN at Login

The winners of the Auth0 Hackathon were **Knights of the Pass**, composed of Inna Shablygin, Kirill Kotyagin, Rostislav Kondratenko, and Igor Vladimirskiy. The Knights of the Pass designed an Auth0 Login flow that streamlines access to corporate resources by recognizing authorization at login for access to VPN.

VPN is a widely-used security tool for remote workers but often creates significant inconvenience for users and systems administrators alike, contributing to productivity and compromised security.

The Knights of the Pass team created an Auth0 application for their test demo and set up a reverse proxy that restricts access to the application from the Internet (e.g., only the login page of the app is exposed). Next, they created an Auth0 action that generates one-time tickets for VPN authentication when the user is being logged in. These tickets are later verified by the RADIUS server. Lastly, their Action displays a webpage in the middle of the login process. The webpage verifies if the user is currently in the corporate network and, if not, starts the VPN client software on the user machine to connect to VPN.

“Companies which utilize Auth0 identity management with WWPass passwordless authentication can use Auth0 Actions to streamline access to corporate resources,” said Inna Shablygin, VP of Operations at WWPass. “Protected by corporate VPN, with extremely transparent and simple user experience, Auth0 Actions is a fantastic tool to glue different pieces of technology together.”

## Want to Know More?

To learn more about [how to use Actions](https://auth0.com/actions) in an Auth0 login flow, check out our [docs](https://auth0.com/docs/actions) section to see how to use Actions in your customer flow.

If you’ve built an Action and think you’re ready to share it as an integration, find out more in the [Auth0 Marketplace](https://marketplace.auth0.com/).

"auth0 actions"