LucasGomes

Product Marketing Manager

Lucas Gomes

Discover how AI in software development brings speed but also new security risks. Learn how to implement a 'verification' mindset with culture, processes, and tools to secure your AI-generated code.

From Vibe to Verification: Securing the Future of AI in Software Development

Brittany Roth

Senior Product Manager

Verify mobile driver’s licenses securely with Auth0’s new API—real-time, privacy-first identity checks made easy.

## Business Imperative

How important is it to keep your personal information out of the hands of others? To be more specific, what measures do you take to safeguard your driver’s license on a day-to-day basis? A driver’s license contains plenty of key information about you, and when it comes to eye color, height, or weight, it may seem innocuous, but malicious actors can use your birth date or home address for something far more dangerous.

With just a few pieces of information, someone could steal your identity, apply for credit cards or loans in your name, or even apply for state benefits. Consider the number of times you present your license for routine verification, such as checking into a hotel, renting a car, setting up an online bank account, or purchasing age-restricted products. 

Online services that use a driver’s license as a form of identity verification typically ask that you take photographs of both the front and back of your license and upload them. While there are many responsible identity verification vendors who protect this data well, not every app or website may be handling that sensitive data securely, and that could be a ripe target for hackers.

Mobile Driver’s Licenses (mDL) offer a secure alternative for verifying your identity online, where application developers can request only the bare minimum of information they need and where end users can explicitly consent to what information is being shared. At Auth0, we are exploring how to make it easier for developers to add mDL verification in applications. 

## What is a Mobile Driver’s License (mDL)?

An mDL is a digital driver’s license that conforms to a series of specifications and standards laid out by the [International Organization for Standardization](https://www.iso.org/about) (ISO). These documents dictate how issuers should implement a driver’s license in association with a mobile device, as well as how one device can verify the validity of an mDL on another device through various flows. To learn more about mobile driver’s licenses, check out [mdl.me](http://mdl.me/)!

In an mDL ecosystem, there are three to four main parties. The first party is the **holder/subject** which is the person to which the license is issued. The second party is the **issuer** of the credential. The issuer is the Department of Motor Vehicles for most US jurisdictions, but could be another government entity. The last required party is the **verifier**, the organization or person ensuring the credential is authentic.

One example is the California DMV (i.e., the issuer). The California DMV allows license holders (i.e., the holder/subject) to request an mDL via their website and can electronically issue an mDL to a digital wallet on the holders’ mobile phone. People can then present the mDL as a form of identification to businesses that accept it as a valid proof of identity. The business would either need to implement a verification system or use a third party to verify the authenticity of the presented credential by decrypting the signature with the Issuer’s public encryption key. 

This is where the potential fourth party can come in. To get the key, the issuer needs to host it somehow via public key infrastructure (PKI) like an **identifier registry**. They could do this on their website, or they could entrust another entity, like the [AAMVA Digital Trust Service](https://www.aamva.org/identity/mobile-driver-license-digital-trust-service), to do this for them. The verifier can retrieve their key directly from the issuer or from that trust service. This is where Auth0 comes in.

![mDL](https://images.ctfassets.net/23aumh6u8s0i/7hbuk0MaeHjt3rFTkfeHDl/61077606ef879ad46e9b1f09b18470c9/mdl1.jpg)

By leveraging mDLs, your business can offer a more secure, convenient, and privacy-focused way to verify customer information compared to traditional physical licenses, enable faster transactions, and reduce the risk of fraud. And your end-users will love the ease and convenience this integration provides. Utilizing their mDLs offers touchless transactions, selective disclosure of personal information, data protection, and so much more. 

## Verifying mDLs with Auth0

The movement towards digital credentials is growing. As mentioned before, the ISO standard is the underpinning of a growing ecosystem of interoperable services for digital driver’s license usage, and it has been implemented by [16 US states](https://www.aamva.org/jurisdiction-data-maps#anchorformdlmap) with another 16 states in the process of doing so. New states and government entities are conducting research and pilot programs; legislative agendas are including bills to create and issue mDLs, and key partners (e.g. [TSA](https://www.tsa.gov/digital-id/participating-states), liquor stores, and credit unions) are accepting these credentials. 

Auth0 is evolving our [Labs implementation of Verifiable Credentials](https://auth0.com/blog/what-is-mdl-how-to-start-using-them/) into the Mobile Driver’s License Verification Service that enables you to enrich user profiles with verified information during signup and login flows and perform ad-hoc verification checks. Auth0 functions as the verifier and validates the authenticity of a presented mDL and makes it easy for customers to get the requested information your application needs. mDL verification not only streamlines existing business processes but also allows users more control over their information.  

This Early Access release facilitates a number of remote presentation use cases where mDL verification  is required during an online transaction, including:

* Age Verification
* License and Driving Privileges Validation
* Prove your Identity: as mentioned above, many countries use driver’s licenses as proof of identity, and mDLs can be considered an equivalent to proving someone’s identity
* Improve business processes involving Know Your Customer (KYC) and Anti-Money Laundering (AML)

## How Do I Use Auth0’s mDL Solution?

The Early Access release of Auth0’s mDL Verification API will enable you to perform an ad-hoc mobile driver’s license verification either [within your existing application](https://auth0.com/docs/secure/mdl-verification/configure-mdl-verification-request) or within an existing authorization flow by utilizing the Verify Credentials [Forms widget](https://auth0.com/docs/customize/forms/nodes-and-components#widgets-components). This Early Access release only supports the [ISO/IEC TS 18013-7:2024](https://www.iso.org/standard/82772.html) standard and the REST API, also known as Web API, protocol.

The steps outlined in our documentation support this by allowing you to create a **Verification Template**, initiate a **Verification Presentation Request**, and check the request’s status for the desired claims. 

![Verification Template](https://images.ctfassets.net/23aumh6u8s0i/kPCsvULQPcz25oJ6pbTaK/53f7b0fa4dd5384aa7089da5f6f210c7/mdl2.jpg)

The **Verification Template** defines the fields you will ask the wallet to provide, such as family name, date of birth, or address. The template supports a specific list of [claims](https://auth0.com/docs/secure/mdl-verification/configure-mdl-verification-request#mdl-claims) as defined by the [ISO/IEC TS 18013-7:2024](https://www.iso.org/standard/82772.html) standard, the AAMVA VICAL as the sole Certificate Authority (CA), and credentials in the form of a mDoc.

The **Verification Presentation Request** is created by your application and initiates a verification flow by making a call to the Auth0 Verification API and returns a URL with the presentation request information for the user’s wallet to consume. Your application presents the URL - ideally in the form of a clickable link or a QR code - to the user to prompt them to share their credential with your application. 

Once the user is prompted to present their credential, your application polls the presentation requests status via our Verification API to determine if the user consented to share their credential. If the presentation is successful, the API will return the JSON from the presentation.

![Verification API](https://images.ctfassets.net/23aumh6u8s0i/61cQOMj4xui04lVtHlRbVh/fcebb2c7c9e05e3e00221bd3a0fe0c70/mdl3.jpg)

## How Do I Get Access to This Early Access Feature?

If you’re interested in using the mDL Verification API [Early Access feature](https://auth0.com/docs/troubleshoot/product-lifecycle/product-release-stages), **please fill out the [EA Terms and Conditions form](https://forms.gle/47YuFPkhh3RZVvt76)**. We are limiting the number of customers for whom this will be enabled and will reach out to you with more details. In the meantime, we encourage you to read our [documentation](https://auth0.com/docs/secure/mdl-verification) or try out our [Hands-On Lab](https://github.com/auth0/hol-mdl)! 

Relevant Documentation:

* [mDL Verifiable Digital Credentials API Documentation](https://auth0.com/docs/secure/mdl-verification/mdl-verification-api)
* [Additional mDL Blog Post](https://auth0.com/blog/what-is-mdl-how-to-start-using-them/)

Auth0’s Mobile Driver’s License Verification API

andrea-chiarelli

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

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

Principal Developer Advocate

Andrea Chiarelli

Checking your customers' email addresses is a basic rule for securely onboarding them in your B2B SaaS application. Learn how to do it in your Blazor Web App.

The very first thing to do when a user signs up for your application is to verify that they actually have access to the email address they provide. Although email verification is not the only security measure you should take to ensure the user's identity, this contributes to reducing spam and fraud. Auth0 provides [a few approaches to email verification](https://auth0.com/docs/manage-users/user-accounts/verify-emails), depending on your specific use case. In this article, you will learn how to leverage the built-in email verification process based on verification links to validate the email address provided by the user during their signup for a Blazor Web application.

## The Sample Application

A previous article showed [how to manage the onboarding of a customer](https://auth0.com/blog/enable-self-subscription-in-blazor-b2b-saas-application/) who signs up for a service offered by a B2B SaaS application implemented with Blazor. On that occasion, we did not consider verifying the client's email address as we wanted to focus mainly on self-registration and creating an Organization via code. Now, we will integrate that application by adding the verification step for the self-registering customer's email address.

Download the sample project to start with this command:

```shell
git clone --branch organization-via-code --single-branch https://github.com/andychiare/MyBlazorSaaS
```

Follow the attached README file instructions to register and configure the application with Auth0. If you don't have an Auth0 account, [you can sign up for free](https://a0.to/blog_signup).

## The Email Verification Process

By default, Auth0 sends a verification link to users when they sign up, but it's up to you to check if their email is verified before allowing them to access your application or perform specific actions.

In the context of your Blazor application, you will implement the following email verification process:

1. Once the customer signs up, Auth0 automatically sends an email to the user, and your application shows a message inviting the user to check their inbox.
2. The page showing the message provides a button to resend a new verification link in case the user didn't receive the first email.
3. If the user attempts to access any other application page, your app checks if the user's email has been verified before granting access.
4. Once the email is verified, the customer can create the Organization for their new subscription.

## Wait for Email Verification

The current customer onboarding flow implemented in your Blazor App allows users to create their Organizations as soon as they sign up. From a visual perspective, they pass from the signup form to the Organization creation form. You need to make sure the customer's email has been verified before allowing them to create their new Organization. Let's start by implementing a page that fulfills points 1. and 2. mentioned earlier.

### The verification waiting page

In the `MyBlazorSaaS/Components/Pages/Onboarding` folder, create a new file named `Verify.razor` and add the following code:

```csharp


@page "/Onboarding/Verify"
@rendermode InteractiveServer
@using Auth0.ManagementApi.Models
@using System.Security.Claims

@inject NavigationManager NavigationManager
@inject IAuth0Management auth0Management

<h1>Verify your email</h1>
<p>
 Please check your inbox for a verification link to continue creating your account.
</p>

<div>
  <button class="btn btn-primary" @onclick="ResendVerificationEmail">Resend Verification</button>
</div>

<div>
@Message
</div>

@code {
  [CascadingParameter]
  private Task<AuthenticationState>? authenticationState { get; set; }
  private string Message = "";

  private async Task ResendVerificationEmail()
  {
    if (authenticationState is not null)
    {
      var state = await authenticationState;
      var userId = state?.User?.FindFirst(c => c.Type == ClaimTypes.NameIdentifier)?.Value;

      try {
        var managementClient = await auth0Management.getClient();
        await managementClient.Jobs.SendVerificationEmailAsync(new VerifyEmailJobRequest() { UserId = userId });
        Message = "The verification e-mail has successfully been sent. Please check your inbox";
      } catch (Exception) {
        Message = "Failed to resend verification e-mail.";
      }      
    } else {
        NavigationManager.NavigateTo("/Onboarding/Signup");
    }
  }
}
```

This page will display a message that invites the user to check their inbox and offers a button to resend the verification link if needed. It will be rendered as shown in the following image:

![Verify email screen in your Blazor Web app](https://images.ctfassets.net/23aumh6u8s0i/72gdEry0IJzomAqT4P95gF/a099d96c8531367d3c8b567ac3853081/blazor-verify-email-screen.png)

Since the current onboarding flow shows the Organization creation page after the user signup, you need to change it. Open the `Program.cs` file in the `MyBlazorSaaS` folder and replace the line of code shown below:

```csharp
// MyBlazorSaaS/Program.cs

//...existing code...

app.MapGet("/account/signup", async (HttpContext httpContext, string login_hint) =>
{
  var authenticationProperties = new LoginAuthenticationPropertiesBuilder()
          //.WithRedirectUri("/onboarding/createOrganization") // 👈 old code
          .WithRedirectUri("/onboarding/verify")  // 👈 new code
          .WithParameter("screen_hint", "signup")
          .WithParameter("login_hint", login_hint)
          .Build();

  await httpContext.ChallengeAsync("OnboardingScheme", authenticationProperties);
});

//...existing code...
```

This ensures that the user will be redirected to the verification waiting page instead of the Organization creation page.

### Resend the verification link

The verification waiting page shows a "Resend Verification" button. Let's take a closer look at the code triggered by that button to learn how to resend the verification link:

```csharp

  
//...existing code...

@code {
  [CascadingParameter]
  private Task<AuthenticationState>? authenticationState { get; set; }
  private string Message = "";

  private async Task ResendVerificationEmail()
  {
    if (authenticationState is not null)
    {
      var state = await authenticationState;
      var userId = state?.User?.FindFirst(c => c.Type == ClaimTypes.NameIdentifier)?.Value;

      try {
        var managementClient = await auth0Management.getClient();
        await managementClient.Jobs.SendVerificationEmailAsync(new VerifyEmailJobRequest() { UserId = userId });
        Message = "The verification e-mail has successfully been sent. Please check your inbox";
      } catch (Exception) {
        Message = "Failed to resend verification e-mail.";
      }      
    } else {
        NavigationManager.NavigateTo("/Onboarding/Signup");
    }
  }
}
```

The `ResendVerificationEmail()` method gets the user ID from the authentication state, gets an instance of the management client, and uses the `SendVerificationEmailAsync()` method, passing an instance of `VerifyEmailJobRequest` with the user ID value. This method of the Management API client corresponds to calling [the email address verification endpoint](https://auth0.com/docs/api/management/v2/jobs/post-verification-email), which will generate a new ticket, include it in a verification link, and send it to the user via email.

## Customize the Email Verification Template

The default email message with the verification link sent to the user will look like the following:

![Email verification message](https://images.ctfassets.net/23aumh6u8s0i/6cP7skL9tqxBUnCAwC1cOa/0e31a5311fbd6506e75e010c091218a9/email-verification-message.png)

You can customize this message using your Auth0 dashboard. Go to the [Branding > Email Templates](https://manage.auth0.com/#/templates) page, select the *Verification Email (Link)* template, and apply the changes you want. You can customize the sender address, the subject, and the message body using [HTML and Liquid syntax](https://auth0.com/docs/customize/email/email-templates/use-liquid-syntax-in-email-templates). You can also customize other settings and use [common variables](https://auth0.com/docs/customize/email/email-templates#common-variables) to include some contextual values in your message. Read [this document](https://auth0.com/docs/customize/email/email-templates) to learn more about email template customization.

By default, nothing visible happens on your application when a user clicks the verification link. Auth0 will mark the user's email field as verified and show a page confirming that the email verification process was successful, as you can see in the following image:

![£mail address verified by Auth0](https://images.ctfassets.net/23aumh6u8s0i/4pgKFqZDlk93OnekyTrElS/1b3bf679d107f68279e8c4f711267836/email-address-verified.png)

However, in our self-subscription flow, we would like the user to be redirected to the next onboarding step after their email is verified, which is the organization creation screen. The email verification template provides a *Redirect To* field that allows you to specify the URL of the page you want the user to land after the email verification. You can parametrize the URL using one of the common variables mentioned above. Specifically, enter the following value in the *Redirect To* field and click the *Save* button:

```
{{ application.callback_domain }}/onboarding/createOrganization
```

That's all! Now, your user will be redirected to the Organization creation page after the email verification.

<include src="Auth0TemplatesForDotnetCTA" />

## Require Email Verification

One small piece is missing to complete the customer onboarding flow. You need to ensure that they cannot access the protected pages of your application if their email has not been verified yet. This means that when you check if the user is authenticated, you also need to consider checking that their email is verified too.

### A basic approach

You don't need to check if the user's email is verified when they access the `Home.razor` page, `Signup.razor`, and `Verify.razor` pages: the first two are public pages, and the third one is specifically designed for users who haven't verified their email yet.

You need to check the validity of the user's email on the `CreateOrganization.razor` page. To this purpose, apply the changes highlighted here on the `CreateOrganization.razor` page:

```csharp


//...existing code...

  protected override async Task OnInitializedAsync()
  {
    if (authenticationState is not null)
    {
      var state = await authenticationState;

      // 👇 new code
      var isEmailVerified = state.User?.FindFirst(c => c.Type == "email_verified")?.Value?.ToLowerInvariant() == "true";
      // ☝️ new code

      // 👇 changed code
      if (state.User?.Identity?.IsAuthenticated??false && isEmailVerified)
      // ☝️ changed code
      {
        Email = state.User?.FindFirst(c => c.Type == ClaimTypes.Email)?.Value??String.Empty;
        UserId = state.User?.FindFirst(c => c.Type == ClaimTypes.NameIdentifier)?.Value??String.Empty;
      } else {
        NavigationManager.NavigateTo("/Onboarding/Signup");
      }
    }
  }

//...existing code...
```

You can see that a new variable `isEmailVerified` has been introduced. This variable gets a boolean value coming from the value of the `email_verified` claim. You will use this variable as an additional condition to go ahead with the Organization creation step.

### A more structured approach

You need to apply the email verification check to most of the protected pages of your application. This depends on your application, of course. In our case, you should also apply the same check to the `Weather.razor` page on the server side and the `Counter.razor` and `FetchDat.razor` pages on the client side.

Applying the earlier approach would work, but it's ineffective in terms of code duplication and maintenance. You will use [ASP.NET Core policy-based authorization](https://learn.microsoft.com/en-us/aspnet/core/security/authorization/policies) instead.

First, open the `Program.cs` file in the `MyBlazorSaaS` folder and add the code highlighted below:

```csharp
// MyBlazorSaaS/Program.cs

//... existing code...

// 👇 new code
builder.Services
    .AddAuthorization(options => {
      options.AddPolicy("VerifiedEmail", policy =>
        policy.RequireAssertion(context =>
          context.User.HasClaim(claim =>
            ( claim.Type == "email_verified" &&
              claim.Value?.ToLowerInvariant() == "true")
          )
        )
      );
    });
// ☝️ new code

// Add services to the container.
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization();

//... existing code...
```

This code defines an authorization policy named `"VerifiedEmail"`. This policy checks if the current user has a claim `email_verified` set to `true`. This is the [standard claim](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) coming from the ID token issued by Auth0.

Now, let's create a page to which the user will be redirected when attempting to access a page without the required authorization. By default, Blazor redirects unauthorized users to an `Account/AccessDenied` page. So, create an `Account` folder in the `MyBlazorSaaS/Components/Pages` folder and add an `AccessDenied.razor` page with the following code:

```csharp

  
@page "/account/accessdenied"

<PageTitle>Access Denied</PageTitle>

<h2>You are not authorized to access this page</h2>

<p>@Reason</p>

@code {
  [CascadingParameter]
  private Task<AuthenticationState>? authenticationState { get; set; }
  private string Reason = "";

  protected override async Task OnInitializedAsync()
  {
    if (authenticationState is not null)
    {
      var state = await authenticationState;

      var isEmailVerified = state.User?.FindFirst(c => c.Type == "email_verified")?.Value?.ToLowerInvariant() == "true";

      if (state.User?.Identity?.IsAuthenticated??false && isEmailVerified)
      {
        Reason = "Your email is not verified yet!";
      }
    }
  }
}
```

This page shows a generic message to the unauthorized user and attempts to show a specific message about the actual reason. In particular, it checks if the user has the `email_verified` claim set to `true` and displays a message accordingly.

Finally, specify the policy `VerifiedEmail` in the `Authorize` attribute of your protected pages as shown below:

```csharp

  
@page "/weather"
// 👇 changed code
@attribute [Authorize(Policy = "VerifiedEmail")]
// ☝️ changed code
@attribute [StreamRendering]

//...existing code...
```

Apply this change to the `Counter.razor` and `FetchData.razor` pages in the `MyBlazorSaaS.Client/Pages` folder as well.

That's all! Your customer onboarding flow now includes the email verification step to mitigate the risks of spam and fraud.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

## Recap

Auth0 always sends an email verification message when a user signs up for your application. However, it's up to you to determine in which scenario to check whether the user's email has been verified.

In the example shown in this article, we took the case of onboarding a customer of a B2B SaaS application developed with Blazor and added the email verification step before allowing them to create a new Organization.

We also saw how to allow the resend of the verification email and prevent access to the application's protected pages when the user's email has not been verified yet.

You can find the final code of the project created during the article on [this GitHub repository](https://github.com/andychiare/MyBlazorSaaS/tree/email-verification).

Enforce Customer Email Verification in Your B2B Blazor Web App

sam-yapkowitz

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

Specialist Solutions Engineer

Sam Yapkowitz

Learn how to leverage Auth0 Forms to implement an invitation code workflow and improve the onboarding of your SaaS users.

Some applications require a user to be verified by an external service before they can log in to the system. This can be in the form of an invite code for a free trial in a SaaS application, address verification for a real estate listing website, or maybe something more robust for a healthcare or financial services application. 

Auth0 recently released [**Custom Prompts**](https://auth0.com/docs/customize/login-pages/universal-login/customize-signup-and-login-prompts) to help app builders collect more information about their users upon signup. These fields can be captured, and further processing can be done with the [**Pre Registration Action Flow**](https://auth0.com/docs/customize/actions/flows-and-triggers/pre-user-registration-flow). Capturing too much information (or capturing information conditionally) can have impacts on the end-user experience. Auth0 has recently released [**Forms**](https://auth0.com/docs/customize/forms), a new drag-and-drop editor for collecting user information, executing workflows, and orchestrating event data, which can be applied to these verification workflows as well. For this article, we will address the invite code workflow where users must verify their invitation code before being able to log in to the application. 

> Note: Custom Prompts and Forms work very nicely together as a user who completes a sign-up will then trigger a Login Flow where Forms can be launched.

In this blog post, we will leverage Auth0 Forms to collect this invite code and make an HTTP request to an externally hosted API to verify that the code + email combo is valid. This is one narrow use case, but the solution we are going to outline can handle any scenario where a user must provide input to be verified externally before granting access.

## Use Case

Let’s imagine you have a SaaS application that has an upcoming private Beta launch. You do not want to restrict users from signing up to your platform (so you can ingest them into your MarTech stack), but you do not want to allow them to officially log in to the platform unless they have been given access by a member of your team or an affiliate. You could solve this use case in many ways, and in this instance, we will solve this by having users provide an “Invite Code” to verify they have been given access by your backend application. You would send the user’s email alongside this code before approving their access to your private launch. You could collect this code during the signup phase using Auth0 Custom Prompts, but if they failed the validation, their account would not be created. Your goal is to create the accounts and then only gate access to the private beta behind this invite code.

## Prompting a User with a Form

We will use a [Post-Login Action](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow) to launch a user into this flow. They will automatically enter this flow after sign up and any time they come back to your application. This Action will check a flag on the user's profile to see if they have been previously verified or not.

```
exports.onExecutePostLogin = async (event, api) => {
  if (event.user.app_metadata.verified !== true) {
     const FORM_ID = 'ap_eJWCKKPimBy86AyTRsQikQ';
     api.prompt.render(FORM_ID);
  }
};
```

You can access the Forms in your Auth0 tenant by navigating to **Actions** → **Forms**, which will launch the editor in a new tab. Here is the visual editor for our specific Flow:

![High-Level Form Flow](https://images.ctfassets.net/23aumh6u8s0i/QXEH3o2wOejR8tqxbrbmv/336b75aecffe19167cae13a8e00e13a5/Uploaded_from_External_User_Verification_with_Forms)

<center> _High Level Form Flow_ </center> <br>


The User is prompted to enter their invite code into a text prompt, and then a flow is invoked. In the image below, you can see the flow diagram that checks if the code result has an error, and if so, we will show an error message; otherwise, the flow continues.

![Verification Flow](https://images.ctfassets.net/23aumh6u8s0i/3GAfnyuteWbHtDHNwROVCg/70627654f98b7ff16b88540c5412d75b/Uploaded_from_External_User_Verification_with_Forms)
<center> _Verification Flow_ </center> <br>

Here, we can see how to configure the HTTP request step to call your endpoint using the user’s email address and the collected invite code.

![HTTP Request Structure](https://images.ctfassets.net/23aumh6u8s0i/oh5XRmbnILUdjN9WLnKML/3407054954d3b100612f18529cea8110/Uploaded_from_External_User_Verification_with_Forms)
<center> _HTTP Request Structure_ </center> <br>

Based on the response, if the result comes back as true, the user will continue the flow, and if not they will be shown an error message which will prevent them from continuing until they input a correct value.

![Conditional Configuration](https://images.ctfassets.net/23aumh6u8s0i/3kzqJOpa2YLCkit2V3gG46/bd4fa60f27b24816454484671952ab49/Uploaded_from_External_User_Verification_with_Forms)
<center> _Conditional Configuration_ </center> <br>

Once the user enters a correct value, the flow exits and returns to the main path, where it will let them know that access has been granted and they can continue using the application. Our Action that launched the flow must have a continue section to resume the authentication transaction, and we will also save a flag on their profile to prevent them from having to enter this flow again.

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

```

![Success Prompt](https://images.ctfassets.net/23aumh6u8s0i/2YeCQcl1qBzU6IJQhgR2qr/51850095d1c6dda7f814fecc33ebd109/Uploaded_from_External_User_Verification_with_Forms)
<center> _Success Prompt_ </center> <br>

And here is the flow end-to-end for a new user who signs up and has a valid email + code combo.

<AmpContent>
<amp-youtube
    data-videoid="duROpUKZR04"
    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/duROpUKZR04' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>
<center> _End to End User Journey_ </center> <br> 

Here is the finished JSON for you to begin building your verification flow today! You can import this directly into your tenant by navigating to the Forms window → Create Form → Import It!

![Importing Existing Flow with JSON](https://images.ctfassets.net/23aumh6u8s0i/3vjVyJ42fDEDF3DC02nRKo/df261abe1b14ee4e6ac30852f80434ef/Uploaded_from_External_User_Verification_with_Forms)
<center> _Importing Existing Flow with JSON_ </center> <br>

```js
{
  "version": "3.0.0",
  "form": {
    "name": "Invite Code",
    "description": null,
    "messages": {
      "custom": {},
      "errors": {}
    },
    "languages": {
      "default": null,
      "primary": "en"
    },
    "translations": {},
    "start": {
      "nextNode": "step_Y3AO",
      "coordinates": {
        "x": 22,
        "y": 167
      },
      "hiddenFields": []
    },
    "nodes": [
      {
        "id": "step_Y3AO",
        "type": "STEP",
        "alias": "Collect Code",
        "config": {
          "nextNode": "flow_Cilk",
          "components": [
            {
              "id": "rich_text_sME2",
              "type": "RICH_TEXT",
              "config": {
                "content": "<h3><strong>Please enter your invite code.</strong></h3>"
              },
              "category": "BLOCK"
            },
            {
              "id": "invite_code",
              "hint": null,
              "type": "TEXT",
              "label": "Invite Code",
              "config": {
                "maxLength": null,
                "minLength": null,
                "multiline": false,
                "placeholder": "XXX-XXX",
                "defaultValue": null
              },
              "category": "FIELD",
              "required": true,
              "transient": false
            },
            {
              "id": "next_button_xlCe",
              "type": "NEXT_BUTTON",
              "config": {
                "text": "Continue"
              },
              "category": "BLOCK"
            }
          ]
        },
        "coordinates": {
          "x": 323,
          "y": -36
        }
      },
      {
        "id": "flow_Cilk",
        "type": "FLOW",
        "alias": "Verify Code",
        "config": {
          "flowId": "#FLOW-1#",
          "nextNode": "step_IifF"
        },
        "coordinates": {
          "x": 1051,
          "y": 139
        }
      },
      {
        "id": "step_IifF",
        "type": "STEP",
        "alias": "Verification Complete",
        "config": {
          "nextNode": "$ending",
          "components": [
            {
              "id": "rich_text_pMye",
              "type": "RICH_TEXT",
              "config": {
                "content": "<h3><strong>Welcome to Demo0, </strong></h3><h3><strong>Click Continue to get Started!</strong></h3>"
              },
              "category": "BLOCK"
            },
            {
              "id": "next_button_Z6Md",
              "type": "NEXT_BUTTON",
              "config": {
                "text": "Continue"
              },
              "category": "BLOCK"
            }
          ]
        },
        "coordinates": {
          "x": 1510,
          "y": -2
        }
      }
    ],
    "ending": {
      "content": null,
      "redirection": null,
      "callback": null,
      "afterSubmit": {
        "email": null,
        "flowId": null
      },
      "coordinates": {
        "x": 2194,
        "y": 110
      },
      "resumeFlow": true
    },
    "social": [],
    "style": {
      "css": null,
      "theme": "ROUND",
      "version": "MODERN"
    },
    "tags": []
  },
  "flows": {
    "#FLOW-1#": {
      "name": "Verify Invite Code",
      "description": null,
      "actions": [
        {
          "id": "http_request_verify_code",
          "type": "HTTP",
          "alias": "Verify Invite Code",
          "notes": null,
          "action": "SEND_REQUEST",
          "params": {
            "url": "https://edge.samyap.dev/api/verify-code",
            "body": {
              "email": "{{context.user.email}}",
              "invite_code": "{{fields.invite_code}}"
            },
            "type": "JSON",
            "basic": null,
            "method": "POST",
            "params": {},
            "headers": {},
            "acceptNOK": false,
            "connectionId": null
          },
          "allowFailure": false
        },
        {
          "id": "if_then_condition_q0Ym",
          "type": "FLOW",
          "alias": "Verify Code Result",
          "notes": null,
          "action": "BOOLEAN_CONDITION",
          "params": {
            "then": [],
            "evaluate": {
              "operands": [
                {
                  "operands": [
                    "{{ http_request_verify_code.body.result }}",
                    "true"
                  ],
                  "operator": "EQ"
                }
              ],
              "operator": "AND"
            },
            "otherwise": [
              {
                "id": "show_error_message_4rkM",
                "type": "FLOW",
                "alias": null,
                "notes": null,
                "action": "ERROR_MESSAGE",
                "params": {
                  "message": "Your code is invalid.  Please contact support for help"
                },
                "allowFailure": false
              }
            ]
          },
          "allowFailure": false
        }
      ],
      "triggers": {
        "webhook": {
          "secret": null,
          "enabled": false
        }
      },
      "synchronous": true,
      "security": {
        "rateLimits": []
      }
    }
  },
  "connections": {}
}

```

## Conclusion

Today you learned how to leverage Auth0 Forms to gather input from users to verify them with external systems using the no-code Forms and Flows editors. This capability can be extended to numerous applications such as Progressive Profiling, Consent Collection and many more.

At Auth0, we aim to provide a high-quality service and developer experience for our customers. The first interaction with your customers is oftentimes a login screen, so we understand how important it is for the user experience to be top-notch. With our hosted Universal Login, we take away the burden of deploying and maintaining these highly secure workflows. With the capabilities of our forms outlined in this post, we are able to help your teams iterate more quickly and customize the experience to be sticky for your brand and ultimately help your business grow.

External User Verification with Forms

Trish Burgess

Trish Burgess is co-founder and COO at IDPartner, a mission-driven startup built to establish global digital trust, fight fraud, and combat misinformation. She has spent the last 10 years building and launching global digital products in the FinTech, payments and identity spaces, including with household names such as Apple (Apple Pay and Apple Card) and Visa. Her accomplishments are driven by her boundless curiosity and her courage of conviction, which help her bring innovative perspectives and drive ideas into action. She holds an M.B.A from The Wharton School, University of Pennsylvania, and M.Sc.Eng. in Computer Networks by Universidad Politécnica de Madrid, Spain. She lives in the San Francisco Bay Area with her daughter and husband.


Co-founder and COO - IDPartner Systems Inc.

Non-documentary ID verification with international coverage of 8,000+ financial institutions and growing

Bank-based reusable identity provides a lower friction alternative to verification methods such as photo ID scans and out-of-wallet questions by delegating user authentication and identity to the end-user’s preferred bank. Bank-based ID is a tried and tested concept with a strong track record in countries like Sweden and Canada. Use cases include document signing, client portal registration and access, and employee onboarding.

Banks are ideal identity providers because they already have customer trust and high levels of engagement (often several times per week), along with extensive investments in Know-Your-Customer (KYC) required by regulators and Strong Customer Authentication (SCA). 

IDPartner connects with existing bank-based ID solutions where they are already available and is working with banks to bring these solutions to market in countries where no ready-made network exists.   

## IDPartner and Auth0 Provide a Best-in-Class Experience for Developers and End-Users Alike

IDPartner provides a social login-like service that simplifies onboarding, sign-in, and account recovery processes for businesses that require a higher level of trust and security wherever they are. [Our integration with Auth0](https://marketplace.auth0.com/integrations/idpartner) allows developers to integrate this capability almost seamlessly as part of their existing Auth0 deployment, helping increase conversions, engagement, and customer satisfaction. 

IDPartner gives financial institutions, developers, and end-users control over what and how identity data can be accessed — always with explicit user consent and in real time. There is no need to scan a passport or take a selfie. Instead, the user’s trusted financial institution will authenticate and identify users with bank-grade assurance. 

The user experience is straightforward. To verify identity for a site or app, the user clicks the ‘Choose your IDPartner’ button and selects their preferred financial institution or reusable identity credential. The user authenticates and consents to share personal information before being redirected back to the site.

IDPartner supports thousands of financial institutions in the US and UK, with additional countries about to come online. Additionally, anyone with a US driver's license or passport can verify their identity using Airside, the developer of a user-controlled digital identity app approved by TSA and used by the world’s largest airline.

**End-user experience**: [This video](https://www.youtube.com/watch?v=-TvwfcjlJDc&t=2s) demonstrates the end-user experience with IDPartner and Auth0. To directly experience IDPartner as an end-user, try our [X (Formerly Twitter) NotABot](https://notabot.idpartner.com/) and [LinkedIn NotABot](https://notabot-linkedin.idpartner.com/) experiences. We created NotABot to give end-users, developers, and investors an idea of end-user experience when using IDPartner. The apps allow you to create a Tweet or a LinkedIn Post demonstrating you are a verified human.

Here is an example of a Tweet verifying I am not a bot on X, starting with the beginning of the journey, which displays the required steps:

![NotABot](https://images.ctfassets.net/23aumh6u8s0i/77hOmsxSqZmThdcCrrrtSX/27937fdce4be113f24211d54b26d21dd/IDPartner01.png)

And here’s the end result — a retweet in my X feed of my type, Human, along with my verified avatar and my name:

![X Retweet](https://images.ctfassets.net/23aumh6u8s0i/2BYCNeS26lUODnsY3Fzd76/541f70c168c1b1fb7dd3169c733fa2d6/IDPartner02.png)

**Developer experience**: IDPartner has worked closely with Auth0 to ensure developers have an easy integration process. The [full set of instructions can be found here](https://marketplace.auth0.com/integrations/idpartner), with [additional information being available directly from the IDPartner documentation site](https://docs.idpartner.com/documentation/relying-party-user-guide). Do not hesitate to reach out to [support@idpartner.com](mailto:support@idpartner.com) if you have any questions as you learn more about IDPartner.  

## Some Key Use Cases Covered by IDPartner and Auth0

Here are some ways IDPartner and Auth0 can deliver better and more secure experiences for consumers:

* **Trust and safety:** Verify users on your platform so that your marketplace can thrive, free from bots and fraudsters. 
* **Secure customer portals:** Drive digital engagement by simplifying sign-up and secure access for your billing and communications channels.
* **Document signing:** Know that the person reading and signing your contract is really who they claim to be.
* **Background checks:** Quickly verify the identity and qualifications of job applicants, tenants, or other individuals. 

Generally speaking, IDPartner is a good fit for all use cases that require verified onboarding to avoid fake accounts, fraud and misinformation, strong user privacy and security, and bot detection.

## Customer Story: Avvanz, a Background Check Company Breaking Ground in the US

Avvanz is a multi-award winning HR tech and Fintech firm that enables fast, simple, and secure employee screening and onboarding and has added reusable bank-based digital identity as an additional way to further secure their processes and protect employers and employees alike.

Avvanz serves around two thousand companies across the globe, providing an ‘Amazon-like’ experience for their customers with more than 20 types of background checks across 150+ countries. But there is always a possible gap in ensuring that an individual is who they say they are, including possible fake credentials, inflated employment history, or even criminal/financial offenses. 

A robust digital identity verification system integrated with a well-tuned screening platform can further simplify and accelerate the process while ensuring compliance with data privacy and other regulatory requirements. This is where the IDPartner-Avvanz partnership becomes indispensable as it adds this essential digital identity verification to the background screening process.

[Here is a conversation between the two companies’ CEOs](https://www.youtube.com/watch?v=OdZLuKhu3tg). It will give you an idea of the benefits that IDPartner brings to Avvanz’s end-user experience. We would love to have a similar conversation with you, as our first customer spoke about their experience offering IDPartner via the integration with Auth0.

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

## Be Part of the Future of Identity, Join the Movement

The product is commercially available with integrations covering over 8,000 US and UK financial institutions. Still, it is just the first step in our journey to provide consumers with instant one-click access to any digital service requiring ID verification without affecting the ease of integration for developers.

As this model comes into place, the experience will be similar to the one in [this video](https://www.youtube.com/watch?v=xrzXzE3ia5U).

## How Do I Get Started with Auth0 and IDPartner?

All types of businesses can leverage IDPartner’s integration with Auth0 to enable bank-grade consumer authentication and identity verification. 

[Register now with this link to gain access to IDPartner’s experts](https://www.idpartner.com/lets-talk), who are ready to discuss your needs and support a successful implementation. Our team will help you integrate our solution seamlessly.


Sign in with Your Bank, How IDPartner and Auth0 Enable Bank-based ID

Vittorio

Vittorio Bertocci is a Principal Architect for Auth0. Before Auth0, he had a lengthy career with Microsoft, where Vittorio worked with Fortune 100 and Global 100 companies, including working on Microsoft’s Azure Active Directory team as principal program manager focusing on the developer experience. He contributed to the inception and launch of Microsoft's claims-based platform components (Windows Identity Foundation and ADFS, ADAL and MSAL SDKs, ASP.NET middleware). Vittorio is a well known speaker, educator and published author.

Principal Architect

Vittorio Bertocci

The differences between on-device and 1:N biometric verification and what they mean for your privacy needs

**TL;DR:** although users perform the same ceremony whenever responding to a biometric prompt, the way the underlying system uses the results can make a world of difference in terms of privacy and security. The key questions users need to ask themselves: does my biometric info ever leave the collection device?

Our daily life is increasingly punctuated by moments in which some machine probes some part of our body before granting us access to something. Your iPhone wants to take a good look at your face before letting you in, and so does your Windows laptop; Android devices and MacBooks might want a little caress with your thumb before unlocking themselves; while wheeling your cabin luggage thru an airport, you might exchange a snap of your iris for faster security lines, biometric gates might let you in a country faster if only you let them compare your passport with your facial features, and some airlines will let you board with nothing more than a smile for their camera. Even doing groceries nowadays might require a piece of you, as the palm readers in Amazon’s owned Whole Foods shops don’t seek to tell your fortune (to you, anyway) but to authenticate you and connect to your customer persona.

All those examples might look more or less the same; save the particular part of your anatomy each machine is into. In fact, those examples can be divided into two crucial categories: the ones where your biometric data is validated by the same device performing the collection and the ones where your biometric data are sent to a centralized database and verified against a copy of your biometric template held there.

This distinction is very important, as it determines what can be achieved with the strategy — and at what cost.

## On-Device Biometric Authentication

When you unlock your phone or laptop using your face or your fingerprints, you are usually providing data for a local check.

This is why you always need to enroll anew whenever you get a new device! When the iPhone asks you to do that funny neck stretching exercise in front of the camera to initialize FaceID, or your Mac asks you to touch the fingerprint sensor several times to set up TouchID, it is acquiring what in jargon is known as a biometric template: a mathematical representation of some salient landmark points that make your face or fingerprint unique, and that are easy to look for and compare during future scans. Crucially, you enroll when the device is in an unlocked state: and once the biometric data is saved in the local device (and the local device _only_), from now on, you can perform a face or fingerprint to prove that _you are the same user that unlocked device at enrollment time_. There is no magical property that proves that it is really you, as in your legal persona as a citizen, etc. — it’s just a convenient way to unlock your device without entering a PIN. Want proof? Enroll one of your spouse’s fingers in TouchID, and they will be able to unlock the device just as well as you do.

### Public Key Cryptography, FIDO, and Stationery

What about things like FIDO and WebAuthn? What happens when you protect a website using FIDO credentials and platform authenticators in particular? Pretty much the same thing, though the operation being gated by the biometric prompt is a bit different.

If you want a refresher on how FIDO authentication works, you can check [the Identity, Unlocked episode with John Bradley about it](https://twitter.com/vibronet/status/1325912224460726272?s=20). But in a nutshell: FIDO2 authentication relies on public key cryptography. When using passwords, a website saves a shared secret and then checks whether the user knows that secret at sign-in time. When using public key cryptography, conversely, the website asks the user to perform something that no one else can do.

Imagine you have a rubber stamp so intricate that it’s impossible to reproduce just by looking at the imprints it produces. Someone wants to start corresponding with you via snail mail, and they want to make sure all the future letters you send are truly from you. To do so, they start by handing you a piece of paper with some random text they generated for the occasion. You stamp it with your magic stamp and hand it back to them; they place it in safe storage with your name on it, and your enrollment is complete.

Next time you want to send them a letter, they send you another piece of paper with more random words they generated specifically for this. You use your stamp to imprint the stamped sign on the new random words and send it back. That proves to them that it’s really you sending this letter because no one else has access to your magic stamp… and it proves that the letter is really for you because the stamp has been applied to the random words you generated for this exchange.

How is this better than passwords? Well, the rubber stamp never leaves your home: it cannot be stolen in transit, and it cannot be reproduced. You cannot be tricked into putting it in an envelope and sending it to some scammer, as is the case with passwords. You just _use_ the rubber stamp, and what’s evaluated by the recipient is your ability to do so (hence, your possession of it). 

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


Public key cryptography works more or less like that. There is a private key that never leaves the device of origin (with one notable exception, see below), and that can be used to perform a so-called digital signature on data- a mathematical operation that generates a unique string representing the combination of the private key and signed text. And there is a public key, which can be used to verify that the signature was actually performed with its corresponding private key and that the signed data haven’t been tampered with. Websites can sign up users by sending some random data (the challenge, in WebAuthn terms) and receive it back signed, alongside the public key corresponding to the private key performing the signature. If the signature match, the website can save the public key (alongside some identifiers, like a username) in the user record. Subsequent sign-ins will do the same dance, validating that the user has access to the private key corresponding to the public key on record. Way better than passwords, for many reasons, but I won’t dwell on them here — see this [whitepaper](https://www.okta.com/sites/default/files/pdf/How_WebAuthn_Works_0.pdf) for a good WebAuthn primer.

Where does biometrics come into play? Well, biometric checks are typically used to unlock access to the private key required to perform the signature during sign-up (during which it might be created, actually) and sign-in. This is important: from the website perspective, what’s really being used for authentication is _something you have_, the private key you are proving possession of by performing a signature. The fact that the local device used _something you are_, a different factor, cannot be directly verified by the website. In fact, it is not uncommon for failed biometric checks (hello, face masks during the first months of Covid lockdowns) to fall back on PIN, something you know, without substantially changing the authentication scheme described above.

To reprise the rubber stamp metaphor: Imagine you keep your rubber stamp in a fireproof box locked with a fingerprint-operated padlock. How you unlock the fireproof box doesn’t change the stamp you’ll affix on the letter for your correspondent, nor will your correspondent know where you keep your rubber stamp or how you access it. It’s not entirely accurate in all cases (see authenticator’s attestations) but close enough for our purposes here.

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


The fact that in this approach, your biometric template never leaves the device is great from the privacy perspective. Bad actors acquiring your biometric template would be a disaster: they could start to track you, impersonate you… and there’s no way of revoking your biometric data.

End users are usually blissfully unaware of all this. Their experience is consistent with using a “something you are” factor; hence they might expect behaviors in line with other biometric prompt solutions relying on centralized databases — for example, the ability to use one’s biometric to authenticate through a kiosk in a location they never visited before. They don’t realize that the “something you are” factor was used just to unlock a “something you have” factor (the key residing on the local device), nor the different implications in terms of privacy & security this entails.

> Note: you might have heard that with passkeys, your credentials are backed up to the cloud, synced, and available on all your connected devices. You might even have heard it [from yours truly](https://auth0.com/blog/our-take-on-passkeys/)! The important thing to realize is that although keys are backed up, biometric info stays on the local device: that's how the same passkey is unlocked via FaceID on my iPhone and via TouchID on my Mac. 

## Remote Biometric Check (1:N verification)

The other use of biometrics is probably the one that best aligns with intuition, as in the one tied to your “true” identity (whatever that really means). You show up in person somewhere, your identity is verified, and your biometric data is acquired - often with devices and processes more elaborated than what you experience with consumer-grade devices. This will typically happen with government institutions. Green card holders, passport holders, and known travelers all experienced their fingerprints (all of them!), iris, and face images being acquired. Visitors to foreign countries can typically expect their pictures and fingerprints taken.

The resulting data ends up in government databases (the Department of Homeland Security in the USA maintains IDENT — a database of biometric data of every international traveler entering the United States) and government-issued artifacts like biometric passports. This makes it possible to raise the assurance levels of identification while giving users levels of convenience never achieved before. For example, participants in the Global Entry program can now re-enter the USA after an international trip by barely slowing down in front of a kiosk that uses facial recognition to recognize incoming passengers and a border officer that consults a gallery of all expected passengers. That certainly beats that one time a few years ago when I had to wait two hours in line at passport control because I was queued right behind a hundred Chinese nationals, and the border only had one interpreter available!

Convenience, however, has a flip side. Your biometric template cannot be revoked, and if it were ever to be leaked to bad actors, it could lead to all sorts of grave abuses- from tracking your presence anywhere to impersonating you.

The fact that custodians of the data are government agencies, with big budgets devoted to security and responsibilities toward citizens, should inspire a modicum of trust — but supply chains are long, and accidents are bound to occasionally happen (as was the case in [a biometric data leak at the Custom and Border Protection agency four years ago](https://techcrunch.com/2019/06/10/cbp-data-breach/)).

The thing is — when it comes to the government, we often have little choice. Some initiatives, like the recent [experimental use of facial recognition by TSA in airports](https://www.tsa.gov/biometrics-technology/evaluating-facial-identification-technology) for speeding up boarding operations, do offer an opt-out option (and are [sparkling protests](https://www.merkley.senate.gov/imo/media/doc/tsa_facial_recognition_technology_letter.pdf)). However if you want to enter the USA, or work here, you simply cannot get out of having your biometrics taken. 

Private businesses, however, are a different matter. Subscribing to [CLEAR](https://www.clearme.com/), the service that allows you to enter airport security lines and events venues without exhibiting documents just by having your irises or fingerprints scanned, is an entirely voluntary action. The same goes for [Amazon One](https://one.amazon.com/), the palm-based identification system that lets you pay for your groceries just by hovering your palm over a reader… thanks to your biometric template data being stored on the Amazon cloud. Those services can be extremely convenient… but [no one is invulnerable to data breaches](https://mashable.com/article/amazon-customer-data-leak), and in the absence of laws regulating how biometric data should be stored and used by private companies (or the consequences of mismanagement spelled out), it’s a risk.

## Now What?

There you have it. Now you know that not every biometric prompt is created equal. You know why iPhone asks you to re-enroll to FaceID and TouchID every time you get a new device (because the biometric data never leaves the device, which is good for privacy). You know that FIDO2 authenticators when they use biometrics, rely on the same mechanism. You even got a primer on digital signatures!

What should you do with the knowledge that some services store biometric info in centralized locations, off the device, and associated risks? Well, that is truly up to your personal utility vs. risk function. In my case, I do subscribe to CLEAR as I travel really a lot, and I find it very convenient... but I don’t (yet?) do groceries nearly enough to overcome the concerns I have about storing my palm in the cloud. 

Finally, putting my architect hat on, I want to close by stressing that we strive to offer [privacy standards that meet our customer's needs](https://www.okta.com/blog/2023/01/why-okta-is-privacy-forward/) by default in our services, and in the services, you can build for your customers on our platform. If you have questions, feel free to contact me below or on Twitter. 

A Tale of Two Biometrics Styles

Viktor Nyitray

Viktor is a CEO of Ageware, software designed for fast and easy age verification online and offline. He is responsible for day-to-day leadership and decision making at the company, as well as promotion of automated age verification in the Czech Republic rest of EMEA.

CEO of Ageware

Use selfies and biometrics to secure age verification for websites and apps

Most consumers have visited apps requiring a rudimentary verification of their age. After all, the digital world is full of content that isn’t suitable for children. But just entering a birthdate or answering a basic yes or no to questions about being of legal age isn’t sufficient for verifying a user’s age. Changes in legislation aimed at keeping children safe from inappropriate content and complying with data-privacy regulations mean that companies bear a growing responsibility for ensuring that their users really are the age they claim to be. 

To help keep kids safe while providing minimally intrusive ease of access for legitimate users and customers of legal age, websites, and apps need a kind of frictionless gatekeeping in the form of biometric age verification. How can companies adopt practices that help comply with evolving regulations and help fulfill their legal obligations and, at the same time, ensure that they don’t overburden their developers with creating functionality that, while necessary, isn’t core to their business? 

## Online Age Verification: Don’t Just Trust – Verify

As a result of a number of laws and regulations, certain online services must verify users’ age when visiting their websites before granting access to the site and its information. These kinds of services include everything from the viewing and purchasing of alcohol to online gambling and betting to more regulated services, such as online banking. Despite the growing demand (and requirement) for online age verification, the solutions available for age verification are not as robust as needed to satisfy increasingly stringent regulations on proof of identity and age. At the same time, voices opposed to potentially intrusive age-verification software claim that these solutions threaten personal privacy and user identity. 

With this in mind, Ageware is a biometric age-verification software solution designed for privacy. Ageware strikes a balance between shielding companies and consumers from the legal consequences of not safeguarding age-restricted material and protecting both children _and_ user privacy. 

## How Ageware Age Verification Works

Ageware’s proprietary AI depends on the humble selfie. Trained by more than one million facial images from people all over the world, the Ageware AI has been taught to be able to determine a user’s age, and that is where the verification process for the majority of users ends. A combination of this advanced AI, biometric security software, and facial recognition algorithms work together to verify a user’s age with nothing more than a selfie and Ageware technology. For those for whom the simple selfie isn’t sufficient, Ageware asks users to take a picture of their ID as well. The Ageware platform is set up to process over 140 types of national identification documents as well as all machine-readable passports. 

This does not happen all that frequently, but when it does, it is due to the fact that Ageware has implemented a five-year security buffer due to the average error in age estimation of 2.7 years. This means that sometimes, especially with young people (18-23), the extra verification step is really needed. The option to prove one’s age using the ID verification step is also possible if, for whatever reason, Ageware does not think the user is actually taking a selfie of a genuine face. Ageware will prompt the user to supply a form of ID so that the user will not be blocked from the page if not justified. 

How does it work? First, the user is asked to take a selfie. The AI then estimates the user’s age from the selfie and checks for “liveness”. If necessary, Ageware escalates the verification to the next step, as described above, checking additional forms of ID. The Ageware Action can be triggered once at user registration but also each time a user logs in using Okta Customer Identity Cloud. 

## Privacy-Friendly Age Verification on Demand

Ageware offers: 

* Assistance with GDPR compliance obligations and full data storage within the EU
* No storage of pictures of additional ID documents once the user is verified
* Fully proprietary algorithms, completely managed by the Ageware team
* Peace of mind for businesses subject to potential fines from regulators if age checks aren’t performed 

## Start Using Simple Selfies to Verify User Ages with Ageware

Ageware can be used by any business or service that needs to check user ages or the real identities of their clients or users. 

Check out the Ageware [integration in the Marketplace](https://marketplace.auth0.com/integrations/ageware).

Ageware App Now Available on Marketplace

diego-parrilla

Diego is a Security Software Architect at the Office of the CTO team (OCTO). It has been a long journey since his dad bought his first eight-bit computer in the early 80s. He joined Auth0 after the acquisition of Apility.io in October 2019, and now he is looking for new ways to improve how Auth0 detects and stops potential threats. When he's not working, Diego loves participating in open source communities, riding his mountain bike, listen 80s and 90s hard rock music, watching NBA games, and traveling with his wife and teenage daughter.

Security Software Architect at OCTO

Diego Parrilla

Assess your users' reputation using the Auth0 Signals Email Verification API.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Important Information</strong><br> 
  <b>The Apility.io and Signals web properties and public APIs are no longer available. For more details, please refer to this <a href="https://auth0.com/blog/auth0-sunsets-signals/">blog post</a>.</b><br> 
</div>

**TL;DR:** How often do you feel that there is something wrong with the email address of that new customer? The username and the domain look suspicious. With the new risk assessment features of the Email Verification API, you can get enough insights to make informed decisions about your users in real-time.

## The Problem

There is a rising wave of abusers that sign up to services offering freemium or free-trial. Typically they want to exploit the resource you offer (compute, streaming, APIs, etc). The tension lies between converting more vs stopping these abusers.

One way to stop them, without introducing much friction, is to verify if their email is legitimate (without sending all users an email). This is what the Auth0 Signals Email Verification API provides.

## What is the Auth0 Signals API?

The [Auth0 Signals API](https://auth0.com/signals) is a standalone free service for the community. The service consists of an HTTP API that allows you to detect the reputation of an Email address or the IP address. The API checks the Email and/or IP address against several public denylists to evaluate its reputation. It responds with data about the originator and a score indicating the reliability level of the Email or IP address. Having this information enables you to detect malicious activities proactively.

## When to use Email Verification signal?

The Email Verification signal provides a continually curated and accurate Email reputation data. It takes the hard work out of consuming Open-Source Intelligence (OSINT) by curating, parsing, and normalizing numerous denylists. Auth0 uses this data to protect its own service.

There are two main use cases for this API:

- **Real-time risk assessment:** Developers can embed into their code requests to the API and detect malicious activity proactively, not reactively. For example, automatically checking Email reputation during the authentication flow. With a disclaimer that it’s free, no SLA and rate limits are in place.
- **Incident response and forensics:** When security experts identify an incident, they begin investigation and response processes to determine if a genuine security incident occurred, its scope, and the best way to remediate the threat. The API and some assessment tools will become part of the Security professionals swiss army knife.

Auth0 Email verification signal enables all users to obtain a score that indicates the risk level of an analyzed Email address. The overall process involves an in-depth analysis of each email,  combining several validation techniques based on custom-built algorithms scoring the legitimacy of an email. Clean and valid email addresses will have a neutral score. Suspicious addresses will have a negative rating: the more negative the score, the more probability of being an address with a low reputation.

## How does the Email Verification API work?

First [sign up in Auth0 Signals and get an API Key](https://auth0.com/signals). If you have any doubt, you can [read this short tutorial detailing all the steps](https://community.auth0.com/t/how-to-obtain-an-auth0-signals-api-key/42048)
The [API documentation in the Auth0 Signals site](https://auth0.com/signals/docs/#email-verification) explains how to use the service with or without an API Key. For example, let’s get the score for the email ```test@example.com```. We will assume that ```example.com``` is a very well known [Disposable Email Address](https://en.wikipedia.org/wiki/Disposable_email_address) provider, so it should have a negative rating. To test the API, we will use the command ```curl```. The requests need two parameters: the Auth0 Signals API Key and the Email to analyze. It’s also possible to add parameters in the query string to tweak how the service works.

```shell
$ curl -i -H "Accept: application/json" -H "X-Auth-Token: API_KEY" -X GET "https://signals.api.auth0.com/bademail/test@example.com"
```

or

```shell
$ curl -H "Accept: application/json" -X GET "https://signals.api.auth0.com/bademail/test@example.com?token=API_KEY"
```

the JSON response will be:

```
{
   "response":{
      ...
      "score":-3,
      "email_address":"test@example.com"
   },
   "type":"bademail"
}
```

We have trimmed the JSON object of the response to make this post more readable, but you can [read the full JSON response in the documentation](https://auth0.com/signals/docs/#email). The global score is ```-3```. That’s a bad score. Let’s see how the scoring formula works in detail.

## The scoring formula explained

The global score or confidence score is the sum after analyzing different parameters of the Email address. These are the possible values:

- **0:** Auth0 Signals is neutral about the Email address given. It means the service cannot find the Email address in any given individual service and cannot classify the Email as risky.
- **-1:** Auth0 Signals has detected the Email address in one of the checks.
- **lower than -1:** Auth0 Signals has detected the Email address in two or more checks. The lower the score, the riskier the Email.

The possible values range between -3 and 0, and there are no positive values because the algorithm does not calculate confidence levels, but rather levels of DISTRUST.

The email verification process analyzes different elements of an email address assigning a neutral or negative score for each part:

- **Address:** If any of these checks fail, the score of this test is -1.
  - **Address Syntax:** This check removes improperly formatted email addresses. It must adhere to [IETF standards](https://tools.ietf.org/html/rfc2822).
  - **Role-Based Account:** Email sent to role-based such as postmaster@, info@, sales@, admin@, etc. can negatively impact the deliverability, and even some ISPs will block them. This process detects and flags such addresses.
- **Domain:** test for the MX domains, and NS domains. If any of these checks fail, the score of this test is -1.
  - **Domain banned:** The process searches the domain in different deny lists. To be a clean domain, it must not appear in any of them.
  - **MX domain banned:** It searches the MX domains in different deny lists too. Clean MX domains must not appear in any of them.
  - **NS domain banned:** It searches the NS domains in different deny lists too. Spammers use very well-known suspicious Nameservers, and we also can block them.
- **Free Email Service:** detects emails hosted by Free Email Services like (Google, Yahoo, Hotmail/Microsoft, etc.). Since this is a very aggressive option, the algorithm does not compute the result as negative, but it flags the email to help users to make a decision.
- **Disposable Email Address:** Throwaway/disposable email addresses, or “junk collector” email addresses" are detected and processed appropriately. It is a widespread threat indicator of bad actors using them to bypass signup forms or login forms that require a valid email address. The score for this test is -1.
- **Banned Email Address:** If the Email address belongs to some of our Email Abuse deny lists, then the score for this test is -1.
- **SMTP Verification:** Performs deep-level extended SMTP verifications on the email address. The process pings the addresses for mailbox existence without sending an actual email to the inbox. It will also check the validity of the MX records and will test if the server implements a catch-all policy. The score for this test is -1 for any of them.
- **Lookup IP in OSINT deny lists:** The algorithms check the email addresses and IP addresses against known DNSBLs and RBL to trap spam networks. The score for this test is -1 for any of them.

## Using the Email Verification API in your application

It’s perfectly fine to use the API in your own services. If you are a developer, here goes some hints to get the most of the Email verification service:

- You can verify 4,000 emails in a 24-hour range. Use your quota wisely.
- The global score or confidence score should be considered an important signal. Still, we strongly recommend reviewing the different individual scores as you process production traffic to better understand the email address's reputation for your use case. Our general-purpose scoring formula can be too generic for some use cases.   
- You can ignore the global score and focus on individual tests. For example: if you want to detect emails from Free Email providers, you can check the ```freemail``` object in the JSON and ignore the rest of the response.
- Have a look at the [Querystring parameters](https://auth0.com/signals/docs/#check-if-an-email-scores-a-negative-or-neutral-score). This can help you adjust the results to your specific needs. 
- Auth0 Signals is free for all and offered 'as is' with no SLA. This means you should make your code resilient in case the API stops responding.
- For production-grade usage use the Auth0 service that includes Signals built-in. 

## The Email Verification tools: Slack Bot
The [Signals Slack Bot](https://auth0.com/signals/ip#signalsbot-slack-landing) is a new tool built on top of the Signals API for Cybersecurity Professionals, SecOps, analysts, and forensics teams willing to use the bot to get the most of the API without having to write a single line of code. The tool uses the Email Verification and IP Reputation APIs combined with some interactive features to drill down on the data. The installation is very straightforward following the [instructions on our community site](https://community.auth0.com/t/auth0-signals-slack-bot/45216).

![The installation page of the SignalsBot App](https://images.ctfassets.net/23aumh6u8s0i/1MhWa1qfDbbAaxaSMG1xcc/b5d1cb6ebfb99b28824293dee6c4ac3f/signals-installation-page)

Once the Slack Bot is installed and configured, any member of the Slack workspace can go to the SignalsBot in the Apps section and click on the Messages tab at the right-hand side of Home and execute the ```email```(lowercase) command with the email to analyze:

![Auth0 Signals Email verification score](https://images.ctfassets.net/23aumh6u8s0i/4jQkOPsEDZy6FopipmFhQj/38d05be24c61028cfcc372cd68875954/signals-email-score)

## Summary

The Email Verification API is a powerful tool to prevent and mitigate sign-up and sign-in abuse at different stages. If the API integrates with the existing authentication workflow it can help to detect potential low-quality users. When the API or the tools are in the hands of Security professionals it can help SecOps teams perform threat intelligence duties more effectively. Be sure to [check out the documentation](https://auth0.com/signals/docs) for more details.

## Join the community!

[Check out the Auth0 Signals community](https://community.auth0.com/c/auth0-signals/78). Go there to interact with other security professionals, get help on incident response actions, or learn more about digital abuse.


Introducing Auth0 Signals Email Verification API

A New Way of Decoding Your Identity Solutions

_**TL;DR:** Auth0 is releasing Auth0 Explorer, an experimental tool that helps you to visualize your Auth0 tenant’s overall structure, offering an innovative user interface to zoom out to the big picture or dive into the details of individual applications settings._

At Auth0 we are obsessed with making identity simple for application builders. In our quest to help our customers and the community at large to better navigate the complexity of identity development, we constantly strive to improve existing technologies. Sometimes, however, we tackle problems that call for more radical innovation and bolder experimentation.

Take the “many moving parts” problem. In a nutshell: any identity solution of non-trivial scope is usually composed by a large number of components, all interacting in non-obvious ways and contributing to the solution’s emergent behavior. Your solution will have multiple identity sources, many clients, and API tangled in complex call graphs, custom logic running here and there, authentication and authorization policies scattered across your topology, and so on. Even if you are an identity expert, well-versed in protocols and concepts, you still need to understand the details of that particular solution to work with it.
What is the state of the art in our industry to help you navigate that particular flavor of complexity? The available tools haven’t changed for quite some time. Every vendor will offer a management portal of some kind, where you can list artifacts of a given type (applications, trusted identity providers, etc) and dig into the details of individual items, but it’s usually very hard to _see_ the relationships between entities and predict what the overall behavior will be. You can see the trees but not the forest. Using APIs and CLIs to inspect your solution doesn’t yield much better results.

While brainstorming how we could help, we informally observed what coping strategies are most commonly pursued by professionals and newbies alike. And what did we find? Nearly everyone makes a _drawing_ of their solution to make sense of it. Scribbles on a whiteboard or a notepad, diagrams in official specs, no matter the format, pictures of the solution components and the relationships between them play a key role in planning, development, and management - and often are the centerpiece of discussions and decision making.

We already took steps to help crafting diagrams effectively, from providing the raw material (see the [identicons clipart collection](https://identicons.dev/) for identity concepts) to publishing templates and examples (like the [Auth0 Engine diagram](https://cdn.auth0.com/blog/auth0-raises-100m-to-fuel-the-growth/inside-the-auth0-engine-high-res.jpg)), but we felt we could do more. We realized that Auth0 tenants already hold all the information necessary to draw a complete picture of your solution, and more… so why should you reverse engineer a diagram when we can generate one for you? That’s how the idea of **Auth0 Explorer** was born.

## Navigating your Identity Solution

Auth0 Explorer is an experimental tool that generates a visual representation of your Auth0 tenant on the fly, arranging in a clear layout all major artifacts (connections, apps, API), representing relationships as a graph, and allowing you to examine every element in greater detail.

There’s no point in describing Auth0 Explorer any further, the best way to give you an idea is to simply show it in action! Just navigate to [https://explorer.auth0.com/](https://explorer.auth0.com/). You’ll be presented with an essential landing page.

![Auth0 Explorer landing page](https://images.ctfassets.net/23aumh6u8s0i/1ftGKX4YtoYkKfMYGFPTqL/c654564443aedce4833629bfeef41b06/landing-page)

Hit Login and sign in with your Auth0 account. You’ll be presented with a consent page:

![Auth0 Explorer consent page](https://images.ctfassets.net/23aumh6u8s0i/5WzJEizvZlugj1Os9qVlpM/786ade19bac85963e8ed5a0d080eb1ea/consent)

The drop-down offers you the chance to select what tenant you want to explore among the ones associated with your user account.

Auth0 Explorer uses the Auth0 Management API, just like any app you might develop by yourself on top of the Auth0 platform. As such, it needs to explicitly ask for consent for reading all the tenant entities it will display. Hit ‘Accept,’ and you’ll land on Auth0 Explorer’s main page.

## Grasping the Big Picture

<include src="Vidyard" id="CjEPUTj6wNC67PzzzaA4jE" />
<br><br>

What you will see is a full diagram of the Auth0 tenant I selected. The top row contains all the connections configured for the tenant. The middle row lists all the applications registered, conveniently color coded to clarify the client type (web app, native client, etc). The bottom row lists all the tenant’s API, including Auth0’s built in ones.

Not only you can see all the main actors in a single representation: if you hover on the individual connection icons, you’ll immediately see what applications are configured to accept identities from them! In the video above you can immediately see what providers are used by many apps, which ones are configured but not used at all, and everything in between.

If you hover on an application icon, you’ll navigate the graph in the opposite direction, making it immediately obvious what identities are accepted for a given application – and what API that application is configured to invoke. That’s pretty neat! The structure of your tenant is laid bare in front of you.

Here’s another example of the potential of Auth0 Explorer for making sense of your solutions. Have you ever tried to compare tenants, or to find out whether your dashboard is open on the tenant you need to work on. Sure, there’s the name visible on the top right…but compare it with the immediate, intuitive insight you get when you visualize two different tenants in two different instances of Auth0 Explorer:

![Visualizing two tenants in Auth0 Explorer](https://images.ctfassets.net/23aumh6u8s0i/5Nh0wp0aRmB3IsPVNxNQyB/139c50ad675bb967f4698fd86e50ee9b/visualizing-2-tenants)

Telling which tenant is your production environment and which one is just being used for experiments becomes blindingly obvious.

Here’s another example of “big picture” insight that becomes possible with Auth0 Explorer. Take a look at the following video.

<include src="Vidyard" id="oZ1AAT8w48HQNt8SroB2eQ" />
<br><br>

In this particular case, I am turning on the traffic layer – which has the effect of varying the thickness of the line connecting an app to an identity provider according to the amount of traffic that IdP generates for the application, as recorded in Auth0 logs. Here you can clearly see that the lion’s share for this app comes from GitHub, followed by Facebook.

Remember, we are still at the experimental stage with Auth0 Explorer: this is just one example of the kind of insight we could offer you in this view, and we are looking forward to your feedback on both visualization style and data layers you’d like to see available here.

## Examining Individual Entities

Once you’ve found your bearings within the tenant, Auth0 Explorer helps you to dig into the details of any of the artifacts displayed in the diagram. The following video shows you a concrete example of that.

<include src="Vidyard" id="aXEGZWz9ez3H1325MxoZpq" />
<br><br>

Whenever you click on an icon, Auth0 Explorer uses the pane on the right to display the attributes of the corresponding entity. In the video above I select the Google connection, a custom DB connection and one SPA – and every time, the right pane shows me the corresponding details. Whenever I decide I want to edit the entity I am examining, I can always click the Edit in Dashboard button and be deep-linked to the corresponding Auth0 Dashboard page. In the example here I do so for a SPA. Any changes will be automatically picked up by Auth0 Explorer at the next refresh.

## Understanding Applications’ Behavior End-to End

Excited yet? Well, hold on to your hats, because the surprises aren’t over yet! We tackled the problem of working at the tenant level, but there’s still a lot we can do at the single application level.

Even the best identity experts cannot simply glance at a list of application attributes (such as the ones displayed in a typical dashboard: client_IDs, return URLs etc) and anticipate how the application will actually work at run time. There are lots of moving parts and service features all contributing to the actual application behavior, and a bunch of text labels just isn’t expressive enough to communicate a complex ensemble of features in immediate, intuitive way.

By simply double-clicking on an application icon, you can experience how Auth0 Explorer tries to address that challenge with a novel approach.

<include src="Vidyard" id="N9b6StnoNV84HmzttvETu3" />
<br><br>

What you see in the GIF above is a representation of the journey of an authentication request, placing on its path all the Auth0 features you can use to customize its behavior.

Going from left to right, you encounter the Anomaly Detection stage, the Universal Login stage (with associated set of identity providers configured for this particular app), the extensibility block (more on that in a minute) and the multi factor authentication stage.

Each feature is represented by an icon that can be either grayed out (if the feature is disabled) or lighted up in color (if the feature is on). Consistently with the affordances you already encountered in the tenant level diagram, you can click on every icon to find details in the right pane.
When you click the Universal Login icon you get an actual preview of what the authentication experience will look like: and if you want to explore that aspect further, Auth0 Explorer offers you a direct link to [Auth0 Flows](https://auth0.com/blog/visualize-the-power-of-auth0-in-minutes/), where you will be able to examine how different user journeys will look like - automatically configured to use logo, colors, and backgrounds from your tenant settings.

If you are using Auth0, chances are that your app takes advantage of our advanced extensibility capabilities - namely, the ability to inject your own Node.js code and execute it directly within our authorization pipeline. That’s an incredibly powerful feature, but it is not always immediately intuitive to keep track of its influence within the context of all the other features.

Yep, you called it! Auth0 Explorer does something for this scenario too. You just need to click on the Extensibility block in the Application View to find out.

<include src="Vidyard" id="8fvgxVprMp5NJ7nHrht2FQ" />
<br><br>

Once expanded, the Extensibility block displays a compact representation of the code extensibility pipeline – showing what extensibility points are there at your disposal, in what sequence they are triggered, and whether you already did add code to them or if they are still inactive.

If you click on the Rules icon, the right pane will display a sequence of all the rules configured for the tenant, with the ones that will trigger for this particular app switched on. If you want to quickly make sense of what a particular rule does, you can click on View Code on the corresponding entry and see its source inlined. If you decide to edit it, the usual Edit in Dashboard button will open the dashboard directly on the right page.

## We Want Your Feedback!

Although it looks great and nicely polished (if we do say so ourselves), it’s important to remember that Auth0 Explorer is not a product or an Auth0 feature at this point in time. It’s an experiment, with no SLA – something we’ll iterate on, changing things around often, and without notice.

We have seen an area where the industry made little progress in many years, and an opportunity to make identity easier for application builders - so we decided to try something radically new. However, as it’s the case for every bold departure from the established norm, we won’t know if we are heading in a promising direction without getting YOUR feedback, and a ton of it. Some examples of things we’d like to learn:

- Do you find Auth0 Explorer useful?
- Did you learn something about your tenant (or app) you didn’t realize until you saw a diagram of it?
- Do you see yourself using Auth0 Explorer every day or only in specific phases of the project?
- Would you use this tool to learn the basics too, or only for working with complex tenants?
- Are there other features or data you’d like visualized in there?
- What actions would you like to be able to perform directly in Auth0 Explorer?
- ...and literally anything else that comes to mind.

<include src="Vidyard" id="PJsse4Kxw1BQnU9RyLwa4T" />
<br><br>

We baked an easy mechanism for you to [share your thoughts](https://discord.com/invite/XbQpZSF2Ys) directly in Auth0 Explorer: just head to the lower left button bar, hit the middle button and jolt down your experience, comments, ideas, insights… anything you want to share. I can assure you we will treasure and ponder each and every one of your messages!

Charting New Territory with Auth0 Explorer

andrew-akers

I'm a product marketing manager who loves learning about technology, information security, and identity. My goal is to turn that knowledge into positive outcomes for our customers. Before Auth0, I was a product marketing manager at Cisco in the network security division. In my spare time, you can find me spending time with my family, reading, writing, and working on endless home improvement projects.

Andrew Akers

Simplify your user experience with our new design, reimagined login flows, and quick-loading pages



[Auth0's new Universal Login experience](https://auth0.com/docs/universal-login/new) — including reimagined login flows, with a fresh UX design, and lightweight pages — is now generally available. Here is everything you need to know about this release.

## First, What is Universal Login?

Universal Login authenticates users via a central authorization server. This contrasts with an [embedded login flow](https://auth0.com/docs/libraries/lock/v11), which relies on JavaScript libraries to perform authentication via cross-origin request. (You can find a more [detailed explanation of universal vs. embedded login here](https://auth0.com/docs/guides/login/universal-vs-embedded).)

Universal Login benefits include:

* Simplified user experience
* Streamlined app integration
* Improved administration
* Increased authentication security, especially with 3rd party integrations and mobile apps

<include src="TweetQuote" quoteText="Universal Login authenticates users via a central authorization server."/>

## Why Are We Updating Universal Login? 

The new Universal Login experience allows us to provide a smoother login experience for you and your users while simplifying the development of future capabilities. The classic Universal Login experience based on Lock remains available for customers who wish to use it.

<include src="TweetQuote" quoteText="The new Universal Login experience allows us to provide a smoother login experience for you and your users."/>

## What is New About the New Experience?

Here are the key improvements and additional capabilities available with the new Universal Login. We will be adding more over time: 

### Lightweight login pages

JavaScript is no longer required for login pages using the new Universal Login experience as the pages are rendered server-side. This drastically reduces the size of the page the end-user needs to load, resulting in lightweight pages that load quickly without consuming much bandwidth. In some cases, we see a nearly 80% reduction in page size from the classic Universal Login experience.

![Auth0's Lightweight Universal Login Auth0](https://images.ctfassets.net/23aumh6u8s0i/54lZ5srDBAM0dqWSRkdxXk/f4260dcf2af6e7b5b4a52c62769e0745/lightweight-login)

### Redesigned flows for login, MFA, signup, and more

The fresh design for Universal Login pages and flows, combined with easy customization capabilities results in a unified, modern look and feel for your login pages. New flows can also be enabled in conjunction with existing classic Universal Login implementations. To see an interactive demonstration of the new flows visit [flows.auth0.com](https://flows.auth0.com/).

![Verify Identity from Auth0 Login modal](https://images.ctfassets.net/23aumh6u8s0i/54AqPKpkzYe7iYnb11rUjp/9bbff2c89ddc9cddbf2711823f894b69/verify-identity)

### Multiple authenticator support for multi-factor authentication

Customers can now enable support for multiple MFA authenticators. End users can now enable multiple MFA factors and then choose which one to use during the login process.

![Other Login Methods View](https://images.ctfassets.net/23aumh6u8s0i/2mXv9PzILbgXR5Uri3aFtZ/a7ab580535119a5a72942fc162adb17b/other-methods)

### Language localization

All of the flows are fully localized in English, Spanish, German, French, Portuguese, Dutch, Norwegian, Swedish, Danish, Finnish, Chinese, Russian, Italian, and Japanese. Language can be determined via [browser settings, a parameter in the /authorize endpoint, or tenant settings](https://auth0.com/docs/universal-login/i18n).

![Different Language Localization/Internationalization Login View](https://images.ctfassets.net/23aumh6u8s0i/2xMQsjc5P3Ax43GdBy55tx/9d95e9d2a6f9cf420b2da9c2d506759e/language-login)

### Email as an MFA factor

The ability to use a confirmed email address as a method for multi-factor authentication.

![Auth0 Email MFA Verification](https://images.ctfassets.net/23aumh6u8s0i/22vI1cV6ZyIyKrtQrtuddl/4e386cbfbc97c9d656b74cb6eb2b6150/email-confirmation)

### Improved consent flow

The consent flow now offers language localization, more branding customization options, and more descriptive text.

![Authorize App/Consent View in  Login modal](https://images.ctfassets.net/23aumh6u8s0i/4ADHl6SvieqGSk06hpMuPB/53cd6ddf893b455543ead731638aa9f8/authorize-app)

### Device Flow

Device Flow is an OAuth 2.0 authorization flow designed for devices that either don’t have access to a browser or have limited input capabilities. Device Flow enables end-users to authorize such devices to access APIs (protected resources) provided the devices have an internet connection.

### Successful password reset and email verification redirect

Now when a user successfully completes a password reset or verifies their email address, they will be redirected to the default tenant or application login URL, allowing them to quickly begin the login flow.

## What features are on the Universal Login Roadmap?

We have a number of improvements in the works. We can share some of our future capabilities, but not all. Here are just a few things that are currently planned:

### Editable text

The new Universal Login text can be customized for your needs.

### Enhanced customization

Even further customization and enhancements for the look and feel for the Universal Login pages to generate an exceptional login experience.

### Home Realm Discovery

Specifically for customers with an enterprise identity provider. Home Realm Discovery will allow users to enter their email in the login screen, which will then automatically detect the connection they should be authenticated with.

## What Are the Limitations to the New Universal Login Experience?

There are currently a few limitations to the new Universal Login experience. [Visit docs for an up-to-date list of the limitations](https://auth0.com/docs/universal-login/new-experience-limitations).

## How Do I Get Started?

To try the New Universal Login experience out, [sign up for Auth0 for free](https://auth0.com/signup) and click on Universal Login in the management dashboard. For a quick, interactive demonstration of the new login flows, visit [flows.auth0.com](https://flows.auth0.com/).

<include src="asides/AboutAuth0" />


Introducing the New Universal Login Experience

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

diegopoza

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

Sr Manager, Developer Advocacy

Diego Poza

Key solutions like anomaly detection, universal login, and custom security rules delivered by Auth0 helps its customers protect sensitive user data.



Tight infrastructure security is critical — but if you don't remember to secure your web applications, customer data remains exposed.

There are several [common threats to web-app security](https://auth0.com/blog/common-threats-in-web-app-security/):

- A lack of encryption between your web browser and their servers
- XSS (cross-site scripting) that occurs when malicious scripts are injected into web applications
- Clickjacking (when an attacker injects transparent or opaque objects into a web application)
- Cross-site request forgery (where the attacker impersonates an authorized user and requests sensitive information, such as passwords)

These threats are continuing to multiply and become more complex by the day. To mitigate breaches, particularly in a time of [heavy regulatory scrutiny](https://auth0.com/docs/compliance/gdpr), Auth0 offers three major strategies:

1.  Anomaly Detection
2.  Universal Login Support
3.  Customizable Rules

Auth0 allows you to combine these features to further amplify protection for your app's end users. While you can always attempt to develop these and similar solutions in-house, outsourcing app security will give you access to a team of experts who work 24/7 to keep up with the latest trends in a constantly evolving space.

## Anomaly Detection

Auth0 provides three built-in shields that [detect anomalies](https://auth0.com/docs/anomaly-detection) among users in an app's system. Used separately or in combination, the shields have the ability to stop malicious access attempts before they occur. Administrators receive alerts of suspicious activity and can then block future login attempts by an aberrant user.

<include src="TweetQuote" quoteText="Learn more about how Auth0 provides three built-in shields that detect anomalies among users in an app's system."/>

### Brute-Force Protection

Within its [Brute-Force Protection](https://auth0.com/docs/anomaly-detection) feature, Auth0 has two distinct shields:

1.  Shield 1 is triggered after 10 failed login attempts on a single account from the same IP address.
2.  Shield 2 is triggered after 100 failed login attempts from a single IP address via different usernames in 24 hours or after 50 sign-up attempts in one minute from the same IP address.

When Shield 1's threshold is reached, an email is automatically sent to the user, which an administrator can edit however he or she wishes. This initial email looks like:

![Affected user email](https://images.ctfassets.net/23aumh6u8s0i/7Hf4QzvX6IDVi6gl4hGRp4/8fc62d71de2ae3698d64c087b89c730c/affected-user-email)

An administrator can easily edit the template by accessing the Auth0 [Dashboard](https://auth0.com/docs/dashboard) and following Emails > Templates.

When Shield 2 is triggered, dashboard administrators are notified. Brute-Force Protection will also block the suspicious IP address. When the issue is resolved, an administrator simply locates the user in the Auth0 [Dashboard](https://auth0.com/docs/dashboard) and files an action to unblock. A user can also click on the "unblock" link provided in the email above or change their password.

### Breached-Password Detection

The third shield is breached-password detection. This is easy to turn on and customize in the Anomaly Detection section of the Auth0 dashboard.

![Breached-password anomaly detection with Auth0](https://images.ctfassets.net/23aumh6u8s0i/3Oe0VufANczOhCpPtuL8iV/99ffa473077e16cd7733334c25a9c73d/breached-password-shield)

Breached-password detection is useful in instances where Auth0 suspects that a user's email has been compromised in a major security breach. (Auth0 consistently tracks these on third-party sites.) If this occurs, Auth0 will trigger the shield, notify the user, and block them from logging in until they reset their information. Breached-password detection is becoming increasingly helpful as many individuals use the same or similar iterations of the same password on multiple sites.

<include src="TweetQuote" quoteText="When Auth0 suspects that a user's email has been compromised in a security breach, Auth0 will trigger a protective shield, notify the user, and block them from logging in until they reset their information"/>

## Universal Login

Auth0 supports [universal login](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/) on customer apps. In contrast to embedded login, this offers increased security and a shorter setup time.

![Auth0 Universal Login offerings](https://images.ctfassets.net/23aumh6u8s0i/21BR2xIUfU721nga9W1FqO/184597f0a961d89938bb9923b08e6a73/centralized-embedded-diagram)

Universal login is a more seamless experience for the user. On the front end he or she sees a simple authentication request; on the back end, credentials remain within the same domain instead of being sent across origins. This makes it a far more secure method than exposing the information to outside sources. When personal data moves from one origin to another, [phishing attacks](https://auth0.com/blog/all-you-need-to-know-about-the-google-docs-phishing-attack/) and [man-in-the-middle attacks](https://auth0.com/docs/security/common-threats#man-in-the-middle-mitm-attacks) become common.

In addition to an enhanced customer experience, universal login is simpler for administrators to maintain and provides the benefits of single sign-on (SSO).

## Auth0 Security Rules

Auth0 has developed customizable [Rules](https://auth0.com/docs/rules/current) for its app-security features. Rules are JavaScript functions that execute when a user authenticates to your application. Rules can be helpful when customizing and extending Auth0's existing capabilities. For example, the [Force Email Verification](https://auth0.com/rules/email-verified) and [User Fraud Score](https://auth0.com/rules/socure_fraudscore) Rules can be incorporated into Auth0's existing tools like Anomaly Detection to better determine if a user truly is who they say they are.

### Force Email Verification

Force Email Verification only allows app access to users who have verified their emails. Incorporating Force Email Verification into an app instead of a browser version is a good UX practice with powerful back end capabilities.

![Force Email Verification code](https://images.ctfassets.net/23aumh6u8s0i/6MhbfE6DYpGdnku3wGI9Rn/4dd87042b24817242ccde8b52d16c781/verify-email-code)

[[Source](https://auth0.com/rules/email-verified)]

For example, if you are working with a large set of emails that belong to a network, e.g., `@university.edu` or `@company.edu`, Force Email Verification can help parse individuals in a group to make sure that a fake user hasn't set up an account to blend in with the others. Force Email Verification requests that users cross-check their information; anyone who returns information that doesn't match or does not return additional information at all will be blocked from logging in.

### User Fraud Score

Like Force Email Verification, you can tack on the User Fraud Score to a variety of features. If you've built an online marketplace — like Etsy, for example — you can use this rule to cross-check everyone conducting business and thus add an extra layer of protection to purchases. The Rule calculates a fraud score for every user, based on their email address and IP address.

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

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

  const request = require('request');

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

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

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

In the Auth0 Dashboard, copy the code block above, and replace placeholders with the appropriate values. The rule will pull the fraud score from socure.com and store it on app_metadata. A full set of Auth0 Rules can be found [here](https://auth0.com/docs/rules/current).

For fraud detection, Auth0 partners with [ThisData](https://auth0.com/blog/anomaly-detection-safer-login-with-thisdata-and-auth0/). ThisData allows real-time detection of any account takeovers across both web and mobile apps.

## No Better Time To Secure Your Apps

Securing your app with the best tools is always a good decision — but it is especially timely, given the slew of new regulations: GDPR deadline has passed, but [it's not too late to comply](https://auth0.com/blog/your-quick-gdpr-compliance-checklist/), and several countries and states in the U.S. have followed the EU with [similar privacy initiatives](https://auth0.com/blog/brace-yourself-the-gdpr-ripple-effect-in-california/). In line with these events, Auth0 has developed additional [strategies](https://auth0.com/gdpr-assessment/) for getting your team into alignment quickly, including [customer identity and access management (CIAM) protocol](https://auth0.com/blog/digital-success-through-customer-identity-and-access-management/).

While it might be easy to forget your apps in the swirl of demands around your core operations — making sure you plug any holes here is key to ensuring that you don't become another [data-breach statistic](https://consequenceofsound.net/2018/06/ticketfly-hacker-data-breach/).


How Auth0 Makes Your Apps More Secure

keith

Guest Author

Keith Kowal

Learn how to implement passwordless real-name and age verification policies with Auth0 and the Trusted Key Mobile App.



**TL;DR:** Learn how “self-sovereign” digital wallet Trusted Key can be leveraged with Auth0 to easily manage authenticated identity.

---

## Introducing Authenticated Identities

Trying to authorize user access based on real-life identity has always presented a significant technical challenge for website and application providers. Age verification is commonly attempted for mature content, and just as commonly circumvented by 14-yr old boys claiming to be born in 1972. Real-name policies have a colorful internet history and are a sure-fire topic to start a dinner argument. Regardless of your outlook, it is reasonable to assume that as technology makes authenticated identity solutions more practical to implement, there will be more service providers looking to implement enhanced age verification and real-name policies to meet the needs of regulators and to differentiate their online experience.
 
A few key technologies are making real-life identity verification closer to reality. First, advances in Optical Character Recognition (OCR), identity documents embedded with barcodes/NFC, and facial recognition allows smart devices such as mobile phones to reliably extract Identity information from government-issued documents and confirm ownership with the person pictured on the ID. Second, public key cryptography allows that identity information to be securely stored using technologies such as Apple’s Secure Enclave, and safely transported. Finally, blockchain technologies are enabling “self-sovereign” identity solutions that allow users to create a digital wallet to store their identity and be in full control of what information leaves that wallet in the form of signed identity tokens, which will, in turn, increase users’ willingness to participate in such identity transfers.

<include src="TweetQuote" quoteText="Technologies like OCR, public key, and blockchain are making real-life identity verification closer to reality."/>
 
To help illustrate these principles we will demonstrate importing real-life identities using Auth0 and Trusted Keys Digital Identity Wallet.

## Setting up the Trusted Key App

The Trusted Key App is a secure self-sovereign Digital Identity Wallet based on Ethereum with a wide range of identity applications including KYC, registration, passwordless login, transaction authorization, document signing, and even managing SSH Keys. This entire Trusted Key App setup process only takes a few minutes.

<include src="TweetQuote" quoteText="The Trusted Key App is a secure self-sovereign Digital Identity Wallet based on Ethereum"/>

**Step 1**: Download the free [Trusted Key iOS App](https://itunes.apple.com/us/app/trusted-key/id1167336246?mt=8&ign-mpt=uo%3D4) or the [Android app](https://play.google.com/store/apps/details?id=com.trustedkey.identify.wallet).
 
**Step 2**: Go through the onboarding process and create a PIN and register an email address.

![Trusted key app setup](https://images.ctfassets.net/23aumh6u8s0i/vbAJOwPBX9RftsU4YJ9Mo/1552cce6af3e296d038bc42987a245b6/enter)

**Step 3**: On the “My Identity” screen select “Add an ID” and “Driver’s License”. The App will take you through a process where you will take a picture of the front and back of your license and then automatically extract the information from the ID for review. The Trusted Key App supports driver licenses from around the world, and if you don’t have a driver’s license you can try another identity card such as a National ID. The App will then take a selfie that confirms you are a kicking breathing human, and that your face matches the picture on the ID.

![Trusted key app add driver's license](https://images.ctfassets.net/23aumh6u8s0i/3rbSxdm84i2Tt4lPF7tPBK/8c11ee736e02b5a0af6305e4752b3400/idphoto)

A key aspect of this process is that users are not able to edit or modify the Identity information extracted from the ID. This means that any identity information provided by the Trusted Key App is derived from a government-issued ID document, and the user’s ownership confirmed through the selfie process, resulting in an authenticated identity.
 
For more information please see the [Trusted Key App user guide here](https://www.trustedkey.com/product/trusted-key-app-user-guide/).

## Getting a Client ID / Secret

**Step 1**: Go to the [Trusted Key Developer Portal here](https://developer.trustedkey.com/).

**Step 2**: Click on “Sign up with Trusted Key App” in the upper navigation bar. You will be asked to enter the email address you registered on the Trusted Key App. You will get a notification on the Trusted Key mobile app asking for authorization to access the Developer Portal. Confirm the login.

![Register new trusted key app](https://images.ctfassets.net/23aumh6u8s0i/2qHU5Hhcc25umjpl5vKR25/bc42e228eecfd7d6c8a826faa2c10c56/register)

**Step 3**: Once you have logged into the Trusted Key Developer Portal click on “Register New App” where you will be asked to enter your app name and callback URI. Your callback URI is `https://YOUR_TENANT_DOMAIN/login/callback`. The portal will then provision a Client ID and Client Secret to use in your API calls to the Trusted Key Platform. Copy both values for the Auth0 setup.

![Trusted key app configuration with Auth0](https://images.ctfassets.net/23aumh6u8s0i/3XBKIU0SsPhr69D0NCvOkG/d5d705f12ffab520dd1502556fa1db81/clientid)

## Setting Up Auth0

[Auth0](https://auth0.com) is an ideal platform for easy configuration of connections to third-party Identity Providers such as Trusted Key, combined with a powerful backend for vetting, adding, and managing users. The setup process starts with [signing up for a free Auth0 account](https://auth0.com/signup). 

Next, go to **Connections > Social** in the Auth0 Dashboard, scroll to the bottom, and click **Create Custom**.

### Standard Trusted Key Social Connection Setup

* **Connection Name**: The name you choose for your connection
* **Authorization URL**: `https://wallet.trustedkey.com/oauth/authorize`
* **Token URL**: `https://wallet.trustedkey.com/oauth/token`
* **Scope**: `openid email`
(Depends on your requirements. Please note that any email address received will have been already verified by the Trusted Key app.)
* **Client ID and Client Secret**: Paste your Client ID and Client Secret obtained in the process described above. 
* **Fetch User Profile Script**:

```js
// Call oauth2 API with the access token and create the profile
function(access_token, context, callback) {
    request.get('https://wallet.trustedkey.com/oauth/user', {
        'headers': {
              'Authorization': 'Bearer ' + access_token,
              'User-Agent': 'Auth0'
        }
    }, (error, response, body) => {
        if (error) {
            return callback(error);
        }
        if (response.statusCode !== 200) {
              return callback(new Error('StatusCode:' + response.statusCode));
        }

        return callback(null, JSON.parse(body));
    });
}
```

### Authenticated Identity Trusted Key Social Connection Setup

To support authenticated identity we will need to make a few changes to the above settings.

In the “Scope” field you would enter the desired authenticated identity information. A convenient shortcut is to use the scope `profile`:

**Scope**: `openid email profile`

By using `profile`, the Trusted Key App will automatically provide the user’s full name, first name, last name, gender, and birth date.
 
You also have the option to force users to provide authenticated identity details to complete the registration process. There are many ways to do this both client side and within the Auth0 dashboard such as setting up a rule. A very simple way is to add some script into the User Profile Agent that mandates authenticated identity information or else returns an error. Typically, if the Trusted Key App is not providing this information it means the user has not scanned their ID, their ID does not contain the needed information, or there was an error in the scanning where identity fields are missing.

```js
// Call oauth2 API with the accesstoken and create the profile
function(access_token, context, callback) {
    request.get('https://wallet.trustedkey.com/oauth/user', {
        'headers': {
              'Authorization': 'Bearer ' + access_token,
              'User-Agent': 'Auth0'
        }
    }, (error, response, body) => {
        if (error) {
            return callback(error);
        }

        if (response.statusCode !== 200) {
              return callback(new Error('StatusCode:' + response.statusCode));
        }

        const ui = JSON.parse(body);

        if(!ui.given_name) {
              return callback(new Error("First Name missing. Please rescan your ID in the Trusted Key App"));
        }

        if(!ui.family_name) {
              return callback(new Error("Family Name missing. Please rescan your ID in the Trusted Key App"));
        }

        if(!ui.birthdate) {
              return callback(new Error("Birthdate missing. Please rescan your ID in the Trusted Key App"));
        }

        if(!ui.gender) {
              return callback(new Error("Gender is missing. Please rescan your ID in the Trusted Key App"));
        }

        return callback(null, ui);
    });
}
```

When you finish filling out the fields, you can **Create** your new social connection, and then click “**Try Connection** at the top of the page. You will be taken to the Trusted Key login. Enter your email address and then confirm the login using your Trusted Key App. If everything works correctly, you’ll get a confirmation message and an output where you can review the raw identity data provided by the Trusted Key App.

![Auth0 Trusted identity data](https://images.ctfassets.net/23aumh6u8s0i/1NuXCcala9EwS2tqNBkknR/2b27e6c394e4df6f1684e003ffa60868/app)

Upon exiting the window make sure your Trusted Key custom social connection is turned on.

## Testing it Out

To provide a “real life” example we set up a demo WordPress website. We then downloaded and installed the [“Login by Auth0”](https://auth0.com/wordpress) WordPress plugin. After activating the login you will be asked to log into your Auth0 Account, and a client will automatically be set up in your Auth0 dashboard. In the WordPress Admin settings under Settings > General > Membership make sure the “Anyone can Register” box is checked.
 
On your WordPress website if you go to login with the Auth0 module there should be a button reflecting the name you choose for your Trusted Key Social Connection—in this case, we called it “Trusted-Key”.

![Auth0 trusted key login demo](https://images.ctfassets.net/23aumh6u8s0i/7jLaydDKEuGmY6yLkPODSu/ddd00cc90e27c8d1c14c2a752ea7588a/login)

Click on the login button and the Trusted Key window should appear. Enter the email address associated with your Trusted Key Wallet, and then confirm the login using the Trusted Key App. You should now be registered and logged into the WordPress website.
 
Back in the Auth0 dashboard if we look at “Users” in the left-hand toolbar we will see the login showing the name and email address associated with your Trusted Key App. If you click on the User a window will open showing the entire user profile. This includes the user’s full name, given name, last name, birthdate, gender, and verified email address. This information can also be stored in the WordPress user profile, although some fields such as birthdate and gender will require customization of the profile input fields.
 
Now that you have the user’s authentic identity information you have a wide range of choices on how to use that data to create customized registration and user experiences. Auth0 provides a powerful set of capabilities in their rules engine or database setup. You also have the option to set up policies or custom flows in the website front end.

![Auth0 trusted key identity data](https://images.ctfassets.net/23aumh6u8s0i/7pO6ipHvHOJAiSbsYeX8XS/e485657b580f1241af0184ac7afb641f/userprofile1)

## Conclusion

The ability to create authenticated identity user profiles provides website and application creators exciting opportunities to redefine and segment their user experience. A new generation of “self-sovereign” digital wallets like Trusted Key makes the ingestion of government identities documents easy and secure. When combined with Auth0’s powerful user management and flexible backend, managing and leveraging authenticated identity is made easy for everyone.


"verification"