Damian Schenkelman

Damian was one of Auth0's earliest employees. He loves building products for developers and taking things from 0 to 1.
<br><br>
He played key roles in implementing product features and growing the engineering organization in the early stages, and later on defining Auth0's architecture for scale and creating new products. Today he helps shape Auth0's long term strategy and leads Auth0Lab, a small and amazing team doing research and development of forward-looking products.
<br><br>
He spends his spare time with family, and friends, exercising, and catching up on all things NBA.

VP R&D (Auth0Lab)

Auth0 and Google Cloud are partnering to secure AI agent communication with the new Agent2Agent (A2A) protocol, ensuring robust authentication for the next generation of AI interactions.

Production-ready AI agents need to be secure, and auth is a big part of security. Auth0 is partnering with [Google Cloud](https://cloud.google.com/?hl=en) to help deliver secure authentication for the [Agent2Agent (A2A) protocol](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/).

### What is the Agent2Agent protocol?
Agent2Agent (or A2A) is a new open interoperability protocol created by Google Cloud, and launched a month ago,  with support and contributions from 60+ companies.

It aims to allow agents to communicate with other agents regardless of their implementation framework or tech stack. For example, a “client” agent should be able to communicate with server agents implemented with LangGraph, Google ADK, Vercel AI SDK, any other agentic framework or any agent implemented without one.

![](https://images.ctfassets.net/23aumh6u8s0i/6qm1UcMBH6arg4ynuBUBMJ/7c7c8117381a56dcd90117deea2fddbb/img_01.png)

### Why is auth important for AI agents?
As companies and developers deploy AI agents into production, interactions between these agents will be common. And naturally, these interactions need to be secure.

We can say that each AI agent can act as a client (when requesting data from other AI agents) and as a server (when responding to data requests from other AI agents).
![](https://images.ctfassets.net/23aumh6u8s0i/5Ku1FadhT8Jqg8EZ9PaiRG/a52b5ed2985a1e1b76cef7052602ff58/img_02.png)

So we end up with some auth-related questions to be answered. These matters are important when implementing any system, and agentic systems are no exception. But there are also a few questions that become more prevalent with the rise of AI agents:

- **Authentication:** How does the server agent know who is trying to perform an action?
- **Delegation:** Is the agent acting on its behalf, or on behalf of a user?
- **Consent:** If the client is acting on behalf of a user, how does the user consent to this operation?
- **Authorization:** How does the server agent know if the caller can perform the action (e.g. call a specific tool)?  If the client is acting on behalf of a user, is the user authorized to perform this action?
- **Auth for headless agents (agents without a UI):** How should AI agents without a UI authenticate users?
- **Fine-grained authorization:** How do we ensure AI agents only have the permissions they need to perform their task, and not more?

### What are we partnering on?
A2A is being designed to support enterprise-grade authentication and authorization from day one. This means the protocol should be able to provide good answers to those questions and support all of those scenarios in multi-agent systems built with A2A.

We are working with Google Cloud to define A2A auth specs based on secure standards, and build SDKs and code samples that showcase A2A auth capabilities. This will include how to integrate A2A with [Auth0](https://auth0.com/) and our new product [Auth for GenAI](https://auth0.com/ai), providing both great security and great auth user experiences.

### How does auth work in A2A?
Agents expose how they operate via [Agent Cards](https://google.github.io/A2A/topics/key-concepts/#fundamental-communication-elements), which include what they can do, how they can communicate (e.g. support streaming?), and how clients should authenticate to them following the [OpenAPI spec](https://github.com/google/A2A/pull/359). Clients use the Agent Card to discover agents and understand how to interact with them.

For example, this agent card defines an HR agent that can receive an email and reply if a person works at a company or not. Clients can authenticate by obtaining an access token via a [client credentials](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) OAuth flow and then providing the token to the agent to authenticate.

```python
AgentCard(
    name='Staff0 HR Agent',
    description='This agent handles external verification requests about Staff0 employees made by third parties.',
    url=f'http://{host}:{port}/',
    version='1.0.0',
    defaultInputModes=HRAgent.SUPPORTED_CONTENT_TYPES,
    defaultOutputModes=HRAgent.SUPPORTED_CONTENT_TYPES,
    capabilities=AgentCapabilities(streaming=True),
    skills=[
        AgentSkill(
            id='is_active_employee',
            name='Check Employment Status Tool',
            description='Confirm whether a person is an active employee of the company.',
            tags=['employment status'],
            examples=[
                'Does John Doe with email jdoe@staff0.com work at Staff0?'
            ],
        )
    ],
    authentication=AgentAuthentication(schemes=['public']),
    securitySchemes={
        'oauth2_m2m_client': OAuth2SecurityScheme(
            description='',
            flows=OAuthFlows(
                authorizationCode=ClientCredentialsOAuthFlow(
                    tokenUrl=f'https://{os.getenv("HR_AUTH0_DOMAIN")}/oauth/token',
                    scopes={
                        'read:employee_status': 'Allows confirming whether a person is an active employee of the company.',
                    },
                ),
            ),
        ),
    },
    security=[{
        'oauth2_m2m_client': [
            'read:employee_status',
        ],
    }],
)
```

One thing we have also been exploring with the Google Cloud team is how agents that don't have a UI (“headless agents”) should authenticate users. For these scenarios we believe the [Client Initiated Backchannel Authentication (CIBA)](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) flow will be a very valuable tool for developers and architects. CIBA is an OpenID Connect flow that does not rely on redirects in the user's browser. Instead, Agents can reach out to users outside via push notification, email, SMS, etc. for them to authenticate. To give you an idea about what CIBA provides from a security standpoint, it can also be used to meet the strong auth requirements of FAPI for financial transactions.

### A working sample
Enough chat, let's see some working [code](https://github.com/google/A2A/tree/main/samples/python/agents/headless_agent_auth) :) We've worked with the Google Cloud A2A team to build a demo showcasing these capabilities. Imagine a scenario where:
 
1. John Doe, who works at Staff0 wants to open a bank account by talking to a chatbot agent
2. Because of internal policies, the bank agent needs to verify that the user is an employee at Staff0, so it contacts the Staff0 HR agent.
3. The Staff0 HR agent can use the Staff0 HR API to check if the user is an employee or not.

For example, it could result in an application flow like this:
<AmpContent>
<amp-youtube
    data-videoid="X22XNlRnHZU"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<iframe class="vidyard_iframe" title="Auth0 + Google A2A & ADK sample" src="//play.vidyard.com/utu4caQfTCBHbbnXDaWo9a.html?" width="640" height="360" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen referrerpolicy="no-referrer-when-downgrade"></iframe>
</NonAmpContent> 

To make it simple to run such a sample, we uploaded it to the A2A repo here. The sample A2A client plays the part of the Bank Agent. When you run the demo, this is what happens behind the scenes:
![](https://images.ctfassets.net/23aumh6u8s0i/417VrO2pWfdEVy3TkATSS5/090672e74f0c822ae90dad8182c4cebe/img_03.png)

### Closing thoughts
At Auth0 we believe AI has the potential to radically reshape software in general and identity in particular. We believe there will be an explosion in AI agents (non-human identities), which requires more security, finer grained access control and support for various delegation scenarios. 

We look forward to continuing our collaboration with Google Cloud, and helping builders secure their AI agents, both by contributing to AI protocols (e.g. MCP, A2A), new capabilities of [Auth for GenAI](https://auth0.ai), and developing new products and features that enable an AI powered world.


[Duplicate] Secure A2A authentication with Auth0 and Google Cloud

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

Generative AI is everywhere, and since not every user has access to all data, learn how to use retrieval-augmented generation with fine-grained authorization to ensure that private information stays private.

Build Trustworthy AI: Implementing Access Control for RAG Systems Using FGA

Kapil Patil

Sr. Partner Solutions Technical Architect

Discover how combining AWS Lambda Authorizers with Auth0 FGA can strengthen your API security. This approach ensures precise, scalable access management across your applications with minimal overhead.

Streamlining API Security with AWS Lambda Authorizers and Auth0 FGA

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 seamlessly integrate Auth0 into your newsletter sign-up process, ensuring compliance with GDPR regulations. This simple guide walks you through different methods to collect user consent for newsletter signups.

Engaging your users and keeping them informed about the latest features you deploy is crucial for any successful online business. However, it's equally important to ensure your communication efforts comply with users’ right to privacy and regulations like GDPR.

Thankfully, if you're already using Auth0 for user authentication, you have a powerful tool at your disposal to streamline the process of obtaining consent for email communications.

In this article, we'll delve into how you can leverage Auth0's capabilities to seamlessly integrate GDPR-friendly newsletter sign-ups directly into your existing user registration or onboarding flows. We'll cover best practices for obtaining explicit consent using two different approaches. By the end, you'll have a streamlined system that not only grows your email list but also fosters trust and transparency with your users.

## Method 1: Customize Signup and Login Prompts

Auth0's Universal Login feature provides a convenient way to add a newsletter sign-up option directly into your existing login or registration process. You can easily customize the Universal Login sign-up form to include an input checkbox for newsletter subscriptions.

When designing this checkbox, it's crucial to use clear and concise language that leaves no room for ambiguity. The checkbox should be unchecked by default, and the wording should explicitly state that the user is agreeing to receive marketing emails from your company.

Here's an example using Auth0 signup prompts for gathering consent:

![Example of Auth0 signup prompts for gathering consent for marketing purposes](https://images.ctfassets.net/23aumh6u8s0i/4n1CUQRKeGZDfnh4WaPoH/310a9792c14981c94634e94498d98b72/checkbox-consent-example.png)

Once the user submits the form, Auth0 can store their consent status as a custom field in their user profile. This allows you to easily track who has opted in to receive your newsletter and segment your audience accordingly.

The documentation provides great detail on [how to customize signup and login prompts](https://auth0.com/docs/customize/login-pages/universal-login/customize-signup-and-login-prompts), so I won't be covering the steps here, but I'll share some of the code I used to set up the example above.

To add the new field to the signup form, I made the following call to the management api:

```shell
curl -L -X PUT 'https://{auth0-domain}/api/v2/prompts/signup/partials' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer {access-token}' \
-d '{"signup":{"form-content-end":"<div class=\"ulp-field\"><input type=\"checkbox\" name=\"ulp-newsletter-consent\" id=\"newsletter-consent\"><label for=\"newsletter-consent\">I agree to receive information and commercial offers to my e-mail.</label></div>"}}'
```

Which will inject the following HTML after the login form.

```html
<div class="ulp-field">
    <input type="checkbox" name="ulp-newsletter-consent" id="newsletter-consent" />
    <label for="newsletter-consent">I agree to receive information and commercial offers in my e-mail.</label>
</div>
```

Then, I'm using Auth0 Actions to automatically sign up the user to my newsletter service. Here's the code for the action:

```javascript
exports.onExecutePreUserRegistration = async (event, api) => {
  const consent = event.request.body['ulp-newsletter-consent'];

  if(consent) {
    api.user.setUserMetadata("newsletter_consent", consent);
    api.user.setUserMetadata("newsletter_consent_date", Date.now());

    // Call the newsletter service API to subscribe the user
    await fetch(`https://newsletter-api.example.com/u/${event.user.email}`, {
      method: "POST"
    })
  }
};
```

You'll have to adapt the HTTP call to match your newsletter service API, or, what I prefer to do, is to add the email to a processing queue, which then triggers the newsletter subscription.

<include 
    src="LinkCard" 
    title="There's a lot more you can do with prompts" 
    link="https://auth0.com/docs/customize/login-pages/universal-login/customize-signup-and-login-prompts" 
    description="Explore the documentation to find out other use cases and examples for prompts." 
/>

### Key considerations for this approach:

- **Integrated with Sign-Up Form**: This method seamlessly blends the newsletter sign-up with the user's initial interaction.
- **Social Login & Passkeys**: Keep in mind that this approach won't work if your primary login methods are social logins (e.g., Google, Facebook) or passkeys.
- **Custom Domain and Custom Page Template Required**: To leverage this functionality, you'll need to have a custom domain set up for your Auth0 tenant.

## Method 2: Using Auth0 Forms for Dedicated Consent Collection Step

If you need a more comprehensive consent collection solution or want to gather additional information beyond a simple yes/no for the newsletter, [Auth0 Forms](https://auth0.com/docs/customize/forms) is the solution for you. This approach involves presenting users with a dedicated form during the authentication process, allowing for more detailed data collection and tailored consent options.

Auth0 Forms is a powerful visual editor that empowers you to create custom, dynamic forms that integrate seamlessly with your authentication flows. These forms can be, for example, used for:

- **Progressive profiling**: Collect user preferences, demographics, or any other data relevant to your business.
- **Enforce Policies**: Require users to accept updated terms and conditions or privacy policies before accessing your application.
- **Customize Authentication Flows**: Add steps to your login or sign-up processes, such as email or phone number verification, OTP, account linking, or consent collection.
- **Trigger Custom Actions**: Initiate backend processes or workflows based on user input.

### How Can Auth0 Forms Be Used for Consent?

Auth0 Forms provide a flexible framework for obtaining and managing user consent in various scenarios:

- **Newsletter Sign-Ups**:  Create a dedicated form with clear and concise language to request explicit consent for email communications.
- **Terms and Conditions Acceptance**:  Present updated terms or policies to users and require their acceptance before continuing.
- **Data Usage Consent**:  Seek permission for specific data processing activities, such as personalized advertising or data analytics.
- **Granular Permissions**:  Offer users fine-grained control over their data by allowing them to choose which types of communication they want to receive.

Here's an example of a form that collects information about the user and asks for marketing consent the second time the user logs into the application.

![Example of Auth0 Forms to collect user information and marketing consent](https://images.ctfassets.net/23aumh6u8s0i/74OX4QmLN20UuPpyIbglk4/acfcc586f1f472584b3aacea98974da3/auth0-forms-consent.png)

<include 
    src="LinkCard" 
    title="Auth0 Forms is a great resource to further customize your authentication flow." 
    link="https://auth0.com/docs/customize/forms" 
    description="Explore the documentation to find out how to build your own forms or use pre-defined templates for common use cases." 
/>

### Key considerations for this approach:

- **Universal Compatibility**: Auth0 Forms works seamlessly with all authentication methods, including social logins and passkeys, providing flexibility for your user base.
- **Additional Step**: Be aware that this method adds an extra step to the authentication flow, which, only for the purposes of asking consent, can potentially affect user experience. Consider balancing the need for comprehensive consent with the desire for a streamlined login process.
- **Versatile Usage**: Auth0 Forms aren't limited to just newsletter sign-ups. They can be used for a variety of scenarios, such as accepting terms and conditions, requesting permission for specific data usage, or collecting user preferences. This versatility makes Auth0 Forms a valuable tool for managing ongoing compliance and user engagement.

## Best Practices for Obtaining Explicit Consent

To ensure your newsletter sign-up process is fully GDPR-compliant, there are several best practices you should follow. First and foremost, use clear and concise language on your sign-up forms. Avoid legalese or confusing terminology, and be upfront about what the user is signing up for.

Additionally, consider offering granular consent options. Instead of just one checkbox for all types of communication, you could provide separate checkboxes for newsletters, product updates, or other types of emails. This gives users more control over the emails they receive and can improve engagement rates.

Another effective strategy is implementing a double opt-in process. This means that after a user submits their email address, they receive a confirmation email with a link they must click to verify their subscription. This extra step helps ensure that the email address is valid and that the user genuinely wants to receive your newsletter.

Finally, it makes it easy for users to manage their communication preferences. Provide a clear link in your emails where users can update their subscriptions or unsubscribe altogether. This demonstrates respect for their privacy and can help prevent spam complaints.

## Conclusion

By following the steps outlined in this article, you can seamlessly integrate GDPR-friendly newsletter sign-ups into your Auth0-powered website or application. This not only ensures compliance with data protection regulations but also builds trust with your users, leading to higher engagement and a more successful email marketing program.

Thanks for reading!

Using Auth0 to Collect Consent for Newsletter Signups

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

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

ENS and Auth0 Lab are partnering to seamlessly make ENS profile data available to application developers

The [Ethereum](https://ethereum.org/en/) network is a popular programmable blockchain; its ecosystem is the one where a lot of active software development is happening. To identify user accounts across the blockchain, Ethereum uses [addresses](https://ethereum.org/en/developers/docs/accounts/). Since its inception in 2015, it has grown to over 198 million [unique addresses](https://etherscan.io/chart/address) and 450 thousand [daily active addresses](https://etherscan.io/chart/active-address) at the time of writing. A big reason for its popularity is that Ethereum allows developers to create and manipulate constructs beyond the network's built-in cryptocurrency ([Ether](https://ethereum.org/en/developers/docs/intro-to-ether/)).

![Graphic 01](https://images.ctfassets.net/23aumh6u8s0i/30tKSg9BZ3iQxWmOV2a85G/2a6879311b5dda35abaaf566f6bd84a5/01-fetch-ens-post.png)

![Graphic 02](https://images.ctfassets.net/23aumh6u8s0i/76xsHVURfZ2bOHIKdfxN1A/d5fb9b92669d3b8493212f24d7837f79/02-fetch-ens-post.png.png)

The problem with these addresses is that while they are very machine friendly, they are not very user friendly. An address is a 42-character hexadecimal string, e.g., `0x06012c8cf97bead5deae237070f9587f8e7a266d`. They are not easy to remember and are long and complicated, making it easy to input them incorrectly.

## Enter ENS

In 2016 Nick Johnson [proposed](https://eips.ethereum.org/EIPS/eip-137) creating the Ethereum Name Service (ENS) constructed to solve the aforementioned problems with Ethereum addresses. ENS was presented as a service that _"provides flexible resolution of short, human-readable names to service and resource identifiers"_. Now, [ENS](https://ens.domains/) is a leading decentralized naming system based on the [Ethereum blockchain](https://ethereum.org/en/developers/docs/intro-to-ethereum/). At the time of writing, it has nearly two million registered names, owned by hundreds of thousands of owners. 

ENS maps human-readable names like `alice.eth` to machine-readable identifiers such as Ethereum addresses, providing Web3 usernames. Moreover, it allows users to choose what data, like "avatar" and "email", they want to make available as part of their public, portable profile. This profile can serve as the record for any number of dapps, and now Web2 apps as well.

![Avatar](https://images.ctfassets.net/23aumh6u8s0i/7pV4xMlvqW2SPbnTyQvQoh/c40e753d90f4439ef8751bf10d146ebd/03-fetch-ens-post.png.png)

Using the [ENS Profile integration](https://marketplace.auth0.com/integrations/ens-profile) from the [Auth0 Marketplace](http://marketplace.auth0.com/), when a user [signs in with Ethereum](https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/), Auth0 will fetch the ENS profile data from the Ethereum network and make it available as [ID Token](https://auth0.com/docs/secure/tokens/id-tokens) claims. That enables you to develop applications leveraging users' ENS profiles and update your application logic to communicate with the Ethereum blockchain.

## Reap the Benefits

The **ENS Profile** integration has several benefits for both developers and end-users:

* **Leverage public user profiles:** As a developer, you can use any ENS record as part of your application. That allows you to support user profile-related functionality without implementing [CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) logic and UI for it.
* **Reduce user friction:** Users often dislike having to spend time re-creating profiles for each application. Once users configure the appropriate [ENS profile records](https://docs.ens.domains/ens-improvement-proposals/ensip-5-text-records), you can display user-friendly usernames and profile pictures and automatically send emails to them. Users will not need to re-enter their profile data into the application, improving the user experience.  
* **Seamlessly integrate with a growing ecosystem:** **ENS Profile** requires minimal changes to your code and allows your application to take advantage of Web3 constructs and its user base. User profile data from ENS is available in ID Tokens. Having ENS data in the ID Token means you don't need to update your application with dependencies and logic that retrieves ENS profile data from the Ethereum network. Instead, Auth0 and the **ENS Profile** integration abstract that from you, allowing you to integrate with Web3 constructs in your application with minimal friction.

The following shows how an application might display the ENS name and avatar (bottom-left corner) after a user signs in:

![ENS](https://images.ctfassets.net/23aumh6u8s0i/5J4W3iSTYSDT3uV8oFzOjr/c213868a315a8fc2d0d7c22635508518/04-fetch-ens-post.png.jpg)

## How It Works

The integration needs the user's Ethereum address to fetch data from ENS, and developers must have the [Sign-in with Ethereum](https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/) integration installed to use **ENS Profile**.

When users sign in with Ethereum, the integration will query their ENS profile. The integration retrieves ENS data from the Ethereum network through one or more providers. These providers expose APIs, so you don't have to connect directly to the Ethereum network to read data from it, providing ease of use. For your flexibility, the **ENS Profile** integration supports any of these providers:

* [Infura](https://infura.io/product/ethereum)
* [Pocket](https://www.pokt.network/pocket-gateway-ethereum-mainnet)
* [Ankr](https://www.ankr.com/protocol/public/)
* [Alchemy](https://www.alchemy.com/supernode)
* [Etherscan](https://etherscan.io/apis)
* [Cloudflare](https://developers.cloudflare.com/web3/ethereum-gateway/)

After retrieving the profile data, the integration will add it to the ID Token that is issued as part of the user login flow. The following [ENS records](https://docs.ens.domains/ens-improvement-proposals/ensip-5-text-records) will be available as ID Token claims ([namespaced](https://auth0.com/docs/secure/tokens/json-web-tokens/create-namespaced-custom-claims) with `https://ens.eth` to avoid collisions):

* `https://ens.eth/name (the domain name)`
* `https://ens.eth/email`
* `https://ens.eth/description`
* `https://ens.eth/url`
* `https://ens.eth/notice`
* `https://ens.eth/keywords`
* `https://ens.eth/com.github`
* `https://ens.eth/com.peepeth`
* `https://ens.eth/com.linkedin`
* `https://ens.eth/com.twitter`
* `https://ens.eth/io.keybase`
* `https://ens.eth/org.telegram`
* `https://ens.eth/avatar`
* `https://ens.eth/content`

The following is one example of an ID Token payload that is available after installing the integration:

```
{
  "https://ens.eth/email": "jane.doe@example.com",
  "https://ens.eth/url": "https://twitter.com/janedoe",
  "https://ens.eth/com.github": "https://github.com/janedoe",
  "https://ens.eth/com.twitter": "https://twitter.com/janedoe",
  "https://ens.eth/avatar": "https://www.gravatar.com/avatar/e2a7e0fbfb2c1d9aeb01fd03648da78e?s=256&d=identicon&r=PG",
  "nickname": "janedoe.eth",
  "name": "",
  "picture": "https://s.gravatar.com/avatar/e2a7e0fbfb2c1d9aeb01fd03648da78e?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fjd.png",
  "updated_at": "2022-06-09T17:11:37.685Z",
  "iss": "https://test-issuer.us.auth0.com/",
  "sub": "oauth2|siwe|eip155%3A1%3A0xde399eB33C579feeB87737B4D44932778C00FBcD",
  "aud": "k5bD0kOBesIwHzL0LVojBcn1DQnPiQD6",
  "iat": 1654794700,
  "exp": 1654830700,
  "auth_time": 1654794697
}
```

That's it. You will be able to use any of the ENS related token claims as part of your application logic just like you have been doing so far.

We can't wait to see what you build with this!

## What's Next?

The Auth0 Lab team is actively exploring the best ways to enable developers to build applications that rely on Web3 identity constructs and help bridge the Web2 and Web3 worlds. You can follow our progress on [Twitter](https://twitter.com/auth0lab). If you're interested in speaking with the team, join our [Discord](https://discord.gg/xkbkz9rZcD) and start a thread.

The [Auth0 Marketplace](https://marketplace.auth0.com/) is looking for Web3 partners to build new extensions onto Auth0. Visit [https://auth0.com/integrate](https://auth0.com/integrate) to learn more.



Fetch ENS profile data using Auth0

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

brandon-roberts

Brandon is a Developer Advocate at Nrwl, focused on community engagement, content creation, and collaboration around Nx, the open-source build framework. He enjoys learning new things, helping other developers build web applications, sharing knowledge, collaborating with others, and contributing to open source. Brandon is a Google Developer Expert in Angular, a technical writer, and also a maintainer of the NgRx project building libraries for reactive Angular applications.

Developer Advocate

Brandon Roberts

Whether you have a single application or a suite of applications, code reuse, standards around structure, process, and feature development help to ensure your codebase remains healthy in the long term.

[Nx is a build framework for monorepos](https://nx.dev) with first-class React support. It helps accelerate the adoption of proven development practices across projects of many sizes and scopes. Nx provides additional tooling for React projects to help scale and develop features at a faster pace. 

This guide walks through some of the tooling provided by Nx, the creation, and structure of an Nx workspace, with an example to follow along with.

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

## What are Monorepos

A monorepo is a single collection of all your source code that spans multiple applications, libraries, and languages. Everything in the monorepo is not deployed at the same time but is all located in a central repository. Many companies use monorepos for different organizations and projects. Some even use a single monorepo to house all the source code for projects across their entire company.

Here are some of the benefits of a monorepo:

* **Shared code** &mdash; Promotes reuse of validation code, UI components, and types across the code base, including code between the backend and the frontend.
* **Atomic changes** &mdash; Make changes to a server API and modify the clients that consume that API in the same commit. No more coordinating commits across different repositories.
* **Developer mobility** &mdash; Provides consistency between building and testing applications written using different tools and technologies. Developers can confidently contribute to other teams’ applications and verify that their changes are safe.
* **A single set of dependencies** &mdash; Use a single version of third-party dependencies for all your apps. Less frequently used applications don’t get left behind with a 3-year-old version of a framework library or an old version of a build tool. 

There are also a few common misconceptions with monorepos:

* Strictly co-locating your code just by placing all your code in the same repository.
* Running all the builds, tests, and quality checks on all applications for each PR or commit.
* Deploying every application on every commit to the main branch.
* Setting up multiple scripts across applications to handle common tasks.

Just because you have all your code in a monorepo, that does not mean you have run all the tests and checks on your monorepo for every single commit. This doesn't scale well and leads to bottlenecks in your development and Continuous Integration (CI) and Continuous Deployment (CD) pipelines. Nx provides integrated tooling to intelligently determine what needs to be run through code analysis, affected commands, and computation caching. 

### Affected commands

Nx uses code analysis to build a dependency graph of all projects in the workspace. It then uses the dependency graph to determine what projects are impacted based on your changes between your Git branches and the main branch. [Nx’s Affected Commands](https://nx.dev/latest/react/core-concepts/mental-model#affected-commands) use this code analysis to perform the minimum set of tasks based on what's changed. Let’s look at two applications that depend on a library as an example.

![](https://images.ctfassets.net/23aumh6u8s0i/3Msqcbm3M7zreqA7s3Yga/fa9a14ab5dd0970d45ff8603494a2530/Uploaded_from_Streamlining_a_React_Monorepo)

To see what applications are affected, use the **[nx affected:apps command](https://nx.dev/latest/angular/cli/affected-apps)**. Nx analyzes the nature of the changes and determines which projects, including applications and libraries, are impacted. In the example above, changing app1 doesn’t cause app2 to be impacted, so you don’t need to run all the pre-merge steps for app2. Alternatively, changing the lib, or packages that both apps depend on does impact both applications.

### Computation caching

Nx is smart in that it also knows the context in which you ran particular commands, the current hash of the files, and other environmental information. 

![](https://images.ctfassets.net/23aumh6u8s0i/1gsO5lGTZaluzgHVc3H3xr/f931ae116060c2def80962a764b4888b/Uploaded_from_Streamlining_a_React_Monorepo)

The image above displays an example of the information collected to build a unique hash used to identify the computation. With this information, Nx caches and stores these computations and can replay them if it seems the same computation is being run again.

This isn’t done through rebuilding source code. Only the artifacts produced from a given command are stored and replayed when possible. If Nx doesn’t find this computation, Nx runs the task, and after it completes, it takes the outputs and the terminal output and stores it locally (and if configured remotely). All of this happens transparently, so you don’t have to worry about it.

## Creating an Nx Workspace Using a React Preset

Now that you know how Nx works, let’s try it out by building a small application that lists Star Wars characters.

Start with creating the Nx workspace with a React application using the `react` preset. 

```sh
npx create-nx-workspace sw-org --preset react --appName myapp
```

After running this command, you’ll be asked to select a stylesheet format. You can choose the default for this demo. You also have the option to connect your workspace to [Nx Cloud](https://nx.app/) if you’d like.

After you make your selections, this command does the following:

- Generates a new Nx workspace
- Scaffolds out a new React application with modern tooling, including [Jest for unit tests](https://jestjs.io/), and [Cypress for E2E tests](https://www.cypress.io/).

There are other presets available, such as `next` for [Next.js](https://nextjs.org/) projects, and `react-express` for a workspace with React and Express pre-configured.

Every Nx workspace has a file structure similar to this:

```treeview
myorg/
├── apps/
├── libs/
├── tools/
├── workspace.json
├── nx.json
├── package.json
└── tsconfig.base.json
```

* `/apps/` contains the application projects. This is the main entry point for each runnable application.
* `/libs/` contains the library projects. Each library defines its external API so that boundaries between libraries remain clear. 
* `/tools/` contains scripts that act on your codebase.
* `/workspace.json` contains the configuration for each project in your workspace.
* `/nx.json` adds extra information about projects, including implicit dependencies and tags that can be used to restrict the ways projects are allowed to depend on each other.
* `/tsconfig.base.json` sets up the global TypeScript settings and aliases.

To serve up the application, enter into the `sw-org` directory and run the `serve` command using the Nx CLI:

```sh
nx serve
```

> Note: If you don't want to install Nx globally, you can use `npx nx serve` instead.

The initial application page is displayed.

![](https://images.ctfassets.net/23aumh6u8s0i/2EUaKnrpRkLehJempAp06f/a99c92b3282e79e42b16877c98cac1c9/Uploaded_from_Streamlining_a_React_Monorepo)

## Generating a Feature Library

[Generating libraries](https://nx.dev/latest/react/structure/library-types#feature-libraries) in an Nx workspace is done by using the `generate` command with the Nx CLI. Feature libraries are used to display UI to the user, which could including routing information, and could use other libraries such as shared components.

Create one now by running:

```sh
nx generate lib people
```

**NOTE** [Nx Console](https://nx.dev/latest/angular/getting-started/console) also provides a full l GUI to run Nx CLI commands in your editor with native VSCode and WebStorm support.

## Generating a Data Access Library

A "data access" library is where functionality for fetching and storing data for a feature exists. So any services necessary to manage the quotes are placed in this library. Throughout building applications, there will be data access libraries across multiple features.

Create the data access library by running:

```sh
nx generate lib data-access
```

**NOTE** You can also create your custom generators similar to the `library` generator inside an Nx workspace. This provides more flexibility to create more standards around your development processes and guidelines. Read more about workspace generators in our [Workspace Generators](https://nx.dev/latest/angular/generators/workspace-generators) guide.

Update the data-access library to fetch the characters from the Star Wars API.

Open up `data-access.tsx` and replace it with the following:

```js
import { useEffect, useState } from "react";

export interface IPerson {
 birth_year: string;
 eye_color: string;
 films: string[];
 gender: string;
 hair_color: string;
 height: string;
 homeworld: string;
 mass: string;
 name: string;
 skin_color: string;
 created: Date;
 edited: Date;
 species: string[];
 starships: string[];
 url: string;
 vehicles: string[];
}

export interface Response<T> {
 count: number;
 next: null | string;
 previous: null | string;
 results: T[];
}

export function usePeople(page: number) {
 const [people, setPeople] = useState<IPerson[]>([]);

 useEffect(() => {
   fetch(`https://swapi.dev/api/people/?page=${page}`).then((r) =>
   r.json().then(data => data.results)
 ).then(data => {
     setPeople(data);
   });
 }, []);

 return people;
}
```

Now update the people feature at `people.tsx` to list out the characters:

```js
import { usePeople } from '@sw-org/data-access';
import './people.module.css';

export function People() {
 const people = usePeople(1);
  return (
   <div>
     <h1>Star Wars People</h1>

     <ul>
       {
         people.map(person => (
           <li key={person.name}>
             {person.name}
           </li>
         ))
       }
     </ul>
   </div>
 );
}

export default People;
```

Replace the `App` template with the `People` component

```js
import styles from './app.module.css';

import { People } from '@sw-org/people';

export function App() {
 return (
   <div className={styles.app}>
     <People/>
   </div>
 );
}

export default App;
```

Refreshing the application shows a list of characters.

![](https://images.ctfassets.net/23aumh6u8s0i/3wmVIH8Sqz1ejavorzIzsI/99c44e96e4e44149da2e72e5e328baad/Uploaded_from_Streamlining_a_React_Monorepo)

The list of characters is simple. The business and data logic is kept in libraries. As your applications grow, the number of libraries grows along with it, but the applications remain relatively small and are only used for integrating core functionality for the app to run.

## Dependency Graph

Nx knows the dependencies between projects in your workspace and can generate your dependency graph visually at any point in time. 

Run the **nx dep-graph** command to see the current state of the workspace.

```sh
nx dep-graph
```

This displays the application, E2E project, and the two libraries. 

![](https://images.ctfassets.net/23aumh6u8s0i/4oiIpWdF5wIpz6y5qJkGA4/9a8802092e0de9c1a0e5c9e25d9828d7/Uploaded_from_Streamlining_a_React_Monorepo)

**NOTE**: You can also have the dependency graph auto-refresh with the `--watch` flag.

You can also see what projects are impacted by a given change. Make a change to the App.tsx, such as removing the `className`, save, and run the **nx affected:dep-graph** command.

```sh
nx affected:dep-graph
```

This displays the **myapp** and **myapp-e2e** highlighted in red as affected projects.

![](https://images.ctfassets.net/23aumh6u8s0i/2S5DueXJUNdbbguneKUjGJ/cc397167e5dc78a1835ab2db57b6dacb/Uploaded_from_Streamlining_a_React_Monorepo)


**NOTE:** The **myapp-e2e** application is directly tied to mapp, but is implicitly linked through the **nx.json** file. Read more about Nx configuration here.

### Using Affected Commands

Nx provides affected commands to run certain tasks against affected projects. For example, make a change to the `data-access` library, and run **nx affected:build**. 

```sh
nx affected:build
```

Nx finds the affected applications impacted by changing the **data-access **library and runs the **build** target for each one of them. That way, **only** the affected projects are built for the given change, and not every project in the monorepo. The same commands work for **test**, **lint**, and **e2e**, and others.

There is also the **nx affected** command that works with any defined target. The alias for **nx affected:build** is:

```sh
nx affected --target=build
```

This allows you to run any target based on the affected projects.

### Using Computation Caching

Along with affected commands, Nx supports[ computation caching](https://nx.dev/latest/angular/core-extended/computation-caching) to never execute the same computation twice. This computation cache is pluggable and can be distributed. Taking `**myapp`** as an example, run the build for `myapp` twice.

```sh
nx build myapp
```

When running the same command the second time without changes, you immediately get the cached results from the previous computation. The computation cache is done locally, but can also be distributed and extended to the rest of your team and organization. 

[Nx Cloud](https://nx.app) is one such option to distribute your computation cache. It includes a free tier with 5 hours of saved time per month, enterprise options, and is free for open-source projects.

## Summary

Nx provides modern tooling including code analysis, code generation, code analysis, affected commands, and computation caching to scale your application development using a monorepo.

What did we cover?

- Monorepos and why you should use one
- Nx workspace structure and standardization
- Smarter tooling with code analysis, affected commands, dependency visualization, and computation caching.

Find out more with the following resources:

* Documentation at [https://nx.dev](https://nx.dev)
* Free [Egghead course](https://egghead.io/playlists/scale-react-development-with-nx-4038) on Scaling React Development

Streamlining a React Monorepo

diegopoza

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

Sr Manager, Developer Advocacy

Diego Poza

Why Naranja and Wabi turned to Auth0 to ensure identity expertise and scaling

The market in Latin America is growing faster than ever, with new venture capital deals nearly doubling to 488 between 2017 and 2020, according to [Bloomberg](https://www.bloomberg.com/news/articles/2021-03-16/latin-american-startups-had-record-venture-capital-deals-in-2020). Beyond VC, a [study by IDB lab](https://publications.iadb.org/publications/english/document/Tecnolatinas-2021-The-LAC-Startup-Ecosystem-Comes-of-Age.pdf) revealed that the tech-enabled startup market hit a valuation of more than $220 billion USD in 2020.

![LATAM](https://images.ctfassets.net/23aumh6u8s0i/Gz6t31FLxbPc7r8T996gE/caed742f057acf90192df17560dbf527/Latam11.jpg)

Globally, the pandemic has [accelerated digital road maps across industries](https://auth0.com/blog/how-brick-and-mortar-approaches-improve-digital-experiences/) and businesses now have to respond to changes in digital expectations and buying patterns.
<include src="QuoteCard" body="Companies cannot predict exactly what their business and customers will need tomorrow, especially in response to today’s rapidly changing digital environment." name="Gabriel Camargo" title="Product Director" team="" company="CLM" />

Partnering with [CLM](https://auth0.com/blog/auth0-expands-global-partner-network-in-latin-america-with-clm/) on distribution in Latin America (LATAM) extends Auth0’s reach into Brazil, Colombia, Ecuador, and Peru.

Over the years of working within Latin America, we’ve learned that [identity expertise](https://auth0.com/blog/building-an-identity-solution-quantity-doesnt-equal-quality) and [scalability](https://auth0.com/blog/can-your-identity-solution-grow-with-your-company) are two critical areas of concern for businesses in the region. You can check out our earlier posts in this series for details, but here, we wanted to look more closely at how we were able to help two companies within the region.

## Naranja — From Leading Credit Card Issuer in Argentina, To Complete Consumer Ecosystem

[Fintech leader Naranja](https://auth0.com/case-studies/naranja/) has been providing credit cards to the Argentinian market for over 30 years. In that time, they’ve grown to cover over 5 million customers by keeping those customers’ needs their top priority. As they grew, Naranja also began to integrate additional verticals into their business model. Pretty soon, they were offering payment services, financing, travel, media, and other services beyond their credit card programs.

As they added these verticals, Naranja’s head of engineering Javier Voos soon realized they would need to consolidate their identity solution to cover all aspects of their growing ecosystem. He knew that in order to continue putting the customer experience first, they would need to find the right IDaaS provider that would be able to scale along with their planned expansion.

[link to video](https://www.youtube.com/watch?v=kqouiuVk07Q&feature=emb_imp_woyt)

<iframe width="560" height="315" src="https://www.youtube.com/embed/kqouiuVk07Q" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

<include src="QuoteCard" body="The main idea behind the Naranja ecosystem is to provide the best experience to our customers, making sure that our digital platform provides all the resources that an online business needs for success, and hence support the ecosystem evolution." name="Javier Voos" title="Head of Engineerin" team="" company="Naranja" />

Voos’ priority was to find a platform that provided secure APIs for identity so they could focus their expansion efforts on B2B services alongside their expanded consumer offerings. Finding Auth0 meant that his team could implement one identity solution that would allow both B2B and B2C customers access to the platforms they needed access to while ensuring data privacy and a low-friction user experience.
<include src="QuoteCard" body="Auth0 gave our company the tools to secure the access to our API for first- and third-party consumers, in a way that can scale through time and put us in a better position to ally with new partners and work our way to a fully functional Naranja API Market." name="Danilo Asis" title="Solution Architect" team="" company="Naranja" />

## WABI — South America’s E-Commerce Portal

With a half-dozen offerings already on offer, [WABI](https://auth0.com/case-studies/wabipay/) is looking to the future. Their ambitious goal is to become Latin America’s go-to e-commerce portal. Their offerings already include WABI, a smartphone-based grocery service; Wabipay, an e-wallet app; and four additional applications. The end-goal WABI envisions is for customers to log in one time and have access to a complete, end-to-end e-commerce experience. They’ll be able to shop, pay, and track delivery all in one place.

Juan Manuel Mingo, former WABI Business Manager, sums up the hurdle they faced when it came to identity and customer authentication, “We had different platforms with different user registration processes,” he says. “Our aim was to unify all the user registration of the different platforms in order to get a better user experience and to have a more organized user database.” The disjointed customer experience was the first thing WABI knew they would have to solve before they could continue growing and expanding their e-commerce ecosystem. 

<include src="QuoteCard" body="Our endgame is that you enter the ecosystem through Wabi. You log in to Wabi, order your things, and when you want to pay, you simply go to WabiPay, and you’re already logged in." name="Frederico Galli" title="General Manager" team="" company="WABI" />

Like Naranja, WABI has always had a customer-first attitude. That meant that customer-facing features like single sign-on were top priorities. As Frederico Galli stated, their endgame is for customers to sign in once and have access to the entire ecosystem of WABI offerings. Not only that, but with further expansion plans in the works, they needed an identity solution that was with them for the long haul. Juan Manual Mingo put it like this, “WABI is scalable, and we need a partner that is, too. We believe Auth0 will support us in getting there.”

![LATAM](https://images.ctfassets.net/23aumh6u8s0i/P45m9X6Z8ag9oOTv8R4kW/cc92f6325cb89fd84f233aa6c6992218/Latam12.jpg)

## Learn how Auth0 can help your business

[Argentinian talent Eugenio Pace and Matias Wolowski](https://www.forbesargentina.com/editorial/la-increible-historia-auth0-cliente-us-27-quinto-unicornio-hoy-vale-us-1100-n1352) founded Auth0, so we know the ins and outs of the South American market. When you’re ready to bring your identity solution in line with your broader organizational expansion goals, reach out to our [market experts](https://auth0.com/contact-us) to start the discussion about how we can help.

<include src="asides/AboutAuth0" />

LATAM Response to Rapid Digital Change

barry-plaga

Chief Financial Officer

Barry Plaga

sandra-karlsson-profile

Manager, International Business Operations

Sandra Karlsson

A Downloadable Guide on Reopening Procedures to Ensure the Safety of Your Employees



Over the past few months, we have all been relegated to our home offices in response to [COVID-19](https://auth0.com/blog/business-continuity-at-auth0-our-response-to-covid-19/). And while more than half of our workforce (55%) was already working remotely before the pandemic hit, there was still a large population of our team that made the transition away from working out of our six physical offices around the world. 

While no one knew how long the quarantine would last (it is still very much in effect for some parts of the world), we started preparing a global reopening plan very early on for the time when we would eventually go “back to normal,” or at least, back to the office. We always have and will always prioritize the safety of our employees. 

The ‘Back to Office’ plan ensures that when all of our offices open up, our employees have clear guidelines on re-entry. Our offices have all been redesigned and reconfigured to accommodate social distancing guidelines and safety precautions to minimize risk as much as possible. In adopting our guidelines, we complied with local laws and organizations, such as [WHO](https://www.who.int/emergencies/diseases/novel-coronavirus-2019), and the [CDC](https://www.cdc.gov/coronavirus/2019-ncov/index.html).

At Auth0, we will start with a phased approach with our worldwide offices. And slowly, but surely, open one by one as their respective regions allow. 

Our worldwide Back to Office guidelines, here as a [**downloadable PDF**](https://cdn.auth0.com/blog/back_to_office/back_to_office_-_worldwide.pdf) for your reference, provide the procedures and actions we took to ensure that the phased reopening was done with the utmost care. We have chosen to share the protective measures and policies that Auth0 has put into place in the hope that they are helpful to other companies for their reopening as well. 

Auth0’s Back to Office plans will later be updated with the local laws and/or guidelines in each country where our offices are located. We hope this document will be useful for anyone working on similar office plans.

**Stay safe and be kind to each other.**

**Auditor Back to Office guidelines:** Sandra Karlsson / Operations & Facilities Team<br>
**Design:** Cecilia Alvarez / Guillermo Mesyngier

<include src="asides/AboutAuth0" />


Returning to Our Auth0 Offices. Slowly and Safely.

Dirceu-Tiegs

What I enjoy the most about being an SRE at Auth0 is that it allows me to exercise different areas such as coding, architecture, writing, training, investigations, debugging, and incident response. It's great to be able to think deeply about all aspects related to reliability and then apply it to large-scale, real-world projects.

Site Reliability Engineering Team

Dirceu Tiegs

Learn more about how Auth0 architects its services to ensure scalability and high availability to handle more than 1.5 billion logins per month.



Auth0 provides authentication, authorization, and single sign-on services for apps of any type (mobile, web, native) on any stack. Authentication is critical for the vast majority of apps. We designed Auth0 from the beginning so that it could run anywhere: on our cloud, on your cloud, or even on your own private infrastructure.

In this post, we'll talk more about our public SaaS deployments and provide a brief introduction to the infrastructure behind [auth0.com](https://auth0.com/) and the strategies we use to keep it up and running with high availability. This is an updated version of the [2014 High Scalability post about Auth0's architecture](http://highscalability.com/blog/2014/12/1/auth0-architecture-running-in-multiple-cloud-providers-and-r.html).

A lot has changed since then in Auth0. These are some of the highlights:

- We went from processing a couple of million logins per month to 2.5 billion logins per month, serving thousands of customers, including [FuboTV](https://auth0.com/learn/sports-centric-streaming-service-fubotv-sees-50-roi-just-auth0s-security/), [Mozilla](https://auth0.com/blog/auth0-mozilla-partnership/), [InterMiles](https://auth0.com/learn/jetprivilege-case-study/), and more.

- We implemented new features like [custom domains](https://auth0.com/docs/custom-domains), [scaled bcrypt operations](https://auth0.engineering/bcrypt-as-a-service-9e71707bda47), vastly [improved user search](https://auth0.com/docs/users/search/v3), and much more.

- The number of services that compose our product in order to scale our organization and handle the increases in traffic went from under 10 to over 30 services.

- The number of cloud resources grew immensely as well; we used to have a couple dozen nodes in one environment (US), now we have more than a thousand over four environments (US, US-2, EU, AU).

- We doubled-down decided to use a single cloud provider for each of our environments and moved all our public cloud infrastructure to AWS.

## Core service architecture

![Auth0.com core service architecture](https://images.ctfassets.net/23aumh6u8s0i/2mden7W7brrYGv8LHDK2Lp/5347634d4197ae655555cf93b8209c2d/auth0-core-service-architecture)

The core service is composed of different layers:

- Core applications: Auto-scaling groups of servers running different services of our stack (authentication, management API, multi-factor authentication API, and much more).

- Data storage: Clusters of MongoDB, Elasticsearch, Redis, and PostgreSQL storing a variety of datasets for different applications and features.

- Transports/Queues: Kinesis streams and RabbitMQ, SNS, and SQS queues.

- Base services: Services for rate-limiting, bcrypt clusters, feature-flags, and more.

- Routing: AWS load balancers (ALB, NLB, and ELB from AWS) and some nodes running NGINX as a proxy.

## High Availability

In 2014 we used a multi-cloud architecture (using Azure and AWS, with some extra resources on Google Cloud) and that served us well for years. As our usage (and load) rapidly increased, we found ourselves relying on AWS resources more and more.

At first, we switched our primary region in our environment to be in AWS, keeping Azure as failover. As we began using more AWS resources like Kinesis and SQS, we started having trouble keeping the same feature set in both providers. As our need to move (and scale) faster grew, we opted to keep supporting Azure with a limited feature parity: if everything went down on AWS, we could still support core authentication features using the Azure clusters, but not much of the new stuff we had been developing.

After some bad outages in 2016, we decided to finally converge on AWS. We stopped all efforts related to keeping the services and automation platform-independent and instead focused on:

- Providing a better failover story inside AWS, using multiple regions and at least 3 Availability Zones per region.

- Increasing usage of AWS-specific resources like auto-scaling groups (instead of using fixed clusters of nodes), application load balancers (ALBs), and more.

- Writing better automation: we revamped our automation, completely embracing infrastructure as code using TerraForm and SaltStack to provision new Auth0 environments (and also to replace existing ones). This allowed us to grow from partially automated environments doing ~300 logins per second to fully automated environments doing more than ~3.4 thousand logins per second; using the new tooling makes it easier to scale up (and down, whenever it makes sense). The level of automation we achieved is not perfect but is allowing us to grow to new regions and create new environments in a much more convenient way.

- Writing better playbooks: with more time and focus, we saw that besides automation we also needed better playbooks in order to understand, manage, and respond to incidents related to our ever-growing mesh of services. This vastly improved scalability and reliability while also allowing us to onboard new employees faster.

<include src="TweetQuote" quoteText="Writing better automation let us grow from partially automated environments doing ~300 logins per second to fully automated environments doing more than ~3.4 thousand logins per second"/>

Let's take a look at our US environment architecture, for instance. We have this general structure:

![Auth0 US Environment Architecture](https://images.ctfassets.net/23aumh6u8s0i/4hGMwY5n4jk2aoJyyRAhjF/0ca131b596da7068aced34ca69fbbc5c/auth0-us-environment-architecture)

And this is the structure inside a single AZ:

![Auth0 Single Availablity Zone](https://images.ctfassets.net/23aumh6u8s0i/4EtOG7to5lHmyYnU5Q3aaC/a22b74fe7b0a58d0f54a78a6b801bbd2/auth0-single-availability-zone)

In this case, we use two AWS regions: us-west-2 (our primary) and us-west-1 (our failover). Under normal circumstances, all requests will go to us-west-2, being served by three separate availability zones.

This is how we achieve high availability: all services (including databases) have running instances on every availability zone (AZ). If one AZ is down due to a data center failure, we still have two AZs to serve requests from. If the entire region is down or having errors, we can update Route53 to failover to us-west-1 and resume operations.

<include src="TweetQuote" quoteText="We achieve high availability by running all services instances on every AWS availability zone"/>

We have different maturity levels for service failover: some services, like user search v2 (that builds a cache on Elasticsearch) might work but with slightly stale data; still, core functionality keeps working as expected.

In the data layer, we use:

- A cross-region cluster for MongoDB.

- RDS replication for PostgreSQL.

- Clusters per region for Elasticsearch with automated snapshot and restores running regularly to account for the lack of cross-region clustering.

We exercise failover at least once per year, and we have playbooks and automation to help new infrastructure engineers get up to speed on how to do it and what are the implications.

Our deployments are usually triggered by a Jenkins node; depending on the service we either use Puppet, SaltStack, and/or Ansible to update individual or groups of nodes, or we update our AMIs and create new autoscaling groups for immutable deployments. We have different types of deployments for new and old services, and this has been shown to be largely ineffective as we need to maintain automation, docs, and monitoring for something that should be unified.

We are currently rolling out blue/green deployments for some of the core services, and we intend to implement the same for every core and supporting service.

## Automated Testing

Besides unit test coverage on every project, we have multiple functional test suites that run in every environment; we run it on a staging environment before we deploy to production, and we run them again in production after finishing a deployment to ensure that everything works.

The highlights:

- We have thousands of unit tests in different projects.

- We use Pingdom probes that run every minute to check core functionality.

- We use a mix of Selenium and CodeceptJS-based functional tests before and after every deployment. The functional test suites test different API endpoints, authentication flows, identity providers, and much more.

<include src="TweetQuote" quoteText="Besides unit test coverage on every project, we have multiple functional test suites that run in every environment: staging before deploying to production and again in production after finishing deployment."/>

## CDN

Until 2017 we ran our own, custom-built CDN using NGINX, Varnish, and EC2 nodes in multiple regions. Since then, we transitioned to CloudFront, which has given us several benefits that include:

- More edge locations, which means less latency for our customers.

- Lower maintenance costs.

- Easier configuration.

There are a few downsides, like the fact that we need to run Lambdas to perform some configurations (like adding custom headers to PDF files and things like that). Still, the upsides definitely make up for that.

## Extend

One of the features we provide is the ability to run custom code as part of the login transaction, either via [_authentication rules_](https://auth0.com/docs/rules/current) or [_custom database connections_](https://auth0.com/docs/connections/database/custom-db). These features are powered by [_Extend_](https://goextend.io/), an extensibility platform that grew out of Auth0 and is now being used by other companies as well. With Extend, our customers can write anything they want in those scripts and rules, allowing them to extend profiles, normalize attributes, send notifications, and much more.

We have Extend clusters specifically for Auth0; they use a combination of EC2 auto-scaling groups, Docker containers, and custom proxies to handle requests from our tenants, processing thousands of requests per second and responding fast to variations of load. For more details about how this is built and run, check out this post on [how to build your own serverless platform](https://tomasz.janczuk.org/2018/03/how-to-build-your-own-serverless-platform.html).

## Monitoring

We use a combination of different tools for monitoring and debugging issues:

- CloudWatch

- DataDog

- Pingdom

- SENTINL

The vast majority of our alerts come from CloudWatch and DataDog.

We tend to configure CloudWatch alarms via TerraForm, and the main monitors we keep on CloudWatch are:

- HTTP errors from our main load balancers.

- Unhealthy instances in a target group.

- SQS processing delays.

CloudWatch is the best tool for alarms based on AWS-generated metrics (like ones from load balancers or autoscaling groups). CloudWatch alerts usually go to PagerDuty, and from PagerDuty to Slack/phones.

DataDog is a service we use to store and act on time-series metrics. We send metrics from Linux boxes, AWS resources, off-the-shelf services (like NGINX or MongoDB), and also custom services we have built (like our Management API).

We have many DataDog monitors. A few examples:

- Increase in response times in `$service` on `$environment`.

- Running out of space on `$volume` in `$instance` (`$ip_address`).

- Issue with `$process` on `$environment` / `$host` (`$ip_address`).

- Increase in processing time for `$service` on `$environment`.

- NTP drifting off / clock issue on `$host` (`$ip_address`).

- MongoDB replica-set change on `$environment`.

As you can see from the examples above, we have monitors on low-level metrics (like disk space) and high-level metrics (like MongoDB replica-set change, which alerts us if there was a change in the primary node definition, for example). We do much more and have some pretty sophisticated monitors around some services.

DataDog alerts are pretty flexible in their outputs and we usually send them all to Slack, sending to PagerDuty only those who should "wake people up" (like spikes of errors, or most things that we are sure that are having an effect on customers).

For logging we use Kibana and SumoLogic; we are using SumoLogic to record audit trails and many AWS-generated logs, and we use Kibana to store application logs from our own services and other "off-the-shelf" services like NGINX and MongoDB.

## The Future

Our platform evolved quite a bit in order to handle the extra load and the huge variety of use cases that are important to our customers, but we still have more room for optimizations.

Not only our platform grew, but our engineering organization increased in size: we have many new teams building their own services and are in need of automation, tooling, and guidance around scalability.
With that in mind, these are the initiatives in place for us to scale not only our platform but also our engineering practice:

- Build a Platform, PaaS style: As mentioned before, today we have different automation and deployment flows; this causes confusion and creates a barrier of entry for engineers as it's hard to experiment and scale up without touching too many repositories. We are developing a PoC for a platform (currently running on top of ECS) in which engineers can configure a YAML file and just deploy it to get computing resources, monitoring, logging, backups, and much more. All of that without having to configure it explicitly. This effort is in an early stage and might still change a lot (EKS?). However, we feel we are taking the right direction given our growing size and scalability constraints.

- Implement smoke tests for every new pull request: besides unit testing (that already runs on each new PR), we want to run integration tests on ephemeral environments wherever that's possible.

- Centralize our logging solution into just one provider. This might mean moving away from Kibana and using just SumoLogic, but we still need to evaluate feature set, data volume, and more.

- Automate metrics: Too much of our metric story is manual now: adding metrics-related calls to the code while deploying, and building dashboards and monitors using the DataDog interface. If we use a standard format and naming, we could do things like building dashboards/monitors automatically, extracting metrics from logs instead of explicitly adding calls to the code, and more.

- Ensure we have auto-scaling and blue/green deployments on every core service. This should come out-of-the-box from our new Platform, but while that is being built and tested we need to improve the scaling/deployment/rollback story for the core services that are still lacking in that regard.

<include src="asides/AboutAuth0" />


Auth0 Architecture: 5 Years In

ec1016a9a63da65998b75f35b6ceb3bb

Javascript junkie, technology enthusiast, tinkerer. Currently Technical Evangelist at Auth0 (https://auth0.com ). I like to learn new things and share that knowledge at conferences.

Technical Evangelist

Joel Lord

Learn how to ensure that only real users are registering to your applications using Kickbox and Auth0 Hooks.



When building an application, it is critical to ensure that the users who are signing up for services or products are real users. By using Auth0, email verification services are provided out of the box; however, wouldn't it be better if verification emails didn't have to be sent at all? By using a combination of [Kickbox](https://kickbox.com/) and [Auth0 Hooks](https://auth0.com/docs/hooks), user email addresses can be validated without sending any emails.

## How does Kickbox work?

Kickbox is an [email technology company](https://kickbox.com/about) with products that help verify email addresses and prevent fake sign-ups applications.

To create a free account, we can visit the [Kickbox sign-up page](https://app.kickbox.com/signup).

<include src="TweetQuote" quoteText="Kickbox ensures we only send email to real users and helps us separate the low-quality addresses from high-value contacts."/>

## Preparing an Auth0 Tenant to Integrate with Kickbox

To demonstrate the integration of Kickbox with Auth0, we are going to use an existing [Auth0 Tenant](https://auth0.com/docs/getting-started/the-basics#account-and-tenants).

> If you haven't already done so, <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 Auth0 account here</a>.

Since we don’t want an email verification to be sent any more, we need to deactivate that option in the tenant. On the left sidebar of the Auth0 Dashboard, let's click on **Emails** first and then on **Templates** to get to the [Email Templates section](https://manage.auth0.com/#/emails). In this section, the **Verification Email** template should be selected by default. Find the **Status** toggle and turn it off.

![Auth0 Email Templates](https://images.ctfassets.net/23aumh6u8s0i/UitVKwTRyrujA8IOXGyfE/54bbbcefe7f54f7fa1dcfab90920d63b/auth0-email-templates)

We are now ready to add an Auth0 hook and integrate Kickbox.

## Kickbox Sendex™ Email Quality

As stated in the Kickbox documentation, Kickbox provides us with a [Sendex value](https://docs.kickbox.com/docs/the-sendex) which is an indicator of the quality of an email address. The existence or syntactical correctness of an email address does not indicate its quality. For example, `john.smith@example.com` can generally be seen as a higher quality email address than `sdfsdfsdf@example.com`.

Kickbox uses a number of algorithms, derived from the millions of email transactions it performs each hour, to determine the overall quality of an email address. These are some of the characteristics Kickbox considers when classifying the quality of an email address:

- Is the email address similar to a known, high-quality, valid email address? The Kickbox platform is always evaluating and learning what patterns good email addresses employ. Its evolving data is used to provide insight into the overall quality of a given address.

- Is the email address domain a commercial domain (example: `acme.com`) or a personal domain (`example: yahoo.com`)?

- Does the email address appear to be associated with a role (example: `postmaster@example.com`) instead of a person (example: `bob.smith@example.com`)?

The Sendex value ranges from a `0` (no quality) to `1` (excellent quality). The value of a good Sendex score depends on the specific purpose of the application. For a transactional email the following criteria may be applied:

- 1.00 - 0.55 = Good

- 0.54 - 0.20 = Fair

- 0.19 - 0.00 = Poor

While the Sendex code is useful to verify the quality of an email address, using it in a pre-registration hook could be problematic. In our case, we will want to validate the authenticity of the email, not the quality. To achieve this, Kickbox provides us with other useful information. We will use two of the properties that are provided by Kickbox to validate the email:

- The `result` property will tell us if this email will actually be delivered or if it's from a risky source. In our case, we will validate that this email is not `undeliverable`.

- The `disposable` property will tell us if this email comes from a service that offers disposable email addresses.

Using these two properties with a pre-registration hook, we'll determine if we'll either create the user account or send an error at the moment of the sign-up.

## Building an Auth0 Hook

[Auth0 Hooks](https://auth0.com/docs/hooks) allow us to customize the behavior of Auth0 using [Node.js](https://nodejs.org/en/) code that is executed against extensibility points (which are comparable to webhooks that come with a server). Hooks give us modularity when configuring our Auth0 implementation and extend the functionality of base Auth0 features.

On the left sidebar in the Auth0 Dashboard, let's click on [Hooks](https://manage.auth0.com/#/hooks). In the Hooks page, we will find different places where we can add a hook in the user login or sign-up life cycle. The one we are interested in is the **Pre User Registration** hook. We want to verify a user email before they register into our system.

To create a new hook, let's do the following:

- Click on the **Create New Hook** button.

- Give the hook a name.

- Select "Pre User Registration" from the "Hook" drop-down field.

- Click on the "Create" button.

Our newly created Auth0 hook will be shown under the "Pre User Registration" section with a green dot before its name. To edit it, let's click on the pencil button in the row below it.

![Newly created Auth0 Hook with an active indicator](https://images.ctfassets.net/23aumh6u8s0i/5YViqqBkxsCE9Am5KufZl8/2f6b325ac113e82ec75baf89547b2f47/newly-created-auth0-hook)

We are taken to the [Webtask editor](https://webtask.io/docs/editor) where we can easily edit our hook logic within the Auth0 Dashboard. In here, we will be able to edit the code that gets executed every time a new user registers. We can add new metadata to our users and return this or we can throw an error which will prevent the user registration.

We can remove all the default code that is there to start with an empty hook. The first thing that we will need is the function that will be executed upon a new user registration:

```javascript
module.exports = function(user, context, callback) {};
```

When our code execution is done, it will need to return the `callback` function with either an error or a valid response. So let’s add this:

```javascript
module.exports = function(user, context, callback) {
  const response = {};
  response.user = user;

  callback(null, response);
};
```

In order to connect to the Kickbox service, we will need to do a `GET` request using the Node `request` module. We can add that at the top of our code just before the `module.exports`:

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

module.exports = function(user, context, callback) {
  // ...
};
```

The [Kickbox email verification API](https://docs.kickbox.com/v2.0/reference) is fairly simple to use. We simply make a `GET` call to the following endpoint:

```shell
https://api.kickbox.com/v2/verify?email=<email>&apikey=<API_KEY>
```

In the URL above, `<email>` is the address that we want to verify and `<API_KEY>` is our [Kickbox API key](https://docs.kickbox.com/docs/using-the-api).

Let’s build the `GET` request:

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

module.exports = function(user, context, callback) {
  const response = {};
  response.user = user;
  const API_KEY = context.webtask.secrets.KICKBOX_API_KEY;
  const email = user.email;
  const url = `https://api.kickbox.com/v2/verify?timeout=6000&email=${email}&apikey=${API_KEY}`;

  request.get({ url }, function(err, resp, body) {
    // Process the response and send back the callback
    callback(null, response);
  });
};
```

Now, we will automatically reject any email address that comes from a disposable email service or email addresses that are known to be undeliverable:

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

module.exports = function(user, context, callback) {
  const response = {};
  response.user = user;
  const API_KEY = context.webtask.secrets.KICKBOX_API_KEY;
  const email = user.email;
  const url = `https://api.kickbox.com/v2/verify?timeout=6000&email=${email}&apikey=${API_KEY}`;

  request.get({ url }, function(err, resp, body) {
    body = JSON.parse(body);

    // Add the user_metadata property if not present already
    if (!response.user.user_metadata) response.user.user_metadata = {};

    if (body.result != "undeliverable" && !body.disposable) {
      // Good email
      console.log("This email is valid, run the callback");
      callback(null, response);
    } else {
      console.log("Probably not a valid email address");
      callback(`Access Denied by Kickbox server. (${body.sendex})`);
    }
  });
};
```

In this case, we are looking at the Sendex score only. If the Sendex score is over `0.75`, we assume that the email address is safe and good to go. There are various other checks that we could make to decide if we want to accept the user or not.

Using this code will send back a generic error message to the end-user on the [Auth0 Universal Login page](https://auth0.com/docs/hosted-pages/login) when the user is trying to sign up with an invalid email.

<include src="TweetQuote" quoteText="Auth0 Hooks are a new extensibility mechanism in Auth0 that allows us to customize the behavior of the Auth0 platform using Node.js."/>

## Taking the User Experience One Step Further

This workflow may not create the most user-friendly experience. In order to show a more meaningful message, we could use the [Auth0 Hosted Pages editor](https://auth0.com/docs/hosted-pages#customize-your-hosted-page). Now that we have access to the Kickbox email data, we could still let our users login but we could perform email verification if we are feeling unsure. There are many other options that we can add to this workflow from here on. There is no limit at what we can do using the Auth0 hooks! I encourage everyone to give them a try.

<include src="asides/AboutAuth0" />


Validate User Emails Fast using Kickbox and Auth0 Hooks

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

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

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Enterprise SSO ensures better productivity, user experience, and security for employees through single-click access.



Leading up to the 2016 U.S. presidential election, Russian hackers allegedly attacked the Hillary Clinton campaign and the Democratic National Committee with [spear-phishing](https://www.pcmag.com/article/354240/spear-phishing-attacks-what-you-need-to-know) efforts to trick users into providing their usernames and passwords to fraudulent websites.

As cybersecurity concerns continue to mount, user credentials demonstrate a universal weak point in corporate security, and the more accounts and logins employees and IT departments must manage, the more hackers can find valuable openings. 

So how do companies navigate these risks in a world constantly pushing for more SaaS application use as they grow in size?

One answer lies in SSO, a way to enable single-click credentials and secure identity verification while also improving user experience. 

## What is SSO?

SSO—Single Sign-on—acts as a holistic, single login point where users enter one set of authentication credentials that grant access to a suite of other applications, regardless of the platform, technology, or domain used. 

Picture an office building with unique offices for a variety of related but separate businesses, each with their own key. 

But if it were using an SSO-like system, authorized personnel would instead use one key to get through the front door, sparing them the hassle of using separate keys to get into the individual offices. 

This is the general idea behind how SSO systems work for services like G Suite — where your Google account login gives you access to a variety of individual applications — and Slack. 

### How does SSO work?

Users begin their SSO experience by logging into a gateway, which can be displayed in a variety of ways, depending on the application a company uses. 

With Auth0, users are redirected to a login page with username and password fields, and may include Social Identity Providers such as LinkedIn, GitHub, Google, etc.

![Example Auth0 login screen - SSO in background](https://images.ctfassets.net/23aumh6u8s0i/3nHe9HYJtL71aEhJwAmUms/cbb668c190ab9abca22db8642f6b0084/enterprise_sso_auth0_example)

From there, the users go through the following steps: 

1. They enter their master username and password
2. The credentials are run through the Identity Provider (IdP) for verification, where the authentication server checks the credentials against the directory that contains stored data
3. If the credentials check out, the authorizing server will set an SSO cookie 
4. Users are then redirected to the application they want to access

In the future, users won’t have to see a login screen when accessing any approved application integrated with the SSO setup. 

Instead, when users want to log in:

1. the IdP checks to see if there is an existing SSO cookie; 
2. if necessary, the provider updates the cookie; and 
3. the IdP returns an ID token containing the users' identity information and logs them in. 

Note: During this process, users don’t see a login screen and are seamlessly directed to the dashboard of the application they’re looking to use. 

## 1. Enterprise SSO Improves Employees' User Experience

By using [enterprise SSO](https://auth0.com/single-sign-on), companies save employees time and effort by asking them for only one login and one set of credentials. 

These credentials work for all cloud, on-premises, and mobile applications and provide a hub for all company applications, rather than requiring employees to remember usernames and passwords for each tool.

SSO also provides employees with a more personalized experience by bringing all of their tools and resources into one hub. 

## 2. SSO Provides Multiplatform Access

<include src="TweetQuote" quoteText="Universal access provides employees with the flexibility they expect in the modern workplace and ensures IT security against the threats inherent in modern digital life"/>

By giving employees a single point of login, companies seamlessly provide their teams with multiplatform access. 

With recent studies showing that small companies use a mean of [13.4 different applications](https://www.intermedia.net/assets/pdf/Osterman_-_Survey_on_Application_Use_Within_Organizations.pdf), and large companies boast an average of [more than 15 applications](https://www.intermedia.net/assets/pdf/Osterman_-_Survey_on_Application_Use_Within_Organizations.pdf), SSO allows companies to reduce the chance of employees losing, reusing, and sharing passwords across a multitude of accounts.

That means employees aren’t limited to accessing key tools and resources only at work: They can also securely log into these applications from their homes and mobile phones or access them while traveling.

![Google G Suite apps panel](https://images.ctfassets.net/23aumh6u8s0i/yEX0HHdnz6XJUO4aPYhpj/c97ba95f168fe8d8d41061f18a5dd93b/enterprise_sso_google_apps)

[Source: [Google](https://gsuite.google.com/)]

This universal access provides employees with the flexibility they expect in the modern workplace and ensures IT security against the [threats inherent in modern digital life](https://auth0.com/blog/four-cybersecurity-attacks-you-need-to-know/).

## 3. Enterprise SSO Ensures More Secure Passwords

While employees objectively know they should create hard-to-guess passwords, the impracticality of remembering complex credentials often results in the reuse of weak passwords over and over again. 

In fact, [nearly 90% of people ages 18–30 use the same password_](https://keepersecurity.com/assets/pdf/Keeper-Mobile-Survey-Infographic.pdf) across multiple accounts. 

When employees give in to the demand for increasingly complex passwords in order to thwart hackers, the frequency of password recoveries skyrockets. Because of these complex password requirements, [_60% of people need to reset their passwords every 60 days_](https://keepersecurity.com/assets/pdf/Keeper-Mobile-Survey-Infographic.pdf) — a practice that also [_costs companies an average $179 per employee_](https://www.pingidentity.com/en/company/blog/2015/11/13/passwords_will_die_a_slow_death.html) [_per employee_](https://www.pingidentity.com/en/company/blog/2015/11/13/passwords_will_die_a_slow_death.html) and is largely avoidable with SSO.

When companies embrace enterprise SSO, team members have to remember only one master set of credentials. This prevents them from creating unique, complex sets of passwords, reusing weak passwords, or [_keeping physical records of all passwords_](https://keepersecurity.com/assets/pdf/Keeper-Mobile-Survey-Infographic.pdf) — all of which are inconvenient, costly, and insecure. 

<include src="TweetQuote" quoteText="Companies looking to save their employees time and provide peace of mind while improving individual and network-wide security can set up SSO with the help of Auth0."/>

## 4. Enterprise SSO Boosts Employee Productivity

Utilizing SSO for employees boosts productivity by reducing the time teams spend locked out of key tools while waiting for password resets and getting set up on new applications. 

Employees are also much more likely to know about and take advantage of resources and tools that make their jobs easier and faster and answer common user questions when those applications are linked to one hub, as SSO allows. 

## How Does a Company Set Up Enterprise SSO?

Companies looking to save their employees time and provide peace of mind while improving individual and network-wide security can [set up SSO with the help of Auth0](https://auth0.com/learn/how-to-implement-single-sign-on/).

Beyond the technical aspects of the switch, companies should keep in mind the following rollout tips to help their teams adjust to an SSO setup:

* Make sure to carry over login information so team members don’t have to reenter everything.
* Provide clear direction for users.
* Identify key applications that employees often use, including key software, cloud accounts, and social media. 


"ens"