Jeremie Berthiaume jpg

Group Product Marketing Manager

Jeremie Berthiaume

Learn how Auth0 and Amazon Web Services can enhance fan engagement for sports organizations.



> The one aspect of your tech stack that can transform your fan experiences for the better.

Fans are the heart and soul of every sporting occasion. They make sport possible. Their loyalty goes far beyond attending matches. Fans expect a seamless experience, whether they’re trying to buy tickets or engaging with online content.


To make that happen, sporting organizations must integrate their platforms, apps, and websites to provide secure access and personalized experiences to their fans. Achieving this level of personalization and convenience might seem difficult, but managing your digital identity doesn't have to be.

## Why Is Identity so Important for Sports Organizations?

Simply put, digital identity is the foundation of fan engagement in today’s connected world. It defines how easily — or not — fans can interact with your organization and influences their overall experience. 

Fans will go to great lengths to follow their favorite teams and clubs. It’s our job to make it easy for them to support and engage. Your fans don’t want to juggle multiple passwords or log in repeatedly just to buy tickets or stream matches. 

They also expect personalized experiences that reflect their interests and past interactions. This is where a unified digital identity becomes crucial.

### Building better experiences

A unified identity platform brings together data from multiple touchpoints, creating a single, clear picture of each fan. 

Armed with these insights, sports clubs can offer tailored promotions, targeted content, and personalized offers. The net result is enhanced fan experiences and increased loyalty.

### Scalability is another major advantage

Sports events can cause significant spikes in digital traffic — think of ticket sales for a major game or demand for merchandise after a championship win. A robust digital identity system effortlessly scales, ensuring platforms remain reliable and responsive even under heavy traffic conditions. This prevents frustrating downtime or slow-loading systems.

## A Team of Two: Auth0 and Amazon Web Services

Auth0, the customer Identity platform, and Amazon Web Services (AWS) offer sports organizations a powerful, scalable solution.Auth0 brings the identity building blocks: secure, seamless identity management that’s ideal for handling millions of fans, members, and partners. AWS hits big with unmatched cloud infrastructure for performance, reliability, and global reach. 

Together, they enable clubs to personalize fan experiences, protect sensitive data, and rapidly scale during peak events like match days or ticket launches. With built-in compliance and flexible integrations, Auth0 and AWS make it easier for clubs to innovate faster, stay secure, and deliver world-class digital experiences.

### What Auth0 and AWS bring to the sports sector — and your organization

#### Develop seamless digital experiences

Auth0 provides an identity management solution perfectly tailored to the sports industry. Its key strengths include seamless fan login through single sign-on (SSO), integrated social logins, and even passwordless authentication methods, making access swift and simple. AWS brings global capacity, offering a scalable architecture that lets you deal with sudden and unexpected spikes in demand.

Downtime means lost business. Uptime is all part of the seamless experience for fans.

- One login for all fan services (e.g., apps, ticketing, merchandise, streaming).
- Simplified access reduces frustration and increases engagement.

#### Increased personalization at scale

- Tailor content, offers, and recommendations based on fan data.
- Unified Identity enables consistent, engaging experiences across channels.

Teams running on our platform can send fans offers for merchandise featuring the customer’s favorite players, personalized discounts on match tickets based on their past attendance, or early access to exclusive content. With an embedded authentication token, fans don’t have to sign in again to reduce friction. 

For example, the food delivery company Hello Fresh has increased its re-subscription rate by embedding a short-lived access token into email links. These meaningful interactions make fans feel valued, driving stronger connections and increased engagement. 

Auth0 helps you achieve it by using a single, secure login credential for each fan. This helps you analyze behaviors and personalize content. AWS helps increase personalization opportunities by providing advanced machine learning and analytics services like Amazon Personalize, which processes customer data in real time to generate hyper-targeted recommendations and predictive insights across multiple engagement channels.

Tap into new revenue streams with Auth0 by leveraging data to boost ticket and merchandise sales, drive more effective advertising and sponsorships, enhance digital and in-app purchases, and launch high-value subscription models with exclusive content and memberships. 

#### New revenue streams include

- Drive ticket and merch sales with personalized promotions.
- Enable subscription models and exclusive content access.

AWS provides access to Amazon Bedrock to help analyze customer behavior, from data collection and preparation to sentiment analysis, behavior pattern recognition, and advanced customer insights. Amazon Bedrock's powerful AI capabilities help you transform raw customer data into actionable, intelligent insights that drive strategic decision-making.

#### Stronger security and compliance

* Protects fans and your organization before, during, and after login.
* Supports GDPR and other compliance needs with centralized identity control.

Over 80% of data breaches involve compromised identity. Auth0 protects fan information with strong encryption and advanced security features like multi-factor authentication with Passkeys and bot protection. These features are essential during high-demand moments like major match days or merchandise launches. 

By consolidating identities and simplifying login processes, organizations reduce the risk associated with multiple passwords, enhancing security and streamlining the user experience. Auth0 and AWS work together to provide a multi-layered approach to threat detection and response, including AWS Web Application Firewall and GuardDuty for wider threat intelligence and faster response. Amazon API Gateway and Auth0 protect your applications from distributed denial of service attacks by enabling rate-limited authentication and authorization enforcement.

#### Proven results

- The Royal Belgian Football Association migrated 700,000 fan identities in four months.
- AWS technologies underpin projects for F1, The PGA Tour, and more.

Sports organizations that have adopted Auth0 and AWS see tangible results. For example, AWS works with major sports organizations around the world, including [F1](https://www.aboutamazon.co.uk/aws-f1-british-grand-prix-silverstone), [the PGA Tour](https://aws.amazon.com/solutions/case-studies/pga-tour-ecs-case-study/), and [the NFL](https://aws.amazon.com/blogs/media/inside-the-nfls-innovative-fan-data-platform-powered-by-aws/), helping deliver standout digital experiences to millions of fans. Auth0 has recently helped the Royal Belgian Football Association migrate 700,000 fan identities onto a unified platform, simplifying user management and bringing personalized experiences to fans.

### A home run for sports teams

Thankfully, integrating Auth0 and AWS is easy. Auth0’s cloud-based model and easy integration capabilities with existing platforms like CRMs, marketing tools, and fan engagement software. This integration allows clubs to focus on delivering great experiences rather than managing complicated systems.

Ultimately, providing a superior fan experience goes beyond match day. It’s about maintaining continuous engagement, delivering meaningful interactions, and securing fan loyalty through personalized, secure digital journeys. 

By leveraging Auth0 and AWS, sports organizations can achieve:

- Personalized fan experiences
- Increased revenue streams 
- Better security and compliance

In the fast-paced digital landscape of sports, fan identity management is the cornerstone of an exceptional fan experience. You know better than anyone that it’s about connecting with supporters in ways that matter, turning fans into lifelong advocates, and driving real, sustainable business growth.

Auth0 and Amazon Web Services: The Secret Ingredients That Drive Fan Engagement

Michelle Agroskin

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

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

Product Marketing Manager, Customer Identity Cloud

Nelson Matias

As a Group Product Manager at Auth0, I focus on delivering innovative solutions that enhance security and user experience for both businesses and developers. With hands-on experience as a Developer, Consultant, and Solution Architect, along with years of working in Technical Account Management, I’m passionate about solving complex problems and shaping the future of identity management.
Outside of work, I often watch football, listen to music, or spend quality time with my kids.

Group Product Manager

Learn how identity solutions like Auth0 N2W SSO help adapt to new App Store rules and unlock revenue with secure web payments.

> You've likely caught the news about the recent court ruling affecting Apple's App Store policies. 

**TL;DR**: Apple can no longer stop you from directing users to your own web-based payment systems, nor can they take commissions from sales that occur there. 

While this may seem like a simple policy adjustment, it could fundamentally change the customer journey and the monetization strategy for thousands of apps. 

For years, dealing with Apple's in-app purchase system often meant giving up a large slice of your revenue and losing control over the customer journey. Even when alternative payment links were permitted under specific API terms after earlier rulings, they came with a steep 27% fee and forced users through annoying re-logins. This kind of experience rarely did much for user trust or conversion rates. Some companies chose to opt out altogether, pointing customers to their browsers to complete subscription purchases.

But things are changing. You now have a clearer path to guide users from your app to your chosen payment pages on the web. This allows you to design a checkout experience you control, one that's optimized for your users, all while cutting out commission fees by using your own payment processors.

## The Web's Growing Role in Your iOS Strategy

This ruling makes the web a more attractive partner for your mobile business. Using web views or embedded browsers inside your native iOS app is looking much smarter – not just for payments but for managing complex account settings, delivering features, or any area where the web offers faster development and easier maintenance.

However, there's a common hurdle when you start blending web content into a native app: the user experience suffers. Imagine your user logged in and moving smoothly through your native app. They tap to buy something or update their subscription, and suddenly, they're on a web page (even an embedded one) asking them to log in all over again. It adds friction and can lead to users giving up.

We've seen many development teams try to patch this problem by building custom solutions to carry session information from the native app to the web view. While the intent is good, these DIY methods are often created without fully addressing the security risks. Passing authentication details in URLs can happen, unintentionally putting your users and your business at risk from attacks like session hijacking. Beyond the security concerns, building and maintaining these custom fixes takes up developer time that could be better spent on your core product.

## Introducing Auth0® [Native to Web SSO](https://auth0.com/docs/authenticate/single-sign-on/native-to-web)

This is where a strong identity strategy becomes essential. If you want to effectively use the web within your iOS app – for payments, extra features, or anything else – you need a reliable and more secure way to connect your native app's login state with your embedded web content.

The Auth0 Native to Web Single Sign-On is designed for this specific challenge. N2W SSO helps you embed web applications within your native apps with less hassle, making sure your users log in once in the native app and stay authenticated when they move to an embedded web view. No more disruptive login prompts, just a consistent user experience.

Here’s the basic idea of how Auth0 N2W SSO works:

Your native application authenticates users using standard [Auth0 authentication flows](https://auth0.com/docs/authenticate). As part of the process, it requests a [refresh token](https://auth0.com/docs/secure/tokens/refresh-tokens) — a common best practice for mobile apps that need long-lived sessions. Most modern apps already use refresh tokens and store them in a more secure manner using tools like `CredentialsManager` or platform-specific keychains. (Learn how in our [native quickstarts](https://auth0.com/docs/quickstart/native))

**Auth0 Native to Web SSO** builds on this foundation by enabling a more secure way to transfer the user's authenticated state from your native app into a web experience — such as a `WKWebView`, `Chrome Custom Tab`, or `SFSafariViewController`.

Here’s how it works:

* The native app starts with a valid `refresh_token`.
* When it needs to display a web page (e.g., for payments or account settings), it exchanges the refresh token for a short-lived, single-use `session_transfer_token`.
* That token is securely passed to the web app — either as a cookie or as a query parameter.
* The web app uses the token to seamlessly authenticate the user via Auth0 without prompting for credentials again.

This token is short-lived (60 seconds by default), for one-time use, and can be bound to the device or IP address to prevent misuse. App Attestation and **DPoP support for refresh tokens** are on the way to provide even finer control over token usage.

<include src="TweetQuote" quoteText="Security doesn't have to mean complexity. Auth0 Native to Web SSO provides out-of-the-box security, saving developer time while keeping user data safe." />


## Why This Matters 

Transferring authentication between platforms is traditionally hard and risky — especially in mobile apps, where teams often try to build fragile workarounds. Auth0 Native to Web SSO removes the need for custom session-handling logic while offering:

* **Out-of-the-box security**, including device binding, token rotation, and attestation.
* **Minimal developer effort** — your team just integrates the SDK and makes a call to Auth0.
* **Improved user experience** with no login prompts when jumping between native and web.
* **Flexible support for real-world mobile use cases**, like payments, subscription management, user profiles, and account settings.

If you're planning to embed web content in your app — whether it's for a Stripe checkout, account center, or upsell page — Auth0 Native to Web SSO provides an identity layer with security features that keeps things seamless for your users and safe for your business.

> Wanna try to use Native to Web SSO in your Android or iOS application, [check our Use Case Implementation](https://sus.auth0.com/docs/contentful/X8OYSJiJQWlBGymP3fcdb).

### Drive consistent user experiences and leave consumers happy

Apple's recent ruling is an opportunity to rethink how your native apps and web experiences can work together, particularly for payments and embedded content. If you're planning to use web views more extensively, a seamless and secure user experience is critical.

**Auth0 Native to Web SSO is currently in Limited Early Access and progressing toward General Availability.** It already supports integration with our Android and iOS native SDKs, as well as infrastructure tooling like the Auth0 Deploy CLI and Terraform provider. While dashboard configuration is still in development, the feature is stable and ready for use in production environments.

This feature offers the identity foundation you need to take advantage of the new flexibility from Apple's policy changes. It helps you provide a modern, uninterrupted user journey while maintaining strong security, letting your teams focus on building products.

*This blog post does not necessarily represent Okta's position, strategies, or opinions.*

Navigating New App Store Rules: Identity Solutions for Revenue Growth

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

AAA (Authentication, Authorization, Accounting) helps developers secure web apps by verifying users, controlling access, and tracking actions.

Historically, the AAA framework (Authentication, authorization, and accounting) has been deeply tied to network security, particularly in the context of remote access, VPNs, and network devices. However, AAA is a conceptual framework and not a protocol itself, allowing us to apply it anywhere identity and access matter. Instead of a VPN gateway, you’re securing a web application. Instead of a network admin, it’s a customer buying shoes online. The scale gets bigger, the users are external, and the focus shifts toward balancing security and usability, but the AAA principles still fit to help us build robust, secure, and maintainable user-facing applications.

For developers, considering AAA in your design decisions means not only verifying who your users are (Authentication) but also controlling what they can do (Authorization) and tracking their actions for auditing and analytics (Accounting). This holistic approach minimizes security risks, enhances user experience, and simplifies compliance.

## A Framework to Measure Identity Platforms

A good identity platform gives you features out of the box that tackle each component of the AAA triad, transforming a simple login system into a comprehensive identity management system that meets your security and compliance requirements. User data is one of the most precious and valuable assets we handle as developers. As such, when we make the decision to delegate creating and handling the identity of our users to a third-party vendor, we need to ensure that we are getting better security, scalability, and user-centric experience than what we could build ourselves. The AAA framework is a helpful tool to assess whether an Identity-as-a-Service (IDaaS) vendor can help you build application systems that are resilient against threats, aligned with business requirements, and equipped for future growth.

In today’s competitive digital landscape, including identity and security as part of your MVP or existing product is a competitive advantage. A holistic approach to security is not just an option—it’s a necessity. However, not every player in the field can deliver the security the current security and threat landscape requires. Let’s dive into why Auth0 is a robust identity platform that meets the requirements of the AAA framework and why you should consider it as your identity solution of choice.

## Authentication

Authentication is the process of verifying a user's identity before granting access to your application. It answers the question: **"Who are you?"**

* [Seamless User Sign-Up and Login](https://auth0.com/docs/authenticate/login)
    * Auth0 offers multiple authentication methods, such as social logins, passwordless options, and multi-factor authentication (MFA). These features enable quick and secure identity verification.
* [Personable User Experience](https://auth0.com/docs/customize)
    * With customizable interfaces, Auth0 reduces barriers during sign-up and login, ensuring that the verification process is both secure and user-friendly.
* [Relevant User Journeys](https://auth0.com/docs/customize/forms)
    * Auth0 offers customization of the metadata you collect from users or creates a unique authentication journey that serves your business needs while still being secure.
* [Uncompromised Internationalization and Localization](https://auth0.com/docs/customize/internationalization-and-localization)
    * Auth0 can handle different languages across the authentication experience, allowing you to connect authentically and accurately with millions of potential customers across the globe. Auth0 adapts to your users instead of forcing users to adapt to inflexible platforms.

## Authorization

Authorization defines what actions or resources a user is allowed to access once they are authenticated. It answers the question: **"What can you do?"**

Auth0 allows developers to implement flexible yet comprehensive authorization models that fit different threat models.

* [Role-Based Access Control (RBAC)](https://auth0.com/blog/an-overview-of-commonly-used-access-control-paradigms/#Role-Based-Access-Control--RBAC-):
    * Auth0 allows you to set granular permissions by assigning roles to users. This ensures that users only access the features and data relevant to their privileges.
* [Auth0 Actions](https://auth0.com/docs/manage-users/access-control/sample-use-cases-actions-with-authorization)
    * Actions are secure  Node.js functions that allow you to modify or complement the outcome of the decision made by pre-configured authorization policies. Developers can use Auth0 Actions to[ handle more complicated cases](https://auth0.com/docs/manage-users/access-control/sample-use-cases-actions-with-authorization) than is possible with role-based access control (RBAC).
* [Fine Grained Authorization](https://auth0.com/fine-grained-authorization)
    * Auth0 FGA delivers relationship-based access control ([ReBAC](https://auth0.com/blog/an-overview-of-commonly-used-access-control-paradigms/#Relationship-Based-Access-Control--ReBAC-)) designed for complex authorization needs, such as restricting resource edits to team leads. As a managed service, it scales to handle millions of permission checks per second with minimal latency, eliminating the need to build and maintain custom solutions.

## Accounting

Accounting, also known as auditing, involves tracking and logging user activities within your application. It answers the question: **"What did you do?"**

* [Detailed Logging](https://auth0.com/docs/deploy-monitor/logs)
    * Auth0 maintains a comprehensive audit trail of authentication and authorization events. This detailed logging is essential for monitoring user behavior and identifying potential security incidents.
* [Usage Analytics](https://auth0.com/docs/get-started/auth0-overview/dashboard/activity)
    * The collected data helps analyze user interactions, optimize authentication flows, and ensure compliance with industry regulations. Accounting provides valuable insights into how your application is used.
* [Log Streaming](https://auth0.com/docs/customize/log-streams)
    * Auth0's log streaming service allows you to export tenant log events to a log event analysis service URL, leveraging robust data services, such as DataDog, Splunk, and Amazon EventBridge, and allowing you to react to events like password changes or new registrations with your own business logic.

## Bringing It All Together

Overlaying the AAA framework on your Auth0-powered B2C or B2B solutions ensures:

* **Enhanced Security:**
    * A multi-layered approach that not only verifies identities (Authentication) but also enforces precise access controls (Authorization) and continuously monitors user activities (Accounting).
* **Improved User Experience:**
    * While users benefit from a smooth and secure sign-up process, the detailed authorization rules and accounting measures ensure that they access the right features with confidence.
* **Operational Excellence:**
    * With robust logging and analytics, you can swiftly detect anomalies, refine your application, and maintain compliance with regulatory standards.

If you haven’t tried it already, [get started with Auth0 today](https://a0.to/get-started)!


Authentication, Authorization, and Accounting For Developers

Enable multitenancy in your Blazor Web App with Auth0 Organizations and get ready for B2B.

Add Auth0 Organizations to Your B2B Blazor Web App

joey devilla headshot 900px

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

Senior Developer Advocate

Joey deVilla

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

Add personalization to your iOS/SwiftUI app with user info from the ID token, a JWT (JSON Web Token) that you’ll read with the Swift JWTDecode library.

In Part 1 of this tutorial, you created a SwiftUI-based iOS app that uses Auth0 for basic login and logout functionality. In this part, you’ll enhance your app by giving it the ability to read the user’s profile to display their photo, name, and email address when they’re logged in.

<include 
    src="LinkCard" 
    title="Calling a Protected API from an iOS Swift App" 
    link="https://auth0.com/blog/calling-protected-apis-from-ios-swift/" 
    description="Looking for a step-by-step guide to leveraging OAuth 2.0 when accessing protected APIs via an iOS app built with Swift? If you're integrating with Auth0, then this is everything you need to know!"     img="https://images.ctfassets.net/23aumh6u8s0i/5PC3nu1F68m8S3BmJFv9SN/e83487c6d89d72fb6a49155722959b1d/ios_hero_2021_2.jpeg"
/>

Once again, you can follow the text in this article, or if you prefer learning by video, you can follow the steps in this article’s companion video:

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

> Look for the 🛠 emoji if you’d like to skim through the content while focusing on the build and execution steps.
> 
> The 📺 emoji highlights links to specific points in the video.


## Examine the ID Token

📺 [The _Examine the ID Token_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2008s)
 
If you look at the `.success` case of the `switch` statement in `ContentView`’s `login()` method, you’ll see these `print()` functions:

```swift
print("Credentials: \(credentials)")
print("ID token: \(credentials.idToken)")
```

These functions’ output will appear in Xcode’s Debug area:

![Xcode screenshot highlighting the Debug area.](https://images.ctfassets.net/23aumh6u8s0i/2Odv2P2CeeMGBoKSHNl3ly/2ba5ae37dbc5afafb94e82f95f41a722/debug_area.png)

> If the Debug area isn’t visible, open the _View_ menu and select _Debug Area_ → _Show Debug Area_ or use the keyboard shortcut _command-Shift-Y_.

You’ll see the contents of the `credentials` object and its `idToken` property, which should look similar to this:

```
Credentials: Credentials(accessToken: "<REDACTED>", tokenType: "Bearer", idToken: "<REDACTED>", refreshToken: nil, expiresIn: 2022-03-20 04:38:25 +0000, scope: Optional("openid profile email"), recoveryCode: nil)
ID token: eyJhbGciOiJSUzI1NiIsInR5cC...
```

The `credentials` object is a package of information that Auth0 sends to your app after authenticating a user. This information includes:

- **ID token:** Data that proves that the user has been authenticated.
- **Access token:** Data that gives a client application permission to access a specific resource to perform specific actions on the user’s behalf.
- **Refresh token:** Applications use this to get additional access tokens when the original access token expires without requiring the user to re-authenticate.
- **Scopes:** A set of [OpenID Connect (OIDC) scopes](https://auth0.com/docs/get-started/apis/scopes/openid-connect-scopes) — authorizations for access to details about the user — that Auth0 has granted to the app. Unless you specify otherwise, *Auth0.swift* defaults to requesting the following scopes when logging in a user:
	- `openid`: Authorization to use OIDC to verify the user's identity
	- `profile`: Authorization to access the user’s name information
	- `email`:  Authorization to access the user’s email address

> Want to know more about ID tokens and access tokens? We explain all in our article, [_ID Token and Access Token: What's the Difference?_](https://auth0.com/blog/id-token-access-token-what-is-the-difference/)
> 
> Want to know more about refresh tokens? See our article, [_What Are Refresh Tokens and How to Use Them Securely_](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/).

The piece of information that we’re most interested in (for this exercise) is the ID token.

When the `print()` function is used to output the contents of `credentials`, the values of the `idToken` and `accessToken` properties are replaced with the string `<REDACTED>` as a security measure. Malicious parties can use tools to capture the output of `print()` functions from production apps; this is why `Credentials` instances redact the values of their `idToken` and `accessToken` properties when printed.

Note that when we use the `print()` function to output `credentials.idToken` — the ID token itself — the value is _not_ redacted. That’s because this value is useful for debugging, which we’ll do in the next step.

> It’s fine to print the value of the ID token to the debug console while you’re learning about the authentication process or building the app. Make sure you remove `print()` statements — especially those that print sensitive information, such as the ID token — before putting them into production!


### What’s in the ID token?

📺 [The _What’s in the ID token?_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2118s)

To see what’s in the ID token, copy its value from the Debug area, go to Auth0’s [JWT.io site](https://jwt.io/) and paste that value into the _Encoded_ text area on the left side of the page. JWT.io will decode the ID token from its JWT form and display its decoded contents in the _Decoded_ area on the page’s right side:

![JWT.io and the decoded ID token.](https://images.ctfassets.net/23aumh6u8s0i/4sg6VirydfCzVVenH6LWil/174552abed55b4fe3d8100493c1510db/jwt.io_screenshot.png)

In the _Decoded_ area’s _Payload_ section, you’ll see the decoded user information from the ID token, including the data that we want the app to display: the user’s name, email address, and picture.

In the next step, we’ll give the app the same ID token-decoding capability as JWT.io’s.

> Auth0 has plenty of information about JWTs. In addition to the main [JWT.io page](https://jwt.io/), you should visit JWT.io’s [_Introduction to JSON Web Tokens_](https://jwt.io/introduction) and download our [free JWT Handbook](https://auth0.com/resources/ebooks/jwt-handbook).


## Get the User’s Information

📺 [The _Get the User’s Information_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2223s)

The app only “knows” whether the user is logged in or logged out in its current state. It also has information about the user’s identity encoded in the ID token. Let’s extract this user information — the *user profile* — and use it to display the user’s name, email address, and picture when the user is logged in. 

🛠 In `Profile`, add the following `import` statement before the `struct Profile` line:

```Swift
// [ 📄 Profile.swift ]

import JWTDecode

// [ More code here ]
```

🛠 In the `Profile` extension, replace the `// TODO: Implement the 'from()' method.` comment with this `from()` method. It uses a couple of methods from the newly-imported `JWTDecode` library:

```swift
// [ 📄 Profile.swift ]

// [ More code here ]

  static func from(_ idToken: String) -> Self {
    guard
      let jwt = try? decode(jwt: idToken),
      let id = jwt.subject,
      let name = jwt.claim(name: "name").string,
      let email = jwt.claim(name: "email").string,
      let emailVerified = jwt.claim(name: "email_verified").boolean,
      let picture = jwt.claim(name: "picture").string,
      let updatedAt = jwt.claim(name: "updated_at").string
    else {
      return .empty
    }

    return Profile(
      id: id,
      name: name,
      email: email,
      emailVerified: String(describing: emailVerified),
      picture: picture,
      updatedAt: updatedAt
    )
  }
  
// [ More code here ]
```

Given an ID token string, the `from()` function creates a `Profile` instance. If `from()` can extract claims — values about the user’s identity, which include their name, email address, and the URL for their picture — from the ID token, it returns a `Profile` instance with that information in its properties. Otherwise, it returns a `Profile` instance with empty properties.


## Display the User’s Information

📺 [The _Display the User’s Information_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2424s)

Now that there’s a way to extract information from an ID token, let’s put it to use. 

Since `userProfile` is marked with the `@State` attribute, it defines the user interface’s state. Whenever `userProfile` or one of its properties changes, the app redraws the user interface to reflect the change.

We want to display the user’s information when they log in, so we’ll use `Profile`’s newly-created `from()` method in the `login()` method.

🛠 Open `ContentView` and update `login()` as shown below:

```swift
// [ 📄 ContentView.swift ]

// [ More code here ]

  func login() {
    Auth0 // 1
      .webAuth() // 2
      .start { result in // 3
        switch result {
          // 4
          case .failure(let error):
            print("Failed with: \(error)")
          // 5
          case .success(let credentials):
            self.isAuthenticated = true
            // 👇🏽👇🏽👇🏽 New line of code here!
            self.userProfile = Profile.from(credentials.idToken)
            // 👆🏽👆🏽👆🏽
            print("Credentials: \(credentials)")
            print("ID token: \(credentials.idToken)")
        }
      }
  }

// [ More code here ]
```

The newly-added line of code runs after the user logs in, and the app receives the ID token. It creates a new `Profile` instance from the data in the ID token and sets `ContentView`’s `userProfile` property to that instance.

When the user logs out, we should clean up the user profile just to be safe.

🛠 Update `logout()` as shown below:

```swift
// [ 📄 ContentView.swift ]

// [ More code here ]

  func logout() {
    Auth0
      .webAuth()
      .clearSession { result in
        switch result {
          case .success:
            self.isAuthenticated = false
            // 👇🏽👇🏽👇🏽 New line of code here!
            self.userProfile = Profile.empty
            // 👆🏽👆🏽👆🏽

          case .failure(let error):
            print("Failed with: \(error)")
        }
      }
  }

// [ More code here ]
```


## Run the App Again

📺 [The _Run the App Again_ section of the video](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2566s)

Run the app and confirm that the changes work. When you log in, you should see the user’s name, email address, and picture:

![The app’s “logged in” screen, featuring the text “Logged in” and displaying the user’s picture, name, and email address.](https://images.ctfassets.net/23aumh6u8s0i/1zYLUYAU3fdbLLde9PmhCN/90854331950e7557fbcc52db5bcb7379/logged_in_screen.png)

Congratulations, and high-fives and handshakes all around! You’ve taken a SwiftUI app and given it the ability to authenticate users with Auth0.


## Next Steps

SwiftUI is an expansive topic; we only scratched its surface in this tutorial. For your next steps in exploring it, you might want to look at these valuable resources:

- [SwiftUI by Example](https://www.hackingwithswift.com/quick-start/swiftui)
- [Your First SwiftUI App](https://www.youtube.com/watch?v=VlhcNR7Qrno)
- [Stanford University’s “Developing Applications for iOS” course for Spring 2021](https://www.youtube.com/playlist?list=PLpGHT1n4-mAsxuRxVPv7kj4-dQYoC3VVu)

📺 Last but not least, the video ends with [closing remarks and a quick accordion number](https://www.youtube.com/watch?v=xOBoLegDmTw&t=2645s)!

Get Started with iOS Authentication using SwiftUI, Part 2: User Info, ID Tokens, and JWTs

Sam4-square

I'm an Identity nerd with many years of experience as a developer and advocate. I love explaining complex topics clearly and understandably. You can find me on stage at developer events worldwide or simply having great conversations in the hallway. Google has recognized me as a Google Developer Expert (GDE) in the domains of Web Technologies, Security, Privacy, Payments, and Identity.

Sam Bellen

When you are working on a complex web application, at some point, you’ll want to restrict or grant access. In this post we'll explore some of the most commonly used access control paradigms.

Whether you are working on a complex web application, managing a hosting infrastructure, or configuring your company's applications, at some point, you’ll want to restrict or grant access to specific people, groups, or applications, depending on some properties. These can be a role or permission, the time of day or location, or the relationship between two entities. Based on your scenario and the level of complexity, one or more access control approaches might work for you.

## Coarse-Grained (CGA) Versus Fine-Grained Access Control (FGA)

We can distinguish two general strategies based on how granular you want to be when making access control decisions. You either choose a coarse or fine-grained approach.
A coarse-grained approach assigns permissions to a large group of users and resources.
A fine-grained approach looks at the bigger picture, taking into account a lot of different data points and scenarios or assigning permissions to a more limited group of users and resources, or even unique permission per user and resource.

Both strategies have their place, and choosing the level of detail you want to include in your access control decisions might influence the paradigms you can use. For example, a role-based access control usually implements coarse-grained access control, while the relationship-based access control approach is ready to make very fine-grained decisions.

## Role-Based Access Control (RBAC)

The first access control paradigm we’ll discuss in this article is **role-based access control**. It is the most commonly used approach and the simplest to start with. Role-based access control, as the name implies, uses a system of roles and permissions to make a decision.

A role is a collection of permissions that can be assigned to a user, and a permission indicates a certain allowed action that can be performed by any user assigned a role containing this permission. For example, a `guest` role might have permission to view all posts on a website, while an `admin` role could have both a view and delete permission attached to it.

```
guest: [
  view:post
]

admin: [
  view:post,
  delete:post
]
```

Your application can either check if the current user has `delete` permissions or has been assigned the admin role. Either scenario will let your app know the user should be able to delete posts. Checking for permissions over roles offers the benefit that your application doesn’t need changes when roles and their permissions change over time.

To get the roles or permissions, your application typically requests them from a user-info endpoint, or your authorization server adds them to the access and/or ID tokens issued when the user is authenticated.

Because we check for permission based on a resource type rather than a specific resource like `post x` or `post y`, RBAC is an example of a coarse-grained access control approach.

## Attribute-Based Access Control (ABAC) or Policy-Based Access Control (PBAC)

**ABAC** or **PBAC** is an access control strategy in which a decision is made based on assessing attributes related to a request or situation. Policies define how these attributes are evaluated. The most common types of attributes are **user** (role, job title, security level), **environment** (time of day, location), **resource** (resource type, data sensitivity), and **action** (read, write, delete). Combining multiple attributes into one or more policies offers a highly customizable and fine-grained solution to grant or limit actions within your applications or systems. The more policies you create, the more control you have over your access decisions, but the harder it becomes to maintain these policies.

An attribute-based access control system often consists of at least a decision engine and a policy language you can use to describe scenarios and their outcome. The same is true for ReBAC, but more on that later.

The decision or policy engine will evaluate data presented in a request against one or more policies written in the policy language. The downside is that you first need to gather the relevant data before passing it to the decision engine for evaluation. This often requires some extra database lookups.

If, for example, you’d like to check if a user can view a document in a parent folder owned by the same user, you’d first need to read the document database table. You'd then search the parent folder for that document and check if a user has access to that folder. Once you’ve done the lookup, you can pass this information to the policy engine to make an informed decision. 

### Open Policy Agent (OPA)

[Open Policy Agent (OPA)](https://www.openpolicyagent.org) is a declarative policy engine that strongly focuses on access control for infrastructure like Docker or Kubernetes containers. Their homepage describes OPA as “Policy-based control for cloud-native environments, flexible, fine-grained control for administrators across the stack.”. This doesn’t mean you can’t use it for other use cases, but it is best suited for managing infrastructure access.

Open policy agents are usually deployed as a “sidecar” beside your applications or infrastructure. This sidecar contains all policies and some relevant data in JSON files. If you run multiple applications, containers, or clusters, it can become a difficult chore to keep all policies and data up-to-date across all OPA sidecars.

Let’s look at an example. If a request comes from an origin we have on a disallow list, the policy engine will return a negative decision. For this to work, we would have written a policy that specifies that the engine looks through a list of blocked origins and checks if the origin, which is part of the request to the decision engine, is part of that list.

OPA policies are written in REGO, a generic programming language that allows you to write detailed policies. Because it is a generic language, it has a steep learning curve and usually takes some time to get used to.

Some [pseudocode](https://play.openpolicyagent.org/p/THKqtQ3QME) for the example above written in [the REGO language](https://www.openpolicyagent.org/docs/latest/policy-language/) would look like the following. 

```REGO
deny[reason] {
    disallowedOrigins := ["blocked.com","malicious.com"]

    some input.request.origin in disallowedOrigins
    reason := sprintf("origin %s has been blocked", [input.request.origin])
}
```

Because Policy engines are usually built to make split-second decisions by evaluating a limited dataset against a mostly static set of policies, they are perfect for infrastructure scenarios without constant changes to the data or the policies. Therefore, there’s no need for a scalable, consistent way to add or remove decision data within these engines. 

This might become an issue when dealing with application access control, especially if your application deals with many users who create or manage content. Each time a user performs an action, your application needs to gather all relevant data points before passing them on to the policy engine. Because of this, the latency of your request depends more on how much time it takes to gather this information than on how fast your decision engine can evaluate its policies. As your application scales, so does your data. These lookups can become a bottleneck for fast and reliable access control decisions.

Luckily, the next access control strategy I want to discuss, relationship-based access control, is built just for these use cases.

## Relationship-Based Access Control (ReBAC)

**Relationship-based access control** is a strategy that offers a fine-grained control based on looking at relationships between users and resources, or between multiple (different) resources.

Most ReBAC implementations today are based on Google's Zanzibar paper. In this paper, they describe the system they’ve built internally to handle a variety of access control scenarios across the whole Google ecosystem. This system needs to be flexible enough to handle authorization scenarios for their varied range of products and fast enough not to impact the user’s experience with them. 

To learn more about the Zanzibar paper, visit our informational website [zanzibar.academy](https://zanzibar.academy).

Just like attribute-based access control, ReBAC usually has a decision engine and a modeling language that lets you define relationships the engine will evaluate. New to this paradigm is a database that stores a large and ever-changing set of data related to all users and resources and their relationships. Whenever a user performs an action, this dataset can be impacted.

### OpenFGA 

[OpenFGA](https://openfga.dev) is an open-source solution for Zanzibar-style ReBAC access control. It’s been adopted by the Cloud Native Computing Foundation (CNCF) and actively worked on by members of Okta and the open-source community. OpenFGA uses an easy-to-read domain-specific language (DSL) to model the authorization model and exposes an API to add tuples to a database or query for access control decisions.

<include 
    src="LinkCard" 
    title="Do you prefer a managed ReBAC solution?" 
    link="https://fga.dev" 
    description="Okta FGA is built on top of OpenFGA and takes away the headaches of hosting, scaling, securing, and backing up your data. 
Find out more at fga.dev."
/>

### Direct versus indirect relationships

The relationships defined in the authorization model can be either direct or indirect. Simply put, direct relationships are directly assigned between a consumer and a resource (we call them user and object) and stored in the database. Indirect relationships are the relationships we can infer based on the data and the authorization model. 

We can write our first simple authorization model using OpenFGA DSL to define a `user` and a `repository` type. A repository can have a user or multiple users as a relation. Knowing this, we can assign a user as the owner of a GitHub repository by saving the following tuple in the database:

```
type user
type repository
  relations
    define owner: [user]
```

```
{
  user: "user:sam",
  relation: "owner",
  object: "repository:fga-demo"
}
```

When we ask the decision engine whether user `Sam` is the owner of the `fga-demo` repository, the engine looks in the database, finds the tuple, and gives us a positive response.

The true power of ReBAC lies in its ability to calculate indirect relationships—relationships that are not explicitly defined but can nonetheless be found between a user and an object. If we expand the GitHub example and add an organization, we can check whether members of that organization can commit to a repository owned by that organization, even if they are not directly assigned as a `repo_writer`.

```
type user
type organization
  relations
    define member: [user]
    define repo_writer: [user] or member
type repository
  relations
    define owner: [organization]
    define can_commit: repo_writer from owner
```

```
{
  user: "user:sam",
  relation: "member",
  object: "organization:okta"
},{
  user: "organization:okta",
  relation: "owner",
  object: "repository:fga-demo"
}
```

Given this new model and these two tuples, we can query for some direct and indirect relationships.
- Direct: `Sam` is a `member` of the `Okta` organization 
- Direct: The organization `Okta` is the `owner` of the `fga-demo` repository
- Indirect: `Sam` is a `repo writer` for the `fga-demo` repository
- Indirect: `Sam` can commit to the `fga-demo` repository

By examining the relationships between users (consumers) and objects (resources) instead of a static list of roles and permissions, Rebac offers a highly flexible and powerful way to deal with fine-grained authorization decisions within applications.

## Hybrid Access Control Solutions

While most access control products, services, or libraries started out with a specific approach in mind, many of them added (partial) support for other paradigms to be flexible, all-in-one solutions.

Using **OpenFGA**, [Contextual Tuples](https://openfga.dev/docs/modeling/token-claims-contextual-tuples) allow authorization checks that depend on dynamic or contextual relationships not written to the OpenFGA store, enabling some attribute-based access control (ABAC) use cases. For example, allow or disallow an action based on the time of day. You can also use [conditions](https://docs.fga.dev/modeling/basics/conditions) to make your authorization models more flexible.

**OPA** was originally created to deal with ABAC for infrastructure. There are some initiatives, like [TOPAZ](https://www.topaz.sh), that are adding a database to the system, allowing it to make decisions on a larger, more dynamic dataset, just like ReBAC does, avoiding the need to gather all relevant data before asking your policy engine for a decision.

[OPAL](https://www.openpolicyagent.org/integrations/opal/) is another initiative that adds an administration layer to OPA. This layer helps you sync the policies and data in your OPA sidecars across your agents.

## Conclusion

There is **no magic bullet for dealing with authorization in all scenarios** we, as application builders, have to face. 

Considering which approach works well for your situation will help you scale your authorization decisions as your application or infrastructure grows more complex. So, ask yourself whether you’re looking for a simple role-based or finer-grained solution. An attribute or policy-based approach might work great if you're dealing with infrastructure. Still, a relationship-based approach might be the best solution for complex applications, saving you from doing some extra database lookups before making each access control decision.

An Overview of Commonly Used  Access Control Paradigms

jimena-garbarino

Jimena is an experienced result and value-oriented programmer with a strong engineering background. She excels with Ruby on Rails, Java, and Scrum development. She has worked in web development for 10+ years in many industries and has a master's degree in software engineering from Universidad de Buenos Aires.

Spring Cloud Developer

Jimena Garbarino

Implementing OpenID Connect authentication in Java Web Applications with Okta Spring Boot Starter and Spring Security support for Authorization Code Flow with PKCE

Proof Key for Code Exchange (PKCE) in Web Applications with Spring Security

Calling a protected API from a .NET 8 Blazor Web App can be a bit tricky. Let's see what the problems are and how to solve them.

Call Protected APIs from a Blazor Web App

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.

Staff Developer Advocate

Deepu K Sasidharan

Passkeys and WebAuthn for developers. Learn how passkeys work and the benefits they provide.

A Passwordless Future: Passkeys for Developers

Passkeys and WebAuthn for Java developers. Learn how to get started with passkeys for your Java and Spring Boot applications.

A Passwordless Future: Passkeys for Java Developers

Let’s find out how to add Auth0 authentication to the new Blazor application model introduced in .NET 8.

Add Auth0 Authentication to Blazor Web Apps

Pradheepa Pullanieswaran

Pradheepa Pullanieswaran is a Developer Advocate at Okta, with a real love for backend and open-source technologies. She has worked in enterprise and web technologies for over a decade and now on the journey of helping developers to better secure their application. She is also an active member of Women Who Code and mentors women to step into the software industry. She loves to read and spends time with her family in her spare time.

Web Authentication API (WebAuthn) is a W3C and FIDO specification that allows registration and authentication of users using public key cryptography instead of a password.

## Introduction

WebAuthn (Web Authentication) is an API specification by W3C that facilitates a secure way for users to log in to online services and websites using various authentication methods, such as biometrics (e.g., fingerprint or facial recognition) and hardware-based authenticators (e.g., USB or NFC tokens). 

## Key Features of WebAuthn

### Phishing resistant

WebAuthn uses [public key cryptography](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/); the user's private key never leaves their device. Since WebAuthn relies on cryptographic keys, it is resistant to phishing attacks. Assuming that a bad actor tricks the user into entering their credentials on a phishing site, the attacker cannot use those credentials because they are scoped to a specific domain. In short, a credential created for `webauthn.me` cannot be used by a fake website, `webauth.me`. According to [Verizon DBIR 2023](https://www.verizon.com/business/resources/reports/2023-data-breach-investigations-report-dbir.pdf), Phishing is one of the major attacks on a web-based application, as shown in the following image. Using WebAuthn, the web applications could have easily averted these attacks. 
   
#### Action varieties in Social Engineering incidents

![Action varieties in Social Engineering incidents](https://images.ctfassets.net/23aumh6u8s0i/EAHiNaQrRaclMm2OnR1TA/cc50a06eef6af456d6a02f74731d4f6e/Phishing_DBIR.png)
 
### High-Security standards 

WebAuthn leverages industry-standard cryptographic algorithms and protocols to ensure the highest level of security. It utilizes the [authenticators](https://auth0.com/blog/not-all-mfa-is-created-equal/#Factors--Authenticators--and-Assurance) to confirm the user's identity and create highly secure public-private key credentials. There are two types of authenticators: roaming authenticators, like hardware security keys, and platform authenticators, like your laptop or device, that support biometrics, such as fingerprint recognition, facial recognition, and voice recognition, depending on the capabilities of the user's device.

### Seamless user experience

With WebAuthn, users can authenticate with a single gesture or action, providing a convenient and frictionless login experience. While delivering a seamless and convenient authentication experience for users, it also enhances security.

## WebAuthn Roles

**Relying Party** - This is the website or online service the user wants to access. The relying party initiates the WebAuthn authentication process and verifies the user's identity.

**WebAuthn Client Device** -  The user's device (e.g., smartphone, computer) that supports WebAuthn and communicates with the relying party. It is capable of hosting the private keypair in secret storage that a user can access through biometrics or PIN.

**User** -  The individual attempting to access a relying party's website or services.

**Authenticator** - There are two types of authenticators, i.e., Platform Authenticators and Roaming Authenticators. 
  
Platform Authenticators refer to a specific type of authenticator built into the user's device or platform, such as a smartphone, laptop, or desktop computer. For example, a smartphone's fingerprint sensor or a laptop's built-in biometric recognition system can act as a platform authenticator. 
  
Roaming Authenticators are authenticators not tied to any particular platform but can be used to authenticate across multiple devices. They are also sometimes referred to as cross-platform or external authenticators. e.g., hardware security keys like the YubiKey.

<include src="WebAuthnMeCTA" group="A"/>

## How WebAuthn Works

WebAuthn's mode of authentication consists of a Registration Flow and an Authentication Flow. With WebAuthn, there are no longer shared credentials between the user and the relying party. A public-private key pair is generated with the help of the authenticators and is used instead of the password. Let us look into the user journey of the registration and authentication flows.

### Registration flow

#### A User visits a website

The process begins when a user visits a website or a web application that supports WebAuthn for authentication and requests the website to create a new account.

#### Initiating registration

The website, often called the relying party, begins the registration process. It generates a unique and cryptographically random challenge and communicates to the user's browser that it wants to register a new public-private key pair for the user.

#### The User chooses an authenticator to generate a public-private key pair

The user selects their preferred authenticator, a platform authenticator (built into their device, e.g., fingerprint sensor), or an external authenticator (e.g., a hardware security key). The chosen authenticator generates a new public-private key pair for the user and signs the challenge generated by the relying party with those keys. 

#### The Authenticator sends back the user credentials

The private key is securely stored within the authenticator, while the public key is sent back to the website along with the signed challenge and an optional private key ID.

#### The Website stores the user credential

The website stores the user's public key and the private key ID (if sent) and associates it with the user's account for future authentication; 

![WebAuthn Registration Flow](https://images.ctfassets.net/23aumh6u8s0i/6tOAUn8BVSqRrvnoe9fekn/d4614b12e493faeefc6d3cfaf36f3245/WebAuthn_Registration_Flow.png) 

The registration process is completed, and no more shared secrets are exchanged over the network between the user and the server, eventually reducing the risk of stolen credentials.

### Authentication flow

Once the user's registration is complete, the returning user can verify the credentials and log in to the application. Following are the steps that take place in the authentication flow for the user.

#### User returns to the website 
When users return to the website to access the protected resources, the web application prompts the user to authenticate. The user provides the username to the server.

#### Website generates an authentication challenge
The website generates a new challenge and sends it to the user's browser.

#### User requests authenticator to sign the challenge
The user selects the authenticator they used during registration, or the authenticator may be automatically detected and requested to sign the challenge. 

#### Authenticator signs the challenge
The authenticator signs the challenge using the private key stored during the registration flow. The authenticator sends the signed response and the public key back to the website.

#### User verification
The website receives the signed response and the user's public key. It verifies the response by checking the signature against the stored public key. If the verification is successful, the website grants the user access to the requested resources.

![Authentication Flow](https://images.ctfassets.net/23aumh6u8s0i/5gbfSpwf2b3EOAP4gP1elm/ae3db34de58eca086f963d06303c54cb/WebAuthn_Authentication_Flow.png)

The user is authenticated securely without a password and with less friction to the user.

## How to Implement the WebAuthn API

Two methods in the WebAuthn API mediate between the user and the server to create the public-private key pair.

1. `navigator.credentials.create`
2. `navigator.credentials.get`

### Using the "navigator.credentials.create" method

The `navigator.credentials.create` method is used to initiate registering a new credential for a user. This method allows users to create a new credential, such as a public-private key pair, which can be used for secure authentication in the future. Here's how you can use `navigator.credentials.create`.

#### Prepare credential creation options
You need to define the options for the credential creation request. These options specify various credential creation parameters, such as the relying party ID (your website's domain), user information, and allowed authenticator types (e.g., platform authenticator or external security key).

Here's an example of how to create credential creation options:

```
const publicKey = {
  challenge: new Uint8Array(/* Generate a random challenge */),
  rp: {
    name: 'Webauthn Me', // Relying party name
    id: 'webauthn.me',     // Relying on party ID
  },
  user: {
    id: new Uint8Array(/* Generate a unique user ID */),
    name: 'jane.doe@example.com',
    displayName: 'Jane Doe',
  },
  pubKeyCredParams: [
    { type: 'public-key', alg: -7 }, // ES256 algorithm
  ],
  timeout: 60000, // 1-minute timeout
  attestation: 'direct', // Attestation type
};

```

The following section describes each variable in detail.

- `challenge`: A challenge is a random value generated by the server and included in the registration request that helps to prevent replay attacks. The challenge serves as a nonce (number used once), ensuring that each registration request is fresh and not subject to replay. It prevents attackers from intercepting and reusing a valid registration message to gain unauthorized access. The server should validate the response promptly and reject it if the challenge has expired or does not match.
- `rp`: The relying party is the entity that relies on WebAuthn for authentication. For example, it is the domain of the website that implements WebAuthn to enable secure user authentication. Validating the relying party information helps prevent phishing attacks.
- `user`: Information about the user who wants to register.
- `pubKeyCredParams`: It is an array that specifies the acceptable public key algorithms and parameters for the generated credential. The array consists of two properties,
    1. `type`: A string indicating the cryptographic algorithm to be used. Common values include "public-key" for ECDSA (Elliptic Curve Digital Signature Algorithm) or "rsa" for RSA (Rivest–Shamir–Adleman)
    2. `alg`: An integer representing the specific algorithm within the given type. For example,`-7`representing ES256 for ECDSA with SHA-256.
- `timeout`: The time limit for the credential creation process.
- `attestation`: The attestation parameter specifies how the authenticator (e.g., security key, biometric device) should attest to the authenticity of the public key credential it generates during the registration process. The attestation parameter can take different values, each representing a different attestation type. Common values include:
    1. `none`: No attestation is requested. The authenticator generates a credential without any assertion of its authenticity. This is suitable for scenarios where the relying party already has a secure means of verifying the authenticator.
    2. `direct`: The authenticator provides an attestation statement, but the format and content depend on the authenticator type. This is also known as "self-attestation."
    3. `indirect`: The authenticator forwards an attestation statement obtained from a third-party service, typically the manufacturer or a trusted party.

#### Call "navigator.credentials.create"
Use the `navigator.credentials.create` method to initiate the credential creation process.

```
navigator.credentials.create({ publicKey })
  .then((credential) => {
    // Handle the successful credential creation
    // Send the credential information to your server for storage
  })
  .catch((error) => {
    // Handle any errors that occurred during credential creation
  });

```
`publicKey`:  It is the variable defined in the previous step. 

#### Handle the Credential Creation Response
If the user successfully creates a credential, the `navigator.credentials.create` promise will resolve with a credential object. You should send this credential object to your server for storage and associate it with the user's account.

```
// Handle the successful credential creation
// Send the credential information to your server for storage
navigator.credentials.create({ publicKey })
  .then((credential) => {
    // Response object has information about the authenticator data, 
    // public key, transport mechanisms, and more.
    const response = credential.response;

    // Access attestationObject ArrayBuffer
    const attestationObj = response.attestationObject;

    // Access client JSON
    const clientJSON = response.clientDataJSON;

    // Return authenticator data ArrayBuffer
    const authenticatorData = response.getAuthenticatorData();

    // Return public key ArrayBuffer
    const pk = response.getPublicKey();

    // Return public key algorithm identifier
    const pkAlgo = response.getPublicKeyAlgorithm();

    // Return permissible transports array
    const transports = response.getTransports();
    
    // Send the credential information to the server for storage
    return credential;
  })
  .catch((error) => {
    // Handle any errors that occurred during credential creation
    console.log('FAIL', error)
  });


```

If the credential creation fails or if there are errors, the promise will be rejected, and you can handle the errors accordingly.

Remember that the server-side storage and management of user credentials are essential for the WebAuthn authentication process. The server should securely store the user's public key and other relevant information to enable future authentication.

### Using the "navigator.credentials.get" method

The `navigator.credentials.get` method is part of the WebAuthn API and is used to initiate the process of authenticating a user based on the credentials they have previously registered. This method is typically used in conjunction with the `navigator.credentials.create` method for credential registration. Here's how you can use this method.

#### Prepare authentication options
You need to define the options for the authentication request. These options specify the criteria for the user's credentials for authentication. You can include the relying party ID (e.g., your website's domain) and specify the allowed authentication methods.

Here's an example of how to create authentication options:

```
const publicKey = {
  challenge: new Uint8Array(/* Generate a random challenge */),
  rpId: 'webauthn.me', // Relying party ID
  allowCredentials: [
    {
      type: 'public-key',
      id: /* The credential ID of the user's registered credential */,
    },
  ],
  userVerification: 'preferred', // or 'required'
};
```

The following section describes each variable in detail.

- `userVerification:` It specifies the preferred user verification method that the relying party wishes to be performed during the WebAuthn authentication process. The [userVerification parameter](https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Presence_vs_User_Verification.html) can take different values, each representing a different user verification method. Common values include `required`, `preferred`, and `discouraged.`
- `allowCredentials:` It is an array that contains one or more "PublicKeyCredential" objects representing the credentials that the relying party is willing to accept during the authentication process. Each element in the allowCredentials array is an object with the following properties: 
  1. `type`: A string specifying the type of the credential. Commonly, this is set to "public-key".
  2. `id`: A byte array representing the credential ID. This corresponds to a credential that was previously created during the registration process.
- `challenge` and  `rpId` are the same parameters used for the `navigator.credentials.create` method.

#### Call "navigator.credentials.get"

Use the `navigator.credentials.get` method to initiate the authentication process:

```
navigator.credentials.get({ publicKey })
  .then((assertion) => {
    // Handle the successful authentication assertion
  })
  .catch((error) => {
    // Handle any errors that occurred during authentication
  });
```

`publicKey`:  It is the variable defined in the previous step.

#### Handle the authentication response
If the user successfully authenticates, the `navigator.credentials.get` promise will resolve with an authentication assertion containing information about the user's successful authentication. You can then send this assertion to your server for verification.

```
// Handle the successful authentication assertion
// Send the assertion to your server for verification
navigator.credentials.get({ publicKey })
  .then((assertion) => {
    // Handle the successful authentication assertion
    // The assertion response has information about the authenticator data, 
    // signature, and user handle
     const response = assertion.response;

    // Access authenticator data ArrayBuffer
    const authenticatorData = response.authenticatorData;

    // Access client JSON
    const clientJSON = response.clientDataJSON;

    // Access signature ArrayBuffer
    const signature = response.signature;

    // Access userHandle ArrayBuffer
    const userHandle = response.userHandle;

    return assertion;
  }).catch((error) => {
    // Handle any errors that occurred during authentication
    console.log('FAIL', error)
  });
```

If the authentication fails or if there are errors, the promise will be rejected, and you can handle the errors accordingly.

Remember that the server-side verification of the authentication assertion is an essential part of the process. The server should validate the assertion's signature and ensure that it matches a previously registered credential for the user.

These steps provide a high-level overview of how to use `navigator.credentials.create` and `navigator.credentials.get` in the WebAuthn API for user authentication. The actual implementation will vary based on your specific use case and server-side verification requirements.

## Conclusion

WebAuthn offers a passwordless and highly secure alternative to traditional authentication methods. Leveraging public key cryptography, user verification methods like biometrics, and a challenge-response model, WebAuthn effectively mitigates the risks associated with phishing attacks and enhances online security. It's important to note that while WebAuthn is phishing-resistant, it is not immune to all types of attacks. Therefore, proper implementation and security best practices on both the client and server sides are crucial to harness the security benefits of WebAuthn fully. [Auth0 supports WebAuthn](https://auth0.com/blog/mfa-with-webauthn-for-fido-device-biometrics-now-available/) and adheres to industry best practices and security standards, removing the heavy lifting of implementing on your own. It is a simple toggle switch in the configuration to show up in your login box, and all the background processing is taken care of by Auth0.

<include src="SignupCTA" text="Try out WebAuthn with Auth0?" linkText="Get started →" />

WebAuthn - A Short Introduction

bonfida

Establishing your identity in a permissionless and censorship-resistant way using Solana. We give the power back to our users

Bonfida.sol

What about a single username for all the dapps that you have to sign up for? No passwords, no emails, just your SNS domain. One that is uniquely yours across Web3.

It’s no secret that an average internet user makes use of an array of emails, passwords, and username combinations spread across different apps to ensure logins. A process that prevails to be a logistical effort.

Today, however, we’re changing the game for Solana developers, their dapps, and users - to make the Solana “login” experience(s) a dream.

We present to you a tooling built by Bonfida and Auth0: **Sign-in with SNS** (SIWSNS). SIWSNS is a new authentication method for .sol domain name holders. A method that allows a domain holder to live interoperably, control their digital identity and build Web3 profiles under a single name across every dapp they interact with.

Following a few simple steps, developers are able to harness the power of Web3 domains and automatically populate the identities of users interacting with their projects. One that is secured by the technology of public-private keys and guarantees consistent identities across the space. Besides the security of this method, we are accelerating the onboarding process for users and enabling already existing personalities to nest themselves in the new projects they delve into. Carrying over their potential following.

This makes for a much simpler experience - where practically no information is required. Ultimately reducing the barriers to entry and stimulating a better and more convenient Web3 experience.

[View the Marketplace page for SIWSNS for developers.](https://auth0.github.io/marketplace-integrations/#/marketplace-integrations/preview/889/details/siwsns)

## A Better Experience for Solana Users

Domain names are unique. This means only one `[king.sol](https://king.sol/>)` and only one `queen.sol` can exist in our space. No, you don’t have to worry about signing into a dapp and not being able to use the same username you have on another.

Sign in with the Solana Name Service Powered by Auth0

Learn how to validate a JSON Web Token (JWT) in different contexts using C# in .NET.

**JSON Web Tokens (JWTs)** have become very popular. Many developers use them in their applications for authentication and authorization purposes, but not all of them really know why and how to validate their JWTs.

This article will explain why you need to validate a JWT, what it means in general, and give you an overview of the many ways you can do it in the .NET platform.

## What Are JWTs?

If you landed on this article, you probably know what a JSON Web Token is. If not, [here is a great introduction to JWTs](https://jwt.io/introduction) and [a tool to decode them](https://jwt.io/#debugger-io).

Simply put, JSON Web Token is an [open standard](https://datatracker.ietf.org/doc/html/rfc7519) that defines how to share information between parties using the [JSON format](https://datatracker.ietf.org/doc/html/rfc8259). The [JWT structure](https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-token-structure) consists of three concatenated Base64 url-encoded strings, separated by dots: the header, the payload, and the signature The information carried by a JWT is **digitally signed so you can verify its origin and trust it**. The digital signature also guarantees the integrity of the information, but it doesn't guarantee privacy unless explicitly encrypted.

Besides this, the JWT specification doesn't define the specific purpose of a token. While most developers think of authentication when dealing with JWTs, this is not an intrinsic property of tokens in the JWT format. JWT is just a format. The meaning of the token depends on the specific context or application.

For example, in the [OpenID Connect](https://openid.net/developers/how-connect-works/) (OIDC) context, the JWT format is used for the ID token, which is the token that proves a user is authenticated. In the [OAuth 2.0](https://auth0.com/docs/authenticate/protocols/oauth) context, the [JWT format can optionally be used for the access token](https://datatracker.ietf.org/doc/html/rfc9068), which is the token that allows a client application to access a specific resource on behalf of the user.

> To learn more about ID and access tokens and their differences, you can read [this blog post](https://auth0.com/blog/id-token-access-token-what-is-the-difference/) or watch [this video](https://www.youtube.com/watch?v=vVM1Tpu9QB4) instead.

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

## What Does Token Validation Mean?

The main purpose of a JWT is to carry information that the recipient can trust. So, the first thing your application needs to do when it receives a JWT is to ensure that the information it carries is trustworthy. This is where validation comes in.

In short, validating a JSON Web Token means ensuring that the token has the structure defined in the standard specification and that you can trust the information it carries.

The JWT validation is based on the following five criteria:

- **Token structure**. The first check is about the token's structure. Does the token match the structure of a JSON Web Token? If the token doesn't follow the standard guidelines, it's not valid.

- **Token integrity**. The next check is for the token's integrity. Has the token been tampered with? You can verify this by checking the signature. If you verify that the token's signature is valid, then it has not been altered in any way.
- **Token expiration**. JWTs have an expiration time defined in the `exp` claim. Is the token expired when it has been received? If a token has expired, you should no longer trust its contents.
- **Expected authority**. The next check is to verify that the token was issued and signed by the expected sender (authority). There are two steps to this check:
  - Verify that the authority is the one expected by your application by comparing it to the `iss` claim (issuer).
  - Verify that the key used to sign the JWT actually belongs to the expected authority.
- **Expected audience**. Finally,  verify that the token is intended for your application. In other words, you should check that the `aud` claim matches with the value that identifies your application. For example, in an ID token, the value for the audience is the client ID; in an access token in JWT format, the value for the audience is the [API identifier](https://auth0.com/docs/get-started/apis/api-settings#general-settings).

> To learn more about [digital signatures, read this article](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/). Check out [this article](https://auth0.com/blog/rs256-vs-hs256-whats-the-difference/) for the differences between the signing algorithms used in a JWT.

Token validation doesn't involve the custom information carried by the token. This is an application-specific logic, which is out of the scope of token validation. For example, validating an ID token does not include verifying that the user's email address in the `email` claim exists.

## Validate a JWT Using an Auth0 SDK

Now that you know what validating a JWT means, you are ready to learn how to validate your tokens in .NET.

Before jumping into the validation code, you should evaluate whether you really need to explicitly validate the JWTs you receive from an issuer like Auth0. Depending on the specific application, you may want to use an Auth0 SDK, which will take care of all the validation steps for you. For example, if you are developing an ASP.NET Core MVC application or a Blazor Server application, you can use the [Auth0 ASP.NET Core Authentication SDK](https://github.com/auth0/auth0-aspnetcore-authentication). This SDK will take care of the entire process of obtaining the JWT tokens for your application, including token validation. Check out [this article](https://auth0.com/blog/exploring-auth0-aspnet-core-authentication-sdk/) for an overview of this specific SDK.

So, if your application can benefit from an SDK, the best move is to write less code and get the JWT validation for free. Take a look at [this article to learn which Auth0 SDK is right for your .NET application type](https://auth0.com/blog/choose-the-right-dotnet-sdk-for-auth0/). 

## Using the ASP.NET Core Middleware

If, for some reason, you can't use an Auth0 SDK, you can configure your ASP.NET Core application by using two middleware:

- The [OpenIdConnect middleware](https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.OpenIdConnect), which allows your ASP.NET Core web applications to authenticate users and get ID and access tokens via [OpenId Connect](https://openid.net/developers/how-connect-works/).
- The [JwtBearer middleware](https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.JwtBearer), which enables your ASP.NET Core web API to handle access tokens.

Both middleware provide you with a convenient way to obtain and validate JWT tokens. The following code snippet shows an example of how to configure OpenIdConnect middleware:

```csharp
// Program.cs

var builder = WebApplication.CreateBuilder(args);


builder.Services.AddAuthentication(options => {
    options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = CookieAuthenticationDefaults.AuthenticationScheme;
  })
  .AddCookie()
  .AddOpenIdConnect("Auth0", options => {
    options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}";
    options.ClientId = builder.Configuration["Auth0:ClientId"];
    options.CallbackPath = new PathString("/callback");
  });

// ...other code...
```

The next example shows how to use the JwtBearer middleware:

```csharp
// Program.cs

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
  .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
  {
    options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}";
    options.Audience = builder.Configuration["Auth0:Audience"];
  });

// ...other code...
```

In both cases, by configuring the `Authority` option, you implicitly ask the middleware to validate your tokens. The middleware will use this value to retrieve the issuer's signing key, which is needed to validate the token's signature. All the other required validation steps are performed automatically. There is nothing else you need to do.

### Simplified configuration for the JwtBearer middleware

Starting with .NET 7, you can [use the JwtBearer middleware in a simplified way](https://auth0.com/blog/whats-new-in-dotnet-7-for-authentication-and-authorization/#Simplified-Configuration). You define your validation values in the `appsettings.json` file, as in the following example:

```json
// appsettings.json

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "Authentication": {
    "Schemes": {
      "Bearer": {
        "Authority": "https://{DOMAIN}",
        "ValidAudiences": [ "{AUDIENCE}" ],
        "ValidIssuer": "{DOMAIN}"
      }
    }
  }
}
```

Then you can simply add the middleware to your ASP.NET Core application, as follows:

```csharp
// Program.cs

// ...existing code...

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication().AddJwtBearer();

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

The behavior is exactly the same as before but with much less code.

### Custom validation with the ASP.NET Core middleware

If you have specific needs, you can customize the JWT validation using the `TokenValidationParameters` option. For example, if you already have the issuer's public key stored on your file system, you can configure your middleware as shown in the following example:

```csharp
// Program.cs

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
  .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
  {
    options.Audience = builder.Configuration["Auth0:Audience"];
    options.TokenValidationParameters = 
      new Microsoft.IdentityModel.Tokens.TokenValidationParameters
      {
        ValidateIssuer = true,
        ValidIssuer = $"{builder.Configuration["Auth0:Domain"]}",
        ValidateIssuerSigningKey = true,
        IssuerSigningKey = new X509SecurityKey(new X509Certificate2(certificateFilePath)),
        ValidateLifetime = true
      };
  });

// ...other code...
```

You can see that the `Audience` option is still there while the `Authority` option is missing. Instead of the `Authority` option, you find the `TokenValidationParameters` option, which is assigned an instance of the `TokenValidationParameters` class. The properties of this instance define what to check in order to complete the JWT validation. Specifically, you ask to validate the issuer (`ValidateIssuer`) and provide the value to match with (`ValidIssuer`). You ask to validate the issuer's signature (`ValidateIssuerSigningKey`) and provide the issuer's public signing key (`IssuerSigningKey`) embedded in a certificate stored in the file system. And finally, you ask to check the expiration time (`ValidateLifetime`).

You can see how removing the `Authority` option from the middleware configuration forces you to manually specify what to check in order to validate the token.

## Validate a JWT “By Hand”

In case you can't use the ASP.NET Core middleware, for example, when you are not developing a web application, don't get desperate. .NET gives you what you need, although this requires some effort on your side.

### Validate your token

First, you need to install the `Microsoft.IdentityModel.Tokens` package from NuGet:

```bash
dotnet add package Microsoft.IdentityModel.Tokens
```

This package provides everything you need for token manipulation, including validation, of course.

Have a look at the following function:

```csharp
public bool ValidateToken(
  string token, 
  string issuer, 
  string audience, 
  ICollection<SecurityKey> signingKeys,
  out JwtSecurityToken jwt
)
{
  var validationParameters = new TokenValidationParameters {
          ValidateIssuer = true,
          ValidIssuer = issuer,
          ValidateAudience = true,
          ValidAudience = audience
          ValidateIssuerSigningKey = true,
          IssuerSigningKeys = signingKeys,
          ValidateLifetime = true
  };

  try
  {
    var tokenHandler = new JwtSecurityTokenHandler();
    tokenHandler.ValidateToken(token, validationParameters, out SecurityToken validatedToken);
    jwt = (JwtSecurityToken)validatedToken;
    
    return true;
  } catch (SecurityTokenValidationException ex) {
    // Log the reason why the token is not valid
    return false
  }
}
```

This function takes a token and validates it by using the other parameters: the issuer, the audience, and the signing keys. If the token is valid, it returns `true` and provides a `JwtSecurityToken` instance representing the token as the `jwt` output parameter.

Once again, you see the `TokenValidationParameters` class, which allows you to define the validation criteria. This time there is no implicit validation. You need to specify all the required validation criteria and the valid values. Then you create a token handler (`JwtSecurityTokenHandler`) and use it to validate the token against the validation parameters. If the validation succeeds, you get an object representing the token, which you assign to the output parameter after casting to `JwtSecurityToken`. Finally, the function returns `true`.

If the validation fails, it should log the reason for the failed validation and return `false`.

### Get the signing keys

The `ValidateToken()` function expects you to pass the basic information for the token validation: the token issuer identifier, the audience, and the issuer's signing keys. You may have all this information on hand or need to retrieve some of it. For example, you can obtain the signing key of the issuer online. According to the [OIDC standard](https://openid.net/specs/openid-connect-discovery-1_0.html), you can find the set of keys (*JSON Web Key Sets*) to verify the issuer's signatures at a public and well-defined URL: `https://{DOMAIN}/.well-known/openid-configuration`.

Read [this document to learn more about the JSON Web Key Sets](https://auth0.com/docs/secure/tokens/json-web-tokens/locate-json-web-key-sets).

To validate a JWT using the `ValidateToken()` function, you must first retrieve the signing key from this URL. As you can see, things start to get complex. This is why I suggest using an Auth0 SDK in the first place, or at least the ASP.NET Core middleware, if possible.

However, if using one of these tools is not feasible in your specific case, here is what you need to do to get the issuer's signing keys.

First, you need to install another package from NuGet: the `Microsoft.IdentityModel.Protocols.OpenIdConnect` package:

```bash
dotnet add package Microsoft.IdentityModel.Protocols.OpenIdConnect
```

This package provides you with the `ConfigurationManager` class, which helps you retrieve the JSON Web Key Sets. The following code shows you how to obtain the signing key of your JWT issuer:

```csharp
var configurationManager = new ConfigurationManager<OpenIdConnectConfiguration>(
  $"https://{builder.Configuration["Auth0:Domain"]/.well-known/openid-configuration}",
  new OpenIdConnectConfigurationRetriever(),
  new HttpDocumentRetriever());

  var discoveryDocument = await configurationManager.GetConfigurationAsync();
  var signingKeys = discoveryDocument.SigningKeys;
```

Once you have the signing keys, you are ready to use the `ValidateToken()` function.

## Recap

Throughout this article, you have learned what JWT validation is and why you need to do it. You also learned that as a .NET developer, you have many options for validating the JWTs your application receives: from a zero-code approach to an almost manual validation.

With the Auth0 SDKs, you get the JWT validation for free. No specific code is required. The SDKs validate tokens for you.

Using the ASP.NET Core middleware, OpenIdConnect and JwtBearer, you get implicit token validation in the default cases. However, you can customize your validation criteria if you are dealing with special cases.

In case you need full control over the validation process, you can rely on the `Microsoft.IdentityModel.Tokens` package for the JWT manipulation and validation and on the `Microsoft.IdentityModel.Protocols.OpenIdConnect` package for retrieving the issuer's signing keys.

Of course, the suggestion is to delegate as much as possible to the SDKs and middleware because the less code you write, the fewer bugs you may create 🙂.


How to Validate JWTs in .NET

Learn how to support Auth0 in Azure SWA for your Blazor WebAssembly application.

Support Auth0 in Azure Static Web Apps for Blazor WebAssembly Apps

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

Learn how to use roles in your Blazor Server and WebAssembly applications to implement the RBAC authorization model.

Role-Based Access Control in Blazor Applications

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

Damian Schenkelman

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

VP R&D (Auth0Lab)

We’re bridging the Web2 and Web3 worlds with new integrations from our partners

Over the past few months, the [Auth0 Lab](https://lab.auth0.com/) team has researched the [Web3 space](https://auth0.com/blog/identity-and-web3/) and its relation to identity, with a main focus on developer building blocks. From that research, we realized we could play a role in **bridging the Web2 and Web3 worlds.**

What do we mean by bridging? In short, making it easy for developers to create applications that take advantage of constructs from each world as necessary through the help of [Web3 partners and their integrations](https://auth0.com/developers/lab/web3). We think we are well positioned to do this, as "software identity" can serve as that bridge.** **

We took a step toward that goal with the introduction of the [Web3 category in the Marketplace](https://marketplace.auth0.com/categories/web3). This new category will help you seamlessly leverage Web3 constructs when building your applications. In this post, we’ll explore the tools we’ve made available and give you a brief overview of our analysis of Web3 and decentralized technologies at large.

## Why Web3?

Let’s start by defining what we mean by Web3. We don't mean cryptocurrencies and decentralized finance. Those are specific _applications_ of Web3.

To us, Web3 includes the philosophies, concepts, and technologies that prioritize user [choice](https://www.notboring.co/p/the-web3-debate?s=r) and [ownership](https://future.a16z.com/why-web3-matters/) and that one can use to build decentralized services. [Blockchains](https://en.wikipedia.org/wiki/Blockchain), tokens (fungible or non-fungible), protocols, services, [dApps](https://ethereum.org/en/developers/docs/dapps/), and [users' keys](https://ethereum.org/en/developers/docs/accounts/#externally-owned-accounts-and-key-pairs) are some (but not all) of the elements that make up Web3.

At its core, Web3 is about user choice. As Packy McCormick, founder of NotBoring,[ put it](https://www.notboring.co/p/the-web3-debate):

_“Some people will want centralized services, some will want fully decentralized ones, and many will choose points on the spectrum in between that work for them at different times and for different things. And we're arguing that Web3 gives them that choice.”_

From our research, we believe Web3 can help application builders provide personalized user experiences and satisfy privacy and compliance use cases. But for the space to really take off, it needs to deliver a strong user experience and protect customer data and assets. 

Countless companies rely on the Okta Customer Identity Cloud to help them meet their UX and security goals. We are excited to bring our capabilities to developers and companies looking to leverage Web3 constructs in the identity space, and the Web3 Marketplace category is our first step toward that goal.

## A New Set of Building Blocks for Identity

Web3 constructs introduce a set of new "decentralized identity" building blocks. With them, users can own their credentials and choose what data they share and what remains private.

Let's go over those building blocks in detail.

**Private keys as credentials.** Users’ private keys can act as credentials to authenticate with services, providing passwordless login user experiences. 

For example, [Sign-in with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) (SIWE) provides sign-in functionality for Ethereum accounts. More generally, [Decentralized Identifiers](https://www.w3.org/TR/did-core/) (DIDs), a recently approved w3c (World Wide Web Consortium) open web standard, propose identifiers based on asymmetric cryptography and owned by users. Methods like [did:pkh](https://github.com/w3c-ccg/did-pkh) or [did:ethr](https://github.com/uport-project/ethr-did) implement DIDs using addresses/keys from decentralized networks like Bitcoin, Ethereum, Solana, etc. You can watch [this video](https://twitter.com/Auth0Lab/status/1501984414267490311?s=20&t=7ig8XYs2PR9gPBCfr8fUMg) on how we used SIWE in a sample app.

**Public, human-friendly usernames.** These can be implemented by associating friendly names, like jane.eth or gary.wallet, to blockchain addresses via smart contracts. These usernames would act both as a user-friendly way to refer to blockchain addresses and as a single username across all applications that rely on the account's private key for authentication.

**Public User Profiles.** These can be implemented using the aforementioned smart contracts to map attributes (besides usernames) to a blockchain address. Some users might publicly share an avatar/profile picture, email address, or other personal details. 

Applications can then use these profiles to provide personalized experiences to users without requiring the creation of application-specific profiles. Watch [this video](https://twitter.com/Auth0Lab/status/1501984444500033542?s=20&t=7ig8XYs2PR9gPBCfr8fUMg) on how we used public user profiles and usernames in a sample app.

**Public Attestations.** These can be implemented using either non-fungible tokens (NFTs) for "ownership attestations" or "soulbound tokens" (SBTs) for non-transferable attestations. 

[Token gating](https://medium.com/@jshanks21/nft-meaning-token-gating-ad83aef7cccd), where access to specific features is allowed only if a user owns a token on a blockchain, is an example of how these could be used. Shopify is working on [tokengated commerce](https://help.shopify.com/en/manual/products/digital-service-product/nfts#tokengated-commerce). You can watch [this video](https://twitter.com/Auth0Lab/status/1501984507481792519?s=20&t=7ig8XYs2PR9gPBCfr8fUMg) on how we used NFTs for token gating in a sample app.

**Private User Data**. This data is associated with a user's identifier (this works with and without DIDs), and **Privacy-Preserving Attestations** can be implemented using [Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) (VCs) and Zero-Knowledge Proofs (ZKPs). 

**Verifiable Credentials**, cryptographically verifiable digital credentials, can be obtained and stored on a user's phone app (called "wallet", adding to the confusion around the term). 

Later, users can present them (the entire credential or some of its attributes) wherever they want. A benefit of these Verifiable Credentials is that issuers don't need to know where credentials are presented. You can watch [this video](https://twitter.com/Auth0Lab/status/1501984570136272900?s=20&t=7ig8XYs2PR9gPBCfr8fUMg) on how we used Verifiable Credentials to help prove a user's age in a sample app.

## Introducing the Web3 Category in Our Marketplace

The Marketplace allows developers to explore and install integrations for various use cases into their identity infrastructure. With a single click, you can add support for Identity Proofing, implement risk-based MFA, or send application activity to your logging infrastructure, among other things. 

Web3 is built on open standards and composable building blocks, giving developers flexibility in how they design and architect their applications. We want to provide that same composability and extensibility. That's why we’ve partnered with leading Web3 organizations that are building developer tooling to launch the Web3 category on the Marketplace.

![web3 and blockain](https://images.ctfassets.net/23aumh6u8s0i/5hBxjlnYRZDGmNqTnLrfBm/a3ea21e3252993f9dbe0a5cbf6cfa8db/01_web3_and_blockain.png)

### Use Cases

As we started working with Web3 organizations to build integrations for Okta, we discovered integrations typically fit into one of three use cases:

* **Logging in with a Web3 account/private key**: Authenticating to an application as the owner of a particular blockchain address or private key. This provides a passwordless login experience to users that allows them to own their identity without involving third parties like social login providers.
* **Creating a Web3 wallet for a user:** Allows creating and associating a wallet (custodial or non-custodial) to an Okta user that logged in with any Okta connection (social, enterprise, database, etc.). This is a model similar to that of centralized exchanges and some gaming platforms. They use it because it does not require users to have a wallet before signing up, so users don't drop out because of that requirement during the signup process.
* **Use Web3 public constructs for app logic:** Once a user's blockchain accounts are identified, developers can use it within their applications. Potential scenarios include: displaying profile information, listing a user's NFTs, and gating access to content based on NFT ownership.

_We expect that as we learn more and Web3 constructs evolve, the previous three categories/use cases might change. For example, a new use case for reading and writing private data might be available in the future once we have integrations supporting those features in our Marketplace._

### Available Integrations

#### Use case: Logging in with a Web3 account/private key

**[Sign-in with Ethereum](https://marketplace.auth0.com/integrations/siwe) (by [Spruce](https://www.spruceid.com/)):** Sign-in with Ethereum enables users to log in with their Ethereum account instead of relying on a traditional intermediary (e.g., social login). 

Spruce builds decentralized identity developer tooling. They are also developing a self-sovereign user data storage solution for Web3 users and organizations. Self-sovereign user data storage means that it relies on open standards and the user’s keys for security, allowing users to control where they store their personal data and who they share it with.

**[Sign-in with Unstoppable Domains](https://marketplace.auth0.com/integrations/unstoppable-domains) (by [Unstoppable Domains](https://unstoppabledomains.com/)):** Unstoppable Domains allows Web3 users to access apps using their portable digital identity. This integration will allow your users to sign in by proving they own a specific domain from Unstoppable Domains. 

That proof is performed by having the user sign a message with the private key that is associated with the address on which the domain is registered and verifying the message's signature. Your app will be able to access profile information associated with the user's domain, such as wallet address, email, profile picture, social profile, and more.

**[Dock Web3 ID](https://marketplace.auth0.com/integrations/dock-web-3-id) (by [Dock](https://www.dock.io/)):** Decentralized Identifiers are identifiers defined in a w3c recommendation. They allow a party (for example, a user) to prove control over them without requiring permission from any other party (for example, a company). For example, to authenticate using a specific DID, a user can sign a payload with a private key that the DID expresses should be used for authentication. 

Then, another party can verify that the signature corresponds to the specific DID. This integration allows your users to sign in by proving ownership of the authentication key of a Decentralized Identifier (DIDs).

#### Use case: Creating a Web3 wallet for a user

**[Non-custodial Web3 Wallets](https://marketplace.auth0.com/integrations/web3auth) (by [Web3Auth](https://web3auth.io/)):** The Web3Auth integration allows you to create and associate a non-custodial wallet to any Okta user, regardless of how they logged in.

#### Use case: Use Web3 public constructs for app logic

**[ENS Profile](https://marketplace.auth0.com/integrations/ens-profile) (by Auth0 Lab):** The Ethereum Name Service (ENS) integration lets you integrate ENS profile data into your application. You can leverage and display user-picked usernames, avatars, and other pieces of their public profile without requiring users to create them for your specific application.

**[NFT Retrieval](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts) (by Auth0 Lab):** The NFT Retrieval integration allows you to retrieve NFTs from a set of contract addresses and add them to ID Tokens as claims. With this, you can use the user's NFTs in your application's logic. 

> _Today, the NFT extensions assume you also use the [Sign-in with Ethereum](https://marketplace.auth0.com/integrations/siwe) integration to get the user's Ethereum address. In the future, we hope to work with partners to standardize claim names. Standardization should allow integrations to read/write users' blockchain accounts from/to a single claim, improving interoperability between integrations._


## What's Next

Launching the Web3 category is our first step to making it easy for developers to build applications using constructs from the Web3 world.

If you are a developer or company exploring integrations with Web3 technologies, we encourage you to [explore these integrations](https://auth0.com/developers/lab/web3) and take them for a spin. It should take minutes to enable Web3 capabilities for new or existing Web2 apps. 

If you are a Web3 organization creating products for other developers, consider building an Okta Customer Identity Cloud integration. Countless developers and businesses use Okta Customer Identity Cloud to manage identity at scale. By building an integration, you can reach hundreds of potential new customers and users. We explain how the integration development process works at [https://auth0.com/integrate](https://auth0.com/integrate).

![integration](https://images.ctfassets.net/23aumh6u8s0i/2cwAfgp4KrMdWMlMtwfjcm/a640a78e8d55498d46bdb873d135f2c5/02_integration.png)

Okta is excited about the prospect of a decentralized future and looks forward to working closely with the Web3 community. Join our [Discord](https://discord.com/invite/QGHxwDsbQQ) to share your thoughts and tell us about the integrations you want to see in the future. We look forward to working with you. 

Let’s keep building!

Introducing the Web3 Category in Marketplace

Use Jakarta EE 10 to build a secure Java web application using OpenID Connect and Auth0.

Use Jakarta EE 10 with OpenID Connect Authentication

Samuel Frank

Sam Frank is Auth0's Sr. Product Manager for new initiatives. He works within the Auth0 Lab to commercialize the team's new ideas so they're available for builders everywhere. As a former platform product manager and startup product lead, he knows the challenges that developers face when creating new apps and he leverages those experiences to focus our teams efforts delivering the next generation of identity tools.

Senior Product Manager

The Customer Identity Cloud platform can now reference NFTs as profile data and as a means to grant access.

The [Auth0 Lab team](http://labs.auth0.com/) has released a pair of [Marketplace integrations](https://auth0.com/marketplace) bringing more [Web3 capabilities](https://marketplace.auth0.com/categories/web3) to the Okta Customer Identity Cloud ecosystem. As the Web3 ecosystem matures, we’re finding that on-chain data, like NFTs (non-fungible tokens), can be used in the identity ecosystem. 

[Our integration](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts) is a simple NFT fetch [Action](https://auth0.com/docs/customize/actions) that retrieves a list of NFTs the user owns. With them, you can make all sorts of IAM-based decisions. If you’re interested in the Auth0 Lab team’s continued Web3 research, come join the conversation on [Twitter](https://twitter.com/Auth0Lab) and [Discord](https://discord.gg/xkbkz9rZcD).

## NFTs in Identity and Access Management (IAM)

By now, you’ve probably heard of NFTs. If not, here [is a helpful explainer](https://www.nytimes.com/interactive/2022/03/18/technology/nft-guide.html). At their core, NFTs are digitally transferable tokens. Tokens have a long history in identity and access management. They are the keystone of authorization in many apps, primarily through the issuance of [JSON web tokens](https://jwt.io/). 

NFTs could be a big extension to token-based IAM. NFTs are flexible, secure, and easily transferable by their nature of using blockchain consensus algorithms to establish ownership and transference. Like with cryptocurrencies, only a specific private key in a wallet can prove ownership. They can help organizations manage capacity problems because you can limit the number of NFTs you mint. This scarcity helps manage supply while still allowing for a robust secondary market. This makes them ideal for ticketed events and venues, like stadiums, trains, and other physically limited spaces.

One of the biggest barriers to mainstream NFT adoption is the usability hurdle of working with blockchains. With our latest integrations, Auth0 Lab seeks to make it easy. Developers can query a user’s NFTs and incorporate them as identity data in their applications, even controlling access based on a user’s ownership of an NFT. We’re excited to see how developers use these new tools when implementing web3 functionality into their applications.

## Token Gating

[Token Gating](https://tokenizedhq.com/token-gating/) is the practice of managing access to resources based on a user’s Web3 NFTs. Notable examples include [‘members only’ communities](https://rarible.com/blog/9-membership-nfts/) of NFT collectors. This exclusivity extends to video games like [Alien Worlds](https://alienworlds.io/), the [largest web3 game](https://www.statista.com/statistics/1266486/blockchain-games-user-number/) at the end of 2022. NFTs are central to the game and unlock certain content, or game locations are only accessible with specific NFTs. [TravelX](https://travelx.io/) is working on another use case around airline tickets.

Token gating is interesting because of the openness of the attestation. Instead of IAM data being stored on a proprietary server, it’s on a public blockchain for anyone to use and see. We’re just witnessing the first experiments in how that data is used. 

## EVM Compatible, Open Source Coming Soon

The current integration works on all [Ethereum virtual machine (EVM) compatible](https://gocrypto.com/en/what-are-evm-compatible-blockchains/) blockchains. This means you’ll have access to NFTs available on some of the largest NFT marketplaces like [OpenSea](https://opensea.io/). You’ll be able to pull from [Ethereum](https://ethereum.org/en/), [Polygon](https://polygon.technology/), [Avalanche](https://www.avax.network/), [Binance Smart Chain](https://www.bnbchain.org/en), and others. EVM blockchains are the oldest programmable blockchains, and the ecosystem is well supported.

The Auth0 Lab team is working on open-source the code so it can be modified and moved to other blockchain platforms. That process takes some time, so keep an eye out by following us on [Twitter](https://twitter.com/Auth0Lab) or heading to our [GitHub organization](https://github.com/auth0-lab) and give it a follow.

## Unlocking NFTs for Your Application

### How it Works

The Auth0 Lab [fetch-nfts integration](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts) works by relying on a few other pieces of infrastructure.

1. It utilizes the [Sign in with Ethereum integration](https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/) that SpruceID released in the Auth0 Marketplace in 2022. This allows the integration to grab a public blockchain address for the user, which is critical to querying an NFT smart contract to know if they own an NFT. If a user logs in with a method other than Sign in with Ethereum, NFTs won’t be fetched.
2. During [setup and configuration](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts?tab=install), specify a list of NFT contracts that you’d like the [Auth0 Actions](https://auth0.com/actions) code to query. You’ll also need to specify an API key for [The Graph](https://thegraph.com/en/), a service that queries blockchain data.
3. With a public key in hand, and a list of NFT contracts to search, the Actions code calls out to The Graph’s APIs to query the necessary NFT contracts. It returns a list of caip-22 asset references that your Action adds to the [ID token](https://auth0.com/docs/secure/tokens/id-tokens) as claims.
4. From there, you can utilize the data in your application to make any decision, like token gating access, that you feel necessary!

### Installation

Check out our [installation](https://marketplace.auth0.com/integrations/auth-0-inc-fetch-nfts?tab=install) guide to get started!

## What’s Next?

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

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

Web3 NFTs for Identity and Access Control, Now Available on Marketplace

Viktor Nyitray

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

CEO of Ageware

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

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

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

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

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

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

## How Ageware Age Verification Works

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

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

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

## Privacy-Friendly Age Verification on Demand

Ageware offers: 

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

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

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

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

Ageware App Now Available on Marketplace

How to use the new user-jwts tool to test a protected ASP.NET Core Web API without involving an authorization server.

Test Authorization in ASP.NET Core Web APIs With the user-jwts Tool

Connect with 350 thousand Unstoppable users and bring Web3 universal usernames into your application

We're excited to announce the latest addition to our [Web3 marketplace category](https://marketplace.auth0.com/categories/web3): [Unstoppable Domain's](https://unstoppabledomains.com/) new [Social Connection](https://marketplace.auth0.com/integrations/unstoppable-domains) in the [Auth0 Marketplace](https://auth0.com/marketplace). You can now add Login with Unstoppable to your login box and let users use their Unstoppable NFT domains as an authentication method.

## Unstoppable Domains

A backbone of Web3 technology is the [public/private keypairs](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/). The public key acts as a blockchain 'address' that can be used on-chain to assign tokens and other resources. Users hold their private keys to verify ownership of the address. 

One of the usability challenges Web3 users face is interacting with these very long public addresses. If they make one typo when sending a cryptocurrency payment, it can lead to '[burned coins](https://www.coindesk.com/learn/what-does-it-mean-to-burn-crypto/)' – a mistake I made when I first started using Web3 tech.

Similar to how domain names made IP addresses human-readable in the 1980s, Unstoppable Domains is looking to make blockchain addresses more human-readable and easier to transact with through the use of Unstoppable NFT domains. 

These domains let users create a universal username, like myname.crypto, to use with any application. Instead of typing their wallet address into Web3 dApps, like cryptocurrency payment apps, they can instead use their NFT domain, provided the dApp developer implements [Unstoppable Domain's libraries](https://docs.unstoppabledomains.com/developer-toolkit/resolution-integration-methods/resolution-libraries/libraries-overview/) or [uses their API](https://docs.unstoppabledomains.com/developer-toolkit/resolution-integration-methods/resolution-service/overview/). 

Additionally, users can build out their digital identity attached to their NFT domains, bringing the Web3 vision of user privacy and data ownership to life.

## Web3 Signal Sign-On

Unstoppable is competing in the new Web3 wallet signal sign-on sector with over 150 dApp integrations and counting. They are an alternative [Identity Provider (IdP)](https://auth0.com/docs/authenticate/identity-providers) to Facebook, Twitter, or Google, etc. Instead of relying on these Web2 alternatives, users can use their wallet, facilitated by Unstoppable infrastructure, to sign in to applications.

![Web3 Signal Sign-On](https://images.ctfassets.net/23aumh6u8s0i/QnwtlykYKcnkdAySSzzH6/b43ce1324134ca5810ee537a05ecbafd/01_marketplace.png)

Unstoppable lets users enrich the profile associated with each domain with other data usually found in user profiles like social media accounts, personal data, other blockchain addresses the user owns, and more. Some of this data is accessible to anyone via the [Polygon Blockchain](https://polygon.technology/), while other data is stored off-chain and retrieved only when the user signs in with Unstoppable. 

Having profiles stored in Unstoppable available when signing in with Unstoppable Domains lowers the friction to create rich profiles in applications that use the Unstoppable ecosystem.

## How It Works

The Unstoppable team has done a lot of work making this process easy for developers. At a high level, it's two easy steps:

1. Create an Unstoppable client account. This video walks you through the process. You can also: [https://www.loom.com/share/f1655c8e94cc464188472eea80d0f921](https://www.loom.com/share/f1655c8e94cc464188472eea80d0f921); learn about its client configuration options here: [https://docs.unstoppabledomains.com/login-with-unstoppable/login-integration-guides/login-client-configuration/](https://docs.unstoppabledomains.com/login-with-unstoppable/login-integration-guides/login-client-configuration/)
1. Install and configure the social connection in the [Auth0 Marketplace](https://marketplace.auth0.com/integrations/unstoppable-domains) and Auth0 [Dashboard](https://manage.auth0.com/). Configuration instructions are on the marketplace integration page.

It takes five minutes. The (simplified) login flow looks a little like this:

![Unstoppable](https://images.ctfassets.net/23aumh6u8s0i/2z9a1dPN8BZLdbweEtBUVy/810fedf4d956033928516cc4d3331d7c/02_marketplace.png)

## What's Next?

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

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


Sign in with Unstoppable Domains, Now on Auth0 Marketplace

pablo-cibraro

Pablo is an internationally recognized expert and entrepreneur with more than 22 years of experience in designing and implementing large distributed systems with Microsoft technologies and a Connected System MVP. <br>
For the last few years, Pablo has helped numerous Microsoft teams develop tools and frameworks for building service-oriented and web applications with .NET. <br>
Pablo now focuses on technologies that enable developers to build large-scale systems and web applications on the cloud, such as HTML5, Node.js, ASP.NET, Windows Azure and Amazon AWS.

Agilesight Cofounder

Pablo Cibraro

Learn about the new ASP.NET minimal Web APIs introduced in .NET 6.0 and how to secure them with Auth0.

Securing ASP.NET Minimal Web APIs with Auth0

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

Use JHipster to build a photo-sharing app for web and mobile that has a React front-end with OIDC authentication and a Spring Boot back-end with OAuth2 authorization.

Integrate React Native and Spring Boot Securely

alexa-bio

Alexa is a Product Marketing Manager on the Auth0 platform team. With a partner and product marketing background, she is focused on growing our marketplace ecosystem working closely with new and existing partners.

Product Marketing Manager

Alexa Jacky

How Auth0 is Investigating Decentralized Identity and Blockchains

Web3, the concept that makes smart contracts and Decentralized Finance possible, continues to grow, having gained [the support of tens of millions of users and around $30 billion in VC investments as of late 2021](https://www.forbes.com/sites/rahulrai/2022/01/02/an-overview-of-web3-venture-capital-activity-in-2021/?sh=43f5eebb1f16). The [Auth0 Lab](https://twitter.com/auth0lab) team has been monitoring and [experimenting with Web3](https://auth0.com/blog/sign-in-with-ethereum-siwe-now-available-on-auth0/) and adjacent technologies. 

From our research and the flurry of interest from consumers and investors alike, it appears that Web3 is moving towards a user-centric web experience. We recognize that it's still early days for Web3. There will be stumbling blocks as the space matures. As the Web3 ecosystem evolves, we are looking for opportunities to bridge the gap between Web2 and Web3 technologies. 

The Auth0 Identity Platform is the backbone of many conventional Web2 applications, leading us to dive into how we can allow our customers to interact with the "on-chain" identity data of their users. Over the course of our research, we've established relationships with Web3 partners to expand our ecosystem and offerings, and we're excited to share them with you today.

## What Is Web3?

Web3 is based on the idea that users should have control over their data, money, and identities without relying on central gatekeepers. In a speech at [Web3 Summit 2018](https://medium.com/@onion797jp/what-is-web3-transcript-7e867e96ddb1), Juan Benet, Co-Founder of Protocol Labs, described it like this: 

"Web 2.0 was about linking programs to that content and building rich, dynamic applications across their devices. And what's going on now is that the relationship is getting inverted. We're linking content and programs directly to each other, bypassing intermediary organizations, removing intermediaries, and gaining public verifiability."

Blockchains and decentralized networks run through the heart of Web3. This new digital economy relies on public ledgers and private wallets to keep track of _who_ owns _what_. They hold the public addresses and private cryptographic keys necessary to conduct transactions. This growing public key infrastructure adds a potentially valuable new security layer to the web.

## What Are the Hesitations around Web3?

A major hurdle in the Web3 space is the lack of mass-market momentum. Web3 technologies are largely used by those invested in crypto and developers looking to build for the future.

Criticisms of Web3 include:

- Potential data protection risks
- The environmental costs of mining and transacting
- The length and complexity of completing a transaction. 

We're aware of the challenges in this space. Web3 is still largely unregulated, and its decentralized nature makes it difficult to add the consumer protections found in the traditional economy. Unlike your credit card, you can't reverse fraudulent transactions. 

Knowing this risk, big players in the Web3 space, such as Coinbase, have taken additional steps to protect customer assets and data. [Coinbase Wallet, for example, allows you to authenticate with biometrics or a PIN](https://blog.coinbase.com/explore-web3-confidently-with-coinbase-wallet-and-ledger-266ce35097a3). It has partnered with other companies to provide hardware wallets that store your private keys in a secure, air-gapped physical device. 

The environmental impact of Web3 also remains a pressing concern for organizations. Cryptocurrencies have a steep carbon footprint, particularly when it comes to mining and transacting. To address this, blockchains like  Ethereum have switched to "proof of stake" from "proof of work," replacing the mining-focused mindset of crypto. 

Aside from the above consumer-level concerns, organizations are heavily invested in Web2 architectures. Many are reluctant to abandon those systems. Organizations need an easy way to bridge their existing Web2 infrastructure and investments with the growing Web3 ecosystem. Unfortunately, blockchains are technically complex to build upon from a developer's perspective. Threat actors can exploit poorly-written or insecure smart contracts to steal funds.

Web3 leaders must address these problems for it to enter the mainstream, as each is individually big enough to inhibit adoption. For many, these downsides can outweigh the potential upsides. 

## Opportunities with Web3

Web3 is young, but it has already asserted its place in the identity space, with users creating a single digital wallet to authenticate across multiple applications. Many businesses are starting to reap the benefits of decentralized identity for SSO. 

Identity on the blockchain offers powerful interoperability opportunities. Some Web3 entities use blockchains and digital wallets alongside traditional authentication methods to manage user and application data. For the end user, they can potentially use the same wallet to authenticate their identity across multiple Web3 applications for seamless login experiences. 

Digital wallets previously focused on storing assets, but with the growth of Web3 and decentralized identity, they are used as a tool to verify identity. From a user's perspective, they work much like traditional federated authentication. 

![Opportunities with Web3t](https://images.ctfassets.net/23aumh6u8s0i/K9RKpRiD5Jy9DY6hrnast/7fd289369a1f3ac77da373cef4d301ab/04.png)

A key opportunity Web3 presents in the identity space is the ability to interact with a user's blockchain data. This presents two benefits: enriching user profiles and streamlining the login process with federated logins using storage wallets. 

Organizations can gather blockchain data from users as they interact with their applications, storing it in a unique portable user profile that any organization can use. Services like Ethereum Name System and Unstoppable Domains offer these universal profiles as a service to users and organizations. Once enough data is committed to the chain, organizations can infer individual user preferences or make fundamental changes to their applications based on broader user behavior. While this is possible in the Web2 world, the decentralized approach removes the need for siloes. Within Web3, control belongs to the person who is the address holder on the blockchain.

We don't know what the future holds for Web3. However, adopting Web3 technologies early can help you prepare for changes in consumer patterns and attitudes. We'll continue to share our analysis of the Web3 space with our community, so you can make informed choices about where you invest your developer time and budget. 

## Growing Blockchain Business Use Cases

The number of business uses [for blockchain technologies](https://www.forbes.com/sites/michaeldelcastillo/2022/02/08/forbes-blockchain-50-2022/?sh=6e4d3cc331c6) continues to grow. Many leverage private permissioned blockchains shared between industry members. Unlike public blockchains like Ethereum, Solana, and others, these private blockchains are invitation-only. This element creates an authentication and authorization layer between the user and the blockchain data.

An example of an established private blockchain is Canada's [verified.me](https://verified.me/). Individuals can share data from know-your-customer (KYC) flows within financial and health institutions. A government-supported tool, it lowers the cost and friction for businesses by allowing them to offer self-service registration and identity verification for verified.me users signing up for new services. Verification is based on encrypted data previously shared with banks and other financial institutions, offering a simple way to validate user information based on trusted sources. Using this secure digital profile, users can choose to connect their data with other applications or institutions, like a credit bureau or an insurance application. Verified.me is free for the end user, so they don't have to pay to share their information. 

It's just one of many instances we've seen popping up. Others include:

* IBM's [Food Trust](https://www.ibm.com/blockchain/solutions/food-trust), which helps fight food fraud on a global scale
* [Risk Stream](https://www.riskstream.org/), which helps insurers settle complex claims faster
* [Mediledger](https://www.mediledger.com/), which helps settle contracts and ensure pharmaceutical quality

This is not an exhaustive list. Managing identity across these blockchains will present a challenge for businesses. They will need to navigate which smart contracts hold valuable identity data, how to use that data meaningfully in authorization decisions, and how to bridge the gap between a user's identity in the digital and physical worlds. 

## What Does Web3 Mean for Your Company?

It depends. For many organizations, the best course of action is to simply wait and see. Monitor the ecosystem, read blogs and technical whitepapers, watch talks from industry leaders, and attend conferences and meetups to stay up to date with the latest trends and be ready to join the Web3 world when the time is right. 

For others, it might be worth investigating if industry-specific blockchains are solving previously-unsolvable problems in your sector. You can also explore some of our [Web3 integrations](https://marketplace.auth0.com/categories/web3) in the [Auth0 Marketplace](http://marketplace.auth0.com/), and check back to hear about the new ones coming out soon.

If you're a Web3 organization looking to solve identity issues, we'd love to hear from you! You can join the[ Auth0 Lab Discord](https://discord.gg/xkbkz9rZcD) and join the conversation. We're also on [Twitter](https://twitter.com/auth0lab), too, if that's more your thing.

Identity and Web3

The Auth0 Marketplace now supports Web3Auth’s innovative key management infrastructure that transforms your app into a dapp

You need a private key to communicate with web3 blockchains; it’s the only way to confirm your own assets on blockchains. However, [Private keys pose a usability challenge](https://csrc.nist.gov/CSRC/media/Presentations/Usability-and-Key-Management/images-media/Usability_and_Key_Mgmt.pdf), and despite being around since the 70s, [they’ve seen poor adoption](https://www.academia.edu/15236280/Overcoming_Barriers_to_Client_Side_Digital_Certificate_Adoption). Web3 wallets, software that stores a private key and creates a communication framework around it, have improved the usability a bit, but it’s still not seamless. Some web3 organizations have tried to solve this problem with [custodial wallets](https://www.coindesk.com/learn/custodial-wallets-vs-non-custodial-crypto-wallets/), where they manage the key for the user. That solution is contrary to the web3 goals of user control and ownership. [Web3Auth’s innovative social authentication tools](https://medium.com/toruslabs/divi-crypto-podcast-key-management-interview-with-zhen-45c418ff3e54) create a non-custodial wallet that the user controls and is still user friendly, and you can now [integrate those tools](https://marketplace.auth0.com/integrations/web3auth) in your Auth0 tenant!

## How Web3Auth is an Advance in Web3 Usability

<img src="https://images.ctfassets.net/23aumh6u8s0i/YpE8R5YzuYRdOAO2DawCI/b64bf3f16f460cad18d3c28c98d468e7/marketplace_01.jpeg" align="right" alt="Web3" width="60%" /> To get access to any blockchain application, a user needs a web3 [public-private key pair](https://en.wikipedia.org/wiki/Public-key_cryptography). The public key functions as the user’s “address” on the blockchain. The address is an ID used to record the ownership of blockchain assets. It can also be used to encrypt messages that only the private key can decrypt. Only the address owner has access to the private key stored in a web3 wallet, which is how blockchains ensure that only the address owner can buy and sell assets associated with the address.

A major usability challenge about keys for the average end user is that if you lose access to it or the private key is exposed; you can’t update it like you would update a password. The most popular web3 wallets typically manage keys by creating a [seed phrase of 12 to 24 words](https://www.coinbase.com/learn/crypto-basics/what-is-a-seed-phrase), which can be used to create an [array of public keys tied to a private key](https://medium.com/toruslabs/a-beginners-guide-the-basic-web3-architecture-and-tech-stack-81f2061d263c). Provided you can find your seed phrase backup, you can recover access to the assets associated with your blockchain address. It's a single point of failure, and expecting users to securely backup their seed phrase does not provide a good user experience. 

[Web3Auth’s platform](https://docs.web3auth.io/overview/key-management) uses [Shamir Secret Sharing](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing) to split the key and save it in the user’s device, a social login provider, and a recovery method. Web3Auth can then look into the device storage and social sign-in to recreate the user’s key, which creates the web2 authentication experience with a non-custodial web3 wallet. If the user is using a new device, they just need to confirm their identity via a recovery option with an email or other method.

This solution provides a developer:

* A non-custodial wallet to use with web3 blockchains.
* An easier way to create user-friendly web3 onboarding in their application.
* The ability to deploy a social login experience associated with a web3 wallet.
* The best of Web3 security and privacy by design for their end-users.

Implementing social logins with Auth0 lets you quickly add a web3 wallet to your existing application. Web3Auth works with a host of blockchains, including the main layer1 chains ([Ethereum](https://ethereum.org/en/), [Solana](https://solana.com/), [Avalanche](https://www.avax.network/)), and layer 2 chains ([Polygon](https://polygon.technology/), [Starkware](https://starkware.co/), [Arbitrum](https://offchainlabs.com/) and more). By the end of the sign-in process, the user has a valid web3 wallet. It’s a frictionless, secure, self-custodial way to onboard users into the web3 world.

## How It Works

Below we have a high-level overview, but if you want the full details, check out the installation guide.

### Regular Web Application Flow

![Regular Web Application Flow](https://images.ctfassets.net/23aumh6u8s0i/71KY5i7OKKpoMa9KhkkRVM/bbfddd66297e51e870e55ef301496e27/marketplace_02.png)

1. A user initiates their sign-in request, which opens the Auth0 login experience. They select their preferred social identity provider.
2. Auth0 manages the OAuth flow, relaying information to the identity provider.
3. The identity provider relays the identity information to Auth0 based on permissions configured in the Auth0 dashboard.
4. Auth0 sends your application server an authorization code as per the normal [authentication flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow).
5. Your server adds a client ID and client secret to request an [ID token](https://auth0.com/docs/secure/tokens) for the user.
6. Your application server sends the ID token to the Web3Auth SDK in the front-end client application.
7. The Web3Auth SDK passes the ID token information to the Web3Auth network, which converts it to a piece of the private key share.
8. The key share is relayed back to the front-end application, which uses it to reconstruct the private key of the user to use in the application.

### Setup Steps

Working knowledge of JavaScript or Mobile SDKs is required depending on your application type. There are four main steps to getting the integration setup. Each of these steps are spelled out in the [integration guide](https://marketplace.auth0.com/integrations/web3auth).

1. Configure your Auth0 tenant and Web3Auth dashboard.
2. Select and install the appropriate Web3Auth SDK based on your application type.
3. With the SDK installed, you’ll need to initialize your Web3Auth application.
4. Finally, you’ll need to use the `connect.to` function to authenticate the user.

## What's Next?

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

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

Create Non-Custodial Wallets and Lower Web3 Sign-In Friction with Web3Auth’s Auth0 Integration

How to deal with the most common security threats in web development.

The focus on security has never been more important than in the current times. In the IT world, it gains more relevance every day. But ensuring security is not just about system administrators. It must also be a developer's skill, especially if they are web developers.

Auth0 brings you [a free ebook about security and web development](https://auth0.com/resources/ebooks/security-for-web-developers). Learn more about it and why you should care about web development security.

## The Web as a Development Platform

Today's Web is not the Web of the early '90s when it was invented. Originally, it was created primarily as a content management system, that is, a platform for sharing and linking static documents. The HTTP protocol and HTML language were sufficient to achieve these basic goals, and security concerns were mostly limited to controlling access to confidential documents.

The demand for interactivity led to the introduction of JavaScript and dynamic page generation technologies, both on the client and on the server sides. That has completely changed the primary use of the Web. It has evolved from a simple way to share and link documents to the backbone of the software and human connection. **The old content management system platform has switched to become a development platform**.

This paradigm change has brought benefits but also pitfalls. And it also brought a slew of new challenges, the most pressing of which is security.

## Web Applications and Security

Web application security refers to the measures taken to protect a website or web application from external attacks that could result in data loss, denial of service, or privacy violation, among other things.
When you deploy a web application, it can be accessed by anyone. You can't make any assumptions about who will access it: authorized or unauthorized users, humans, or bots. By default, **you should assume that your application is exposed to any security risk**. But what are security risks?

Three key concepts should be clear to you when analyzing your application security:

- **Threats** are incidents that can potentially harm your application. Think of them as external processes that your application must defend against.
- **Vulnerabilities** are weaknesses in your application that attackers can exploit. They can depend on design flaws or bugs, not just in your code, but also in its dependencies. Deficiencies can also exist at the infrastructure level, such as insecure protocols or network issues.
- **Risks** are the potential damage your application can suffer when a threat exploits a vulnerability. You can think of risks as the intersection of threats and vulnerabilities.

Understanding these concepts is fundamental for protecting your applications against attackers.

<include src="BigQuote" quoteText="Know your enemy and know yourself, find naught in fear for 100 battles. Know yourself but not your enemy, find level of loss and victory. Know not thy enemy nor yourself, wallow in defeat every time" quoteAuthor="Sun Tzu" />

**Consider threats as your enemy’s weapons and vulnerabilities as your weakness**. You need to know both to face the battle and make decisions with a calculated risk. In other words, learning how security attacks work is the first pass to avoiding them.

## Common Web Application Threats

It is not possible to make a complete list of potential threats to which a web application is exposed. The constantly-shifting state of web security means that there are too many variables at play. However, there are well-known threats that you should be aware of.
The [Open Web Application Security Project](https://owasp.org/) (OWASP), the online community devoted to spreading knowledge and awareness about web security, tracks the most common security risks for web applications in its [OWASP Top Ten](https://owasp.org/www-project-top-ten/). This document intends to create security awareness in the developer audience by detailing the ten most critical security risks. It represents an excellent first step towards creating a security culture in the developers’ community. Hopefully, this first step may push developers for the adoption of a [security by design](https://en.wikipedia.org/wiki/Secure_by_design) mindset, i.e., an **approach that makes you think of security at each step of your application development**.

<include src="SignupCTA" text="Try out the most powerful authentication platform for free." linkText="Get started →" />

## Security for Web Developers

In this path toward security awareness, Auth0 wants to contribute with a free ebook dedicated to security for web development: "[Security for Web Developers](https://auth0.com/resources/ebooks/security-for-web-developers)".

As we said, to protect your web applications from security risks, **you need to know how threats work to understand your application's vulnerabilities**. Each chapter of this book is dedicated to one threat and provides you with working examples of vulnerable applications. Using these examples, you’ll learn the “behind the scenes” details of each threat and how to remediate the application’s vulnerability.

For example, you will learn how *Cross-Site Scripting* (XSS), *Cross-Site Request Forgery* (CSRF), and *Clickjacking* attacks work in practice and how you can prevent them. But it's not all about reading. You can also download and get your hands on the code explained in the book. So, what are you waiting for? [Download your free copy](https://auth0.com/resources/ebooks/security-for-web-developers) and leave your feedback in the comments!

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


Security and Web Development

philippederyck

Philippe De Ryck helps developers protect companies through better web security. His Ph.D. in web security from KU Leuven lies at the basis of his exceptional knowledge of the security landscape. As the founder of Pragmatic Web Security, Philippe delivers security training and security consulting to companies worldwide. His online course platform allows anyone to learn complex security topics at their own pace. Philippe is a Google Developer Expert and an Auth0 Ambassador/Expert for his community contributions on the security of web applications and APIs.

Web Security Expert, Founder of Pragmatic Web Security

Philippe De Ryck

Deploying CSP without disruptions is quite a challenge. This article offers you practical guidance on deploying CSP for modern web applications.

CSP is one of the most elaborate security policies in modern browsers. Besides acting as a second line of defense against XSS, CSP offers control over various types of content, outgoing connections, and the application's behavior. In this article, we elaborate on these features and provide you with a prioritized CSP deployment guide that will help you configure CSP in production.


## Getting Started with CSP

In [part 1](https://auth0.com/blog/defending-against-xss-with-csp/) and [part 2](https://auth0.com/blog/deploying-csp-in-spa/) of this series on CSP, we discussed the intricacies of using CSP as a second line of defense against XSS. In this third part, we look at deploying CSP in practice, starting from nothing. We also focus on additional features CSP has to offer beyond defending against XSS.

Before we dive in, let's set the scene. You have an application for which you'd like to configure a CSP policy. Awesome! Using the guidelines from the previous articles in this series, you have set up a CSP policy for your application, which brings you to a place known by every developer: "it works on my machine".

But what happens if you deploy this CSP policy in production? Will it work on your user's machines? Will it work on every browser? And more importantly, __what happens if it doesn't work__? 

In essence, a lot of uncertainty with potentially disastrous consequences. A misconfigured CSP policy is likely to break the entire application, potentially for many users. 

With that picture in mind, we're ready to dive in. Let's start by looking at one of the remarkable features of CSP: running a policy in report-only mode.

## Deploying CSP in Report-Only Mode

You can tell a browser to run a CSP policy in report-only mode. This means that the browser will take your CSP policy, process it, and ensure that all application features are compatible with the policy. If the browser finds a violation, it will raise the necessary warnings and errors. However, unlike the examples we covered in the previous articles, the browser only reports the problem. The actual violation is not blocked.

Concretely, if the browser finds an unauthorized script block or script file, it will generate a warning, but it will not prevent the code from loading or executing.

To configure a report-only policy, the server sends the browser a CSP policy using the `Content-Security-Policy-Report-Only` header instead of the `Content-Security-Policy` header. The snippet below illustrates this configuration.

```
Content-Security-Policy-Report-Only: 
  script-src 'self';
  object-src 'none';
  base-uri 'self';
  report-uri /reporting/csp
```

Report-only mode is the perfect way to test a policy without breaking the application. However, we're still missing a piece of the puzzle. Generating warnings and errors in the developer tools is helpful for local development,  but how can you learn about errors generated in the user's browser? That's where the `report-uri` directive comes in. 

You may have noticed that the earlier sample policy contained a `report-uri` directive. This directive includes a URL, which identifies an endpoint where the browser can send reports about policy violations. The snippet below shows a sample report from one of our demo applications.

```
{
   "csp-report":{
      "document-uri":"https://example.com",
      "referrer":"",
      "violated-directive":"script-src-elem",
      "effective-directive":"script-src-elem",
      "original-policy":"script-src 'self'; object-src 'none'; base-uri 'self'; report-uri /reporting/csp",
      "disposition":"report",
      "blocked-uri":"inline",
      "line-number":10,
      "source-file":"https://example.com",
      "status-code":200,
      "script-sample":""
   }
}
```

As you can see, the browser compiles a report in JSON format. The report contains information about the location of the violation, the policy that triggered the violation, and the type of violation. These reports are sent automatically when `report-uri` is enabled. 

The reporting endpoint for handling CSP reports is straightforward. It accepts an incoming POST request with a JSON body and handles the data as desired. Typically, reports are logged in a data store for later consumption. Consumption of reports can be manual (e.g., through a dashboard) or automatic (e.g., analysis scripts). Note that most security information products have built-in support for CSP endpoints.

A final interesting tidbit about reporting is that you can ask the browser to include a sample of the inline code block that caused the violation. When `'report-sample`' is added to the `script-src` directive, the browser will include the first 40 characters of the code block. This helps perform an investigation into the cause of the violation. If you can find the inline code block that matches the snippet, you know exactly where it came from. If it is legitimate, it should be authorized to load. Otherwise, CSP has likely stopped an attack, and you should investigate this further.

To summarize, report-only mode is the best way to try out your first CSP policy in the real world without causing any disruptions for your users. You can keep tweaking your policy in report-only mode until you're happy. Once everything looks good, you can deploy the policy in blocking mode using the regular `Content-Security-Policy` header.

## CSP Reporting in Blocking Mode

A CSP policy that is running in blocking mode can still trigger violations. For example, when an attacker tries to exploit an XSS vulnerability, the policy is supposed to raise an error and stop the script from executing. 

Note that all of this happens behind the scenes in the user's browser. But with CSP reporting, you can instruct the user's browser to send you a report about the violation. This way, you can learn about the violation and investigate the potential cause, such as a misconfiguration or an actual XSS vulnerability. 

The snippet below shows a CSP policy in blocking mode, with reporting enabled.

```
Content-Security-Policy: 
  script-src 'self' 'report-sample';
  object-src 'none';
  base-uri 'self';
  report-uri /reporting/csp
```

CSP reporting is a great way to gain insights into the behavior of your application in the user's browser. However, you should not go on a wild goose chase when you see a single violation report. Reporting is valuable but not necessarily very accurate. 

For example, browser extensions often modify content on a page, which can trigger a violation of your CSP policy. Unfortunately, adjusting a CSP policy to allow arbitrary extension behavior is not feasible. In fact, browser extensions often even modify CSP policies, in which case the violation is caused by a policy that's not even yours. This [blog post by Dropbox](https://dropbox.tech/security/on-csp-reporting-and-filtering) gives a bit more insight into the challenges of running a CSP reporting endpoint in the real world. 

Finally, the CSP reporting endpoint is unauthenticated and publicly accessible. An attacker could easily supply fake CSP reports to the endpoint to confuse the security team. 

As a consequence, we recommend enabling CSP reporting and monitoring incoming reports. However, following up on reports is likely only warranted when many users produce the same report or if the report can be traced back to a potential attack vector in the application. Filtering and finetuning are essential to reduce the noise in the feed. 

## CSP beyond Script Code

So far, we've only talked about CSP as a second line of defense against XSS attacks. However, if you look at the CSP specifications, you'll discover that CSP can do so much more. This section looks at all the other types of content you can control with CSP.

Before we dive in, we want to point out that most of the peculiarities of handling JavaScript do not apply to other types of content. The directives for other types of content can be configured with simple expressions pointing to specific hosts, including a CDN, without negatively impacting the security of the CSP policy. The only exception is CSS code, so let's cover that first.


### Stylesheets

CSP allows you to control how the browser handles CSS code in the page. The `style-src` directive applies to all CSS code, such as `<style>` blocks, `style` attributes, and remote stylesheets. 

Like script code, CSS code is considered dangerous dynamic content since malicious CSS code can change the behavior of the page. Therefore, setting the `style-src` attribute enables a couple of default restrictions, such as blocking all inline CSS code. 

To re-enable inline style code, the `style-src` directive supports the same mechanisms as we have discussed from script code: `'unsafe-inline'`, hashes, and nonces. In theory, you are supposed to selectively enable style code using hashes or nonces. In practice, the story is somewhat different.

Using hashes and nonces should not be that difficult if you completely control the style code. However, in many real-world applications, styling is handled in a library that is not under the control of the application developer. Not enabling inline style code typically breaks the library, and selectively re-enabling styles is often infeasible. That's why a real-world CSP policy that aims to restrict styles is generally forced to add `'unsafe-inline'` to make things work. 

To summarize, restricting styles is a bit less critical than restricting JavaScript code execution. If you want to configure a `style-src` directive, aim to make it as strict as possible. However, if you end up enabling `'unsafe-inline'`, it's not the end of the world.


### Images, fonts, and media

CSP also allows you to control where images, fonts, and media (audio and video) can be loaded from. The directives for these resources are, in respective order, `img-src`, `font-src`, and `media-src`.

These directives are typically configured with a list of URL-based locations. Note that it is not uncommon for images to include `data:` as a source expression or even use the wildcard `*`.


### Embedded content

The `object-src` directive allows you to define valid sources for embedded content, typically included using the `<object>`, `<embed>`, or `<applet>` elements. 

Note that these elements are typically used for legacy content, such as Flash files or Java applets. In modern applications, these are typically no longer needed. Therefore, it is recommended to set the `object-src` directive to the value `'none'`. 

### Child contexts

A document loaded in the browser can create a new browsing context, resulting in a parent-child relationship. One example is using an `<iframe>`, which creates a nested browsing context. Another example is loading a web worker, which also instantiates a child context. Both child contexts are instantiated with a URL, for which the source can be controlled with the `child-src` directive.

The recommended default value for the `child-src` directive is the value `'none'`. When the application relies on iframes or web workers, this directive should be configured with the expected sources for these children.


### Setting a default

That leaves one more content directive to discuss: `default-src`. This directive can be used as a default configuration for each type of resource that is not configured with an explicit directive. 

No worries, it sounds more complicated than it is. Let's take a look at an example.

```
default-src 'self'; img-src https://images.example.com
```

The policy shown above uses `default-src` as a catchall but also specifies an `img-src` directive. So for scripts, stylesheets, fonts, etc., the browser applies `default-src`. In this example, these types of content can be loaded from the application's origin. For images, there is a more specific directive (`img-src`), so the browser uses that instead. Images can only be loaded from `https://images.example.com`, not from the application's origin.

The CSP specification allows an elaborate configuration of `default-src`, including the use of hashes and nonces. However, in practice, such a configuration is not recommended. Instead, `default-src` should be set to a sane starting point, which is either `'none'` or `'self'`. For every type of resource you would like to load, you can configure specific directives with the desired expressions.

To summarize, `default-src` applies to everything that is not explicitly configured. If a more specific directive is present, only that directive is considered for that particular type of content.

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

## Even More CSP Directives

There's a lot more to CSP (yes, really!). Apart from controlling where content is loaded from, CSP also allows you to control outgoing connections, as well as certain application behaviors. We briefly cover these directives in this section. 

Note that this is not an exhaustive guide on every available CSP directive. We refer to [this extensive CSP guide on the Mozilla Developer Network](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) for more information.


### Controlling outgoing connections

With CSP, you can control outgoing connections. Concretely, CSP offers two directives for this purpose: `form-action` and `connect-src`.

The `form-action` directive allows you to choose where forms can be submitted. This directive is useful to avoid form hijacking in a traditional web application. For traditional web applications, the value `'self'` makes the most sense. Single Page Applications typically do not rely on form submissions but call APIs from JavaScript code instead. SPAs should set the `form-action` directive to the value `'none'`.

The `connect-src` directive controls outgoing connections, such as XHR or Fetch requests, but also WebSocket connections and Server-Sent Events. This directive should be configured with the APIs that your application consumes. If no outgoing connections are needed, the directive can be set to the value `'none'`.

### Enabling additional restrictions

CSP also offers control over behavioral features in the browser. Let's look at a few directives that you should definitely know about.

The `frame-ancestors` directive allows the application to restrict how it is loaded in a frame. Since many applications are not supposed to be loaded in a frame anywhere, they configure this directive with the value `'none'`, which is an essential [defense against UI redressing attacks](https://auth0.com/blog/preventing-clickjacking-attacks/). When selective framing is desired, the application can use `'self'` or a list of URLs to enable selective framing. Omitting the directive from a policy allows all framing, which is the default behavior in all browsers. 

The `sandbox` directive is the most restrictive directive available in CSP. It is similar to the `sandbox` attribute for `iframe` elements and is intended to be used on responses serving potentially untrusted content, such as user-provided documents. Adding the `sandbox` directive without any expressions enables all restrictions of the HTML5 `sandbox` attribute on the browsing context. A sandbox disables JS execution, form submissions, plugin content, popups, etc. To re-enable selective restrictions, specific keywords can be added as values of the `sandbox` directive (e.g., `sandbox allow-scripts`). For more information about the sandbox and its restrictions, check out [this MDN documentation page](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox).

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

## A Prioritized CSP Deployment Guide

We're reaching the end of this three-part series on CSP, and what a journey it has been. 

We started by discussing [CSP's ability to act as a second line of defense against cross-site scripting](https://auth0.com/blog/defending-against-xss-with-csp/). After that, we looked at [using CSP in a modern JavaScript frontend application](https://auth0.com/blog/deploying-csp-in-spa/). And in this third part, we looked at many other goodies CSP has to offer, such as reporting, content directives, and behavioral control.

But where does that leave you? How do you even get started with CSP? What should you focus on first?

All good questions that we'll answer in this final section, where we provide you with a prioritized CSP deployment guide. This guide helps you get started with deploying CSP for a modern application. Of course, your mileage may vary depending on your needs.


### It's mostly about XSS

The most important capability of CSP is stopping or limiting the exploitation of an XSS vulnerability. That's precisely what [Google's CSP policy](https://auth0.com/blog/defending-against-xss-with-csp/#Google-s-Universal-CSP-Policy) focuses on. So, if you're starting with CSP, forget about all the other types of content. You can always handle them later.

Your first CSP policy should configure `script-src` to fit your application. You also need to add `base-uri` and `object-src`, which can likely be configured with respectively `'self'` and `'none'` values. 


### Try it out

You can easily try out a CSP policy on a development version of the application. However, if you want to see your policy in action, deploy it as a report-only policy. This will give you a good idea of what you can expect.


### Flip the switch to blocking mode

When you are happy with your report-only policy, you can consider transforming it into a blocking policy by changing the name of the response header. No worries if you get something wrong, you can easily remove or modify the CSP header afterward.


### Congratulate yourself

If you succeeded in deploying a strict CSP policy in blocking mode without causing any side effects, you did great. You have now successfully deployed a second line of defense against XSS, which is no small feat.


### Add additional defenses

Frontend applications are supposed to have protections against UI redressing attacks in place. The easiest way to enable these is by adding a `frame-ancestors` directive to your CSP policy. 


### Further finetune your CSP policy

If you prefer, you can keep finetuning your CSP policy to cover other types of content as well. To be honest, the benefits of doing so are quite limited compared to the secondary defense against XSS attacks. Additionally, it will make the policy a lot more fragile, so be careful when you go down this path.



From Zero to Hero with CSP

Marketplace partner Spruce has expanded the Auth0 platform to use web3 wallets as an identity source.

Thanks to the hard work of [Spruce](https://www.spruceid.com/), following their [announcement on March 8th](https://blog.spruceid.com/spruce-developer-update-17/), you can now add Sign-in with Ethereum to your Auth0 tenant via their [marketplace integration](https://marketplace.auth0.com/integrations/siwe). While the debate rages on the value of cryptocurrencies, non-fungible tokens (NFTs), and decentralized autonomous organizations (DAOs), it’s clear that Web3 technologies have the potential to change the way we authenticate. The [Auth0 Lab team](https://twitter.com/Auth0Lab) has been [following Web3 developments closely](https://twitter.com/Auth0Lab/status/1501984403773394946?s=20&t=_wTmCWDZR0kQifVURed70Q), and we’re excited to promote this new capability in Auth0.

## Adoption 

<img src="https://images.ctfassets.net/23aumh6u8s0i/oPVdQLjdTS63FS60ODRzA/3892e933900b03cf12060cbdb9c34a9a/Uploaded_from_Sign_in_with_Ethereum" align="right" alt="Adoption" width="450" /> At the end of 2021, [crypto.com](http://crypto.com/) estimated that [300 million people](https://assets.ctfassets.net/hfgyig42jimx/5i8TeN1QYJDjn82pSuZB5S/85c7c9393f3ee67e456ec780f9bf11e3/Cryptodotcom_Crypto_Market_Sizing_Jan2022.pdf) own some form of cryptocurrency. That means those 300 million crypto users (as well as new ones) need a wallet to hold the private keys allowing them to access their currency. 

Diving in, [71 million of those cryptos](https://decrypt.co/89486/number-of-non-zero-ethereum-addresses-record-high-71-million-glassnode) wallets hold Ethereum. This massive adoption has led to an ecosystem of tools to help users leverage the [private keys in their wallets](https://developer.bitcoin.org/devguide/wallets.html) for more than just blockchain transactions. 

While many users lean on [Metamask](https://metamask.io/) for [non-custodial software wallets](https://www.bitcoin.com/get-started/custodial-non-custodial-bitcoin-wallets/) and a gateway for interacting with [Web3 DApps](https://ethereum.org/en/developers/docs/dapps/), other options are gaining market share. [Portis](https://www.portis.io/) and [Torus](https://toruswallet.io/) are other non-custodial wallet competitors.

<br><br><br>

[Coinbase](https://www.coinbase.com/) is a popular cryptocurrency exchange that creates [custodial wallets](https://www.coindesk.com/learn/custodial-wallets-vs-non-custodial-crypto-wallets/) on behalf of users to hold on to their cryptocurrencies. [With 89+ million verified users](https://www.coinbase.com/about#:~:text=Coinbase%20powers%20the%20cryptoeconomy,%2C%20earn%2C%20and%20use%20crypto.), it’s quickly becoming a trusted option. [Fortmatic](https://fortmatic.com/) is a custodial wallet just for authentication and gives users access to their private key with a traditional email/password flow that users recognize in web2.


[WalletConnect](https://walletconnect.com/) is both a standard and a set of SDKs that help any app connect to any type of Web3 wallet. With over 160 apps listed in its registry, it’s becoming a popular way for developers to get access to users’ wallets.

Transactions on the Ethereum blockchain are also increasingly getting easier to conduct courtesy of tools like the [Ethereum Name Service (ENS)](https://ens.domains/), which, similar to DNS, maps a unique human-readable name to the underlying machine-readable strings assigned to each wallet/account. This name can be used instead of the public key, and many apps know to find the address by looking at the ENS smart contract with a registry of the associated addresses. [With 300k+ users](https://ens.domains/#home-statistics), ENS is a growing trend in the Web3 community that makes it easier for the average person to work with their key.

## Sign-in with Ethereum (SIWE)

Ethereum, along with other blockchains that allow for “[smart contracts](https://ethereum.org/en/developers/docs/smart-contracts/)”, allow for additional authentication data to be stored on the blockchain. Non-fungible tokens (NFTs) are already being used to grant access to things like [web communities](https://thirdweb.gitbook.io/thirdweb/guides/membership-nft-for-discord), [restaurants](https://coinyuppie.com/empowering-the-membership-club-model-analyzing-the-worlds-first-nft-restaurant/), and [events](https://cointelegraph.com/news/showtime-nft-tickets-take-the-stage-in-2022-connecting-artists-and-fans). When our [Auth0 Lab team](https://twitter.com/Auth0Lab) started looking into Web3 technologies, we realized that smart contracts could be used to store data for [JWT claims](https://jwt.io/introduction), [verifiable credentials](https://en.wikipedia.org/wiki/Verifiable_credentials), and other authorization data. All that’s needed is a signature by the private key to prove the user’s ownership of those rights.

In early December 2021, the Auth0 Lab [released a demo](https://twitter.com/Auth0Lab/status/1468974610058137604?s=20&t=6GJfq6iCeKQ_vhonsCgNSw) of what this could look like using Auth0. It quickly [got the attention](https://twitter.com/metamask/status/1471177244450111498?lang=en) of Web3 organizations like Metamask and led to a jump into the [Auth0 Lab Discord membership](https://discord.gg/xkbkz9rZcD), a community open to anyone interested in discussing Auth0 Lab initiatives with the team. 

[Spruce](http://www.spruceid.com/), which builds decentralized identity tooling and [self-sovereign user data storage](https://www.spruceid.com/kepler) for Web3 users and organizations, released a [sign-in with Ethereum (SIWE) integration](https://marketplace.auth0.com/integrations/siwe) on the Auth0 marketplace. Now any Auth0 client can leverage SIWE in their applications.

![Spruce](https://images.ctfassets.net/23aumh6u8s0i/7qt8yG4BuFlFw5zshSeoVt/f1bd2e1300fa06af4d4d92f0e4625637/Uploaded_from_Sign_in_with_Ethereum)

This activity diagram shows how the oidc.login.xyz server can facilitate authentication. The website in this diagram is an Auth0 application. Like with any OIDC server, Auth0 can augment the data from any additional sources and help manage the JWT. It’s a great way to quickly plug your existing Auth0 application into the growing Web3 user base.

Currently, Metamask, WalletConnect, Fortmatic, Torus, and Coinbase are all supported in the integration.

## Adding Sign in With Ethereum to Your Tenant

It only takes minutes to add sign in with Ethereum to your Auth0 tenant! 

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

### Step One: Add the Integration from the Marketplace

From [https://marketplace.auth0.com/integrations/siwe](https://marketplace.auth0.com/integrations/siwe), with a simple click of “Add Integration” and a quick selection of which tenant you’d like to add the integration to, you can get started with your setup.

![Step One](https://images.ctfassets.net/23aumh6u8s0i/5sEgcSRNSFANYAdz2dHD9Q/9eb81092329c05bf9e40cdf9a8d50bcb/Uploaded_from_Sign_in_with_Ethereum)

### Step Two: Obtain a Client ID and Secret

Obtain a Client ID and secret, this can be done with a simple CURL command:

```
curl -X POST https://oidc.login.xyz/register -d '{"redirect_uris":["https://YOUR_AUTH0_DOMAIN/login/callback"]}'
```

![Step Two](https://images.ctfassets.net/23aumh6u8s0i/6qu6mdHY7AEPtn146hdscW/aae8d0fe17316defe591973784a743e9/Uploaded_from_Sign_in_with_Ethereum)

### Step Three: Create the New Social Connection

Login to the Auth0 tenant you selected in Step One and head over to your social connections. A sign-in with Ethereum connection will be on the list:

![Step Three](https://images.ctfassets.net/23aumh6u8s0i/06A8NyYZB1me1aUoQNsHk/8e7710042f874be484e70b3da1a30b9f/Uploaded_from_Sign_in_with_Ethereum)

### Step Four: Configure the Social Connection

Accept the access request by clicking “Continue”, and add your Client ID from Step Two. If your application is a[ Confidential Application](https://auth0.com/docs/get-started/applications/confidential-and-public-applications), add the Client Secret. 

![Step Four](https://images.ctfassets.net/23aumh6u8s0i/34XGbspkzKnoq9HCNZZHmh/cb71bc313c862877fdab1145b57b1852/Uploaded_from_Sign_in_with_Ethereum)

### Step Five: Enable the Connection on Your Application

Finally, toggle the connection to on for the application you’re trying to add it to:

![Step Five](https://images.ctfassets.net/23aumh6u8s0i/32ac6TFbbxiXFOgL0kGyDE/63304bbfa56209f8d2507c979e636ca3/Uploaded_from_Sign_in_with_Ethereum)

That’s it! If you need additional help, review the installation instructions on the [integration marketplace page](https://marketplace.auth0.com/integrations/siwe), and you can always join the [Spruce discord server](https://discord.gg/Sf9tSFzrnt).

## Future Plans for Sign-in with Ethereum

Sign-in with Ethereum (SIWE) [is an open standard](https://eips.ethereum.org/EIPS/eip-4361), led by Spruce with support from the Ethereum Foundation and ENS. It was built [in public](https://login.xyz/) over a number of months with the input of security experts, Ethereum community members, and Web3 projects. Spruce will continue to support their existing work on [numerous libraries for direct integration](https://docs.login.xyz/) and their OpenID Connect Identity Provider Server, which is also [open source](https://github.com/spruceid/siwe-oidc).

## What’s Next?

The Auth0 Lab team is deeply invested in exploring Web3 identity potential. You can follow our progress on [Twitter](https://twitter.com/auth0lab). If you’re interested in speaking with the team, join our discord and start a [thread](https://discord.gg/xkbkz9rZcD).

The Auth0 Lab team is working on demo features and apps that will show the potential of Web3 identity for Web2 and Web3 orgs alike. We look forward to sharing our experiments, working with you, learning from you, and building awesome things together.

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

Sign In With Ethereum (SIWE), Now Available on Auth0

Learn how to secure Blazor WebAssembly applications with Auth0.

Securing Blazor WebAssembly Apps

Learn how to build client-side Web apps using Blazor and how to secure them with Auth0.

What is Blazor? A Tutorial on Building Web Apps with Authentication

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

Managing Trial Periods with Auth0 Actions

william_johnson

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


Will Johnson

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

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

## What You Need

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

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

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

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


## Create a Slack Workspace

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

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

## Create a Slack Webhook

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Create Post User Registration Action

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

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

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

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

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

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

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

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

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

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

### Add webhook URL as a Secret

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

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

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

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

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

### Add npm package

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

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

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

### Write custom logic

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

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

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

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

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

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

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

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

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

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

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

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

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

Here is the complete code for the Action:

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

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

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

## Test the Action, Then Deploy It

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

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

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

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

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

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

## Add the Action to the Post User Registration Flow

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

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

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

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

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

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

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

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

## Conclusion

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

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

Send Slack Message After New User Sign Up with Auth0 Actions

vincenzo-chianese

Vincenzo Chianese is an Italian Software Developer focused on Web APIs and User Interfaces. He has been working for the last years in API companies such as Apiary, Oracle, LunchBadger, Stoplight. Currently, he is working for Microsoft to help move Microsoft Graph forward and authored some open-source tools in the market (Prism, Express Gateway).

API Architect

Vincenzo Chianese

Build your first web API in the functional programming world of Clojure with this step-by-step guide

## Introduction

This article will walk you through building a web API using Pedestal, a Clojure web framework. [Pedestal](http://pedestal.io/) is focused on APIs first and exemplifies the very best possibilities of Clojure's functional paradigm.

You'll put together a basic project with the necessary dependencies and serve up some basic information about superheroes. In a later article, we'll also secure the API using a collection of best practices and Auth0!

## Requirements

For this tutorial, you won't need much out of the box. Be sure you've:

1. Installed the [JDK](https://www.oracle.com/java/technologies/downloads/). This tutorial was written with the latest and greatest version of Java.
2. If you're on windows, set JAVA_HOME as an environment variable.
3. Wondered why JAVA_HOME isn't set by the JDK installation in 2021
4. Installed [Clojure](https://clojure.org/guides/getting_started)

Open up your command-line interface and check that you're good to go:

```bash
clj --version
 
Clojure CLI version 1.10.3.967
```

## Setup a New Clojure Project

>If you're brand new to Clojure, check out ["Why Developers Should Look into Clojure"](https://auth0.com/blog/why-developers-should-look-into-clojure/) first.

Clojure's ecosystem provides several build and dependency management tools. While [Leiningen](https://leiningen.org) and [Boot](https://github.com/boot-clj/boot/) provide this functionality and have been around a while, the Clojure team has provided the solution we'll be using for this article  [tools.deps](https://clojure.org/guides/deps_and_cli).

Skipping Leiningen reduces the number of things we need to install. **tools.deps** is included with the Clojure CLI and satisfies all of the requirements for this article, so you should be set.

Like `package.json` for Node, `pom.xml` for Maven projects, and `requirements.txt` in Python, Clojure's CLI uses a single file to manage its dependencies. Create a root folder (`clojure-pedestal`) for your project on your system and, in it, create a file called `deps.edn`.

`deps.edn` contains dependencies (for different environments, like development or production), additional commands/scripts, and much more. We'll keep it simple for now - but do know that EDN stands for ["Extensible Data Notation"](https://github.com/edn-format/edn) and is used across the Clojure universe.

### Add dependencies

For your Web API, you'll need to install a couple of Pedestal packages. In addition, we'll include some defacto-standard libraries for [logging](http://www.slf4j.org/) and accessing [environment variables](https://github.com/weavejester/environ). 

There's no "install dependency" command available in the Clojure CLI. Instead, we'll itemize what we need within `deps.edn`. When we invoke the Clojure CLI, it'll look into the file and download artifacts from our maven registry. You declare dependencies in the main hash-map, under the `:deps` keyword. Here's what your `deps.edn` should look like:

```clojure
{:paths ["src"]
:deps {io.pedestal/pedestal.service {:mvn/version "0.5.9"}
       io.pedestal/pedestal.route {:mvn/version "0.5.9"}
       io.pedestal/pedestal.immutant {:mvn/version "0.5.9"}
       org.slf4j/slf4j-simple {:mvn/version "1.7.32"}
       environ/environ {:mvn/version "1.2.0"}}}
```

### Add core.clj

Within your project folder, create two folders in sequence: `src` and `app`. Within `app`, add `core.clj`. your directory should look like this:

```
clojure-pedestal
|   deps.edn
|___src
    |
    |___app
        core.clj
```

>Because of how the JVM constructs the classpath, it is important that the namespace and the path of the file match. For instance, if we have a namespace called `app.core.models.user`, the file will have to be `src/app/core/models/users.clj`.

## Pedestal Fundamentals

### Hello world

Let's walk through the fundamental steps to have an HTTP Web API listening for requests and returning data.

In `core.clj`, declare a namespace called `app.core` and require some of the dependencies we're using. Avoid spending time understanding what we're using each dependency for; it will be more apparent once we write some code.

```clojure
(ns app.core (:require [io.pedestal.http :as http]
                       [environ.core :refer [env]]))
```

To create a functioning server, you'll need to:

* Define the **handler** for a specific route
* Define the **routes** and attach them to handlers
* Create a **service map** containing some configuration options
* Create a **server instance** and then run it

This is what some basic code to accomplish those goals should look like:

```clojure
(defn hello-world [_] {:status 200 :body "Hello"}) ; Route handler
 
(def service-map {::http/routes #{["/" :get hello-world :route-name :hello-world]} ; Routes
             ::http/type   :immutant
             ::http/host   "0.0.0.0"
             ::http/join?  false
             ::http/port   (Integer. (or (env :port) 5000))}) ; Service map
 
(defn -main [_] (-> service-map http/create-server http/start)) ; Server Instance

```

That's it! With just this code and our packages, we can now run the server and try it out. From your root directory, run:

```bash
clj -X app.core/-main
```

...and then you can use `curl` to test the Web API ...

```bash
curl http://localhost:5000
Hello
```

### Routing fundamentals

Next up is using Pedestal's intuitive routing features to return some data. We'll also filter and expand that data at different endpoints when necessary.

As you work through these instructions, start just under your namespace declaration.

Once again, in `core.clj`, define some static superhero data to play with:

```clojure
(def heroes [{:name "Clark" :surname "Kent"  :hero "Superman"}
             {:name "Bruce" :surname "Wayne"  :hero "Batman"}
             {:name "James" :surname "Logan"  :hero "Wolverine"}
             {:name "Steve" :surname "Rogers" :hero "Captain America"}
             {:name "Bruce" :surname "Banner" :hero "Hulk"}])
```

Then define two additional route functions besides your root "Hello World". They should:

1. Return all the superheroes we have defined
2. Return the hero matching the name provided as a route parameter
<br>

```clojure

(defn get-heroes [_] {:status 200 :body heroes})

(defn get-hero [{{:keys [hero]} :path-params
                {:keys [extended]} :query-params}]
 (if-let [hero (->> heroes
                    (filter #(= hero (:hero %)))
                    first)]
   {:status 200 :body (if extended hero (dissoc hero :hero))}
   {:status 404}))

```

Be sure to update your route map accordingly. While we're here, extract your routes to live outside of the API specification. That will keep our functions and definitions short:

```clojure

(def routes #{["/" :get hello-world :route-name :hello-world] ;Routes
              ["/heroes/:hero" :get get-hero :route-name :get-hero]
              ["/heroes" :get get-heroes :route-name :get-heroes]})

(def service-map
  {::http/routes routes
   ::http/type :immutant
   ::http/host "0.0.0.0"
   ::http/join? false
   ::http/port (Integer. (or (env :port) 5000))}) ; Service map

```

While Pedestal does a lot for us and the code above is simple, it's worth dissecting it to explain some of the Clojure features that keep code concise.

Each route in Pedestal is technically a specialized [Interceptor](http://pedestal.io/guides/what-is-an-interceptor). Interceptors are a common web framework concept used in things like Angular as well as Pedestal. Simply put, they let you layer functions to create a "pipeline" to handle web requests. We will return to the concept of interceptors later.

Pedestal routes take a [request map](http://pedestal.io/reference/request-map) and return a [response map](http://pedestal.io/reference/response-map) with the response details. 

```clojure
(defn hello-world [request] {:status 200 :body "Hello"})
```

The request map contains query parameters under the `:query-params` key and path parameters under the `path-params` key. Typically, to get the data we need from a map, we need to access them by keys. Here's what that would look like in our hello-world method, attached to our root route:

```clojure
(defn hello-world [request]
 (let [query-params (:query-params request)
       path-params (:path-params request)]) {:status 200 :body "Hello"})
```

From there, you could access the specified parameter with either a threading macro or using `get-in`...

```clojure
(defn hello-world [request]
 (let [extend (get-in request [:query-params :extended] )
       path-params (get-in request [:path-params :hero])]) {:status 200 :body "Hello"})
```

This method is legit — but it's a little wordy. To fix that, Clojure supports destructuring in binding statements. Destructuring is syntactic sugar that saves lines of code when accessing maps or sequential data structures.

Consider a nested map like this one:

```clojure
(def locations {:type "Office" :address {:street "Ocean Drive" :zip 90210 :city "Beverly Hills" }})
```

It is possible to destructure the map and access particular keys in several ways:

```clojure
; Destructuring in a let statement
(let [{:keys office} locations] (println office))
 
; Destructuring in a function
(defn print-office [{:keys office}] (println office))
 
; It also works in nested maps
(let [{{:keys [city]} :address} locations] (println city))
 
; Destructuring Sequential structures, like our superhero data
(defn simple-heroes  ["Clark" "Kent" "Superman"])
(let [[name surname hero]] (println name " - " surname " - " hero))
```

Destructuring has a lot of facets we cannot explore here, but the [official documentation](https://clojure.org/guides/destructuring) contains a detailed guide on how best to use this feature. However, with this crash course, we should now understand what's happening at the beginning of our function `get-hero`:

```clojure
(defn get-hero [{{:keys [hero]} :path-params
                {:keys [extended]} :query-params}] {})

(defn get-hero [{{:keys [hero]} :path-params
                {:keys [extended]} :query-params}]
                ;...
```

...which can be interpreted as saying: "From path params extract the hero key; from query, params extract the extended key."

In case you're thinking: "hey, that looks a bit like SQL query expressed as data structure" (I'm psychic) — you're onto something. Indeed, [Datalog](https://www.learndatalogtoday.org) is a query language that expresses queries as data. It's used by [Datomic](https://www.datomic.com), which we will explore in a future article.

As a counter-example where destructuring _might_ not make sense, take a look at the filter statement we are using to find the hero by name in `get-hero`:

```clojure
(filter #(= h (:hero %)))
```

With destructuring, you need to "fall back" to a regular fn definition instead of a "lambda". That means the code would look like this:

```clojure
(filter (fn [{:keys hero}] (= h hero)))
```

To destructure, we need to "fall back" to a regular fn definition instead of a "lambda". There's not a dramatic improvement in readability, so I suggest accessing the key explicitly.

### Serving Data

After applying the modifications above, our code should look like this:

```clojure
(ns app.core (:require [io.pedestal.http :as http]
                       [environ.core :refer [env]]))

(def heroes [{:name "Clark" :surname "Kent" :hero "Superman"}
             {:name "Bruce" :surname "Wayne" :hero "Batman"}
             {:name "James" :surname "Logan" :hero "Wolverine"}
             {:name "Steve" :surname "Rogers" :hero "Captain America"}
             {:name "Bruce" :surname "Banner" :hero "Hulk"}])

(defn hello-world [request]
  (let [extend (get-in request [:query-params :extended])
        path-params (get-in request [:path-params :hero])]) {})

(defn get-hero [{{:keys [hero]} :path-params
                 {:keys [extended]} :query-params}]
  (if-let [hero (->> heroes
                     (filter #(= hero (:hero %)))
                     first)]
    {:status 200 :body (if extended hero (dissoc hero :hero))}
    {:status 404}))

(defn get-heroes [_] {:status 200 :body heroes})

(def routes #{["/" :get hello-world :route-name :hello-world]
              ["/heroes/:hero" :get get-hero :route-name :get-hero]
              ["/heroes" :get get-heroes :route-name :get-heroes]})

(def service-map
  {::http/routes routes
   ::http/type :immutant
   ::http/host "0.0.0.0"
   ::http/join? false
   ::http/port (Integer. (or (env :port) 5000))}) ; Service map

(defn -main [_] (-> service-map http/create-server http/start)) ; Server Instance
```

If we start the server again now and try to get some data, we should now be able to get results and test out our new endpoints:

```bash
curl http://localhost:5000/heroes
[{:name "Clark", :surname "Kent", :hero "Superman"} {:name "Bruce", :surname "Wayne", :hero "Batman"} {:name "James", :surname "Logan", :hero "Wolverine"} {:name "Steve", :surname "Rogers", :hero "Captain America"} {:name "Bruce", :surname "Banner", :hero "Hulk"}]
 
curl http://localhost:5000/heroes/Superman
{:name "Clark", :surname "Kent"}
 
curl "http://localhost:5000/heroes/Superman?extended=1"
{:name "Clark", :surname "Kent", :hero "Superman"}
```

You can indeed see the API is behaving as you'd expect. However, this response isn't JSON - which you can see from the syntax or by looking at the response details via `curl -v`:

```bash
$ curl localhost:5000/heroes/Superman -v
...
> Content-Type: application/edn
```

[EDN](https://github.com/edn-format/edn) is arguably a better format than JSON for several reasons, especially if you're using  [ClojureScript](https://clojurescript.org).  However, the lingua franca of publicly exposed APIs and JavaScript applications is JSON. For this reason, you're going to modify our application to return data in JSON by default. 

To do so, you need to modify our Service Map (where we specify our options) and add a new interceptor that will serialize the body to be JSON whenever it makes sense. The good news is that Pedestal provides an interceptor out of the box we can use.

Our code's `http/create-server` function will look for the `::http/interceptors` key in the service map. If it does not exist there, it will automatically use some [default interceptors](http://pedestal.io/reference/default-interceptors) that perform a series of common tasks. Since we need to add a new interceptor, we're going to need to update the interceptor chain by hand:

```clojure
(def service-map (-> {::http/routes routes
                     ::http/type   :immutant
                     ::http/host   "0.0.0.0"
                     ::http/join?  false
                     ::http/port   (Integer. (or (env :port) 5000))}
                http/default-interceptors
                (update ::http/interceptors into [http/json-body])))
```

Here we:

- Define the `service` with the routes and other keys
- Pass the map to the `http/default-interceptors` function that will return a new service map with the `::http/interceptors` key
- Add the `json-body` interceptor to the chain to serialize the data as JSON when appropriate.

If we try to request the same data again using `curl` we can see now that the response is JSON encoded:

```bash
curl http://localhost:5000/heroes/Superman
{"name":"Clark","surname":"Kent"}
```

You could apply the exact same approach to incoming body parameters if you had a route that used them. I won't dive deeply here, but the installation method for the [body-params](https://github.com/pedestal/pedestal/blob/master/service/src/io/pedestal/http/body_params.clj#L178) interceptor is the same as other interceptors.

We've completed a significant milestone with us returning data in the format most people expect when interacting with a Web API! But we're not done. Any Web API worth its salt should be well protected. You'll use Auth0 and some custom interceptors to accomplish that in my next article.

Create an API server with Clojure and Pedestal

Learn how to use Auth0 Actions to redirect users to an announcement web page and back to the application (or just redirect them to Rick Astley’s video).

Use Actions to Show Users an Announcement after Logging in (Or Rickroll Them)

bruno-krebs

I am passionate about developing highly scalable, resilient applications. I love everything from the database, to microservices (Kubernetes, Docker, etc), to the frontend. I find amazing to think about how all pieces work together to provide a fast and pleasurable experience to end users, mainly because they have no clue how complex that "simple" app is.

R&D Content Architect

Bruno Krebs

Supporting Sign in with Apple on iOS and web apps can be an easy task if you use the right tools.

How to Implement Sign in with Apple Easily on iOS Apps

Image from iOS

Weiyu Fang is a Software Engineer at Datawiza. His expertise includes OIDC/OAuth, SAML, DevOps, Web and API development. Skilled in Golang, Python, Java and Linux.

Software Engineer at Datawiza

Weiyu Fang

Learn how to integrate a Java web application with Auth0 and implement OIDC/OAuth SSO for a Java

In this step-by-step tutorial, you will learn how to integrate a Java web application with Auth0 using Datawiza to implement OIDC/OAuth SSO for the Java web application.

## Prerequisites

*   A favorite text editor or IDE
*   [JDK 1.8](http://www.oracle.com/technetwork/java/javase/downloads/index.html) or later
*   [Gradle 4+](http://www.gradle.org/downloads) or [Maven 3.2+](https://maven.apache.org/download.cgi)
*   [Docker](https://docs.docker.com/get-docker/) (18.03+)
*   [Docker Compose](https://docs.docker.com/compose/install/)

## Run a Java Web Application

We use the sample offered in [Spring.io official Building an Application with Spring Boot](https://spring.io/guides/gs/spring-boot/#initial) as the example in this section. The application running at port 8080 simply returns “Greetings from Spring Boot!”

![Java Web Application](https://images.ctfassets.net/23aumh6u8s0i/4XcFQXlX8odLIEORRMXePX/e4857dbc14b281600d7016416cb2de77/java_01.png)

Suppose you want to add SSO authentication for a Java web application using Auth0. In that case, Auth0 provides quickstarts on adding the user login to [a Java EE web application](https://auth0.com/docs/quickstart/webapp/java-ee) or [a Java Servlet application](https://auth0.com/docs/quickstart/webapp/java) and integrating Auth0 with any new or existing Spring Boot 2 web application. What’s more, there is [an official Java client library for the Auth0 platform](https://github.com/auth0/auth0-java) and [a Java implementation of JSON Web Token (JWT)](https://github.com/auth0/java-jwt). However, you will still need to invest significant time to clearly understand concepts related to Auth0, OIDC, Oauth2, JWT, and so on. And you cannot avoid heavy code changes. You deserve a better solution, and we are building one that will reduce the required time from weeks to just minutes.

## Introduction to the Datawiza Platform

The Datawiza Platform is a cloud-delivered, [SaaS-based access management solution](https://www.datawiza.com/blogs/why-access-management-as-a-service-amaas-why-now). It includes a data plane and a control plane: Datawiza Access Broker (DAB) and Datawiza Cloud Management Console (DCMC).

**DAB** is a lightweight, container-based access proxy deployed close to your application via the sidecar (agent) or gateway mode. It talks to Auth0 on behalf of your applications, so you don’t need to worry about the integration work. **DCMC** is a cloud-based management console where you can configure and manage the policies of DABs. Such a SaaS-based design makes the whole platform much easier to use.

## Step 1: Create an Application in Auth0

First, we need to create an [Auth0 application](https://auth0.com/docs/applications) in the [Auth0 console](https://manage.auth0.com/dashboard). When performing this step, make sure to log in to your account on Auth0. Visit the link [here](https://auth0.com/) to create a developer account.

You can skip this step if you already have an application with the following values: Domain, Client ID, and Client Secret.

Create an application after you log in to Auth0.

![Auth0](https://images.ctfassets.net/23aumh6u8s0i/5KPM1zIMEVCS02gsenU3AQ/48ba320672eb660458c28ffcc6600578/java_02.png)

Enter the application name and choose **Regular Web Applications**, then click **CREATE**.

![Web Applications](https://images.ctfassets.net/23aumh6u8s0i/36tWZTXSdPv0B4aDfeXqnv/3de24e44791a7abd6a3499f284679786/Uploaded_from_How_to_Add_Auth0_Authentication_to_Java_Application_in_5_Mins)


Select the **Settings** tab and fill out the form. Follow the steps below:

*   **Allowed Callback URLs**: e.g., http://localhost:9772/authorization-code/callback
*   **Allowed Logout URLs**: e.g., http://localhost:9772
*   Use the default settings for the remaining fields

Then click **SAVE CHANGES.**

![Settings](https://images.ctfassets.net/23aumh6u8s0i/7BslNzTcUIOHNTBjtcscMd/c5f92a9e9e2f246a07eb2fbe2d4bae6e/java_03.png)

On the same page, be sure to save a copy of **Domain**, **Client ID,** and **Client Secret**. You will need these values later when establishing the connection.

![Domain](https://images.ctfassets.net/23aumh6u8s0i/12JKUSCw0J4xGMFZHEFWM4/d3b70060bdb20ce32290cf0a8088281a/java_04.png)

Choose Users under the **Users & Roles** Tab and create a test user.

![Users & Roles](https://images.ctfassets.net/23aumh6u8s0i/2L6ryltJG4griEOuFLlzUJ/65aad91e89a23cc2309381b7ec5a0702/java_05.png)

![Users & Roles](https://images.ctfassets.net/23aumh6u8s0i/57E0DP3e3qZEhzTYkO8Prj/5b1093bd7494bebae007ff643c946f9a/Uploaded_from_How_to_Add_Auth0_Authentication_to_Java_Application_in_5_Mins)

You have now registered a web application on Auth0. Next, you will create a simple configuration in the DCMC.

## Step 2: Configurations in Datawiza Cloud Management Console

Then, log in to the [Datawiza Cloud Management Console (DCMC)](https://console.datawiza.com/). If you do not have a DCMC account, you can create one by email from the DCMC login page. Also, we provide social login and SSO functionality with Microsoft, GitHub, and Google to simplify logins for you.

The **Get started** function will guide you through the configuration. After logging in to the DCMC, click on the yellow “Get started” button and follow the steps.

![Get started](https://images.ctfassets.net/23aumh6u8s0i/1qnlBAo4ObfXE6kOPNEExN/3ac984608b96227445f338b5fbf90cfd/Uploaded_from_How_to_Add_Auth0_Authentication_to_Java_Application_in_5_Mins)

Enter some basic information, such as the deployment name and provisioning key name:

![Information](https://images.ctfassets.net/23aumh6u8s0i/3QrulTuioxuOFocdMZz0HN/abc2a1ee268182235313546f04127c1c/java_06.png)

![Information](https://images.ctfassets.net/23aumh6u8s0i/3MZTaEuTTgp90bZ7rnugK5/87494ca141c7507833b8bbcdd367d6a5/java_07.png)

Now **Add an Application**:

![Add an Application](https://images.ctfassets.net/23aumh6u8s0i/2FHLJeyXB9W9MDLaKEK1YC/fe5ca0c3fcb584b4a211ccb358f4e3f7/java_08.png)

Configure your application with the following values:

*   **Platform**: _Web_
*   **App Name**: _Demo App_
*   **Public Domain**: _http://localhost:9772_
*   **Listen Port**: _9772_
*   **Upstream Servers**: _http://host.docker.internal:8080_
*   **Default Action**: _Allow_

Note that **Upstream Servers** is the address of the Java application.

*   If you use Mac or Windows, then set the Upstream Servers to _http://host.docker.internal:8080_ (requires Docker 18.03+).
*   If you use Linux, use _ip addr show docker0_ to get the docker host IP (e.g., 172.17.0.1) and then set Upstream Servers to http://172.17.0.1:8080 (see [this](https://stackoverflow.com/questions/24319662/from-inside-of-a-docker-container-how-do-i-connect-to-the-localhost-of-the-mach) for more details).

Next **Configure the IdP**:

![Configure the IdP](https://images.ctfassets.net/23aumh6u8s0i/3NJsB2nqQyhVWaFcRwDv1h/04db1d78ff8749138eb4d3d7b21dda3d/java_09.png)

Select **OIDC** as the Protocol and **Auth0** as the Identity Provider. Input the **Domain**, **Client ID,** and the **Client Secret** you saved when creating the app in Auth0. Then click **Create**.

In the last step, we will provide the command lines to pull the DAB image and the docker-compose file to run the DAB.

Execute the command lines in steps 1 & 2 and note down the docker-compose file in step 3.

![Add Auth0 Authentication](https://images.ctfassets.net/23aumh6u8s0i/6VDmHW6PtR3WzOyNcdysD5/292d99c072ab54d0927a4b07b829a764/java_10.jpg)

## Step 3: Run DAB as a Sidecar (Agent) to Your Application

After finishing the configuration in DCMC, you can run the DAB with the YAML file noted in the previous step. The docker-compose YAML file, named _datawiza-access-broker.yaml_ should then appear like this:

```
version: '3'  
services:  
datawiza-access-broker:  
image: registry.gitlab.com/datawiza/access-broker  
container\_name: datawiza-access-broker  
restart: always  
ports:  
- "9772:9772"  
environment:  
PROVISIONING\_KEY: #############################  
PROVISIONING\_SECRET: #############################
```

Now, we can use docker-compose to create and start the DAB:

```
docker-compose -f datawiza-access-broker.yaml up -d
```

That's it. After executing the command above, the Node.js application should have SSO enabled with Auth0.

Now, let's give it a try.

Open a browser and type in **http://localhost:9772**. You should see the Auth0 login page as follows:

![Auth0 login](https://images.ctfassets.net/23aumh6u8s0i/7vZUQEx0L1ahWKl3DSB5le/42b46194e44dec3c510900bce5f8a0ba/Uploaded_from_How_to_Add_Auth0_Authentication_to_Java_Application_in_5_Mins)

After logging in to Auth0, the Java web application will be shown.

![Auth0](https://images.ctfassets.net/23aumh6u8s0i/1xKW0FnBZnh3QMK5d3MiLB/443be2a918e0f2d08f9b3f7d9c7c8884/java_11.png)

## Summary

Congratulations! You secured a Java web application by adding Auth0 authentication using Datawiza -- in minutes instead of weeks or months. This is only a small sampling of what Datawiza can do. See [Datawiza’s online docs](https://docs.datawiza.com) or [official website](https://datawiza.com) for much more information.

How to Add Auth0 Authentication to a Java Application in 5 Mins


Learn more about how we can secure our Clojure Web API using Auth0

In my [previous article](https://auth0.com/blog/create-an-api-server-with-clojure-and-pedestal/), we built a simple Web API in Clojure with the Pedastal framework. We covered some core concepts essential to know for writing Clojure and serving data on the web.

It was a great start! But the very next thing we should consider when building a Web API is making sure that it's secured. 

## Requirements

Of course, you'll want the source code that we ended up with at the close of the previous article. You'll also need to sign up for a free Auth0 account. You won't need a credit card, and this will be the simplest way for us to add basic Authentication.
 
### Interceptors explained
 
We have already used Interceptors while building our application. From our previous article:

> Simply put, they let you layer functions to create a "pipeline" to handle web requests.

They can also be used for responses, as we've seen with our JSON serialization example above.
 
### Building a base interceptor
 
In Pedestal, an interceptor is nothing more than a map with a `:name` along with `:enter`,  `:leave`, and `:error` keys. The name is (you guessed it) the name, while the last three items represent optional keys that receive a [context map](http://pedestal.io/reference/context-map) as an argument. Each of these keys is executed when the request is coming in when the response is being sent, and if an error happens along the way. You'll need to include at least one of these functions for this to count as an interceptor!
 
For instance, let's say we want to create an interceptor that inserts a specific response header for every response we send. To accomplish this, all we need to do is create a map with a function on the `:leave` keyword and associate the header:
 
```clojure
(def header-interceptor {
 :name "header-interceptor"
 :leave (fn [ctx] (assoc-in ctx [:response :headers "AppName"] "Pedestal-Auth0-App"))})
```
 
Pedestal also offers helpers to write a specific type of interceptor without having to specify the entire map. Here's that same function using these helpers:
 
```clojure
(require 'io.pedestal.interceptors.helpers :as helpers)
 
(def header-interceptor (helpers/on-response (fn [response] (assoc-in response [:headers "AppName"] "Pedestal-Auth0-App"))))
```
 
Armed with a basic understanding of interceptors in Pedastal, we can now set up an Auth0 account and then write our interceptor to validate any tokens provided in a request.
 
## Validating a Token

In an OAuth-compliant application, Identity providers must provide information to validate JWT tokens that they issue. Many frameworks and languages create black boxes where you provide some configuration parameters, and they do the rest. We're going to go into a bit more detail in this application. Here are some basic concepts to understand:

### JSON Web Tokens
Most documentation sources and developers shorten JSON Web Tokens to just JWT. JWTs are essentially long strings that encode JSON, and are frequently used for Authentication and Authorization. Identity providers issue JWTs and include information relevant to the apps that use them, such as your name, email address, or permissions for that app. If you're unfamiliar with JWTs I highly suggest [Auth0's documentation](https://auth0.com/docs/security/tokens/json-web-tokens) on the matter. When issued by an Identity provider, they're often signed so that you can know they're authentic, which leads us to...

### JSON Web Key Set
JSON Web Key Set's acronym is JWKS. We'll use the acronym for the remainder of this article. This key set contains the *public* keys that say, "Yeah, I made that token." The Identity provider has used a separate and private cryptographic key to construct the token. This process that allows for a public verification key and a private construction key is called asymmetric encryption. 

We'll need to retrieve the location of the JSON Web Key set for our Identity provider when we create a new Application in the Auth0 portal so we can verify JWTs. You can read a bit more about the concept in the [Auth0 documentation](https://auth0.com/docs/security/tokens/json-web-tokens/json-web-key-sets). 

### Create a new Auth0 application

Before writing the code to validate a token issued by an identity provider effectively, let's quickly review a couple of steps necessary to set up Auth0.
 
Once we've logged in, select Applications -> APIs from the left menu and create a new API. For demo purposes, we can just put a random name and an identifier. In my case, I am going to be using `clojure-pedestal` for both.

![Creating a new API in Auth0](https://images.ctfassets.net/23aumh6u8s0i/3IGLaJE64V2cWe3X4tahSX/70f98430ee2beab09b258e52f6ad5006/clojure_04.png)

When confirming the operation, Auth0 will also create a default Test application for the new API. Click on Applications -> Applications on the left menu to review the application's details. From the **Settings** tab, we will need to grab the domain. This is the base URL we'll need to determine a JWKS location.

![The Application settings we'll need to configure in Clojure](https://images.ctfassets.net/23aumh6u8s0i/7qAlQDPvlD9qLqx4k2cznV/bb18a3cbaaef5e58d31524cd5d8eadf0/clojure_05.png)

In this example, since my domain is https://dev-q6rh8--8.us.auth0.com/, my JWKS URL will be https://dev-q6rh8--8.us.auth0.com/.well-known/jwks.json

### Set up the authorization interceptor in Pedestal
 
Auth0 offers several Java libraries to work with JWT and JWK. Since Clojure has a good interoperability story with Java, we can use these libraries to write our interceptor.
 
If you've been writing Clojure for a little bit this should be simple. We will take it easy for this article and use a third-party Clojure library that will do most of the work. If you're curious/eager to see what using the Auth0 Java libraries would look like, you can take a look at the reference implementation that accomplishes the same thing at the end of this article.
 
The first thing we're going to do is to add a library providing the helpers we need to decode and verify the JWT in `deps.edn`:
 
```diff
{:paths ["src"]
:deps {io.pedestal/pedestal.service {:mvn/version "0.5.9"}
       io.pedestal/pedestal.route {:mvn/version "0.5.9"}
       io.pedestal/pedestal.immutant {:mvn/version "0.5.9"}
       org.slf4j/slf4j-simple {:mvn/version "1.7.32"}
-        environ/environ {:mvn/version "1.2.0"}}}
+        environ/environ {:mvn/version "1.2.0"}
+        no.nsd/clj-jwt {:git/url "https://gitlab.nsd.no/clojure/clj-jwt.git" :git/sha "bc23acb3c7cbf0d2def2d395c3e3d9c405be28d5"}}}
```
 
We can see that the `clj-jwt` has been imported from the repository directly instead of the Maven Central registry. This is a legitimate use case, and it works out of the box with `tools.deps`.

Let's now create a new file `src/app/jwt.clj`, and use the following code:
 
```clojure
(ns app.jwt (:require [no.nsd.clj-jwt :as clj-jwt]
                      [io.pedestal.interceptor.helpers :as interceptor]))
 
(defn- unauthorized [text]
 {:status  401
  :headers {}
  :body    text}) ; Helper to return a 401 status code
 
(defn decode-jwt [{:keys [required? jwk-endpoint]}]
 (interceptor/before
  ::decode-jwt
  (fn [ctx] (if-let [auth-header (get-in ctx [:request :headers "authorization"])]
              (try (->> auth-header
                        (clj-jwt/unsign jwk-endpoint)
                        (assoc-in ctx [:request :claims]))
 
                   (catch Exception _
                     (assoc ctx :response (unauthorized "The token provided is not valid"))))
 
              (if required? (assoc ctx :response (unauthorized "Token not provided"))
                  (assoc-in ctx [:request :claims] {}))))))
```
 
We can now import and apply our interceptor in our web application by updating core.clj:
 
```clojure
(ns app.core (:require [io.pedestal.http :as http]
                       [io.pedestal.interceptor.helpers :as helpers]
                       [app.jwt :refer [decode-jwt]] ;Add the reference to the new class
                       [environ.core :refer [env]]))
                       
...

(def jwk-endpoint "https://application-name.us.auth0.com/.well-known/jwks.json")
 
(def service-map (-> {::http/routes routes
                     ::http/type   :immutant
                     ::http/host   "0.0.0.0"
                     ::http/join?  false
                     ::http/port   (Integer. (or (env :port) 5000))}
                http/default-interceptors
                (update ::http/interceptors into [http/json-body
                                                  (decode-jwt {:required? true
                                                               :jwk-endpoint jwk-endpoint})])))
 
```
 
And now we can try to send some requests. To obtain a valid JWT token, we would theoretically have to complete an oAuth2 flow. For testing purposes, Auth0's UI offers a token for your current username that you can grab directly from the "Test" tab of the API:

![Getting test information from the Auth0 Portal](https://images.ctfassets.net/23aumh6u8s0i/5JO6ewpLrkkRItejcsrevD/af2f21dd6118f8d561f9f1255943ae31/clojure_06.png)

Now, let's send three requests to our API:

1. One with that JWT added correctly to the headers
2. One with an invalid JWT added to the headers
3. One with no JWT or additional headers at all

The first should be successful, with the remainder being rebuffed with a 401 HTTP status code by our new interceptor.
 
```bash
curl http://localhost:5000/ --header 'authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ikhsb2NuQ1ZiRFRzdjVMTEs5d2RpeiJ9.eyJpc3MiOiJodHRwczovL3ZuY3oudXMuYXV0aDAuY29tLyIsInN1YiI6IldJeVUybTdZY3BWMHlCeU52dVNHSGpWUEEzYXFRbnA5QGNsaWVudHMiLCJhdWQiOiIvZGV2L251bGwiLCJpYXQiOjE2MzE4Mjk3NTQsImV4cCI6MTYzMTkxNjE1NCwiYXpwIjoiV0l5VTJtN1ljcFYweUJ5TnZ1U0dIalZQQTNhcVFucDkiLCJndHkiOiJjbGllbnQtY3JlZGVudGlhbHMifQ.tvzoDnqE5GWfqUKl0XbFtJBv_E3704qDoMOb9YheRj-409ntIcLs02UKVbR1g28-fDEPcQ-IxGRTBcOPEYy7X0HB-IByPCDink_Kj-hJ5O_2ft9I_lYZFOmeRL7TqD3TF9S17hta5UAFEj9zxQ_c_gcI7VY0F3t7iMfe3pNu9ut1l9-iYqjJ_BNCf-pxfQpWqnfQCnjU1qStGHPRmaK1dzXFIdXnH8S0rixcsuaxt5sbFivCIuQTNZ8QxvsW-vJekW1T2IkFOlGRWWWUoKTW2j4PnFlMWnCm7O91xR0zEaAHdQkmAob323qJf9IgucGxD3emX1k_ugLHdfnpvELaEQ'
< HTTP/1.1 200 OK
 
curl http://localhost:5000/ --header 'authorization: Bearer thisIsInvalid'
< HTTP/1.1 401 Unauthorized
 
curl http://localhost:5000/
< HTTP/1.1 401 Unauthorized
```
 
Our interceptor is now checking out all the requests and ensuring a valid token is included before moving on.
 
To give more detail about how JWTs work, we can also create a new route to return the claims encoded in the token to the sender. Update core.clj again:
 
```clojure
…
…
(defn get-claims [req] {:status 200 :body (:claims req)}) ; Add a new route returning the claims on the request object
 
(def routes #{["/heroes/:hero" :get get-hero :route-name :get-hero]
             ["/heroes" :get get-heroes :route-name :get-heroes]
             ["/claims" :get get-claims :route-name :get-claims]
             ["/" :get hello-world :route-name :hello-world]})
```
 
```bash
curl http://localhost:5000/claims --header 'authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ikhsb2NuQ1ZiRFRzdjVMTEs5d2RpeiJ9.eyJpc3MiOiJodHRwczovL3ZuY3oudXMuYXV0aDAuY29tLyIsInN1YiI6IldJeVUybTdZY3BWMHlCeU52dVNHSGpWUEEzYXFRbnA5QGNsaWVudHMiLCJhdWQiOiIvZGV2L251bGwiLCJpYXQiOjE2MzE4Mjk3NTQsImV4cCI6MTYzMTkxNjE1NCwiYXpwIjoiV0l5VTJtN1ljcFYweUJ5TnZ1U0dIalZQQTNhcVFucDkiLCJndHkiOiJjbGllbnQtY3JlZGVudGlhbHMifQ.tvzoDnqE5GWfqUKl0XbFtJBv_E3704qDoMOb9YheRj-409ntIcLs02UKVbR1g28-fDEPcQ-IxGRTBcOPEYy7X0HB-IByPCDink_Kj-hJ5O_2ft9I_lYZFOmeRL7TqD3TF9S17hta5UAFEj9zxQ_c_gcI7VY0F3t7iMfe3pNu9ut1l9-iYqjJ_BNCf-pxfQpWqnfQCnjU1qStGHPRmaK1dzXFIdXnH8S0rixcsuaxt5sbFivCIuQTNZ8QxvsW-vJekW1T2IkFOlGRWWWUoKTW2j4PnFlMWnCm7O91xR0zEaAHdQkmAob323qJf9IgucGxD3emX1k_ugLHdfnpvELaEQ' -v
< HTTP/1.1 200 OK
< Content-Type: application/json;charset=UTF-8
 
{"iss":"https://dev-q6rh8--8.us.auth0.com/","sub":"WIyU2m7YcpV0yByNvuSGHjVPA3aqQnp9@clients","aud":"clojure-pedestal","iat":1631829754,"exp":1631916154,"azp":"WIyU2m7YcpV0yByNvuSGHjVPA3aqQnp9","gty":"client-credentials"}
```
 
## Conclusions

Building your own Authentication handler isn't an everyday activity in modern web development. Many devs will go their entire career without having to configure JWKS URLs or decoding claims in a token - instead, they'll plug in a library with nice documentation and hope that it works. 

Clojure and Pedastal let you take a much better look under the hood at this essential process. Even better, the language and framework make this process incredibly easy to show in a tiny Web API project.

To get more information about Pedestal, its roadmap, and documentation, you can refer to the [official website](http://pedestal.io).

We'll try to see something more complicated in the next installment, such as database interactions with [Datomic](https://datomic.com)
 
### Using Auth0 Java Libraries
 
For reference, this is what implementing the same JWT decoder/verifier would look like using the official Auth0 SDK.
 
```clojure
(ns app.auth
 (:require [cheshire.core :as json]
           [io.pedestal.interceptor.helpers :as interceptor])
 (:import (java.net URL)
          (com.auth0.jwt JWT)
          (com.auth0.jwt.exceptions SignatureVerificationException AlgorithmMismatchException TokenExpiredException JWTVerificationException JWTDecodeException)
          (com.auth0.jwt.algorithms Algorithm)
          (com.auth0.jwk UrlJwkProvider)
          (com.auth0.jwt.interfaces RSAKeyProvider)
          (org.apache.commons.codec Charsets)
          (org.apache.commons.codec.binary Base64)))
 
(defn- new-jwk-provider
 [url]
 (-> (URL. url)
     UrlJwkProvider.))
 
(def ^{:private true} rsa-key-provider
 (memoize
  (fn [url]
    (let [jwk-provider (new-jwk-provider url)]
      (reify RSAKeyProvider
        (getPublicKeyById [_ key-id]
          (-> (.get jwk-provider key-id)
              (.getPublicKey)))
        (getPrivateKey [_] nil)
        (getPrivateKeyId [_] nil))))))
 
(defn- base64->map
 [base64-str]
 (-> base64-str
     Base64/decodeBase64
     (String. Charsets/UTF_8)
     json/parse-string))
 
(defn- decode-token
 [algorithm token {:keys [issuer leeway-seconds]}]
 (let [add-issuer #(if issuer
                     (.withIssuer % (into-array String [issuer]))
                     %)]
   (-> algorithm
       (JWT/require)
       (.acceptLeeway (or leeway-seconds 0))
       add-issuer
       .build
       (.verify token)
       .getPayload
       base64->map)))
 
(defn- decode [token {:keys [jwk-endpoint] :as opts}]
 (-> (Algorithm/RSA256 (rsa-key-provider jwk-endpoint))
     (decode-token token opts)))
 
(defn- find-token [{:keys [headers]}]
 (some->> headers
          (filter #(.equalsIgnoreCase "authorization" (key %)))
          first
          val
          (re-find #"(?i)^Bearer (.+)$")
          last))
 
(defn- unauthorized [text]
 {:status  401
  :headers {}
  :body    text})
 
(defn decode-jwt [{:keys [required?] :as opts}]
 (interceptor/before
  ::decode-jwt
  (fn [ctx]
    (try
      (if-let [token (find-token (:request ctx))]
        (->> (decode token opts)
             (assoc-in ctx [:request :claims]))
        (if required? (assoc ctx :response (unauthorized "Token not provided"))
            (assoc-in ctx [:request :claims] {})))
 
      (catch JWTDecodeException _
        (assoc ctx :response (unauthorized "The token provided is not valid")))
 
      (catch SignatureVerificationException _
        (assoc ctx :response (unauthorized "Signature could not be verified")))
 
      (catch AlgorithmMismatchException _
        (assoc ctx :response (unauthorized "Algorithm verification problem")))
 
      (catch TokenExpiredException _
        (assoc ctx :response (unauthorized "Token has expired")))
 
      (catch JWTVerificationException _
        (assoc ctx :response (unauthorized "Invalid claims")))))))
```


Secure a Clojure Web API with Auth0

What is the best way to apply Role-Based Access Control (RBAC) to your ASP.NET Web API? Let's find out together.

Role-Based Authorization for ASP.NET Web APIs

Learn how to build a CRUD Web API with ASP.NET through this practical tutorial.

Building ASP.NET CRUD Web APIs

Checking user permissions allows you to have more control over access to your ASP.NET Web API.

Protecting a Web API from unauthorized users is the first step to get control over who can access it. However, simply excluding anonymous users may be insufficient in some situations. You may need to control over who can do what on your application. This article will show you how to define and check permissions for users accessing your ASP.NET Web API secured with Auth0.

## The Need for Permissions

A previous article introduced [how to enable authorization for ASP.NET Web APIs](https://auth0.com/blog/aspnet-web-api-authorization/). The sample application accompanying that article is an ASP.NET Web API that implements the CRUD (*Create*, *Retrieve*, *Update*, *Delete*) operations over a glossary of terms. That article explains how to protect the Web API by using Auth0 so that only authorized users can create, modify, and delete glossary items. Everyone can still get the list of terms or a single glossary item.

That worked pretty well! However, you may need more granular control over the users who can do specific operations. For example, you may want to give some users the ability to add a new glossary term or modify an existing one, but you don't want them to delete items. Only specific users should be able also to delete items. To achieve this control level, you must deal with permissions.

In the security context, a **permission** is a property of a resource that indicates the operation a user can do on it, like, for example, read, write, print, send, etc. In the case of your sample application, you have the glossary and term resources. Regarding the former, you can get the list of terms and add new items. Regarding the latter, you can read, update, or delete it.

<details>
  <summary>Permissions vs. privileges</summary>
Usually, permissions and privileges are used interchangeably, but technically they have precise and different meanings in the context of computer security.


A **permission** is an action that can be performed on a resource. It is somehow bounded to the resource, and you can consider it as a resource property.

A **privilege** is a permission assigned to a user or an application. When you assign the writing permission to a user, you are granting them a privilege.
</details>

## Setting up the Web API Application

The goal of this article is to show you how to implement permission-based authorization in this sample application. 

> Make sure you have [the latest .NET SDK](https://dotnet.microsoft.com/download/dotnet/current) already installed on your machine to run the sample ASP.NET application.

So, let's start by downloading the source code with the following command:

```bash
git clone --branch add-authorization --single-branch https://github.com/auth0-blog/glossary-web-api-aspnet.git
```

Once you download the application, register it with Auth0 in order to enable support for the authorization service. If you haven't an Auth0 account, you can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free one</a>. Follow the [instructions in this article to register the application with Auth0](https://auth0.com/blog/aspnet-web-api-authorization/#Registering-the-Web-API-with-Auth0).

After you completed the registration, move to the `glossary-web-api-aspnet` folder and open the `appsettings.json` configuration file. Its content looks as follows:

```json
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "Auth0": {
    "Domain": "YOUR_AUTH0_DOMAIN",
    "Audience": "YOUR_UNIQUE_IDENTIFIER"
  }
}
```

Replace the `YOUR_AUTH0_DOMAIN` placeholder with your Auth0 domain and the `YOUR_UNIQUE_IDENTIFIER` placeholder with the value you provided as a unique identifier of your API (`https://glossary.com`, if you kept the value suggested in [the mentioned article](https://auth0.com/blog/aspnet-web-api-authorization/#Registering-the-Web-API-with-Auth0)).

> Note: Your Auth0 domain is a string in the form `YOUR-TENANT-NAME.auth0.com` where `YOUR-TENANT-NAME` is the name you provided when you created your account with Auth0. For more information, [check the documentation](https://auth0.com/docs/getting-started/the-basics#domains).

Now, launch the ASP.NET Web API application by typing `dotnet run` in a terminal window. By pointing your browser to `https://localhost:5001/swagger`, you should see the [Swagger UI](https://swagger.io/tools/swagger-ui/) shown below to test the API interactively:

![Protected Web APIs in Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/1rNBChKdbCr9fKdpbbYcKR/014f6ace0411febc726959cd88ed8e6a/protected-swagger-ui-webapi.png)

To call the `POST`, `PUT`, and `DELETE` actions, [you need an access token, as explained in this section](https://auth0.com/blog/aspnet-web-api-authorization/#Testing-the-Secure-Web-API).

Now you are ready to set up permissions on your Web API.

## Defining Permissions for an API

The first step is to define the permissions for your application. These permissions can vary depending on the needs of your application. In the glossary Web API application, we are going to define the permissions identified by the following strings:

- `create:term`. This permission allows you to add a new term to the glossary.
- `update:term`. With this permission, you can update an existing term.
- `delete:term`. This permission allows you to delete a term from the glossary.

To associate these permissions with your API, go to the [API section](https://manage.auth0.com/#/apis) of your Auth0 Dashboard and select the API you defined for the glossary application. Then select the *Permissions* tab. Here you can add the permissions with their descriptions as defined above. At the end of this process, that page will look like the following:

![Defining permissions in the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/52FOUrB7EcV17WYLSjdbDS/19d1360d9def0ea77cc550ba664a7748/defining-permissions-auth0-dashboard.png.png)

This configuration informs Auth0 that the glossary Web API supports only these permissions.

Next, move to the *Settings* tab and scroll down to the *RBAC Settings* section. Here, click both the *Enable RBAC* and the *Add Permissions in the Access Token* toggle buttons, as in the following picture, and don't forget to click the *Save* button at the end:

![](https://images.ctfassets.net/23aumh6u8s0i/49AQnZIW5pP4wBIHA4sV9i/2c476e2508ff68fde80061b6973016ca/enabling-rbac.png)

These settings will enforce the evaluation  of roles and permissions assignments during the user login.

> Although we will not use roles in this article, you still need to enable RBAC (Role-Based Access Control) support.



<details>
  <summary>Permissions vs. scopes</summary>
When defining the API permissions in the Auth0 Dashboard, you find the term *scope* next to the term *permission*. You may think that they are synonymous, but they actually aren't. Both describe the actions that can be performed on a resource, but they are used in different authorization scenarios.

**Permissions** are used in a [first-party authorization scenario](https://auth0.com/docs/applications/first-party-and-third-party-applications#first-party-applications), i.e., when the same organization or person controls both the client and the server applications.

**Scopes** are used in a [third-party authorization scenario](https://auth0.com/docs/applications/first-party-and-third-party-applications#third-party-applications), i.e., when different organizations control the client and the server applications.

In the latter scenario, the client application asks for one or more permissions to operate on a specific resource on behalf of the user. This requested permission is a **scope**. Usually, scopes limit what an app can do on behalf of the user, and the user may grant them to the application or not.

Scopes have been [introduced by OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) in the context of delegated authorization.
</details>

## Checking Permissions in an API

As the next step, you need to check that the user calling your API has the proper permissions. You can accomplish this task by defining one or more authorization policies and applying them to the controller or the methods that implement your ASP.NET Web API.

An **authorization policy** is a set of requirements that users or applications must meet in order to be allowed to perform an action on a resource. Let's see how you can define and apply an authorization policy in practice.

### Registering an authorization policy

To define an authorization policy for the glossary Web API, open the `Startup.cs` file in the root folder of the project and append the following code to the body of the `ConfigureServices()` method:

```csharp
// Startup.cs

// ...existing code...

namespace Glossary
{
  public class Startup
  {
    // ...existing code...
    
    public void ConfigureServices(IServiceCollection services)
    {
      // ...existing code...
      
      //👇 new code
      services.AddAuthorization(options =>
      {
        options.AddPolicy("WriteAccess", policy => 
                          policy.RequireClaim("permissions", "create:term", "update:term"));
        options.AddPolicy("DeleteAccess", policy => 
                          policy.RequireClaim("permissions", "delete:term"));
      });
      //👆 new code
    }
    
    // ...existing code...
  }
}

```

You invoked the `AddAuthorization()` method to configure the ASP.NET authorization service. To this purpose, you defined two authorization policies via the `AddPolicy()` method of the `options` parameter. Each policy has a name and a lambda expression. For example, the `WriteAccess` authorization policy is defined by requiring the `permissions` [claim](https://auth0.com/docs/tokens/json-web-tokens/json-web-token-claims) in the access token whose value can be `create:term` or `update:term`. Similarly, for the `DeleteAccess` policy.

### Authorization policy approaches

You defined two authorization policies based on the permissions you defined for the API in the Auth0 Dashboard. Both policies are based on requiring the existence of claims with specific values. This is the simplest way to define an authorization policy in ASP.NET. It is usually referred to as [claim-based authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims).

If you have more complex criteria for defining your authorization policies, you need to use the [policy-based authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies) approach. For example, if you want to be sure that the issuer of the `permissions` claim is your [Auth0 tenant](https://auth0.com/docs/get-started/create-tenants), you can define your `WriteAccess` authorization policy as follows:

```csharp
options.AddPolicy("WriteAccess", policy => 
                    policy.RequireAssertion(context =>
                       context.User.HasClaim(claim =>
                         (claim.Type == "permissions" &&
                          (claim.Value == "create:term" ||
                           claim.Value == "update:term") &&
                          claim.Issuer == $"https://{Configuration["Auth0:Domain"]}/"
                         )
                       )
                    )
                  );
```

In this case, you used the `RequireAssertion()` method to build a boolean expression that evaluates your specific criteria. In particular, this criteria checks that the `Issuer` property of the claim matches the URL of your Auth0 tenant.

> Note that claim-based authorization is just a specialized case of policy-based authorization.

If you have more specific needs, you can even [customize the built-in ASP.NET authorization middleware](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/customizingauthorizationmiddlewareresponse).

### Applying an authorization policy

Once you define and register your authorization policies, you can apply them in your Web API. Applying an authorization policy is just a matter of passing parameters to the `Authorize` attribute. So, open the `GlossaryController.cs` file under the `Controllers` folder and apply the changes outlined in the following:

```csharp
// Controllers/GlossaryController.cs

// ...existing code...

namespace Glossary.Controllers
{
  [ApiController]
  [Route("api/[controller]")]
  public class GlossaryController : ControllerBase
  {
    // ...existing code...

    [HttpPost]
    [Authorize(Policy = "WriteAccess")]    //👈 changed code
    public ActionResult Post(GlossaryItem glossaryItem)
    {
      // ...existing code...
    }

    [HttpPut]
    [Authorize(Policy = "WriteAccess")]    //👈 changed code
    public ActionResult Put(GlossaryItem glossaryItem)
    {
      // ...existing code...
    }

    [HttpDelete]
    [Route("{term}")]
    [Authorize(Policy = "DeleteAccess")]    //👈 changed code
    public ActionResult Delete(string term)
    {
      // ...existing code...
    }
  }
}
```

This way, you are requesting the ASP.NET authorization middleware to evaluate a specific policy to authorize the execution of the related controller's method.

Your Web API is ready to run and check permissions!

## Testing Permissions

To test the new glossary Web API, you are going to simulate users accessing the endpoints with different permissions. For this simulation, you will interact with the API through the Swagger UI by providing an access token. So, launch the Web API by typing `dotnet run` in a terminal window and point your browser to [https://localhost:5001/swagger](https://localhost:5001/swagger).

### Testing access without permissions

Let's try to access a protected endpoint with an access token not bound to any permissions. Go to the [API section](https://manage.auth0.com/#/apis) of your Auth0 Dashboard, select the API related to the glossary app, and select the *Test* tab. Here you can get a token to test your Web API by clicking the *Copy Token* icon as shown in the following picture:

![Copy access token](https://images.ctfassets.net/23aumh6u8s0i/1FENUfKNw5FrmexhvdWwv5/bb1c283a019dc0fd7322e357efd1bdb2/copy-token.png)

Now, head back to your browser and click the *Authorize* button. A window dialog opens, as shown in the following picture:

![Bearer token in Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/18f9kh3tBXiOMbxjSA7j1k/c0ab1d1475b75ef51a50a1009ea3c5c1/access-token-swagger-ui.png)

Paste the token you copied from the Auth0 Dashboard into the text box and click *Authorize*.

> To learn a bit more about the Swagger UI, check out [this article about ASP.NET Web API authorization](https://auth0.com/blog/aspnet-web-api-authorization/).

Now, try to add a new glossary term through the `POST` action. You should get a negative response from the server similar to this one:

![Forbidden action on an endpoint](https://images.ctfassets.net/23aumh6u8s0i/2jJfEWsECwVKy9qwcy7Nyk/182e158601d78774ee3fd633028badea/forbidden-action-on-endpoint.png)

Notice that, this time, you didn't receive the `401 Unauthorized` HTTP status code. You received the `403 Forbidden` status code. This denotes that you are providing an access token, so you are authorized to access the application, but you don't have the required permissions to perform this specific action.

You can verify your current permissions by visiting [jwt.io](https://jwt.io/) and pasting your access token there. This tool allows you to decode your access token. You will discover that the `permissions` claim shown in the payload section is an empty array, as in the following picture:

![Empty permissions claim in JWT](https://images.ctfassets.net/23aumh6u8s0i/5bMNrF4vS9iYs3hQuxCMe2/d8bffd83f61373f5b9a6e2b0d69691b6/empty-permissions-claim-in-jwt.png)

### Testing access with writing permissions

Let's create an access token with the required permissions for adding a new term.

Back in your API configuration page on the Auth0 Dashboard, select the *Machine to Machine Applications* tab. You'll get a list of applications, some of them with the *(Test Application)* label in the name. These applications are automatically created by Auth0 when you create an API there. They are meant as test clients from your API. One of them should have the *Authorized* switch on. Click the dropdown next to it and check the `create:term` and `update:term` permissions in the section that will be shown:

![Writing permissions assignment](https://images.ctfassets.net/23aumh6u8s0i/1noHOvxBZaRERXAJ9SpPt2/849b32e5f54524cc3e6f3e58eb1f3578/assign-writing-permissions.png)

Then, click the *Update* button, move again to the *Test* tab, and copy the new token that has been generated for you. Now, in the Swagger UI of your Web API, click the *Authorize* button again. This time the following window should appear:

![Changing the access token](https://images.ctfassets.net/23aumh6u8s0i/1WKMrki5ZtwLPvBKmoQ1Gv/b276253e73ed5848f804ac69a37718d3/changing-access-token.png)

Click the *Logout* button and paste the new access token in the text box that appears.

At this point, try again to add a new term to the glossary through the `POST` action. Now you should get a successful response from the server.

If you decode your new access token in [jwt.io](https://jwt.io/), you should see that the `permissions` claim now contains the two permissions you assigned:

![Writing permissions in JWT](https://images.ctfassets.net/23aumh6u8s0i/WVVEcOwuIeuB73aYKu0Q0/e8a722919757b259befd52ddc09dfdf5/writing-permissions-in-jwt.png)

If you attempt to delete the newly created term with the same access token, you get the `403 Forbidden` status code as before. In fact, your access token doesn't contain the deleting permission.

### Testing access with deleting permissions

To be authorized to delete a glossary term, you need to grant the deleting permission to the test application. So, go back to the *Machine to Machine Application* tab of your API configuration on the Auth0 Dashboard and open the permissions section of the test application again. Check also the `delete:term` permission and click the *Update* button. Now, in the *Test* tab, copy the new access token and head back to your browser.

In the Swagger UI of your Web API, replace your current access token with the new one by using the *Authorize* button. Then, delete the glossary term you added earlier by using the `DELETE` action. This time your attempt should be successful!

## Recap

In summary, you learned that permissions give you more granular control over access to your Web API. You discovered how to define permissions associated with your API in Auth0 and how to define and register authorization policies in your ASP.NET application. You saw that checking permissions in your API controller is a matter of adding a parameter to the `Authorize` attribute. You used your test client application on the Auth0 Dashboard to generate access tokens with the required permissions. Finally, you used the Swagger UI to test your Web API with access tokens having different permissions.

You can download the final code of the sample application from [this GitHub repository](https://github.com/auth0-blog/glossary-web-api-aspnet/tree/add-permission).


Permission-Based Security for ASP.NET Web APIs

Learn how to secure an ASP.NET Core Web API by granting access only to authorized users through Auth0 authentication and authorization services.

Having control over who can access your API is a necessary requirement to make your application secure. This article will show you how to restrict access to your ASP.NET Core Web API to authorized users only.

## Setting up the Web API Application

Let's start by setting up the ASP.NET Core Web API application to be protected. You can download a glossary Web API from [this GitHub repository](https://github.com/auth0-blog/glossary-web-api-aspnet/tree/starter) by running the following command in a terminal window:

```bash
git clone --branch starter --single-branch https://github.com/auth0-blog/glossary-web-api-aspnet.git

```

This ASP.NET application provides you with a CRUD Web API to manage a glossary of terms. You can learn the details of its implementation by reading [this article](https://auth0.com/blog/building-aspnet-web-api).

Once you download the application, move to the `glossary-web-api-aspnet` folder and launch it by typing `dotnet run` in a terminal window. By pointing your browser to `https://localhost:5001/swagger`, you should see a page like the following to interactively test the APIs:

![Swagger UI for Web API](https://images.ctfassets.net/23aumh6u8s0i/39X3FZbdleAybhhvH5hCV7/b0276f9319a0a8110fcffc1dd583f602/webapi-swagger-ui.png)

The Web API application allows you to get a list of term definitions or a single term definition. It also lets you create a new definition and modify or delete an existing one.

The current implementation of this glossary Web API allows anyone to perform all the available operations on the glossary. Most probably, you want to allow everyone to get a single glossary item or the full glossary. Still, only authorized users should be enabled to create, update, and delete glossary items.

Let's go and see how to protect these three actions by integrating your ASP.NET Core Web API with [Auth0](https://auth0.com) services.

## Registering the Web API with Auth0

To start securing your API with Auth0, you need an Auth0 account. If you haven't got one, you can <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free one</a>. Now, you can register your Web API through the [Auth0 Dashboard](https://manage.auth0.com/).  Move to the [API section of the Dashboard](https://manage.auth0.com/#/apis) and follow these steps:

1. Click on *Create API*
2. Provide a friendly name for your API (for example, *Glossary API*) and a unique identifier in the URL format (for example, *https://glossary.com*)
3. Leave the signing algorithm as RS256 and click the *Create* button

These steps make Auth0 aware of your Web API and will allow you to control access.

> **Note**: While you are in the Auth0 Dashboard, take note of your Auth0 domain. You will need it soon. This is a string in the form `YOUR-TENANT-NAME.auth0.com` where `YOUR-TENANT-NAME` is the name you provided when you created your account with Auth0. For more information, [check the documentation](https://auth0.com/docs/getting-started/the-basics#domains).

<details>
  <summary>Using the Auth0 CLI</summary>
As an alternative to the Dashboard, you can use [the Auth0 CLI](https://auth0.com/blog/introducing-auth0-cli/) to register your API with Auth0.


In this case, [install the CLI on your machine](https://github.com/auth0/auth0-cli#installation) and [configure it to access your Auth0 tenant](https://github.com/auth0/auth0-cli#login). Then, run the following command in a terminal window:

```bash
auth0 apis create --name "Glossary API" --identifier https://glossary.com --scopes ""
```

This command creates an entry for your API with the name *Glossary API* and the unique identifier `https://glossary.com`. You are not specifying any [scope](https://auth0.com/docs/scopes) for this application right now.

Running this command has exactly the same effect as registering your API through the Auth0 Dashboard.

After the registration, you will get an output like the following:

```bash
=== <YOUR_AUTH0_DOMAIN> API created

  ID          60ac3b89f0cd4a003d42e850  
  NAME        Glossary API              
  IDENTIFIER  https://glossary.com   
  SCOPES  
```

Take note of the values for the `<YOUR_AUTH0_DOMAIN>` placeholder and the identifier.
</details>

## Enabling Authorization Support

The next step is to adapt the ASP.NET Core Web API application's code to use Auth0 authorization services.

### Configuring the Web API

Back in your ASP.NET application, open the `appsettings.json` configuration file and replace its content with the following:

```json
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "Auth0": {
    "Domain": "YOUR_AUTH0_DOMAIN",
    "Audience": "YOUR_UNIQUE_IDENTIFIER"
  }
}
```

Replace the `YOUR_AUTH0_DOMAIN` placeholder with your Auth0 domain and the `YOUR_UNIQUE_IDENTIFIER` placeholder with the value you provided as a unique identifier of your API (`https://glossary.com`, if you kept the value suggested above).

### Integrating with Auth0

In order to interact with the Auth0 authorization services, your application needs to be able to handle tokens in the [JWT](https://jwt.io/) (*JSON Web Token*) format. You can accomplish this by installing the `Microsoft.AspNetCore.Authentication.JwtBearer` library. Move to your application folder and type the following command in a terminal window:

```bash
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer
```

When the installation is complete, open the `Startup.cs` file and add the `JwtBearer` namespace. The `using` section of the file should look as shown below:

```c#
//Startup.cs
...existing code... 
using Microsoft.OpenApi.Models;
using Microsoft.AspNetCore.Authentication.JwtBearer; //👈 new code

namespace Glossary
{
  //...existing code...
}
```

In the same file, replace the `ConfigureServices()` method of the `Startup` class with the following code:

```c#
//Startup.cs

// ...existing code...
    public void ConfigureServices(IServiceCollection services)
    {
      //👇 new code
      services.AddAuthentication(options =>
      {
        options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
      }).AddJwtBearer(options =>
      {
        options.Authority = $"https://{Configuration["Auth0:Domain"]}/";
        options.TokenValidationParameters = 
          new Microsoft.IdentityModel.Tokens.TokenValidationParameters
          {
            ValidAudience = Configuration["Auth0:Audience"],
            ValidIssuer = $"{Configuration["Auth0:Domain"]}",
            ValidateLifetime = true,
          };
      });
      //👆 new code

      services.AddControllers();
      services.AddSwaggerGen(c =>
      {
        c.SwaggerDoc("v1", new OpenApiInfo { Title = "Glossary", Version = "v1" });
      });
    }
// ...existing code...
```

You added the authentication service by specifying the JWT bearer scheme. You also configured the JWT handler by using the domain and audience values from the `appsettings.json` configuration file. In particular, you built the authority URL based on the Auth0 domain and set the parameters that allow the access token to be validated. Specifically, a token is considered valid if it meets the following criteria:

- it has the expected audience,
- it was issued by the expected domain,
- it is not expired.

Finally, replace the `Configure()` method of the `Startup` class with the following code:

```c#
//Startup.cs

// ...existing code...
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseHttpsRedirection();
    app.UseRouting();
  
    app.UseAuthentication();  //👈 new code
    app.UseAuthorization();
  
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}
// ...existing code...
```

Compared to the previous version, you just added the `app.UseAuthentication()` statement to enable authentication for your application.

<details>
  <summary>Why do you need authentication?</summary>
You may wonder why you need to register the authentication middleware in your ASP.NET Web API. After all, you should only manage authorization. The authentication middleware is needed because it is responsible for creating the security context under which the code is running.


Also, the registration order is important: you need to register the authentication middleware before the authorization middleware.

For more details, check out the [ASP.NET Web API authentication and authorization documentation](https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api).
</details>

<include src="Auth0TemplatesForDotnetCTA" />

## Securing the API Endpoints

Almost everything is ready to secure your application. You just need to protect the actions that allow clients to create, update, and delete glossary items. So, open the `GlossaryController.cs` file in the `Controllers` folder and add the `Microsoft.AspNetCore.Authorization` namespace. The `using` section of the file will look like the following:

```c#
//Controllers/GlossaryController.cs
using System;
using System.Collections.Generic;
using Microsoft.AspNetCore.Mvc;
using System.IO;
using Microsoft.AspNetCore.Authorization;  //👈 new code

namespace Glossary.Controllers
{
  // ...existing code...
}
```

Now, add the `Authorize` attribute to the `Post()`, `Put()`, and `Delete()` methods. As an example, your `Delete()` method should become like shown below:

```c#
//Controllers/GlossaryController.cs
// ...existing code...
        [HttpDelete]
        [Route("{term}")]
        [Authorize]  //👈 new code
        public ActionResult Delete(string term)
        {
            var glossaryItem = Glossary.Find(item =>
                   item.Term.Equals(term, StringComparison.InvariantCultureIgnoreCase));

            if (glossaryItem == null)
            {
                return NotFound();
            }
            else
            {
                Glossary.Remove(glossaryItem);
                return NoContent();
            }
        }
// ...existing code...
```

As you can see, the only difference is the `Authorize` attribute.

> **Note**: You may be wondering if the order of the attributes applied to a method or to a controller class matters. Their order is internally defined, and it depends on the stage of the HTTP pipeline they are bound to and on their scope (global, class, or method scope). So, from a syntactical point of view, it doesn't matter if you put, for example, the `Authorize` attribute before or after the `Route` one.
> For more information on this point, check the [official documentation](https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/filters?view=aspnetcore-3.0).

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

## Testing the Secure Web API

In order to ensure that all works as expected, run the application, point your browser to [https://localhost:5001/swagger](https://localhost:5001/swagger), and test the GET action on the `api/Glossary` endpoint. You should get the list of term definitions as before.

### Testing unauthorized accesses

Now, try to add a new item to the glossary by using the POST action on the `api/Glossary` endpoint as shown in the following picture:

![Calling HTTP POST on the Glossary Web API](https://images.ctfassets.net/23aumh6u8s0i/2Wj5qH5QGMcZC82KC47HVM/758a0589e4254ff6a013deb48808cba7/post-webapi-swagger-ui.png)

This time you should get a `401 Unauthorized` HTTP status code, as shown below:

![Unauthorized response from the Web API](https://images.ctfassets.net/23aumh6u8s0i/4GB1MoOEZ3VoKRddc5Vwxi/0510cf8164263b15d188fc5ab5751424/unauthorized-response.png)

This means that your endpoint is protected: only authorized users can add a new definition to the list. So, in order to add a new item to the glossary, you need to get an access token from Auth0 and make a request to the API endpoint using the [Bearer Authorization scheme](https://www.rfc-editor.org/rfc/rfc6750.html).

### Testing authorized accesses

However, before going ahead, you need a way to provide your access token to the interactive web API documentation. To achieve this goal, edit the `Startup.cs` file and apply the changes shown in the following code snippet to the `ConfigureServices()` method:

```csharp
//Startup.cs
// ...existing code...
    public void ConfigureServices(IServiceCollection services)
    {

      // ...existing code...
      services.AddControllers();

      services.AddSwaggerGen(c =>
      {
        c.SwaggerDoc("v1", new OpenApiInfo { Title = "MyProject", Version = "v1.0.0" });

        //👇 new code
        var securitySchema = new OpenApiSecurityScheme
        {
          Description = "Using the Authorization header with the Bearer scheme.",
          Name = "Authorization",
          In = ParameterLocation.Header,
          Type = SecuritySchemeType.Http,
          Scheme = "bearer",
          Reference = new OpenApiReference
          {
            Type = ReferenceType.SecurityScheme,
            Id = "Bearer"
          }
        };

        c.AddSecurityDefinition("Bearer", securitySchema);

        c.AddSecurityRequirement(new OpenApiSecurityRequirement
          {
              { securitySchema, new[] { "Bearer" } }
          });
        //👆 new code
      });
    }
// ...existing code...
```

You added a few additional configuration options to your API's Swagger instance. In particular, you defined a security schema and added it to the generated documentation as a security requirement.

Now, restart your ASP.NET Core Web API and take a look at the web page shown at the address [https://localhost:5001/swagger](https://localhost:5001/swagger):

![Protected Web APIs in Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/1rNBChKdbCr9fKdpbbYcKR/014f6ace0411febc726959cd88ed8e6a/protected-swagger-ui-webapi.png)

You see the new *Authorize* button and the lock icon on each action. You can configure Swagger to get a more accurate UI, but this topic is out of the scope of this article. Please check out [the official documentation for more details](https://github.com/domaindrivendev/Swashbuckle.AspNetCore#add-security-definitions-and-requirements).

At this point, let's get the access token from Auth0. The simplest way is to access [the API section of your Auth0 Dashboard](https://manage.auth0.com/#/apis) again, select the API that you created before and select the *Test* tab. In this section, you can get a temporary token to test your Web API by clicking the *Copy Token* icon as shown in the following picture:

![Copying temporary token from the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/1FENUfKNw5FrmexhvdWwv5/bb1c283a019dc0fd7322e357efd1bdb2/copy-token.png)

Now, head back to your browser and click the *Authorize* button. A window dialog opens, as shown in the following picture:

![Configure access token for Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/18f9kh3tBXiOMbxjSA7j1k/c0ab1d1475b75ef51a50a1009ea3c5c1/access-token-swagger-ui.png)

Paste the token you copied from the Auth0 Dashboard into the text box and click *Authorize*.

With this step, you have configured the interactive documentation to add the Authorization header to each HTTP request. That header's value will be the access token in the form of a bearer token.

If you try to add a new glossary term through the POST action, you should get a successful `201 Created` HTTP status code as before securing the API. The following picture shows an example of such a response:

![A successful response from the protected Web API](https://images.ctfassets.net/23aumh6u8s0i/2iY4mvFFAZGrDcpXKZiFPU/b0f0b3d576e9d0fc19e7fc7574e089a3/success-response-webapi-post.png)

Now your Web API is ready to be securely consumed by clients.

## Recap

This article showed you how to protect your ASP.NET Core Web API to prevent unauthorized users from accessing specific endpoints. You learned how to register your Web API application with Auth0, how to enable your ASP.NET application to support authorization, and how to use the autogenerated interactive documentation to test the endpoints.

You can download the full source code of the application from [GitHub](https://github.com/auth0-blog/glossary-web-api-aspnet/tree/add-authorization).


"Web"