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

Auth0’s latest features enhance user experience with secure, customizable logins, flexible authentication, and improved security—without compromising convenience.

Customer expectations are higher than ever. They want security, convenience, and personalization, all without friction. Businesses need to deliver seamless experiences while keeping user data safe. The challenge? Balancing security with ease of access.

At Auth0, we believe you shouldn’t have to choose between security and experience. That’s why we’re introducing innovations that strengthen security and improve user experience—before, at, and after login.

## Powerful New Features for Secure, Seamless Login

Today’s businesses need to build trust with their users. Customers *expect* engaging experiences, convenient journeys, and secure digital platforms. Before they give you their business, they need to know that you can cater to their unique needs, provide ease of use across multiple channels, and protect their data and sensitive information. When security and user experience are seamlessly integrated, customers engage more, businesses grow, and digital experiences become effortless. And that starts with getting identity right. 

> We’ve updated the authentication journey to help businesses deliver trusted, customized experiences while keeping users safe.

#### **Before login**: greater flexibility with Tenant Access Control

**Security starts before users even log in. **Tenant Access Contro**l (Generally Available, March 2025) helps protect applications and APIs from threats like denial-of-service attacks. Stopping lousy traffic before it reaches your applications prevents disruptions and keeps them running. This feature allows organizations to create granular policies to manage access and mitigate threats, giving them more control over protecting their applications and users.

#### **At login**: Advanced Customization for Universal Login

**The login box is often the first interaction users have with your brand and the one they repeatedly return to as they continue engaging with it. Now, with **Advanced Customization for Universal Login** (Early Access, February 2025), businesses can control every piece of their login experience while leveraging Auth0’s security and built-in authentication process. Create pixel-perfect experiences and tailor every detail to match your brand with the same built-in security Auth0 is known for. 

#### **After login**: strengthen security

**Security doesn’t stop after users are logged in. We’re introducing key enhancements to secure the entire customer journey:

 * **FAPI 2 Certification **(Achieved, March 2025) strengthens API security with financial-grade protections that prevent transaction tampering and data leaks within our Highly Regulated Identity product.
 * **Client-initiated backchannel Authentication** (Limited Early Access, Generally Available Q2 2025) enables a client application (e.g., call center system, POS terminal, autonomous AI agent) to initiate the authentication process on behalf of the customer, making authentication easier.
 * **Native to Web SSO** (Early Access, April 2025) keeps users signed in as they move between mobile and web apps, eliminating unnecessary logins (and frustrated customers!).

## Identity Is the Key to Better Experiences 

In the past, businesses struggled with trade-offs, prioritizing security at the expense of user experience or vice versa. Modern identity removes that compromise, ensuring that security enhances, rather than hinders, customer experience.

Businesses that get identity right can deliver effortless logins, personalized interactions, and enterprise-grade security without slowing growth. These latest innovations make it easier than ever to:

* Protect against fraud and unauthorized access
* Build seamless, branded login experiences
* Maintain compliance with industry standards
* Enable flexible, secure authentication
* Keep users signed in across platforms

## Get Started Today

Auth0 makes identity **simple**, **scalable**, and more **secure.** These latest innovations help businesses stay ahead by offering users the frictionless, secure experiences they expect.

> Stop building identity from scratch. Start building with Auth0.

Learn more about these updates in our [documentation](https://auth0.com/docs/get-started) or [contact our team](https://auth0.com/contact-us) today.

_Any products, features, functionalities, certifications, authorizations, or attestations referenced in this material that are not currently generally available or, have not yet been obtained, or are not currently maintained may not be delivered or obtained on time or at all. Product roadmaps do not represent a commitment, obligation, or promise to deliver any product, feature, functionality, certification, or attestation, and you should not rely on them to make your purchase decisions._

Better User Experiences, Stronger Security

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

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

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

## The Challenge of Global Scale

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

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

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

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

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

## Why Auth0 Stands Out

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

### Dual capability

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

### Robust security

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

### Scalability

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

### Flexible customization

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

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

## Auth0 Is Ahead of the Competition

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

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

## See Auth0 in Action

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

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

### Step-by-step developer guides

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

### Code samples

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

## Conclusion

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

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

Authentication and Authorization For Developers Who Build at Global Scale

Jax Painter

Director, Product Marketing

Empower your team with a unified digital Identity strategy that includes intelligent, integrated auth capabilities that minimize risk while improving experience.

Developers are the backbone of innovation. What they focus on can accelerate or hinder the delivery of new products. Authentication and authorization have always been a top development priority, but increases in data volumes, data usage, mobility, and other factors are creating significant complexity.

Navigating increasing auth challenges with manual, cumbersome approaches —while also trying to keep up with the latest security standards and regulations — can be overwhelming. This situation can result in frustrated developers, delayed launch dates, and an increased risk of security gaps that can cause outages, costly non-compliance fees, and damaged business reputations. AI and [GenAI](https://www.okta.com/blog/2024/10/unlocking-the-power-of-generative-ai-with-identity/) adoption only amplify developers' auth challenges because models require massive amounts of information for accuracy and all data usage must align with evolving security and compliance regulations.

How organizations manage auth also determines their effectiveness in protecting data against evolving threats, complying with regulations, and improving brand reputation. Building auth services from scratch or relying on features in legacy systems can easily lead to compliance and governance missteps caused by Identity fragmentation across applications and systems. After all, siloed Identity management is difficult to track, making it harder to safeguard customer data.

Chief technology officers, directors, and development leaders can empower their teams with a unified digital Identity strategy that includes intelligent, integrated auth capabilities that minimize complexity and risk while improving experience. By building and maintaining authentication with less effort and simplifying governance and compliance, developers can spend the bulk of their time doing what they excel at, bringing new products and services to market faster.

## Moving from Complexity to Clarity — and Ideas to Impact

Authentication and authorization are critical vehicles for creating innovative solutions and differentiating experiences for customers and employees. That’s because users expect scalable, frictionless access to apps, digital tools, and cloud services.

To make this possible while enabling teams to manage all their tasks, developers need easy-to-use auth systems that minimize the need for custom code and specialized security skills. That way, developers have what they need to build flexible solutions that can easily integrate with other technologies, support new authentication methods, and facilitate new use cases including AI and GenAI — all in a way that minimizes risk and delivers positive user experiences.

## How LaunchNotes Uses Authentication to Drive Growth

[LaunchNotes](https://www.okta.com/customers/launchnotes/) equips product and development teams with the tools they need to effectively communicate, understand, and manage the what, when, and why of product roadmaps. To drive growth, especially in the enterprise customer space, LaunchNotes replaced their authentication software with a unified solution from Auth0. It provides the enterprise-grade authentication and authorization capabilities prospective customers were looking for, like [single sign-on](https://www.okta.com/products/single-sign-on-workforce-identity/) (SSO).

Auth0 is also easy to use. With it, developers were able to set up a proof of concept in one hour and deploy their new auth solution, including SSO capabilities, within less than three weeks. Within one week of going live, LaunchNotes’ first enterprise customer signed up and more than 10 customers re-engaged.

Developers are also realizing ongoing efficiencies with their unified auth solution. Today, they spend 95% less time managing password policies for B2B customers. They implemented social logins in just minutes. And now, they onboard new customers up to 20% faster, which improves the experience of customers and employees.

## How Cribl Transforms Auth to Bring New Products to Market Faster

[Cribl](https://www.okta.com/customers/cribl/) helps organizations collect, process, route, and analyze logs, traces, and other telemetry data from their in-house and third-party systems and apps. Because this data is critical in establishing and managing seamless, protected communication between systems, Cribl provides customers with strict access controls. For years, Cribl used [role-based access controls](https://www.okta.com/identity-101/what-is-role-based-access-control-rbac/) (RBAC) to authorize users.

However, when they introduced virtual Workspaces for their customers, Cribl quickly recognized that their RBAC approach could not scale with increasing complexity and growth. Developers were spending too much time manually building and maintaining auth systems. To set up authentication for just one Workspace, they had to manually define up to 400 roles in a JSON Web Token.

After evaluating their best options, Cribl’s teams unanimously chose to adopt a unified auth solution from Auth0. It enables granular RBAC and centralized auth models that are flexible, scalable, and easy to manage. Today, developers input their new products into their authorization model and Auth0 automatically handles the mapping between data owners as directed. As a result, what used to take developers months of manual effort now takes just weeks. And because developers can set up authorization for new products 80% faster, they have more time to spend on innovation.

## How Alma Media Builds and Maintains Identity Security with Less Effort

Media and service company [Alma Media](https://www.okta.com/customers/alma-media/) was struggling with siloed auth solutions. The organization operates more than 100 websites and brands used by millions of customers, and every site had its own login method. This meant customers couldn’t navigate between corporate brand sites without having to log in again. Cumbersome user experiences cut Alma Media's conversions in half. Additionally, developers had to create, manage, and scale each site’s standalone authentication solutions, leaving them little time to work on impactful projects.

To achieve their goals, Alma Media adopted a unified auth solution from Auth0 that has dramatically simplified development. As a result, Alma Media improved their user experience, security, and innovation potential. Customers now have SSO, so they no longer have to manage multiple IDs and passwords across sites. They can also opt to log in to sites using their social media accounts.

Additionally, in-house developers and IT teams now use the same flexible solution for managing auth across sites. This straightforward approach reduces risk,  boosts efficiency, and delivers measurable savings. Alma Media has decreased their total cost of ownership by 30% and license expenses by 10%.

## Ignite Innovation at Your Organization

Maximizing the time your developers have to create differentiating solutions that improve security, experience, and innovation is easier with a unified strategy. Auth0 equips organizations with intelligent, integrated authentication and authorization tools that reduce complexity so developers can turn ideas into impactful solutions faster.

No-code, low-code, and pro-code tools accelerate the development of automated flows that teams can quickly adapt to meet current and future use cases. Built-in capabilities also simplify governance and compliance, including certification and regulatory support, data sovereignty, and centralized controls.

Free your devs and simplify auth management! Learn More about [Customer Identity and Access Management (CIAM)](https://www.okta.com/customer-identity/)

## Resources

- [Check out our Developer Center](https://developer.auth0.com/)
- [Unlock SaaS app growth: Download the Why Customer Identity White Paper](https://www.okta.com/resources/whitepaper-why-ciam/)
- [Learn about Fine-Grained Authorization (FGA)](https://auth0.com/resources/whitepapers/fine-grained-authorization-technical-primer)
- [Discover how Okta secures your Generative AI implementation](https://www.okta.com/blog/2024/10/unlocking-the-power-of-generative-ai-with-identity/) 
- [Explore the Build versus buy question for CIAM](https://www.okta.com/resources/whitepaper-build-vs-buy/)


Innovation Ignited: How Development Leaders Make Authentication an Innovation Engine

andrea-chiarelli

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

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

Principal Developer Advocate

Andrea Chiarelli

Learn how to integrate CIBA authentication in your .NET applications to improve security and privacy.

There are scenarios where the user cannot interact directly with an application to use its functionality securely. In these scenarios, CIBA can guarantee security and usability at the same time.
This article will walk you through CIBA authentication and how to implement it in a .NET application.

## What Is CIBA?

CIBA stands for *Client-Initiated Backchannel Authentication*, and it's a [standard flow](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) for decoupled authentication defined by the OpenID Foundation. Decoupled authentication occurs when the user is authenticated outside the context of an application. For example, consider a call center agent that is asked to modify a customer's order on the phone. Before executing that request, the agent needs to be sure that the user on the phone is actually the customer who placed that order. In this case, the call center agent sends an authentication request to the customer's phone. Once the customer confirms their identity, the operator can perform the requested action. Notice that the user authentication does not occur in the order management application, i.e., the application where the requested action needs to be performed, but on the user's device. This is why this type of authentication is called decoupled authentication.

Read [this article to learn more about CIBA use cases](https://auth0.com/blog/ciba-authenticate-customers-in-call-centers/).

## The CIBA Flow

Let's dig into the following diagram to understand how CIBA works:

![The Client-Initiated Backchannel Authentication (CIBA) flow](https://images.ctfassets.net/23aumh6u8s0i/3FccU3SUoWUH9TjY8zpSao/0dbdc84a573753cba9505edcf9237ee3/ciba-flow.png)

From this diagram, you see that the actors involved in the flow are:

- **The user**. This is the user who interacts with the application starting the authentication flow. In the use case described earlier, this is the call center agent.
- **The client application**. This is the application that initiates the CIBA authentication flow. In our previous example, it was the order management application. Notice that this application must be a [confidential client](https://auth0.com/docs/get-started/applications/confidential-and-public-applications), i.e., an application running in a controlled environment, such as a server environment. You cannot implement the CIBA flow directly in a SPA or desktop application; these applications must rely on a backend server.
- **The authorization server**. It's the server that authenticates the user and supports the CIBA flow, such as Auth0.
- **The end user**. This is the customer who needs to be authenticated to allow the user to perform actions on the client application. In the context of our example, this is the customer asking for a change to their order. The end user must have a mobile device with an application enrolled with the authorization server to receive push notifications.

> While in this diagram you have two distinct users, in some scenarios, the user and the end user can be the same person. Consider the case of a user accessing a kiosk in a retail shop or a device without a browser. Read [here](https://auth0.com/blog/ciba-authenticate-customers-in-call-centers/) for more use cases.

Following the numbered arrows in the diagram, we have:

1. The user interacts with the client application and requests the end user's authentication.
2. The client application submits an HTTP request to the authorization server's `/bc-authorize` endpoint  and then start polling the `/token` endpoint to receive the response.
3. The authorization server sends a push notification to the end user's device.
4. The end user interacts with the push notification. The mobile application retrieves the data associated with the authentication request (consent details) and presents it to the end user. At this point, the end user sends their response, i.e., they can accept or deny the request.
5. The client application receives the end user's response. If the response is successful, it also receives the tokens to perform the requested action.


This is a high-level overview of the CIBA flow. For more details on the messages exchanged by the actors involved in the flow, check out [this document](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba).

## The Sample Application

Once you have a high-level understanding of CIBA flow, let's see how to implement it in a .NET application using Auth0.

Assume a call center scenario where an agent with a user on the phone needs to access that user's sensitive data managed by an application. This could be a hospital call center where users ask for information about their medical records. It could also be a tax center where users ask for information about their current tax situation. The agent needs to be sure that the user is who they say they are before giving this information.

You can imagine a screen like the following in front of the call center agent:

![User data screen to initiates the CIBA flow](https://images.ctfassets.net/23aumh6u8s0i/1Uq6DfvHijZcx1eJVkUXZz/156a145dd050bfbca9600255f3ea9371/user-data-screen-to-initiates-ciba-flow.png)

By clicking the "Load sensitive data" button, the agent initiates the CIBA flow to authenticate the user requesting access to their data.

From a technical perspective, the application is a .NET application running on a server. The screenshot above shows a Blazor Web App, but it could be an ASP.NET Core MVC or a Razor Page application. This application has to call a protected API to get the end user's sensitive data, and for this reason, it needs an access token with the appropriate scopes.

The backend application has a mobile counterpart capable of receiving push notifications, and the user must have this application installed on his device, typically a smartphone.

In the following sections, you will learn how to enable CIBA for this application using Auth0. You will start by enabling CIBA support on the backend application and then enable CIBA on the mobile device.

<div className="alert alert-info alert-icon">
  <i className="icon-budicon-487 icon-info"></i>
  <b>This article focuses on the backend application. It mentions how to deal with the mobile application at a high level but redirects you to the specific platform documentation for more details.</b><br> 
</div>


## Add CIBA Support to the Backend App

To add CIBA support to your backend application, you need first to configure your Auth0 tenant and then configure and modify your application's code.

### Enable CIBA support on your Auth0 tenant

To configure your Auth0 tenant to support CIBA, follow these steps in your [Auth0 dashboard](https://manage.auth0.com/):

- Make sure that [your application is registered with Auth0](https://auth0.com/docs/get-started/auth0-overview/create-applications/regular-web-apps) and take note of the domain, client ID, and client secret.
- Scroll down in the application settings and [enable the CIBA flow](https://auth0.com/docs/get-started/applications/configure-client-initiated-backchannel-authentication#configure-ciba-for-your-application).
- Make sure that the API the application is going to call is [registered with Auth0](https://auth0.com/docs/get-started/auth0-overview/set-up-apis) and take note of its identifier, also known as audience.
- Enable [Auth0 Guardian push notifications for your tenant](https://auth0.com/docs/get-started/applications/configure-client-initiated-backchannel-authentication#enable-auth0-guardian-push-notifications-for-your-tenant) and [configure push notifications for MFA](https://auth0.com/docs/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-push-notifications-for-mfa).
- The user must have [enrolled in MFA push notifications](https://auth0.com/docs/secure/multi-factor-authentication/auth0-guardian#enroll-in-push-notifications) to receive them.

Once you have configured your Auth0 tenant, go to your application's source code and update the `appsettings.json` configuration file with the following settings:

```json
// appsettings.json

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "Auth0": {
    "Domain": "YOUR_AUTH0_DOMAIN",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientSecret": "YOUR_CLIENT_SECRET",
    "Audience": "YOUR_API_AUDIENCE"
  }
}
```

Replace the `YOUR_AUTH0_DOMAIN`, `YOUR_CLIENT_ID`, and `YOUR_CLIENT_SECRET` placeholders with the respective application setting values from the Auth0 dashboard. Replace the `YOUR_API_AUDIENCE` placeholder with the audience of the API you want to call.

### Initiate the CIBA flow

Now you are ready to implement the CIBA flow in your backend application.

As the first step, install the [Auth0 Authentication API SDK for .NET](https://github.com/auth0/auth0.net) by running the following command in the root folder of your project:

```bash
dotnet add package Auth0.AuthenticationApi
```

The Auth0 Authentication API SDK is a generic .NET client for the [Auth0 Authentication API](https://auth0.com/docs/api/authentication). It's a low-level library that targets .NET Standard 2.0 and can be used in the legacy .NET Framework as well as the most recent .NET versions. At the time of writing, only the Auth0 Authentication API SDK supports CIBA for .NET.

> Check out [this article to learn more about the various Auth0 SDKs for the .NET platform](https://auth0.com/blog/choose-the-right-dotnet-sdk-for-auth0/).

To initiate the CIBA flow, we assume that when the call center agent clicks the "Load sensitive data" button, the following C# method is called with the user ID as its parameter's value:

```csharp
private async void GetUserData(string userId)
{
  var authenticationApiClient = new AuthenticationApiClient(new Uri($"https://{Configuration["Auth0:Domain"]}"));

  var response = await authenticationApiClient.ClientInitiatedBackchannelAuthorization(
    new ClientInitiatedBackchannelAuthorizationRequest()
    {
      ClientId = Configuration["Auth0:ClientId"],
      ClientSecret = Configuration["Auth0:ClientSecret"],
      Audience = Configuration["Auth0:Audience"],
      Scope = "openid profile read:sensitivedata",
      BindingMessage = "Request to access your private data",
      LoginHint = new LoginHint()
        {
          Format = "iss_sub",
          Issuer = $"https://{Configuration["Auth0:Domain"]}/",
          Subject = userId
        }
    });

  var isAuthorized = false;
  var isPendingAuthorization = true;
  var cibaTokenResponse = new ClientInitiatedBackchannelAuthorizationTokenResponse();

  while (!isAuthorized && isPendingAuthorization)
  {
    try 
    {
      cibaTokenResponse = await authenticationApiClient.GetTokenAsync(
        new ClientInitiatedBackchannelAuthorizationTokenRequest()
        {
          AuthRequestId = response.AuthRequestId,
          ClientId = Configuration["Auth0:ClientId"],
          ClientSecret = Configuration["Auth0:ClientSecret"]
        });
      
      isAuthorized = true;
      isPendingAuthorization = false;
    } catch (ErrorApiException ex)
    {
      if (ex.ApiError.Error == "authorization_pending") 
        Thread.Sleep(5000);
      else
        isPendingAuthorization = false;
    }
  }

  if (isAuthorized)
  {
    await LoadSensitiveUserData(cibaTokenResponse..AccessToken);
  }
}
```

The `userId` parameter contains the ID value of the user in the context of Auth0. Typically, it's a string in the form of `auth0|3813a4b5e...`. Let's break down the code of the `GetUserData()` method into its main parts.

> Be aware that the code shown here is a simplified version of the code you should have in production. Its goal is to explain how to implement the CIBA flow, ignoring performance details and other optimizations.

### Send the CIBA request

Consider the first section of the method:

```csharp
private async void GetUserData(string userId)
{
  var authenticationApiClient = new AuthenticationApiClient(new Uri($"https://{Configuration["Auth0:Domain"]}"));

  var response = await authenticationApiClient.ClientInitiatedBackchannelAuthorization(
    new ClientInitiatedBackchannelAuthorizationRequest()
    {
      ClientId = Configuration["Auth0:ClientId"],
      ClientSecret = Configuration["Auth0:ClientSecret"],
      Audience = Configuration["Auth0:Audience"],
      Scope = "openid profile read:sensitive-data",
      BindingMessage = "Request to access your private data",
      LoginHint = new LoginHint()
        {
          Format = "iss_sub",
          Issuer = $"https://{Configuration["Auth0:Domain"]}/",
          Subject = userId
        }
    });

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

In this part, you create an instance of the `AuthenticationApiClient` class by passing the URL of your Auth0 tenant. Then, you start the CIBA flow by calling the `ClientInitiatedBackchannelAuthorization()` method. This method is responsible for submitting the HTTP request to the `/bc-authorize` endpoint of Auth0. It needs the details of the authorization request, which is passed through an instance of the `ClientInitiatedBackchannelAuthorizationRequest` class.

Apart from the client ID, client secret, and audience, a few other values are passed in the request:

- **Scope**. This is the string containing the [scopes](https://auth0.com/docs/get-started/apis/scopes) requested by the application. In addition to `openid` and `profile`, which are OpenID Connect standard scopes to get the user profile data in an ID token, notice the `read:sensitive-data` scope, which is a specific permission request to access the user's sensitive data.
- **BindingMessage**. This is a message displayed on the user's device to let them know about the request. This ensures that the action taken on the authentication device (the user's phone) is related to the request sent by the application.
- **LoginHint**. It's an object containing information to identify the user who should authorize the requester to access their sensitive data.

### Wait for a CIBA response

After the CIBA request is submitted, the backend application waits for a response from Auth0. This response depends on the action taken by the user on their device, so you need to poll the Auth0's `/token` endpoint to get the needed tokens:

```csharp
private async void GetUserData(string userId)
{
  //...other code...
  var isAuthorized = false;
  var isPendingAuthorization = true;
  var cibaTokenResponse = new ClientInitiatedBackchannelAuthorizationTokenResponse();

  while (!isAuthorized && isPendingAuthorization)
  {
    try 
    {
      cibaTokenResponse = await authenticationApiClient.GetTokenAsync(
        new ClientInitiatedBackchannelAuthorizationTokenRequest()
        {
          AuthRequestId = response.AuthRequestId,
          ClientId = Configuration["Auth0:ClientId"],
          ClientSecret = Configuration["Auth0:ClientSecret"]
        });
      
      isAuthorized = true;
      isPendingAuthorization = false;
    } catch (ErrorApiException ex)
    {
      if (ex.ApiError.Error == "authorization_pending") 
        Thread.Sleep(5000);
      else
        isPendingAuthorization = false;
    }
  }
  
  //...other code...
}
```

You can see a few variables that help control the loop you are about to start.

Within this loop, you call the `GetTokenAsync()` method to get a response from Auth0. This method needs an object as its parameter, which includes the request ID and the application credentials.

Until a positive response is received from the user, you will get an `authorization_pending` exception. In this case, you should suspend the current thread and retry after a few seconds. In the example above, the thread waits 5 seconds. If the user denies authorization, you get an `access_denied` exception.

If the user authorizes the request, you get a response in the `cibaTokenResponse` object containing the ID and access tokens.

> You should catch opportunely the exceptions you get and give the user an appropriate message about why the CIBA flow was not completed.

### Use the tokens

Finally, you have the access token that allows you to call the API to get the user's sensitive data:

```csharp
private async void GetUserData(string userId)
{
  //...other code...
  
  if (isAuthorized)
  {
    await LoadSensitiveUserData(cibaTokenResponse..AccessToken);
  }
}
```

We don't go into the details of calling the protected API using the access token. If you need guidance on this, check out [this article](https://auth0.com/blog/call-protected-api-in-aspnet-core/#Use-Your-Access-Token).

> We have omitted the step of validating the tokens received for simplicity, but it is fundamental for the application's security. Read [this article to learn more about token validation in .NET](https://auth0.com/blog/how-to-validate-jwt-dotnet/). Specifically, read [this section](https://auth0.com/blog/how-to-validate-jwt-dotnet/#Validate-a-JWT--By-Hand-) to learn how to validate them without using a middleware, which applies in our case since we are using the Auth0 Authentication API SDK.

## Add CIBA Support to the Mobile App

While this article focuses on the implementation of the backend application, we can't help but provide some information on its mobile counterpart.

First, you should use the [Auth0 Guardian SDK](https://auth0.com/docs/secure/multi-factor-authentication/auth0-guardian) to handle the communication with Auth0 on your mobile app.

While developing your mobile application, you should take care of the following steps in the CIBA flow:

- Your mobile app [receives the push notification](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba#step-4-mobile-application-receives-the-push-notification) from Auth0.
- Then it [retrieves the details of the CIBA request](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba#step-5-mobile-application-retrieves-the-consent-details), in particular, the binding message.
- The app [presents the binding message to the user](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba#step-6-mobile-application-presents-the-consent-details-to-the-user), asking them to accept or deny the request.
- Finally, it manages the user's response by [sending it back to Auth0](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba#step-7-mobile-application-sends-the-user-response-back-to-auth0).

## Summary

This article has given you a high-level idea of what CIBA is and in what scenarios you can use it.
Then, you learned how to configure your Auth0 tenant and application to support CIBA. So, you have seen how to integrate CIBA into a .NET application that runs on a server and what steps to consider when developing the mobile counterpart.

Stay tuned for future evolutions of CIBA support in Auth0.

Use CIBA Authentication with Auth0 and .NET

samantha-murphy

Samantha Murphy is a Principal Product Marketing Manager for Okta. She leads the Customer Identity Security portfolio, driving go-to-market strategy, messaging, launches, and strategic growth initiatives. Before Okta, Sam spent over six years in product management roles in Identity and Access Management.

She holds a Bachelor of Commerce degree from Queen’s Smith School of Business and is from Ottawa, Canada.

In her free time, Sam makes the most of winter by playing an awesome ice skating sport called ringette.

Principal Product Marketing Manager, Customer Identity

Samantha Murphy

Find out how you can improve your customers' security and authentication experience using CIBA.

Imagine you're a customer trying to resolve an urgent issue over the phone—for example, a bank transaction, an online order, or a technical support request. Before the agent can help, they need to verify your identity. They ask you for your security passcode, which you’ve forgotten. Then come the security questions: your birthday, your last bank transaction, your best friend's name. These questions are easily compromised and create security concerns.

This frustrating experience is all too common across industries. From financial services to retail, organizations face the challenge of verifying customers securely and efficiently for online, over-the-phone, and in-person interactions. That's where CIBA comes in.

In this blog post, we’ll explore how our new [**Client-Initiated Backchannel Authentication (CIBA**](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba)**)** feature, part of Auth0, improves customer authentication for call centers and in-person interactions. CIBA makes authentication faster, more secure, and eliminates the need for outdated PINs or security questions.

## Moving Beyond Less Secure Security Questions and OTPs

Call centers are just one out-of-band scenario currently burdened with inconvenient and insecure authentication protocols. Say you’re trying to verify your Identity so you can personalize the settings in your new car, but in order to do so you need to go through a cumbersome process: open the car’s app, scan a QR code, open a browser and log in –all before you can update your personal settings. Or maybe you’re trying to pick up a retail order in person, but in order to do so, you need to authenticate yourself with security questions or personal information. The problem is that these questions are vulnerable to data breaches and phishing attacks (just like passwords) and revealing private information directly to agents creates obvious privacy concerns that customers shouldn’t have to deal with.

Some organizations may try to get around this by using SMS or emailing one-time passwords (OTPs). However, these methods often introduce an additional, cumbersome step into the authentication process and present security challenges. SMS for example is vulnerable to SIM Swapping, which allows attackers to intercept SMS OTPs. Email OTP assumes that the email account is secure, which may not be the case. Plus, both email and SMS OTPs are vulnerable to the typical phishing and social engineering attacks that trick people into compromising their OTP, and they lack biometric authentication methods (e.g. face ID, fingerprint, etc.).

CIBA offers a more consumer-friendly and secure way of authenticating “out-of-band” customers.

## CIBA: A Superior Approach to Out-of-Band Authentication

Safe, seamless brand experiences go beyond the login box. They extend to critical customer touchpoints—like when customers seek support over the phone, online, or in person. CIBA empowers businesses to deliver **both enhanced security and a smoother user experience**, leading to stronger customer satisfaction and better business outcomes. Let’s unpack what CIBA is and how it drives business success:

**Client Initiated Backchannel Authentication (CIBA)**—also known as a **decoupled authentication flow**—is a protocol that enables a client application (e.g., call center systems, POS terminals, in-person service tools, or autonomous AI Agents) to initiate the authentication process on behalf of the customer.

Let’s walk through an example workflow.

A user would like to withdraw from their bank and agrees to initiate the CIBA mobile app verification process.

![Initiate the CIBA verification process](https://images.ctfassets.net/23aumh6u8s0i/4Z2y3Etq6z8cYdxMHwEHDJ/636c00a03bb28fc64e73e1daebff455d/Uploaded_from_Okta_CIBA_blog_v1)

Right away, the user gets a notification on their phone to approve the request and authenticates with biometrics through the app.

![CIBA flow: the user gets a notification on your device](https://images.ctfassets.net/23aumh6u8s0i/3F7yYxI2qaHLys12sLQcuB/dcb6b0227f0388a95f369023b95f69f3/Uploaded_from_Okta_CIBA_blog_v1)

Lastly, the user approves the request and seamlessly and securely continues their withdrawal.

![CIBA flow: User approves the authentication request](https://images.ctfassets.net/23aumh6u8s0i/QOu1PqIN7gV6Bn5Mars8Q/bd13772e469354c82bfb62a0c780c77a/Uploaded_from_Okta_CIBA_blog_v1)

## Achieving Better Business with CIBA

CIBA improves your business and your customer experience with some great features:

### Stronger Security and Privacy

Traditional out-of-band authentication methods, like security questions or email/SMS one-time passwords (OTPs), are insecure and frustrating. CIBA replaces these outdated approaches with **secure, seamless in-app biometric authentication** (e.g., Face ID or fingerprint). A simple push notification lets customers verify their identity effortlessly with **just one tap**, without sharing sensitive personal information.

### A Financial-Grade Protocol

Trusted by financial institutions, CIBA is a **financial-grade protocol** that provides stronger safeguards against phishing and data breaches. By securing highly sensitive customer interactions, CIBA acts as a **robust fraud prevention tool**, protecting both businesses and customers from scams and breaches.

### Non-Repudiation for Trust

A CIBA authentication flow with the [Guardian mobile SDK](https://auth0.com/docs/secure/multi-factor-authentication/auth0-guardian) supports **non-repudiation**—so that neither party in a communication can deny their involvement. For example, in a call center scenario, this prevents customers or agents from disputing that certain information was exchanged. Non-repudiation builds trust and ensures authenticity for sensitive interactions.

### Enhanced Customer Experience (CX)

CIBA delivers smoother CX with **one-tap in-app authentication** —no browser redirects. This simple, efficient flow reduces abandonment rates, increases app engagement, and empowers customer-facing teams to drive satisfaction and business growth.

With [**Auth0 Guardian SDK**](https://auth0.com/docs/secure/multi-factor-authentication/auth0-guardian), you can further enhance CX by customizing every aspect of the CIBA customer journey to reflect your brand and meet unique business needs—creating an experience that’s as secure as it is smooth.

## CIBA in Action: Real-World Examples

A decoupled authentication flow leveraging CIBA adds a much-needed security boost to sensitive interactions, all while supporting seamless customer experiences across a number of different scenarios and use cases:

*   **Call center verification**.
Say you’re a financial services institution, and a customer is calling in to request help with their bank account. Using CIBA, the bank teller can authenticate the customer by sending a push notification to the banking app your customer has installed on their phone. There, they can confirm their identity using the already-enabled biometric sign-in. No more asking customers to share SMS passcodes or make their social security numbers, and (forgotten!) answers to security questions vulnerable by speaking them out loud.

*   **In-person verification**.
In all kinds of in-person scenarios (e.g., withdrawing money at a bank, checking into a hospital, picking up meds at the pharmacy) CIBA gives employees the option of confirming customers’ Identity in real-time by initiating a push notification sent immediately to their phone. The alternative in these situations is often asking customers to present physical documentation such as utility bills or their driver's licenses––an insecure authentication method that can leave customers vulnerable to fraud if they are stolen or compromised.

*   **Connected device verification**.
CIBA also allows internet-connected devices to initiate push notifications in IoT scenarios. For example, if a customer is registering a new car and customizing their settings, CIBA lets them kick off this process in an easy, authenticated manner by confirming their Identity through a push sent directly to a consumer app. Not only is this a more secure means of authentication, it also allows customers to avoid clunky options currently on the market, e.g., scanning a QR code that redirects to the app.

*   **POS terminal**.
In a retail environment that increasingly favors hybrid shopping experiences (e.g. ordering furniture online and picking it up in person) a CIBA flow allows customers to confirm their Identity on-site through self-serve kiosks that initiate a push notification sent to the customer’s phone. This not only keeps the transaction secure, but it also eases any labor constraints retailers might be experiencing by preventing employees from getting roped into the authentication process.

**Better security. Better CX. Better business.**.
CIBA represents a new addition to the security toolbelt for organizations looking for a more secure, more seamless way of authenticating users in call center scenarios and beyond.

Curious about where CIBA can improve your operations––and your bottom line? [Schedule a demo with your account rep](https://auth0.com/contact-us) to see it in action.

CIBA: Authenticate Customers in Call Centers and Other Out-of-Band Scenarios

carla_urrea

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

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

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

Senior Developer Advocate

Carla Urrea Stabile

Native login with passkeys is now available, so let’s take a look at how to sign up and log in on Android using Auth0’s Native Login.

How to Sign Up and Log In with Passkeys in Android Using Auth0's Native Login

Haley Bourke

Sr. Site Reliability Engineer

A Beginner’s Guide to Understanding Password Authentication Protocol (PAP)

For modern developers, securing user data is more critical than ever. Ensuring that your applications implement reliable and effective authentication methods is a fundamental part of protecting both your users and your system.

[Password Authentication Protocol (PAP)](https://www.okta.com/identity-101/pap-security) serves as a starting point in understanding how to authenticate users. As one of the simplest such protocols, understanding how PAP works provides a foundation for a developer’s understanding of authentication. 

In this article, we will provide a high-level overview of PAP, surveying its role in application security as well as its limitations. We’ll see how leveraging platforms like Auth0 can help you to implement secure, scalable authentication, freeing you to focus on the best experience possible for your users. 

## So What Is It?

Password Authentication Protocol (PAP) is a method for authenticating human users (or devices, service accounts, etc.) by verifying their credentials.

PAP is used with Point-to-Point Protocol (PPP). PPP is a data link layer protocol used to establish direct communication between two network nodes. PPP supports various[ authentication protocols](https://www.okta.com/identity-101/authentication-protocols/), as we shall see. Before establishing a network connection between the two nodes (client and server), the identity of the client must first be verified via one of these supported protocols. 

PAP is just one of the protocols that PPP supports and is one of the simplest to understand. As we will see, PAP has its drawbacks, but its strength is its simplicity.

## Password Authentication Protocol (PAP) vs. Challenge Handshake Authentication Protocol (CHAP)

PAP is a two-way handshake: a client requests authentication, and a server responds. Passwords are delivered in plain text. The system then verifies that the credentials match what is stored for that user and responds with an ack or nack as appropriate.

You may begin to see a problem here. Since the password is sent across the network as regular text, PAP is not the most secure method.

In contrast to the two-way handshake and plain text password of PAP, CHAP is a _three-way_ handshake process.

In a system that uses CHAP, the server first sends a “challenge” to the client. This challenge could be a random string. The client then combines the challenge string with the user’s password and sends back a hash of the combination. If the client’s hash of the challenge + password combo matches the server’s, the user is authenticated.

As we can see, the CHAP process is more secure than PAP since the password itself in plain text is never sent across the network; only the challenge + password hash is. If that hash were to be intercepted, the hacker would not necessarily be able to decipher the user’s password. To provide additional security, the “challenge” word can be rotated periodically to ensure that if the challenge word were to be leaked or deciphered, the hacker would not be able to use it indefinitely to intercept and decipher traffic.

### Why Use PAP?

Now that you understand what PAP is and why CHAP can provide an extra layer of security, you may wonder, why use PAP at all?

Unfortunately, some systems, like certain legacy systems, may not support CHAP as a protocol. Some systems may also use multiple vendors under the hood when authenticating, each with differing CHAP variations, complicating implementations. In these cases, we may elect to use PAP in combination with some other layer or layers of security.

A hybrid approach is also an option: authenticate via the CHAP process if possible, but fall back to PAP if the CHAP method fails.

When using PAP, it is important to be aware of its limitations. It is a good idea to provide encryption at another layer of your system, for example, via SSL, TLS, or VPN.

## PAP and Auth0

While PAP is a foundational authentication method, as we have seen, its simplicity can pose security risks in modern applications. Implementing a robust and scalable authentication layer to your application can be difficult and time-consuming.

That’s where [Auth0](https://auth0.com/) comes in. With Auth0, you can easily implement and manage authentication in your application securely. Auth0 abstracts away the intricacies, saving valuable developer time while ensuring the highest security standards for your users.

## Recap

In this article, we learned about PAP and CHAP, their strengths and limitations, and when to use each of them.
Now that you have a basic foundation on authentication protocols, you may wish to explore more via the links provided below. 

## Additional Learning

* [Learn more about the security behind PAP](https://www.okta.com/identity-101/pap-security/).
* [Authentication Protocols 101](https://www.okta.com/identity-101/authentication-protocols/).
* [Oracle documentation on how to edit the PPP Path configuration file](https://docs.oracle.com/cd/E19096-01/sol.ppp301/805-4018/6j3qil152/index.html).
* [Academic article on Point-to-Point Protocol](https://www.sciencedirect.com/topics/computer-science/point-to-point-protocol).

What is Password Authentication Protocol?

Learn how to prevent CSRF attacks from compromising your users when implementing Google OAuth for user registration and user login.

Growing an active user base is a top priority for all developers. Your product pages need copy, design, and engineering that can efficiently and effectively convert visitors into users. A visitor is an anonymous person browsing your site or app. A user is a visitor who exchanges some information to access more layers or features of your app. Even with just an email address or username, you can build a profile or identity for a user.

As such, user authentication is the backbone of conversion. User registration and login must be secure and as frictionless as possible. Long and tedious forms or requirements during registration can turn prospects away. Errors or downtime during login can frustrate even your most loyal customers, leading to dissatisfaction or support tickets.

## Why Use Google OAuth for User Authentication

A reliable way to implement user registration and authentication in an application and turn visitors into users quickly and securely is by using a registration and authentication system that your visitors already use and trust, such as Google.

As a developer, you can take advantage of Google's high security and trust Google as a source to safeguard user credentials so that you don't have to. Google social login leverages the OAuth 2.0 protocol for authorization and uses [OpenID Connect (OIDC)](https://developers.google.com/identity/openid-connect/openid-connect) as the standard for user authentication. You can delegate to Google's UI/UX and engineering the burden of password requirements, password protection, password error handling, email verification, profile data collection, and more. 

How easy or difficult is it to implement Google Login on your own? It depends. On the surface, it may be like a simple endeavor: In the JavaScript ecosystem, use a library like [`google-auth-library`](https://www.npmjs.com/package/google-auth-library), write a few lines of code, and call it a day.

While `google-auth-library` is a robust client library for using OAuth 2.0 authorization and authentication with Google APIs, it's essential to know how to use it effectively to avoid introducing security vulnerabilities in your application that could put your end-users and your organization at risk.

For instance, a recent [post on X](https://x.com/forgebitz/status/1858616526540042521) went viral: a developer named Klaas shared with the X developer community a code snippet on how to implement "google login with just the google-auth-library, no frameworks in 50 lines of code":

```typescript
export const googleLoginAction = {
  getAuthUrl: () => {
    const query = {
      client_id: oauth_google.client_id,
      redirect_uri: oauth_google.redirect_uri,
      response_type: "code",
      scope: oauth_google.scopes,
    };

    const url = new URL(oauth_google.endpoint);
    url.search = new URLSearchParams(query).toString();
    return url.toString();
  },
  verifyGoogleCode: async ({ code }: { code: string }) => {
    log.info({ code }, "verifying google auth code");

    try {
      const tokenResponse = await fetch("https://oauth2.googleapis.com/token", {
        method: "POST",
        headers: {
          "Content-Type": "application/x-www-form-urlencoded",
        },
        body: new URLSearchParams({
          client_id: oauth_google.client_id,
          client_secret: oauth_google.client_secret,
          code,
          grant_type: "authorization_code",
          redirect_uri: oauth_google.redirect_uri,
        }),
      });

      const tokenData = (await tokenResponse.json()) as { id_token: string };

      const ticket = await client.verifyToken({
        idToken: tokenData.id_token,
        audience: oauth_google.client_id,
      });

      const userData = ticket.getPayload();
      log.info({ userData }, "google auth successful");
    } catch (error) {
      log.error({ error }, "failed to verify google auth code");
      throw new Error("Failed to verify Google authentication");
    }
  },
};
```

Klaas' X post ignited a passionate discussion around user authentication and general security. As of the time of writing, the post had gathered 449k impressions, 4.7k likes, 387 reposts, and 83 comments.

## Google OAuth Implementation Can Go Wrong

Some of the commenters asked questions about the code's security posture, while others offered insights and advice on how to improve the security of that Google OAuth implementation.

Some commenters assumed the code was running on the client and were alarmed by the code handling a client secret, which could lead to a security compromise. Klaas clarified that the code is intended to run in the backend and [further explained its purpose as follows](https://x.com/forgebitz/status/1858776267266441324):

 "_this [code] has two simple functions, create a URL where you redirect the user to and a verify code function, you have the create a /callback (on the server) to get that URL. You still need to make authentication/authorization_"

Some other commenters pointed out that the code could be subject to a [Cross-Site Request Forgery (CSRF) attack](https://en.wikipedia.org/wiki/Cross-site_request_forgery), which confused others: How can there be a CSRF attack if there's no cookie involved or when the code does not run in the client?

First and foremost, let's recap what a Cross-Site Request Forgery (CSRF) attack is. [Andrea Chiarelli](https://auth0.com/blog/authors/andrea-chiarelli), Principal Developer Advocate at Okta, [summarizes a CSRF attack as follows](https://auth0.com/blog/cross-site-request-forgery-csrf/#--What-is-CSRF--):

- A typical Cross-Site Request Forgery (CSRF or XSRF) attack aims to perform an operation in a web application on behalf of a user without their explicit consent.
- The attacker leads the user to perform an action, like clicking a link.
- This action sends an HTTP request to a website on behalf of the user.
- If the user has an active authenticated session on the trusted website, the request is processed as a legitimate request sent by the user.

Andrea warns us that "even though CSRF attacks are commonly associated with session cookies, be aware that [Basic Authentication sessions](https://en.wikipedia.org/wiki/Basic_access_authentication) are also vulnerable to CSRF attacks" and that, in fact, "a CSRF vulnerability relies on the authenticated session management".

[Sandrino Di Mattia](https://x.com/sandrinodm) is a Senior Director on the Product Architecture team at Okta with robust and deep experience in cloud, identity, and security. In the thread, Sandrino commented that the code doesn’t seem to perform any state validation, making it open to CSRF attacks.

You may be wondering like others did: ["CSRF attack without any cookies, must be a new thing"](https://x.com/__morse/status/1858951728852295909). Let's explore how improperly implemented OAuth can lead to a CSRF attack.

## Cross-Site Reference Forgery (CSRF) Are Not About Cookies

Sandrino shares that CSRF is not related to cookies. Missing state validation is the most basic vulnerability in OAuth flows. [OAuth 2.0 specification recommends a `state` parameter](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1) that allows you to verify the authenticated state of your browser. The `state` parameter preserves the browser's authenticated state set by the client in an authorization request, and the authorization server makes it available to the client in the response.

[The `state` parameter helps you mitigate CSRF attacks](https://datatracker.ietf.org/doc/html/rfc6749#section-10.12) by using a unique and non-guessable value associated with each authentication request about to be initiated. That value allows you to prevent the attack by confirming that the value from the response matches the one you sent.

**But how does a CSRF attack work without cookies?**

Sandrino explains that an attacker can go through the OAuth flow but stop right when the redirect with the authorization code to the callback URL happens. Now, the attacker can send the link to the callback URL, including the code, to the victim, which consumes the code on their machine.

Depending on the implementation of your application, a few security, privacy, and data exploits could happen. For example, the attacker's account is now forced on the victim’s browser. The victim now could be uploading docs or filling in and sending personal data to the attacker's account, thinking it’s the victim's account. Or a worse scenario: the victim is already signed in, and now this new identity (the attacker's identity) is automatically linked to the victim's existing account.

## Prevent CSRF Attacks in Google OAuth

Sandrino advises us that preventing this type of attack takes a few lines of code. In practice, on redirect, you store a random value in a cookie. You then send that value to Google using the `state` param. On callback, you validate the incoming `state` parameter with the value in the cookie. If the `state` value in the response does not match the `state` value in the cookie, you reject the login operation and stop further access. The `state` parameter and PKCE can help prevent this type of attack.

> For a deep dive on this topic, you can consult the ["More Guidelines Than Rules: CSRF Vulnerabilities from Noncompliant OAuth 2.0 Implementations"](https://www.cise.ufl.edu/~butler/pubs/dimva15.pdf) paper from the Georgia Institute of Technology and the University of Florida. Check out section 3.3 on page 8.

There's a saying that goes: "You don't know what you don't know". But then, how can you know? By doing precisely what Klaas did: share code with others and be open to feedback and constructive criticism. At the same time, you can leverage the knowledge and expertise of others who have been through similar and more complex situations, which can help you avoid falling into traps or dangerous holes.

You may be thinking, "I can rely on AI for that!" You can use AI tools to learn and understand, but remember that those tools are imperfect, as they are an aggregation of human knowledge and can also make mistakes. There are instances where an AI tool can present you with "security" code with high confidence. Still, that code could be anything but secure, missing the implementation of security best practices or defensive mechanisms.

## Use Libraries to Implement Google OAuth 

It's important to highlight that if you want to implement a standard protocol yourself, you need to understand its specifications well, be aware of its nuances, and follow its details diligently. Instruments like the `state` parameter and all other security measures included in specifications and standards are the result of discussions and experience of industry experts throughout the years.

As developers, we often fall into the dilemma of reinventing the wheel (do it yourself) or relying on those who have already done it in the best way (use a library).

Sandrino suggested in the thread that it's better to use a library like Passport.js over the code shared on the tweet&mdash;or rather, X post. Passport.js implements OAuth 2.0 the way that the standard defines it. You can inspect the implementation of Google OAuth in Passport.js by looking at the [`lib/strategy.js`](https://github.com/jaredhanson/passport-google-oauth2/blob/master/lib/strategy.js) file of the [`passport-google-oauth20`](https://github.com/jaredhanson/passport-google-oauth2/tree/master) npm package.

The `OAuth2Strategy` from Passport is well-documented. The comments in the code can quickly guide you on what's happening through that flow:

- The Google authentication strategy authenticates requests by delegating to Google using the OAuth 2.0 protocol.
Applications must supply a `verify` callback function that accepts an `accessToken`, `refreshToken`, and service-specific `profile` and then calls another `cb` callback function, supplying a `user`. The `user` value should be set to `false` if the credentials are invalid. If an exception occurs, `err` should be set.

Let's see an example of how you'd use Google OAuth login with Passport.js:

```javascript
passport.use(new GoogleStrategy({
    clientID: '123-456-789',
       clientSecret: 'shhh-its-a-secret'
       callbackURL: 'https://www.example.net/auth/google/callback'
     },
     function(accessToken, refreshToken, profile, cb) {
       User.findOrCreate(..., function (err, user) {
         cb(err, user);
       });
     }
));
```

As you inspect the implementation code, you'll notice that Passport.js does much more than handle the login. [OAuth 2.0 provides consented access and restricts actions](https://auth0.com/intro-to-iam/what-is-oauth-2) of what a client app can perform on resources on behalf of the user without users ever sharing their credentials with the application. Using Google OAuth 2.0, you can also request access to user contacts and other resources on the Google platform. As the needs of your application scale, you may see yourself needing a more complex data access policy that calls for more code to write and maintain and more scenarios and edge cases to be aware of.

## Google OAuth Attacks Go Beyond CSRF Attacks

Security is an ever-evolving landscape. It's critical for you to stay on the vanguard regarding security in the industry, especially with the rise of artificial intelligence (AI). Implementing authentication on your own is an investment in money, risk, and time. Relying on robust, time-tested libraries or identity service providers can minimize some of those costs.

As mentioned in the post, implementing social login with Google OAuth for your app is just one piece of the authentication puzzle. Once you have users, you are responsible for protecting the data they entrust you. For example, depending on the region where you operate, you may be subject to regulations around user management and privacy, such as GDPR, which also extends to logs, not just the user data you have in your databases.

As you scale and grow in popularity, you may also gain unwanted attention from bad actors and attackers who may want what you are securing: rich user data. But, even on a small scale, you may become the target of bad actors looking to test their skills to break into apps.

> Recommended read: [The biggest underestimated security threat of today](https://techcrunch.com/2024/11/01/the-biggest-underestimated-security-threat-of-today-advanced-persistent-teenagers/)

In the X thread we have been discussing, Jared Hanson, the creator of Passport.js and a Principal Product Architect at Okta, validated that "checking a nonce or state is highly recommended." Jared added, "It’s less simple, but it protects against common attacks."

[Aaron Parecki](https://aaronparecki.com/), Director of Identity Standards at Okta, reminded me that it's not just CSRF attacks that are the concern when it comes to OAuth 2.0 flows. Even if you fix the CSRF attacks we have described, you could still be open to an OAuth 2.0 authorization code injection attack, which you can prevent with PKCE. You can learn more about that type of attack by watching the video below: 

<AmpContent>
<amp-youtube
    data-videoid="1ot45WwQWJE"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div className='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/1ot45WwQWJE' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

Aaron also hosted an "OAuth Happy Hour", which includes [a demo of the authorization code injection attack](https://www.youtube.com/watch?v=moQidjdV5cw). Be sure to check it out!

Let us know if you'd like a detailed follow-up blog post covering the OAuth 2.0 authorization code injection attack.

## Aside: Use Auth0 to Implement Google Social Login

Auth0 makes it even easier to get started with Google. Every new tenant has the Google social connection enabled by default. You don't even have to set up a Google Cloud project to see Google social login in action. Auth0 maintains a set of developer keys you can use to start testing Google social login in your applications in development. Follow the ["Google Social Connection to Login"](https://developer.auth0.com/resources/labs/authentication/google-social-connection-to-login#introduction) lab to learn how to use those Google dev keys and set up ones for production.


Prevent CSRF Attacks in OAuth 2.0 Implementations

peterfernandez_360

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

Peter Fernandez

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

Demystifying Multi-Tenancy in a B2B SaaS Application

With .NET 9.0, some interesting authentication and authorization features have been added to the platform. Let’s take an overview of them.

.NET 9 introduces interesting new features, primarily focused on cloud-native development and performance. However, the [list of improvements](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-9/overview) in other areas of the platform is long. This article will focus on the main innovations introduced by .NET 9.0 in authentication and authorization.

## Support for Pushed Authorization Requests (PAR)

One of the most interesting features brought by .NET 9.0 is support for [Pushed Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9126) (PAR), an OAuth 2.0 and OpenID Connect extension that strengthens the security profile of these protocols. PAR allows applications to not expose the parameters of an authorization request through the browser. Instead, it enables direct communication of these parameters between the application and the authorization server. This is very important when you implement applications in a high-security context, such as in the financial, healthcare, or other regulated sectors. If you want to learn the details of [how PAR works, read this article](https://auth0.com/blog/what-are-oauth-push-authorization-requests-par).

ASP.NET Core adds support for PAR to the native [OpenID Connect middleware](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.openidconnect.openidconnecthandler). This is a typical configuration of the middleware if you are not using the [Auth0 SDK](https://github.com/auth0/auth0-aspnetcore-authentication):

```csharp
// Program.cs
...
  
builder.services.AddAuthentication(options =>
  {
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
  })
  .AddCookie()
  .AddOpenIdConnect("Auth0", options =>
  {
    options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}";

    options.ClientId = builder.Configuration["Auth0:ClientId"];
    options.ClientSecret = builder.Configuration["Auth0:ClientSecret"];
    options.ResponseType = "code";
});

...
```

If the Identity provider you are using supports PAR, you don't need to do anything different from this. In fact, the OpenID Connect middleware transparently supports PAR by default. In other words, if the middleware detects PAR support by analyzing the standard `.well-known/openid-configuration` discovery document, it automatically leverages the PAR endpoint to pass the authorization request parameters. You can change the default behavior by modifying the value of the new option property `PushedAuthorizationBehavior`. For example, the following setting disables PAR support:

```csharp
// Program.cs
...
  
  .AddOpenIdConnect("Auth0", options =>
  {
    options.Authority = $"https://{builder.Configuration["Auth0:Domain"]}";
    ...
    options.ResponseType = "code";
    
    options.PushedAuthorizationBehavior = PushedAuthorizationBehavior.Disable;
});

...
```

If you want to force your application to use PAR, you can set the value of `PushedAuthorizationBehavior` to `PushedAuthorizationBehavior.Require`. In this case, you get an error if the Identity provider does not support PAR.

Finally, to help customize PAR support, the [`OnPushAuthorization`](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.openidconnect.openidconnectevents.onpushauthorization?view=aspnetcore-9.0#microsoft-aspnetcore-authentication-openidconnect-openidconnectevents-onpushauthorization) event has been added to `OpenIdConnectEvents`.

## OAuth and OIDC Parameters Customization

Staying in the context of the OpenID Connect middleware, now you have a simplified way to add custom parameters to the authorization request. Up to .NET 8, if you wanted to add a custom parameter, such as `audience`, to the authorization request, you had to handle the `OnRedirectToIdentityProvider` event as shown in the following code snippet:

```csharp
// Program.cs
...

.AddOpenIdConnect(options =>
{
  options.Events.OnRedirectToIdentityProvider = context =>
  {
    context.ProtocolMessage.SetParameter("audience", "https://myapi.com");
    return Task.CompletedTask;
  };
});
...
```

> If you are using the [Auth0 SDK for ASP.NET Core](https://github.com/auth0/auth0-aspnetcore-authentication), you already have [an easier way to add the audience parameter](https://github.com/auth0/auth0-aspnetcore-authentication/blob/main/EXAMPLES.md#calling-an-api).

.NET 9 introduces the `AdditionalAuthorizationParameters` option to simplify this process. The previous code is equivalent to the following:

```csharp
// Program.cs
...
  
  .AddOpenIdConnect("Auth0", options =>
  {
    ...
    
    options.AdditionalAuthorizationParameters.Add("audience", "https://myapi.com");
});

...
```

## Configuration Flags for Windows Authentication

When using [HTTP.sys](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/httpsys) as a web server for ASP.NET Core applications on Windows systems, you can now configure [Windows Authentication](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth) by setting two new properties:

- `EnableKerberosCredentialCaching`. If this boolean value is `true`, the Kerberos authentication credentials are cached.
- `CaptureCredentials`. If this boolean value is `true`, the HTTP Server API captures the caller's credentials and uses them for Kerberos or Negotiate authentication.

The following code shows an example of usage of these properties:

```csharp
// Program.cs
...
builder.UseHttpSys(options =>
{
    options.Authentication.Schemes = AuthenticationSchemes.Negotiate;
    options.Authentication.EnableKerberosCredentialCaching = true;
    options.Authentication.CaptureCredentials = true;
});
...
```

## Authentication State Serialization for Blazor Web Apps

If you are a Blazor developer, you know how complicated authentication is since [render modes](https://www.telerik.com/blogs/getting-started-blazor-new-render-modes-net-8) have been introduced in .NET 8. You can get an idea by reading [this excerpt](https://auth0.com/blog/auth0-authentication-blazor-web-apps/#Why-Is-Blazor-Authentication-More-Complicated-Now) from my tutorial on adding authentication to Blazor Web Apps. Basically, in an application model where components can be rendered on the server side, on the client side, and on both sides dynamically, you need to keep the user authentication state in sync between the two sides of your Blazor application. This leads to writing a fair amount of code, as you can see by taking a look [here](https://auth0.com/blog/auth0-authentication-blazor-web-apps/#Syncing-the-Authentication-State). In practice, you need to serialize the user authentication state on the server, then send it to the WebAssembly client, which in turn needs to deserialize it. In addition, both authentication states must be kept in sync in order to reflect on the client side the actual authentication state on the server.

Fortunately, .NET 9 simplifies this approach by providing two new methods:

- `AddAuthenticationStateSerialization()`, which adds the services to serialize the authentication state on the server.
- `AddAuthenticationStateDeserialization()`, which adds the services to deserialize the authentication state in the WebAssembly client.

Instead of creating the serializing and deserializing classes yourself, you can now simply call the two methods respectively on the server and on the client to sync the authentication state.

On the server, you will have:

```csharp
// Program.cs
...
builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization();
...
```

On the client, you will write the following:

```csharp
// Program.cs
...
builder.Services.AddAuthorizationCore();
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddAuthenticationStateDeserialization();
...
```

Read the [documentation](https://learn.microsoft.com/en-us/aspnet/core/blazor/security/server/?view=aspnetcore-9.0&tabs=visual-studio#manage-authentication-state-in-blazor-web-apps) to learn more.

## Conclusion

Although they are not revolutionary innovations in authentication and authorization, these new features are very convenient because they aim to simplify the work of .NET developers.
In particular, PAR support prevents developers from implementing the extension specifications themselves and encourages the adoption of increasingly advanced security. Also, simplifying the serialization and deserialization of the authentication state in Blazor relieves developers of the burden of implementing specific classes, resulting in potentially fewer bugs.

Authentication and Authorization Enhancements in .NET 9.0

Learn how to overcome ASP.NET Core authentication configuration issues when your application is behind a proxy, load balancer, gateway, container, or similar system.

When your ASP.NET Core application runs behind a proxy, a load balancer, or even within a container, its authentication flow may break. Let's try to understand why and what solutions we can adopt.

## The Broken Behavior

You have built your awesome ASP.NET Core application and have integrated it with authentication. Everything works like a charm in your local development environment. It's time to deploy it on your stage environment (or do you prefer to go directly into production? 😏).

Let's assume you don't serve your web application directly through a web server. You may need a slightly more complex infrastructure for several reasons:

- Load balancing, caching, compression, and other performance features.
- Request and response processing.
- Request filtering and other security features.
- Portability, process isolation, and other containerization features.

Whatever your reason is, there are chances that your application will run within a container or behind a reverse proxy, a load balancer, an application gateway, etc. Regardless of the specific function, we can call this intermediary between a client and your application a [proxy](https://en.wikipedia.org/wiki/Proxy_server). The following diagram describes this generic scenario:

![Generic proxy scenario](https://images.ctfassets.net/23aumh6u8s0i/4VCtaFCTenYuMYklZY5NRb/3c3e4eda73f1ef68e93592586f477767/generic-proxy-scenario.png)

In this scenario, your awesome application that was perfectly working in your local development environment may stop working.

The specific error depends on your particular environment and configuration, but typically, the type of error falls into one of the following categories:

- The callback URL uses HTTP instead of HTTPS.
- The callback URL uses an internal domain name instead of the public domain name.
- An unexpected error occurs.

Let's take a look at each of these categories in the following subsections considering a scenario with Auth0 as the Identity provider.

### The callback URL uses HTTP instead of HTTPS

Assume that your application is reachable at the address `https://my-awesome-app.com` and everything is correctly configured on the Auth0 side. When you try to authenticate, you get an error similar to the following:

```shell
Callback URL mismatch.
http://my-awesome-app.com/callback is not in the list of allowed callback URLs.
```

Actually, you have registered the callback URL on the Auth0 side, but your registered its scheme as `https` while the error message reports `http`. Why is your actual callback URL using `http`?

Usually, this type of problem occurs when your application runs within a container service such as [Azure Container Apps](https://learn.microsoft.com/en-us/azure/container-apps/overview), [AWS Elastic Container Service](https://aws.amazon.com/ecs/), or other similar services.

### The callback URL does not use the public domain name

Another possible scenario is when you get an error like the following:

```shell
Callback URL mismatch.
https://localhost/callback is not in the list of allowed callback URLs.
```

You correctly defined the callback URL with your domain &mdash; `my-awesome-app.com` &mdash; on the Auth0 dashboard, but your application builds the callback URL using `localhost`. In some scenarios, the domain of the callback URL can be an internal domain, such as the subdomain name assigned to your application instance by Azure or AWS (e.g., `internal-name.azure.com` or `internal-name.amazonws.com`).

Usually, this issue occurs when an application runs behind services like [Azure Gateway](https://azure.microsoft.com/en-us/products/application-gateway/), [Azure Front Door](https://azure.microsoft.com/en-us/products/frontdoor/), [AWS Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/), [AWS CloudFront](https://aws.amazon.com/cloudfront/), etc. but also behind reverse proxies like [nginx](https://nginx.org/) or [Caddy](https://caddyserver.com/).

### An unexpected error occurs

Other different errors may occur depending on your specific infrastructure. For example, you may experience error messages like the following:

```shell
An unhandled exception occurred while processing the request. Exception: Correlation failed.
```

This does not directly say what the reason for the problem is, but it may depend on the same scenario we are going to illustrate in a moment.

### A few considerations

Let's consider a few things before analyzing the issue that may cause this type of error and how to solve it.

We mentioned Blazor as the framework used for building your awesome application, but consider it just an example. Any ASP.NET Core-based framework is subject to the problem we described: ASP.NET Core MVC, Blazor, and Razor Pages.

Also, we are using Auth0 as an example of an OpenID Connect Identity provider, but this is NOT a problem on the Auth0 side or the side of other identity providers. It's not even an OpenID Connect problem. As you will learn, it's a problem of ASP.NET Core. Specifically it's a problem with the [OpenID Connect middleware](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.openidconnect).

> More in general, the problem may affect any web application regardless of its development stack, but we are focusing on ASP.NET Core because of its specific behavior and solution.

## Why Does My Application Not Work?

To understand why these problems occur, you need to know how the ASP.NET Core OpenID Connect middleware works internally &mdash; at least at a high level &mdash; and how the HTTP traffic flows in an infrastructure where proxies are included.

### How OpenID Connect middleware works

To implement user authentication using OpenID Connect, you should implement the details of the [protocol](https://openid.net/specs/openid-connect-core-1_0.html). This would be a daunting task, but fortunately, ASP.NET Core provides specific middleware that alleviates some of this burden.

> The [Auth0 SDK for ASP.NET Core](https://github.com/auth0/auth0-aspnetcore-authentication) makes things even easier, but it also relies on the OpenID Connect middleware, so you cannot avoid the problems we are dealing with here.

Without going into the details of the protocol, one of the tasks of the middleware is to build the URL of the application to which the user's browser will be redirected after authentication. Through this URL, the application receives the authorization code that enables it to get the ID and access tokens. This URL is the so-called **redirect URI** or **callback URL**.

The middleware automatically builds this URL based on internal parameters and uses some properties of the HTTP request to build the base URL.

For example, suppose the middleware handles an HTTP request to `https://example.com/login`. The callback URL will be built as `https://example.com/signin-oidc`.

> If you are using the [Auth0 SDK for ASP.NET Core](https://github.com/auth0/auth0-aspnetcore-authentication), the default callback URL will be `https://example.com/callback`.

As you can see, the base path of the callback URL is the same as the request URL.

### HTTP requests and proxies

Consider the diagram shown above:

![Generic proxy scenario](https://images.ctfassets.net/23aumh6u8s0i/4VCtaFCTenYuMYklZY5NRb/3c3e4eda73f1ef68e93592586f477767/generic-proxy-scenario.png)

As said, the proxy between the client and your application can have several tasks. Reverse proxying is one of these tasks. Basically, a [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy) accepts requests from a client and forwards them to one or more applications.

In some scenarios, the reverse proxy is also used as [TLS termination proxy](https://en.wikipedia.org/wiki/TLS_termination_proxy): it encrypts and decrypts communications outside your hosting infrastructure via TLS tunnels. In other words, a reverse proxy accepts secure HTTPS requests but uses plain HTTP to forward the request internally, as highlighted in the following diagram:

![TLS reverse proxy scenario](https://images.ctfassets.net/23aumh6u8s0i/7zUeXNHMR82jeAdX6DyKwC/4443d5a0f9289a16a460b64d2ac85fa7/tls-reverse-proxy-scenario.png)

In this case, your application will receive a request to `http://example.com` and then the middleware will build  `http://example.com/signin-oidc` as the callback URL. This will differ from the allowed callback URL you registered with Auth0, and this is why you will get the first case of error: your callback URL has the HTTP scheme instead of HTTPS.

> We mentioned earlier that the HTTP vs. HTTPS issue often affects applications running within a container service. The reason is that these services use a proxy to route the traffic, and this proxy provides [TLS termination](https://en.wikipedia.org/wiki/TLS_termination_proxy).

In the example above, we supposed that the internal domain name of your application instance is the same as the public one: `example.com`. This rarely happens. Usually, your internal application instance is reachable through an IP address or an internal name, such as `my-app-instance.example.com`, as shown below:

![Reverse proxy internal name scenario](https://images.ctfassets.net/23aumh6u8s0i/1SIzuxF8qhmNPPSZrkBrS4/92126bb3cb0215effb4bfa69b493a474/reverse-proxy-internal-name-scenario.png)

In this case, your application will receive a request to `https://my-app-instance.example.com` and the middleware will build a callback URL as `https://my-app-instance.example.com/signin-oidc`. Again, this URL differs from the allowed callback URL you registered with Auth0. By the way, depending on the configuration of your hosting environment, the internal URL of your application may not be publicly reachable.

Different error messages may arise in other scenarios or configurations, but often the problems are related to this difference between the public address and the internal address of your application.

<include src="Auth0TemplatesForDotnetCTA" />

## How to Fix the Broken Behavior

Once you understand why these errors occur, it's time to learn how to fix these issues.

As you learned in the previous section, when your ASP.NET Core application runs behind a reverse proxy, load balancer, or similar network component, it may lose access to some information coming with the original HTTP request. You need a way to access this information and provide it to the OpenID Connect middleware to build a correct callback URL.

### Meet the `X-Forwarded-*` headers

Most reverse proxies forward the original HTTP request data through specific HTTP headers. The most common are:

- `X-Forwarded-For`. This header contains the IP address of the original client.
- `X-Forwarded-Host`. This one has the original value of the `Host` header included in the original client's request.
- `X-Forwarded-Proto`. In this header, you can find the protocol used for the original request &mdash; HTTP or HTTPS.

Thanks to these headers, you can access the relevant values of the original HTTP request and build your callback URL correctly.

Despite what is commonly thought, `X-Forwarded-*` headers do not derive from an official standard but are so widely used that they can be considered a de facto standard. Actually a [standard](https://datatracker.ietf.org/doc/html/rfc7239) exists and it's based on a single header: [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded). However, the `X-Forwarded-*` headers are still more popular.

> Make sure your proxy is correctly configured in order to trust the values forwarded via `X-Forwarded-*` headers. In fact, the client's request may go through a chain of proxies on the Internet, and if your proxy simply forwards the  `X-Forwarded-*` headers it receives, you may be exposed to security risks.  Well-configured proxies don’t accept forwarded headers. Instead, they populate these headers with reliable values like the TCP connection and original HTTP headers such as `Host`.
> Read [this article](https://blog.ircmaxell.com/2012/11/anatomy-of-attack-how-i-hacked.html) for an example of security issues to which a misconfigured proxy can lead.

### Using Forwarded Headers middleware

Fortunately, you don't need to directly access HTTP requests to extract the values of `X-Forwarded-*` headers. ASP.NET Core provides you with middleware that simplifies your life: the *Forwarded Headers middleware* implemented by the [ForwardedHeadersMiddleware](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.httpoverrides.forwardedheadersmiddleware) class.

Basically, this middleware extracts the original values of the client request forwarded by the proxy and makes them available to you as first-hand values of the `Request` object. This saves you from writing specific code for your application when it runs behind a proxy.

To enable the Forwarded Headers middleware, include it in the request pipeline of your application by adding the line highlighted below to your `Program.cs` file:

```csharp
// Program.cs

//...existing code

var app = builder.Build();

//👇 new code
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
  ForwardedHeaders = ForwardedHeaders.XForwardedProto |
                     ForwardedHeaders.XForwardedHost;
});
//👆 new code

app.UseAuthentication();

//...existing code
```

> Make sure you call the `UseForwardedHeaders()` method before other middleware. The middleware order is important, and adding it as the first middleware in the request pipeline ensures that the values of the original request are propagated consistently.

In the example above, you enabled the mapping of the `X-Forwarded-Proto` and `X-Forwarded-Host` headers, which are needed to make the OpenID Connect middleware build the callback URL correctly. In addition, any statement that accesses `HttpContext.Request.Scheme` and `HttpContext.Request.Host` will get the value coming from the original request.

Optionally, you can also configure the Forwarded Headers middleware to only accept `X-Forwarded-*` headers coming from a trusted proxy, as shown in the following code snippet:

```csharp
// Program.cs

//...existing code

var app = builder.Build();

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
  ForwardedHeaders = ForwardedHeaders.XForwardedProto |
                     ForwardedHeaders.XForwardedHost;
  KnownProxies.Add(IPAddress.Parse("10.0.0.42"); //👈 new code
});

//...existing code
```

You can also add multiple trusted proxies and configure the middleware to accept custom header names. See the [documentation](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer) for more details.

> Not all proxies or other network appliances add the `X-Forwarded-*` headers by default. They may need additional configuration. Consult their documentation to learn how to configure it.

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

### No code alternative?

If you don't want to or cannot change the code of your ASP.NET Core application, an alternative exists. You can set the environment variable `ASPNETCORE_FORWARDEDHEADERS_ENABLED` to `true`, and the Forwarded Headers middleware is automatically added to the request pipeline and configured.

While this approach is very convenient, unfortunately [it only maps](https://github.com/dotnet/aspnetcore/blob/v8.0.10/src/DefaultBuilder/src/ForwardedHeadersOptionsSetup.cs) the `X-Forwarded-For` and `X-Forwarded-Proto` headers. This means that it could not be sufficient if your scenario also requires using the original host name, as in the authentication case we are discussing here. Also, consider that this approach does not allow you to define your trusted proxies and handle customized headers.

## Conclusion

Now you know the type of errors you can run into when you publish your application on an infrastructure a little more complex than a simple web server.

We have explored a number of cases where OpenID Connect-based authentication no longer works due to the loss of original HTTP request information. However, we have seen how to fix the problem simply by using the Forwarded Headers middleware.

Before concluding, we want to highlight that this type of problem is related to more than just authentication. It involves any functionality that requires dynamic URL generation, as well as client geolocation and other processing based on the client's original request. For more information on the different scenarios, see [this document](https://learn.microsoft.com/en-us/azure/architecture/best-practices/host-name-preservation).


ASP.NET Core Authentication Behind Proxies

Ramona-Schwering_square

Ramona, a Developer Advocate at Auth0, bridges roles as a tester and developer. She's a Google Dev Expert in Web Tech, Women Techmaker Ambassador, and Cypress Ambassador, building trust in test automation and identity topics.

Developer Advocate

Ramona Schwering

We're excited to announce the general availability of Auth0 Forms, a powerful visual editor that empowers you to create custom, dynamic forms that integrate seamlessly with your authentication flows.

We are thrilled to announce that Auth0 Forms is now **generally available**. Auth0 Forms is a robust visual editor that enables you to create custom, dynamic forms that seamlessly integrate with your authentication workflows. With [Auth0 Forms](https://auth0.com/features/forms), you can enhance customer experiences and save time by eliminating days or weeks of coding. This no-code visual editor allows developers to create personalized sign-up flows tailored to their company's requirements. Explore pre-built templates, debugger mode, multi-language support, and more.

<iframe width="560" height="315" src="https://www.youtube.com/embed/jkzwN2xwO5w?si=CNJZsw1M2wGPXHmW" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

## What's up with Auth0 Forms?

Auth0 Forms is a new feature of the Auth0 identity platform that allows you to use a visual editor to add custom steps and business logic to your authentication flow. You can now create customizable forms to collect user information that you can conditionally trigger when your users go through the login and authentication flow you've designed for your app.

The platform offers a visual, drag-and-drop editor for creating custom forms within login and signup flows. This allows for easy modifications without needing external redirects, simplifying identity workflows. Developers can use the low-code solution to build and manage forms with minimal coding, adding UI components, logic, and branding. Each form consists of a series of steps. In between the steps, you can trigger custom business logic to perform various actions on the data collected in the form. 

![Auth0 Forms Visual Editor](https://images.ctfassets.net/23aumh6u8s0i/7tAL7osVzrUEHQZ50GCCyz/93b8a7a5f951e56a6bdf9a9f8f0c443c/auth0_forms_01.png)

As a whole, a form behaves much like a state machine, where you can have different nodes that represent a state of the machine. In the context of forms, there are the following nodes: Start, Step, Flow, Router and End screen:

* **Start nodes** for managing hidden fields, as they are not visible to the user
* **Step nodes** are the visual representation of the form, such as visible user data input fields
* **Flow nodes** for defining custom logic and integration flows
* **Router nodes** for setting up rules to create conditional logic jumps between nodes
* **Ending screen nodes** for resuming the authentication flow post-submission

Each form must have a start and an end screen node. Within these two nodes, you can add any number of step, flow or router nodes to define the visual representation of your form and control its business logic. Components are dragged into fields using the drag-and-drop builder. 

The system also includes pre-built templates for common scenarios, making creating workflows for tasks like [progressive profiling](https://auth0.com/docs/manage-users/user-accounts/user-profiles/progressive-profiling) and policy acceptance easier. This means you can define conditions that prompt users to provide additional information as they interact with your product. For instance, upon the user's third login, you could request that they fill out their profile.  

<iframe width="560" height="315" src="https://www.youtube.com/embed/qh1NKbyaaJ4?si=IbT-vWCTw2reLs9V" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

Other use cases may include the following examples:

* **Enforce Policies**: If you need to update your policies, you can create logic to verify if users have accepted the latest policies. Depending on that, a custom form will be displayed for users who need to accept those updated policies.
* **Customize Authentication Flows**: Extend and customize your flows with additional steps and custom logic. For example, you can verify email or phone numbers with OTP and account linking, confirm payment details with Stripe, and more.
* **Trigger Custom Actions**: Initiate backend processes or workflows based on user input.
… and much more! 

## Close-up on Auth0 Form’s Features

Are you excited to use Auth0 Forms? 

* Explore our [comprehensive documentation](https://auth0.com/docs/customize/forms) for detailed information and resources. If you’re looking for guidance on your use cases, you might find it in the [template section](https://developer.auth0.com/resources/templates/forms) of our [Developer Center](https://developer.auth0.com). 
* Looking for a more hands-on approach? Explore the [Auth0 Developer Center Labs](https://developer.auth0.com/resources/labs?topic=forms) to explore a variety of use cases and guides on how to build, e.g., progressive Profiling, custom policies, and custom signup steps. 🤓
* If you're curious about examples and how to get started quickly, find a [demo experience](https://forms.auth0.dev/) and try it out. 🚀

![Auth0 Forms Visual Editor](https://images.ctfassets.net/23aumh6u8s0i/3hlVk0QphKHf2P2yOqV3Ht/6b05d9756123e0a07a84edc3c921581a/auth0_forms_02.png)

With Auth0 Forms, you're not just implementing authentication – you're crafting user experiences.
Happy coding! 🚀


Auth0 Forms Is Now Generally Available!

abhi

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

Group Product Manager

Abhishek Ambastha

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

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

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

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

## Can I Use Passkeys With The Free Tier?

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

## Migrating from Passwords to Passkeys

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

<include src= "LearnPasskeysCTA"/>

### Is Auth0 getting Rid of Passwords Entirely?

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

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

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

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

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

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

### What About the Existing Users with Passwords?

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

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

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

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

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

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

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

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

## Enabling Passkeys in Your Auth0 Tenant

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

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

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

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

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

### Are there any prerequisites to enable passkeys?

Yes, passkeys come with specific prerequisites:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Passkeys Configuration at Auth0

### What is Local Enrollment?

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

### What is Progressive Enrollment?

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

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

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

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

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

## Security & Attack Protection with Passkeys

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

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

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

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

### Are Attack Protection Features Applicable to Passkeys?

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

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

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

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

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

## Managing and Handling Passkeys

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

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

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

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

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

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

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

### Can you Use Passkeys with Actions?

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

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

## Account Recovery

### How can users recover their passkeys?

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

### How could users recover an account?

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

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

All You Need To Know About Passkeys at Auth0!

Learn how to authenticate users of your .NET MAUI Blazor application using Auth0.

Add Auth0 Authentication to Blazor Hybrid Apps in .NET MAUI

joey devilla headshot 900px

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

Joey deVilla

Learn how to add authentication (login and logout) to iOS apps built with SwiftUI with Auth0 and the Auth0.Swift package.

Get Started with iOS Authentication using SwiftUI, Part 1: Login and Logout

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

A guide to building B2B SaaS applications using Auth0 and the Auth0 Organizations feature.

A B2B SaaS Application Primer Using Auth0

A step-by-step guide to leveraging OAuth 2.0 when accessing protected APIs via an iOS app built with Swift and integrated with Auth0.

Calling a Protected API from an iOS Swift App

Calah Vargas

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

Associate Manager, PLG

Shreya Gupta

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

Developer Advocate, Startups

How Auth0 enhances this nonprofit startup’s use case

**Challenge:** You’re a nonprofit or startup, or maybe even both, with [digital experiences](https://www.okta.com/blog/2024/03/how-nonprofits-achieve-their-missions-while-delivering-secure-digital-experiences/)— such as an app or a website—and your team wants to implement a third-party user authentication solution with solid security.

If you oversee authentication and authorization at a nonprofit or a startup, the roadblocks to implementing a third-party solution might be endless. Whether you’re a nonprofit trying to reduce non-program expenses or a startup with a limited budget considering rolling your own user authentication, choosing an off-the-shelf solution will allow you to spend even more time focusing on your mission and core product. This means getting your app to market faster and providing a secure experience to your users, donors, volunteers, community members, and more. 

## Species360, a Global Leader in Wildlife Care and Conservation

[Species360](https://species360.org/), an NGO and global leader in wildlife care and conservation, is an example of a nonprofit organization that transitioned its in-house solution to Auth0 by Okta. “Species360 combines passion-based, non-profit operating principles with cutting-edge software development.” ([species360.org](http://species360.org/)) As a tech-forward nonprofit, it started its journey with Auth0 through our [Auth0 for Startups](https://auth0.com/startups) program and then leveraged our [Okta for Good](https://www.okta.com/solutions/nonprofits/) preferential pricing and support. Learn more about Species360’s journey with Okta [here](https://www.okta.com/customers/species-360/). In this article, we’ll dive into Species360’s assessment and implementation processes. 

## Assessment

Species360 wanted to remove Customer Identity and Access Management (CIAM) from its plate and didn’t want to worry about building anything except for a few customizations. Species360’s acquisition of [Hortis](https://www.hortis.com/), the plant collection platform that already used Auth0, influenced the team’s decision to outsource and enabled them to get up and running quickly. “I felt it was better to focus more on the hard cost of outsourcing it [user authentication] to a company that does it as well as we would want to do it anyways.” - Clint Pidlubny, Director of Technology, Species360. 

## Implementation

In order to modernize its ZIMS (Zoological Information Management System) platform, Species360 is overhauling its legacy application software and rearchitecting the future version of its current platform. In parallel to updating its current platform, Species360 is also building a new version of the platform. As the team continued their setup and interacted with the [Auth0 APIs](https://auth0.com/docs/api) and the [React SDKs](https://auth0.com/docs/quickstart/spa/react/01-login), they decided to fully integrate Auth0 into the new version.

![Implementation](https://images.ctfassets.net/23aumh6u8s0i/4fHpU4ns0uH9boHkdvx7UM/d584896a850f9a774281dc80f0dbcd37/Uploaded_from_Species_360_Developer_Blog_-_Draft)

The Species360 team felt that getting the platform set up and configured was simple on their end. For this, they relied on the [Deploy CLI Tool](https://auth0.com/docs/deploy-monitor/deploy-cli-tool) - an Auth0-provided tool that helps you manage your Auth0 tenant configuration, integrating into your development workflows as a standalone CLI or as a node module. They leveraged the tool and SDKs to ensure that the progression between environments could be done programmatically. 

## Valuable Features

In addition, Species360 leveraged [Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) and [Enterprise Connections](https://auth0.com/docs/authenticate/enterprise-connections) for its larger and more sophisticated members who preferred a streamlined user experience with SSO connectivity. Species360 also benefits from these features because sometimes its members have different security standards than it does. Auth0 Enterprise Connections allow users to authenticate with an external, federated identity provider (IdP) such as Azure AD, Google Workspace, PingFederate, and more. 

![Valuable Features](https://images.ctfassets.net/23aumh6u8s0i/3BGSDKHrHCYeTQGvomBc34/ce04769498fe349910e27685aa219620/Uploaded_from_Species_360_Developer_Blog_-_Draft)

Today, Species360 uses Enterprise Connections on both its Zims and Hortis platforms. In fact, on the Hortis platform, that feature has allowed the team to win business where SSO connectivity was a requirement.

Species360 has also configured [SMTP Email Providers](https://auth0.com/docs/customize/email/smtp-email-providers/configure-365-exchange-as-smtp-email-provider), so it can integrate Auth0 capabilities with Microsoft 365 and send emails through its usual email provider. 

![Conclusion](https://images.ctfassets.net/23aumh6u8s0i/2tv0ZtGehGSixJm96KLsCT/391bcdcde32633ff98b5301616265110/Uploaded_from_Species_360_Developer_Blog_-_Draft)

## Conclusion

We’re always interested in learning from our customers - specifically, what advice they would give to someone looking to implement user authentication for the first time. Clint rolled his own auth in the past and said, “APIs are ubiquitous…There’s almost a service for everything. The idea is that I can… get into a startup program—or have access to bring on however many users for free and outsource some of these complex pieces so I don't have to think about them.” **His advice is simple: developers should look externally to see who’s done this better and then leverage that capability.**

<include src="QuoteCard" body="We’re not in the business of user management; we’re in the business of data management for the animal species and our members' facilities. I don't want my team to have to spend an hour a month thinking about the user management side of things because, for us, that's not the value we’re creating." name="Clint Pidlubny" title="Director of Technology" team="" company="Species360" />

## Get Started Today

Auth0 by Okta has discounted offerings for [nonprofits](https://auth0.com/nonprofits/get-started) and [startups](https://auth0.com/startups) alike. We want to help extend your team’s capacity and give your customers, members, donors, volunteers, and communities a secure and flexible way to access your services. [Start building today](https://auth0.com/signup?utm_source=blog&utm_medium=auth0&utm_campaign=productblog).

A Developer’s Journey with User Authentication: Species360

Add Private Key JWT authentication to your .NET application to empower security in sensitive contexts.

Sensitive operations require increased security mechanisms, but at the same time, threat actors are on the rise, so it's crucial to raise the bar on application authentication security, such as using Private Key JWT authentication. Private Key JWT is a secure authentication method for applications to get security tokens from an authorization server. In this article, you will learn when you may need it, how it works, and how to implement it in a .NET application using Auth0.

## When a Client Secret Is Not Enough

In the OAuth 2.0 context, your application needs to authenticate in order to get an ID, access, and refresh token. This means that your application must provide its [credentials](https://auth0.com/docs/secure/application-credentials), typically a client ID and a secret, to the authorization server, such as Auth0.

Sensitive applications typically run in a server environment and are [confidential clients](https://auth0.com/docs/get-started/applications/confidential-and-public-applications#confidential-applications), i.e., applications capable of securely storing their credentials. Typically, these are server-rendered web applications or back-end services and applications that run in a protected environment. [Public clients](https://auth0.com/docs/get-started/applications/confidential-and-public-applications#public-applications), such as Single-Page Applications or mobile apps, can't securely store a secret. They must use [specific flows](https://auth0.com/docs/get-started/applications/confidential-and-public-applications#grant-types) that don't include client authentication, and their level of security is generally less reliable than that of a confidential client.

Although client authentication based on client secret provides a higher level of security for obtaining the access token than a public client flow, there are contexts in which it is considered insufficient. Think of banking or financial contexts, where the highest levels of transaction security must be ensured. Or in the healthcare context, where data confidentiality must be protected.

In these contexts, various regulations (e.g., [Open Banking](https://www.openbanking.org.uk/)) require the use of more secure mechanisms to protect transactions. Among these mechanisms, they require a more secure alternative to client authentication based on client ID and secret.

## Private Key JWT Authentication

[Private Key JWT authentication](https://auth0.com/docs/secure/application-credentials#private-key-jwt-authentication) is a secure alternative to client authentication based on a secret. It's a [standard mechanism](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bearer) that relies on asymmetric cryptography to authenticate your application.

Basically, you generate a private and public key pair. Keep your private key securely stored and accessible to only your application. Don't even share it with Auth0. Share the corresponding public key with Auth0 instead. By nature, the public key is not sensitive data, so even if an attacker manages to catch it, they can't impersonate your application.

When your application needs an access token, it generates a specific JWT, called *assertion*, and signs it with its private key. Then, it sends this assertion to Auth0 in order to authenticate. The following is an example of an HTTP request to authenticate via an assertion:

```bash
curl --request POST \
  --url 'https://<YOUR-AUTH=-DOMAIN>/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=client_credentials \
  --data client_id=<YOUR_CLIENT_ID> \
  --data client_assertion=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi... \
  --data client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer \
  --data audience=<YOUR_API_IDENTIFIER>
```

Auth0 validates the assertion using your application's public key and, if everything is ok, issues your access token.

If you want to learn more details about [how to authenticate with Private Key JWT, read the documentation](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt). If you use one of the Auth0's SDKs, you don't need to build an assertion yourself, as you will see later in this article.

> Private Key JWT authentication is only available with the [Enterprise plan](https://auth0.com/pricing).



## Highly Regulated Identity and Private Key JWT Authentication

As mentioned, Private Key JWT authentication is a secure client authentication method required in business contexts where higher levels of security must be guaranteed, such as in finance, insurance, and healthcare.

To meet customers' needs in this area, Okta has released [Highly Regulated Identity (HRI)](https://auth0.com/docs/secure/highly-regulated-identity), a set of Auth0 features that enable high levels of security standards, such as [Financial Data Exchange](https://financialdataexchange.org/) and [Open Banking](https://www.openbanking.org.uk/), and compliance with widely adopted regulations, such as the [Payment Services Directive (PSD2)](https://www.europeanpaymentscouncil.eu/sites/default/files/infographic/2018-04/EPC%20Infographic_PSD2_April%202018.pdf).

> Highly Regulated Identity is an add-on for the Enterprise plan. For an overview of [Highly Regulated Identity, check out this article](https://auth0.com/blog/elevate-security-and-ux-with-highly-regulated-identity/).

Private Key JWT authentication is available in the Enterprise plan, so you don't need HRI to use it in your applications. However, if you need to use PS256 as the signing algorithm for your assertions, you need HRI on top of your Enterprise plan. HRI also supports [mutual TLS](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-mtls) as another secure mechanism for client authentication using a public-private key pair.

## The Sample Project

To see how to use Private Key JWT authentication in practice, you will use an ASP.NET Core web application that gets users' health data from a protected API. You can download the sample project by running the following command in a window terminal:

```bash
git clone -b starting-point --single-branch https://github.com/auth0-blog/dotnet-private-key-jwt-authentication
```

You will get two .NET projects:

- *HealthCkeckApi*, an ASP.NET Core Web API project that provides the user's health data through a protected endpoint.
- *HealthCheckWebApp*, an ASP.NET Core MVC application that implements the frontend used by the user to get their own health data.

You need an Auth0 account to configure and run the application. If you don't have one, you can <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for free now</a>. Follow the README document to configure and run the application.

Once your application is up and running and you have logged in, you will see a page like the following:

![HealthCheckWebApp home page](https://images.ctfassets.net/23aumh6u8s0i/6sAQuTcGWazJolzmaTzicI/08d8248e7dcec5cd978f11b633512823/healthcheckwebapp-home.png)

By clicking the *Show Health Checks* button, you will see a list of data like the following:

![HealthCheckWebApp checks data](https://images.ctfassets.net/23aumh6u8s0i/3hLebkfhp5Sn552D5tuppl/f2532b77a0f0577bda3d9cc04b3ddf45/healthcheckwebapp-data.png)

You will work on the *HealthCheckWebApp* application, which represents the OAuth confidential client that needs an access token to call the protected API. The current application implementation uses the [Auth0 ASP.NET Core Authentication SDK](https://github.com/auth0/auth0-aspnetcore-authentication) to authenticate the user and get the access token from Auth0 by using its client ID and secret.

You will modify this application to use Private Key JWT authentication instead of client ID and secret.

## Create and Register Your Public Key

Let's start by creating a private and public key pair. Go to the `HealthCheckWebApp` folder and generate your private and public key pair. For example, using [OpenSSL](https://www.openssl.org/) you can create the key pair with the following command:

```bash
openssl genrsa -out app_keys.pem 2048
```

This command generates an `app_keys.pem` file containing the private and public key pair you will use as a credential for your application.

Extract the public key from that file with the following command:

```bash
openssl rsa -in app_keys.pem -outform PEM -pubout -out pub_key.pem
```

You will get a `pub_key.pem` file containing only the public key. You will be sharing the public key with Auth0, while your private key must be kept safe and never shared with anyone.

Go to your [Auth0 dashboard](https://manage.auth0.com/) and open the *Credentials* tab of your application configuration page, as shown in the following image:

![Private Key JWT credentials in the Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/3jt9HLrTXYTOIwYFkPWSVE/d0c86d8b49331d22f461ea5482a78fac/auth0-private-key-jwt-credentials.png)

Select *Private Key JWT*, and a window like the following will show:

![Private Key JWT credential configuration](https://images.ctfassets.net/23aumh6u8s0i/5YiXuI8YceCxplwKghjmd2/0f8e8d8440e27795de4e6666a6f4ece9/auth0-private-key-jwt-configuration.png)

This window allows you to define a Private Key JWT credential for your application. Assign a name for the credential and upload the `pub_key.pem` file containing the public key. Optionally, select the signing algorithm and set an expiration date. Finally, click the *Add Credential* button to save your changes.

You will see your credential appearing below the *Application Authentication* section:

![Auth0 Private Key JWT authentication credential list](https://images.ctfassets.net/23aumh6u8s0i/0yhreNj2u7io7iTPnyRMB/844280997c40fc67565a27eb0b4fb3bb/auth0-private-key-jwt-authentication-credentials-list.png)

> You can add multiple credentials for your application, as you will learn in a moment.

## Get Your Access Token

Your application is now configured to use Private Key JWT authentication on the Auth0 side. Let's adjust the application code to use this authentication method instead of the client ID and secret.

Open the `appsettings.json` file in the `HealthCheckWebApp` folder and remove the `ClientSecret` key. You don't need it anymore. The file's content will be as follows:

```json
// HealthCheckWebApp/appsettings.json

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "Auth0": {
    "Domain": "<YOUR-AUTH=-DOMAIN>",
    "ClientId": "<YOUR-CLIENT-ID>",
    "Audience": "https://myapi.com"
  },
  "HealthCheckApiBaseUrl": "https://localhost:7102"
}
```

Now, edit the `Program.cs` file in the `HealthCheckWebApp` folder by applying the changes highlighted in the following code snippet:

```csharp
// HealthCheckWebApp/Program.cs

// ...existing code...

// 👇 new code
var cryptoProvider = new RSACryptoServiceProvider();
cryptoProvider.ImportFromPem(File.ReadAllText("app_keys.pem"));
var securityKey = new RsaSecurityKey(cryptoProvider);
// 👆 new code

builder.Services
    .AddAuth0WebAppAuthentication(options => {
      options.Domain = builder.Configuration["Auth0:Domain"];
      options.ClientId = builder.Configuration["Auth0:ClientId"];
      // 👇 old code
      //options.ClientSecret = builder.Configuration["Auth0:ClientSecret"];
      options.ClientAssertionSecurityKey = securityKey;
      // 👆 new code
      options.Scope = "openid profile email";
    })
    .WithAccessToken(options =>
      {
          options.Audience = builder.Configuration["Auth0:Audience"];
      });

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

You load the key pair from the `app_keys.pem` file, generate an instance of the `RsaSecurityKey` class from the content of that file, and assign it to the `securityKey` variable. Then, you replace the assignment of the `ClientSecret` option with the `ClientAssertionSecurityKey` option and assign the value of the `securityKey` variable.

You are done! The Auth0 ASP.NET Core Authentication SDK will take care of creating the assertion and authenticate your application with Auth0 to get the access token. You will notice no difference in the behavior of the application, but under the hood your application uses a more secure authentication method to get the access token to call the protected API.

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

## Credential Rotation

When you configured your application to use Private Key JWT authentication, you should have noticed two things:

- You can set an expiration date.
- You can create multiple credentials for the application.

These two optional features allow you to further strengthen the security of Private Key JWT authentication.
In fact, setting an expiration date for a credential is always a good practice, even with secure mechanisms such as Private Key JWT.

However, setting an expiration date can cause some downtime when the old credential expires and the new one has not yet been activated. To avoid this downtime, you can add a new credential before the old one expires. This way, on the application side, you can replace the old credential with the new one before it expires, preventing the application from becoming inoperable.

For more information about credential rotation, see [the documentation](https://auth0.com/docs/get-started/applications/rotate-credentials).

## Summary

Throughout this article, you learned about Private Key JWT authentication and how it increases your application's level of security in obtaining tokens.

Together with other advanced features of Highly Regulated Identity, Private Key JWT helps achieve a high level of security and compliance required in areas such as finance, insurance, and health care.

You also saw how to implement Private Key JWT in a .NET application using the Auth0 SDK, which relieves you of the task of dealing with low-level details.

The final version of the example application code implementing Private Key JWT is available on [GitHub](https://github.com/auth0-blog/dotnet-private-key-jwt-authentication).



Use Private Key JWTs to Authenticate Your .NET Application

milan-khan

Milan is the Product Manager for advanced identity security features for customers operating in highly regulated industries. Milan is especially keen on solving consumer identity problems balancing user experience, security and compliance.

Senior Product Manager

Milan Khan

An introduction to Strong Customer Authentication (SCA), a mechanism for providing a higher level of security in sensitive contexts.

Strong Customer Authentication (or SCA for short) is a versatile authorization mechanism that first made waves in the financial services industry for digital payments, and adoption is picking up pace, even for non-financial transactions.

SCA was enacted in 2019 as a requirement of the [revised European Union (EU) Payment Services Directive (PSD2)](https://www.ecb.europa.eu/press/intro/mip-online/2018/html/1803_revisedpsd.en.html). Its main purpose is to raise security standards and reduce fraud for online and contactless payments, and it's now a part of life for millions of consumers in the EU.

PSD2 and its regulatory technical standards (RTS), along with inputs from the European Banking Authority in the form of opinions, questions, and answers, describe how SCA should be implemented by financial services organizations in EU member states. In summary and in relation to user security and authentication, this means:

- The payer needs to authenticate themselves with multi-factor authentication in order to authorize the payment.
- Multi-factor authentication (MFA) must comprise two (or more) of the following elements: knowledge, possession, and inherence.
- The payer (the consumer) gives informed consent to the payment amount and the payee's account.
- The payment transaction must be (cryptographically) linked to an amount and a payee specified by the payer (known as Dynamic Linking – this is what makes SCA different from typical “step-up MFA”).

In this blog post, we'll explore these SCA components and show how you can implement them using Auth0 by Okta! 

## Exemptions from Applying SCA

Strong Customer Authentication takes a risk-based approach, and there is a provision for exemptions to be applied to SCA. Low-risk scenarios that allow service providers not to apply SCA include:

- Payments to existing payees that have been previously authorized using SCA.
- Payments from one account to another account, where both accounts belong to the same account holder and are with the same service provider.
- The service provider has judged the payment transaction to be low risk through real-time risk and fraud analysis. The level of historic fraud will determine the threshold for amounts that can be exempted from SCA; i.e., lower levels of fraud will mean higher payment amounts can be exempt from SCA.
- Payments transactions below EUR 30 (or local equivalent) are considered "low value" and may be exempt from SCA. Service providers will have to request the payer to perform an SCA if the exemption has been used five times since the payer's last successful SCA or if the sum total of previously exempted payments exceeds EUR 100 (or local equivalent).

## Multi-Factor Authentication &mdash; Something You Know, Have, or Are

As discussed earlier, SCA mandates the use of at least two distinct authentication factors out of the three categories: knowledge, possession, and inherence.

- The **knowledge factor** is something the user knows, such as a password, a personal identification number (PIN), or an answer to a security question.
- The **possession factor** is something the user has, such as a telephone SIM card, a mobile device, or a smart card. Each of these typically has a cryptographic key, so the possession factor is essentially possession of a cryptographic key, preferably the private key of an asymmetric key pair.
- The **inherence factor** is something you are and is typically biometric verification where a user's captured biometric is compared to a reference template. This can be, for example, a fingerprint, facial, or voice biometric.

## Consent

Authorizing payments and any other sensitive transaction requires that the user know what they are authorizing and consenting to. SCA requires the user to view the payee and the payment amount before any authorization.

This concept of providing informed consent can also apply outside of payment scenarios for any sensitive transactions such as:

- Changing login and/or security settings
- Changing user profile settings, e.g., home address
- Sharing personal data

![Strong Customer Authentication user consent](https://images.ctfassets.net/23aumh6u8s0i/6kC16xojBEnAQLynhGuUM/bfb4bbeb85b87c2ab28e00faaff2a1a0/strong-customer-authentication-user-consent.jpg)

## Dynamic Linking &mdash; What Makes SCA Different

Dynamic Linking is what sets SCA apart from a regular step-up authentication prompt. Linking transaction details to the approval prompt allows users to double-check accuracy and avoid transaction tampering before approving the transaction.

When a payer (the consumer) initiates a payment, the transaction itself must be linked to the amount and payee specified by the payer. This dynamic linking generates an “authentication code,” which is unique and specific to the transaction (payee and amount). 

The authentication code is transferred through the payment and authorization processes. Any changes to the payment data (amount, payee) will invalidate the authentication code and, thus, the transaction.

> If you want to learn more about the details of SCA, here are some related documents:
>
>- Revised EU Payment Services Directive “PSD2”: [2015/2366 - EN - Payment Services Directive >- EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32015L2366) 
>- SCA Publication: [Strong customer authentication requirement of PSD2 comes into force - European Commission](https://finance.ec.europa.eu/publications/strong-customer-authentication-requirement-psd2-comes-force_en)
>- Regulatory Technical Standard for SCA: [Delegated regulation - 2018/389 - EN - EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389) 
>- Amendment on the RTS for SCA: [Final Report on the amendment of the RTS on SCA & CSC](https://www.eba.europa.eu/sites/default/files/document_library/Publications/Draft%20Technical%20Standards/2022/EBA-RTS-2022-03%20RTS%20on%20SCA&CSC/1029858/Final%20Report%20on%20the%20amendment%20of%20the%20RTS%20on%20SCA&CSC.pdf) 
>- Opinion of the European Banking Authority on SCA: [Opinion of the European Banking Authority on the implementation of the RTS on SCA and CSC](https://www.eba.europa.eu/sites/default/files/documents/10180/2137845/0f525dc7-0f97-4be7-9ad7-800723365b8e/Opinion%20on%20the%20implementation%20of%20the%20RTS%20on%20SCA%20and%20CSC%20%28EBA-2018-Op-04%29.pdf) 

## Strong Customer Authentication with Auth0 by Okta

[Highly Regulated Identity](https://auth0.com/docs/secure/highly-regulated-identity) (HRI) is a solution suite on the Customer Identity Cloud powered by Auth0 that delivers Financial Grade Identity™ that helps organizations elevate security, privacy, and user experience beyond login. HRI enables developers to meet the high levels of security required by companies operating within highly regulated industries like banking, insurance, and health care. You can also use HRI for other sensitive operations that require enhanced security, such as users updating their account information, admin or security settings, accessing sensitive data or apps, and more.

Here, we look at how Highly Regulated Identity can be used to build a Strong Customer Authentication solution.

### Solution architecture

The diagram below describes a possible architecture and interactions for a Strong Customer Authentication solution built on Auth0 by Okta using HRI features.

![Strong Customer Authentication flow in Auth0 by Okta](https://images.ctfassets.net/23aumh6u8s0i/31xqfrkhJVa87fbeplvGpz/459e46a7bcb42fd79aafbf1576eebdb6/strong-customer-authentication-flow-in-auth0-by-okta.png)

Important points to note:

- The blue  components are Okta-owned and part of Auth0 and Highly Regulated Identity solution suite.
- The green  components are built and maintained by the customer, e.g., customer mobile apps, applications, and services. 

### Sequence of operations

1. The user has initiated a payment transaction via their web browser at a digital banking web application, e.g., they may be making a payment from their bank account.

2. The digital banking web application sends the transaction request to Auth0:

   a. The transaction request may contain the “authentication code” for the amount and payee as part of the transaction. 

   b. The request is sent to the `/par` endpoint and avoids exposing sensitive transaction details at the browser.

3. Auth0 validates the request and generates: 

   a. A `linking_id` when the Consent Policy is configured as “Transactional Authorization with MFA” and the API audience is configured with this Consent Policy.

   b. A `request_uri` as a reference to the next step in the authorization process.

4. Auth0 sends the request_uri back to the calling web application .

5. The web application redirects the browser with the `redirect_uri`, which opens the login page in Auth0:

   a. The user can perform the login with their knowledge-based factor (i.e. their password). 

   b. This login step can be avoided if there is already a single sign-on session. 

   c. The user will wait here on this “holding page” until the decoupled flow completes.

6. Meanwhile, a [post-login trigger](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow#login-post-login) can run custom an Action code that extracts the authorization details (e.g., amount, payee, authentication code) from the transaction request.

   a. At this point, the Action code can integrate with third-party risk and fraud engines to determine whether a step-up authentication (i.e., SCA) is needed.

7. The Action writes the `linking_id` and contextual authorization details into a message store, i.e., a data store, for future retrieval.

8. Auth0 performs a lookup for the MFA mechanism to use; here, we will use a mobile push notification to a custom mobile app which embeds the Okta [Guardian SDK](https://auth0.com/docs/secure/multi-factor-authentication/auth0-guardian):

   a. Auth0 sends a mobile push notification to the mobile app, along with the `linking_id`.

   b. No transaction details are sent over the push notification.

9. The customer mobile app receives the push notification with the transaction `linking_id` and calls the message store to retrieve the transaction details for the user to authorize and consent to.

10. The customer mobile app extracts the authorization details for the requested transaction, i.e., payment amount and payee, and displays this to the user for consent.

    a. The user reviews the transaction details and proceeds to accept or decline.

11. The customer mobile app with embedded Guardian SDK calls the Okta MFA endpoint with the result of the user authorization:

    a. Was the MFA action completed successfully or not?

    b. If the MFA was completed successfully, did the user accept or decline?

12. Once the mobile push-based MFA completes, the web browser is redirected from Auth0 and the MFA page back to the digital banking web application:

    a. The digital banking web application receives an authorization code.

13. The digital banking web application exchanges the authorization code for an access token:

    a. The access token contains the details from the original transaction request, including the payment amount and payee and “authentication code”.

14. The digital banking application uses the access token to consume APIs in order to initiate the payment transaction in the appropriate back-end systems.

15. The user is informed of the outcome of the payment transaction.

### Supported authentication mechanisms

The solution architecture describes SCA using a mobile push notification to a customer's mobile app with embedded Guardian SDK. However, there are alternative options that are also compliant with SCA:

- Authentication by one-time passcode (OTP) sent via SMS.
- Authentication by WebAuthn.

For both of these authentication options, the user performs the authentication on the login page and then is shown the transaction details to authorize and consent to.

## Final Words

The Highly Regulated Identity solution suite on Auth0 delivers Strong Customer Authentication for financial services and payments. The SCA solution also applies to non-payment use cases and can be applied to any sensitive operation where step-up authentication, user authorization, and consent are required.

You can read more about [Highly Regulated Identity on the Auth0 by Okta documentation](https://auth0.com/docs/secure/highly-regulated-identity).


Strong Customer Authentication Explained

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

Staff Developer Advocate

Juan Cruz Martinez

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

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

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

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

For example, you can use Actions to:

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

## Prepare your Tenant

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

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

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

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

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

## Understand the APIs

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

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

### `enrollWith(factor, options)`

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

Example:

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

### `enrollWithAny(factors)`

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

Example:

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

### `challengeWith(factor, options)`

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

Example:

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

### `challengeWithAny(factors)`

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

Example:

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

## Create a New Auth0 Action

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Writing the Actions Code

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

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

Here's the actual code:

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

## Attach an Auth0 Action to the Login Flow

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

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

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

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

## Test Your New Authentication Flow

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

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

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

## Conclusion

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

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

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

Thanks for reading!

Using Actions to Customize Your MFA Factors

A new release of the package Auth0 Templates for .NET is out with new project templates and other improvements.

A new awesome version of the [Auth0 Templates for .NET package](https://www.nuget.org/packages/Auth0.Templates/) has been released! It brings you new templates and other improvements, which we will discover in a moment. Install now the latest release of the templates by running the following command in a terminal window:

```bash
dotnet new install Auth0.Templates
```

> ⚠️ Make sure you have uninstalled any previous version of the package from your machine before installing the new one.

Ready to learn what's new in the latest release? Let's go!

## New Project Templates

The first big news is that two new templates are now available: the Blazor Web App and the MAUI templates.

### The Blazor Web App template

The Blazor Web App template allows you to create a web application using the .NET 8 Blazor application model. As you may know, this new type of Blazor application has some complexities in properly supporting authentication. Take a look at [this article](https://auth0.com/blog/auth0-authentication-blazor-web-apps/) to learn more about it. Now you can have a starting point for your new Blazor application with Auth0 embedded in a snap by simply running the following command:

```bash
dotnet new auth0blazor -o MyNewBlazorApp
```

As usual, if you also have the [Auth0 CLI](https://github.com/auth0/auth0-cli) installed on your machine and logged in, you can automatically register your app with Auth0. Of course, you can still use the templates with Visual Studio:

![Auth0 Blazor Web App template in Visual Studio](https://images.ctfassets.net/23aumh6u8s0i/1fmXTCgaPVzvKGGiW0QPon/edd5f2a979472be788c9c6d448dc1ed0/auth0-blazor-web-app-vs.png)

Read [more about the Blazor Web App template here](https://github.com/auth0/auth0-dotnet-templates/blob/main/docs/auth0blazor.md).

### The MAUI template

With the MAUI template, you can build desktop and mobile applications with Auth0 authentication for Windows, macOS, iOS, and Android using a single code base. In this case, the command to use is as follows:

```bash
dotnet new auth0maui -o MyNewMauiApp
```

Building your new MAUI app using this template will save you a lot of time, as you can see from reading [this article](https://auth0.com/blog/add-authentication-to-dotnet-maui-apps-with-auth0/).

Check out [this document to learn more about the MAUI template](https://github.com/auth0/auth0-dotnet-templates/blob/main/docs/auth0maui.md).

## Other Improvements

In addition to the new templates, the new package brings you other internal and external improvements. To mention just a few of them:

- The Blazor WebAssembly template now supports .NET 8.
- The program that registers your application with Auth0 is no longer tied to .NET 7.0.
- A few issues with the auto-registration script have been fixed.

These improvements help provide a better experience when scaffolding and registering your application with Auth0.

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

## JetBrains Rider Support

Now you can use the Auth0 Templates with JetBrains Rider! Starting with [version 2024.1](https://www.jetbrains.com/rider/whatsnew/), Rider fully supports custom templates, so now you can choose your preferred IDE to build your .NET applications with Auth0 integrated, regardless of your operating system. This is especially important now that [Visual Studio for Mac is close to its retirement](https://learn.microsoft.com/en-us/visualstudio/mac/what-happened-to-vs-for-mac?view=vsmac-2022).

Previously, Rider [didn't support parameters for custom templates](https://youtrack.jetbrains.com/issue/RIDER-16759), which was a clear barrier to using the Auth0 Templates. Now you can use them just like in Visual Studio!

![Auth0 Blazor Web App Template in JetBrains Rider](https://images.ctfassets.net/23aumh6u8s0i/2wWfc13e4He4h6Ob3H7Eyu/d4fcd35aab3ae5a1ed41f6ec25fc486b/auth0-blazor-web-app-rider.png)

## A Look Back and a Glimpse Forward

The first version of the package was released one year ago. Since then, the project has grown with new templates and integration with the Auth0 CLI for automatic registration of your applications. During this year, the package has been downloaded over 8,000 times, and we have received suggestions and contributions.

We want to continue improving the current templates by adding features and improving the developer experience. Your feedback is very important. Share your thoughts by leaving a message below, or by opening a [new issue](https://github.com/auth0/auth0-dotnet-templates/issues/new/choose) to report problems and request new features.
If you like the project, don't forget [to star it on GitHub](https://github.com/auth0/auth0-dotnet-templates).

New Templates for Building .NET Apps with Auth0 Authentication

Passkeys allow you to authenticate securely, and they're easy to integrate using Auth0. But what happens after that? Let's learn how to list and revoke passkeys using Auth0.

Passkeys are the replacement for passwords, and they're here to stay. If you have been learning about this new technology, you know that it's still relatively new, but adoption is growing daily. 

Passkeys are available in Auth0, Google, Apple, Github, and many other places. So, there's a chance you are already using passkeys or are starting to implement them. 

In this blog post, you'll learn to manage your passkeys in Auth0 using the Management API. 

## What is a Passkey?

A passkey is a phishing-resistant cryptographic key pair that users can use for passwordless authentication. More specifically, [passkeys are FIDO credentials](https://fidoalliance.org/faqs/#PasskeysFAQs) that are discoverable by browsers or housed within native applications or security keys for passwordless authentication.

If you haven't already, you can [get started with passkeys using Auth0](https://auth0.com/blog/activate-passkeys-let-users-log-in-without-password/). After getting your free account, all you need to do is navigate to the [**Dashboard > Authentication**](https://manage.auth0.com/#/connections/database/), select your **Database Connection**, and activate passkeys under the **Authentication Methods** tab.

![passkeys prompt](https://images.ctfassets.net/23aumh6u8s0i/2dkPgFFDBt3H2ebmyuy9hF/1c060396c5078842ee312817e0bedccb/Uploaded_from_Using_Passkeys_for_a_Seamless_Login_Experience_in_the_Apple_Vision_Pro)


## The Passkey Lifecycle

Let's dive deep into the passkey's lifecycle. 

### Creation 

It all starts by creating a new passkey, and this can happen at different moments throughout the lifecycle of your user account:

- **Create a passkey during the registration flow:** When a user signs up for the first time to a website, they can create a passkey for their account. 
- **Add new passkey to existing account:** Multiple reasons could trigger this scenario; for example, you are starting to roll out passkeys to your users, and when they log in, you prompt them to create a new passkey. Another example is when a user gets a new security key or loses the old one and wishes to create a new passkey in their new device. 

When you create a new passkey, your browser will call the `navigator.credentials.create()` method from the Web Authentication (WebAuthn) API. Your authenticator will cryptographically sign a challenge generated by the relying party. You can [learn more about the registration process here](https://webauthn.me/introduction). 

Note that in the creation process, both the authenticator and the relying party, in this case, your server, will persist their records related to the newly created passkey.

### Read

When you use your passkey to authenticate yourself, you are "reading" your passkey. Technically speaking, when you use your passkey, the browser calls the `navigator.credentials.get()` method from the Web Authentication API, which is a read endpoint. 

In Auth0, you can do this using the Management API, and that's exactly what you'll learn in the next section. 

### Update

Updating a passkey might be a misleading term; **you can't update a passkey itself**, but rather, your users can update some attributes that can help them identify their passkeys, such as the display name.

Note that as a developer, you can't update the attributes of a passkey in the relying party, but your end-users can change the display name of their passkeys in their authenticators. 

In Auth0, your user's passkeys names might look like something like `passkey|<some_string>`, but this is actually the ID that is also being used as the name. 

![passkeys list in Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/7uxxwd3qtKHfk0sP3t1NUJ/70faad079091a9272e3eb33861ff8655/Screenshot_2024-05-08_at_16.15.31.png)

### Delete

Revoking or deleting a passkey is an action you must execute with extreme care. It's essential that before revoking a passkey, your users have another factor in place to authenticate themselves. Auth0 will still support the password reset flow for this user, which would allow a user to recover access to their account if all their passkeys have been revoked. 

Note that because both the relying party and the authenticator have their own record of your passkey when you delete a passkey from the relying party, your users may also have to delete it from their authenticator. 

<include src= "LearnPasskeysCTA"/>

## List Passkeys with Auth0

You can see the list of passkeys for a given user using the Auth0 Dashboard, but if you want to retrieve the list to use it in your application, you can use the Auth0 Management API. 

> Bear in mind you need to enable the use of the Auth0 Management API for your Auth0 Application. You can do so from the **Auth0 Dashboard > APIs > Auth0 Management API**. Find the **Machine to Machine Applications** and your Auth0 Application name and toggle the switch to **Authorized**. You might also need to [enable Client-Credentials Exchange](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow).

A passkey in Auth0 is an authentication method, which means you can use the [`GET  /api/v2/users/{id}/authentication-methods` endpoint](https://auth0.com/docs/api/management/v2/users/get-authentication-methods) to retrieve passkeys for a given user account. The response of this endpoint looks like this: 

```json
[
  {
    "id": "passkey|dev_pzg5wcycfdfd1VZ",
    "type": "passkey",
    "confirmed": true,
    "key_id": "foNlEKGDGREYERxDu3OuXu8sD-rhn1Dsy47HHcwxwg",
    "credential_device_type": "single_device",
    "credential_backed_up": false,
    "identity_user_id": "6657689457685295031f19fb",
    "user_agent": "Chrome 123.0.0 / Mac OS X 10.15.7",
    "public_key": "pQECAyYREGREGRwdnUjPZw9cnElZbv0Q8Axe/NgPBSPmoxJ+86IlggFeeypCWw7eRrgrgrgrrfd5DKYFnarkeoCr6L+1ds4=",
    "created_at": "2024-04-08T15:59:50.762Z",
    "last_auth_at": "2024-04-09T11:35:20.911Z"
  },
  {
    "id": "webauthn-roaming|dev_L7lkgrrgrp4d2x",
    "type": "webauthn-roaming",
    "confirmed": true,
    "name": "carla's key",
    "created_at": "2024-04-26T09:47:15.750Z",
    "last_auth_at": "2024-04-26T09:51:24.089Z",
    "key_id": "O2qqpM1EgSgEaC_NFSOvr0igwNtW91hyGjHNjVCsnjCoLiZzvEvGYOIj_h1SrETGGTRTGRWRk0mmIflkYA",
    "public_key": "pQECAyYgASFYIC9btx34m5xI0Xyr7zpViOVfJQaD2gfDFDDGDFGDFyk2QN6AwjHv1h3Odh+704d8nEbUM1pz+Wf5tyNKTcqg=",
    "relying_party_identifier": "your-tenant.eu.auth0.com"
  }
]
```

In this case, this user has one passkey and one security key enrolled as their authentication methods. To filter them, you can use the field `type` and check for the `passkey` value. 

Here's a code snippet in Ruby that showcases how to call the Auth0 Management API using the [`ruby-auth0` gem](https://github.com/auth0/ruby-auth0). You can find a [list of all the Management API SDK Libraries here.](https://auth0.com/docs/libraries#mgmt)

```ruby
# Initialize the Auth0Client
client = Auth0Client.new(client_id: ENV['AUTH0_CLIENT_ID'],
                         client_secret: ENV['AUTH0_CLIENT_SECRET'],
                         domain: ENV['AUTH0_DOMAIN'])

# Call the Get an authentication method by user id endpoint
passkeys = client.user_authentication_methods(auth0_user_id)

# Select only elements that have the type "passkey"
passkeys = passkeys.select { |p| p["type"] == "passkey" }
```

Where `auth_user_id` is the id of the user in Auth0 (i.e., `auth0|6657689457685295031f19fb` and the values for `client_id`, `client_secret`, and `domain` are set as environment variables. 

The value of the `passkeys` variable would then be: 

```ruby
3.2.2 :010 > passkeys
 => 
[{"id"=>"passkey|dev_pzg5wcycfdfd1VZ",
  "type" => "passkey",
  "confirmed" =>true,
  "key_id"=>"foNlEKGDGREYERxDu3OuXu8sD-rhn1Dsy47HHcwxwg",
  "credential_device_type"=>"single_device",
  "credential_backed_up"=>false,
  "identity_user_id"=>"6657689457685295031f19fb",
  "user_agent"=>"Chrome 123.0.0 / Mac OS X 10.15.7",
  "public_key"=>
   "pQECAyYREGREGRwdnUjPZw9cnElZbv0Q8Axe/NgPBSPmoxJ+86IlggFeeypCWw7eRrgrgrgrrfd5DKYFnarkeoCr6L+1ds4=",
  "created_at"=>"2024-04-08T15:59:50.762Z",
  "last_auth_at"=>"2024-04-09T11:35:20.911Z"}] 
3.2.2 :011 > 
```

## Revoke a Passkey in Auth0

Similarly to listing your passkeys, you can use the [`DELETE  /api/v2/users/{id}/authentication-methods/{authentication_method_id}` endpoint](https://auth0.com/docs/api/management/v2/users/delete-authentication-methods-by-authentication-method-id) to revoke a passkey from a user's authentication methods. 

> Note that before revoking a passkey, you should ensure the user has a fallback authentication factor to allow them to log in. In Auth0, the fallback will automatically be the password reset flow, but you can [enable other factors](https://auth0.com/docs/secure/multi-factor-authentication/multi-factor-authentication-factors#factors).

Here's an example of how to delete an authentication method using the `ruby-auth0` gem to interact with the Auth0 Management API:

```ruby
# Instantiate the Auth0Client if it hasn't been instantiated previously
client = Auth0Client.new(client_id: ENV['AUTH0_CLIENT_ID'],
                         client_secret: ENV['AUTH0_CLIENT_SECRET'],
                         domain: ENV['AUTH0_DOMAIN'])

# Call the delete authentication method endpoint 
client.delete_user_authentication_method(auth0_user_id, auth0_passkey_id)
```

Similarly, here you're reading the values for `client_id`, `client_secret`, and `domain` from the environment; the `auth0_user_id` variable is the user's id in Auth0 and the `auth0_passkey_id` is the passkey's id from Auth0 (i.e., `passkey|dev_pzg5wcyjfdhgkfSC01VZ`)

## Summary 

In this blog post, you learned the basics of the passkey's lifecycle and how to list and revoke passkeys using the Auth0 Management API. You also learned that as an end-user, you could create, read, update, and delete passkeys in your authenticators, and as a developer, you can manage the passkey's lifecycle on the relying party's side.

I’ve Got Passkeys Working in My App! But How Do I Manage Them?

Learn how to keep tokens more secure by using the Backend for Frontend (BFF) architectural pattern.

One of the biggest challenges for applications using OAuth 2.0 and OpenID Connect is token security. Preventing an ID, access, or refresh token from falling into the wrong hands is a priority of these protocols. The specs have adopted several technical solutions, and some best practices have been proposed. Among the latter is the use of the Backend for Frontend pattern, whose rationale and architecture we will analyze in this article.

## OAuth 2.0 Client Types and Security

OAuth 2.0 defines two types of client applications: public and confidential clients. This classification is based on the application's ability to keep authentication credentials secure. From [the specs](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1):

- **Confidential**. Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.
- **Public**. Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.

In a nutshell, confidential clients are those applications that run in a protected environment, such as a server, while public clients are applications that run in an uncontrolled environment, such as the user's device. Typical confidential clients are traditional web applications, while typical public clients are Single-Page Applications (SPA), desktop and mobile apps.

From a security perspective, public clients can't store their credentials securely. There is a high risk of tokens falling into the wrong hands. This can happen either because of a potential lack of protection on the local system or because of the potentially large number of instances of the application that increase the attack surface.

To mitigate the problem of issuing a token to a client that can't be authenticated (i.e., a public client), a specific flow has been designed: the [Authorization Code Flow with PKCE](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). Anyway, this does not solve all the concerns about the security of a public client.

## SPA Security and Tokens

Another concern for public clients is token storage. Once an ID or access token is received from the server, how can a public client protect it from unauthorized access? As long as the application is running, the application memory is the safest place to store tokens. But what if the application stops running temporarily?

For example, consider a SPA that has a token in memory. What happens when the user refreshes the page on which the application is running? The token is lost, and the user is forced to authenticate again for the application to obtain a new token.

You could consider storing the token in the browser's local storage or in a cookie and reloading it after the refresh, but this is not a recommended practice. A malicious user or application could gain access to the local storage or cookie and obtain the token. See [this article for more information on the risks of using browser storage](https://auth0.com/blog/secure-browser-storage-the-facts/).

Something similar happens with native applications (desktop and mobile): when the user closes the application, all tokens are lost, requiring authentication the next time the application is opened. While this may be acceptable in certain contexts, many users have become accustomed to not having to authenticate every time they open their app, especially in the mobile environment. However, native applications have an advantage over SPAs. The presence of secure storage mechanisms in most popular operating systems, such as Keychain in iOS/Mac or Keystore in Android.

The level of security required by an application depends on its specific functionality. It is the result of balancing the data confidentiality requirements with the ease of implementation. Therefore, in some contexts, using the Authorization Code Flow with PKCE and all the concerns about token management in a SPA may be acceptable. In other contexts, it is not. What can you do for those contexts where you can't absolutely risk a token falling into the wrong hands?

## The Backend For Frontend Pattern

A seemingly marginal note in [the definition of client in the OAuth 2.0 specification](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1) suggests a solution:

*A client may be implemented as **a distributed set of components, each with a different client type and security context** (e.g., a distributed client with both a confidential server-based component and a public browser-based component).*

This paves the way for the adoption of a well-known architectural pattern: the **Backend for Frontend** (BFF) pattern. This is a popular pattern to address specific needs for a client platform by building a dedicated backend. The needs may be of various types: decoupling of concerns, flexibility and maintainability, optimized performance, security, etc.

> Read [this document](https://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html) to learn how this architectural pattern was born.

In our case, we are interested in strengthening the security of SPAs in the context of OIDC and OAuth 2.0, and the [best current practices](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-backend-for-frontend-bff) give us some guidelines about using this pattern.

Let's explore how the BFF pattern works.

### The BFF architecture

The actors involved in a typical scenario where a SPA uses the Authorization Code Flow with PKCE are shown in the following diagram:

![Architecture of a SPA using OIDC and OAuth2](https://images.ctfassets.net/23aumh6u8s0i/4PBIbTFxPR4PalUltQQEgV/69698b96960c0368e7429f6d1e3d8549/spa-oidc-oauth-architecture.png)

The SPA interacts with the authorization server to get the ID, access, and refresh tokens. Then, the SPA uses the ID token to get data about the user, the access token to call an API, and the refresh token to get a new access token once it expires.

In this scenario, all the tokens are in the hands of the SPA.

By applying the BFF pattern, we are going to enter a new component in this architecture, the dedicated backend, as shown below:

![BFF architecture](https://images.ctfassets.net/23aumh6u8s0i/43eXspNnMJS3ImbvAva0R9/5cf40b564dcbd03eb7394c15078d8b63/bff-architecture.png)

In this new scenario, the backend has three core responsibilities:

- It interacts with the authorization server as a confidential client.
- It manages all the tokens on behalf of the SPA, which can't access them anymore.
- It proxies all requests to the API, embedding the access token before forwarding them.

The SPA only interacts with the backend, relying on traditional cookies for authenticated sessions. Basically, the backend exposes a number of endpoints that let the SPA access the user profile data and the remote API.

This architecture improves the security of token negotiation, since it now happens via a confidential client, and token storage, since it now occurs on the server side.

### The BFF flow

Let's take a look at how the actors in this architecture interact with each other by following this diagram:

![Backend for Frontend flow](https://images.ctfassets.net/23aumh6u8s0i/6uM2x48XekNyFpODMiFjJq/c351e6278219b3865bd0bc6dd33e828b/backend-for-frontend-bff-flow.png)

Here are the descriptions for each step:

1. The SPA points to a backend URL (`/login` in the example above) to let the user authenticate.
2. The backend starts the usual OpenID Connect negotiation with the authorization server: it redirects the user browser to the authorization endpoint to authenticate the user and get the needed tokens.
3. The authorization server issues the tokens to the backend, which can store it in a cache.
4. The backend issues a cookie representing the user session and triggers the reloading of the SPA in the browser.
5. The SPA makes an API request to the backend including the cookie.
6. The backend validates the SPA request, retrieves the associated access token, and uses the token to make a call to the API.
7. The API returns a response to the backend.
8. The backend forwards the response to the SPA.

## Caveats and Variations

The BFF pattern solves the main concerns about using SPAs in an OIDC/OAuth 2.0 flow:

- There is no longer a public client negotiating the tokens, but this negotiation is now the responsibility of a confidential client represented by the backend.
- The SPA no longer needs to store tokens to prevent user re-authentication after page refresh.

To properly implement the BFF, there are a few caveats you need to pay attention to:

- The session cookie issued by the backend must be marked `Secure` and `HttpOnly`.
- The cookie must be associated with the token(s) issued by the authorization server.
- The tokens can be stored on the server side or in the session cookie. In the latter case, the cookie must be encrypted.
- The backend must implement all the measures to prevent Cross-Site Request Forgery (CSRF) attacks.
- The BFF pattern does not work for a standalone SPA that relies on calling a protected API directly from JavaScript. The SPA must be hosted by the backend, which is implemented as a regular web application.

While the BFF pattern solves the main security concerns of token exchange and storage for SPAs, some developers are concerned about performance issues. Specifically, the mediation run by the backend as a proxy API can be a bottleneck in some contexts. There is an alternative to the BFF pattern that meets this need, but it comes at the cost of reduced security.

This alternative is the [Token-Mediating Backend pattern](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-token-mediating-backend), which allows the backend to negotiate the tokens as in the BFF pattern but provides the access token to the SPA. This way, the SPA can directly call the protected API using the access token. While this pattern keeps token negotiation secure by always relying on the backend as a confidential client, it leaves the issue of storing and protecting the access token open. To overcome this issue, you can consider [using OAuth 2.0 with DPoP](https://auth0.com/blog/oauth2-security-enhancements/#Demonstrating-Proof-of-Possession--DPoP), which binds an access token to the client, making it no longer a bearer token. In this case, you need a DPoP-enabled authorization server, of course.

## Summary

Now you have a better understanding of the concerns related to token management and SPAs. You learned that SPAs, like any public client, are not always a safe place to handle ID, access, and refresh tokens. Much depends on the specific business requirements of the application, of course.

If you need a more secure architecture for your SPA, you can apply the Backend for Frontend pattern. This pattern introduces a dedicated backend for token negotiation and management on behalf of the SPA. This way, no tokens will reach the SPA, while the backend will also take charge of proxying the requests to a protected API.

The Backend for Frontend Pattern

jess-author

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

Sr. Developer Advocate

Jessica Temporal

Build Python CLI applications secured by using the device authorization flow with Auth0.

Securing a Python CLI application with Auth0

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

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

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

## Prerequisites

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

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

## Create a New Action

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Working with a Deny List

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Working with an Allow List

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

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

Here is the new code:

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

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

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

## Delegate List to an API

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

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

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

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

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

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

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

## Attach an Auth0 Action to the Login Flow

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

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

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

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

## Summary

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

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

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

Thanks for reading!

Permit or Deny Login Requests Using Auth0 Actions

Upgrading made easy: from in-house authentication to modern login flows, flexible user profiles, and the convenience and security of passkey

Imagine you’re working on a monolithic application that includes a home-grown authentication system. Over the years, the authentication function has received upgrades here and there to improve security and to stay reasonably up-to-date in a changing world.

Sooner or later — perhaps triggered by considering different growth paths and how best to make use of developer time — you start to recognize that your in-house Identity stack is a limiting factor:

* Integrating with partners and other technology components requires custom work
* Maintenance obligations are distracting from work on your core app
* Meeting regulatory requirements for privacy is an ongoing challenge 
* Providing different access privileges to different types of end users is becoming more complicated than ever anticipated
* With every breach headline, you’re reminded of the constant need to strengthen security

Shopper Approved found themselves in a similar situation — in 2017, the company’s ambitions were outgrowing the home-grown Customer Identity capabilities of their monolithic PHP app.

With that realization, the search was for a third-party authentication solution.

# Why Shopper Approved chose Auth0 by Okta 

Since its launch in 2010, [Shopper Approved](https://www.shopperapproved.com/) has helped over 20,000 eCommerce brands — from mom-and-pop shops to global enterprises — generate more online trust, visibility, and conversions.

> “We knew we wanted to replace our login and authentication mechanism, and we needed a solution that would ‘tango’ with our [Laravel](https://laravel.com/) front-end templating engine,” Christopher Budge, Shopper Approved’s CTO recalled, “but we didn't know which direction we wanted to go in.”

<include src="QuoteCard" body="The Self-Service pricing was really attractive to us. The other providers that we found were prohibitively expensive for what was initially an experimental project, and not a lot of them had the adaptability that we needed to integrate into our existing application." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

While searching online for ideas and options, Budge came across Auth0 — and, in particular, the Self-Service plans.

> “The other providers that we found were prohibitively expensive for what was initially an experimental project, and not a lot of them had the adaptability that we needed to integrate into our existing application.”

The Self-Service option gave Budge and the wider team plenty of time to perform due diligence. “_We looked for a long time before ultimately deciding upon Auth0,_” he shared. “_The more I dug into it, the better it looked._”

The ability to explore the solution in a hands-on manner, without a commitment, helped the team to make an informed choice. Budge explained that:

<include src="QuoteCard" body="I got together with our technical lead and programming contractor, and they started playing with it — and then they said, 'Yeah, we think this is going to work." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

While every organization’s Identity journey is unique, here’s how Shopper Approved implemented Auth0.

## Migrating Users from the Legacy System to Auth0	

No matter how much preparation is done, a migration is always a nervy thing. As it turns out, those nerves were unnecessary — Shopper Approved’s migration from their legacy, home-grown authentication system to Auth0 went off without a hitch.

Budge recalled, “_We weren't sure how well our system would adapt to having its old authentication system ripped out and something new put in its place, but the migration actually exceeded expectations. Within 24 hours, we were able to ingest our entire user database into Auth0 and have them set up as users able to log in._”

However, migrating users was simply the foundation for modernizing the experience for Shopper Approved’s customers, with Budge adding, “_The universal login allows for such a smooth application login and flow. And our marketing team has really appreciated the customization and branding options that allow us to deliver a better customer experience._”

### Letting quickstarts guide the way

One of the first things Budge’s team did was explore Auth0’s step-by-step [quickstart guides](https://auth0.com/docs/quickstarts) to get a feel for the overall migration process.

“The quickstart guides were dead easy. Plus, between your host documentation and the notes in GitHub, it’s really, really easy as a developer to figure out ‘where am I and where do I need to go?’” and ‘What’s next?’”

![quickstarts](https://images.ctfassets.net/23aumh6u8s0i/58lZcrqemW0dCDEIrlLxef/fd17a831afcbbe647abd73d3420e9d95/01-migration.png)

### Leveraging SDKs

SDKs reduce the developer effort required to implement specific use cases, and Budge’s team found exactly what they needed among Auth0’s 40+ SDK libraries.

“Your SDKs are written really well, and your APIs are documented really well. So, code-wise, it’s extremely easy to interact with the platform — you can get going and don’t really have to think hard about it.”

![SDKs](https://images.ctfassets.net/23aumh6u8s0i/1cSZQDXlQ1VDHD7RFG71vu/6922a4a4409f3bab6453b7b48f12541e/02-migration.png)

## Building User Profiles

User data can come from many sources, including your own databases as well as social, legal, and enterprise identity providers. Some examples include Google, Facebook, Active Directory, and SAML.

In Shopper Approved’s case, there was an added complication — practically every user profile that had ever been created in their system still existed, and collectively, many of these profiles had inconsistent and incomplete data. But, perhaps counterintuitively, the upgrade actually presented an opportunity to clean up the user database. Budge’s migration script identified existing user records that were poorly formatted, allowing the team to quickly correct any issues — ultimately improving the overall structure of the company’s user data and laying a strong foundation for efficient scalability.

“The way your user profiles are set up — they’re just really easy to understand, manipulate, and customize. The data structure was easy to map to what we had and what we needed.” Maybe even more importantly, Budge recalled that “It just worked. When we were playing around with it, we saw that it does exactly what [your documentation](https://auth0.com/docs/manage-users/user-accounts/user-profiles) says it does.”

![User Profiles](https://images.ctfassets.net/23aumh6u8s0i/3EfvAVkkj9Ornz9JcTH5CJ/1783bd310eb0cd0722dbbe754aa606c4/03-migration.png)

## Innovating With Identity: Exploring Passkeys

The Identity domain is always evolving, with new specifications, standards, and [regulatory requirements](https://auth0.com/security) frequently appearing.

Unsurprisingly, one of the reasons why Budge was so eager to introduce a leading off-the-shelf solution was that it would allow the company to keep pace with these changes — while at the same time allowing the team to apply their finite resources on their core value proposition. In short, he knew that choosing Auth0 meant that Shopper Approved’s CIAM needs would be met today, tomorrow, and as far into the future as he could imagine.

Like many CTOs, Budge had closely been following [passkeys](https://learnpasskeys.io/) — FIDO credentials that are discoverable by browsers or housed within native applications to enable — and was excited by their potential to provide [a highly secure and very convenient user authentication experience](https://auth0.com/blog/webauthn-and-passkeys-for-developers/).

> “I’ve been watching passkeys for a long time, and — literally the day I got [the announcement that they were available](https://auth0.com/blog/activate-passkeys-let-users-log-in-without-password/) — I jumped right in. We really enjoyed rolling them out early to our organization, and we’ve had zero issues. And it’s great that we didn’t have to build passkey support ourselves!”
> _Christopher Budge_

![Passkeys](https://images.ctfassets.net/23aumh6u8s0i/3qOGVNCBexcnp5LqxkAcNB/7a0c5eaa7bdb2cd37987795f7a504712/passkeys.png)

## Enjoying Ongoing Value

Budge’s hopes for lower support and maintenance obligations have come to fruition. “We have not had to spend a single development hour at all on user authentication and login — it's never failed, and it's never broken.”

Similarly, the upgraded security is evident. 

> “We've had many security researchers and penetration testers try to break in. Every time they run smack-dab into Auth0.”

<include src="QuoteCard" body="We have not had to spend a single development hour at all on user authentication and login — it's never failed, and it's never broken." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

### Get started in minutes — for free — with no humans (other than yourself) required!

We’ve always tried to make things less complex for developers, which is why [our Self-Service plans](https://auth0.com/pricing) allow you to create a trial account with nothing more than an email address. During your 22-day trial period, you can create a simple app, configure its look and behavior, and explore the Auth0 solution in detail — giving you plenty of time to really get your hands dirty.

![Get started](https://images.ctfassets.net/23aumh6u8s0i/3s3e2u6XsF3BitzYgE3TpY/1097a71343e41a488444684c12c2c248/identity_journey.png)

Plus, anyone using our products can take advantage of resources including [quickstarts](https://auth0.com/docs/quickstarts), [40+ SDKs](https://auth0.com/docs/libraries), [detailed guides](https://developer.auth0.com/resources/guides/web-app/nextjs/saas-basic-authentication), and [extensive (but easy-to-follow) documentation](https://auth0.com/docs/articles) to help get started and implement a strong Customer Identity function.

In fact, with only a few lines of code, you can have Auth0 integrated into any app, written in any language, and in any framework.

[Try for free](https://auth0.com/signup?utm_source=whitepaper&utm_medium=auth0&utm_campaign=whyauth0) and see for yourself.


A Customer Identity Migration Journey

Passkeys let developers authenticate users more securely and without phishing risks. However, several subtle nuances may lead them to some misconceptions.

Passkeys replace passwords for user authentication, provide a better user experience, offer more security and phishing resistance. However, there are some subtle nuances that can confuse developers. Let’s dig into some of them.


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


> This article is not an introduction to passkeys. It assumes that you, as a developer, have some general knowledge about them and are looking for clarification about some confusing concepts.
>
> If you are new to passkeys, you can learn more by visiting [learnpasskeys.io](https://learnpasskeys.io).

## Where Are the Specs for Passkeys?

The term *passkey* is [a common noun](https://passkeys.dev/docs/reference/terms/#passkey) in the same way that password is. It's not a product name, and it's not a formal technical name such as [ID token](https://auth0.com/blog/id-token-access-token-what-is-the-difference/) or [JWT](https://jwt.io/introduction). However, a widely accepted definition from the FIDO Alliance [defines passkeys](https://fidoalliance.org/passkeys/) as "*a replacement for passwords that provide faster, easier, and more secure sign-ins to websites and apps across a user’s devices*".

The FIDO Alliance also provides a technical definition of passkeys: "*passkeys are FIDO credentials that are discoverable by browsers or housed within native applications or security keys for passwordless authentication*".

In other words, while **the term passkeys is common** in everyday conversation, it identifies something that is formally defined by a set of technical specifications: [FIDO2/WebAuthn](https://fidoalliance.org/fido2/). Keep reading to learn a bit more about these specifications.

By the way, you should not capitalize the term passkey as if it were a product name. It should follow the capitalization rules of any common noun, as with the term password.

## Passkeys, FIDO, and FIDO2

Some recurring terms around the passkey definition may confuse many developers: FIDO, FIDO Alliance, FIDO2. What are they? What is the relationship between them?

[FIDO](https://fidoalliance.org/what-is-fido/) stands for *Fast IDentity Online* and refers to an initiative to solve the password problem in user authentication. The same name is used to identify the set of standards that allow user authentication through cryptographic keys, although the correct name should be *FIDO Authentication*.

[FIDO Alliance](https://fidoalliance.org/overview/) is the name of the open industry association that carries on the Fast IDentity Online (FIDO) initiative. Among its members, you can find Apple, Microsoft, Google, and Amazon.

[FIDO2](https://fidoalliance.org/fido2/), or rather FIDO2 Authentication, is one of the FIDO Alliance's technical specifications for enabling passwordless strong authentication. Specifically, FIDO2 Authentication is the set of standards that passkeys rely on. FIDO2 Authentication includes the [W3C WebAuthn](https://www.w3.org/TR/webauthn-2/) specifications and the [FIDO Client to Authenticator Protocol (CTAP)](https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html) specifications. These are commonly referred to together as “FIDO2/WebAuthn”.

The WebAuthn specification defines how web-based relying parties can interact with passkeys in a browser, while CTAP allows the implementation of Cross-Device Authentication (CDA), i.e., it enables communication between a client/platform and an external authenticator.

## Passkeys and FIDO Credentials

The technical definition of passkeys refers to FIDO credentials. What are they?

**FIDO credentials,  also known as WebAuthn credentials, are cryptographic key pairs** based on [public-key cryptography](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/) and used for authentication. With FIDO credentials, the authentication process is not based on a shared secret, as it happens with passwords. On the contrary, the user shares the public key with the authentication server at the time of registration. Sharing the public key does not compromise the security of the user identity: it's public information that can be shared without any risk. To authenticate, the user must demonstrate that they are in possession of the corresponding private key. This is accomplished by signing a challenge (a randomly generated value) with the private key.

So, the core building block of the passkeys infrastructure is a public-private key pair called FIDO credentials. From a technical perspective, we can identify passkeys with special FIDO credentials. What is so special about these FIDO2/WebAuthn credentials compared to traditional ones? They are **discoverable**, which means that an authenticator is able to detect the private key associated with an authentication server (relying party) given its domain. This makes the user experience smooth and convenient since they don't even need to send their username to the authentication server.

## Passkeys and WebAuthn

You may have heard of passkeys in conjunction with WebAuthn and are wondering what their relationship is. As mentioned earlier, passkeys rely on FIDO2 Authentication, which is based on two specifications: [W3C Web Authentication (WebAuthn)](https://www.w3.org/TR/webauthn-2/) and [FIDO Client to Authenticator Protocol version 2 (CTAP2)](https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html).  While CTAP2 defines how devices can communicate with external authenticators, WebAuthn defines how browsers can manage FIDO credentials for user registration and authentication.

WebAuthn defines a JavaScript API to allow a website to request the creation of a new passkey and get proof of possession of the private key. By using this API, a website can't access the private key of the cryptographic key pair, but it can request the authenticator to sign a challenge with that private key. This proves that the user controls the private key, which is what proves the user's identity.

To summarize, a passkey is a credential that allows a user to prove their identity, while WebAuthn is a standard API that allows an application to create and use passkeys for sign-in.

## Passkeys and Biometrics

A common misconception is that passkeys let users authenticate via their biometrics, such as their fingerprint or their face. While using biometrics is one of the ways to complete the authentication process with the relying party, saying that passkeys let you authenticate through biometrics is not accurate.

The relying party has no access to your biometrics. Your fingerprint and your face data are stored locally in your authenticator device, so the relying party cannot authenticate you based on your biometrics. It authenticates you as the holder of the private key part of your passkey. Biometrics are used locally to let you access your authenticator and prevent a malicious person from using your authenticator. To be precise, [a biometrics-based authentication exists](https://auth0.com/blog/a-tale-of-two-biometrics-styles/#On-Device-Biometric-Authentication), but it is local and does not involve the relying party. 

In addition, you are not required to use biometrics to access your authenticator unless the relying party forces this requirement. In some contexts, you can just use a PIN or draw a pattern to access your authenticator. The use of biometrics, PIN, or other interactions with the authenticator is known as an [authorization gesture](https://www.w3.org/TR/webauthn-2/#authorization-gesture).

## Passkeys Are Not Accounts

Another common misconception about passkeys is that they are the same as user accounts. You can find some [threads](https://developer.apple.com/forums/thread/711023) [about this](https://www.reddit.com/r/Passkeys/comments/14sj4yd/multiple_accounts_on_a_single_device/) [confusion](https://developer.apple.com/forums/thread/732735) all around.

A user account can be defined as the representation of the identity of a user in a given context. For example, your Google account identifies you in the Google ecosystem, i.e., in the set of applications and services that Google provides you. Your Apple account identifies you in the Apple ecosystem, and so on.

To prove your identity to Google when you access one of its applications, you need to provide your credentials, such as a password or a signed challenge, in case you are using a passkey.

Your credential is not your identity/account. It allows you to prove your identity, but it's not *the account*. You can change your credentials, but your account remains the same.

In the context of passkeys, you can add a passkey to your account. You could even add multiple passkeys to your account. If you remove your passkey (or one of your passkeys) from your account, you are not deleting your account. You are just removing a way to prove your identity.

Think of your passkeys as you think of your passwords.

## Passkeys Are Not (Necessarily) Hardware-based

While many FIDO authenticators are based on hardware devices, [FIDO2/WebAuthn does not require this](https://www.w3.org/TR/webauthn-2/#authenticator). The specifications explicitly say that an authenticator can be implemented via software. This means that the public and private key pair is created by the software and is stored on the file system after encryption.

A software authenticator can be part of the operating system or an independent application. While a hardware authenticator does not allow you to export the private key stored on it, a software authenticator is more flexible. In fact, synced passkeys rely on a software application or operating system subsystem to export their private key to the cloud and then share it with other devices.

## Passkeys Are Not Only for the Web

A common misconception about passkeys is that they are meant only for web applications. Perhaps this is due to the fact that WebAuthn is a W3C standard, which essentially involves browsers. In fact, you can use passkeys for desktop and mobile applications, too.

You can use two approaches to get passkey support into your native applications:

- **Use the browser to authenticate the user**. You can delegate user authentication to an external browser or system webviews. In this case, user authentication relies directly on WebAuthn, as it happens with web applications. After authentication, the user is redirected back to the native application with a token proving it succeeded.
- **Use your platform-specific abstraction of the WebAuthn API**. Platforms provide you with native implementations to manage passkeys in your applications. For example, you can use [Credential Manager](https://developer.android.com/training/sign-in/passkeys) to support passkeys in Android and [specific APIs for macOS and iOS](https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys). 

## The Role of Authenticators

Authentication using passkeys relies on authenticators, which are hardware or software components capable of managing cryptographic key pairs. You can have two types of authenticators:

- **Platform authenticators**. These authenticators are integrated into your device or are modular software components running on your device. Usually, they are not removable from your device. Examples of platform authenticators include Google Password Manager, Apple iCloud Keychain, Windows Hello, 1Password, Bitwarden, and Dashlane.
- **Roaming authenticators**. These are authenticators that can be used on a device other than the one on which the user is authenticating. Examples of roaming authenticators are security keys or smartphones.

While this classification may seem simple to understand at first look, keep in mind that **the authenticator type is more a matter of role than inherent characteristics**. In other words, a specific authenticator can act as a platform authenticator in one context and as a roaming authenticator in another.

Consider the case of the authenticator embedded in a smartphone. When the user authenticates to an application running on the smartphone, the smartphone's authenticator is a platform authenticator. When the user uses the same smartphone to authenticate to an application running on a laptop via Cross-Device Authentication, the smartphone is a roaming authenticator.

The rule of thumb to determine what is the current role of an authenticator is:

- Has your device a built-in authenticator, and you are using it to access an app or website on the same device? If so, it’s a platform authenticator.
- Has your device a built-in authenticator, but you are using it to let another device access an app or website? Then it’s a roaming authenticator.

As a final note, while as per [definition](https://www.w3.org/TR/webauthn-2/#authenticator), the authenticator is just the subsystem able to manage cryptographic key pairs, it's common to call the entire device the authenticator. So, don't be surprised if you hear someone say they use their smartphone as an authenticator.

## Not All Passkeys Are the Same

You might have heard that there are different types of passkeys, and you may have heard different confusing names for them: single-device, multi-devices, synced, device-bound. Let's try to put order in this naming.

The currently accepted naming for passkey categorization is as follows:

- **Device-bound passkeys**. These types of passkeys are bound to a single authenticator, i.e., the authenticator that created them. Once a passkey has been created, it cannot leave the device where it was created. As an example, consider a security key: you can't move the passkey created with this authenticator to another device.
  For a very short period of time, this was referred to as a *single-device passkey*, but that name is no longer used.
- **Synced passkeys**. These are passkeys that can leave the authenticator in which they were created and move across devices via the cloud. The passkeys are end-to-end encrypted and synced to all of a user’s devices using the same provider. This enables sharing them with all the devices of a user associated with the same passkeys provider account, such as Apple ID, Google account, 1Password account, Bitwarden account, and so on.
  For a very short period of time, these were referred to as *multi-device passkeys*, but that name is no longer used.

## Passkeys, Single Sign-On, & C.

You learned that passkeys are a new way to authenticate the user in a much more secure and convenient way than other traditional forms of authentication, first and foremost, username and password. But how does [Single-Sign On (SSO)](https://auth0.com/docs/authenticate/single-sign-on) work with passkeys? Can we continue to use one account to access multiple applications, or do we have to create a new passkey for each application while using the same account?

Actually nothing changes when you use and implement SSO in your applications. Passkeys introduce a new way to authenticate a user but do not change how to manage the resulting authenticated session. In other words, once the authentication server has authenticated the user, it can generate the authentication cookie just as it did with password-based authentication. Passkey and SSO can coexist seamlessly.

Similarly, passkeys and OpenID Connect or OAuth 2.0 coexist. There is no overlap. After a passkey-based authentication, the identity provider or authorization server may issue the required tokens as usual.

<include src="LearnPasskeysCTA" />

## Summary

Passkey technology is proven and solid, but some internal complexity may lead to some misconceptions. This article went through a few of them, trying to explain how things are. If you have any other doubts about passkeys and the technologies behind them, please leave a comment below.


Common Developer Misconceptions About Passkeys

This Valentine’s Day ditch passwords and fall in love with passkeys, the future of authentication!

This Valentine’s Day story is a love story, but like many love stories, it starts with a tragic breakup. Just yesterday I was writing a [breakup letter with passwords](https://auth0.com/blog/a-farewell-letter-to-passwords), it wasn’t easy, but necessary. Our relationship was going nowhere, and long gone were the days of butterflies and passion.

With my heart cautiously open, I decided to take a leap of faith. I'm embarking on a new love story, one built on trust, convenience, and affection, a relationship where I feel safe, where I can be myself, my face, my fingerprints, and not a random string.

My new love is passkeys, and maybe it’s again those butterflies in my stomach doing the thinking, but what’s not to be loved about passkeys?

As I write these words down, I want to celebrate what passkeys bring in for me, to our relationship, to my online identity, and to my protection:

- **An Unbreakable Bond**: Passkeys, through the magic of public-key cryptography, forge an unbreakable connection between me and my data. It’s like a padlock secured by something uniquely mine, like my fingerprints, my face, or one of my secure devices.

    A bond so strong that it can resist brute-force attempts, a bond so unique that it is breach safe, and a bond so close that it is phishing resistant.
- **Effortless Access**: I remember the frantic searches, the cold sweat dripping down my forehead as I desperately tried every password combination? With passkeys I can say goodbye to such anxieties! using a simple tap, a fingerprint, or a facial scan. Just like effortlessly unlocking my partner’s heart with a shared understanding.

- **Always By My Side**: No more worrying about forgotten passwords or locked accounts. Passkeys work across different platforms and devices, ensuring I’m always connected to my loved ones, just like an invisible link that keeps us together.

- **Sharing is Caring**: I can easily share my passkeys across my devices without compromising security. Passkeys offer seamless login experiences across devices and secure and convenient ways to grant access, just like sharing experiences in a healthy relationship.

- **Uniquely Yours**: Since I can’t reuse a passkey, they are unique per online service and account. When I create a new passkey, it’s tied to that specific domain.

I’m sharing my love story, in hopes it will inspire others. If you ever felt like me, and you think it’s time to ditch passwords and move on, [learn and adopt passkeys today!](https://a0.to/passkeys_blog).

<include src="LearnPasskeysCTA"/>

Reasons to Fall in Love with Passkeys

Learn how to authenticate users of your .NET MAUI application using Auth0.

Add Authentication to .NET MAUI Apps with Auth0

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

A step-by-step guide for building a secured GraphQL API with Spring Boot and Auth0 authentication in React

How to Build a GraphQL API with Spring Boot

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. 

Matt Raible

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

Build a Beautiful CRUD App with Spring Boot and Angular

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

Let’s explore the latest security enhancements in the OAuth 2.0 specification.

OAuth 2.0 is now widely adopted, but some security concerns remain. Recently, two new specifications were released to improve OAuth 2.0 security and address some of these concerns: *Demonstrating Proof of Possession* (DPoP) and *Step-Up Authentication Challenge Protocol*. Let’s take a high-level look at them to understand how they work.

## Demonstrating Proof of Possession (DPoP)

The most popular artifact associated with OAuth 2.0 is the access token. This token, as well as the refresh token, is a **bearer token**, and [there is a specification on how to use it](https://datatracker.ietf.org/doc/html/rfc6750). As mentioned in that specification, a fundamental feature of a bearer token is "that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can."

While this feature simplifies the token management, it raises some security concerns. In fact, if a bad actor manages to steal an access token, they can use it without any problem. Therefore, some [security measures](https://datatracker.ietf.org/doc/html/rfc6750#section-5) should be taken to mitigate potential threats.

> Read [this article to learn more about access tokens and how they differ from ID tokens](https://auth0.com/blog/id-token-access-token-what-is-the-difference/).

[Demonstrating Proof of Possession (DPoP)](https://www.rfc-editor.org/rfc/rfc9449) is a mechanism designed to restrict who can use an access or refresh token. With this mechanism, the authorization server issues a token that is bound to the requesting client, so that no one other than that specific client can use the access or refresh token. In other words, a token issued by using DPoP is no longer a bearer token.

### Request a DPoP access token

The client using an access token with DPoP must prove that it is the legitimate recipient of the token. This is done using public key cryptography: the client must prove that it has the private key of the public/private key pair. But let's go in order to understand how DPoP works with a standard OAuth 2.0 flow.

For simplicity, we will use the [Authorization Code flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow), but the same applies to the other flows. The high-level steps are listed below:

1. The user is redirected to the authorization server with a request to initiate the flow.
2. The authorization server authenticates the user and redirects them back to the application with an authorization code.
3. The client application generates a public/private key pair and creates a DPoP proof, which is a JWT containing the public key and the method and URI of the HTTP request where it will be used. This also binds the DPoP proof to a specific HTTP request.
4. The client application sends the authorization code to the authorization server to request an access token. The HTTP request includes the DPoP proof in the `DPoP` header field. The following is an example of access token request with DPoP proof:

```http
POST /token HTTP/1.1 
Host: server.example.com 
Content-Type: application/x-www-form-urlencoded 
DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2I...  
grant_type=authorization_code 
&code=3LgurgEWbtafaqTn2VxkASV 
&redirect_uri=https%3A%2F%2Fapp.example.com 
```

5. The authorization server validates the DPoP proof by checking the signature and the request details (HTTP method and URI). It then generates a hash of the client's public key (JWK thumbprint) and embeds it in the access token. For non-JWT access tokens, the JWK thumbprint can be checked through the [introspection endpoint](https://www.rfc-editor.org/rfc/rfc7662.html). Finally, the authorization server sends the access token with the JWK thumbprint to the client application.

### Use a DPoP access token

When the client application needs to call a protected API, it performs the following steps:

1. The client application creates a new DPoP proof bound to the HTTP request it's about to make.
2. The client sends the access token in the `Authorization` header field of the HTTP request using the `DPoP` scheme. It also provides the DPoP proof in the `DPoP` header field. The following is an API call example with DPoP proof:

```http
GET /protectedresource HTTP/1.1 
Host: api.example.com 
Authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K0pXVCIsImNuZiI6eyJqa3QiOiJybW56aTJvSWNYW...
DPoP: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRwb3Arand0IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2I...
```

3. In addition to the standard access token validation, the API also validates the DPoP proof to make sure that this request comes from the intended sender.

While using DPoP provides more security than the simple bearer token, this does not mean that there are no threats to DPoP access tokens. Take a look at [the security considerations in the DPoP specification](https://www.rfc-editor.org/rfc/rfc9449#section-11) to learn more.

## Step-Up Authentication Challenge Protocol

A second security enhancement to OAuth 2.0 has been introduced with the [Step-Up Authentication Challenge Protocol specification](https://www.rfc-editor.org/rfc/rfc9470.html), which has our [Vittorio](https://auth0.com/blog/authors/vittorio-bertocci/) as its author along with [Brian Campbell](https://www.pingidentity.com/en/resources/blog/author/brian-campbell).

This specification adds [Step-Up Authentication](https://auth0.com/blog/what-is-step-up-authentication-when-to-use-it/) to OAuth 2.0-protected APIs to enforce stronger authentication requirements when a risky operation is requested by a client. In other words, when a client calls a critical API endpoint, the server checks that the access token meets specific authentication requirements, and if it's doesn't, it returns an error response to the client with directions on what is required.

### The step-up authentication flow

Basically, the high-level flow has the following steps:

1. The client sends a request to a critical API endpoint including the access token.
2. The API endpoint extracts information about user authentication from the access token.
3. If the user authentication information meets the authentication requirements for that endpoint, the request is processed. Otherwise, the API endpoint returns an error response that includes the authentication requirements.
4. The client requests a new access token from the authorization server that meets the authentication requirements.

### The authentication requirements

The specification defines two types of authentication requirements:

- *Authentication Context Class Reference* (ACR): This requirement indicates one or more specific authentication methods. For example, it can specify that Multi-Factor Authentication (MFA) is required.
- *Maximum Authentication Age*: This requirement specifies the elapsed time since the last *active* user authentication. An active user authentication occurs when the user is actively involved, for example by entering a username and password. An implicit authentication due to a still valid authenticated session is not considered an active user authentication.

These requirements are embedded in a JWT access token through the standard `acr` and `auth_time` claims. For non-JWT access tokens, the requirements can be verified through the [introspection endpoint](https://www.rfc-editor.org/rfc/rfc7662.html).

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

## Summary

This article provided a high-level overview of the new specifications released in September 2023 to improve the security of OAuth 2.0. The DPoP specification defines a mechanism to bind an access token to the client application that requested it, overcoming the risks associated with bearer tokens. The Step-up Authentication Challenge Protocol defines a way to request more stringent authentication requirements when accessing a critical resource or requesting a risky operation from a client.

OAuth 2.0 Security Enhancements

There are tons of identity resources out there. What if you had a curated list of resources? Then, keep reading this blog post!

Identity is a broad topic, and many resources are available. This blog post gives you a curated list of some of the most relevant resources at Auth0 by Okta and relevant identity organizations. 

## Identity Fundamentals

A [digital identity](https://auth0.com/docs/glossary#digital-identity) is a set of attributes that define a particular user in the context of a function that is delivered by a specific application. 

### Learn it from Vittorio

[Identity Fundamentals Course](https://auth0.com/docs/videos/learn-identity-series) brought to you by the one and only [Vittorio Bertocci](https://auth0.com/blog/in-celebration-of-vittorio-bertocci/). 

![learn-identity-homepage](https://images.ctfassets.net/23aumh6u8s0i/PdtPHtKHxiudV6PLeXyic/e40723969ec9b0bd62d1ab0a8cfb4a61/learn-identity-homepage)

### IAM, CIAM, Am I?

- [Identity and Access Management](https://auth0.com/docs/get-started/identity-fundamentals/identity-and-access-management) provides control over user validation and resource access, and it's commonly known as IAM.
- [Customer Identity and Access Management (CIAM)](https://auth0.com/blog/what-is-ciam/) how companies give their end users access to their digital properties as well as how they govern, collect, analyze, and securely store data for those users.

### No Time? Learn Identity In a Minute

- [Identity In a Minute Series](https://www.youtube.com/playlist?list=PLshTZo9V1-aHPyYQeq7skl2Y8lcANtvcI) is an ongoing series of 60-second shorts that describe key concepts in modern identity management, authentication, and authorization.

![ID in a minute thumbnails](https://images.ctfassets.net/23aumh6u8s0i/4eQTmKzd2uMVKaHnJ5oPUf/37a1be693263cc7413312f63a6b9714b/Screenshot_2023-12-05_at_23.12.33.png)

### More Time? Learn Directly from Identity Experts

- [Identity Unlocked Podcast](https://identityunlocked.auth0.com/): "Identity, Unlocked" is the podcast that discusses identity specs and trends from a developer perspective.
- [Authorization in Software Podcast](https://authorizationinsoftware.auth0.com/): "Authorization in Software" features chats with industry subject matter experts in authorization.

## Authentication

In [authentication](https://auth0.com/intro-to-iam/what-is-authentication), a user or application proves that they are who they say they are by providing valid credentials.

 There are many ways of authentication, though. 🤔 Learn about the most common ones:

- [Username and Password Authentication](https://auth0.com/blog/username-password-authentication/)
- [Passwordless Authentication](https://auth0.com/blog/what-is-passwordless-authentication/)
- [SMS Passwordless Authentication](https://auth0.com/blog/sms-passwordless-authentication/)
- [What is Single Sign-On Authentication and How Does It Work?](https://www.youtube.com/watch?v=Vp6kx4Sd_E0)

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

## Authorization  

[Authorization](https://auth0.com/intro-to-iam/what-is-authorization) is the process of giving someone the ability to access a resource.

People usually mix up [Authentication and Authorization](https://auth0.com/intro-to-iam/authentication-vs-authorization) because authentication usually leads to authorization, but authorization does not always lead to authentication.

Learn more about authorization and the different types: 👇

- [What Is The Right Authorization Model For My Application?](https://auth0.com/blog/whats-the-right-authorization-model-for-my-application/)
- [What is Role-Based Access Control (RBAC)?](https://auth0.com/intro-to-iam/what-is-role-based-access-control-rbac)
- [What is Fine-Grained Authorization?](https://docs.fga.dev/intro/authorization-and-okta-fga#what-is-fine-grained-authorization-fga)
- [Permissions, Privileges and Scopes - What's the Difference?!](https://youtu.be/vULfBEn8N7E?feature=shared)

## 2FA, MFA all-the-FA 

There are many options you can use to prove your digital identity. These are called [**authentication factors**](https://auth0.com/blog/not-all-mfa-is-created-equal/#Factors--Authenticators--and-Assurance), and there are three main types:

- knowledge or something that you know, like a password,
- possession or something that you have, like a device
- inherence, which is something that you are or is inherent to you. 

Usually, your application requires only one authentication factor to authenticate a user, typically a password. In some contexts, you may want more assurance about the user's identity. In that case, you can require two or more authentication factors. That's what two-factor authentication (2FA) and multi-factor authentication (MFA) are all about.

Learn more about 2FA and MFA 👇:

- [Two-Factor Authentication (2FA)](https://auth0.com/learn/two-factor-authentication)
- [The Working Principles of 2FA (2-Factor Authentication) Hardware](https://auth0.com/blog/the-working-principles-of-2fa-2-factor-authentication-hardware/)
- [The Working Principles of 2FA (2-Factor Authentication) Software](https://auth0.com/blog/the-working-principles-of-2fa-2-factor-authentication-software/)
- [2FA Using Biometrics](https://auth0.com/blog/two-factor-authentication-using-biometrics/)
- [Getting Started with Multi-Factor Authentication](https://auth0.com/learn/get-started-with-mfa)

## OAuth2, OIDC, Oh-what? 

There are many standards used for identity. Some of the most relevant are OAuth2 and OIDC. OAuth 2.0, which stands for "Open Authorization", is a standard designed to allow a website or application to access resources hosted by other web apps on behalf of a user. At the same time, Open ID Connect (OIDC) is an authentication protocol that utilizes the authorization and authentication mechanisms of OAuth 2.0. 

But what else is out there? Learn more here 👇

- [OAuth 2.0 Simplified](https://www.oauth.com/)
- [OAuth 2.0 and OpenID Connect (in plain English)](https://youtu.be/996OiexHze0?feature=shared)
- [OAuth in Five Minutes](https://youtu.be/KT8ybowdyr0?feature=shared)
- [An Illustrated Guide to OAuth and OpenID Connect](https://www.youtube.com/watch?v=t18YB3xDfXI)
- [OIDC Playground](https://openidconnect.net)
- [SAML Authentication](https://youtu.be/VzRnb9u8T1A?feature=shared): you can also use [samltool.io's](https://samltool.io/) playground to learn more

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

## Tokens, tokens, and more tokens!

A token is a piece of data that has no meaning or use on its own but, combined with the correct tokenization system, becomes a vital player in securing your application. There are different tokens, but what does each one do? How do you use them?

- [ID Tokens VS Access Tokens: What's the Difference?](https://youtu.be/vVM1Tpu9QB4?feature=shared)
- [What are Refresh Tokens?! and...How to Use Them Securely](https://youtu.be/LowJMwa7LCU?feature=shared)
- [Token-based Authentication Made Easy](https://auth0.com/learn/token-based-authentication-made-easy)
- [JSON Web Tokens](https://auth0.com/learn/json-web-tokens)
- [JWT.io](https://jwt.io)

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

## WebAuthn

WebAuthn is a W3C recommendation for defining an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications to authenticate users strongly. Here are some great resources to learn more:

- [A Developer's Guide to WebAuthN](https://youtu.be/rsJcXHUZhRY?feature=shared)
- [Enable Passwordless Login using Biometrics](https://youtu.be/d18xx_OJJ7U?feature=shared)

<br>
<include src="WebAuthnMeCTA" group="B"/>

## Passkeys

Passkeys are password replacements that provide a faster, easier, and more secure user login experience that leverages WebAuthn under the hood. Learn more about passkeys: 

- [webauthn.me/passkeys](https://webauthn.me/passkeys)
- [Our Take on Passkeys](https://auth0.com/blog/our-take-on-passkeys/) 
- [Passkeys in Action](https://www.youtube.com/watch?v=SWocv4BhCNg)
- [passkeys.dev](https://passkeys.dev/)

From Zero to Hero: Identity Edition

Should you use cookie-based or token-based authentication in ASP.NET Core Identity? Or should you use JWT and OpenID Connect?

.NET 8 has been released and many new exciting features are available to developers. In particular, this release brings [new options for authentication and authorization for ASP.NET Core Identity](https://auth0.com/blog/whats-new-dotnet8-authentication-authorization/). While these features have been long awaited, it seems that not everyone is happy with Microsoft's implementation choices, and there is some confusion among developers about the proper approach to use in their ASP.NET Core Identity-based applications. Let's try to shed some light on this not-so-simple topic.

## ASP.NET Core Identity: What’s New

One of the most criticized features of ASP.NET Core Identity until .NET 7 has been [its lack of *modern* authentication support for Single Page Applications](https://github.com/dotnet/aspnetcore/issues/42158). Whatever *modern* means, [ASP.NET Core Identity](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity) has provided support for cookie-based authentication since version 3.1. It has also provided a set of web pages that allow users to register, authenticate, recover passwords, etc.

However, the current trend in authentication for SPAs seems to be token-based rather than cookie-based, and ASP.NET Core Identity didn't support it. The only option provided with the built-in SPA templates was based on Identity Server, a third-party [OpenID Connect](https://openid.net/developers/how-connect-works/) server. This approach has been [deemed excessive for small projects](https://github.com/dotnet/aspnetcore/issues/42158#issuecomment-1153222403) by several developers, and in any case introduces a third-party dependency that not everyone may want.

To address this issue, .NET 8 introduces support for token-based authentication and a set of [Identity API endpoints](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-api-authorization) that let developers do through the API what they could already do through the old-style web pages.

> To learn more about [the new authentication and authorization features introduced by .NET 8, read this article](https://auth0.com/blog/whats-new-dotnet8-authentication-authorization).

Awesome! So the problem is fixed and we all live happily ever after.🎉

In fact, things are not quite like that. Some developers are not entirely happy. There are those who expected a different implementation, and those who are now confused about the correct use of the new options. Let's try to bring some order to all this confusion.

> Disclaimer: This article is not a step-by-step tutorial on how to add ASP.NET Core Identity to your application. Its purpose is to discuss the authentication modes that it supports as of .NET 8.0.

## Cookie or Token-based Authentication?

Now ASP.NET Core Identity provides you with two authentication options: cookie-based and token-based. But what is the actual difference between the two approaches?

### Cookie-based authentication

Cookie-based authentication is the typical approach used by the traditional server-side rendered web page model. This is the model used by ASP.NET Core MVC and Razor Pages, to put it bluntly. In this type of authentication, a server-generated cookie proves successful user authentication and represents the user session.

> To learn more about [the relationship between cookies and sessions, read this article](https://dev.to/andychiare/sessions-tokens-and-rocknroll-4pdc).

Roughly, the cookie-based authentication flow is as follows:

1. The user authenticates through a web page.
2. The server generates a cookie and sends it to the browser with the response page.
3. The browser sends the cookie with each new page request.
4. If the server finds the cookie in the incoming request, it can use it to get the relevant information to make its authorization decisions.

The fun fact is that the cookie's back and forth is automatically managed by the browser. Provided that the server applies all [the security best practices](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#cookies) to protect its cookies, your application doesn't need to care about storing them and sending them back with each request.

### Token-based authentication

Token-based authentication doesn't rely on cookies to prove user authentication. It relies on a token, which is a unique string of characters that also represents the user's session.

> To learn more about [how tokens help build sessions, check out this article](https://dev.to/andychiare/sessions-tokens-and-rocknroll-4pdc).

Awesome! How does the token-based flow work? Here is a rough description:

1. The user authenticates via a client-side page that calls the login endpoint.
2. The server generates a token and sends it to the app in the login endpoint's response.
3. The app sends the token with each new HTTP request.
4. If the server finds the token in the incoming request, it can use it to get the relevant information to make its authorization decisions.

As you can see, this flow is basically the same as the cookie-based flow. The only difference is that this one mentions the token instead of the cookie. So what is the real difference between the two approaches?

<details>
  <summary>What does authentication mean in this context?</summary>

If you are an experienced developer, you should already know the difference between **authentication** and **authorization**. Very roughly, authentication verifies the identity of the user while authorization verifies what the user can do.

Cookie-based authentication and token-based authentication are somewhat ambiguous terms. In fact, in this context, the cookie and the token indicate that the user has been successfully authenticated. However, they are used to make authorization decisions. When the server receives a request from a client, it checks if a cookie or a token is included in it. If so, the cookie or the token allows the server to somehow retrieve information to determine whether or not the request can be fulfilled. This information may also include the user profile data, of course. The specific way used to retrieve this information does not really matter.

This means that there is no real user authentication when sending a request to the server. User authentication has already taken place at the beginning of the session.
</details>

### Cookies and tokens: a quick comparison

As you learned in the previous sections, cookie-based and token-based authentication are very similar. The main visible difference is the artifact they rely on to prove authentication and support session creation. However, there are significant differences. I will not go into a detailed comparison between cookies and tokens, but I can't help but mention at least the following:

- **Cookies** are *tied to a domain*, require *little storage*, and are *automatically managed by the browser*. However, without proper precautions, they are vulnerable to [CSRF](https://auth0.com/blog/cross-site-request-forgery-csrf/) and [XSS attacks](https://auth0.com/blog/cross-site-scripting-xss/), are *not suitable for multi-domain applications*, and have *scalability issues*.
- **Tokens** are *not tied to only web applications* and they *promote server scalability*. However, *their management and security is left to the developer*. Depending on the type of token, there may be an *invalidation problem*, i.e. a revoked token may still be used by the client, and a *data transfer overhead* if the token size becomes significant.

> It's worth noting that while cookies in general can lead to scalability issues when used as pointers to server-side data, this is not the case with the authentication cookie issued by ASP.NET Core Identity. By default, this cookie contains encrypted data that allows the server to retrieve the user's identity information without having to access a server-side store. However, you need to [properly configure your servers](https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview) in order to share the same encryption/decryption key.

That said, when should you use one type of authentication over the other?

### Which authentication type to use?

There's a common belief that cookie-based authentication should be used for traditional server-side page-rendered applications, while token-based authentication is for SPAs and native applications.

Actually, the ASP.NET Core Identity framework uses the cookie-based authentication approach for ASP.NET Core MVC and Razor Pages applications. With these types of applications, each request triggers a complete reload of the entire web page in the browser. In previous versions of .NET, if you wanted to leverage the ASP.NET Core Identity built-in authentication pages in your SPA, the user experience would be disrupted. Users would pass from the partial page reload experience typical of a SPA to a full page reload experience. This is one of the reasons behind the request of token-based authentication from many developers. They feel that having a token and a set of authentication APIs, such as the Identity API, allows them to build a consistent user experience for SPAs. In addition, this API can also be used by native applications, i.e., desktop and mobile applications, which were excluded by the traditional cookie-based approach.

This criterion may seem reasonable, but...

## Wait! Identity API Endpoints Have Cookies Too?

So, in general, you might think that cookie-based authentication is meant for traditional server-rendered applications, while token-based authentication is meant for SPAs and native applications.

However, if you dig into [the currently sparse documentation](https://devblogs.microsoft.com/dotnet/whats-new-with-identity-in-dotnet-8/#securing-blazor-webassembly-apps), you will find that you can call the authentication endpoint (`/login`) with the `useCookies=true` parameter. In other words, you can call the following endpoint: `/login?useCookies=true`. What does this mean? What scenario does it cover?

Well, despite many developers thinking that SPA should use token-based authentication, this is not always the case. Think about this for a moment:

- Why should you use tokens and manage the back-and-forth and their security when you can use cookies to take advantage of the built-in capabilities of browsers?
- What can you do with a token that you can't do with a cookie?
- In other words, do you really need a token in your specific scenario?

As a general rule, you should use the right tool for your specific needs. Over-designing or following common sense can lead to extra work and possible risks because you have to worry about token security.

If the client of your Web API application is a native client, you are forced to use token-based authentication. Supporting cookies in native applications would be impractical. However, you can use cookies in your SPA. Provided that your application lives in a single domain, you can use cookies and their automatic management by browsers. Why not?

If your application consists of a SPA and a Web API, and you authenticate users locally using ASP.NET Core Identity, you should use cookie-based authentication. Technically, your application is a first-party application, and even [OAuth best practices](https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-14.html#section-6.1) recommend using this approach.

## Why Are These Tokens Not JWTs?

Another common misconception is that *token* means *JSON Web Token* (JWT). I've seen many developers react as shown in the following picture when they learn that the token issued by the Identity API is not in JWT format:

![Why not JWT?](https://images.ctfassets.net/23aumh6u8s0i/4CaZUMohAdvA2AiEDtfGjx/6585793bf36b74b70f29610f448ceb97/why-not-jwt.png)

Actually, that token has a proprietary format, although you can partially decode it. Read [this article](https://nestenius.se/2023/08/29/bearertoken-the-new-authentication-handler-in-net-8/) if you want to learn more about what's inside the access and refresh tokens issued by the Identity API.

Again, why do developers think the JWT format would have been better in this context? If your application is a first-party application in the authentication context, why do you need JWT?

The JWT format was invented to share information between two trusted parties. In the authentication and authorization context, a typical example of JWT adoption is when a third-party entity authenticates or authorizes a user. In this case, the third-party entity (the Identity provider or authorization server) issues a JWT containing the information related to the authentication or authorization result.

The need for a JWT arises from the fact that the third-party entity and your application are independent; they do not share a common data source.

Your application receives the result of the requested operation in the form of a JWT and it can verify that this information was actually issued by that entity by validating the token's signature. To be precise, only OpenID Connect defines a [JWT-based format for ID tokens](https://openid.net/specs/openid-connect-core-1_0.html#IDToken). OAuth 2.0 doesn't recommend [a specific format for access tokens](https://datatracker.ietf.org/doc/html/rfc6749#section-1.4), although [one is available](https://datatracker.ietf.org/doc/html/rfc9068).

> To learn more about [ID token and access token differences, see this article](https://auth0.com/blog/id-token-access-token-what-is-the-difference).

The point is, does your application really need the JWT format for access tokens? If so, your scenario may be different from what the Identity API was designed for. In a first-party scenario, your server should have all the information it needs to make authorization decisions.

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

## When Do You Need OpenID Connect and OAuth 2.0?

Developer reactions to the new Identity API make me think that they have been waiting for a built-in OpenID Connect and OAuth 2.0 implementation. They would probably expect Microsoft to have replaced Identity Server with its own OpenID Connect server. However, this may sound somewhat contradictory, since many have complained about the complexity of Identity Server in simple authentication scenarios.

Leaving aside speculation about what some developers expected, .NET 8 and its version of ASP.NET Core Identity is now here with its new authentication options. When should you use it in your applications and when do you need OpenID Connect and OAuth 2.0?

ASP.NET Core Identity can be the right solution if you need to build an application with basic authentication needs. Your users are authenticated locally, you don't expect much traffic and therefore don't plan to scale anytime soon, you don't have complex custom authentication needs. You can also integrate with external identity providers. I recommend using cookie-based authentication for web applications (including SPAs) and token-based authentication only for native apps.

OpenID Connect comes into play when your needs go beyond a simple authentication. You should look for a standards-compliant Identity provider if you need [Single Sign-On](https://auth0.com/docs/authenticate/single-sign-on) (SSO), for example. If you expose your API to third parties, you can leverage the benefits of a standard authorization approach such as OAuth 2.0. In these cases, ASP.NET Core Identity is not a good fit.

Check [this document](https://learn.microsoft.com/en-us/aspnet/core/security/how-to-choose-identity-solution?view=aspnetcore-8.0) for some guidance on when ASP.NET Core Identity is sufficient or when you need an OpenID Connect server.

## Some Caveats About Identity API Endpoints

The discussion so far is intended to help you make the right choices for authentication in your .NET applications based on your specific application scenario. This will help you avoid overdesign and make an informed choice about the right approach.

If you have decided to use the Identity API for your SPA and native application, there are still a few caveats that you still need to be aware of.

The Identity API is a great addition that allows you to leverage the user authentication and management under the hood, while you can customize your own UI. However, there is currently no way to make its endpoints unavailable. All Identity API endpoints are exposed. For example, anyone can call the `/register` endpoint to create a new user, regardless your application's business logic expects self-registered users or not. Presumably this will be fixed in the future, but as for .NET 8, it's like this.

A second concern is that you can't customize the Identity API endpoints. In most cases, you may not need customization, but what can you do if you need to customize the data required in the `/registration` endpoint? Or even add an unsupported authentication method, such as [WebAuthn](https://webauthn.me/introduction)?

Include these questions in your ASP.NET Core Identity evaluation.

<include src="SignupCTA" />

## Recap

In summary, .NET 8 brings exciting new features to ASP.NET Core Identity: token-based authentication and the Identity API.

However, this does not mean that they are the right approach for your specific scenario. Take some time to analyze what you need right now and in the near future. Don't follow the trend without carefully analyzing your needs and what ASP.NET Core Identity can offer you. You probably don't need token-based authentication for your SPA. Perhaps the simple token format for the Identity API is enough for your needs.

Anyway, if your analysis leads you to use OpenID Connect, don't forget that [Auth0 can help you](https://a0.to/blog_signup)! 😎


Cookies, Tokens, or JWTs? The ASP.NET Core Identity Dilemma

Let’s explore the new features brought by .NET 8 to support authentication and authorization in your applications.

The release of **.NET 8** is just around the corner. Among the amazing features it brings to developers, it offers a minor revolution in support for authentication and authorization: moving ASP.NET Core Identity from a page-oriented approach to an API-oriented approach.

Let's explore what's going on.

## ASP.NET Core Identity and Token-based Authentication

ASP.NET Core developers have the built-in [ASP.NET Core Identity](https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity) framework to add support for local authentication and authorization. The identity framework includes everything that developers typically need to authenticate and authorize users against a local user store. By default, a SQL Server database is created on Windows and a SQLite database is created on macOS, but you can change it to the DBMS of your choice.

The ASP.NET Core Identity framework is designed for server-rendered web applications, such as ASP.NET Core MVC or Razor Pages applications, and has challenges with SPAs, where token-based authentication seems more appropriate. To address this problem, Microsoft has provided built-in project templates for SPAs based on Angular and React with Identity Server support since .NET Core 3.1. However, the .NET community [has not been totally happy with this approach](https://github.com/dotnet/aspnetcore/issues/42158). To [meet the community's demands](https://github.com/dotnet/aspnetcore/issues/42158#issuecomment-1481742187), Microsoft removed the default support for Identity Server in .NET 8 and redesigned the internal architecture of ASP.NET Core Identity to be more suitable for SPAs and native apps. .NET 8 introduces a new set of Identity API endpoints and support for token-based authentication. But let's go in order.

## Bearer Token Authentication Handler

The first building block of this new infrastructure is the new [bearer token authentication handler](https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.dependencyinjection.bearertokenextensions.addbearertoken). This handler is similar to the classic [cookie authentication handler](https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.dependencyinjection.cookieextensions.addcookie) that ASP.NET Core Identity uses by default. The cookie authentication handler is responsible for two things:

- Creating a new session cookie after the user authenticates.
- Building a `ClaimsPrincipal` user object based on a valid session cookie received in the incoming HTTP request.

Similarly, the bearer token authentication handler is responsible for:

- Creating a new token after the user authenticates.
- Building a `ClaimsPrincipal` user object based on a valid token received in the incoming HTTP request.

In other words, the bearer token handler mimics the behavior of the cookie handler to manage authenticated sessions based on a token instead of a cookie.

> Note that the tokens generated by the bearer token handler are not in JWT format. Also, they don't follow any specific standard. While the documentation mentions [access tokens](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.bearertoken.accesstokenresponse.accesstoken?view=aspnetcore-8.0) and [refresh tokens](https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.bearertoken.accesstokenresponse.refreshtoken?view=aspnetcore-8.0), they do not implement the [OAuth 2.0 authorization framework](https://oauth.net/2/).

How can this bearer token handler be used in practice?

Consider the following code:

```csharp
// Program.cs

using Microsoft.AspNetCore.Authentication.BearerToken; //👈
using System.Security.Claims;
 
var builder = WebApplication.CreateBuilder(args);
 
builder.Services
    .AddAuthentication()
    .AddBearerToken();  //👈
builder.Services.AddAuthorization();
 
var app = builder.Build();
 
app.MapGet("/login", (string username) =>
    {
        var claimsPrincipal = new ClaimsPrincipal(
          new ClaimsIdentity(
            new[] { new Claim(ClaimTypes.Name, username)},
            BearerTokenDefaults.AuthenticationScheme  //👈
          )
        );

        return Results.SignIn(claimsPrincipal);
    });
 
app.MapGet("/user", (ClaimsPrincipal user) =>
    {
        return Results.Ok($"Welcome {user.Identity.Name}!");
    })
    .RequireAuthorization();
 
app.Run();
```

This application defines two API endpoints:

- The `/login` endpoint creates a `ClaimsPrincipal` user object based on the username sent in the HTTP request and returns the result of signing in.
- The `/user` endpoint returns the username of the authenticated user.

Note the highlighted lines in the code. You have a reference to the new `Microsoft.AspNetCore.Authentication.BearerToken` namespace, which gives you access to the `BearerTokenDefaults.AuthenticationScheme` value. You also configure the bearer token middleware by using the `AddBearerToken()` extension method.

Now, assume you call the `login` endpoint with curl, as shown below:

```bash
curl 'https://<YOUR_HOST>/login?username=joe'
```

You will see a result like the following:

```json
{
  "token_type": "Bearer",
  "access_token": "CfDJ8Ha5YkqG...omitted content...",
  "expires_in": 3600,
  "refresh_token": "CfDJ8Ha5YkqG...omitted content..."
}
```

This JSON contains an access token and a refresh token that you can use to make your calls to the protected APIs exposed by your application. For example, you can now call the protected `/user` endpoint as follows:

```bash
curl -i https://<YOUR_HOST>/user \
-H 'Authorization: Bearer CfDJ8Ha5YkqG...omitted content...'
```

And you will get the following response:

```json
Welcome joe!
```

In summary, the bearer token authentication handler makes it very easy to set up token-based authentication. This is the building block of the whole ASP.NET Core Identity transition to token-based authentication.

## Identity API Endpoints

The second step in adding token-based authentication to ASP.NET Core Identity is to introduce the Identity API endpoints. Basically, this is an API version of the actions that you can perform with ASP.NET Core Identity through the classic web UI. Once you enable the [Identity API endpoints](https://github.com/dotnet/aspnetcore/blob/main/src/Identity/Core/src/IdentityApiEndpointRouteBuilderExtensions.cs), you will get endpoints like `/register`, `/login`, `/forgotPassword`, `confirmEmail`, etc.

The Identity API endpoints solve two of the most complained problems:

- You can build your own UI for user authentication and account management while maintaining the overall UI style of your application.
- After authentication, your app can get access tokens instead of cookies, so it's a more suitable approach for SPAs and native applications.

> Keep in mind that the Identity API endpoints do not implement [OpenID Connect (OIDC)](https://auth0.com/docs/authenticate/protocols/openid-connect-protocol). They simply expose the standard functionality provided by the ASP.NET Core Identity UI through a custom API. They are intended for first-party authentication.

Adding the Identity API endpoints to an ASP.NET Core application relies on two new methods:

- `AddIdentityApiEndpoints()`, which configures the token-based authentication using the bearer token handler in addition to the cookie authentication, and adds a set of identity services.
- `MapIdentityApi()`, which actually adds the Identity endpoints to your application.

The code in your `Program.cs` file will look like the following:

```csharp
// Program.cs

using System.Security.Claims;
using Microsoft.AspNetCore.Identity;
using Microsoft.AspNetCore.Identity.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthorization();

builder.Services.AddDbContext<ApplicationDbContext>(
    options => options.UseSqlite(builder.Configuration["ConnectionString"]));

builder.Services.AddIdentityApiEndpoints<IdentityUser>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

var app = builder.Build();

app.MapIdentityApi<IdentityUser>();

app.MapGet("/user", (ClaimsPrincipal user) =>
    {
        return Results.Ok($"Welcome {user.Identity.Name}!");
    })
    .RequireAuthorization();

app.Run();
```

Your client will be able to register a user by calling the `/register` endpoint, authenticate the user through the `/login` endpoint, and so on.

While the Identity API endpoints seem to solve the two main complaints about the classic ASP.NET Core Identity, there are [some concerns about using them in a production context](https://andrewlock.net/should-you-use-the-dotnet-8-identity-api-endpoints/), mainly on the security and scalability side.

## Blazor Identity UI

In addition to the changes to ASP.NET Core Identity, .NET 8 integrates the authentication framework into the Blazor project template. You can create a new .NET 8 Blazor application with identity support by running the following command:

```bash
dotnet new blazor -au Individual
```

You will get a Blazor application with everything you need to manage users and authentication locally. You will get a SQLite database to store the user accounts. You will get a SQL Server database if you use Visual Studio to scaffold the application instead of the .NET CLI. You also will get all the pages that allow users to register, authenticate, and manage their account.

The following image shows the built-in login page of a Blazor app:

![Blazor login page](https://images.ctfassets.net/23aumh6u8s0i/3J8DlVMk9qsHw9tLIAwpue/cd94d62d51ce5dc6627bda3c75d14a42/blazor-identity-ui-login.png)

The user authentication and management pages that implement the Blazor Identity UI are not Razor pages as it happens with the classic ASP.NET Core Identity, but [Razor components](https://learn.microsoft.com/en-us/aspnet/core/blazor/components). The template provides you with the source code for all of the UI components in the `Pages/Account` folder of the project. This allows you to customize them according to your application design.

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

## Custom Authorization Policies Simplification

Apart from the new features related to ASP.NET Core Identity, .NET 8 introduces a simplification to the definition of custom authorization policies. Previously, you had to write a lot of code to define a parameterized authorization policy to apply to an API endpoint.

For example, suppose you want to define a policy for an endpoint that only authorizes users over the age of 18 and that can be used as shown below:

```csharp
[ApiController]
[Route("api/[controller]")]
public class DrinkController : Controller
{
    [MinimumAgeAuthorize(18)]
    [HttpGet("beer")]
    public string BeerDispenser(ClaimsPrincipal user) => $"Here is your beer, {user.Identity?.Name}!";
}
```

With previous .NET versions, to implement your custom authorization policy, you must write the code outlined in the following code snippet:

```csharp
class MinimumAgeAuthorizeAttribute : AuthorizeAttribute
{
  ...
}

class MinimumAgePolicyProvider : IAuthorizationPolicyProvider
{
  ...
}

class MinimumAgeRequirement : IAuthorizationRequirement
{
  ...
}

class MinimumAgeAuthorizationHandler : AuthorizationHandler<MinimumAgeRequirement>
{
  ...
}
```

You must define an `AuthorizeAttribute`. Then you need to implement an `IAuthorizationPolicyProvider` to handle your custom policy and an `IAuthorizationRequirement` to define the requirement. Finally, you have to implement the `AuthorizationHandler`.

The code snippet shown above outlines the classes you need to implement. To see an example of the actual implementation, take a look at this [code sample](https://gist.github.com/captainsafia/309e408cb5e2c2e5acd44d2e19f7f88e).

Using the new `IAuthorizationRequirementData` interface, your implementation code becomes as follows:

```csharp
class MinimumAgeAuthorizeAttribute : AuthorizeAttribute, IAuthorizationRequirement, IAuthorizationRequirementData
{
  public MinimumAgeAuthorizeAttribute(int age) => Age =age;
  public int Age { get; }

  public IEnumerable<IAuthorizationRequirement> GetRequirements()
  {
    yield return this;
  }
}

class MinimumAgeAuthorizationHandler : AuthorizationHandler<MinimumAgeAuthorizeAttribute>
{
  protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, MinimumAgeAuthorizeAttribute requirement) 
  {
    ...
  }
}
```

You only need to implement two classes instead of four as in the previous example. See [here](https://gist.github.com/captainsafia/7c54e92d12df695ff0908e989fb8531f) for the complete code.

## Summary

Throughout this article, you have learned about the new features that .NET 8 brings to support authentication and authorization. Most of these features are related to the extension of the ASP.NET Core Identity framework to support token-based authentication, which paves the way for authentication in SPAs and native applications.

As a side effect, you get access to the bearer token authentication handler, which allows you to issue access tokens, and to the Identity API endpoints, which allow you to embed authentication support in your Web API.

In addition, the Blazor project template now supports authentication through the Identity API endpoints and a rich set of Razor components designed for user authentication and management.

Finally, the new `IAuthorizationRequirementData` interface allows you to create custom authorization policies with less code.


.NET 8: What's New for Authentication and Authorization

Ryan Friess

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

Sr. Sales Engineer - ID.me

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

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

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

## The Power Duo: Auth0 and ID.me

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

## How Does It Work? 

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

## Turnkey Integration of ID.me on Auth0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<AmpContent>
<amp-youtube
    data-videoid="Vd9zZcsGUkE"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div class='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/Vd9zZcsGUkE' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## Conclusion 

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

Strengthen Your Application Security beyond Authentication

evan-sims

Evan is a software engineer on the DX-SDKs team at Auth0, and his pronouns are He/Him. He's passionate about helping developers build great (and secure!) software, a big fan of PHP, Laravel, Symfony, and WordPress, and an avid FOSS contributor. Before joining Auth0, he created free and open-source software supporting humanitarian aid and citizen journalism efforts. Once upon a time, he worked as a technical designer in the video games industry; he's more focused on playing them these days. He loves reading, traveling, spending time outdoors with his partner, and writing his blog autobiographies in the third person.

SDK Engineer

Evan Sims

Integrate Auth0 in your Laravel applications with no code by using the new Laravel SDK.

[Laravel](https://laravel.com/) is a tremendously popular web application framework — with good reason! Now in its 10th generation, the framework has built up a robust and mature foundation that’s not just battle-tested but genuinely delightful to build applications with. Laravel has elevated the entire PHP experience to a new level thanks to its incredibly passionate developer community. These days it’s nearly become as synonymous with PHP as Rails has with Ruby. And with PHP running on [at least 80% of web servers](https://kinsta.com/blog/is-php-dead/), that’s a big deal. For a good reason, companies like Disney, Warner Brothers, Twitch, and The New York Times have embraced Laravel.

Auth0 has offered a Laravel SDK for many years — our first release dates back to 2014! A lot has changed since then, and like all our SDKs, we’ve evolved to fit the times and the community’s needs. Every new release is an opportunity to iterate, improve, and create a better developer experience.

Early last year, [we released v7 of our Laravel SDK](https://github.com/auth0/laravel-auth0/), which was a big one. We rewrote the SDK from the ground up to take advantage of [PHP 8](https://stitcher.io/blog/new-in-php-8) and [Laravel 9](https://kinsta.com/blog/laravel-9/) and restructured everything on top of our massively upgraded core [PHP SDK v8](https://github.com/auth0/auth0-php). For the first time, developers could integrate authentication with Auth0 in their Laravel apps in less than ten lines of code, and it was great!

But we wondered — what if you could do it with zero lines of code?

Over the last few months, we’ve been striving to create that experience for our Laravel developers, and as of [v7.8 release](https://github.com/auth0/laravel-auth0/releases/tag/7.8.0), we’ve reached that milestone (and so much more).


## With Great Power...

Laravel is a robust framework created to support practically any kind of application developers might want to build. It’s one of those rare frameworks that has managed to strike a harmonious balance between powerfully customizable and highly opinionated. And when it comes to something as critical to an application as authentication, if you’re going to tackle the subject, you better be sure you’re striking that same balance successfully. It should “just work” while also being flexible enough to mold to the most niche scenarios.

Admittedly in the past, our Laravel SDK has not always hit that mark on addressing those niches, particularly in supporting monolithic apps; that is, apps that serve JSON APIs with token-based authorization as well as modern frontends with session-based authentication, in the same codebase. The community asked us to create a better solution, but there were some technical hurdles to work through first.

Traditionally, our SDK exposed authentication through a single API, which made integration super simple but meant that, on occasion, developers had to figure out how to support some exotic use cases using just a single SDK configuration. It simply didn’t always work as elegantly as one would hope.

With v7.8, we went back to the drawing board to address this. We took a deep dive into the core of Laravel’s Authentication APIs, drilling into the framework’s source code, and began laying the groundwork for a whole new approach that let us support every type of application (yes, even those tricky monolithic apps!) in exciting new ways. We even learned some new tricks along the way!


## Real Artists Ship

Efforts toward these ends [began with 7.2](https://github.com/auth0/laravel-auth0/releases/tag/7.2.0), where we started working on the foundation of our new approach. We started by building the support we needed to do this right. We began by releasing support for native Laravel sessions, persistent session storage, and support for Laravel’s native caching APIs. We built experimental [Octane](https://laravel-news.com/laravel-octane-for-scale) support for supercharged applications. We improved reliability by achieving 100% code coverage and implemented mutation testing and triple-filtered static analysis to ensure we caught as many edge cases as possible. We cut a new release each month, bringing us closer to our new goal: a no-code solution that addresses all our customers' requests.

And today, finally, with 7.8, we’ve reached our goal. There’s so much to share, but we’ll distill it down to the headline features:


### Changing of the Guard(s)

With 7.8, we released two completely new Guards that leverage every aspect of Laravel’s powerful Authentication API. These new Guards — one for session-based authentication and the other for token-based endpoint authorization — enable support for applications of all types and use cases, finally addressing the demands of those monolithic app developers.

Previously, you had to write the following code:

```php
Route::middleware(['guard:auth0', 'auth0.authenticate'])->get('/messages', function () { 
    // ...
});
```

Today you just write as follows:

```php
Route::get('/messages', function () {
    //...
} })->middleware('auth'); 
```

We created a suite of new middleware and services that support using these Guards without any integration work within the application. There are no editing files, defining middleware, or Kernel changes; it just works. Authentication is immediately available, and any routes configured to use Laravel’s native `‘auth’` middleware for limiting access to authenticated sessions instantly work with Auth0. **Zero lines of code!**

Previously, you had to define your guards and provider...

```
// config/auth.config: 
return [ 
    'guards' => [ 
        'auth0' => [ 
            'driver' => 'auth0.guard', 
            'provider' => 'auth0-provider', 
        ]
    ],
    'providers' => [ 
        'auth0-provider' => [ 
            'driver' => 'auth0.provider', 
            'repository' => \Auth0\Laravel\Auth\User\Repository::class, 
        ]
    ],
];
```
...and modify the Kernel:

```php
// app/Http/Kernel.php: 
use Illuminate\Foundation\Http\Kernel as HttpKernel; 

class Kernel extends HttpKernel 
{
protected $middlewareGroups = [ 
    'web' => [ 
        \App\Http\Middleware\EncryptCookies::class, 
        \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class, 
        \Illuminate\Session\Middleware\StartSession::class, 
        \Illuminate\View\Middleware\ShareErrorsFromSession::class, 
        \App\Http\Middleware\VerifyCsrfToken::Class, 
        \Illuminate\Routing\Middleware\SubstituteBindings::Class, 
        \Auth0\Laravel\Auth\Guard::class, 
    ]; 
} 
// routes/web.php: 
use Auth0\Laravel\Http\Controllers\{Callback, Login, Logoutl}; 
Route::group(['middleware' => ['web', 'guard:auth0'], static function (): void {
    Route::get('/login', Login::class)->name('login'); 
    Route::get('/logout', Logout::class)->name('logout'); 
    Route::get('/callback', Callback::class)->name('callback');
    }); 
```

Today, this is all you need to do:

```php
// Nothing! 🎉
```

And for the first time, we now support Laravel’s powerful native Authorization API, which enables developers to write permissions-based gates and policies that can use Auth0’s RBAC with APIs for fine-grained access control.

This is what you had to write previously:

```php
Route::middleware(['guard:auth0', 'auth0.authenticate'])->group(function () { 
    Route::get('/messages', function () { 
        return response("You're authorized to read messages."); 
    })->can('auth0.authorize:read:messages'); 
}); 
```
Here is what you have to write today:

```php
Route::get('/messages', function () { 
    return response("You're authorized to read messages."); 
})->middleware('auth')->can('read:messages'); 
```

### Auth0 CLI: First-Class Configuration

To support these new guards, we completely reinvented our SDK configuration API — and ended up building something profoundly flexible and capable. Our new configuration API enables us to support an infinite number of Guard instances in memory at any given time, supporting every conceivable need a developer might have for their application’s authentication needs — which is particularly important for Octane applications.

Our goal with the new configuration API was to simplify the integration experience dramatically, taking a sometimes lengthy explanation process involving application configuration instructions and `.env` file editing down to just a few error-proof steps.

What we arrived at was a whole new configuration experience powered by the Auth0 CLI. The CLI is an exciting tool that guides developers in managing their tenants through an elegant command-line interface. It was a perfect fit for simplifying one of the biggest challenges of getting started with the SDK, so we baked in native support for the CLI. Now, the JSON expressed by the CLI can be used to directly configure an application’s Auth0 SDK integration. **For the first time, you can configure your tenant and SDK in a single command.** It’s pretty awesome!


### The Quickest of Quickstarts

We’re always looking for ways to improve a developer’s first experiences with our SDKs, and that all begins with the quickstart. These starter applications demonstrate how a developer can integrate base applications with fully functional authentication as efficiently as possible — ideally resulting in a working app in 5 minutes or less.

Now that we’ve achieved no-code and integrated the Auth0 CLI, developers can do this with their Laravel application in **less than a minute**.

We re-wrote our Laravel quickstarts from the ground up to showcase this new configuration approach and demonstrate these new features, which cut the length of our quickstart in half. We also reworked the GitHub repository so developers can use it as a starting template for new Laravel applications with a single command.

Want a fully functional Laravel 9 application with Auth0 authentication out of the box? You got it!

```
composer create-project auth0-samples/laravel
```

Ready to configure it? Done!

```
./auth0 apps create \ 
--name "My Laravel Application" \ 
--type "regular" \ 
--auth-method "post" \ 
--callbacks "http://localhost:8000/callback" \ 
--logout-urls "http://localhost:8000" \ 
--reveal-secrets \ 
--no-input \ 
--json > .auth0.app.json 
```

You have a ready-to-ship app with completely functional authentication and access control.

## Integration Comparison

Let's compare how you would have integrated Auth0 previously with how you do it today.

### The old-days integration

Previously, you should have started with the installation:

```
$ composer global require laravel/installer 
$ laravel new example-app 
$ cd example-app 
$ composer install 
$ composer require auth0/laravel 
```

Then, you should have created an application in the [Auth0 dashboard](https://manage.auth0.com/)...

![Setup — Auth0 Application Creation](https://images.ctfassets.net/23aumh6u8s0i/4QoFmUwS0wdwyaHrQe5Ynr/444d87da9a8fabb23ad449dbc83de48b/09_-_Setup___Auth0_Application_Creation.png)

...and configured it:

![Setup (Continued) — Auth0 Application Configuration](https://images.ctfassets.net/23aumh6u8s0i/S2eVoxkVBulc96Ei8KrOn/1f2c5d6eedcbea27533337c60ccfd644/10_-_Setup__Continued____Auth0_Application_Configuration.png)

Back to your application, you should have configured it with the Auth0 registration data:

```
AUTH0_DOMAIN="..." 
AUTH0_CLIENT_ID="..." 
AUTH0_CLIENT_SECRET="..." 
AUTH0_COOKIE_SECRET="..." 
AUTH0_AUDIENCE="..." 
```

You should have defined your Guards and provider:

```php
// conflg/auth.config: 
return [ 
    'guards' => [ 
        'auth0' => [ 
            'driver' => 'auth0.guard', 
            'provider' => 'auth0-provider', 
        ]
    ], 
    'providers' => [ 
        'auth0-provider' => [ 
            'driver' => 'auth0.provider', 
            'repository' => \Auth0\Laravel\Auth\User\Repository::class,
        ]
    ], 
];
```

You should have defined your middleware in the Kernel:

```php
// app/Http/Kernel.php: 
use Illuminate\Foundation\Http\Kernel as HttpKernel; 

class Kernel extends HttpKernel 
{
    protected $middlewareGroups = [ 
        'web' => [ 
            \App\Http\Middleware\EncryptCookies::class, 
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class, 
            \Illuminate\Session\Middleware\StartSession::class, 
            \Illuminate\View\Middleware\ShareErrorsFromSession::class, 
            \App\Http\Middleware\VerifyCsrfToken::Class, 
            \Illuminate\Routing\Middleware\SubstituteBindings::class, 
            \Auth0\Laravel\Auth\Guard::class,
        ];
} 
```

You should have added support for authentication...

```php
// routes/web.php: 
use Auth0\Laravel\Http\Controllers\fCallback, Login, Logout}; 

Route::group(['middleware' => ['web', 'guard:auth0'], static function (): void {
    Route::get('/login', Login::class)->name('login'); 
    Route::get('/logout', Logout::class)->name('logout'); 
    Route::get('/callback', Callback::class)->name('callback');
    }); 
```

...and optionally configure the application's routing:

```php
Route:middleware('guard:auth0', 'auth0.authenticatel)->group(function () { 
    Route::getr('/messages', function () { 
        return response("You're authorized to read messages."); 
    })->can('auth0.authorize:read:messages'); 
});
```

### Today's integration

With the new SDK, you integrate Auth0 in your Laravel application in two easy steps.

First step, create a new application:

```
$ composer create-project auth0-samples/laravel
```

Second step, configure your application through the Auth0 CLI:

```
./auth0 apps create \
--name "My Laravel Application" \
--type "regular" \
--auth-method "post" \
--callbacks "http://localhost:8000/callback" \
--logout-urls"http://localhost:8000"\
--reveal-secrets \
--no-input
--json > .auth0.app.json
```

Optionally, configure its routing this way:

```php
Route::get('/messages', function () { 
    return response("You're authorized to read messages."); 
})->middleware('auth')->can('readmessages'); 

```

## Conclusion

At Auth0, we never stop innovating, and our SDKs are absolutely no exception. With v7.8, we’ve achieved a powerful no-code integration, an incredibly streamlined configuration scheme powered by the Auth0 CLI, and we now offer our quickest quickstarts ever. We’re proud of our latest Laravel release, but more importantly, we’re excited to see what developers build with it. We wouldn’t have gotten here without the valuable feedback of our developer community, and we’re excited to continue building the future of authentication in Laravel together.


Authentication with Laravel: Raising the Bar with a No Code Future

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

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

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

## What Happened in Round One

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

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

ChatGPT gave correct answers to these questions:

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

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


## And Now, Round Two! 

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

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

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

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

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

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

```swift
import Auth0

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

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

                    completion(nil)

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

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

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

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

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

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

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

I ran the app...

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


## A Closer Look At ChatGPT’s Code

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

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


### The Auth0Manager class

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

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

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


### The WebAuth instance

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

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

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

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

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

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

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

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

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

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

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

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

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

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


### The login() method

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

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

                completion(nil)

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

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

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

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

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

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

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

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

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

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

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


### The logout() method

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

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

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

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

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

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

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

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


## Is Your Developer Job Safe?

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

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

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

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

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

diegopoza

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

Sr Manager, Developer Advocacy

Diego Poza

Compromised credentials are a threat to your business and customers. Here’s how to reduce the risk.

Credential stuffing is a type of cyberattack in which a cybercriminal uses stolen usernames and passwords from one organization (obtained in a breach or purchased off of the dark web) to access user accounts at another organization.

Credential stuffing attacks are one of the most common causes of data breaches because[ 64% of all people](https://f.hubspotusercontent20.net/hubfs/3791228/2022%20SpyCloud%20Annual%20Identity%20Exposure%20Report.pdf) reuse the same password on multiple (and sometimes all) accounts. In fact, on Auth0's platform alone,[ nearly half of all login requests](https://auth0.com/resources/whitepapers/credential-stuffing-attacks) we receive each day are attempts at credential stuffing.

The opportunity for cybercriminals to use credential stuffing is only growing as more credentials are exposed through breaches; at present, literally billions of compromised credentials are circulating on the dark web. 

However, credential stuffing attacks are preventable if you implement the right cybersecurity measures. Below is what executives need to know about credential stuffing attacks and what can be done to reduce or prevent the likelihood that their organizations will be a victim of one.

> More in the following:
>
> - **[Credential stuffing whitepaper](https://auth0.com/resources/whitepapers/credential-stuffing-attacks)**
> - **[What is broken authentication](https://auth0.com/blog/what-is-broken-authentication/)**

## How Credential Stuffing Works

To execute a credential stuffing attack, cybercriminals add a list of stolen username and password pairs to a botnet that automates the process of trying those credentials on multiple sites at once. Large-scale botnet attacks can overwhelm a business' IT infrastructure, with websites experiencing as much as[ 180 times](https://auth0.com/blog/auth0-reveals-50000-credential-stuffing-attempts/) their typical traffic during an attack.

![Anatomy Credential Stuffing](https://images.ctfassets.net/23aumh6u8s0i/ohyMA4nbwQgkGF77RnSOs/b8997e017022790f156a985fb97c375d/anatomy-credential-stuffing.jpg)

Once cybercriminals find a site where a set of credentials works, they’ll have access to a user's account and personal data to do with as they please, which most commonly includes:

* **Selling access to compromised accounts:** This is particularly common for media streaming services. [Disney+](https://www.cpomagazine.com/cyber-security/new-disney-plus-streaming-service-hit-by-credential-stuffing-cyber-attack/),[ Netflix, and Spotify](https://www.engadget.com/2019/03/13/wickedgen-admin-arrested-stolen-passwords-netflix-spotif/) have all been victims of attacks in which hackers sold access to user accounts for less than the cost of a subscription.
* **E-commerce fraud:** Hackers can impersonate legitimate users at retailers' websites and order a high-value product, either for their own use or for reselling. This is a common (and for criminals, potentially lucrative) form of identity theft, which makes retail the most vulnerable vertical for credential stuffing, according to[ research from Akamai](https://www.akamai.com/newsroom/press-release/akamai-research-commerce-remains-top-target-with-over-14-billion-web-application-and-api-attacks).
* **Corporate/institutional espionage and theft:** While the above crimes have serious consequences for companies and their customers, this third form of attack has the potential to be most devastating for businesses. If an attacker successfully hijacks the account of an employee or admin, they could gain access to all sorts of sensitive personal information, like credit card numbers, social security numbers, addresses, and login credentials as well, all of which they can sell to the highest bidder.

## The Costs of Credential Stuffing Attacks

Although credential stuffing attacks often have a low success rate ([usually one to three percent](https://www.recordedfuture.com/credential-stuffing-attacks/)), their impact on organizations is often anything but small.

For example, the Ponemon Institute's ["Cost of Credential Stuffing" report](https://library.idgcommunications.net/idgcampaigns/documents/uploaded_data/d40/97b/1c-/original/the-cost-of-credential-stuffing_EN.pdf) found that businesses lose an average of $6 million per year to credential stuffing in the form of application downtime, lost customers, and increased IT costs.

Increasingly, regulators, as well as the public, are also holding companies accountable for credential stuffing attacks with stiff fines. Companies may be subject to legal action under data privacy laws such as [GDPR](https://auth0.com/docs/compliance/gdpr) if they fail to implement adequate security measures to prevent such attacks, fail to inform the public of a breach, or don't do enough to protect passwords.

For example, in 2018, the UK's [Information Commissioner's Office (ICO) fined Uber](https://www.computerweekly.com/news/252453244/ICO-fines-Uber-385000-for-data-protection-failings) £385,000 for "a series of avoidable data security flaws" that exposed the data of approximately 2.7 million UK customers. And in 2021, the French Data Protection Authority (CNIL) fined a data controller and its data processor €225,000 “for failure to implement adequate security measures to protect customers’ personal data against credential stuffing attacks on the website of the data controller.”

## Credential Stuffing Attacks vs. Brute Force Attacks

Credential stuffing is considered a type of brute force cyberattack. But in practice, the two are very different, as are the best ways to secure your systems against them.

Brute force attacks attempt to guess passwords by changing the characters and numbers (often in prescribed patterns or with commonly used base password phrases). To protect against them, you can limit the number of failed login attempts with[ brute force protection](https://auth0.com/docs/attack-protection/brute-force-protection), use a CAPTCHA, or require your users to use a stronger password.

However, a strong password won’t stop a cybercriminal from gaining access to an account via credential stuffing because the password is already known. Even CAPTCHA's or brute force protection’s ability to protect users is limited since users often[ change their passwords in predictable patterns](https://www.sans.org/security-awareness-training/blog/time-password-expiration-die) and cybercriminals have a breached password to iterate from.

## How to Prevent Credential Stuffing Attacks

Most people know password reuse is unsafe but choose to use the same password on multiple sites anyway because they have roughly[ 100 passwords to remember](https://tech.co/news/average-person-100-passwords). Password managers are an option, but [adoption rates are low](https://www.security.org/digital-safety/password-manager-annual-report/). So to prevent credential stuffing attacks, it’s up to organizations to take measures — such as removing passwords altogether — to ensure cybercriminals can’t use stolen credentials to access their users’ accounts. Based on [OWASP's Credential Stuffing Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html), below are several methods for doing so.

### Credential hashing

Credential hashing is the first step to protecting your user's credentials from theft. [Hashing](https://auth0.com/blog/hashing-passwords-one-way-road-to-security/) scrambles a user's password before you store it in your database so that in the event that it is stolen, a hacker won’t be able to use them (in theory, at least).

In practice, not all password hashing is uncrackable. As Rick Redman, a penetration tester at KoreLogic, [explains](https://www.wired.com/2016/06/hacker-lexicon-password-hashing/), “The strength of the hash is the insurance policy. It tells you how much time users have to change their passwords after a data breach before they come to harm... If it’s just SHA1, there is no window... If it’s bcrypt, you have time to run away and change all your passwords.”

So although hashing user passwords won’t prevent a credential stuffing attack, it will limit what a cybercriminal can do with those passwords once they’ve stolen them.

### Breached password protection

Breached password protection compares the password a person uses to log in against databases of compromised credentials (like[ haveibeenpwned](https://haveibeenpwned.com/)) to prevent credential stuffing in real-time. 

For example,[ Auth0's breached password detection](https://auth0.com/docs/attack-protection/breached-password-detection) can be configured to notify a user, block them from logging in, or request an additional authentication factor (MFA) if it suspects their credentials were part of a published security breach or if a login attempt came from a suspicious IP address.

### Bot detection

As mentioned earlier, attackers use bots to execute a credential stuffing attack. [Auth0's bot detection](https://auth0.com/docs/secure/attack-protection/bot-detection) feature is able to identify a bot attempting to authenticate with [a high percentage of success](https://auth0.com/blog/auth0-bot-detection-reduces-bot-attacks-by-79/). It provides protection against credential stuffing attacks with very little friction to legitimate users. When a bot attack is detected, it displays a CAPTCHA step in the login experience to eliminate bot and scripted traffic.

### Anomaly detection

Monitoring what is happening is always a good approach to intervene earliest and stop an attack. If you have visibility of your traffic, you can understand when you are under attack, and you can take action to mitigate attacks. In Auth0, you can use [Log Streams](https://auth0.com/docs/customize/log-streams) to monitor your traffic in near real-time. After creating and configuring a Log Stream, you will start seeing Auth0 events being ingested into your chosen monitoring service. Based on your monitoring service, you can build your anomaly detection dashboard by anayzing the [Attack Protection Log Events](https://auth0.com/docs/secure/attack-protection/view-attack-protection-events).

### Multi-Factor Authentication (MFA)

[Multi-factor authentication (MFA)](https://auth0.com/multifactor-authentication) is a highly effective way to prevent credential stuffing because it requires users to log in with another form of authentication in addition to a username-password combination. For example, this could mean biometric authentication such as a fingerprint, a one-time code sent to a device associated with the user, or an email sent to a secured account — none of which a cybercriminal will have access to.

Although the adoption of MFA has been slow due to concerns about its impact on customer experience, the increase in sophistication and customizability of MFA are helping it catch on. For instance, in February 2020,[ Google announced](https://siliconangle.com/2020/02/12/google-require-nest-users-use-two-factor-authentication-enhanced-security/) it would require Nest smart home users to use two-factor authentication.

### Continuous authentication

Continuous authentication systems use factors like biometrics or behavioral patterns to verify a user’s identity in real-time (while they use an application) instead of a password. As a result, credential stuffing attacks (as well as a number of other cyberattacks) are no longer a viable method for cybercriminals to gain unauthorized access to a user’s account.

### Passwordless authentication

[Passwordless authentication](https://auth0.com/passwordless/) can prevent credential stuffing altogether because it verifies a user with something they have (a device or another account) or something they are (biometrics) instead of a password (something they know).[ Passwordless](https://auth0.com/passwordless/) also creates a better login experience for users and saves organizations time and money from dealing with password resets.

## Passwordless Authentication Is Better for Businesses and Users

Not only does passwordless authentication eliminate credential stuffing attacks, but numerous studies and reports show that it is a[ more secure](https://auth0.com/blog/is-passwordless-authentication-more-secure-than-passwords/),[ more user-friendly](https://www.lastpass.com/solutions/passwordless-access/from-passwords-to-passwordless), and[ more cost-effective](https://www.weforum.org/press/2020/01/forgotten-your-password-not-having-one-will-make-you-safer-says-world-economic-forum) solution overall than traditional username-password authentication for both businesses and their users.

“Relying on passwords as the primary means for authentication no longer provides the security or user experience that consumers demand,” Andrew Shikiar, Executive Director of the FIDO Alliance, [explains](https://www.weforum.org/press/2020/01/forgotten-your-password-not-having-one-will-make-you-safer-says-world-economic-forum) in a joint report with the World Economic Forum. Adrien Ogee, Project Lead from the World Economic Forum, adds, “Better authentication practices are not just possible; they are a necessity.”

Auth0’s platform makes it easy to implement secure, user-friendly passwordless authentication using biometrics, social logins, and more. Learn how to eliminate the risks associated with traditional username and password authentication with Auth0’s Passwordless authentication platform[ here](https://auth0.com/passwordless/).

"authentication"