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

37590801?s=460&v=4

A software engineer who dreams about non-electric sheep and autonomous vehicles and likes to champion security.

Software Engineer

Dan Arias

Secure Fastify APIs easily with the Auth0 Fastify SDK. It simplifies Auth0 integration, offering route protection and token validation.

Fastify is rapidly gaining traction among Node.js developers, and for good reason! If you're looking for a high-performance and low-overhead way to build web applications and APIs, Fastify is an excellent choice. Its plugin architecture is powerful, but securing those APIs remains a critical concern for developers.

To help address this, we are introducing the **`auth0-fastify-api` SDK**. This new package brings seamless Auth0 integration into your Fastify projects, simplifying API endpoint protection.

## So, What is Fastify, Anyway?

For those who might be new to it, Fastify is a web framework for Node.js focused on delivering a strong developer experience with minimal overhead, built around a robust plugin system. Key features include:

- **High Performance:** Fastify is known as one of the fastest Node.js frameworks, utilizing optimizations like schema-based request/response serialization.
- **Extensibility:** A rich ecosystem of plugins allows developers to easily add needed functionality.
- **Developer Experience:** Features like built-in logging, developer-friendly error handling, and first-class TypeScript support contribute to a smoother development process.
- **Schema-Powered:** Use JSON Schema to validate routes and serialize outputs, leading to more predictable and robust applications.
- **Helpful CLI:** The **`fastify-cli`** tool streamlines common development tasks like running the app and generating project scaffolds ([See fastify-cli on GitHub](https://github.com/fastify/fastify-cli)).
- **NestJS Integration:** Fastify's performance can also be leveraged within the popular NestJS framework by using it as the underlying HTTP provider ([Learn More](https://docs.nestjs.com/techniques/performance#performance-fastify)).

## Introducing `auth0-fastify-api`

This new SDK is specifically designed to secure Fastify APIs. It functions as a dedicated Fastify plugin to simplify the validation of access tokens issued by Auth0.

Here's what the SDK offers:

- **Simple Integration:** Sets up as a standard Fastify plugin.
- **Automatic Token Validation:** Handles the validation of incoming JWT access tokens (sent as Bearer tokens) against your Auth0 tenant configuration.
- **Route Protection:** Provides a **`requireAuth`** decorator for easily securing specific routes.
- **Scope Enforcement:** Allows specification of required scopes (permissions) needed to access certain endpoints.
- **User Information Access:** Makes the validated token payload available on **`request.user`**.
- **Token Access Utility:** Includes **`request.getToken()`** for accessing the raw token string if necessary.
- **Standard Error Handling:** Sends standards-compliant `WWW-Authenticate` headers on authentication/authorization errors.

## Getting Started: Quick Setup

Integrating the SDK involves two main steps:

1.  **Install the SDK:**

```bash
npm install @auth0/auth0-fastify-api
# or
yarn add @auth0/auth0-fastify-api
```

2.  **Register the Plugin:**

In your main Fastify application file, register the plugin, providing your Auth0 domain and API audience:

```typescript
import Fastify from "fastify";
import Auth0 from "@auth0/auth0-fastify-api";

const fastify = Fastify({ logger: true });

fastify.register(Auth0, {
  domain: "YOUR_AUTH0_DOMAIN", // For example: your-tenant.auth0.com
  audience: "YOUR_API_AUDIENCE", // The Identifier of your API in Auth0
});

// ... rest of your setup
```

> Remember to replace the placeholder values with your actual Auth0 domain and API identifier.

### A Functional Example

Let's look at a functional example that demonstrates setting up a basic server, loading configuration from the environment, and protecting a route.

Create a `fastify` directory anywhere in your system and initialize a Node.js project within it:

```bash
npm init -y
```

Within that directory, create a `server.ts` file and follow the instructions in this section to build it up.

First, import the necessary modules and use `dotenv` to load configurations like your Auth0 domain and audience from a `.env` file, which avoids hardcoding sensitive credentials.

```typescript
import Fastify from "fastify";
import Auth0 from "@auth0/auth0-fastify-api";
import * as dotenv from "dotenv";

dotenv.config();

const fastify = Fastify({
  logger: true,
});

if (!process.env.AUTH0_DOMAIN || !process.env.AUTH0_AUDIENCE) {
  fastify.log.error("Auth0 domain or audience not configured in .env file");

  process.exit(1);
}
```

It's good to check that the environment variables were loaded correctly.

Next, register the `Auth0` plugin, passing the configuration loaded from the environment variables:

```typescript
fastify.register(Auth0, {
  domain: process.env.AUTH0_DOMAIN,
  audience: process.env.AUTH0_AUDIENCE,
});
```

To ensure the `Auth0` plugin has finished loading before defining routes that use its decorators, such as `requireAuth`, register your protected routes inside an anonymous plugin function:

```typescript
fastify.register(() => {
  fastify.get("/", { preHandler: fastify.requireAuth() }, (_, reply) => {
    reply.send({ ok: true });
  });
});
```

Finally, start the server, listening on the port `3000`:

```typescript
fastify.listen({ port: 3000 }, function (err, address) {
  if (err) {
    fastify.log.error(err);
    process.exit(1);
  }

  fastify.log.info(`Server is now listening on ${address}`);
});
```

You can run this short example by following these steps:

Install dependencies:

```bash
npm install fastify @auth0/auth0-fastify-api dotenv
```

Create a `.env` file with your Auth0 details:

```bash
AUTH0_DOMAIN=your-tenant.auth0.com
AUTH0_AUDIENCE=your-api-identifier
```

You can follow the steps on the ["Register APIs"](https://auth0.com/docs/get-started/auth0-overview/set-up-apis) document to learn how to create an API in the Auth0 Dashboard and get the required values: the Auth0 Domain, which is your tenant domain, and the Auth0 Audience, which is a unique identifier for your API.

Run the server:

```bash
npx ts-node server.ts
```

This provides a basic but functional starting point that loads configuration securely and correctly waits for the Auth0 plugin before defining protected routes.

## Securing A Route with `requireAuth`

As you saw earlier, to protect an individual API endpoint, use the **`requireAuth`** decorator provided by the SDK. Add it as a `preHandler` in your route definition:

```typescript
fastify.get(
  "/private",
  { preHandler: fastify.requireAuth() },
  async (request, reply) => {
    const user = request.user;
    return { message: "This is a protected route", user };
  }
);
```

Fastify will only reach the body of the route event handler if the token sent in the request authorization header is valid. The decoded token claims of the token are available in the `request.user` object.

If a request is made to `/private` without a valid Bearer token in the `Authorization` header, the SDK automatically rejects it with a `401 Unauthorized` status.

### Securing Multiple Routes

Applying the `preHandler` to every route can be repetitive if multiple routes require the same protection. Fastify's plugin system and encapsulation offer an efficient way to apply an authorization guard at the router level to protect multiple routes at once.

Group related routes within their own plugin and apply the **`requireAuth`** hook once using [`fastify.addHook`](https://fastify.dev/docs/latest/Reference/Server/#addhook) within that plugin's context. All routes defined within that plugin will then inherit the hook.

Let's see this concept in action.

**1. Create a routes plugin:**

Within an asynchronous Fastify plugin, you use `fastify.addHook("preHandler", fastify.requireAuth())` to run the authentication check before any route defined within this plugin. Routes defined after this hook (`/profile`, `/orders`, etc.) are automatically protected.

```typescript
// private-routes.ts
import { FastifyPluginAsync } from "fastify";

const privateRoutes: FastifyPluginAsync = async (fastify, opts) => {
  // Apply the hook once for all routes in this plugin
  fastify.addHook("preHandler", fastify.requireAuth());

  fastify.get("/profile", async (request, reply) => {
    // Token is already validated by the hook
    return { user: request.user };
  });

  fastify.get("/orders", async (request, reply) => {
    // Hook handles main auth; specific checks can still happen here
    if (!request.user.scope?.includes("read:orders")) {
      return reply.code(403).send({ error: "insufficient_scope" });
    }
    return {
      orders: [
        /* ... */
      ],
      user_id: request.user.sub,
    };
  });
  // Define more protected routes here...
};

export default privateRoutes;
```

**2. Register the plugin in your main server file:**

In your main server setup (likely within the `fastify.register(async function(fastify){...})` block), import the `privateRoutes` plugin. Use `fastify.register` to load it, passing the `prefix` option (e.g., `{ prefix: "/api/v1" }`) to mount all routes from the plugin under that path.

```typescript
import Fastify from "fastify";
import Auth0 from "@auth0/auth0-fastify-api";
import * as dotenv from "dotenv";
import privateRoutes from "./private-routes"; // Import the routes plugin

dotenv.config();

const fastify = Fastify();

fastify.register(Auth0, {
  domain: process.env.AUTH0_DOMAIN,
  audience: process.env.AUTH0_AUDIENCE,
});

fastify.register(async function (fastify) {
  if (!process.env.AUTH0_DOMAIN || !process.env.AUTH0_AUDIENCE) {
    fastify.log.error("Auth0 domain or audience not configured in .env file");
    
    process.exit(1);
  }

  // Register the protected routes plugin under the /api/v1 prefix
  fastify.register(privateRoutes, { prefix: "/api/v1" });

  // Routes defined outside that plugin don't inherit its hooks 
  // and need their own protection
  fastify.get("/", { preHandler: fastify.requireAuth() }, (_, reply) => {
    reply.send({ ok: true });
  });
});

fastify.listen({ port: process.env.PORT || 3000 });
```

Now, requests to `/api/v1/profile`, `/api/v1/orders`, or any other route inside `private-routes.ts` are automatically protected by the **`requireAuth`** hook applied at the plugin level.

## Enforcing Scopes

If you need to ensure the user has been granted specific permissions (scopes) in their access token, use the `scopes` property of the **`requireAuth`** decorator:

```typescript
const requiredScopes = ["read:messages", "write:messages"];

fastify.post(
  "/messages",
  { preHandler: fastify.requireAuth({ scopes: requiredScopes }) },
  async (request, reply) => {
    return { message: "Message created successfully", user: request.user };
  }
);
```

Only requests with valid tokens containing both `read:messages` and `write:messages` scopes will reach the route event handler body.

If you don't have multiple scopes to check, you can also assign `scopes` a string as its value. For a single scope, you could use the following:

```typescript
const requiredScopes = "read:messages";
```

If the validated token doesn't include _all_ the specified scopes, the SDK will return a `403 Forbidden` error with an `insufficient_scope` code.

## Accessing User Information

Once a token is validated by `requireAuth`, its decoded payload (claims) is attached to the Fastify request object at `request.user`. This typically includes information like the user ID (`sub`), audience (`aud`), issuer (`iss`), and granted scopes (`scope`).

```typescript
fastify.get(
  "/profile",
  { preHandler: fastify.requireAuth() },
  async (request, reply) => {
    // Access the user's unique identifier (subject)
    const userId = request.user.sub;
    // Access the scopes granted in this token
    const scopes = request.user.scope;

    return { userId, scopes, fullProfile: request.user };
  }
);
```

## Conclusion

The `auth0-fastify-api` SDK provides a straightforward way to secure your Fastify APIs by integrating Auth0 token validation. It offers simple decorators for protecting routes and checking scopes, allowing you to focus on your application's core logic.

We encourage you to try it out in your next Fastify project and share your feedback! Check out the [source code](https://github.com/auth0/auth0-fastify/blob/main/packages/auth0-fastify-api) and [examples](https://github.com/auth0/auth0-fastify/blob/main/packages/auth0-fastify-api/EXAMPLES.md) to learn more.

Happy coding!

Announcing the Auth0 Fastify API SDK: Secure Your APIs with Speed!

Let's explore the scenarios where ASP.NET Core Identity shows its limitations and what the alternatives are.

When it comes to handling identity and access management in the .NET platform, ASP.NET Core Identity is a fantastic starting point. It provides a full-featured, out-of-the-box solution for managing users, roles, and authentication in ASP.NET Core applications that is simple to set up and use. However, as applications grow in complexity and authentication and authorization requirements become more challenging, ASP.NET Core Identity may start showing its limitations.  
This article explores the limitations of ASP.NET Core Identity, the technical reasons behind these challenges, and discusses alternative solutions.

## Why ASP.NET Core Identity?

Before diving into its limitations, let’s first understand why ASP.NET Core Identity is so popular. ASP.NET Core Identity is a membership system that provides common features like user registration, login, role management, and claims-based authentication. It is tightly integrated with the ASP.NET Core ecosystem and supports both [cookie-based and token-based authentication](https://auth0.com/blog/cookies-tokens-jwt-the-aspnet-core-identity-dilemma/) (starting with .NET 8). It offers several key features out of the box:

* **User Registration and Login**. ASP.NET Core Identity simplifies user registration and login processes, including options for password recovery, email confirmation, and Multi-Factor Authentication (MFA).  
* **Role-based Authorization**. The system allows for granular control over user roles and permissions, which is essential for access control.  
* **External Authentication**. ASP.NET Core Identity supports various external authentication providers, such as Google, Facebook, and Microsoft, allowing users to sign in using their existing credentials from these platforms.  
* **Customizability**. Developers can customize the system to fit their needs, adding additional fields to the user model, integrating with other services, and defining custom password policies.

While ASP.NET Core Identity is highly effective for small to medium-sized applications with basic authentication needs, its limitations become apparent in more advanced scenarios.

## Limitations of ASP.NET Core Identity

What are the limitations you may encounter when your application needs to grow in the context of ​​security and user management? Let's explore some of the main scenarios.

### Support for Standard Authentication Protocols

One of the primary limitations of ASP.NET Core Identity is its lack of support for advanced authentication protocols, such as OAuth 2.0, OpenID Connect (OIDC), and SAML. These protocols are crucial for implementing [Single Sign-On (SSO)](https://auth0.com/docs/authenticate/single-sign-on) across multiple applications and integrating with third-party Identity providers.  
While it can integrate with an external authentication service, this requires external libraries or a separate service to handle the authentication and authorization, adding complexity to the application.

### Single Sign-On and Federation

SSO is an essential feature for many organizations. It allows users to log in once and access multiple systems without needing to authenticate again. This is particularly important for enterprises with multiple applications that rely on centralized authentication.  
ASP.NET Core Identity is designed primarily for a single application context. While it’s possible to set up SSO in ASP.NET Core Identity by manually configuring external authentication providers (like Google, Microsoft, Facebook, or other enterprise systems), doing so is cumbersome and doesn’t scale well.  
Setting up SSO with complex protocols like SAML 2.0 or OpenID Connect can be challenging. You often need to rely on third-party libraries and write a lot of boilerplate code, which can be time-consuming and error-prone.  
In addition, if your application totally relies on an external Identity provider, the ASP.NET Core infrastructure, including the user database, becomes useless.

### Token Management

While .NET 8 introduced token-based authentication endpoints for Single-Page Applications (SPAs), these endpoints are limited in functionality compared to full-fledged OIDC or OAuth 2.0 implementations. For instance:

* By default, the tokens generated by ASP.NET Core Identity are not configured as JSON Web Tokens (JWTs).  
* Advanced OAuth flows like [client credentials](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) or [device authorization](https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow) are not natively supported.  
* Handling token refresh, revocation, or issuing custom tokens for various clients can be cumbersome with ASP.NET Core Identity.

### Microservices and Distributed Architectures

In modern application architectures, microservices are becoming increasingly popular. A key challenge in microservices is managing authentication and authorization across multiple services, each potentially using a different technology stack.  
ASP.NET Core Identity isn’t designed with microservices in mind. While it can work in monolithic applications, when dealing with a microservices architecture, you often need a solution that can provide centralized authentication and authorization, preferably using token-based authentication.  
In a microservices-based system, you might need to authenticate users once (e.g., OpenID Connect) and propagate tokens across multiple services (e.g., using OAuth 2.0). ASP.NET Core Identity is not ideal for this setup as it’s typically used for stateful session management, which is not optimal for distributed systems.

### Scalability and Performance

For high-traffic applications with millions of users, the default ASP.NET Core Identity database schema might become a bottleneck. While adequate for smaller applications, it isn't optimized for high-volume scenarios. Customizing the schema or implementing caching strategies is necessary but requires a deep understanding of the underlying database.

### Multitenancy

ASP.NET Core Identity is inherently designed for single-tenant applications, i.e., an application that manages a single set of users, typically belonging to one organization. A multi-tenant application is one in which a single instance serves multiple organizations or customers, each with its own set of users. This is a common scenario in SaaS (Software-as-a-Service) applications, where each customer (tenant) has different users, roles, and permissions.  
ASP.NET Core Identity does not provide built-in support for multi-tenant architectures. While it is possible to configure the system to work in a multi-tenant environment by creating separate user stores for each tenant, this approach can be cumbersome to manage and doesn’t scale well.

### Advanced Security Features

Implementing advanced security features like MFA with complex policies, FIDO2 credentials and passkeys, adaptive authentication, or risk-based authentication requires significant custom development. While ASP.NET Core Identity supports basic MFA, it lacks the flexibility to implement dynamic policies based on user behavior or risk profiles.  
Also, exposing protected APIs to third-party applications with ASP.NET Core Identity is possible, but it requires careful implementation of JWT-based authentication and authorization. Managing token issuance, validation, and revocation becomes critical, and inconsistencies can lead to security vulnerabilities. This is definitely a task for OAuth 2.0 and OIDC-compliant identity providers.

### Advanced Customization Requirements 

ASP.NET Core Identity's default implementation often requires significant customization to meet unique business requirements:

* Customizing the Identity API endpoints is challenging. For example, you cannot easily modify the data required for user registration or add unsupported authentication methods like WebAuthn.  
* The default UI for identity management forces you to use server-rendered pages unless you override them entirely.  
* Managing hierarchical roles or permissions is not natively supported.  
* Implementing fine-grained authorization for specific resources requires significant additional work.

### Security Concerns

Security is a major consideration when building any authentication system. While ASP.NET Core Identity provides some basic security features, the default configuration of ASP.NET Core Identity may expose vulnerabilities:

* Endpoints like `/register` are not natively protected, allowing [unauthorized access if not explicitly secured](https://auth0.com/blog/cookies-tokens-jwt-the-aspnet-core-identity-dilemma/#Some-Caveats-About-Identity-API-Endpoints).

* Without careful configuration, token expiration and refresh mechanisms [can introduce security risks](https://www.telerik.com/blogs/new-net-8-aspnet-core-identity-how-implement).

Also, it does not cover all the advanced security needs that modern applications require. Features like brute-force protection, IP whitelisting, user account lockouts, and MFA are important for securing an application’s authentication system. While ASP.NET Core Identity does provide some of these features (like MFA and account lockouts), more sophisticated threat protection features are often needed in high-risk environments.

## Self-Hosted Alternative Solutions

When you encounter one or more of the limitations discussed in the previous section, it is time to look for alternative solutions. A first option could be to replace ASP.NET Core Identity with a self-hosted standards-based Identity and access management solution.

Among the most popular self-hosted solutions in the .NET ecosystem, we can mention [Identity Server](https://duendesoftware.com/products/identityserver) and [Keycloak](https://www.keycloak.org/). Both offer more advanced identity and access management capabilities than ASP.NET Core Identity. Specifically:

* They **support standard protocols**, such as OpenID Connect and OAuth 2.0. Both products are OIDC-certified, which means they passed the tests that ensure compliance with the OIDC specifications. In terms of SAML support, while Keycloak supports it natively, Identity Server supports SAML via [a specific component](https://www.identityserver.com/articles/saml-20-integration-with-duende-identityserver).  
* They offer a **centralized authentication** solution enabling SSO and Federated Identity.  
* Support for **mutitenancy** depends on the specific product you are going to use. While Keycloak has native support for mutitenancy through [*realms*](https://www.keycloak.org/docs/latest/server_admin/index.html#_configuring-realms), supporting robust mutitenancy with Identity Server requires careful planning and implementation.  
* Support for **advanced authentication mechanisms** like passkeys is natively available in recent versions of Keycloak while it requires specific integration of third-party libraries in Identity Server.

Using a self-hosted solution like Identity Server or Keycloak certainly overcomes some of ASP.NET Core Identity's major limitations, especially regarding SSO and standards compliance. In terms of other features, much depends on the specific product and your needs in protecting your users' identities.

## Cloud-Based Solutions

Using a self-hosted solution, you still have to deal with issues that can become problematic as your application and its needs grow.

Leaving aside the features that your specific scenario requires, you still have to deal with your application's performance, high availability, and security. In other words, maintaining the efficiency and security of the Identity management solution is entirely up to you. You will have to follow the evolutions of the chosen self-hosted solution and apply updates promptly after verifying them. You will have to deal with scaling the authentication system as the number of users and concurrent requests grows. You will have to learn to do a job that is probably not yours.

Cloud-based solutions such as [Auth0](https://auth0.com/) offer you significant benefits in this regard.  
In addition to [features](https://auth0.com/features) that certainly go beyond those offered by self-hosted solutions and advanced customization possibilities, a cloud solution like Auth0 allows you to delegate the task of taking care of the security and maintenance of the Identity management of your application. No need to keep the system updated and take care of configuring the entire infrastructure to keep the identity of your users safe. In addition, you can take advantage of advanced security tools such as Anomaly Protection, Brute Force Protection, Bot Detection, and other features to armor your application's authentication system.

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

## Wrapping Up

Choosing the right IAM solution depends on your specific needs and priorities. If you're building a simple application and need basic user management, ASP.NET Core Identity might be sufficient. For complex scenarios requiring SSO, federation, or advanced security features, IdentityServer or Keycloak are excellent self-hosted alternatives. If you prefer to offload the complexities of IAM and prioritize scalability and ease of use, a managed solution like Auth0 is a great option.

Here is a table that summarizes the main features supported by ASP.NET Core Identity compared with Identity Server, Keycloak, and Auth0 for your quick reference:

![Comparison table between ASP.MET Core Identity, Identity Servre, Keycloak, and Auth0](https://images.ctfassets.net/23aumh6u8s0i/4LpbsTxQhzyj2LXjULjWBz/29e1ddd3c5f245901ea9d951a98ea2a5/aspnet-core-identity-keycloak-auth0-comparison-table.png)

Remember to carefully evaluate your requirements and consider the tradeoffs between cost, complexity, and control before making a decision.  


When ASP.NET Core Identity Is No Longer Enough

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

Staff Developer Advocate

Juan Cruz Martinez

Discover the Model Context Protocol (MCP) and its authorization mechanisms. Learn how to use API keys, OAuth 2.1 implementation, and best practices for secure LLM API connections.

An Introduction to MCP and Authorization

deepu-sasidharan

Deepu is a polyglot developer, Java Champion, and OSS aficionado. He mainly works with Java, JS, Rust, and Golang. He co-leads JHipster and created the JDL Studio and KDash. He's a Staff Developer Advocate at Okta. He is also an international speaker and a published author.

Deepu K Sasidharan

Discover how AI agents are taking center stage by seamlessly integrating with multiple digital tools like Gmail, Calendar, Slack, and Google Drive to be more efficient. Learn why it is important to secure them and how to do it.

**AI agents** or **Operators** are the latest trend in AI. At their core, agents are autonomous systems that not only process natural language using Large Language Models (LLMs) but also decide when and how to act by interfacing with external tools and APIs. These smart entities blend machine learning with decision-making capabilities, enabling them to perform complex tasks, interact in real-time, use the most efficient tools to perform certain tasks, and even learn from their environment—all without constant human intervention.

<AmpContent>
<amp-youtube
    data-videoid="r7wEinUG0ns"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>

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

## Tool Calling Agents

LLMs on their own are still susceptible to hallucinations and mistakes, but the ability to call tools opens up a whole new world of possibilities where error-prone tasks can be offloaded to a more traditional non-AI tool, like using a calculator to do math rather than relying on the LLM for it. Similarly, tool calling allows AI agents to interface with other applications and services, like Gmail, Calendar, Slack, and Google Drive, to do more for you than just answering questions.

Tool calling can be generally classified into these:

1. **Unauthenticated Tools:** These are tools that don't require authentication and are generally simpler to configure, like a calculator, a weather API, or a unit converter.
2. **Authenticated Tools:** These are tools that require authentication and are generally complex to configure, such as an API provided by another internal application or services like Gmail, Calendar, Slack, and Google Drive.

In an enterprise environment, the authenticated tools can be further classified into:

1. **First-Party Tools:** These are services that are part of the same infrastructure and require authentication, like an API provided by another internal application or a microservice.
2. **Third-Party Tools:** These are external services that require more complex authentication. They could be services that are authenticated using service accounts or API keys, like a payment API, or services that need to be authenticated by the end user, such as Gmail, Calendar, Slack, and Google Drive.

Tool calling provides many key advantages to an AI agent:

- **Autonomous Decision-Making:** AI agents analyze context and determine the next best action, reducing the need for manual oversight.
- **Optimized Task Execution:** They can connect to various services and APIs, enabling them to perform specialized tasks like data retrieval, scheduling, and communication.
- **Scalability and Adaptability:** As systems evolve, agents can easily incorporate new functionalities, adapting to changes in workflow or priorities.
- **Improved User Experience:** Their ability to tackle diverse tasks leads to more personalized and efficient interactions, making technology feel both intuitive and proactive.

## Tool Calling Agent: A Conceptual Example

Imagine an AI personal assistant that consolidates your digital life by dynamically accessing multiple tools to help you stay organized and efficient. Here’s how it could work:

1. **Gmail Integration:** The assistant regularly scans your inbox to generate concise summaries. It highlights urgent emails, categorizes conversations by importance, and even suggests drafts for quick replies.
2. **Calendar Management:** By interfacing with your calendar, it can remind you of upcoming meetings, check for scheduling conflicts, and even propose the best time slots for new appointments based on your availability.
3. **Slack Notifications:** For team communications, the assistant monitors Slack channels. It identifies key messages and creates action items, ensuring you never miss an important update from your colleagues.
4. **Google Drive Access:** Whether you need immediate access to the latest project document or a file related to a current task, the assistant retrieves pertinent documents from Google Drive on demand. It can create document summaries and even create new documents based on your instructions.

With tool-calling capabilities, the possibilities are endless. In this conceptual scenario, the AI agent embodies a digital personal secretary—one that not only processes information but also proactively collates data from connected services to provide comprehensive task management. This level of integration not only enhances efficiency but also ushers in a new era of intelligent automation, where digital assistants serve as reliable, all-in-one solutions that tailor themselves to your personal and professional needs.

## Security Challenges with Tool Calling AI Agents

Building such an assistant is not that difficult. Thanks to frameworks like [LangChain](https://www.langchain.com/), [LlamaIndex](https://www.llamaindex.ai/), and [Vercel AI](https://vercel.com/ai), you can get started quickly. The difficult part is doing it securely so that you can protect the user's data and credentials.

Many current solutions involve storing credentials and secrets in the AI agent application’s environment or letting the agent impersonate the user. Storing credentials securely in the environment might work for APIs that require API keys or service accounts. However, this is not a good idea for cases where the end users need to authenticate to the service, as it can lead to security vulnerabilities and excessive scope and access for the AI agent.

<br>

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487 icon-info"></i>
  <b>To learn more about other security concerns and vulnerabilities in AI check out this blog post on <a href="https://auth0.com/blog/identity-challenges-for-ai-powered-apps/">Identity Challenges for AI-Powered Applications</a>.</b><br> 
</div>

When you build an AI agent, you need to consider all its other security implications as well. You don't want an LLM to have unlimited access to your personal data like email and documents, and more importantly, you don't want to provide your credentials to the LLM to access these tools. Let's face it, regardless of how secure the LLM is, there is always a possibility of it getting manipulated into divulging sensitive information or doing something you don't want it to do.

## Tool Calling with the Help of Auth0

This is where Auth0 comes to the rescue. As the leading identity provider (IdP) for modern applications, our upcoming product, [Auth for GenAI](https://auth0.com/blog/auth-for-genai/), provides standardized ways built on top of OAuth and OpenID Connect to call APIs of tools on behalf of the end user from your AI agent.

Auth0 brokers a secure and controlled handshake between the AI agents and the services you want the agent to interact with on your behalf – in the form of scoped access tokens. This way, the agent and LLM do not have access to the credentials and can only call the tools with the permissions you have defined in Auth0. This also means your AI agent only needs to talk to Auth0 for authentication and not the tools directly, making integrations easier.

### Call first-party APIs on users' behalf

When your AI agent, secured with Auth0, needs to call another application also secured with Auth0, you can use standard OAuth 2.0 flows, like the [Authorization Code Flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow), to get an API token from that application with user consent. In this case, Auth0 will manage the retrieval of new access tokens using cached refresh tokens when the API token expires.

### Call third-party APIs on users' behalf

When your AI agent, secured with Auth0, wants to call external services like Gmail, Calendar, Slack, and Google Drive, Auth0 can help the agent get access tokens for the external service on behalf of the end user. In this case, Auth0 brokers the API access token from the external service to the AI agent.

![Tool calling with Federated API token exchange](https://images.ctfassets.net/23aumh6u8s0i/1gY1jvDgZHSfRloc4qVumu/d44bb7102c1e858e5ac64dea324478fe/tool-calling-with-federated-api-token-exchange.jpg)

This is made possible by Federated API token exchange, which is a way to obtain an access token from an external identity provider without the need for the user to re-authenticate every time. The end user authenticates and connects the external service once, and Auth0 intermediates the authentication and authorization process and provides the API access token to the AI agent. Auth0 takes care of storing refresh tokens and getting new access tokens when the current access token expires.

## Security Best Practices for Tool Calling AI Agents

Here is a summary of security best practices to consider when building a tool-calling AI agent:

- **Least Privilege**: Grant the minimum permissions needed (e.g., read-only access).
- **Audit Logs**: Track API calls and credential usage.
- **Proxying**: Use an IdP like Auth0 as a broker between the AI agent and the tools to protect the user's credentials.
- **Encryption**: Encrypt credentials at rest and in transit (HTTPS/TLS).
- **Token Rotation**: Regularly rotate API keys and tokens.
- **Sandboxing**: Run tools in isolated environments when possible to limit damage from leaks.

## Learn More about AI Agents and Auth for GenAI

This post offers a glimpse into the transformative potential of AI agents and highlights how secure and intelligent tool calling can empower AI agents to deliver a more connected and personalized experience. Stay tuned for a series of posts on tool-calling Agents with [Auth for GenAI](https://a0.to/ai-content), where we will build the conceptual personal assistant from the previous section in Node.js and Python, showing how to integrate with different types of services securely using your favorite AI frameworks and Auth0.

Before you go, we have some great news to share: we are working on more content and sample apps in collaboration with amazing GenAI frameworks like [LlamaIndex](https://www.llamaindex.ai/), [LangChain](https://www.langchain.com/), [CrewAI](https://www.crewai.com/), [Vercel AI](https://vercel.com/ai), and [GenKit](https://firebase.google.com/docs/genkit). [Auth for GenAI](https://auth0.com/blog/auth-for-genai/) is our upcoming product to help you protect your user's information in GenAI-powered applications. Make sure to join the [Auth0 Lab Discord server](http://a0.to/auth0-lab-discord) to hear more and ask questions.

Tool Calling in AI Agents: Empowering Intelligent Automation Securely

For developers tasked with building global applications, choosing the right authentication solution is crucial. Auth0's ability to bridge the gap between enterprise and consumer needs makes it a standout choice in the crowded authentication landscape.

In today's multi-platform world, identity management isn't a one-size-fits-all solution. As developers, we need an authentication system that not only secures enterprise-level applications (B2B) but also delivers a seamless, user-friendly experience for consumer-facing products (B2C). That's why developers across the world turn to Auth0 when they feel it's time to delegate the task of building and maintaining ***authentication and authorization*** to a vendor with deep security expertise and adaptable technical capabilities. 

## The Challenge of Global Scale

Global companies with multifaceted portfolios face a unique set of challenges:

- **Multiple Platforms:** Users access their services via smartphones, PCs, consoles, and more.

- **Diverse Regulatory Requirements:** Compliance with international data privacy and security regulations is non-negotiable.

- **Customization Needs:** Every organization has its own unique workflows and integration requirements, such as compatibility with legacy authentication systems or [support for protocols like SCIM](https://auth0.com/docs/authenticate/protocols/scim).

For developers building at a global scale, the solution needs to be robust enough to handle high security and regulatory demands while remaining flexible for rapid development and global expansion.

## Why Auth0 Stands Out

Auth0's strength lies in its ability to effectively serve both B2B and B2C needs across geographical regions. Here's what makes it a compelling choice:

### Dual capability

Auth0 is built to handle both enterprise-grade integrations and consumer-friendly interfaces. While many competitors specialize in one or the other, Auth0 offers the best of both worlds.

### Robust security

With advanced features like multi-factor authentication (MFA), threat detection, and continuous monitoring, Auth0 meets stringent global security standards—critical for protecting sensitive user data and adhering to mandatory compliance requirements. Don't let regulation get in the way of expansion.

### Scalability

Whether you're serving thousands or millions of users across different regions, Auth0 scales seamlessly. This is vital for companies that operate in a global marketplace.

### Flexible customization

Auth0 allows extensive customization through robust APIs that support multiple programming languages and frameworks. This flexibility means you can tailor the authentication process to meet your specific needs, ensuring a smooth user experience regardless of the platform. Whether you are building the next top-ranking mobile game, a desktop AI application, or a streaming service, Auth0 has a solution that adapts to the user experience you want to attract, convert, and retain paying customers.

### Comprehensive support
 
Transitioning to a new authentication system can be complex. Auth0's professional services and support ensure that even challenges like regulatory compliance or cloud infrastructure migrations (e.g., AWS) are managed efficiently.

## Auth0 Is Ahead of the Competition

While there are strong contenders in the IDaaS space, they often excel in more niche areas. A competitor may be a strong option for enterprise integrations but may require extra effort to tailor it for consumer-facing applications. Some competitor platforms often focus on streamlined, developer-friendly solutions for either simple consumer apps or internal enterprise tools. However, they might not offer the same depth of customization and B2B/B2C functionality required for complex global environments or operations.

Auth0's proven track record in both B2B and B2C scenarios makes it uniquely suited for organizations that need a versatile, scalable, and secure authentication solution.

## See Auth0 in Action

Seeing is believing. Experience Auth0's power firsthand by diving into our developer resources. There, you can quickly set up secure authentication flows for both business and consumer scenarios.

### Interactive demo
   
Try out [our reference B2B SaaS application](https://saastart.app/) to experience features of multi-tenancy support, user management and access controls, security policies, self-service Single Sign-On configuration, and more out-of-the-box. Follow our [guided walkthrough](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-saastart/) to see how easily Auth0 can secure B2B SaaS applications. If you prefer to learn while reading code, check out the [Auth0 B2B SaaS Starter open-source repo](https://github.com/auth0-developer-hub/auth0-b2b-saas-starter).

### Step-by-step developer guides

Check out our [detailed developer guides](https://developer.auth0.com/resources/guides) on integrating strong authentication using Auth0 with different frameworks and languages. These guides will show you how to implement everything from simple login pages to role-based access control in Single-Page Applications (SPAs), APIs, and web applications. Once you are done with the basics, explore our [developer labs](https://developer.auth0.com/resources/labs) to learn how to extend your authentication solution to include features such as Single-Sign On (SSO) for end-users using Google, GitHub, or X/Twitter, as well as enhancing your authorization models with Fine-Grained Authorization.

### Code samples

[Clone any of our starter projects](https://developer.auth0.com/resources/code-samples) and see practical examples of how Auth0 streamlines the implementation of authentication and authorization. Experiment with the code, tweak it to suit your needs, and accelerate your development process.

## Conclusion

For developers tasked with building global applications, choosing the right IDaaS solution is crucial. Auth0's ability to bridge the gap between enterprise and consumer needs—coupled with its robust security, scalability, and flexibility—makes it a standout choice in the crowded authentication landscape. 

If you're developing a platform that must meet both B2B and B2C demands on a global scale, Auth0 is definitely worth a closer look. [Global companies like SEGA have chosen Auth0](https://www.okta.com/jp/press-room/press-releases/sega-auth0/) as a comprehensive and compliant yet flexible authentication solution that not only enhances security and user experience but also streamlines development and operational efficiency: by opting for a ready-to-use IDaaS solution rather than maintaining an in-house system, SEGA was able to lower development friction, allowing their teams to focus more on core game development and innovation.

Authentication and Authorization For Developers Who Build at Global Scale

carla_urrea

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

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

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

Senior Developer Advocate

Carla Urrea Stabile

The way to implement an authorization system depends on your application's needs. Let's explore Relationship-Based Access Control (ReBAC) and implement it in a Rails API using OpenFGA.

How to Implement Relationship-Based Access Control (ReBAC) in a Ruby On Rails API?

tyler-nix

Tyler’s professional experience spans engineering, architecture, sales, and product at companies ranging from a small Series B startup to a large Fortune 5 enterprise. He now uses his diverse experiences to build better products at Okta. When he is not scaling digital products, he is pursuing hobbies that inherently don’t scale (especially those outside). He loves hearing his kids laugh while riding bikes, spotting a new bird species, and watching his garden grow.

Product Manager

Tyler Nix

Learn how the ReBAC authorization model overcomes RBAC when it comes to evaluate permissions on a specific resource.

In today’s dynamic digital landscape, ensuring users have the right permissions for specific resources is a critical task for any organization. Resource-based access control often needs to be highly fine-grained, especially in complex systems with millions of objects—such as files, projects, records, accounts, etc.

Yet building fine-grained authorization (FGA) correctly with traditional Role-Based Access Control (RBAC) presents several challenges, particularly when it comes to protecting against the top vulnerability in web applications: [Broken Access Control](https://owasp.org/Top10/A01_2021-Broken_Access_Control/).

RBAC itself isn't inherently problematic. But when you try to build fine-grained authorization on top of RBAC, the struggle creeps in. However, this is where Relationship-Based Access Control (ReBAC) shines: evaluating permissions on a per-resource basis. ReBAC makes it simple to perform an authorization check on complex permission models.

## The Difficulty of Building Fine-Grained Authorization with RBAC

[RBAC](https://auth0.com/docs/manage-users/access-control/rbac) has been the go-to method for managing access control in many applications. In RBAC, users are assigned to roles (e.g., admin, editor, viewer), and roles are mapped to permissions that give access to various resources.

A common approach to evaluating access to a resource in an application is to include the permissions in a user’s access token as scopes. However, since most scopes are generic and binary (e.g. `_view_all_documents_`), it would be difficult to manage detailed, resource-specific scopes (e.g. _view_document_123_) by adding them to the token because it would lead to token bloat. Additionally, since scopes in a token are static by design, they cannot easily reflect real-time permission updates until the token is refreshed.

Because of this, developers will often implement their own custom FGA solutions using RBAC built with SQL tables to unlock more dynamic and real-time access control. But this approach isn’t without its issues.

As systems grow and product improvements require more intricate resource hierarchies, the need to manage numerous roles, users, and resource-specific permissions leads to messy databases and unruly SQL queries, which often involve multiple joins spread out across database tables or services.

In contrast, [(ReBAC)](https://docs.fga.dev/authorization-concepts#what-is-relationship-based-access-control) models permissions based on relationships between users and resources, simplifying the evaluation logic. With ReBAC, permissions are dynamic and context aware. While you can fully implement RBAC roles within ReBAC, it also allows for more granular control over who can do what with each resource.

## Evaluating Resource-Specific Permissions with RBAC

Let’s consider an example: In a project management application, Aria is the admin for her entire organization. She is thus granted permissions to view and edit all documents in any project. The developers of the application have chosen to implement resource-specific authorization by building RBAC in SQL tables.

How do we determine if Aria has access to view a specific document? She would not have any direct assignments because she is not the document creator, but she should inherit the “editor” permissions since she is the organization’s admin. Evaluating this resource-specific authorization check in RBAC would require joining the various database tables that contain the role assignments and resource hierarchies in the organization to see if her "admin" role cascades down to that specific document.

As a result, with each permission check requiring more complex SQL queries, the application’s authorization logic becomes difficult to manage and even harder to update, possibly even leading to performance issues with deeply nested resources.

## How ReBAC Simplifies Resource-Specific Permission Checks

With ReBAC, permissions are calculated based on relationships instead of explicitly assigned roles, simplifying the evaluation of who has access or not. In a ReBAC system, Aria’s permissions aren’t solely based on her role but also on her role’s relationships with a document. Since Aria is the admin of the organization, the relationship can be cascaded down from the organization level via inheritance to a specific project or document level.

When you need to make an authorization check on a specific resource, the authorization system references the logic defined in the authorization model against the known object relationships and returns a decision (i.e. true or false). “_Can Aria edit the document business-report-1?_” = TRUE. We’ll learn later why this authorization check can be so simple.

> ReBAC makes it far more efficient than RBAC to check access on a per-resource basis.

## Evaluating Permissions with Okta Fine Grained Authorization

Now, let’s explore how Okta Fine Grained Authorization, a hosted and managed service of the popular open-source ReBAC project OpenFGA, leverages relationship-based access control to simplify access management.

Okta Fine Grained Authorization is designed to be flexible enough to work for small startups scaling single applications but powerful enough for large enterprise corporations creating complex relationships at a global scale. It does all of this while staying friendly enough for adjacent stakeholders on the team to read and understand the authorization logic.

Let’s build on the practical example above of Aria being an admin in her project management company. Suppose you have a hierarchical system in which different teams have access to various documents in a project based on the user's assignment.


### Sample Authorization Model in Okta Fine Grained Authorization

```bash
model
   schema 1.1

type user

type organization
  relations
    define admin: [user]

type project
  relations
     define organization: [organization]
     define owner: [user] or admin from organization
     define member: [user]
     define viewer: member or owner

type folder
  relations
     define parent: [folder, project]
     define owner: owner from parent
     define viewer: viewer from parent or owner

type document
  relations
     define parent: [folder]
     define editor: [user] or owner from parent
     define viewer: [user] or viewer from parent or editor
```

In this model, there are five core “types”: `user`, `organization`, `project`, `folder`, and `document`. Each plays a specific role in managing access within the system.

- `User` represents the individuals who will interact with the system. Users are assigned roles and permissions either directly or through group memberships.
- `Organization` contains all the projects with the ability to assign a global admin (like Aria).
- `Project` contains members, controlling access to project documents through membership at a top-level project.
- `Folder` adds a hierarchy to managing resources, connecting users to documents, even through deeply nested folders.
- `Document` inherits access permissions from their parent folder, which ultimately inherits from the project, all while allowing direct assignment to enable use cases like sharing a document with an external user.

A typical authorization scenario might look like this:

1. _Document_ business-report-1 is nested inside two _Folders_ under _Project_ Alpha.
2. _Project_ Alpha is a part of the Acme _Organization_.
3. Aria is assigned as the admin of the Acme _Organization_.

In Okta Fine Grained Authorization, these would be represented as relationship tuples stored in the centralized authorization system. You can think of Okta Fine Grained Authorization as a permissions database and tuples are the data. Each tuple will contain a user, relation, and object value like this:

```bash
{
  User: user:aria
  Relation: admin
  Object: organization:acme
}
```

Thus, following the logic in the authorization model, the access check for _“Can Aria edit the document business-report-1?”_ would return TRUE because:

1. Aria has the admin relationship in the Acme organization.
2. The admin relationship receives the owner relationship in the projects of that organization.
3. The owner relationship is thus inherited by the folders in that project.
4. Owner permissions continue to cascade down to the editor relationship of the documents inside the organization’s project folder, of which Aria is the admin.

![](https://images.ctfassets.net/23aumh6u8s0i/3pEKrtX5hEZrGMz2mT40RV/d13f7730b526aec43508c1f1294b37e3/01_rebac.png)

![](https://images.ctfassets.net/23aumh6u8s0i/65WRfIj3zGTtCo8S5dimhn/e8150eab044f6763069ff81cb42bf5c7/02_rebac.png)

## The Okta Fine Grained Authorization API

With ReBAC and Okta Fine Grained Authorization, querying permissions is as simple as checking a user’s relationship to a resource. Instead of performing multiple joins across tables as in RBAC, a single API call checks the relationship, making it highly efficient.

```bash
curl -X POST https://api.fga.dev/stores/{store_id}/check \
  -H "Authorization: Bearer {your_api_token}" \
  -d '{

    "tuple_key": {
        "user": "user:aria",
        "relation": "editor",
        "object": "document:business-report-1"
      }
}'
```

While RBAC is a powerful model for role-based permissions, it can struggle when adapted to manage fine-grained, resource-specific permission scenarios. Alternatively, ReBAC excels in dynamic, heavily-nested environments where permissions are based on inherited relationships between users and resources. By adopting ReBAC (and using a platform like Okta Fine Grained Authorization), development teams can streamline how they handle complex access control in their applications, reducing the major risk of broken access control that can stem from complex database queries. Try [Okta Fine Grained Authorization](https://auth0.com/fine-grained-authorization) for free.

### Additional Resources

- [https://fga.dev](https://fga.dev/)
- [FGA Playground](https://play.fga.dev/)
- [Fine-Grained Authorization in your Next.js application using Okta FGA](https://auth0.com/blog/fine-grained-access-control-with-okta-fga-nextjs/)
- [FGA Modeling Guide Video Series](https://www.youtube.com/watch?v=8VGy52SQ8bw)

How To Evaluate Resource-Specific Permissions Efficiently with ReBAC instead of RBAC

peterfernandez_360

As an Architect, Consultant, and Engineer, I have more than 30 years of experience designing and developing secure and robust software solutions. When not helping teams deal with the complexities of Customer Identity, you can usually find me working behind the scenes, acting in or directing a show at my local theatre.

Peter Fernandez

Why a Multi-Tenant approach is fundamental to B2B SaaS, and how using Auth0 and the Auth0 Organizations feature can help implement it.

Demystifying Multi-Tenancy in a B2B SaaS Application

Whilst Administration is a fundamental aspect of any application, discover how it takes on a whole new dimension in the world of B2B SaaS!




## What's Next?

In this article, I've walked through the details of Multi-Tenancy in a B2B SaaS Application and also provided some insight together with code examples for how I'm integrating with Auth0 to help build multi-tenancy in my application, TheatricalPA. I'll be writing more about the other topics I've mentioned in this article in the near future, so be sure to watch out for those. In the meantime, feel free to comment below and tell us what you think - we always love to hear feedback, positive or otherwise, as it helps us to improve our content! Thank you. Aside from that, here are some additional resources you might like to follow up on that can help you on your journey. Have fun, and I'll catch up with you next time! 🤗

* [_Speed up Your Customer Identity Journey with Auth0 SaaStart_](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-saastart/)
* [_Auth0 Zero Index Newsletter_](https://developer.auth0.com/newsletter)


Vendor vs Subscriber Administration: a Delegated Admin Story

paulo-nascimento

Paulo Nascimento is a Machine Learning Engineer at Okta, spearheading AI development for the Customer Identity Cloud (CIC). He brings expertise from AI startups to create innovative solutions powering the CIC organization. Paulo's work focuses on integrating AI technologies to strengthen enterprise security, enhance user experience, and drive intelligent automation across Okta's identity platform.

Machine Learning Engineer

Paulo Nascimento

Waleed Manzoul

Staff Product Designer

Automate user lifecycle, enhance security and boost IT efficiency across your enterprise

## Introduction

Consider a Fortune 500 company, like a bank with 40,000 employees. A financial analyst at this company will use many SaaS tools to do their job, like Slack, Google Suite for Work, Zoom, Tableau, Workday, and more. In fact, enterprise organizations rely on [an average of 211 apps each](https://www.okta.com/businesses-at-work/) to run their businesses.

So, the bank’s central IT team might be responsible for managing 200+ SaaS apps, and our financial analyst may need access to a quarter of them. Naturally, for an employee to use all of those apps, accounts for each one would need to be provisioned first.

Fortunately, our bank’s IT team is smart. They utilize [Okta Workforce Identity Cloud](https://www.okta.com/workforce-identity/) to maintain [a directory of all their employees](https://www.okta.com/products/universal-directory/) and enable easy account creation and access to those SaaS apps using [Single Sign-On](https://auth0.com/docs/authenticate/single-sign-on). That means they don’t have to manually provision SaaS apps every time a new employee joins the company or an existing employee needs access.

But what about other events in an employee’s time with the company, such as when they change their role, change their name or pronouns, or eventually leave the company? How many times might those events happen over 40,000 employees? And how might each of those changes be reflected in the SaaS apps that they use?

## User Lifecycle Management Using SCIM

Fortunately, if a SaaS app used at the company relies on a workforce provisioning engine that utilizes SCIM ([System for Cross Identity Management](https://scim.cloud/), a standard for automating the exchange of user identity information between identity domains), that app can synchronize its user list to the central employee directory and react to changes that happen in the directory.

For the bank’s central IT team, this means they can make updates to users once in their central employee directory and have those changes reflected in all of the SaaS apps an employee uses, **reducing administrative overhead and toil**.

The power of this “live” connection that SCIM provides becomes critical when an employee leaves the company. Once central IT deletes this employee from their central directory, any user accounts they had with those SCIM-powered SaaS apps will be deactivated within seconds, **eliminating the chance of unauthorized access** through “[zombie accounts](https://www.wsj.com/tech/cybersecurity/unused-online-accounts-data-safety-38fa675e)” and **maintaining compliance with data privacy regulations**, like [GDPR](https://gdpr-info.eu/art-5-gdpr/).

Timely deprovisioning of former employees can have **cost savings** as well. When an employee leaves, the central IT team can quickly release the employee’s SaaS licenses and accurately reflect the reduced spend to the respective vendors.

So, you can imagine that the bank’s central IT team would want any new SaaS app it evaluates to leverage SCIM due to its many benefits:

* Saves a lot of manual labor
* Improves their security posture
* Saves their company money

## How Does SCIM Provisioning Work?

SCIM works by providing a defined schema of identity data that represents users and groups, along with a REST API that supports JSON and XML for CRUD operations on those user and group resources. 

Behind the scenes, SCIM is broken down into a few core components:

* SCIM Service Provider
    * This service hosts the identity data and responds to SCIM API requests. It’s also commonly called a SCIM server.
    * _Examples: Cloud applications, identity providers (e.g., Okta)_
* SCIM Client
    * The SCIM Client **initiates SCIM requests to interact with a SCIM server to perform operations that manage identities.**
    * _Examples: Identity management systems, HR systems_
* SCIM Schema
    * The SCIM schema defines the structure of identity data.
    * Core schemas: User, Group, EnterpriseUser (defined in [RFC7643](https://datatracker.ietf.org/doc/html/rfc7643))

The SCIM core components then use an HTTP-based REST API that supports JSON and XML data formats, although JSON is more common. The REST API uses standard HTTP methods like GET, POST, PUT, PATCH, and DELETE to support CRUD operations.

SCIM supports a number of key operations, such as:

* User Provisioning
    * The ”SCIM Client” sends a POST request to create a new user, and the ”SCIM Provider” creates the user and returns a unique identifier (ID).
* User Retrieval
    * The ”SCIM Client” sends a GET request with the user ID or search criteria, and the ”SCIM Provider” returns user data that matches the request, provided the user exists.
* User Update
    * The ”SCIM Client” sends a PUT or PATCH request with the updated user data, and the ”SCIM Provider” applies changes and confirms the update.
* User Deprovisioning
    * The ”SCIM Client” sends a DELETE request, and the ”SCIM Provider” removes or deactivates the user account.

On top of this core functionality, SCIM also provides useful features such as: 

* Bulk Operations
    * Where batch processing can be applied for multiple SCIM operations in a single request
* Filtering and Searching
    * Allows complex queries to find specific users or groups by using a standardized filter syntax

For each request, the SCIM REST API will return with the appropriate HTTP status to indicate success or failure along with detailed error messages for troubleshooting. SCIM typically uses OAuth 2.0 for authorization and supports HTTPS for secure data transmission.

SCIM is also extensible, which means that organizations can extend the standard SCIM schemas to accommodate their specific needs. For example, if an organization wants to include additional information about employees not covered by the standard SCIM schemas, then they can store additional information such as ”department” or ”manager” in their user profiles.

## SCIM vs SAML

Security Assertion Markup Language (SAML) is an XML-based framework for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). It’s most commonly used to enable Single Sign-On (SSO) across different web applications and services.

SCIM and SAML are both protocols for identity and access management (IAM). However, they serve different purposes. 

SCIM is used for user provisioning and management across different systems and applications, ensuring that identity data is consistent across. SAML, on the other hand, is used to access multiple applications with a single set of credentials.

> In summary, SCIM is for user management, while SAML is for user authentication.

## SCIM vs. SSO

Single Sign-On (SSO) is an authentication method that allows users to sign in to multiple applications with a single set of credentials.

Although SCIM and SSO are related, SCIM is a protocol used for provisioning appropriate roles and groups to users, whereas SSO authenticates those users into multiple accounts with a single set of login credentials.

## Inbound SCIM with Auth0

If you’ve been reading about SCIM online, you’ve probably found identity providers like Okta Workforce Identity Cloud and Microsoft Entra ID support SCIM in different ways, and that building for each of them can become a substantive effort. We’d advise that you learn about the identity providers your customers use and tailor your SCIM solution to meet the majority of your customers. However, If you think you will need to integrate your development with more than one identity provider, don't despair: there are solutions that allow you to easily connect to multiple identity providers at once. 

In fact, that's one of the things we do at Auth0. Our [Inbound SCIM solution](https://auth0.com/docs/authenticate/protocols/scim) allows you to integrate with Okta Workforce Identity Cloud, Microsoft Entra ID, and other identity providers via both SAML and OpenID Connect, manage attribute mappings on a per connection basis, and more. 

## Conclusion

SCIM is a powerful way to automate user lifecycles and maintain user accounts across platforms that can save companies time, money, and increase their security. Learn more about SCIM by exploring the [Auth0 docs](https://auth0.com/docs/authenticate/protocols/scim). 


Streamline Account Provisioning and Management with SCIM

abhi

Abhishek Ambastha is a Group Product Manager with over 18 years of experience in security and identity solutions. At Okta CIC, he drives innovations to counter identity threats and enhance user security with seamless experiences.

Group Product Manager

Abhishek Ambastha

There are so many resources out there about passkeys and each vendor has its own implementation of the standard. Let’s answer some of your frequently asked questions about passkeys at Auth0!

There are so many resources for passkeys, and each vendor has its implementation of the standard. 

If you still need to familiarize yourself with passkeys, I recommend you look at this [blog post](https://auth0.com/blog/webauthn-and-passkeys-for-developers/).

Now, let's answer some of your frequently asked questions about passkeys at Auth0!

## Can I Use Passkeys With The Free Tier?

Starting with the elephant in the room, let's leave this clear here and now: **Passkeys are included in ALL PLANS**, yes, including the Free Tier, at no additional cost. We really, really are aiming for a passwordless future, and this is part of our commitment to it. 

## Migrating from Passwords to Passkeys

The industry is moving towards a passwordless future, and at Auth0, we are committed to the same goal. 

<include src= "LearnPasskeysCTA"/>

### Is Auth0 getting Rid of Passwords Entirely?

Not yet. For now, we introduced passkeys as an additional authentication option alongside passwords. Users can choose between a passkey and a password based on what works best.

### Can your Users Only Use a Passkey for Login?

Yes, absolutely. End users can sign up and log in using only passkeys, providing a completely passwordless experience. Passkeys serve as a robust first and primary factor for account authentication, designed to enhance security and offer a more user-friendly experience. The goal is eventually to replace passwords.

### Can your Users Continue to Use Passwords for Signup & Login?

Yes. If passkeys are enabled in the configuration, end users will be prompted to continue with a passkey or a password.

<img src="https://images.ctfassets.net/23aumh6u8s0i/AbdRxr97bTLiR7ciHSFMs/9d8d9592d5b26a9b7dfa80271831c07c/passkeysprompt.png" alt="passkeys prompt" width="300"/>

### What About the Existing Users with Passwords?

When you enable progressive enrollment in the Auth0 Dashboard, existing users with passwords will be prompted to add a passkey so that they can use it in subsequent logins.

### Does Auth0 Support a Passkey-Only Flow (a flow where there is no password involved anywhere)?

Not at the moment. We are keeping the option of using passwords alongside passkeys; there are still some challenges regarding compatibility issues with older devices or browsers that need passkey support. In such cases, passwords will remain a viable method of authentication. 

In other words, **disabling password is not yet supported in the Database connection.**

![Username-Password DB Connection on passkeys config page](https://images.ctfassets.net/23aumh6u8s0i/3e3aJQhXISfjet2Pb3qvT2/6218e3ad3cdca472faafb23f06a7c06b/passkeys-db.png)

### Which Device and Browser are Compatible with Passkeys?

Passkeys are compatible with different operational systems and browsers at differing levels. Please refer [to `passkeys.dev` Device Support](https://passkeys.dev/device-support/) (maintained by [W3C WebAuthn Community Adoption Group](https://www.w3.org/community/webauthn-adoption/) and members of the [FIDO Alliance](https://fidoalliance.org/)) which provides latest information on device/browser support on passkeys.

> You can [learn more about passkeys and see them in action](https://youtu.be/v-KTu8W\_irM?feature=shared) in this excellent session from Oktane 2023. 

## Enabling Passkeys in Your Auth0 Tenant

You can enable passkeys by switching a toggle, and you can always refer to [the documentation](https://auth0.com/docs/authenticate/database-connections/passkeys) to understand how the signup and login flow with passkeys work at Auth0, but let's answer some more specific questions about enabling passkeys:

### How Can You Enable Passkeys for Your Users?

Passkeys are available in the Database connection section in the Auth0 Dashboard. You could enable passkeys by logging in to your Auth0 Dashboard and navigating to [Authentication -> Database](https://manage.auth0.com/\#/connections/database) -> Connection -> Authentication Methods -> Passkey as shown in the below screenshot.

![Username-password db connection page](https://images.ctfassets.net/23aumh6u8s0i/6ApYxla0hbMtXy6gEVwEpV/a2328b46620c5d74ad44d5b7b4294783/passkeys-rb-1.png)

For more details on enabling passkeys, follow the steps [in this blog post.](https://auth0.com/blog/activate-passkeys-let-users-log-in-without-password/) 

### Are there any prerequisites to enable passkeys?

Yes, passkeys come with specific prerequisites:

1. Enable New Universal Login: we encourage you to switch to New Universal Login, where new features like passkeys are being introduced.

2. Deactivate Custom Login Page: Enabling the Custom Login Page reverts the New Universal Login to the Classic experience, which connects to the first requirement.

3. Activate Identifier First Login: This facilitates a seamless user journey, beginning with the Identifier. Users can then decide whether to proceed with passkey or password authentication.

4. Deactivate Requires username: For connections that have not activated attributes for flexible identifiers, the username is not supported. To use passkeys with usernames, you will need to  [activate attributes for flexible identifiers](https://auth0.com/docs/authenticate/database-connections/activate-and-configure-attributes-for-flexible-identifiers) on the connection.

5. Disable Use my own database: Finally, "Use my own database" must be disabled unless Import Users to Auth0 is enabled as it implies passkeys created in the system will remain separate from user credentials stored in external custom databases (unless Lazy migration is ON).

If you are missing any of the prerequisites above, we will show a checklist similar to the image below when you try to enable passkeys for your users.

![passkeys pre-requisites](https://images.ctfassets.net/23aumh6u8s0i/2n9HEqIK9TN3Fep2VEaSpA/80016c1e19d9c713ecc6c20a034cdb51/passkeys-prereq.png)

### Is there any other important consideration for enabling passkeys?

An important point to note is **the [relying party](https://auth0.com/docs/glossary\#relying-party) domain should not change after passkeys are enrolled**, because changing the domain will invalidate all existing passkeys. As such, passkeys are created for a specific RP domain.

### Are there different options for logging in with passkeys?

Yes. You could choose how the passkey options are rendered in their end user prompts. This will control how the challenge is triggered. 

Two options are available for logging in with passkeys: **Passkey Button and Autofill.** By default, both options are enabled when passkeys are configured.

> As per [FIDO UX guidelines](https://fidoalliance.org/UX-guidelines/), FIDO research explored participants' success and satisfaction with dedicated passkey buttons and autofill. FIDO testing indicates that autofill ensured the highest success for people to sign in with a passkey.

However, it is essential to note that autofill does not work in all scenarios. For example, when autofill is disabled in the browser, the Passkey Button provides the fallback UX.

## Passkeys Configuration at Auth0

### What is Local Enrollment?

When you enable local enrollment and authenticate through the cross-device flow (using a QR code) across ecosystems, Auth0 will prompt the user to create a passkey on their second device. Local enrollment ensures secure and effortless logins, as the passkeys from the second device become accessible for subsequent logins. It also eliminates the need for the user to repeatedly use a QR code to log on to the second device; instead, they can simply utilize the local passkey for all subsequent logins.

### What is Progressive Enrollment?

Progressive enrollment allows Auth0 to prompt existing users with passwords to add passkeys so they can use them for their next login. 

### Why is Auth0 Skipping Captcha Verification When Passkeys are Selected?

Passkeys already offer a phishing-resistant authentication method. To achieve a faster, seamless, and secure login experience, adding additional friction during login steps like Captcha is not optimal. Hence, Captcha verification is presented, but users can skip this step when they select log in with a passkey. They still have to solve a Captcha if they're presented with one and choose to continue with the password.

### Does Auth0 have any limit on the number of passkeys per user?

Yes. For now, we've implemented a **limit of 20 passkeys per user.** A user could have multiple passkeys. For example, a user could create a passkey on Apple and Google devices when they authenticate via cross-device authentication using a QR code.

## Security & Attack Protection with Passkeys

### What if An Attacker Tries to Abuse a QR Code?

FIDO cross-device authentication incorporates an inherent verification mechanism utilizing Bluetooth technology to ensure the proximity of the two devices. While this process remains seamless for the user, potential attackers who acquire a QR code and attempt remote logins will be thwarted, as the cross-device authentication does not operate over remote connections. We're limiting the attack surface to a few meters of physical proximity instead of anywhere in the world, as with passwords.

### Is Bluetooth a Requirement for Cross-Device Authentication? How does it Impact the Overall User Experience?

Yes. The Bluetooth-based proximity verification for cross-device authentication happens seamlessly for the end user. If they have deactivated Bluetooth, a user-friendly prompt will guide them to enable Bluetooth when they scan a QR code for cross-device authentication.

### Are Attack Protection Features Applicable to Passkeys?

Yes. Certain attack protection features, such as Suspicious IP throttling, will be applicable for passkeys. Credential Guard is skipped when utilizing a passkey due to the absence of a password. While Bot Detection will operate during the pre-login assessment phase, the Captcha verification step is bypassed when opting for passkey-based logins.

### What if MFA is Enabled in the Flow?

The MFA policy will continue to apply for login with passkeys. This implies that users will be prompted with a second factor depending on their MFA configuration. If you choose to bypass a second factor, you could implement custom logic when a passkey is used as an authentication method.

### Can I use Passkeys as a Second Factor?

Not for now. Passkeys are the first and primary factor for account authentication, designed to enhance security and offer a more user-friendly experience. The goal is to eventually replace passwords.

## Managing and Handling Passkeys

### How can you debug passkeys in your tenant logs?

Passkeys are an additional authentication method. Therefore, we're repurposing existing event codes outlined in [Log Event Type Codes](https://auth0.com/docs/deploy-monitor/logs/log-event-type-codes). However, to enhance clarity regarding the employed authentication method, we've incorporated the following elements:

* Signup: The event with type `ss` will include a field `details.authentication_method` set to either `password` or `passkey` based on the method used during signup.

* Login: For passkey-based logins, `"performed_amr": ["phr"]` is included. During login, the event with type `s` indicates if a passkey is used to authenticate. The `details.prompts` array contains the set of prompts that the end-user navigated through, and the `"performed_amr": ["phr"]` will be present on the element if passkey authentication was used (`phr` stands for "phishing-resistant" and is the standard amr (Authentication Method Reference) claim value for passkeys).

* Progressive & local enrollment: Successful enrollment will be captured with `gd_enrollment_complete`, while failed enrollment attempts will be recorded as `gd_webauthn_enrollment_failed`.

### Can you Use Passkeys with the Management API?

Yes, you can list and revoke passkeys using the Auth0 Management API. You can learn more about [managing passkeys with this blog post.](https://auth0.com/blog/passkeys-management/) 

### Can you Use Passkeys with Actions?

Yes. You can, for example, detect whether a user authenticates with a passkey within the [Post-Login trigger](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow).

In the event object, the `authentication.methods` array contains elements describing the methods used to authenticate for the current session. The elements' names are set to `pwd` for regular password-based authentication and `passkey` for passkey-based authentication.

## Account Recovery

### How can users recover their passkeys?

Auth0 stores a record of public information about your passkey (such as the public key) that you can use for authentication. As passkeys are stored within their respective ecosystems (like Apple or Google) and not shared with the relying party (such as Auth0), end users must retrieve passkeys directly from these ecosystems when needed. 

### How could users recover an account?

The existing account recovery process remains unchanged. Users will still need to verify their email by clicking the link in their inbox. Following successful verification, they'll have the option to set up a new password.
 

We hope this passkeys FAQ helps you leave passwords behind and enable passkeys for your users today. If you have other questions, make sure to post them in the comments, and our team will be happy to help! 

All You Need To Know About Passkeys at Auth0!

There are different ways to implement an authorization system and the one you choose depends on your application's needs. Attribute-Based Access Control (ABAC) is just one of them, so let's go ahead and learn how to implement it in a Rails API.

Previously on your access control series \*read with TV show presenter's voice\*... You learned about [Role-Based Access Control (RBAC) and how to integrate it into your Rails API](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/).
In this blog post, you’ll continue learning about different authorization systems, this time about Attribute-Based Access Control and how to migrate the access control of the expense management API from RBAC to ABAC. 

<details>
<summary>Starting from here?</summary>

If you want to start this tutorial from the beginning, [start from this blog post.](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/)

Clone the application repo and check out the `add-rbac` branch:

``` bash  
git clone -b add-rbac https://github.com/auth0-blog/rails-api-authorization 
```

Make the project folder your current directory:

``` bash  
cd rails-api-authorization
```

Then, install the project dependencies:

``` bash  
bundle install
```

Then, setup the database

``` bash
  rails db:setup
```

Finally, create a `.env` hidden file:

``` bash  
touch .env
```

Populate `.env` using the `.env.example` file:

``` bash  
cp .env.example .env
```

Add your Auth0 configuration variables to the .env file and run the project by executing the following command:

``` bash  
rails s
```

</details>

## What Are Attributes in the Context of Access Control?

Let's consider the use case of the expense management API you are using in this tutorial. For RBAC, you created an `admin` role and assigned it to users using Auth0 Actions. Users with the `admin` role can approve and review expenses, and so far, that's so good. 

The following requirement you have is that only certain users can do certain things on specific expense reports: 

- Users can only see a report they own (submitted by them)
- Users can only see a report if they are the approver
- Users who are approvers can only *approve* reports on weekdays (we don't want people working on weekends!)

With the current RBAC implementation, a user with the `admin` role can do all of these things, but unfortunately, not all admin users need to approve reports. So, as a solution, you think adding these guards to your code sounds good, so **you are going to check the attributes of the report** (the user is either the approver or submitter of this report), the date the report is being approved, etc. 

This practice has a name, and it's called Attribute-Based Access Control.

## What Is Attribute-Based Access Control (ABAC)?

[According to NIST, Attribute-Based Access Control (ABAC)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-162.pdf) is an access control method where a subject's requests to perform operations on objects are granted or denied **based on assigned attributes of the subject, assigned attributes of the object**, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.

In other words, any access decision that your application makes based on attributes of an entity can be considered ABAC and it'll be specific to your application and access control needs. 

ABAC also gives you more control and granularity over your access decisions, making it more flexible than RBAC. 

Regarding the expense management API, RBAC and ABAC can coexist; in fact, checking for a role or permission is also checking for attributes, in this case, attributes assigned to the user, so we can say RBAC is an implementation of ABAC with a limited scope of roles and permissions. So now, let's say it is a requirement that the user also needs to be an admin to perform the approver actions. Why not? 😛 

Let's look at what you'll need to change in your Ruby on Rails API to comply with the new access control requirements and implement ABAC. 

## ABAC Implementation in a Ruby on Rails API

Let's take a look at the requirements you need to implement: 

- Users can only see a report they own (submitted by them)
- Only approvers can see reports submitted by other users
- Only admin users can approve reports
- Users who are approvers can only *approve* reports on weekdays (we don't want people working on weekends!)

Based on this, there are a few changes you could make to the application; most of them are related to the `report` entity. 

Let's think of the scenario where a **user can only see a report they have submitted, or they are the approver**; you could think of this as multiple things like the user needs to have some relationship with the expense report, meaning they are either the submitter or the approver.

There's little we can do with the relationship example now. Still, you can define that if a user is the submitter or approver of a report, they have some **ownership** over it and are allowed to see that report, so let's start there. 

In the API context, you can define this ownership such that **the user making the request is the same user for which we want to see reports.** At the moment, your API doesn't have the context of the user other than an access token, which tells you only that they are authorized to access your API and that they are `admin` because [you added this role as a custom claim in the access token.](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#Creating-and-Assigning-Roles-with-Auth0)

So, that's great 🫠 how can you get information from the user in your API using Auth0? The answer is by connecting your Auth0 API and your Auth0 Application!

### Connect Your Auth0 API with your Auth0 Application 

If you have a REST API as your backend, chances are you have a frontend application where your users authenticate and manage their data, etc. 

When you use Auth0, your users can authenticate using [Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login). So, you need to create an Auth0 Application for either a SPA or a Regular Web Application and [integrate it with your code using one of the SDKs](https://auth0.com/docs/libraries). For this blog post, let's focus on the example of the regular web application. 

[When you created the expense management API](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#Building-the-Starter-Application), you created an [Auth0 API](https://auth0.com/docs/get-started/apis) and an Auth0 Regular Web Application for testing purposes, well now you are going to use this Regular Web Application because in a real-life scenario, your users will probably authenticate themselves *somewhere* and once they're authenticated you proceed to do X or Y in your REST API. 

In the Regular Web Application you created in Auth0 for your users to authenticate, you need to implement login, logout, etc., and you can learn how to do so by following [any of the Developer Center Guides on Authentication](https://developer.auth0.com/resources/guides?type=web-app). Still, the general process is almost identical in all of them, and the outcome is that **you will get an access token from Auth0 issued for the authenticated user.** 
 
Then, you need to tell your Regular Web Application that your users will be interacting with your REST API and, therefore, its counterpart in Auth0, so when you request the access token, you need to provide the `audience` as well. An example of how to do this in a [Ruby on Rails Web application](https://developer.auth0.com/resources/guides/web-app/rails/basic-authentication) would be: 

```ruby
Rails.application.config.middleware.use OmniAuth::Builder do
 provider(
 :auth0,
    AUTH0_CONFIG['auth0_client_id'],
    AUTH0_CONFIG['auth0_client_secret'],
    AUTH0_CONFIG['auth0_domain'],
 callback_path: AUTH0_CONFIG['auth0_callback_path'],
 authorize_params: {
 scope: 'openid profile email',
 audience: 'https://rails-api-authorization', # pass the audience ✨
 }
 )
end
```

Once you pass the `audience`, you'll get a JWT token containing the information about the user, as well as any scopes and claims you've added. To learn more about the audience parameter [you can check out this post.](https://community.auth0.com/t/what-is-the-audience)

That's all you need to do for now in Auth0 to make this work, so let's get back to the code!

### Validate Ownership of the User Making the Request

You already added a method to check for the user's role, so similarly, you could do the same to check for the user's *ownership*. In the context of the expense management app, we'll say: 

> A user is allowed to see an expense report of another user if they are the subject of the access token 

At the moment, you do not store any information about the user's data in your database, but you will need the Auth0 user's ID to compare it. 

#### Add the Auth0 ID to the User Model

Let's create a migration to add a new field to the User model using the following command on your terminal: 

```bash
rails g migration AddAuth0IDToUsers auth0_id:string 
```

The command above will generate a new migration file under `db/migrate/YYYYMMDDHHMM_add_auth0_id_to_users.rb` that looks like this:

```ruby
class AddAuth0IdToUsers < ActiveRecord::Migration[7.0]
  def change
 add_column :users, :auth0_id, :string
  end
end
```

Then, execute the migration by running `rails db:migrate` on your terminal. 

Now, let's add a validation to the User model to make sure the `auth0_id` field is always present and unique. Go to `app/models/user.rb` and add the following code: 

```ruby
class User < ApplicationRecord
 has_many :expenses, foreign_key: :submitter_id
 has_many :submitted_reports, class_name: 'Report', foreign_key: 'submitter_id'
 has_many :reports_to_review, class_name: 'Report', foreign_key: 'approver_id'

 validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }, presence: true, uniqueness: true
  # 👇 new code 
 validates :auth0_id, presence: true, uniqueness: true
end
```

You're all set from the model level. Let's move to the controller level. 

#### Add the Ownership Validation to the Controller

Go to the `Secured` concern in `app/controllers/concerns/secured.rb` and add the following code: 

```ruby
# frozen_string_literal: true

module Secured
  extend ActiveSupport::Concern

  REQUIRES_AUTHENTICATION = { message: 'Requires authentication' }.freeze
  BAD_CREDENTIALS = {
 message: 'Bad credentials'
 }.freeze
  MALFORMED_AUTHORIZATION_HEADER = {
 error: 'invalid_request',
 error_description: 'Authorization header value must follow this format: Bearer access-token',
 message: 'Bad credentials'
 }.freeze
  INSUFFICIENT_ROLES = {
 error: 'insufficient_roles',
 error_description: 'The access token does not contain the required roles',
 message: 'Permission denied'
 }.freeze
  # 👇 new code 
  NOT_OWNER = {
 error: 'not_owner',
 error_description: 'The access token does not belong to the current user',
 message: 'Permission denied'
 }.freeze
  # 👆 new code 

  def authorize
 token = token_from_request

 validation_response = Auth0Client.validate_token(token)

    @decoded_token = validation_response.decoded_token

    return unless (error = validation_response.error)

 render json: { message: error.message }, status: error.status
  end

  def validate_roles(roles)
    raise 'validate_roles needs to be called with a block' unless block_given?
    return yield if @decoded_token.validate_roles(roles)

 render json: INSUFFICIENT_ROLES, status: :forbidden
  end

  # 👇 new code 
  def validate_ownership(current_user)
    raise 'validate_ownership needs to be called with a block' unless block_given?
    return yield if @decoded_token.validate_user(current_user)

 render json: NOT_OWNER, status: :forbidden
  end
  # 👆 new code 

  private
  # ... 
end
```

You are adding a new hash called `NOT_OWNER` to specify the error message in case the user is not the owner of the access token being passed. Then, in the `validate_ownership` method, you're checking the access token and returning an error if the user is not the owner. Since you haven't implemented the `validate_user` method yet, let's add it to the token structure. 

Go to your `Auth0Client` class in `app/lib/auth0_client.rb` and add the following code: 

```ruby
# frozen_string_literal: true

require 'jwt'
require 'net/http'

class Auth0Client

  # Class members
  Response = Struct.new(:decoded_token, :error)
  Error = Struct.new(:message, :status)
  Token = Struct.new(:token) do
    def validate_roles(roles)
 required_roles = Set.new roles
 token_roles = Set.new token[0][Rails.configuration.auth0.roles]
 required_roles <= token_roles
    end
    # 👇 new code
    def validate_user(current_user)
 current_user.auth0_id == token[0]["sub"]
    end
    # 👆 new code
  end

  # Helper Functions
  # ...
end
```

The `validate_user` method checks the `current_user` variable (the user from whom you want to check the reports) against the owner of the access token. In the access token, you have information about the user's ID in Auth0 under the `sub` field, so you are comparing that against the `auth0_id` from the local database. 

Next, call the `validate_ownership` method in the `ReportsController`. You want to validate the user's ownership when they request to review or submit a report, so let's add the validation to the corresponding actions. 

Go to `app/controllers/reports_controller.rb` and add the following code: 

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  def submitted
    # 👇 new code
 validate_ownership(@user) do # user is the owner of these reports
      @reports = Report.where(submitter_id: @user.id) # list only reports where user is submitter

 render json: @reports
    end
    # 👆 new code
  end

  # GET users/:user_id/reports/review
  def review
    # 👇 new code
 validate_ownership(@user) do # user is the owner of these reports
      @reports = Report.where(approver_id: @user.id) # list only reports where user is approver

 render json: @reports
    end
    # 👆 new code
  end

  # GET users/:user_id/reports/1/approve
  # ...
end
```

By adding the `validate_ownership` block in the controller together with the condition inside the query, you are implementing a form of ABAC because you're allowing or denying access based on certain attributes of the user or the report. 

### Validate that Only Approver Users can Approve Reports 

Even though this might be a new requirement, you already took care of this scenario when you first added RBAC. If you look at the `approve` action in the `ReportsController`:

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  # ...

  # GET users/:user_id/reports/1/approve
  def approve
 validate_roles [ADMIN] do # if user is admin
      if @report.is_approver?(@user) # if user is the approver for this report
        @report.status = "approved"
        @report.save
 render json: @report
      end
    end
  end

  # GET users/:user_id/reports/1
  #...
end
```

The check for `@report.is_approver?(@user)` already confirms that 
 `@user` is the approver of `@report`. This is interesting because sometimes we mix up different authorization models without even realizing it, and that's okay as long as it fits your business model. s

### Validate that Approvals Only on Weekdays

You only have to add another validation to allow users to approve expense reports on weekdays, and this is possible by adding a new check to the `approve` action in the `ReportsController`. Go to `app/controllers/reports_controller.rb` and add the following code: 

```ruby
class ReportsController < ApplicationController
 before_action :set_report, only: %i[ show approve ]
 before_action :set_user
 before_action :authorize

  # GET users/:user_id/reports/submitted
  #...

  # GET users/:user_id/reports/1/approve
  def approve
 validate_roles [ADMIN] do # if user is admin
      if @report.is_approver?(@user) # if user is the approver for this report
        # 👇 new code 
        if Date.current.on_weekday? # can only approve on weekdays
          @report.status = "approved"
          @report.save
 render json: @report
        else
 render json: {message: "Can only approve on weekdays"}, status: 401
        end
        # 👆 new code 
      end
    end
  end

  # GET users/:user_id/reports/1
  #...
end
```

[The function `Date.current.on_weekday?`](https://api.rubyonrails.org/classes/DateAndTime/Calculations.html#method-i-on_weekday-3F) returns true if it's a weekday (Mon-Fri) and false otherwise. Users who try to approve during the week will get an error.

At this point, you've fulfilled all the requirements you've received so far! 🚀 It's time to go back to the client and discuss the progress you've made. 

> Up until here, all the changes in the code are available in the [`add-abac` branch of the repository.](https://github.com/auth0-blog/rails-api-authorization/tree/add-abac)

## What About Policies?

You're introducing a lot of extra complexity in the application code that needs to be recreated by each environment, such as web, mobile, CLI, etc. Using a policy engine can streamline application decision-making. 

[A policy](https://csrc.nist.gov/glossary/term/access_control_policy) is a set of rules defining a software service's behavior. There are access control systems like [Open Policy Agent (OPA)](https://www.openpolicyagent.org/), a full-featured policy engine that offloads policy decisions from your software so you don't have to implement it from scratch, or [Policy-Based Access Control (PBAC)](https://csrc.nist.gov/glossary/term/policy_based_access_control), where access control decisions are made based on the business roles of users and is combined with policies.

You won't implement PBAC for the sake of this tutorial, but I thought it was interesting for you to know that decision-making engines like these exist.

## Oh, No. What's Next?

You are showing your implementation to the client, and they're satisfied, but as usual, they came back with more requirements 🥲 

- Users who are managers can see the reports of their directs, plus the reports of their directs' directs, and so on 😵‍💫

You think of a way to implement this with your current solution and... recursiveness 🥲 you know this is possible, but you also start exploring what options are out there for these scenarios. You bump into Relationship-Based Access Control, which seems interesting 🤔 because you feel like basing your implementation on the relationships of your users could work, but you need to do more research. 

## Conclusion 

When we talk about attributes, we refer to properties of the entities of your application; in the expense management application example, we are talking about attributes of a user or an expense report. Attribute-Based Access Control is an authorization model that allows you to make decisions based on these attributes. ABAC gives you more granularity than RBAC because you can specify access control on specific resources other than a role that usually includes more than one resource. 

In the next blog post, you'll learn about ReBAC and its implementations. 

How to Implement Attribute-Based Access Control (ABAC) in a Ruby On Rails API?

Nowadays you could replace your physical driver's license with a digital, cryptographically verifiable one. Let's learn about it and how to start using them.

A driver's license is a document that gives legal authorization for people to drive certain types of vehicles, and they're often made of plastic and have the size of a credit card, so you usually store it in your wallet. Some countries, like Australia, the UK, and the US, use driver's licenses to prove their citizens' identity.

As driver's licenses continue to play a crucial role in verifying your identity, it makes sense that they evolve alongside our increasingly digital world. That's where Mobile Driver's Licenses come in. In this blog post, you'll learn more about them and how to use them.

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

Let's start from the beginning. **A Mobile Driver's License (mDL) is a driving license that resides on a mobile device** instead of physically in your wallet. The beauty behind an mDL is that **they are cryptographically verifiable**, meaning you can use cryptography to verify their information and authorship.

An mDL is a type of [Verifiable Credential (VC)](https://auth0.com/blog/what-are-verifiable-credentials-why-you-should-care/#What-are-Verifiable-Credentials) and they're an [ISO Standard](https://www.iso.org/standard/69084.html). As a VC, mobile driver's licenses also have an issuing authority, which is the authorized organization issuing the driver's license; for example, in the US, that'd be [the DMV](https://en.wikipedia.org/wiki/Department_of_motor_vehicles). There is an mDL holder, and it's the person to whom the mDL is issued. Finally, there is an mDL verifier, which is the entity that can verify the authorship of the mDL.

### mDL Step by Step

![mDL Roles](https://images.ctfassets.net/23aumh6u8s0i/7xGF2PSKekpejYPX11EOse/157c1415ce452ff436954197c1e90eb7/mdl-roles.png)

1. **Issuing:** A user can request an mDL from an issuing authority using their digital wallet. In mDL, this wallet is called an mDoc reader. An mDoc is a document that resides on a mobile device, so the mDoc reader can retrieve an mDoc for verification purposes. The issuer will verify the user's details and use their private key to sign and issue the mDL.

2. **Presenting:** A user can show their mDL using an application called an mDL reader to prove their identity, for example. This application would request the mDL data, which must be verified later.

3. **Verifying:** The mDL reader is in charge of cryptographically verifying the mDL data.

<include src="SmallBannerCTA"
         imgLink="https://images.ctfassets.net/23aumh6u8s0i/12gXwIIea5F2nkS1hNQFWy/70e57fab64095553831e4f4a0ee497d9/mdl-logo.png"
         text="Want to learn more about mDL?"
         linkText="Visit → mdl.me"
         link="https://mdl.me"/>

## Where Are We Today?

Today, many countries have started implementing and deploying pilots for Mobile Driver's Licenses. In the US, for example, there are already [multiple states that have mDL implementations](https://www.aamva.org/jurisdiction-data-maps#anchorformdlmap) in place. [The TSA (Transport Security Administration) has been accepting digital credentials as proof of identity since early 2022](https://www.tsa.gov/travel/frequently-asked-questions/when-will-phased-digital-id-rollout-start-which-airportsstates).

In November 2023, the [European Union also submitted a proposal to introduce mobile driver's licenses](https://data.consilium.europa.eu/doc/document/ST-15808-2023-INIT/en/pdf) and make them fully equivalent to their physical counterpart.

These are just a few examples to tell you that Mobile Driver's Licenses are coming to stay, and many other countries will start piloting and adopting them. Many companies are also beginning to build their own mDL readers and implementations; in fact, [the mDL ISO Standard was tested at the Interoperability Event](https://blog.spruceid.com/iso-iec-18013-7-interoperability-event-results/) where companies joined forces to test their implementations. Some mDL readers and mDL implementers included **Google, the National Institute of Standards and Technology (NIST), Okta, Samsung**, and more. You can read more about it in the [event results publication](https://docs.google.com/document/d/1M4ufcKqmj8gycNovslOSWzFB2nB1o1eu/edit?ref=blog.spruceid.com#heading=h.gjdgxs).


## Where to Use mDL?

Mobile Driver's Licenses have many potential use cases, but some of the most relevant are:

- Prove your Identity: as mentioned above, many countries use driver's licenses as proof of identity, and mDLs should be equivalent to prove someone's identity.
- Improve business processes involving Know Your Customer (KYC) and Anti-Money Laundering (AML)

## Getting Started with mDL

There are a few ways you can get started with mDL, the first one being going to [mdl.me](https://mdl.me) to learn more about it, how it works, and use the debugger to understand what's happening under the hood.

You can also start playing with a library like the one we crafted at [Auth0 Lab, mDL](https://github.com/auth0-lab/mdl). This NodeJS library allows you to issue and verify mDL [CBOR](https://cbor.io/) encoded documents. This library allows you to have a good start to understand how mDL works but **it's important to mention the library alone allows you to create, parse and validate mDL but it's not enough if you need to exchange mDLs.** So for example if you want to present mDL you need to implement a protocol such as the one in the [ISO/IEC DTS 18013-7](https://www.iso.org/standard/82772.html).

### Using the mDL library

First, you need to install the library. For that, run the following in your terminal:

```bash
npm install @auth0/mdl
```

> Note this blog post is for educational purposes and not meant to be used in production. In order to use mDL you'd need a protocol on top to exchange the data, such as the one in [ISO/IEC DTS 18013-7](https://www.iso.org/standard/82772.html) for presenting mDLs.


### Issuing a Credential

Let's take a look at what the code for issuing a new credential would look like:

```js
import { MDoc, Document } from "@auth0/mdl";
import fs from "node:fs";

// Create Document: representation of the mDL data
const document = await new Document('org.iso.18013.5.1.mDL')
  .addIssuerNameSpace('org.iso.18013.5.1', {
    family_name: 'Jones',
    given_name: 'Ava',
    birth_date: '2007-03-25',
  })
  .useDigestAlgorithm('SHA-512')
  .addValidityInfo({
    signed: new Date('2023-10-24'),
    validUntil: new Date('2050-10-24'),
  })
  .addDeviceKeyInfo({ deviceKey: devicePublicKeyJWK })
  .sign({
    issuerPrivateKey,
    issuerCertificate,
    alg: 'ES256',
  });

// Create MDoc
const mdoc = new MDoc([document]);

// CBOR encode the MDoc
const encodedMdoc = mdoc.encode();
```

This script is doing a few things. First, it adds the document type `org.iso.18013.5.1.mDL` to the `Document` instance; this refers to the mDoc document type that is used to identify the ISO driving license standard. Then, it adds the name and birth date attributes of the holder.

The digest algorithm is set to `SHA-512`, and it's used to compute the digest of each attribute. A digest algorithm is a cryptographic hash function that maps a large block of data into a fixed-size output (512 bits or 64 bytes in this case). The verifier will use the same algorithm to verify the disclosed attributes. This is related to the way that [selective disclosure](https://www.w3.org/TR/vc-data-model/#dfn-selective-disclosure) is implemented in mDL.

Then you'll see the `validityInfo`, which is the period of time the document is valid, and finally the device key information in the `addDeviceKeyInfo` method. Here, you specify the public key of the device that will hold the mDL to ensure that the mDL will only be used by the device that holds the corresponding private key. In other words, a presentation will only be accepted if it's signed with the private key that corresponds to the public key in the mDL.

Finally, you use the `sign` method to sign the document using the issuer's private key and certificate.

### Requesting a Credential

Now let's take a look at what should happen on the verifier side. The verifier is the entity that will request the mDL from the holder to later on verify its authenticity. 

Depending on the use case, the holder could have an application on their device that can serve as mDL reader (for example if they're opening a bank account online from their phone) or they could have be requested to show their mDL and the mDL reader resides in another device (for example, to enter a bar and prove that the holder is 18 years old or more, the person at the entrance could have an mDL reader where people can present their mDLs).

The mDL reader requests the mDL data that it needs and the holder uses the digital wallet to present the credential. When the holder presents the credential, the verifier needs to first generate an [ephemeral key pair](https://csrc.nist.gov/glossary/term/ephemeral_key_pair) and a nonce. An ephemeral key pair it's a short-term key pair generated when needed, and the nonce is a random value that is used to prevent replay attacks. The verifier then sends the nonce and the ephemeral public key to the holder. 

You could use [the JOSE package](https://www.npmjs.com/package/jose), for example, to generate these short-term keys. After installing `jose` with `npm install jose` you could do something like the following:

```js
const {generateKeyPair} = require('jose');
const ephemeralKey = await generateKeyPair('ES256')
```

### Generating a Device Response

Once the holder receives the nonce and the ephemeral key, their device can generate a device response. The device response is a signed message that contains the mDL and the nonce.

```js
const deviceResponseMDoc = await DeviceResponse.from(mdoc)
  .usingPresentationDefinition(PRESENTATION_DEFINITION_1)
  .usingHandover([holderNonce, clientId, responseUri, verifierGeneratedNonce])
  .authenticateWithMAC(DEVICE_JWK, ephemeralPublicKey, 'HS256')
  .addDeviceNameSpace('com.foobar-device', { test: 1234 })
  .sign();

const encodedSessionTranscript = getSessionTranscriptBytes(
  { client_id: clientId, response_uri: responseUri, nonce: verifierGeneratedNonce },
  holderNonce,
);

const deviceResponse = deviceResponseMDoc.encode();

sendToVerifier({ deviceResponse, encodedSessionTranscript });
```

With the mDL issued to the holder, the device creates a new device response using the `DeviceRespose` class. The `usingHandover` method is used to specify the date the verifier sent along with a nonce generated by the holder. Here, the `PRESENTATION_DEFINITION_1` constant refers to [which proofs the verifier is requesting from the holder](https://identity.foundation/presentation-exchange/spec/v2.0.0/#presentation-definition). An example could be:

```js
export const PRESENTATION_DEFINITION_1 = {
  id: 'mdl-test-age-over-18',
  input_descriptors: [
    {
      id: 'org.iso.18013.5.1.mDL',
      format: {
        mso_mdoc: {
          alg: ['EdDSA', 'ES256'],
        },
      },
      constraints: {
        limit_disclosure: 'required',
        fields: [
          {
            path: ["$['org.iso.18013.5.1']['age_over_18']"],
            intent_to_retain: false,
          },
        ],
      },
    },
  ],
};
```

In this case, the verifier is asking for an mDL with just one of the holder's attributes to verify that the holder is over 18 years old. You can find other examples in the [mDL repository](https://github.com/auth0-lab/mdl/blob/41724db924161c680c6fff0aa80450a8a2aa7286/__tests__/issuing/config.ts#L108). 

The `authenticateWithMAC` method is used to specify the way in which the device response is authenticated. In this case, it's authenticated [with a MAC](https://datatracker.ietf.org/doc/html/rfc9052#name-mac-objects) using the `HS256` algorithm. The secret for this MAC is computed as follows:

- On the holder's side it uses the public ephemeral key generated by the verifier plus the private key of the device.
- On the verifier's side it uses the private ephemeral key generated by the verifier plus the public key of the device.

The `addDeviceNameSpace` method adds a namespace to the device response.

Finally, the `sign` method is used to sign the device response.

### Verifying the Device Response

Finally the verifier verifies the `DeviceResponse`.

```js
const verifier = new Verifier([ISSUER_CERTIFICATE]);
await verifier.verify(encoded, {
  ephemeralReaderKey: ephemeralPrivateKey,
  encodedSessionTranscript,
});
```

First you need to construct a `Verifier` instance with a list of the issuer's certificates you trust.

Then you call the `verify` method with the encoded device response, the private key of the ephemeral key pair, and the encoded session transcript. This is a structure defined by the ISO standard. You can learn more about it in the  [ISO 18013.5 (section 9.1.5.1 - Session transcript)](https://www.iso.org/standard/69084.html)

## What's Coming: Verify mDL with Auth0

You can [sign up for the waitlist](https://regionalevents.okta.com/mdlearlyaccess) to be one of the first to know when mDL with Auth0 is available in Early Access.

You can also go to [mdl.me](https://mdl.me) to learn more, and if you know about any other mDL libraries out there, let us know so we can include them in the list of resources!

What is a Mobile Driver's License (mDL) and How to Start Using Them

sofia-prosper

Sofía Prósper, a trained architect, is a passionate Developer Advocate and the current Partner Manager of Auth0 by Okta Marketplace. She has a diverse background focused on architecture, design, art, and verbal communication. Recipient of the Spanish Data Protection Agency Prize in 2018, in her spare time, she has worked since as an advocate defending Privacy, Digital Rights, and Digital Sovereignty in Spain. Outside her daily work, you can find her illustrating her travel journal, cooking for friends, collecting recipe books, and joining side projects in beautiful Galicia, Spain.

Senior Developer Advocate and Partner Manager of the Auth0 Marketplace

Sofía Prósper Díaz-Mor

Eutelo Pena

All my career I have been oriented to the creation of software products for mobile devices. Initially, as an Android & iOS developer, implementing biometric solutions in Gradiant / Alice Biometrics. Over the years, my role has been changing towards the management layer, the product and the leadership of teams, carrying it out in places like Bank Sabadell, InAuth (AMEX group), Verse (Square group) or Eccocar. Currently back home, where I am helping to make digital onboarding easier for people.

Head of Product at Alice Biometrics

Facial biometrics revolutionizes digital processes. Implemented thoughtfully, it provides businesses a competitive edge while safeguarding privacy.

## Introduction

In the era of digital transformation, businesses are constantly looking for ways to streamline their processes and enhance security. One technology that is rapidly gaining traction in this regard is facial biometrics, which includes face recognition and face liveness detection. This technology is revolutionizing processes such as the digital onboarding of new users and adding an extra layer of security to prevent AI bots and fraudsters from causing harm. Auth0 has included facial biometrics features at [Auth0 marketplace](https://marketplace.auth0.com/partners/alice-biometrics).

## The Power of Facial Biometrics

Facial biometrics technology uses unique features of a person’s face to verify their identity. It’s a powerful tool that can be used in a variety of applications, from unlocking smartphones to verifying identities at border controls.

### Face Recognition

Face recognition technology works by comparing selected facial features from a given image with the photo ID for the onboarding use case or with the facial template stored for authentication, password reset, or access control use cases. It’s a fast and accurate way to verify the identity of users, making it an excellent tool for digital onboarding and multiple account opening. 

### Face Liveness Detection

Face liveness detection is a technology that can determine whether the source of a biometric sample is a live human being or a representation of a human being. This technology is crucial in preventing fraudsters from using photos, videos, or masks to impersonate legitimate users.

![](https://images.ctfassets.net/23aumh6u8s0i/72e8GkU7K8cuSoxC8JrleF/c3d57801015e621f725020f2db951b8e/Biometric_3.jpg)

## How Facial Biometrics Enhance Businesses Processes

Facial biometrics can significantly enhance several aspects of digital security and user experience. Let’s delve into how this technology can improve authentication, bot prevention, account recovery, and password reset processes.

### Digital Onboarding

Digital onboarding is the process of integrating new users into a system. It’s a critical process for businesses, as it’s often the user’s first interaction with the company. Facial biometrics can streamline this process by quickly and accurately verifying the identity of the user.

For example, a bank can use facial biometrics to verify the identity of a new user opening an account. The user simply takes a selfie, which is then compared to a photo ID they provided. The process is quick, easy, and secure, providing a positive experience for the user while ensuring the bank is complying with KYC (Know Your Customer) regulations.

### Authentication

Facial biometrics provide a secure and user-friendly method for user authentication. Instead of remembering complex passwords, users can simply use their faces as a form of identity verification. This not only enhances security but also improves the user experience by offering a quick and convenient authentication method.

### Bot Prevention

Bots pose a significant threat to digital security. They can carry out a variety of malicious activities, from spamming to automated attacks. Facial biometrics, particularly face liveness detection, can help prevent bots by ensuring that a real, live person is behind each action.

### Account Recovery

Account recovery can be a complex process. Traditional methods often involve answering security questions or receiving a code via email or SMS. With facial biometrics, users can recover their accounts by simply verifying their identity with their face. This makes the account recovery process more secure and user-friendly.

### Password Reset

Resetting passwords can be a hassle for users. However, with facial biometrics, this process can be simplified. Users can verify their identity using their faces and then set a new password. This not only streamlines the password reset process but also adds an extra layer of security.

![](https://images.ctfassets.net/23aumh6u8s0i/1PBtpzTeahMOcqlpm1MoL3/09f0029a9c41c405493f0549b51a7397/Biometric_2.jpg)

## Adding Security to Business Processes

In addition to streamlining digital processes, facial biometrics can also add an extra layer of security. By verifying the identity of users at key points, businesses can prevent AI bots or fraudsters from gaining access to sensitive information or systems.

For instance, a business could use facial biometrics to verify the identity of users before they make a transaction. This could prevent a fraudster who has gained access to a user’s account from making unauthorized transactions.

## Conclusion

Facial biometrics offer a powerful tool for businesses undergoing digital transformation. By streamlining the digital processes and enhancing security, this technology can provide a competitive edge while protecting against AI bots and fraudsters. As with any technology, it’s important to implement it in a way that respects user privacy and security. With these considerations in mind, facial biometrics can play a key role in the digital transformation journey. If you want to try biometrics, please visit [Alice Biometrics](https://marketplace.auth0.com/partners/alice-biometrics) profile at Auth0 marketplace to learn more.

Facial Biometrics: The Key to Digital Transformation and Enhanced Security

Shreya Gupta

Shreya is the Developer Advocate for Auth0 for Startups. She previously founded a non-profit called Bit Project, worked at a YC-backed Startup as a Developer Advocate, and currently hosts The Developer Diaries podcast. Through each experience, she has found her love for building resources and tools that help move the needle for developers. Outside of work, she enjoys traveling, watching K-Dramas, and drinking boba.

Developer Advocate, Startups

Calah Vargas

Calah Vargas is the Associate Manager of Product Led Growth, focusing on nonprofits, startups, and partnerships. She works on product marketing and customer marketing initiatives. Outside work, you can find her cooking, trying new restaurants, and traveling with friends and family.

Associate Manager, PLG

Before you start working with AI developer tools, understand what it could mean for you, your product, and your customers.

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Note:</strong><br> 
  This blog post is based on interviews conducted with startup founders, engineering managers, data scientists, and risk analysts in the Artificial Intelligence and Machine Learning space.<br> 
</div>

Evaluating tools that can help optimize your development processes? Maybe you’re entirely building alongside [Devin, the first AI software engineer](https://www.cognition-labs.com/introducing-devin) to get your app to market faster, generating code snippets for your React app with [V0.dev](https://vercel.com/blog/announcing-v0-generative-ui), or using [GitHub CoPilot](https://thehackernews.com/2024/03/github-launches-ai-powered-autofix-tool.html) to help patch your website’s security flaws.

While productivity and efficiency are hallmarks of development success, security and privacy are just as paramount to protect your product and maintain customer trust. According to [Snyk’s 2023 AI Code Security report](https://snyk.io/reports/ai-code-security/), **80% of developers are bypassing security policies to use AI**.

But modern-day [Generative AI](https://news.mit.edu/2023/explained-generative-ai-1109) tools don’t typically have the built-in capability to determine whether the data it is exposed to is sensitive. It’s completely up to the user to take precautions and set up the proper protocols when choosing to use one of these tools. Let’s explore the potential risks of using AI tools in the dev process and what questions you could ask yourself to help make more informed decisions – for you, your product, and your customers.

## Productivity vs. Risk

According to Snyk’s blog, [How to Embed Security in AI-assisted software development](https://snyk.io/blog/snyk-and-atlassian-embed-security-ai-assisted-software-development/), “Code generation, using generative AI… is the area that stands to offer the greatest productivity benefits — **and the highest potential for introducing risk**.“

AI tools can help accelerate the process of taking an idea and building an MVP with limited resources. Although engineering productivity cannot be tracked by a single metric for all, it’s easy to see how these tools are already helping developers reduce time spent in generating code and improving the quality of code.

Like with all third-party tools, to strike the perfect balance between productivity and risk, it’s important to recognize ways in which these tools can hurt your product and customer security, now and in the future. In many situations, risk cannot be quantified, but companies can have an increased or decreased risk factor (risk tolerance) depending on:

* Industry
* Product type and use case
* Company stage

For example, risk tolerance can be higher for startups in growth mode, especially in industries outside of security.

## Risk Prevention Strategies

Let’s explore the most common risks associated with AI tools and mitigation strategies outlined by some engineers. 

Nonprofit OWASP (The Open Worldwide Application Security Project) documented a [list of potential security risks](https://owasp.org/www-project-top-10-for-large-language-model-applications/) when deploying and managing Large Language Models (LLMs) – some examples include:

* Sensitive Information Disclosure (LLM06) - LLMs can inadvertently disclose sensitive, proprietary, or confidential information leading to privacy breaches, intellectual property theft, and unauthorized access
* Prompt Injection (LLM01) - Attackers can manipulate LLMs through crafted inputs, causing the LLMs to execute the attacker’s intentions
* Overreliance (LLM09) - Systems or people overly dependent on LLMs without oversight may face misinformation, miscommunication, legal issues, and security vulnerabilities due to incorrect or inappropriate content generated by LLMs

When adding these tools to your tech stack, do these questions come to mind?

* How are you deciding which tools to use to increase your efficiency and productivity? 
* Do you have an internal vetting process for third-party vendors? How are you updating this for AI tools?
* Will you be prompting the AI tools with customer data and PII or proprietary restricted information? Are you in line with your applicable regulatory compliance frameworks? (GDPR, etc.)
* Does this tool abide by your corporate guidance?
* Do you have customer permission to use their data in this way?
* How could these tools impact you?
* What risks will you, your product, and your customers face?
* What guidance or guardrails does the tool have to protect your data as a user? Two popular types of AI developer tools are those for engineering productivity and those for general use, and the available configurations may vary.

We interviewed a few engineers (anonymously) about what they’re doing to minimize the risks associated with AI developer tools. Here’s a breakdown of some of the most common concerns and questions engineers are asking to reduce any harmful and inadvertent impact while coding with Gen AI tools.

* PI and copyright concerns
    * Once one of these tools generates code, who is the owner?
    * What happens if the tool is suggesting the same code to another customer, maybe even a competitor?
    * If you use AI tools in order to create a customer-facing chatbot, and a customer includes PII in their prompt – who is in charge of monitoring and removing this data and ensuring it isn’t being used to re-train models?
* Overreliance
    * Generating a few lines of code vs a few files of code – how familiar are you with the code in your product, and how much do you trust it?
    * Are you aware of the potential risk of [AI hallucinations](https://www.ibm.com/topics/ai-hallucinations) and how are you reducing it?
        * AI hallucinations are outputs from models that are nonsensical or inaccurate. For example:
            Question: where can I find the help center?
            Context: you’re looking for a website like [domain].com/help or support.[domain].com
            AI answer: the help center is located on the ground floor of this building.
* How are you updating your code and content review processes to deal with Gen AI?
* Data Exposure
    * Can you make sure your own data won't be used to answer prompts for competitors or malicious actors?
    * What are practical and technical strategies you can take to prevent data exposure?
    * Do you have strict policies and training for engineers when they are using these tools, or are you exploring third-party tools that tackle data leak prevention?

There’s no specific path to being completely secure from the risk of AI tools today, but there are many different strategies you can take to build strong guardrails to protect code and mitigate risk. Ensuring restrictions are very specific when engineers are using AI tools like Devin and code review is a must.

## AI Developer Tools Now and Tomorrow

AI tools for developer productivity are becoming increasingly popular. Further down the line, a startup founder might be able to ideate, possibly write [pseudocode](https://builtin.com/data-science/pseudocode), and use these tools to bring their idea to life. They might be able to start testing in a matter of minutes, not months.

If you’re an early-stage company, you might be eager to get started and may not have as much internal guidance as a large corporation. We hope this blog helps you start to outline the potential risks and considerations when evaluating AI tools for developer productivity. 

[Auth0 for Startups](https://auth0.com/startups) is empowering early-stage startups – tell us what we can do to best support you and your team!

_These materials and any recommendations within are not legal, privacy, security, compliance, or business advice. These materials are intended for general informational purposes only and may not reflect the most current security, privacy, and legal developments or all relevant issues. You are responsible for obtaining legal, security, privacy, compliance, or business advice from your own lawyer or other professional advisor and should not rely on the recommendations herein. Okta is not liable to you for any loss or damages that may result from your implementation of any recommendations in these materials. Okta makes no representations, warranties, or other assurances regarding the content of these materials. Information regarding Okta's contractual assurances to its customers can be found at [okta.com/agreements](http://okta.com/agreements)._

Security Considerations in the Time of AI Engineering

matt-raible

Matt Raible is a well-known figure in the Java community and has been building web applications for most of his adult life. For over 20 years, he has helped developers learn and adopt open source frameworks and use them effectively. He's a web developer, Java Champion, and Developer Advocate at Okta. Matt is a frequent contributor to open source and a big fan of Java, IntelliJ, TypeScript, Angular, and Spring Boot. 

Developer Advocate

Matt Raible

Learn how to build a secure CRUD app with Spring Boot and Angular. You'll use Auth0 for authentication and authorization and Cypress to verify it all works.

Build a Beautiful CRUD App with Spring Boot and Angular

joey devilla headshot 900px

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

Joey deVilla

Smartphones include EXIF metadata in their photos. Here’s how to read, write, and erase it using Python.

How to Read and Remove Metadata from Your Photos With Python 

poovamraj

I'm a senior software engineer at Auth0. From Rust to Kotlin, Java to JavaScript, I love exploring new languages, technologies, and frameworks. Away from the screen, you can find me in the Alps hiking.

Senior Software Engineer

Poovamraj Thanganadar Thiagarajan

We added support for hooks and rewrote it in TypeScript, made API improvements, improved Expo, Android, and iOS integration, and we think you’ll like it.

**We’re excited to announce the general availability of version 3.0 of our React Native SDK!** In this latest version, we’ve transformed our [`react-native-auth0` SDK](https://github.com/auth0/react-native-auth0) to work with two goals in mind:

* To work with the latest and greatest version of React Native, and 
* To create improvements to make your life as a developer easier. 

Read on to find out more about the new version of the SDK!


## What Changed?

We wanted to improve your developer experience and let you focus on what your applications do. We listened to your feedback, made changes to remove the obstacles that were getting in your way, and cut out the confusing parts that were slowing you down.

In this new version of the SDK, we made the following changes:

**100% support for hooks.** You’ve been asking for access to our authentication APIs (such as login via SMS, email, and so on) through hooks. That makes sense — after all, the general consensus is that React hooks generally make for more concise code that’s easier to read and maintain. So we went “all in”: our SDK now has 100% support through hooks! (And yes, you can still use it “the old way” too!)

**Improved `user` object and credentials.** The `User` object (available through our hooks API) isn’t static anymore and doesn’t just capture a snapshot of the user’s information at the moment of login. Instead, it dynamically updates to reflect changes to the user in real time. You can now force-refresh the user credentials, check their validity, and you can do so using either hooks or classes.

**Expo improvements.** The SDK now seamlessly integrates into any Expo project with a single line of configuration. You just specify the domain, and the SDK automatically generates the other configuration lines. We’ve also raised the minimum supported version of Expo to a more stable version (currently v48).

**Completely rewritten in TypeScript.** This allows us to take advantage of TypeScript’s type safety and removes any confusion about what data you provide to and receive from the SDK’s methods. (It also has the side benefit of making the SDK easier to maintain and update, which we believe will provide future benefits for you.)

**Improved Android/iOS interoperability.** We switched from React Native’s Android and iOS SDKs for web authentication to our own SDKs, which we use in the `Auth0.Android` and `Auth0.Swift` packages. Ours are battle-tested, more reliable, and less buggy, which provides your users with a better login/logout experience.


## Requirements

Naturally, you’ll need an Auth0 account to use the SDK. <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">You can sign up for a free account here;</a> the free version supports unlimited login/logout for up to 7,000 users and ten applications.

### Which versions of React Native are supported?

Version 3 of our React Native SDK targets apps using React Native version `0.60.5` and up.

### Is Expo supported?

This SDK _is_ compatible with Expo [custom development client](https://blog.expo.dev/introducing-custom-development-clients-5a2c79a9ddf8) and [EAS (Expo Application Services)](https://expo.dev/eas) builds. 

⚠️ Please note that the SDK is _not_ compatible with the [Expo Go](https://expo.dev/client) app because of the SDK’s use of custom native code.

### Which versions of Android and iOS are supported?

Version 3 of our React Native SDK supports the following mobile platform versions:

* **Android SDK 28, also known as “Android 9” or “Pie” (or later).** Android 9 was released in August 2018. 84% of devices active in the Play Store at the time of writing (August 2023) will run applications targeting this Android version. The oldest phones that support this version of Android date back to late 2017.
* **iOS 13 (or later).** iOS 13 was released in September 2020. As of the end of February 2023, almost 88% of iOS users were running iOS 16, with nearly 12% running iOS 15. iOS 14 users accounted for about 0.2% of users, while users of iOS 13 and earlier comprised the remaining 0.3%. The oldest iPhones that will run iOS 13 are the 6S and 6s Plus, which date back to 2015. Simply put, you’re not really leaving anyone behind by setting iOS 13 as the oldest supported version.


## How to Find Out More

* [**The `react-native-auth0` GitHub repository.**](https://github.com/auth0/react-native-auth0/) You can find the code here, as well as more than enough documentation to get started using the SDK — it’s all in the README file.
* [**The migration guide.**](https://github.com/auth0/react-native-auth0/blob/master/MIGRATION_GUIDE.md) This document covers the improvements that we made going from version 2 to version 3, changes that might break your current implementations, and changes to the format for callback URLs. If you’re working with projects based on the v2 SDK, make sure you read this.
* **Quickstarts.** The fastest way to create a new project that uses the Auth0 React Native SDK is to use a quickstart. We have a [**React Native quickstart**](https://auth0.com/docs/quickstart/native/react-native/interactive) and an [**Expo quickstart**](https://auth0.com/docs/quickstart/native/react-native-expo/interactive).
* **Sample projects.** These sample projects will help you get acquainted with the Auth0 React Native SDK in general and version 3 in particular:
	* [Login/logout app using React components](https://github.com/auth0-samples/auth0-react-native-sample/tree/master/00-Login)
	* [Login/logout app using React hooks](https://github.com/auth0-samples/auth0-react-native-sample/tree/master/00-Login-Hooks)
	* [Login/logout app using Expo](https://github.com/auth0-samples/auth0-react-native-sample/tree/master/00-Login-Expo)
* [**Code examples.**](https://github.com/auth0/react-native-auth0/blob/master/EXAMPLES.md) This is a collection of code snippets that shows you how to perform specific tasks using the SDK.


## Summary

We made version 3 of the React Native for Auth0 SDK based on your feedback to improve the developer and user experiences. With support for hooks, better integration with both Android and iOS, strong typing support, and fewer bugs, we’re sure you’ll enjoy working with this version!

Introducing Auth0 React Native SDK 3.0!

Ryan Friess

Dynamic and seasoned, Ryan holds the role of Senior Sales Engineer at ID.me, a prominent platform specializing in identity proofing, group affiliation verification, and authentication. Ryan's extensive background in both sales and engineering enables him to seamlessly fuse technical intricacies with client requirements. He excels at providing custom solutions that effectively tackle intricate challenges across diverse sectors.

Sr. Sales Engineer - ID.me

Enhance Auth0’s authentication and elevate trust by combining it with ID.me’s verified identities.

In today's interconnected digital landscape, ensuring robust security for online platforms has become a top priority. As the number of data breaches and cyber-attacks continue to rise, businesses and organizations must employ innovative solutions that go beyond traditional authentication methods. Two industry giants, Auth0 and ID.me, have joined forces to create a powerful alliance that offers advanced security measures by integrating Auth0's identity and access management expertise with ID.me's cutting-edge authentication and identity verification capabilities. 

![ID.me & Auth0](https://images.ctfassets.net/23aumh6u8s0i/2MEfvv6hdNXWLrBzbZQNfz/b8ac2c26229144aa7cf12473e4a1c11e/01_Idme.png)

## The Power Duo: Auth0 and ID.me

In the realm of consumer identity and access management, Auth0 has been a trailblazer with its versatile authentication solutions, catering to diverse needs across industries. By providing a seamless and secure way for users to log in to applications and services, Auth0 has revolutionized the way developers handle identity and access management. But what happens when consumer authentication is not enough, and the business needs a way to associate a user’s true identity to their request to access your application? That's where ID.me comes in. 

## How Does It Work? 

ID.me exists to put individuals in charge of their own login, their own data, and their own ID cards to allow the login and the data to move with the user. ID.me’s primary focus lies in validating users' identities through a multi-layered approach, ensuring that the person on the other end of the screen is who they claim to be, and our user’s know they can take their portable identity with them anywhere they see the green ID.me button. This level of assurance goes far beyond the standard username-password-OTP combination, effectively thwarting potential fraudulent activities for higher-risk transactions. 

## Turnkey Integration of ID.me on Auth0

We wanted a way for developers and business decision makers to easily leverage the benefits of ID.me’s trusted and portable credentials within their existing Auth0 implementation in a turnkey manner - eliminating the need of custom development. Therefore, we worked closely with the Auth0 team to create **three turnkey marketplace listings**: 

- [ID.me Post-Login Action](https://marketplace.auth0.com/integrations/idme)
- [Social Login (Community)](https://marketplace.auth0.com/integrations/idmecommunity)
- [Social Login (Identity)](https://marketplace.auth0.com/integrations/idme-identity)

In just four configuration steps, you can benefit from ID.me’s network of 110M+ members and 47M+ IAL2 verified members for your secure authentication and identity verification needs. 

![Cconfiguration Steps](https://images.ctfassets.net/23aumh6u8s0i/7pJt2OAXv9rzBWIY24KIVS/6b30010556c4dfd158b2254ed4cb64fe/02_idme.png)

It’s as simple as selecting the Add Integration button on the marketplace listings, entering your ID.me credentials, and applying the post-login action and social login to your appropriate Auth0  applications. We’ll go into more detail in the next section, but as a sneak peak, your end result will look something like this:

![Integration](https://images.ctfassets.net/23aumh6u8s0i/6ipkP21q1On13NKx4cn8Rs/0bfcf3f9a7dfbce35deb0fb6bef6ffcf/03_idme.png)

- **Pathway #1** - By providing users with the choice of how they prefer to log into your application, customer satisfaction increases, pass rates improve, and ID.me provides 
support for any of your users that elect to log in through ID.me - effectively _reducing the burden and lowering the costs of password resets to your call center or IT Help Desk_. After successful authentication or verification, a corresponding Auth0 user account will be created with appropriate ID.me-validated attributes mapped within the user account.
support for any of your users that elect to login through ID.me - effectively _reducing the burden and lowering the costs of password resets to your call center or IT Help Desk_. After successful authentication or verification, a corresponding Auth0 user account will be created with appropriate ID.me validated attributes mapped within the user account. 

![Pathway #1](https://images.ctfassets.net/23aumh6u8s0i/5Br6WvqABfS3DtVAjTAeML/ab441728797ab912328c7ae80213f8b2/04_idme.png)

- **Pathway #2** - In order to support your existing user base, users can log into their existing account, and can be redirected to ID.me for verification. After successful verification, the individual’s ID.me attribute payload will automatically be mapped within the existing Auth0 user account. 

## For Developers - Let’s Dive a Little Deeper

While integrating ID.me is turnkey within your Auth0 tenant, it’s still important to understand the nuances of the user journey and data flow. The architecture diagram below provides an overview of the two pathways we just discussed: ID.me as a Social Login and ID.me as a Post-Login Action.

![ID.me](https://images.ctfassets.net/23aumh6u8s0i/4CHSxbdUrMVfmKWxhWGBd5/3905e1176eb5ec191575bd955fef71e2/05_idme.png)

The top half of the architecture diagram highlights the Auth0 login with the ID.me post-login action pathway, in which the user elects to log into their existing Auth0 credentials, and will be redirected to ID.me for verification. Take note that an indicator is used to determine when to prompt an existing user for verification with ID.me, and that post-successful verification, that indicator will be updated within the user's application metadata. 

The bottom half of the architecture diagram demonstrates the data flow for the Social Login pathway. This is where our partners receive the benefit of the ID.me network, allowing 110M users to login to your application with their pre-verified ID.me credentials in just a few clicks. 

Now, let’s take a look at an even deeper dive and look at an overview of ID.me, as well as what the exact steps needed to configure the ID.me integrations in this video. 

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

## Conclusion 

The digital landscape is continually evolving, demanding innovative solutions to combat cybersecurity threats effectively. The partnership between Auth0 and ID.me brings together two industry leaders, each contributing its strengths to create a security ecosystem that surpasses traditional authentication methods. By combining Auth0's identity and access management prowess with ID.me's authentication and identity verification capabilities, we can ensure a higher level of trust, security, and compliance while providing a seamless user experience. Together, we are transforming the way to approach digital security, setting a new standard for safeguarding user identities in an ever-changing world.

Strengthen Your Application Security beyond Authentication

We asked ChatGPT to write code to integrate Auth0 into an Android app after its initial release. The code didn’t work then. Will it work this time?

ChatGPT Tries to Add Auth0 Authentication to an Android App, Round Two!

There are different ways to implement an authorization system and the one you chose depends on your application's needs. Role-Based Access Control (RBAC) is just one of them, so let's go ahead and learn how to implement it in a Rails API.

How to Implement Role-Based Access Control (RBAC) in a Ruby On Rails API?

We asked ChatGPT to write code to integrate Auth0 into an iOS app after its initial release. The code didn’t work then. Will it work this time?

## What Happened in Round One

Barely two weeks after the initial release of ChatGPT, I tidied up my home office/studio, put on my newest Aloha shirt, and started asking the newly-released AI some questions about OAuth and Auth0. The result was the video below, which you’ll find on the OktaDev YouTube channel: _Chatting with ChatGPT About Auth0:_

<iframe width="600" height="338" src="https://www.youtube.com/embed/rfkgdorO-8Y" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

ChatGPT gave correct answers to these questions:

- “What is OAuth?” and a follow-up question where I asked it for a more layperson-friendly version of its initial answer.
- “What is OIDC?” and the same follow-up question as my previous one.
- What is an ID token?
- What is an access token?
- What is a refresh token?
- Are there security downsides to using refresh tokens with indefinite lifespans?

ChatGPT didn’t do as well when I asked it, “How do I write an iOS app that uses Auth0 for login?” The set of steps it suggested was correct, but it said that I should use the  `Auth0.authentication()` method to make the Universal Login screen appear. **No such method exists**.


## And Now, Round Two! 

Half a year has passed since I asked ChatGPT about adding Auth0 authentication to an iOS app. Over that period, OpenAI’s developers added a newer model, GPT 4.0, which you can access only if you have a paid account. They also made adjustments and improvements to the original GPT 3.5 model, which powers the free version of ChatGPT.

I decided to see if the free version of ChatGPT could give me a working iOS authentication code this time. I asked it **“How do I write an iOS app that uses Auth0 for login and logout?”**

Here’s ChatGPT’s response, which I’ve condensed slightly for brevity:

1. Set up an Auth0 account.
2. Create an iOS project. Set it up with the desired UI and navigation flow for the login and logout functionality.
3. Install the Auth0 SDK. You can use CocoaPods or Swift Package Manager to install the SDK dependencies.
4. Configure your Auth0 application by providing the necessary settings, such as allowed callback URLs and logout URLs.
5. Implement login functionality: Create a login view controller or integrate the login functionality into an existing view controller. Use the Auth0 SDK to initiate the login process by presenting the Auth0 login screen. The user will be able to enter their credentials or choose a social login option.
6. Handle login callback: Once the user successfully logs in, Auth0 will redirect them back to your app. You need to implement the callback handling in your app to receive the authentication result. This typically involves handling a URL scheme or Universal Link that Auth0 uses to redirect back to your app.
7. Store and manage tokens: When the login is successful, Auth0 provides an access token and, optionally, a refresh token. You'll need to store these tokens securely, such as using the iOS Keychain, and handle token refreshing when necessary.
8. Implement logout functionality: Create a logout function that clears the stored tokens and logs out the user. You can use the Auth0 SDK to perform the logout operation.
9. Secure API requests: To secure your app's API requests, include the access token in the authorization header when making requests to your backend services. Ensure that your backend verifies the authenticity of the token with Auth0.
10. Test and refine: Thoroughly test your app's login and logout functionality to ensure it works as expected. Make any necessary refinements or enhancements based on user experience and feedback.

I then asked **“Could you show me some Swift code that uses Auth0 for login and logout?”**

Its response: “Certainly! Here's an example of Swift code that demonstrates how to use Auth0 for login and logout in an iOS app,” followed by this code:

```swift
import Auth0

class Auth0Manager {
    let auth0 = Auth0.webAuth(clientId: "YOUR_CLIENT_ID", domain: "YOUR_DOMAIN")

    func login(completion: @escaping (Error?) -> Void) {
        auth0
            .scope("openid profile")
            .audience("https://YOUR_API_IDENTIFIER")
            .start { result in
                switch result {
                case .success(let credentials):
                    // Successful login
                    let accessToken = credentials.accessToken
                    let idToken = credentials.idToken
                    // Store the tokens securely

                    completion(nil)

                case .failure(let error):
                    // Handle error
                    completion(error)
                }
            }
    }

    func logout() {
        auth0.clearSession(federated: true) { result in
            switch result {
            case .success:
                // Successful logout
                // Clear stored tokens and any other user data

            case .failure(let error):
                // Handle error
                print("Logout error: \(error)")
            }
        }
    }
}
```

My thought was probably what you’re thinking right now: _Does this code work?_

I opened a copy of the iOS project I use for demonstrating Auth0 authentication, which is based on the Auth0 iOS Quickstart app (you can [download a version configured with your Auth0 tenant settings](https://auth0.com/docs/quickstart/native/ios-swift/01-login) or [get it from this Github repository](https://github.com/auth0-samples/auth0-ios-swift-sample/tree/master/Sample-01)). I added a new file to the project, `Auth0Manager.swift`, and pasted the class that ChatGPT generated there. I replaced these placeholder values...

- `YOUR_CLIENT_ID` with my app’s client ID
- `YOUR_DOMAIN`with my tenant’s domain
- `YOUR_API_IDENTIFIER` with `https://YOUR_DOMAIN/api/v2/`, replacing `YOUR_DOMAIN` with my tenant’s domain

…and replaced my demo app’s calls to its original `login()` and `logout()` methods with calls to the versions that ChatGPT provided.

I ran the app...

...and it worked! It appears that this time, ChatGPT — and the _free_ version at that — got it right.


## A Closer Look At ChatGPT’s Code

Now that it’s clear that ChatGPT now knows how to write code to integrate Auth0 into an iOS app let’s take a look at the way it did this.

<img src="https://images.ctfassets.net/23aumh6u8s0i/2g2IgpFO8E6hNzFAwaDfdc/e2042210acd1c1b96f3c4629001a5d39/gavel.png" align="left" style="padding: 20px;" alt="Judge’s gavel resting on a hardcover book." />To make this exercise a little more fun, I’ll keep a running score where I’ll award points for what I thought were good things that ChatGPT did and deduct points for things that I thought were bad ones. Watch for the picture of the gavel for these scores.


### The Auth0Manager class

This is different from a lot of [tutorial code](https://auth0.com/blog/get-started-ios-authentication-swift-uikit/), which puts the Auth0 logic and data — the`login()` and `logout()` methods as well as the variables to hold the tokens that Auth0 returns —  inside the view object that makes the call to display the Universal Login screen or log the user out. Many tutorials take this approach because it shows all the code in a single file, which is useful when you’re trying to explain something new to the reader.

In a _real_ iOS app (as opposed to a tutorial app), you’d probably take the same approach as ChatGPT’s and put the authentication and authorization code in its own class. In fact, [that’s what we do in tutorials showing how to integrate Auth0 into Android apps](https://auth0.com/blog/add-progressive-profiling-auth0-authentication-android-apps-jetpack-compose/) since they rely heavily on ViewModels that inherit from Android’s built-in `ViewModel` class.

<img src="https://images.ctfassets.net/23aumh6u8s0i/2g2IgpFO8E6hNzFAwaDfdc/e2042210acd1c1b96f3c4629001a5d39/gavel.png" align="left" style="padding: 20px;" alt="Judge’s gavel resting on a hardcover book." />I’ve decided to follow ChatGPT’s example and put Auth0 code in its own class in my tutorials from now on to make my tutorial code a little closer to real-world code. For this idea, I’ll award ChatGPT 1 point.


### The WebAuth instance

ChatGPT’s `Auth0Manager` class has a single property, `auth0`, a `WebAuth` instance whose definition is as follows:

```swift
let auth0 = Auth0.webAuth(clientId: "YOUR_CLIENT_ID", domain: "YOUR_DOMAIN")
```

`Auth0.webAuth()` is a function in the _Auth0.Swift_ library that creates an instance of the `WebAuth` class, which provides the necessary methods for logging a user in and out. Both the `login()` and `logout()` methods use this instance.

ChatGPT’s solution uses the version of `Auth0.webAuth()` that takes two arguments: the client ID and the domain. It’s the most straightforward way to show how you can use Auth0 to implement login and logout in an app, but you probably wouldn’t do this in a production application since you’d be hard-coding server credentials.

Fortunately, there’s another form of `Auth0.webAuth()` that _doesn’t_ take arguments for the client ID and domain. In fact, it doesn’t take _any_ arguments, and you’d use it like this:

```swift
let auth0 = Auth0.webAuth()
```

Instead of relying on arguments that you pass to it, this form of `Auth0.webAuth()` looks through the app’s property lists (a.k.a. _plists_) for values corresponding to the following keys:

- `ClientId` for the client ID
- `Domain` for the tenant domain

You would typically create a new property list — usually named `Auth0.xml` — and store the `ClientID` and `Domain` values there. Here’s what it would look like in an Xcode project if you prefer editing property lists visually...

![auth0_plist](https://images.ctfassets.net/23aumh6u8s0i/6LexUyPkhqCzEvMCASpR37/246ed1182fd7d410cebaca9c4a6d01b0/auth0_plist.png)

...and here’s how it would look if you prefer editing property lists as source code:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Domain</key>
    <string>** Put your tenant’s domain here ***</string>
    <key>ClientId</key>
    <string>** Put your app’s client ID here ***</string>
</dict>
</plist>
```

Putting the client ID and domain values in their own file makes it easy to exclude them from version control, which makes it less likely that you’ll unintentionally share these values with people outside your organization.

<img src="https://images.ctfassets.net/23aumh6u8s0i/2g2IgpFO8E6hNzFAwaDfdc/e2042210acd1c1b96f3c4629001a5d39/gavel.png" align="left" style="padding: 20px;" alt="Judge’s gavel resting on a hardcover book." />ChatGPT’s implementation works when trying to explain how to implement something, which earns it 1 point. However, its implementation isn’t one that you should use in a production application, and it should have explained this fact, so I’m deducting the point I just gave it. ChatGPT’s current score is holding at 1 point.


### The login() method

Let’s take a look at ChatGPT’s `login()` method:

```swift
func login(completion: @escaping (Error?) -> Void) {
    auth0
        .scope("openid profile")
        .audience("https://YOUR_API_IDENTIFIER")
        .start { result in
            switch result {
            case .success(let credentials):
                // Successful login
                let accessToken = credentials.accessToken
                let idToken = credentials.idToken
                // Store the tokens securely

                completion(nil)

            case .failure(let error):
                // Handle error
                completion(error)
            }
        }
}
```

Its `login()` implementation is mostly the same as the `login()` methods in our tutorials or our iOS Quickstart app. There’s the usual method chaining from the `webAuth` instance, where the methods are called in this order:

- `scope()` to request the minimum amount of scopes necessary to authenticate a user:
    -   `openid` to indicate that we want to use OpenID Connect (OIDC) to verify the user’s identity. Since Auth0 authentication is OIDC-based, Any application using Auth0 must request this scope.
    -  `profile` to retrieve the user’s name.
    -  The ChatGPT code doesn’t include a request for the `email` scope, which I would recommend, simply for access to the user’s email address, which is typically how an app would send out-of-band communications to the user.
-  `audience()` to specify one or more APIs that the access token that Auth0 returns should grant access to. In the rare case that you’re using Auth0 for authentication only, you can skip this method call. In my case, I passed it the string `https://MY_DOMAIN/api/v2/`, replacing `MY_DOMAIN` with my tenant’s domain. This is the URL for the Auth0 user management API, which is useful for accessing the user’s app and user metadata.
- `start()` to indicate what the app should do in the cases where the user was able to log in and where they weren’t.

The big difference between ChatGPT’s implementation of `login()` and the ones we’ve been using here on the Auth0 blog and in our Quickstarts can be seen in the `login()` method’s signature:

```swift
func login(completion: @escaping (Error?) -> Void)
```

ChatGPT’s version of `login()` has a parameter, `completion`, that takes an argument of type `(Error?) -> Void`. This argument is a closure that takes an argument of type `Error?` (a value whose type is `Error`, a subclass of `Error`, or `nil`) and does not return a value. The `@escaping` annotation informs Swift that the closure provided to `login()` might [outlive or go beyond `login()`’s scope](https://www.donnywals.com/what-is-escaping-in-swift/).

The `completion` parameter allows the code that calls `login()` to perform additional actions upon successful login and also in case login fails:

- If the user logged in successfully, `login()` calls `completion(nil)`.
- If the user’s attempt to log in failed, `login()` calls `completion(error)`, where `error` is the `Error` instance returned by `start()` method of the `WebAuth` instance contained in the `auth0` property.

The code calling `login()` must provide a closure argument that specifies what extra actions should happen whether the login succeeds or fails. For example, here’s the code in my demo app that calls `Auth0NManager`’s `login()` method:

```swift
auth0Manager.login() { error in
    if let error = error {
        print("Login error!")
        isAuthenticated = false
    } else {
        print("Login successful!")
        isAuthenticated = true
    }
}
```

<img src="https://images.ctfassets.net/23aumh6u8s0i/2g2IgpFO8E6hNzFAwaDfdc/e2042210acd1c1b96f3c4629001a5d39/gavel.png" align="left" style="padding: 20px;" alt="Judge’s gavel resting on a hardcover book." />I like ChatGPT’s addition of the <code>completion</code> parameter and feel no shame in stealing this idea (is it even possible to steal from an AI?). I’m granting ChatGPT 1 point, resulting in a total of 2 points so far.


### The logout() method

Here’s ChatGPT’s `logout()` method:

```swift
func logout() {
    auth0.clearSession(federated: true) { result in
        switch result {
        case .success:
            // Successful logout
            // Clear stored tokens and any other user data
            print("Logged out!")
            
        case .failure(let error):
            // Handle error
            print("Logout error: \(error)")
        }
    }
}
```

ChatGPT’s implementation of the `logout()` method is pretty much the same as the `logout()` methods in our tutorials or our iOS Quickstart app.

I would steal ChatGPT’s trick from its `login()` method and add a `completion` parameter that takes a closure that performs additional actions for both successful and unsuccessful logouts. My implementation would look something like this:

```swift
func logout(completion: @escaping (Error?) -> Void) {
    auth0.clearSession(federated: true) { result in
        switch result {
        case .success:
            // Successful logout
            // Clear stored tokens and any other user data
            completion(nil)
            
        case .failure(let error):
            // Handle error
            completion(error)
        }
    }
}
```

And here’s how I’d call the `logout()` method:

```swift
auth0Manager.logout() { error in
    if let error = error {
        print("Logout error!")
    } else {
        print("OK")
        isAuthenticated = false
    }
}
```

<img src="https://images.ctfassets.net/23aumh6u8s0i/2g2IgpFO8E6hNzFAwaDfdc/e2042210acd1c1b96f3c4629001a5d39/gavel.png" align="left" style="padding: 20px;" alt="Judge’s gavel resting on a hardcover book." />ChatGPT didn’t provide a <code>completion</code> parameter for the <code>logout()</code> method as it did for the <code>login()</code> method. I won’t award it a point, but I won’t take one away, either. At the end of this exercise, ChatGPT has 2 points. Not bad!


## Is Your Developer Job Safe?

Considering that it’s been only half a year since we last tested ChatGPT’s ability to write code that integrates Auth0 into iOS apps, this is an impressive improvement. You might be wondering what kinds of leaps it might make over the next couple of years if AIs keep advancing at the same pace, and more importantly, what this means for your career as a developer.

I don’t think of AIs like ChatGPT as a threat. Instead, I think of them as part of a long series of cognitive aids that include  [tally sticks](https://en.wikipedia.org/wiki/Tally_stick), [the abacus](https://www.ecb.torontomu.ca/~elf/abacus/intro.html), writing, [logarithmic tables](https://www.cuemath.com/algebra/log-table/), and [slide rules](https://sliderulemuseum.com/SR_Course.htm), as well as their more modern counterparts such as the combination of search engines and Stack Overflow, [code completion](https://en.wikipedia.org/wiki/Intelligent_code_completion), and [GitHub Copilot](https://github.com/features/copilot). I think that AIs can enhance what a human programmer can do and even provide ideas and inspiration that they might not think of. After all, ChatGPT’s answer provided me with a couple of ideas that I’m going to use in future code.

You might find it helpful to read this IEEE Spectrum article, [_How Coders Can Survive—and Thrive—in a ChatGPT World_](https://spectrum.ieee.org/ai-programming), which lists four ways in which developers can stay ahead of generative AIs. It captures my thinking about AI and programming in its final paragraph:

<blockquote>For programmers to survive in a generative AI world, they’ll need to embrace AI as a tool and incorporate AI into their workflow while recognizing the opportunities and limitations of these tools—and still relying on their human coding capabilities to thrive.</blockquote>

ChatGPT Tries to Add Auth0 Authentication to an iOS App, Round Two!

Logging out of an application may not be as easy as it can seem at first. Let's explore the options available in the different scenarios.

We put a lot of emphasis on the login step of an application: authentication methods, authentication factors, user identity protection, passwordless, single sign-on, etc. What about the logout step? Do you think it's so easy to implement that it doesn't deserve much attention?

Implementing logout may not be as easy as you think at first, especially in contexts where multiple actors may be involved in the login step, as it may happen in the Auth0 context.

This article will give you a high-level overview of logout issues and the different types of logouts. It will not go into the implementation details of logout, but you will get an idea of the complexity behind this apparently simple operation.

## A Few Questions about Logout

An Arabic proverb reads: "*Think of the going out before you enter*". This highlights the importance of planning well for a way out before entering any environment, physical or virtual. This also applies to logging out of applications. Understanding how to properly log out of an application has the same weight as logging in.

Before you dive into the different types of logout, ask yourself a few questions that may help you understand how to implement it for your application needs.

### What is the relationship between login and logout?

Login is the initial step in an authenticated session, which is a session that has an authenticated user associated with it. Logout is the final step of an authenticated session, that is, the last step in a session whose activities are bound to an authenticated user. Before the login and after the logout, any user activity in your application is not bound to an authenticated user but to a so-called unknown user, often called an *anonymous user*.

So, we can say that during the time between the login and the logout steps, your application knows who the logged-in user is.

### How many authenticated sessions do you have?

In the Auth0 context, when your application user logs in by using the [Universal Login page](https://auth0.com/docs/authenticate/login/auth0-universal-login), Auth0 creates a new authenticated session. Likewise, when your application receives confirmation of user authentication from Auth0, it should create another new authenticated session.

The first session tracks the interaction between the user and the Auth0 server: let's call it the *Auth0 session*. The second session tracks the interaction between the user and your application: let's call it the *Application session*. The following diagram highlights these two sessions in the context of Auth0:

![Application session and Auth0 session](https://images.ctfassets.net/23aumh6u8s0i/7GL9lhge2VPiguMql1fZba/be9b5db48db07160a24ea887471051ab/application-auth0-sessions.png)

You can use a third-party Identity provider (IdP) to authenticate your users through Auth0. For example, you can allow your users to authenticate with their favorite social media providers, such as Google, Facebook, or Twitter. In this case, a third session is created in addition to the Auth0 session and the application session: the 3rd-party IdP session. The following diagram illustrates this new scenario:

![Application session, Auth0 session, and 3d party IdP session](https://images.ctfassets.net/23aumh6u8s0i/4YiylvkgLKQSeoXJu1xKIh/9f51fc289d1b1f9f9d74eb815006d421/application-auth0-3d-party-idp-sessions.png)

### Why do you need to log out?

This may seem like a strange question, but think a bit about it. What is the purpose of logging out of an application? Basically, it means terminating an authenticated session. All the information associated with the session must be destroyed so that unauthorized parties can't take it over. In other words, it's a security measure. But you should not underestimate that it also has an impact on the user experience, as you will see later.

### Where do you want to log out from?

Again, this may seem like a silly question at first. Probably the most natural answer is: "*I want to log out of the application*". But as you learned earlier, there are scenarios where there are multiple authenticated sessions. Which of these sessions do you need to close? Just the application session? All sessions?

You will learn about the options in a moment.

### Why do you ask these questions?

These questions (some of which are not yet answered) should help you think about the correct way to let your users log out of your application in your specific scenario. Carefully analyze the context of your application to find the right way to let your users log out. With these questions in mind, let's see what types of logouts are available.

## Types of Logouts

I guess that it shouldn't sound weird at this point to talk about different types of logouts. Just as there are different ways to log in to your application, there are different ways to log out. Let's explore them.

### Application logout

Logging out of your application means closing your application session. How you close your application session depends on how it is implemented. For example, if your application is a [regular web application](https://auth0.com/docs/get-started/applications), you might have implemented your session using a cookie and session storage on the server side. To close the user's session, your application should invalidate the cookie and clear the session storage. Handling your application session is your responsibility.

Closing your application session doesn't close the Auth0 session. This means that the user's session with Auth0 is still alive. Technically, this means that the user's browser still has a valid authentication cookie issued by Auth0. If the user accesses the Universal Login page to authenticate while the Auth0 session is still valid, they are not even prompted for their credentials. Their authentication status is confirmed, and a new ID token is issued.

The following diagram shows the session status after application logout:

![Application logout](https://images.ctfassets.net/23aumh6u8s0i/4l8XzMQc9fJn9nKfPhhWm2/43654bd6f3da2616d3241c0f0b66caec/application-logout.png)

It is up to you to decide whether this logout type is right for your application. You know your application business scenario and the user experience you want to provide to your users.

### Auth0 logout

Suppose you don't want your user to be left with an active Auth0 session when they log out of your application. In this case, you must close both your application session and the Auth0 session.

As mentioned before, it is your responsibility to handle the logout of your application. To close the user's Auth0 session, your application must call the [Auth0 logout endpoint](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-auth0). This way, the next time the user accesses the Universal Login page, they will be prompted for their credentials.

In short, when the user clicks the logout button in your application, you close your application session and then call the Auth0 logout endpoint.

> Currently, Auth0 supports two logout endpoints: the [OIDC logout endpoint](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-auth0) and the [alternative logout endpoint](https://auth0.com/docs/api/authentication#logout).

The following diagram shows the session status after application and Auth0 logouts:

![Application and Auth0 logout](https://images.ctfassets.net/23aumh6u8s0i/2jGrD0v3xLCldzzMYX9gjb/9870f5bab211f2f47beac09a2b05b356/application-auth0-logout.png)

Check if this logout type is appropriate for your needs.

### Federated logout

Suppose that your application allows users to log in with a third-party Identity provider, such as Google, via Auth0. As you've already seen, in this scenario, you have the sessions shown in the following diagram:

![Application session, Auth0 session, and 3d party IdP session](https://images.ctfassets.net/23aumh6u8s0i/4YiylvkgLKQSeoXJu1xKIh/9f51fc289d1b1f9f9d74eb815006d421/application-auth0-3d-party-idp-sessions.png)

If you apply the application and Auth0 logout, the IdP session remains active.

This may be an acceptable scenario in some contexts. For example, most users use [social logins](https://marketplace.auth0.com/features/social-connections) to access multiple independent applications. If they use Google to access your application, there is a high probability that they are already authenticated with Google because they may have Gmail or some other open application that requires Google as the IdP. So, when your user logs out of your application by closing only the application session and the Auth0 session, they can still use Gmail or any other application they have logged in to through Google.

However, there are scenarios where this approach may not be appropriate. Consider the case where the third-party IdP is not a social media provider but an [enterprise IdP](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers). In these scenarios, you may want the user to log out of the IdP when they log out of your application. The [Federated logout](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-idps) accomplishes this goal. After logging out of the application, the authenticated sessions involved in your scenario will look like this:

![Federated logout](https://images.ctfassets.net/23aumh6u8s0i/13qgFDDmMVx2bjhQX7x4wb/2f948733cc09c9d9c9eb3c948af26b31/federated-logout.png)

> Note that not all third-party IdPs support Federated logout. Check [which ones](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-idps#federated-logout-support) support it.

The Federated logout introduces some user experience challenges. While logging out of your application and Auth0 is expected by the user, logging out of a third-party IdP may be something unexpected and even annoying to the user. Consider a user who uses Google to access your application, and after they log out of your application, they are unable to access their email on Gmail because their authenticated session has been terminated. As a best practice, you should make your users aware that they are logging out of their third-party IdP. For example, you can require confirmation to log out of the third-party IdP. Alternatively, you can implement the logout function so that the user can choose whether or not to log out of their third-party IdP as well.

### Global logout

The logout scenarios analyzed so far assume that there is a single application and that the user logs out of that application. What happens when multiple applications are involved in the same authenticated session? What if the user logs out of the third-party IdP instead of your application? What is the desired behavior?

The following diagram illustrates this specific scenario:

![multiple-application-auth0-3d-party-idp-sessions](https://images.ctfassets.net/23aumh6u8s0i/6ndpGiqaF3WYTo1iPCSpep/687586187b40b966e293e676fb08c423/multiple-application-auth0-3d-party-idp-sessions.png)

The diagram shows a situation where two applications (Application A and Application B) share the same authenticated sessions: the Auth0 session and a third-party IdP session.

> This scenario would be similar even without the third-party IdP. However, the inclusion of the third-party IdP makes explicit the case where the user logs out of it instead of one of the applications.

As said before, what to do when the user logs out of one of these applications or from the IdP depends on your business needs. In some scenarios, you may want to do nothing: the other applications will continue to work until the user logs out of them. In other scenarios, you may want to terminate the sessions of the other applications.

The logout that terminates the sessions of the other applications is usually called **Global logout** or **Distributed logout**. From a certain point of view, it can be seen as the counterpart of the [Single Sign-On (SSO)](https://auth0.com/docs/authenticate/single-sign-on). For this reason, it is also known as **Single Logout (SLO)**, especially in the [context of SAML](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-saml-idps).

Basically, when a user logs out of one of the applications sharing the same authenticated session, a logout request is sent to the other applications. The details of how this happens depend on the specific protocol (e.g., SAML, OIDC), where the initial logout happens (one of the applications or the IdP), and the type of application (regular web application, SPA). This article will not go into those details. If you are curious, take a look at these docs:

- [OpenID Connect Session Management](https://openid.net/specs/openid-connect-session-1_0.html). The OIDC specification for implementing Global logout by actively monitoring the user's current authentication status.
- [Front-Channel Logout](http://openid.net/specs/openid-connect-frontchannel-1_0.html). The OIDC specification for implementing Global logout when the browser notifies the IdP of the application session termination.

- [Back-Channel Logout](https://auth0.com/docs/authenticate/login/logout/back-channel-logout). A high-level overview of the [OpenID Connect Back-Channel Logout](https://openid.net/specs/openid-connect-backchannel-1_0.html) specification, i.e., when a regular web application communicates the termination of the application session to the IdP.

- [Best Practices for Application Session Management](https://auth0.com/blog/application-session-management-best-practices/). A blog post about the best practices for checking and terminating authenticated sessions.

Of course, the same user experience issues we mentioned for the Federated logout also apply to Global logout.

## Life after Logout

You have explored the different types of logouts you may encounter as you deal with increasingly complex scenarios. But what happens after the user logs out of your application? Since their authenticated session terminates, they are no longer authorized to access the protected pages of your application. Where will they be redirected?

This is mostly a user experience decision. You can redirect your users to the home page of your application, a specific page, or the authentication page (i.e., the Universal Login page). The choice is up to you, but there are a few points to keep in mind:

- When your logout involves Auth0 (i.e., it's not just an Application logout), you'll need to specify where to redirect the user. Learn how to do this based on the [OIDC logout endpoint](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-auth0#redirect-users-after-logout) or the [alternative logout endpoint](https://auth0.com/docs/authenticate/login/logout/redirect-users-after-logout).
- Register the URL of the page to which users will be redirected in the *Allowed Logout URLs* field of your Auth0 Application Settings in the Auth0 dashboard. This is a security measure to prevent URL injection attacks.
- Let's say you only use the Application logout or allow users to authenticate with a third-party IdP, but you don't use the Federated logout. In these cases, be sure to redirect users to an unprotected page after they log out. Otherwise, their active authenticated session with Auth0 or the IdP will re-authenticate them, and a new application session will start. The perceived effect is that the users will not log out of your application.

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

## Summary

In this article, you were invited to ask yourself a few questions about when you are going to implement your logout function. These questions should help you choose the right approach to define the logout for your specific scenario.

Then you explored some logout types based on different scenarios: you started with a scenario where the simple Application logout might be enough and arrived at a scenario where multiple applications are involved, and you need a Global logout.

At the end of this article, I hope you now have an idea of the complexity behind the logout step. It may look easy at first, but in scenarios where multiple applications and multiple IdPs are involved, it becomes very challenging. The alternative to this complexity would be to [discourage your users from logging out of your application](https://www.theverge.com/23670169/logout-button-ui-websites-design-ui-interface). Is that what you want? 🙂

The Not-So-Easy Art of Logging Out

React is one of the most popular JavaScript frameworks, and Spring Boot is wildly popular in the Java ecosystem. This article shows you how to use them in the same app and secure it all with Okta.

Use React and Spring Boot to Build a Simple CRUD App

andrew-hughes

Andrew is a senior web app developer with 15+ years of experience and solid expertise with React, Node, and React Native, as well as tons of SQL/NoSQL knowledge. He has performed complicated back-end API integrations for clients, including payment platforms like Stripe and PayPal along with InfusionSoft and WordPress. His extensive professional background also includes working with PHP, Laravel, Java, and Swift/iOS.

Andrew Hughes

Learn how to use Java and embedded Jetty to create a simple servlet-based web service. Then see how to do it with Spring Boot.

Get Started with Jetty, Java, and OAuth

Catherine Razeto

Catherine Razeto is a Staff Data Scientist on the Machine Learning team for Okta's Customer Identity products. She focuses on developing threat detection models to secure our customers' applications. She led the development of the machine learning engine for the Bot Detection security feature. She is interested in classification problems, anomaly detection and fraud detection at-scale.

Staff Data Scientist

The aggregated score indicates the level of bot activity seen across all CIAM customer login flows

From online retail to social media — and everything in between — bots are (one of the reasons) why we can’t have nice things. As we examine in detail in our[ State of Secure Identity Report](https://auth0.com/resources/whitepapers/2022-state-of-secure-identity-report), these digital automatons plague Identity flows at all parts of the user journey:

* Fake signups defraud registration forms and pollute customer intelligence systems;
* Brute force attacks use breached passwords in account takeover (ATO) attacks; and
* Malicious bots burden app owners with scams and spam, degrading the user experience.

Consumer-facing apps, in particular, must identify and filter out bots as part of their security and growth objectives — and since day one, Auth0 has devoted considerable effort to helping our customers do just that.

## Bot or Not?

As a vital part of the[ Attack Protection](https://auth0.com/docs/secure/attack-protection) add-on in the[ Okta Customer Identity Cloud](https://www.okta.com/customer-identity/), our[ Bot Detection](https://auth0.com/docs/secure/attack-protection/bot-detection) feature mitigates scripted attacks against native applications, passwordless flows, and custom login pages.

By correlating a variety of data sources — like past events associated with an IP address, recent login history, IP reputation data, and an assortment of other factors — we can detect when an Identity request is likely to be coming from a bot. When the Bot Detection feature detects bot or scripted login requests, it triggers a CAPTCHA step in the login flow.

Over the years, we’ve continually refined our bot detection capabilities: today’s version employs a machine learning (ML) model that ingests 60+ inputs — and when we introduced this new system last year, it[ reduced bot attacks by 79%](https://auth0.com/blog/auth0-bot-detection-reduces-bot-attacks-by-79/) above and beyond its precursor.

Importantly, the improved defensive capabilities were achieved without the expense of user friction: even during attacks, fewer than 1% of challenges are shown to legitimate human users.

## Building on Bot Detection: The Identity Threat Level (ITL)

Being at the ‘front door’ of applications with a Customer Identity and Access Management (CIAM) solution that secures billions of login transactions per month, Auth0 has a unique vantage point from which to monitor Identity threats.

This powerful perspective was the genesis of the Identity Threat Level (ITL), a score from 0 to 10 that indicates the level of bot activity targeting CIAM systems: a score of 0 means there’s practically no bot activity to speak of, while a score of 10 means almost all traffic is attributable to bots.

By aggregating (anonymously, of course!) observations across our customer base, we can calculate an ITL for different industries and geographies, with the option of introducing additional slicing and dicing on other common attributes.

Tracking historical trends and daily shifts has the potential to inform of elevated risks to CIAM login and sign-up flows, enabling app providers to increase their own monitoring, proactively tighten thresholds, implement additional defenses — or respond in any other way they see fit.


<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Behind the scenes</strong><br> 
Here's a simplified overview of how an ITL is calculated.<br>
Each day, the ITL instrumentation analyzes traffic samples that cover all industries and geographies and includes customers of all sizes.
By cross-referencing the samples against our Bot Detection capabilities, we're able to determine with high accuracy what proportion of those Identity flows are associated with bots.
Finally, for each dimension or combination of dimensions (e.g., Financial Services in North America), we calculate the ITL.<br>
The ITL is based on traffic from Okta's Customer Identity Cloud customers; we believe it's reasonable to conclude that organizations that aren't customers will experience similar threats, but we cannot and do not assert that this is definitely the case.<br> 
</div>

## Sneak-Peak Observations

While future posts will explore the ITL in greater detail, including diving into Identity trends and perhaps even specific attack campaigns, in this post, we’ll stick to some high-level observations.

For example, consider the chart below, which shows the ITL for the Travel/Transportation industry, across all regions, from January 1st, 2023, through April 1st, 2023.

Just from a quick visual examination, we can see that so far in 2023, this ITL fluctuates up and down around an average of about 5.5, with the peaks corresponding to weekends (some industries exhibit this weekday/weekend pattern, and others don’t).

![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/4ahrXj9vXgxuQnLrwXlU6w/b5df3271d0dee7ac8a87819a8247e38f/Battling_Bots_01.png)

Next, let’s use the ITL to see how the threat of bots varies across industries. In the chart below, we’ve zoomed out to a weekly view to more clearly showcase the general trends in Financial Services, Retail/eCommerce, and Software/SaaS/Tech.

We can see that of the three industries, Retail/eCommerce has experienced the highest peak ITL (nearly 8) and has had an average score of around 6. During the same period, Financial Services peaked at an ITL of 7 but has generally trended downward, while Software/SaaS/Tech has maintained a fairly constant ITL of around 5.5


![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/29k788paxQ9AF3bksWHWuB/da9f6822e69ea5ed48364c5ab8558561/Battling_Bots_02.png)


For our third example, let’s shift our attention to Healthcare (with a global aggregation and weekly granularity). It’s clear that around the beginning of March, bot activity targeting the Healthcare industry picked up significantly — jumping from a baseline ITL of around 3.5 to repeated peaks approaching 6.0!

Do providers of Healthcare apps know that they’re under siege — and would they configure their defenses differently if they knew?

![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/Wb4zGX0ZgOOjDzlBYtD2M/1cf104b5bca618e3be5df9e2ed2aba82/Battling_Bots_03.png)

As our final example, let’s return our attention to Travel/Transportation, but this time we’ll go one level deeper and examine the ITL for three different geographies: the Americas (AMER), Asia-Pacific (APAC), and Europe, the Middle East, and Africa (EMEA).

From this breakdown, we can see that while the composite Travel/Transportation ITL tends to be in the range of 5.5 to 6.0, the threat level varies considerably by region: APAC and EMEA are largely in the 3.0 to 4.0 range, while the AMER score has remained above 7.0 for all of 2023!

![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/68RTbaQaVFgqNYO5rOsmJ0/23995c6abed960115b391617a78f184d/Battling_Bots_04.png)

## Looking Ahead

Anonymous firmographic metadata can help us not only to monitor _what_ is happening but also _why_. As a result, the ITL is about more than just observing attack trends — it’s about surfacing insights and informing actions to protect both providers and users of online services.

At the same time, ITL scores equip the broader security community with data that — until now — has only been available to a handful of organizations.

Ultimately, we’ve really only begun to scratch the surface of the insights that ITL scores can provide, and we invite you to join us on this journey of discovery.

Battling Bots: Introducing the Identity Threat Level (ITL)

People are saying Ruby is dead, while others use it widely in their companies. Let's dive into the history of Ruby. From its birth to how it's doing today and to what the future holds.

[Ruby](https://en.wikipedia.org/wiki/Ruby_(programming_language%29) is an interpreted, open-source programming language with a focus on simplicity and productivity. **Ruby is already 30 years old**, and it has become one of the most used programming languages. 

Some claim Ruby is dead; others use it widely in their companies. Join me in this blog post as we learn about Ruby's history and where it stands today. 

## How It Started

[Ruby was born on Feb. 24th, 1993](https://youtu.be/gTNC26BtRFc?t=85). This was the day when [Yukihiro Matsumoto](https://en.wikipedia.org/wiki/Yukihiro_Matsumoto), also known as **Matz** and creator of Ruby, decided along with his colleague Keiju Ishitsuka what the name of the language was going to be during a chat conversation: 

```plain-text
matz> Let us decide the codename now
matz> tentative one.
keiju> Ok.  
matz> What is your best up to now?
keiju> I'm content with coral.  
matz> I thought ruby is cool as a codename, isn't it
keiju> Well. Ruby is also good.  
matz> But, coral is also good
matz> arrr
```
<center>*[Extract from the chat between Matz and Keiju back in Feb 1993](https://blade.ruby-lang.org/ruby-talk/88819)*</center>
<br/><br/>

They knew they wanted to name the programming language after jewels, so they were considering *Ruby* and *Coral*. As Matz explains in his talk [Ruby After 25 Years](https://youtu.be/gTNC26BtRFc?t=286), Coral was longer by one character making it more annoying to write multiple times. *Ruby was shorter and more beautiful*.

Matz created Ruby because he wanted a simple object-oriented, easy-to-use scripting language. He added the features he loved the most, such as iterators, exception handling, and garbage collection. 

Ruby is a clean, simple, and powerful object-oriented programming language. There are no curly braces; scopes are clearly defined by blocks, and overall makes you happy to use it. This was, in fact, one of Matz's goals when creating the language:

> "I hope to see Ruby help every programmer in the world to be productive, enjoy programming, and be happy. That is the primary purpose of Ruby language."
&mdash; <cite>[Matz on Ruby 1.9, Google TechTalks 2008](https://youtu.be/oEkJvvGEtB4?t=1795)</cite>

I mean, look at this thing: 

```ruby
class Numeric
  def plus(x)
    self.+(x)
  end
end

y = 5.plus 6
# y is now equal to 11
```

I can't imagine a more beautiful thing 🤩. 

This code creates a new class, `Numeric`, with a `plus` method. Because everything is an object in Ruby, you can call this method with anything, even a number! We do this in the example `y = 5.plus 6`. The `Numeric` class is just a small example of what Ruby can do, but I'm sure it gives you an idea of its power.  

But Ruby has come a long way from the first version to the current one. After naming the language in 1993, `ruby-0.95` was released to the Japanese domestic newsgroups on Dec. 21st, 1995. In 1996 `ruby-1.0` was released, and in July 1997, Matz announced that **he had been hired by [netlab.jp](https://www.netlab.jp/), a Japanese open source company, to be a full-time Ruby developer**. This only helped accelerate the implementation of Ruby, so on Aug. 13th, `ruby-1.1` was released, and on Sept. 22nd, 1997, the first article about Ruby was published. I did my best to find it, but it is not available anymore 😭.

The popularity of Ruby was growing every day in Japan, and as more and more developers started to use Ruby, the first Ruby books were published to support the community's continued learning. The first was "The Object-Oriented Scripting Language Ruby" by Matz himself.

![The Object-oriented Scripting Language Ruby 1999 edition book cover](https://images.ctfassets.net/23aumh6u8s0i/5qtUsDS2rpmpR3AIZABxgc/f06c643901227a3a2fb449223415aba9/amazon-ruby-book.jpg)


In 2000 [Ruby was more popular than Python in Japan](http://ruby-doc.com/docs/ProgrammingRuby/html/foreword.html), and the acceptance and growth of the language were starting. In 2004, a new server-side web application framework was born: [Ruby on Rails](https://rubyonrails.org/). The launch of Rails, together with the fact that [Apple announced that it would ship Ruby on Rails with Mac OS X v10.5 "Leopard"](https://rubyonrails.org/2006/8/7/ruby-on-rails-will-ship-with-os-x-10-5-leopard) helped Ruby to become the [Language of the Year in 2006](https://www.tiobe.com/tiobe-index/ruby/) and to be used mainly for web development. 

Fast-forward to 2016, Ruby reaches the highest position (since 2001) in the TIOBE index at number 8, and its usage is peaking. Between 2013 and 2020, we went from `ruby2.0.0` to `ruby3.0.0`, and the community and the language were more and more mature. 

But where is Ruby now? 

## How It's Going 

Ruby is at version [`ruby3.2.1`](https://github.com/ruby/ruby/releases/tag/v3_2_1) as of the date of publishing this article, and by the end of 2022, there were [2.4 million Ruby developers](https://www.slashdata.co/free-resources/state-of-the-developer-nation-23rd-edition?) out there.

At the beginning of this article, I mentioned that some people say Ruby is dying, and I'm afraid I have to disagree with this statement. Ruby, as technology, still creates value nowadays, which is essential to remember. When technology creates value, it also creates jobs, opportunities, and money. 


Now let me tell you why Ruby is still creating value:

### Ruby lives to its purpose: *programmer happiness*

You can take it from me, or you can take it from [other people in the industry.](https://jetrockets.com/blog/is-ruby-still-alive-in-2023) The reality is programming in Ruby is truly joyful, and if you still need to do it, I highly recommend you try it. 

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
<strong>We have created step-by-step guides to help you integrate Auth0 with your Ruby on Rails application. Check out the 
<a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/web-app/rails/basic-authentication">Rails Authentication By Example</a> and the <a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/api/rails/basic-authorization">Rails Authorization By Example</a> guide, which also covers the concept of <a onclick="window.metricsLib.track('from_blog_to_devres')" href="https://developer.auth0.com/resources/guides/api/rails/basic-authorization#set-up-role-based-access-control-rbac">Role-Based Access Control (RBAC)</a> and let yourself fall in love with Ruby😍.</strong>
</div>

### Ruby is widely used in big companies 🧑‍💻

[Ruby is widely used in the tech industry](https://toprubycompanies.info/) by some of the biggest companies like Airbnb, Shopify, Coinbase, and Gitlab. Some are significant contributors to Ruby's source code and Ruby on Rails. 

### Ruby makes money 🤑

In 2022, Ruby and Ruby on Rails are still listed as [the top-paying technologies](https://survey.stackoverflow.co/2022/#top-paying-technologies) for developers, with a median yearly salary of about $90,000. 

Also, because big publicly-traded companies are using Ruby, [the total market cap of only 46 (!) of them is currently at about $284 Billion.](https://toprubycompanies.info/)

### Ruby has a great community

The [Ruby community](https://www.ruby-lang.org/en/community/) is highly active, and many projects contribute to it. One of them is the [Rails Foundation](https://rubyonrails.org/foundation) which aims to improve the documentation, education, marketing, and events to benefit all new and existing Rails developers. 

Also, Ruby is open source, and everyone can contribute to its development; this also means it can quickly evolve to fit developers' needs in the future. 

## What’s Next?

[Ruby 3.0](https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/) was released in 2020 with many improvements and new features, so the plan to keep improvement remains. 

Some of the improvements, ambitions, and features that Ruby will be working on are the following: 

- **Ruby 3x3**: 
  - It started as "Make Ruby 3.0 run 3 times faster than Ruby 2.0", but it [has been revisited in 2021](https://youtu.be/Dp12a3KGNFw?t=2757) and changed to *"Ruby 3.x will be 3 times faster than Ruby 3.0 "* so we will see more and more performance improvements!
- **Performance**: 
  - Ruby 3.2 adds a lot of performance improvements, such as re-implementing the [MJIT](https://www.rubyguides.com/2018/11/ruby-mjit/) compiler in Ruby and executing it under a forked process instead of using a native thread. 
  - [YJIT](https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md) is now production-ready, and there will be more performance improvements coming as shown by [Alan Wu in RubyKiagi 2022](https://youtu.be/EMchdR9C8XM?t=1910).
- **Concurrency / Parallelism**:
  - Ruby 3.0 introduced [Ractors](https://ruby-doc.org/core-3.0.0/Ractor.html), an [actor-model abstraction](https://en.wikipedia.org/wiki/Actor_model) that provides a parallel execution feature without thread-safety concerns. Ractors have improved since they were first released and will continue their development to ensure Ruby is more *thread-safe* than ever. 
- **Static Analysis with [RBS](https://github.com/ruby/rbs) and [Typeprof](https://github.com/ruby/typeprof)**: both of these tools were released with Ruby 3.0 are still being improved in new versions. 
  - RBS allows you to add type annotations to your Ruby code in files with a new extension called `.rbs`.
  - Typeprof is a type analysis tool that reads plain (non-type-annotated) Ruby code, analyzes what methods are defined and how they are used and generates a prototype of type signature in RBS format.

## Conclusion 

Ruby is an object-oriented and interpreted programming language created by Yukihiro Matsumoto in 1993. Ruby was quickly adopted in Japan and then expanded to the rest of the world; it gained popularity when the Ruby on Rails framework was released. Ruby has peaked in popularity over the years and remained relatively stable. 

Ruby is still widely used in big companies like Shopify, AirBnb, and Github, which also contribute to the source code and investment and language development. 

Programming languages' popularity and the features that developers seek come and go. A few years ago, developers didn't want to deal with static typing; now, they do, for example. It is hard to predict whether Ruby will become extremely popular, but surely Ruby is still alive, and it will live as long it continues to create value for the community and companies but also while it makes developers happy. 

A Brief History of Ruby

Broken Object Level Authorization is the most critical API security vulnerability. Learn how Fine Grained Authorization (FGA) can help fix it.

According to [OWASP](https://owasp.org/), the worldwide web security community, Broken Object Level Authorization (BOLA) is the most critical vulnerability affecting APIs. What is this vulnerability? How can it be exploited? How can you prevent it in your API? Keep reading to find the answers to these questions.

## What Is OWASP API Security Top Ten?

One of the main goals of the OWASP community is to make developers and technologists aware of the risks their applications and systems are exposed to. With this in mind, the community publishes some documents that highlight what are the most common security risks.

The [OWASP Top Ten](https://owasp.org/www-project-top-ten/) document is the most popular one. It focuses on web development in general. But there is also a more specific document for APIs: the [API Security Top Ten](https://owasp.org/www-project-api-security/).

Both the 2019 and the [2023](https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc.html) versions of the document report that [Broken Object Level Authorization](https://github.com/OWASP/API-Security/blob/master/2023/en/src/0xa1-broken-object-level-authorization.md) is the most critical security risk. It's incredible that after four years this security risk is still affecting APIs around the world! Is there a way to mitigate if not eliminate this vulnerability?

The answer to this question is positive: you can prevent  this vulnerability from affecting your API by designing a proper authorization system. But before you get to the solution, let's learn what Broken Object Level Authorization is.

## What Is Broken Object Level Authorization?

Authorization is the process of determining what a user has access to. This access control can be done in many different ways based on the business rules of the specific application.

In the API context, each request to a protected endpoint should be analyzed to determine if the client is authorized to access and perform the requested action. Typically, this check is done at the code level and is based on verifying that the client has the right permissions to access the resource (the object) exposed by the API endpoint.

The main problem in this case is to define what is the actual resource to protect.

In some scenarios, it's the API endpoint itself. Consider the `/profile` endpoint: it implicitly returns the profile data of the current user. The API may know who the current user is from the session storage or from the access token sent along with the request.

In other scenarios, the object to protect is the requested resource. Consider the endpoint `profile/42`, which returns the profile data of the user with ID 42. In this case, comparing the current user ID to the requested user ID may not be correct. Think of an administrator who should have access to the profile data of all the users. The authorization check should verify that the current user has permission to access the requested object.

Inaccurate permission checking in endpoints that use object IDs exposes the API to BOLA attacks. In fact, an attacker could manipulate the object ID to gain access to an object for which they have no permissions.

> In the past, the Broken Object Level Authorization (BOLA) vulnerability was called Insecure Direct Object Reference (IDOR). The name was changed because it suggested that the problem was with the ID, while in fact it's with the authorization check.

## An Example of BOLA Vulnerability

To understand how a Broken Object Level Authorization vulnerability can be exploited by an attacker, let's use a practical example.

Suppose your bank provides you with an app to manage your account. Being a curious developer, you take a look at how your app interacts with the server. You notice that it calls the endpoint `https://thebankwebsite.com/accounts/9876543` to get data about your own account whose number is 9876543.

You remember that one of your friends has the same bank as you. You also remember that you made a money transfer to him in the past, so you look for his account number in the messages he has sent you. You find out that his account number is 1029387. So, you take curl or another HTTP client and replay your HTTP request to the bank's server by changing the endpoint's URL: `https://thebankwebsite.com/accounts/1029387`.

Surprisingly, you get the data about your friend's account from the server! This means that the bank's API has a BOLA vulnerability. Their authorization check fails at the object access level.

You can imagine, for example, that the API implementation for that particular endpoint is as follows:

```javascript
const express = require('express');
const app = express();
const { auth, requiredScopes } = require('express-oauth2-jwt-bearer');

//This checks that the provided access token is valid
const validateAccessToken = auth({
  audience: '...yourApiIdentifier...',
  issuerBaseURL: `https://...yourDomain.../`,
});

//This checks that the provided access token grants reading permissions
const checkReadPermissions = requiredScopes('read:account');

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          res.json(getAccountData(req.params.accountNumber));
        }
);
```

This Node.js Express code snippet shows how a GET request on the `/accounts/:accountNumber` endpoint is handled. Note that the endpoint is protected by two middleware:

- `validateAccessToken`, which ensures that the client provides a valid access token.
- `checkReadPermissions`, which ensures that the access token contains the required `read:account` scope in order to allow the client to access the requested account.

Unfortunately, these checks are not sufficient to implement an accurate access to the account object. In fact, they will not prevent you from accessing your friend's account.

<include src="ebook-ads/WebSecurity" />

## How to Prevent BOLA Vulnerabilities

What measures can you take to prevent BOLA vulnerabilities?

A common suggestion is to avoid using easily recognizable object identifiers in your endpoint URL, such as the bank account number in the example above. This measure prevents the knowledge of the object ID from allowing an attacker to compose a specific HTTP request. For example, you could use a GUID in the URL to identify the bank account instead of the bank account number itself. GUIDs are randomly generated values and make them very difficult to guess.

This approach can mitigate the risk of BOLA attacks, but it doesn't solve the problem. If the attacker finds a way to determine the GUID associated with a bank account, this protection will be bypassed.

The real problem is not in the object ID but in the authorization mechanism. The access control of your API should not be limited to controlling access to the endpoint. It should verify that only authorized users can access **the object exposed by the endpoint**.

In the bank account example, this means that additional checks should be performed. For example, you can check that the current user is the owner of the account, as outlined below:

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

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          const userId = req.auth.payload.sub;
          const account = getAccountData(req.params.accountNumber);
  
          if (account.userId == userId) {
            res.json(account);  
          } else {
            res.status(403).json("Permission denied."); 
          }
        }
);
```

This would solve the unauthorized access to the bank account described earlier. However, it might not cover other scenarios. For example, consider a bank account with multiple owners. Each owner could have different permissions on the account. Also consider a bank employee: they should be able to access the accounts of their branch customers. And perhaps a regional manager should be able to access the accounts of multiple branches.

As you can see, the authorization policy that your API should implement strictly depends on the specific business logic. This logic is mainly determined by the relationship between users and resources. When this relationship becomes complex, your API code run the risk of getting messed up.

## What Is Fine-Grained Authorization?

To handle complex authorization policies, you should use Fine Grained Authorization (FGA). FGA allows you to control access to resources by analyzing a context described by various attributes and relationships. By having access to a detailed context, you can more effectively control who can access what in your system.

You can design and implement FGA in a variety of ways, but the most common models are as follows:

- **Attribute-Based Access Control (ABAC)**. This authorization model allows you to make authorization decisions by evaluating attributes such as the user's role or age, the resource type or size or status, the action requested, the current date and time, and so on.
- **Policy-Based Access Control (PBAC)**. This authorization model allows you to make authorization decisions based on policies. It is very similar to ABAC. The main difference is that PBAC focuses more on logic while ABAC relies more on data.
- **Relationship-Based Access Control (ReBAC)**. This authorization model focuses on the relationship between users and resources. This also includes relationships between resources. ReBAC provides a more expressive and powerful authorization model that can describe very complex contexts.

Okta offers [Fine Grained Authorization](https://fga.dev) through two solutions based on the ReBAC model:

- [Auth0 FGA](https://dashboard.fga.dev/). This is an *authorization service* that centralizes your authorization logic and data. It allows you to define your authorization model, store your authorization data, and make your authorization decisions across all your applications. Read the [Auth0 FGA documentation](https://docs.fga.dev/intro/authorization-and-auth0-fga) to learn more.
- [OpenFGA](https://github.com/openfga). This is the Open Source project powering the Auth0 FGA service. You can install the [OpenFGA Server](https://github.com/openfga/openfga) and use its SDKs to integrate authorization into your applications.

## How FGA Solves BOLA Vulnerabilities

Auth0 FGA and OpenFGA allow you to fix Broken Object Level Authorization vulnerabilities in your APIs without messing up your code. Whether you use the hosted product or install the Open Source engine on your servers, FGA allows you to centralize the access control to the resources protected by your API.

You can do this in three steps:

1. **Define your authorization model**. In this step, you define the types of objects in your system and their possible relationships with each other. The authorization model is usually fairly static once written. Check out [this document to learn more about defining your authorization model](https://docs.fga.dev/modeling).
2. **Store your authorization data**. This step allows you to define the actual data and its relationships according to the authorization model you defined in the previous step. This represents the state of the system and will be changing as users interact with your application.
3. **Add authorization check to your API**. In the third step, you integrate authorization checks into your API and start leveraging the power of FGA.

### Define your authorization model

Going back to the bank account example, you can define your authorization model in Auth0 FGA by using its [configuration language](https://docs.fga.dev/modeling/configuration-language). The following code shows a minimal example of how your model could be written:

```yaml
model
  schema 1.1
type user
type branch
  relations
    define employee: [user]
type account
  relations
    define branch: [branch]
    define owner: [user]
    define can_create: employee from branch
    define can_view: owner or employee from branch
```

Notice that the last line in the model above defines the account owner and the employees of the branch where the account was opened as the legitimate viewers. This is the basis for avoiding the Broken Object Level Authorization problem.

Using the [Auth0 FGA Playground](https://play.fga.dev/), you can also get a visual representation of this model:

![The bank authorization model in the Auth0 FGA Playground](https://images.ctfassets.net/23aumh6u8s0i/3cklRF8G4IPBGWb07P4JsI/a75e9daf57459430a9c40f620aad7792/auth0-fga-bank-authorization-model.png)

> You can play with the model used in this article by [making your own copy](https://play.fga.dev/stores/create/?id=01GVMW810J23DEBPGT22MFE4M7).

### Store your authorization data

As the next step, you fill this model with actual data. You define your users and add a direct relationship to the objects in your model. You also define relationships between objects and other aspects that depend on your specific model. You provide data to the system using tuples. For example, the following tuples define some relationships related to the bank model presented earlier:

```json
[
  // User Mary is the owner of the account 12345
  {
    "user": "user:mary",
    "relation": "owner",
    "object": "account:12345"
  },
  // User John is an employee of the branch b1
  {
    "user": "user:john",
    "relation": "employee",
    "object": "branch:b1"
  },
  // Account 12345 was created in the branch b1
  {
    "user": "branch:b1",
    "relation": "branch",
    "object": "account:12345"
  }
]
```

To learn how [to populate your authorization model with data, read this document](https://docs.fga.dev/writing-data).

### Add authorization check to your API

Finally, you can add the authorization checks to your API using one of the [available SDKs](https://docs.fga.dev/integration/install-sdk). Referring back to the bank example, the Node.js Express code will perform its authorization checks as follows:

```javascript
const { OpenFgaApi } = require('@openfga/sdk');
const fgaClient = new OpenFgaApi({
  //...configuration...
});

// ...existing code...

app.get('/accounts/:accountNumber', 
        validateAccessToken, 
        checkReadPermissions,
        function(req, res) {
          const userId = req.auth.payload.sub;
          const account = getAccountData(req.params.accountNumber);
  
          const { allowed } = await fgaClient.check({
            tuple_key: {
              user: `user:${userId}`,
              relation: 'can_view',
              object: `account:${req.params.accountNumber}`,
            },
          });
  
          if (allowed) {
            res.json(account);  
          } else {
            res.status(403).json("Permission denied."); 
          }
        }
);
```

The authorization check is performed by `fgaClient.check()`, which passes the tuple to be verified to the FGA engine. The FGA engine uses the authorization model and the data you provided to determine if the current user is authorized to view the requested account. Since you have defined there who the legitimate viewers of this account are, your API is not BOLA vulnerable. In addition, your code is kept clean.

Read more about [integrating FGA into your API](https://docs.fga.dev/integration).

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

## Summary

By the end of this article, you should have a clearer idea of what Broken Access Level Authorization is and how Fine Grained Authorization can help prevent it.

You have begun to explore what BOLA is and how it can be exploited with a practical example. You have seen that the root cause of this vulnerability is an inadequate authorization system. You learned about FGA and saw what Auth0 offers in this area.

Using the API example analyzed earlier, you learned how to integrate it with Auth0 FGA to overcome the BOLA vulnerability in three steps: define an authorization model, populate the model with data, and invoke the authorization check from the API.

In addition to avoiding BOLA vulnerabilities, Auth0 FGA provides a powerful authorization system to solve very complex scenarios effectively and efficiently. [Give it a try](https://fga.dev/).


How Fine Grained Authorization Solves the Most Critical API Security Risk

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

In this post you will learn about Single Sign-On (SSO) authentication and how to use it for your web apps

[Single Sign-On (SSO)](https://auth0.com/resources/whitepapers/definitive-guide-to-single-sign-on) authentication is now required more than ever. Nowadays, almost every website requires some form of authentication to access its features and content. With the number of websites and services rising, a centralized login system has become a necessity. In this post, we will study how **SSO authentication** is implemented for the web. Read on!

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

## Federated Identity Glossary

The concept of a centralized or linked electronic identity is known as *federated identity*. Federated identity systems handle several concerns:

- Authentication
- Authorization
- User attributes exchange
- User management

The **authentication** aspect deals with validating user credentials and establishing the identity of the user.

**Authorization** is related to access restrictions (e.g., is the user allowed to access X resource?). 

The **attributes exchange** aspect deals with data sharing across different user management systems. For instance, fields such as *"real name"* may be present in multiple systems. A federated identity system prevents data duplication by linking the related attributes. 

Lastly, **user management** is related to the administration (creation, deletion, update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.

SSO is strictly related to the **authentication** part of a federated identity system. Its only concern is establishing the identity of the user and then sharing that information with each subsystem that requires the data. Below, we focus on this crucial aspect of a federated identity system.

![What is single sign-on separator 1](https://images.ctfassets.net/23aumh6u8s0i/2xIzg7UIbBpGNvCeRsdn4k/32f29b73fc2b4bd33bac6fe124d9bfb1/what-is-sso-1)

## Single Sign-On (SSO) Authentication

Sooner or later web development teams face one problem: you have developed an application at domain X and now you want your new deployment at domain Y to use the same login information as the other domain. In fact, you want more: you want users who are **already logged-in** at domain X to be already logged-in at domain Y. This is what SSO is all about.

![Non-Single-Sign-On Scenario](https://images.ctfassets.net/23aumh6u8s0i/4pa532TumNn6TI3gQmMWEw/0a6182b447b75b24bea1b763c1ba73a1/non-sso-scenario)

The obvious solution to this problem is to **share session information** across different domains. However, for security reasons, browsers enforce a policy known as the [*same origin policy*](https://en.wikipedia.org/wiki/Same-origin_policy). This policy dictates that cookies (and other locally stored data) can **only be accessed by its creator** (i.e. the domain that originally requested the data to be stored). In other words, domain X cannot access cookies from domain Y or vice versa. This is what SSO solutions solve in one way or the other: sharing session information across different domains.

![No cookie sharing](https://images.ctfassets.net/23aumh6u8s0i/2WJQLWBpByFyth3ufF3Af0/5f341d8816d77f20dc05c5a2f31ec89f/same-origin-policy-forbids-this)

Different SSO protocols share session information in different ways, but the essential concept is the same: there is a **central domain**, through which authentication is performed, and then the **session is shared** with other domains in some way. 

For instance, the central domain may generate a signed [JSON Web Token (JWT)](https://auth0.com/docs/jwt), which may be encrypted using [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516). This token may then be passed to the client and used by the authentication domain as well as any other domains. The token can be passed to the original domain by a redirect and it contains all the information needed to identify the user for the domain requiring authentication. As the token is signed, it cannot be modified in any way by the client.

![SSO - Central authentication domain](https://images.ctfassets.net/23aumh6u8s0i/2GrAhJRypY1XQx3TIDbqzO/ecbd47c21f1e1c1fd334a239b9015a08/using-central-auth-domain)

Whenever users go to a domain that requires authentication, they are **redirected** to the authentication domain. As users are **already logged-in** at that domain, they can be immediately redirected to the original domain with the necessary authentication token.

![Single Sign-On Authentication](https://images.ctfassets.net/23aumh6u8s0i/4hakDPwQtaPfcDNwkd4C9x/e54ee76304953540b4b71fcccbaf690a/typical-sso-v2)


## SSO Authentication with Auth0

If you have been reading about SSO online, you have probably found that there are many different implementations: OpenID Connect, Facebook Connect, SAML, Microsoft Account (formerly known as Passport), etc. Our advice is to choose whatever is simplest for your development efforts. For instance, [SAML](https://auth0.com/docs/protocols/saml) is deeply entrenched in enterprise developments, so in some cases, it will make sense to pick that. If you think you will need to integrate your development with more than one alternative, don't despair: there are frameworks that allow interoperability between different SSO solutions. In fact, that's one of the things we do at Auth0.

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

You can go and check our [docs on Single Sign-On](https://auth0.com/docs/sso/single-sign-on) and the [Auth0 SSO samples](https://github.com/auth0/auth0-sso-sample).

If you remember the Typical SSO Scenario diagram we saw earlier, you can see how Auth0 comes to play in the next diagram:

![SSO with Auth0](https://images.ctfassets.net/23aumh6u8s0i/5n5APnJDhCtUiyZvyAG6rK/5a9faf400e436dd131bdee21b81c8761/auth0)

In this case, **Auth0 is the [Authentication Server](https://auth0.com/blog/what-is-an-authentication-server/)** and it works as a *bridge* between different SSO frameworks. 

<include src="ebook-ads/SsoGuide" />

## Conclusion

Single Sign-On authentication is here to stay. Decentralized systems are becoming more and more common and authentication is an essential aspect of all of them. SSO solves a big problem: how to manage the increasing number of users across a whole ecosystem of applications and services. Frameworks such as [OpenID Connect](https://auth0.com/resources/ebooks/the-openid-connect-handbook?ref=blog) and services such as the one we provide at Auth0 make [integrating Single Sign-On](https://auth0.com/learn/how-to-implement-single-sign-on/) into your new or existing applications much easier. If you are implementing authentication for a new application or service, consider integrating SSO from the get-go.

![What is single sign-on separator 3](https://images.ctfassets.net/23aumh6u8s0i/5L0CZk6C2On5CTXSHlE3MF/50e145cd648e88dd800f90ca19cfa1e4/what-is-sso-3)

What Is Single Sign-On Authentication (SSO) And How Does It Work?

Learn how to implement a Sinatra API and protect its endpoints using Auth0

Add Authorization to a Sinatra API using Auth0

arthur-bellore

I’m a tech content creator. I enjoy breaking up seemingly complicated topics into easy-to-understand pieces for people to read. When I’m not in front of a computer, you’ll usually find me reading books.

Cybersec Writer

Arthur Bellore

Transport Layer Security (TLS) is the cryptographic protocol behind pretty much any computer network used today: from web browsing to email, APIs, and VoIP. But how exactly does it work?

## SSL vs. TLS

SSL, or Secure Sockets Layer, is the predecessor to TLS. It was a cryptographic protocol developed by Netscape in 1994, but since it had serious flaws, it was never released to the public. SSL 2.0 was released publicly one year later, in 1995, but it, too, was found to have serious flaws. Finally, SSL 3.0 was rebuilt from the ground up and released in 1996.

Microsoft, who had its own version of the protocol, and Netscape agreed to hand over the project to the Internet Engineering Task Force (IETF) and make it an open standard. As part of the deal, the name was changed to TLS, Transport Layer Security, to signify that it no longer had ties with Netscape.

The first upgrade to SSL 3.0 was published in 1999 in [RFC 2246](https://datatracker.ietf.org/doc/html/rfc2246) as TLS 1.0. Tim Dierks, the editor of RFC 2246, has said [in his blog](https://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html) that TLS 1.0 was really SSL 3.1, but they changed the name “so it wouldn’t look the IETF was just rubberstamping Netscape’s protocol.” Indeed, if you look at RFC 2246, it says:

This document describes TLS Version 1.0, which uses version { 3, 1 }. Version value 3.1 is historical: TLS version 1.0 is a minor modification to the SSL 3.0 protocol, which bears the version value 3.0.

TLS became the standard of encryption and authentication over computer networks, and it’s still being used today. The most recent version of the protocol is TLS 1.3, which was released in August 2018.

### What is the difference between SSL and TLS?

SSL hasn’t been updated since its release in 1996, and it was deprecated in 2015 in [RFC 7568](https://datatracker.ietf.org/doc/html/rfc7568). Most [modern browsers disable it by default](https://en.wikipedia.org/wiki/Version_history_for_TLS/SSL_support_in_web_browsers) or don’t support it outright anymore.

Despite this, because of the association between the two, many people still use the term SSL when they really mean to say TLS. Vendors typically use the same terms their target customers use to facilitate messaging, so their marketing collateral generally contains terms such as “SSL/TLS” or “SSL,” even though SSL is deprecated.

We now know that SSL and TLS are different things, but for the remainder of this article, SSL will be used interchangeably with TLS to match its everyday usage.

## Why SSL/TLS Was Created

For two computers to communicate with each other, they must perform a set of agreed-upon operations in a specific order. A **protocol** is what dictates those operations. The HTTP protocol is the protocol that web servers and clients use to establish a connection and communicate with each other through the Internet.

It works roughly as follows:

1. The server listens for new connections on port 80
2. The client connects to the server, and this starts a chain of operations as set forth by the HTTP protocol
3. The client sends a GET request to the server; the server receives the request, processes it, then sends back a response: headers and index.html, plus other content it might need to serve (CSS files, JavaScript files, cookies, etc.) for the client to render the content correctly.

This works to distribute content between two remote computers, but there is a problem: HTTP was intended to expand the local knowledge management tools throughout the multiple computers at CERN in the late 1980s, so it was designed as a clear text protocol.

Because it’s clear text, a malicious actor could insert themselves between client and server and potentially read sensitive information, such as credit card numbers or passwords, or they could intercept the client’s requests and serve back malicious files pretending to be server.

As the Internet evolved and the number of sensitive information flying around increased exponentially, an encryption layer sitting below HTTP was necessary. However, this is a bit tricky: if a bad actor can “listen in” the conversation between client and server while the connection is unencrypted, how can they exchange encryption keys securely?

One option would be for the two parties to create a public-private key pair and send over the public key pair to the other party, so they can use that to encrypt their packet before sending them over the wire.

The problem with this is that asymmetric (public-key) cryptography is _much slower_ than symmetric cryptography.

The "strength" of asymmetrical cryptography relies on modular arithmetic, mathematical operations that are very hard to do in the opposite direction. The numbers used in these operations need to be big enough to provide the necessary security, but performing arithmetic with very large numbers can be taxing on a CPU.

Symmetric cryptography, on the other hand, works differently and does not suffer from this problem. On top of that, most devices have AES instruction sets integrated into their CPUs to speed up AES operations, making AES encryption have almost zero overhead on modern devices.

The TLS protocol gets around this issue by using asymmetric cryptography to exchange keys at the beginning and then switch to symmetric keys (“sessions keys”) from then on in a process known as the TLS handshake.


## TLS handshakes

The exact steps of the TLS handshake will depend on which TLS version is supported by the client and server, as well as which parameters they are set to use.

Since most modern browsers still support TLS 1.2 and a lot of websites still use TLS 1.2 (according to a [paper published by Syed-Winkler](https://www.grin.com/document/1037281), as of February 2021, TLS 1.3 is supported by 42.9% of surveyed websites, while TLS 1.2 is supported by 99.3%), we will talk about TLS 1.2 first and then discuss how TLS 1.3 differs from 1.2.


### The TLS 1.2 handshake

TLS 1.2 can be configured to use many key exchange algorithms, and among them, the most well-known and widely used is the RSA key exchange algorithm. Let’s go over how the RSA algorithm works in TLS 1.2, then talk about how the process differs in TLS 1.3 with the [Diffie-Hellman](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) (DH) key exchange algorithm.

The RSA key exchange works roughly as follows in TLS 1.2:

1. **Server listens for new connections on port 443.**
2. **Client connects to port 443 and initiates the handshake process with a ClientHello message to the server.** This message contains the TLS versions and cipher suites the client supports and a 32-byte random number known as Client Random.
3. **Server says “hello” back with a ServerHello message.** The server selects a cipher and the TLS version from the list provided by the client, then generates a different 32-byte random number known as Server Random and sends it all back along with the server’s own SSL certificate.
4. **Client uses the SSL certificate to verify the server’s identity.** SSL certificates contain a public key generated by the server and a digital signature signed with the private key of a trusted third party known as a certificate authority (CA). Most web browsers and operating systems come bundled with public keys from trusted CAs, which are used to verify that the CA issued the certificate.
5. **The client verifies the server has the matching private key to the certificate through ClientKeyExchange.** The client generates the pre-master secret (a 48-byte random number) and encrypts it with the server’s public key obtained from the certificate. If the server is the true owner of the certificate, it must be able to decrypt the message and obtain the original pre-master secret.
6. **Server decrypts the pre-master secret.** Now both the server and client have the pre-master secret, the Server Random, and the Client Random. They can use that to derive the master secret using the previously agreed cipher and arrive at the same (symmetric) key, which will become the session key once both parties verify their keys match.
7. **Client sends a ChangeCipherSpec message.** This indicates that the client is ready to create the session key and start communicating through an encrypted tunnel using that key.
8. **Client proves to server it has the correct keys.** The client hashes all handshake records up to that point, encrypts them with the session key, and sends them to the server. If the server generates the correct key, it will be able to decrypt that message and verify the record hashes (which the server can independently generate).
9. **Server proves to the client that it has the correct keys.** The server does the same thing and sends it to the client.
10. **A secure connection is established.** If both keys match, the TLS handshake is complete.

<br>
#### Problems with TLS 1.2

TLS 1.2 left a lot of its configuration parameters up to the users, which often resulted in bad choices (the old security adage of “among too many options, the worst one will be chosen”).

Additionally, in the name of backward compatibility, TLS 1.2 also allowed old, insecure ciphers to be used. (TLS 1.2 itself was released in 2008.) As time passed, it became more prone to attacks as vulnerabilities in older cipher or versions of TLS were discovered.

On top of all that, the RSA key exchange has a few weaknesses:

* **The same public-private key pair is used both to authenticate the server and to encrypt the pre-master secret (item #5 above).** If an attacker obtains the private key, they will be able to re-generate the session keys and be to decrypt the entire session.
* **There is no Perfect Forward Secrecy (PFS).** Since the server’s private key doesn’t change, an attacker might record and store encrypted data for years, hoping to decrypt it years down the line if the server’s private key is ever leaked or compromised.
* **Performance.** It’s necessary to make two round trips between the client and server until the session key is established.

To address these problems, the IETF began developing TLS 1.3 in 2013 and finally released it to the public in August 2018.

### What changed in TLS 1.3

In practice, the main differences between TLS 1.3 and 1.2 are:

* Shorter handshake
* Only supports key exchange algorithms with perfect forward secrecy (PFS), such as ephemeral Diffie-Hellman
* Support for 0-RTT (Zero Round Trip Time) resumption

This represents a bit of a paradigm change in TLS 1.3: shifting the focus from user configurability and backward compatibility to security by being more opinionated.

This allowed the designers to create a shorter handshake (by restraining DH as the only key exchange algorithm) but also prevented developers from choosing insecure options by restricting the number of options available in the first place.

For example, while it was technically possible to use DH as the key exchange method in TLS 1.2, the participants were responsible for setting the DH parameters. Picking the right parameters is crucial to make sure the DH exchange is secure, as some parameters can be trivially broken.

In 2015, security researchers [published a paper](https://weakdh.org/) describing how the WeakDH attack, which affected 8.4% of the top 1 million domains at the time, could trick servers into using small (insecure) DH parameters, enabling adversaries to decrypt data transmitted between client and server.

TLS 1.3 makes it impossible to use anything but a set of DH parameters that are believed to be secure.

### The TLS 1.3 handshake

Because there are significantly fewer options for the client and server to agree on, the TLS 1.3 handshake is much simpler:

1. **Server listens for new connections on port 443.**
2. **Client connects to port 443 and initiates the handshake process with a ClientHello message to the server.** Since the list of cipher suites was vastly reduced in TLS 1.3 (from 37 to 5), the client assumes the server is going to use one of the five. It proactively calculates a key pair for each of the cipher suites and sends it to the server along with the protocol version.
3. **Server calculates the key session.** With the client’s key share, the server is able to generate the session key.
4. **Server says “hello” back with a ServerHello message.** The server generates its own key share and sends it over to the client, so it also can generate the session key, along with the server’s encrypted SSL certificate (using the session key created on #3).
5. **Client generates master secret and a secure connection is established.** The client receives the server’s key share and calculates the session key. It decrypts and verifies the server’s certificates, and if everything is good, the handshake is complete.

Note that there are two different public-private key pairs on an ephemeral DH exchange: the first is the ephemeral pair, created every time client and server establish a connection, which guarantees forward secrecy. The second pair, embedded on the SSL certificate, is used for authentication and doesn’t change.

Given that a new key is generated for every session, this feature guarantees PFS. If the encryption keys are compromised at a later date, the leaked key will only be able to decrypt the specific session to which it corresponds; all the prior sessions are still safe. As a result, large-scale storage of data transmitted between server and client is rendered worthless.

## How Auth0 Can Help

The temptation to intercept, undermine, and circumvent encryption has never been stronger. Cybercriminals are working to find ways to get around the issues that strong encryption presents due to the volume of valuable information that is sent between computers today.

While this rarely results in direct assaults against cryptographic algorithms or protocols, it frequently prompts attackers to devise novel methods of intercepting or capturing information. With these threats ever present, it is more crucial than ever to focus on maintaining strong and up-to-date implementations of effective encryption protocols.

Some applications are still running TLS versions older than 1.2, and others are still running the original SSL protocol. If yours is one of them, you should consider upgrading it immediately. Auth0 [supports both TLS 1.2 and TLS 1.3](https://auth0.com/docs/customize/custom-domains/self-managed-certificates/tls-ssl) and can help you keep your applications secure.

The TLS Handshake Explained

Learn what is a Yubikey and how you can set one up with your Auth0 account.

If you are reading this blog post, you are interested in security and how to make your accounts more secure. This blog post will teach you about Yubikeys, their benefits, and how to provide two-factor authentication (2FA) in your applications with Auth0.

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

## What is a Yubikey?

**A Yubikey is** a hardware authentication device that makes two-factor authentication easier by plugging it into your laptop and tapping it. Yubikeys are a type of [security key](https://www.okta.com/identity-101/security-token/) manufactured by [Yubico](https://www.yubico.com/).

Usually, when logging in to any service, you must enter **something you know**, such as your login credentials, email, and password. In our case, 2FA adds another layer of security by requiring you to provide **something you have**, for example, a code from an authenticator app or SMS on your phone. Instead of using a code, you can use a device such as your Yubikey. In other words, **2FA is the process requiring a user to verify their identity in _two unique ways_** before they are granted access to a system. [It's a form of Multi-Factor Authentication.](https://www.okta.com/blog/2021/07/what-is-two-factor-authentication-2fa/)

## How Does a Yubikey Work?

Yubikeys use [U2F (Universal 2nd Factor)](https://auth0.com/blog/the-working-principles-of-2fa-2-factor-authentication-hardware/#How-The-U2F-Protocol-Was-Created), an open standard for two-factor authentication based on [public-key cryptography.](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/#The-Keys) 

With your Yubikey, you must first register it into your account to authenticate later. 

### Register your Yubikey

1. First, you must authenticate using another method, like your email and password. 
2. When you plug in your Yubikey and signal that you want to register a security key, the server you want to authenticate with sends a challenge and an AppID to the Yubikey. 
3. When the Yubikey receives this information, you'll be prompted by the browser to tap the Yubikey to confirm the request. 
4. Your Yubikey will generate a [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) and hash it together with the AppID and the secret key to create a private and public key. 
5. The nonce and public key are sent back to the server to be stored so they can be used later when the user wants to authenticate.


### Authenticating with your Yubikey 

1. The server remembers you had registered a Yubikey, so it generates a new challenge to send back along with the AppID and nonce created when you first registered your Yubikey. 
2. The browser prompts you to tap the Yubikey, and the Yubikey will use the information received in step 1 to re-create the same key pair created when you registered your Yubikey. 
3. If everything goes well, your Yubikey encrypts the challenge sent by the server with the private key and sends the challenge back. 
4. The server decrypts the challenge using the public key it already has, and if the challenge matches the one the server sent, it means the user authentication was successful. 

## Benefits of Using a Yubikey 

One of the advantages of using a Yubikey is that they **protect against phishing attacks**. Registering a new key to a server sends an AppID that could be the website URL you're trying to authenticate. Therefore, **the credentials you create in a server are linked directly to a single website**.  

Yubikeys provide **one-touch login** without requiring a mobile phone to complete an authentication challenge.

You can also register as many Yubikeys as you want to minimize the chances of account lockout. You should have more than one key and register them simultaneously; **that way, if you lose any, you'll always have a backup.**

As a developer, using a device like a Yubikey might make your life easier, especially if you use [**WebAuthn**](https://webauthn.me/). It's a specification for an API that enables browsers to **create and use** strong public-key credentials so you can authenticate your users on your web applications. **In the WebAuthn process, the authenticator can be a Yubikey.**


## Set Up Your Yubikey with Auth0

You can set up your Yubikey with most mainstream websites like Google, Facebook, Instagram, etc .[Yubico provides an extensive list](https://www.yubico.com/es/works-with-yubikey/catalog/?sort=popular) of all the  applications that support Yubikeys.

In this case, you will set your Yubikey with your Auth0 application to allow your users to log in with a tap!


### Requirements 
- A [**Yubikey**](https://www.yubico.com/products/)
- **An Auth0 account ** <a href="https://a0.to/blog_signup" 
  data-amp-replace="CLIENT_ID" 
  data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">
  which you can get by signing up here
</a>

### Enable and define an MFA Factor 

First, head up to the [Auth0 Dashboard](https://manage.auth0.com/dashboard). On the left-hand menu, click **Security** and under this section, **Multi-factor Auth**. You will see a list of [Factors](https://auth0.com/docs/secure/multi-factor-authentication/multi-factor-authentication-factors):  

![Auth0 MFA Factors](https://images.ctfassets.net/23aumh6u8s0i/18uOwO0agDCb0gfQc9nmKC/61533e04f9b7bbedf7c67a2232dfef4b/Screenshot_2023-01-05_at_4.30.56_PM.png)

Click the factor called **"WebAuthn with FIDO Security Keys"**. It will navigate to the factor configuration page, where you can enable it by using the toggle button on the top right as follows: 

![MFA Factor WebAuthn with FIDO Security Keys config page](https://images.ctfassets.net/23aumh6u8s0i/6oH5pOPesYN4HC26M4hzui/24974cde91e7d132c09122d83ab731ea/Screenshot_2023-01-09_at_6.17.22_PM.png)

### Define an MFA policy 

Once you have enabled your MFA Factor, click **"Back to Multi-factor Authentication"**, next, scroll down to find the **Define Policies** section. 

A policy determines when to prompt users to complete to prove they own a particular account. For the sake of this tutorial, you can select **"Always"** and click **"Save"**

![MFA Policies](https://images.ctfassets.net/23aumh6u8s0i/1LnK0IMESXmCtY7p7fPFEa/cc38bef3e4d43b4c777d81ecbce59ce2/mfa-policies-always.png)

### Test your MFA strategy with your Yubikey 

First, **plug your Yubikey into your laptop**. Make sure it lights up when you do it to make sure it's plugged in correctly.

Next, head to the [Auth0 Dashboard](https://manage.auth0.com/dashboard) and find the **"Try your Login box"**, then click **"Try it out"**.

![Try your Login Box](https://images.ctfassets.net/23aumh6u8s0i/6x1ti069gOiQQEfKMxJOkA/1a574fcaa21a63c27af49c46f945ac5d/auth0-try-login-box.png)

The Universal Login page should open, so **go ahead and Sign Up** with either an email and password or with Google.

<img src="https://images.ctfassets.net/23aumh6u8s0i/1qNiYSkRJ2LV9ofWcmilUi/67d360f73933aeab8af3b1f6ff665891/universal_login_try_it_out.png" alt="Universal Login Page" width="500"/>

After you Sign Up, **your browser will detect that you have a Yubikey**, and it will take you to the following page so you can register your Yubikey:

<img src="https://images.ctfassets.net/23aumh6u8s0i/1o0j38TBwuyW7NoqQJUk9k/c0600bbf6ad4561c2e5d9fc52a606b95/Screenshot_2023-01-05_at_5.07.06_PM.png" alt="Add your Security Key" width="500"/>

Click "Use security key". A modal will pop up; select "USB Security Key": 

<img src="https://images.ctfassets.net/23aumh6u8s0i/4aGvztvwh1NH15CBhmmWHn/ab1ca9633bcf26c2c3dc6a7bc6626010/Screenshot_2023-01-05_at_5.09.29_PM.png" alt="Select your Security Key" width="500"/>


At this point, you'll be asked to **tap your Yubikey**:

<img src="https://images.ctfassets.net/23aumh6u8s0i/bo8pyABsZITlIghPPmWNV/04af1578bec8ca62d2f2562cb041c4f5/tap_key.png" alt="Tap Yubikey" width="500"/>


Next, you'll need to **add a name for your Yubikey**. Make sure to use a name that will help you identify which Yubikey you need to use.

<img src="https://images.ctfassets.net/23aumh6u8s0i/4sX3zXNfxEGWeb9TyXV6QA/a20804c8bfd843b299b9e32fd3cb69f1/Screenshot_2023-01-05_at_5.16.15_PM.png" alt="Name Yubikey" width="500"/>

And that's it! You have set up your Yubikey with Auth0! 🎉 You'll see a success message like this one:

<img src="https://images.ctfassets.net/23aumh6u8s0i/5MamqbabTSGXTwVkpoqtDb/6889544b4747fd3f2b73d3bab34c375e/yubikey_added.png" alt="Security key success message" width="500"/>

## Summary

In this post, you learned about Yubikeys and how to set them up with Auth0.

Yubikeys are a type of security key made by Yubico that makes two-factor authentication easier. Yubikeys use U2F, which is based on public-key cryptography. 

Using a Yubikey allows you to do a one-touch login and have as many Yubikeys as you want. 

Setting a Yubikey with Auth0 is a relatively straightforward process; all you need is the Yubikey and an Auth0 Account. 

What do you think? Will you be using a Yubikey in the future? Let me know in the comments. 

Thanks for reading!

What is a Yubikey and how to set it up with Auth0?

Learn about the essential features of the Auth0 Flutter SDK and how it helps developers build and secure Flutter iOS and Android applications.

Today we are announcing the release of the [Auth0 Flutter SDK](https://pub.dev/packages/auth0_flutter), a new SDK that makes it easy to secure Flutter applications with Auth0. Whether you need to secure access to an iOS or Android application, the Auth0 Flutter SDK got you covered!

The new Flutter SDK builds on a strong foundation by wrapping our existing and robust [Auth0.Android](https://github.com/auth0/Auth0.Android) and [Auth0.swift](https://github.com/auth0/Auth0.swift) libraries while focusing on the developer experience first.

Our SDK team optimized the Auth0 Flutter SDK for quick integration into your applications and for flexibility to accommodate simple and advanced use cases.

Since the introduction of [Flutter 3](https://medium.com/flutter/introducing-flutter-3-5eb69151622f), the framework allows for building cross-platform applications, extending from mobile applications to desktop applications and platforms. Our SDK allows for extension in such platforms by leveraging federated plugins, which means you can easily add support for other platforms without forking the SDK.

## Auth0 Flutter SDK Features

The new SDK offers features for multiple use-cases and complexity, going from magically getting the job done to providing a rich set of APIs enabling you to build your authentication flow per your specific requirements.

Let's explore the essential features of the Auth0 Flutter SDK that enable developers to do more:

- ⚡️ Quick implementation of login, logout, and automatic storage and renewal of tokens functionality into Flutter apps using WebAuth and the [Auth0 Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) page.
- ⚙️ For more advanced use-cases, developers have access to the [Authentication API](https://pub.dev/documentation/auth0_flutter/latest/auth0_flutter/AuthenticationApi-class.html), which at the time of release supports:
	- Logging in with a username or email and password
	- Signing up new users
	- Getting user information from `/userinfo`
	- Renew tokens
	- Reset passwords
- 🔐 Auth0 provides a default instance of [Credentials Manager](https://pub.dev/documentation/auth0_flutter/latest/auth0_flutter/DefaultCredentialsManager-class.html) that automatically stores the user's credentials. If you need your own solution for handling credentials, you can create your own [custom credentials manager](https://pub.dev/documentation/auth0_flutter/latest/auth0_flutter/CredentialsManager-class.html).
- ➕ And more [advanced features](https://pub.dev/packages/auth0_flutter#advanced-features) like accepting user invites, login into organizations, and bot detection.

## Requirements

The Auth0 Flutter SDK doesn't require any other library to work. However, there are SDK version and platform requirements for your project:

<table style="width:100%" cellspacing="2" cellpadding="5">
    <thead>
        <tr style="border-bottom: solid 1px">
            <td>**Flutter**</td>
            <td>**Android**</td>
            <td>**iOS**</td>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>SDK 3.0+</td>
            <td>Android API 21+</td>
            <td>iOS 12+</td>
        </tr>
        <tr>
            <td>Dart 2.17+</td>
            <td>Java 8+</td>
            <td>Swift 5.3+</td>
        </tr>
        <tr>
            <td></td>
            <td></td>
            <td>Xcode 13.x / 14.x</td>
        </tr>
    </tbody>
</table>

Check the [project on GitHub](https://github.com/auth0/auth0-flutter/tree/main/auth0_flutter#requirements) to for the most up-to-date set of requirements.

## Installing the SDK

The Auth0 Flutter SDK is distributed via [pub.dev](https://pub.dev/packages/auth0_flutter).

To add the SDK, run the following command from the root directory of your project:

```bash
flutter pub get auth0_flutter
```

## Adding Universal Login to Your Flutter Application

Adding the full-featured [Auth0 Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) authentication page to your application is easy with the SDK.

Please explore the [Flutter Quickstart guide](https://auth0.com/docs/quickstart/native/flutter/interactive) to see in detail how to set up your Flutter application to use the Auth0 SDK. For now, let's take a quick peak at how the Flutter SDK integration goes!

### Add login to your app

Integrate Auth0 Universal Login in your Flutter app by using the Auth0 class. Redirect your users to the Auth0 Universal Login page using `webAuthentication().login()`. This is a `Future` and must be awaited for you to retrieve the user's tokens.

```dart
await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').login();
```

### Add logout to your app

Logging out users is as easy as calling the Auth0 Flutter SDK `webAuthentication().logout()` function. The `logout()` function is responsible for calling the `logout` endpoint to clear their login session and to clear the user login state from the device session.

```dart
await auth0.webAuthentication(scheme: 'YOUR CUSTOM SCHEME').logout();
```

## Next Steps

There are a lot of options to work with with the SDK, and in this post, we only barely scratch the surface of it. If you want to learn more about the SDK, please check out the [quick start guide](https://auth0.com/docs/quickstart/native/flutter/interactive) and the [SDK documentation](https://pub.dev/packages/auth0_flutter).

Thanks for reading!

Introducing the Auth0 Flutter SDK

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

"Passkey" is the shorthand for FIDO multi-device credentials, a new technology that makes it convenient to use FIDO's phishing-resistant authentication methods and ceremonies across multiple devices.

Our Take on Passkeys

MatthewHughes

I'm a Liverpool-based technology writer with a passion for usability and security. When I'm not churning out copy, you'll find me walking my two dogs: Luna and Apollo

Business Content Writer

Matthew Hughes

When it comes to SaaS applications, performance matters. Private Cloud SaaS helps you scale the performance of your growing SasS applications.

Performance matters. You know this, of course. Every second of additional latency translates into [lower conversions and tougher customer retention](https://businessmondays.co.uk/tackling-cart-abandonment-with-improved-login-experiences/). It's why you agonize over every individual detail, why your cloud infrastructure vibrates with the well-oiled efficiency of a Formula One engine.

As your business scales, staying fast becomes much harder. Essential SaaS (software-as-a-service) components that worked well when you were a smaller company now struggle to contend with your higher traffic volumes. 

Fortunately, there's an alternative. Private cloud SaaS offers the flexibility of a self-hosted application with none of the downsides. And, for performance-sensitive applications, it offers the boost necessary to deliver an incredible, slick user experience. 


## The Need for Speed 

Virtually every company and public sector organization uses SaaS in some form. Why? It's often the most practical and affordable option. Hiring and training someone to operate and provision a system takes time, money, and resources. With SaaS, the vendor handles long-term maintenance and upgrades. As most use a subscription model, there are no major upfront costs.

Most SaaS applications, by design, are multi-tenant environments. Multiple customers — whether individuals or organizations — share the same computational resources. This model is cheaper but has several trade-offs. Customers have little choice in where the application is deployed. They lose control. They can't make the subtle tweaks that ultimately result in faster, more responsive applications. 

Private cloud SaaS applications are different. They combine the benefits of a SaaS app (low costs, low maintenance, faster time-to-market) with the flexibility and autonomy of a self-hosted application. Customers can choose where, how, and with whom to deploy their application. They are the sole tenants, and they set the rules.

This control helps organizations comply with the ever-increasing number of data residency laws worldwide. But it can also deliver meaningful performance benefits, resulting in more responsive applications and better user experience outcomes.


## Reducing Latency One Millisecond at a Time

Have you ever wondered why Google only shows you ten results for each page? It seems counterintuitive, doesn't it? Google is a search engine. Its job is to show you relevant results for your queries. More is better, surely?

Not necessarily. In 2006, Marissa Mayer, then the company's Vice President of Search, [shared the results of an internal experiment](http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html) at the Web 2.0 Conference. Google asked a select group of users if they wanted to see more results with their queries. Most said yes. 

In response, Google provided random users (not just those in the focus group) with 30 results per page — triple the normal amount. 

What happened next? Frustration. Load times more than doubled for those in the test cohort, soaring from 0.4 seconds to 0.9 seconds. That 0.5-second delay had a measurable effect on user activity and satisfaction. Traffic and revenue from the test group dropped 20%. As Mayer said at the time: "Users really respond to speed." 

How does this relate to private cloud SaaS? Well, there are limits to how far you can optimize an application for speed with efficient coding and generous resourcing alone. 

If your primary application is located in Amsterdam but relies upon a component hosted in Los Angeles, you'll find a measurable delay as packets make their long journey through a network of submarine cables. You add 135ms to your load times – give or take 10ms.

You can't speed this process up. You are constrained by the speed of light. That's fast, but when you are trying to deliver an incredible experience to your customers, it feels like an eternity. 

You have only one solution: bring that component physically closer to your core application. 

The private cloud SaaS model lets you deploy resources in the same continent, country, and even data center. By eliminating performance bottlenecks in your product, your customers will benefit from a faster, more responsive experience. 


## How Private Cloud SaaS Can Help You Scale 

As your business grows, you may feel constrained by the limitations of multi-tenant, public cloud SaaS applications. Many vendors limit the number of requests that can be made per second (RPS) in order to preserve the quality of the service. While most SaaS companies are prepared to oblige larger customers with bespoke plans, this isn't always a given. 

And you cannot always predict when demand will spike. Take lab-testing and diagnostic services provider (and Auth0 customer) [BioReference Labs](https://auth0.com/case-studies/bioreference), for example. BioReference had begun transitioning to a patient-centric model, where customers could access their lab results without going through an intermediary — like their physician. As a result, it invested in Auth0's multi-tenant customer identity and access management (CIAM) platform. 

At the start of the COVID-19 pandemic, demand for its services jumped 25 times. Its monthly active users increased from 8,000 to 148,000. In response, the company migrated its identity infrastructure to a private instance of Auth0's Identity Platform, giving it essential breathing room to meet existing demand and add more customers in the future.

By opting for a private cloud SaaS application, you can provision your environments with the resources necessary to meet existing demand. And you have the flexibility to change your environment as circumstances dictate. 


## Becoming Resilient with Private Cloud SaaS 

Nobody likes downtime. Not your customers, who rely on your product. And certainly not you. 

Performance issues can devastate your bottom line. As load times and instability increase, conversion rates drop. Unfortunately, these problems are often beyond your control. In a multi-tenant SaaS environment, seasonal demand spikes — like those during the holiday shopping season — can result in longer wait times and instability for your customers. 

The private cloud SaaS model can insulate your business from any disruption in the public cloud SaaS application. With control over the environment, you can structure your SaaS infrastructure to be highly resilient, with custom disaster recovery protocols and redundant failover systems. 

You can establish custom backup and restore procedures. Mitigating against data center-level disruption becomes easy. Should the underlying cloud infrastructure fail, you can automatically switch operations to an unaffected environment, keeping downtime to a minimum. And with bespoke update rules, you can deploy patches and new features at a time when your customers are least active. 


## Nimble SaaS, Happy Customers

For most companies, it makes sense to use a multi-tenant public cloud SaaS product. But as your needs increase, you may find it sensible to switch to a dedicated environment. 

Private Cloud SaaS offers the best of both worlds. It requires little maintenance but offers the flexibility of a self-hosted application. You become able to make the choices necessary to deliver a lightning-fast, highly resilient product.

The Auth0 Identity Platform is available in both multi-tenant and private cloud versions. When you opt for a private environment, you get all the benefits of our industry-leading CIAM platform, but with the flexibility to choose how and where it's deployed. To find out how it can benefit your company, reach out to our team.

How Private Cloud SaaS Can Boost Application Performance

500x500

I'm a software engineer, but I prefer to call myself Technology Bishop. Spreading knowledge through writing is my mission.

Antonello Zanini

Learn why you may need custom error responses on 4xx errors, what a good custom format looks like, and how to apply it to your error responses in Express.

How To Implement Custom Error Responses in Express

sambiopic

I'm Director of Developer Relations and a Google Developer Expert for Angular and Web Technologies. I believe anyone who wants to learn to code should be able to learn code and I love teaching. When I'm not coding or writing, you'll find me outside hiking or camping in the beautiful Pacific Northwest.

Director of Developer Relations

Sam Julien

Learn why the login box alone just won't cut it – and how to move beyond it – as life and development continue to evolve.

Join us for Developer Days 2022 and discover life beyond passwords. Registrations are open for our Seattle, Sydney, London, and Berlin. Save your seat today!

<AmpContent>

<b>Seattle</b><br>Wednesday<br>August 24, 2022<br><a href="http://regionalevents.okta.com/DeveloperDaySeattle2022">Check out Seattle</a><br>

<b>Sydney</b><br>Tuesday<br>September 6, 2022<br><a href="http://regionalevents.okta.com/DeveloperDaySydney2022">Check out Sydney</a><br>

<b>London</b><br>Thursday<br>September 29, 2022<br><a href="http://regionalevents.okta.com/DeveloperDayLondon2022">Check out London</a><br>

<b>Berlin</b><br>Wednesday<br>October 5, 2022<br><a href="https://regionalevents.okta.com/DeveloperDayBerlin2022">Check out Berlin</a><br>

</AmpContent>

<NonAmpContent>
<style>
table {
  border-collapse: collapse;
  width: 100%;
  border: 1px solid #ddd;
}

th, td {
  text-align: left;
  padding: 16px;
}
</style>
<table>
  <tr>
   <td><img src="https://images.ctfassets.net/23aumh6u8s0i/1nkZ0XesAUpHE0oIKVIgIB/fc02efba5f1a93f97e33ad24b2ebd91c/01.png" width="" alt="alt_text" title="image_tooltip"></td>
   <td><img src="https://images.ctfassets.net/23aumh6u8s0i/5LivuzVqbtafwH02otDCH3/40282613c247bc618ecf51a6ad5cd971/02.png" width="" alt="alt_text" title="image_tooltip"></td>
   <td><img src="https://images.ctfassets.net/23aumh6u8s0i/3JJNwJHTMr3ls6scSAlZRW/1028eb4a16d72a9bbce6b31bc075e8bb/04.png" width="" alt="alt_text" title="image_tooltip"></td>
   <td><img src="https://images.ctfassets.net/23aumh6u8s0i/3as5x6Y9szXH7RtUlpbwlq/474ef5b1162728a31885314052951cd8/03.png" width="" alt="alt_text" title="image_tooltip"></td> 
  </tr>
  <tr>
   <td><b>Seattle</b><br>Wednesday<br>August 24, 2022<br><a href="http://regionalevents.okta.com/DeveloperDaySeattle2022">Register now for Seattle</a></td>
   <td><b>Sydney</b><br>Tuesday<br>September 6, 2022<br><a href="http://regionalevents.okta.com/DeveloperDaySydney2022">Register now for Sydney</a></td>
   <td><b>London</b><br>Thursday<br>September 29, 2022<br><a href="http://regionalevents.okta.com/DeveloperDayLondon2022">Register now for London</a></td>
   <td><b>Berlin</b><br>Wednesday<br>October 5, 2022<br><a href="https://regionalevents.okta.com/DeveloperDayBerlin2022">Register now for Berlin </a></td>
  </tr>
</table>
</NonAmpContent>

<br>

As technology evolves, life and development have more complex demands than a simple login box can meet. Learn modern techniques for building more secure apps from industry and community leaders, and try them out in our hands-on interactive labs. Auth0 technical experts will be on-site to support one-on-one architecture reviews and offer opportunities to make new connections between sessions.


![Developer Day 2022](https://images.ctfassets.net/23aumh6u8s0i/tJ507YxFgmC38a6GBVtsI/875f64920ba57e637afc6ee9a966ea48/dd2022.jpg)

For further information, visit our [Developer Day site](https://regionalevents.okta.com/DeveloperDays2022).

Developer Day 2022: Registrations Open!

William Juan

I am a Frontend Developer working primarily in the web and hybrid mobile spaces. The majority of my work has revolved around the Angular ecosystem, including working with other Angular-related frameworks such as NativeScript and Ionic. My passion lies in converting a design into code and achieving a close to pixel-perfect end-product.

Frontend Developer

See how it's easy to manage your Angular application's state using NGXS and learn how you can use NGXS with Auth0's SDK to handle user-related functionalities.

"IT"