Linda Gong

Linda Gong is a Product Marketing Manager for Orchestration at Okta, where she leads go-to-market strategy for Okta Workflows and Auth0 Extensibility. With a background in demand generations and marketing analytics, she brings a data-driven mindset to messaging, product launches, and driving adoption. When she’s not crafting product narratives, you’ll likely find her hunting down the best local coffee shops or planning her next travel adventure.

Product Marketing Manager

Auth0 + Sift integration delivers real-time, risk-based fraud detection and prevention while enabling frictionless logins for legitimate users.

Nearly [$13 billion](https://javelinstrategy.com/research/2024-identity-fraud-study-resolving-shattered-identity-crisis) — that’s how much account takeover (ATO) fraud cost businesses in 2023 alone. This isn’t just another alarming stat — it’s a wake-up call for any organization managing user accounts. Industries like e-commerce and financial services are feeling the heat, with ATO attack rates spiking [36%](https://sift.com/index-reports-account-takeover-fraud-q3-2024) and [10%](https://sift.com/index-reports-account-takeover-fraud-q3-2024) year-over-year, respectively.

The methods behind these attacks aren’t new: stolen credentials from data breaches, phishing attacks, and malware are still the go-to tools for fraudsters. What is new? The scale, sophistication, and speed of these attacks. And traditional defenses—CAPTCHA, static rules, even MFA—aren’t enough on their own.

### What you need: Real-time, AI-driven fraud defense

That’s where Auth0 + Sift comes in. Together, they deliver real-time, risk-based fraud detection and authentication at scale. With the pre-built integration, businesses can achieve robust ATO defenses quickly and with minimal engineering lift. 

With the Auth0 extensible identity platform and Sift’s AI-powered risk engine, you can automatically score risk, trigger adaptive MFA, and block bad actors—without slowing down your trusted users.

![Auth0 + Sift integration](https://images.ctfassets.net/23aumh6u8s0i/4E3Z7xaIl3d7lFbAY1qJWH/265b3594668967191449fad982a03f06/Screenshot_2025-04-28_at_6.03.34_PM.png)

### Check out the solution brief to learn how to stay ahead of account takeover attacks

Download [Auth0 + Sift integration solution brief](https://cdn.auth0.com/blog/blog/auth0sift-solution-brief.pdf) to discover:

* Why real-time, AI-powered risk assessment is essential to stop ATO fraud
* How the Auth0 + Sift integration works
* A real-world example from a global e-commerce platform
* Key outcomes: reduced fraud losses, enhanced user experiences, and increased operational efficiency



Account Takeover Attacks Are Surging — Stop Them With AI-Powered Fraud Defense

Aliyah Winfrey

I'm Aliyah Winfrey, a staff design researcher who’s passionate about creating clarity and alignment in complex research spaces. I thrive on asking the right questions and uncovering insights that drive meaningful design. Outside work, I tend to my garden, experiment with new baking recipes, or get lost in a classic PS2 game.

Staff Design Researcher

Exploring the evolving tech/identifier trends, needs, and behaviors of a global audience

As an advocate for developers and a company that trusts the developer community, we are open-sourcing this survey data to foster dialogue, innovation, and shared learning. By making these insights publicly available, we invite researchers, developers, and CIAM leaders to analyze and build upon our findings. Understanding global digital identity trends requires diverse perspectives, and an open-source approach allows for an informed and equitable discussion. 

Digital technologies continue to change human interactions, shaping global attitudes toward identity, security, and new technological innovations in similar and different ways. Our latest End-User Device & Login Sentiment survey highlights key trends in digital identity preferences, authentication methods, and security concerns. This survey and high-level takeaways contribute to the broader discourse of technology, CIAM, and an evolving general population market. Please find details on the purpose, audience, and collection below:

## Purpose

Understand the general population of global users' evolving technology needs and behaviors to identify key trends and shifts. The following Key topics were covered: 

**Device/OS usage**

* Personal vs. Work device usage 
* Device registration preference
* Work application usage

**Attitude towards technology**

* Overall tech familiarity 
* Hardware update motives
* Frequency of technology updates

**Identifier preference**

* Identifier familiarity 
* Identifier registration preference
* Perceived vulnerability and convenience 

**Password management**

* Reuse & Change Password
* Compromised PII
* Fraud Check

![Key Topics](https://images.ctfassets.net/23aumh6u8s0i/34N68QuL8Q9JZBT8ql8wXB/218ff72b8716be2887562adb892c3e28/key_topics.png)

### Research Questions

1. Understand current technology devices and usage patterns 
2. Identifying emerging trends in end-user preference 
3. Discover unmet needs and pain points to capitalize on new opportunities, driving innovation and strategic growth

### Target Audience

Partnered with Qualtrics for a 33-question survey in the following regions/countries: EMEA (France & United Kingdom), NAMR (United States & Canada), LATAM (Mexico & Brazil), and India. 

### Sample

**N=1049**

* Age
    * Age 18-23: 19%
    * Age 24-30 19%
    * Age 35-54: 32%
    * Age 55+: 30%
* Region
    * NAMR 25%
    * EMEA 25%
    * LATAM 25%
    * APAC 25%
* Gender
    * Male:48%
    * Female: 52%
* Community Type
    * 1/3 Rural
    * 1/3 Suburban
    * 1/3 Urban
* Household Income
    * Less than $25,000- 5%
    * $25,001 - $50,000- 10%
    * $50,001 - $75,000- 20%
    * $75,001 - $100,000- 30%
    * $100,001 - $150,000- 20%
    * $150,001 - $200,000- 10%
    * More than $200,000- 5%

### Data Integrity 

No personally identifying information (PII) was collected. All responses shorter than 3 minutes (180 seconds) were removed. The median completion time was 6.08 minutes. Participants were compensated for completing the survey. 

Samplings across regions are representative of age and gender distributions. For example, given the larger youth population, more youth aged 18 to 30 were sampled in India. Given the country's demographics, ages ranging from 45 to 59+ were skewed towards EMEA and NAMR. 

Additionally, LATAM skewed predominantly toward the urban community type, EMEA represented much of the rural community type, and NAMR led heavily toward the Suburban community type.

### Regression analysis

![Regression analysis](https://images.ctfassets.net/23aumh6u8s0i/2cF18Iz0eEWlprYHPlHlFR/f21d36a8cb21cabedd6100f1037f7aba/Regression_analysis.png)
_Logistic Regression on survey data was completed to gauge if any response options forecast an individual's Willingness to Try New Identifiers. No substantial evidence indicates these factors are significant predictors._

<br>
Six low-level predictors for Willingness to Try New Identifiers were identified. These include the following:

1. Attitude towards New Tech
2. Familiarity with Identifiers other than Email and Username
3. How often do individuals update their devices
4. Age
5. Apple-Only OS Owners
6. APAC/India region 

Data was collected in October of 2024. Data is accessible via a[ CSV. file](https://cdn.auth0.com/blog/blog/End-User-Sentiments-Survey.csv).

#### Citation

1 End-User Device and Login Sentiment, Auth0, 2024. [Link](https://auth0.com/blog/digital-identity-what-users-think-about-devices-and-logins/)

## Insights

### Top 10 Learnings 

1. Android Phone and Windows OS more widely adopted across diverse groups: <br>
 - Adoption more prevalent in LATAM and APAC
 - Android users tend to be lower to middle-household income 
![Android, Windows OS lead in adoption](https://images.ctfassets.net/23aumh6u8s0i/1cz14tdcdDmqEZI5ZBgD9M/15021e7a00fe7d4967d9255f16f99b7d/Screenshot_2025-03-21_at_12.39.11_PM.png)
2. Younger demographics and higher income are more likely to use Apple OS <br>
 - Apple OS more pronounced in EMEA and NAMR
3. Younger demographics and higher income are more likely to use Apple OS <br>
 - Positive attitude toward new technology, higher frequency of device updates, and more open to adopting new identifiers
4. EMEA and NAMR are more cautious about approaching new technologies <br>
 - Preference could be influenced by cultural differences and regulations
![General comfortability with adopting tech once mainstream](https://images.ctfassets.net/23aumh6u8s0i/6LXzCLV1QzEPUbZk2rh5c9/33bea12287c85db2359d9e8990a5bda4/Screenshot_2025-03-21_at_12.29.28_PM.png)
5. Top upgrade motivators are new features, device damage, battery issues, and limited memory. <br>
 - India/APAC unique concern for social brand preference and security concerns
![New features and de ice damage lead us upgrade motivators](https://images.ctfassets.net/23aumh6u8s0i/7CbnGFomOPj6PfmU4IfzeD/e92edbcce72f7994c1ca55ac4575dfa8/Screenshot_2025-03-21_at_12.30.33_PM.png)
6. Respondents who are more familiar with alternative identifiers (email and username) show higher readiness to adopt new ones. <br>
 - Apple OS users less likely to try new identifiers 
7. The most familiar and used identifiers include Email, username, phone/SMS, and biometrics. In contrast, the least used and familiar include Blockchain and hardware security keys. <br>
 - Social login is slightly more prevalent in LATAM and APAC
![APAC lead in familiarity and use for most methods](https://images.ctfassets.net/23aumh6u8s0i/71S0j1xEeG6isV67O1SwkP/4a7cdda42233bd8cc16c2a6a2f5829cf/Screenshot_2025-03-21_at_12.35.26_PM.png)
8. Username, email, and fingerprint are rated as the most convenient across all regions. <br>
 - EMEA and NAMR seem to be more sensitive to non-conventional identifiers such as government ID, security key, and voice ID, while even social login is ranked neutral. 
![Username, email, and fingerprint rated as most convenient](https://images.ctfassets.net/23aumh6u8s0i/7JSF843aMWSNsNSTxBBF0d/c1e9723a8b0efd52cc02748b81256bf6/Screenshot_2025-03-21_at_12.36.02_PM.png)
9. In contrast, Social Login is perceived as the most vulnerable to hackers and cyber-attacks. <br>
 - Our recent article, Demystifying Social Login, dives deeper into the security of leveraging Auth0 social connections for end-users. 
![Social Login seen as most vulnerable to cyberattacks](https://images.ctfassets.net/23aumh6u8s0i/7zuPvErvRjmZo3uflHsRdG/49f35a40cc73261e8d7ad06cffba6f8b/Screenshot_2024-12-17_at_10.27.55_AM.png)
10. Security and Privacy priority for motivations to try new identifiers <br>
 - NAMR and EMEA rank innovation as one of the lowest drivers
![Security and Privacy priority for motivations to try new identifiers](https://images.ctfassets.net/23aumh6u8s0i/3LpGrqWztktMy8Nw1H2lYJ/550ad822c4f8684ef18c2cea1f751d56/Screenshot_2025-03-21_at_12.34.25_PM.png)

> Download the [.CSV data here](https://cdn.auth0.com/blog/blog/End-User-Sentiments-Survey.csv).

Join the conversation! Share your thoughts, repost, and tag us to discuss the future of digital identity.

Digital Identity: What Users Think About Devices and Logins

jess-author

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

Sr. Developer Advocate

Jessica Temporal

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

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

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

Sam4-square

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

Principal Developer Advocate

Sam Bellen

Supercharge your Auth0-issued access tokens with information, like organizations a user belongs to, from your Auth0 FGA decision engine.

Auth0 supports Roles and Permissions and allows you to add users' permissions to your access tokens with a convenient toggle in the dashboard. But what if you’re using a more fine-grained solution to make access control decisions, like [Auth0 FGA](https://a0.to/auth0-fga-content) or its open-source counterpart, [OpenFGA](https://a0.to/fga-content)?

Actions are our way of offering developers flexibility. There are many different use cases for Auth0 Actions, and enriching an access or ID token is one of them. In this blog post, we’ll explore how we can add some relevant user data from our Auth0 FGA decision engine to the access tokens issued by our Auth0 tenant so that we can use that data in our application logic.

## Prerequisites

For this blog post, we assume you are familiar with either Auth0 FGA or OpenFGA and have an instance up and running. If you’d like to follow along, you can use the following model and tuples to set up a test store, or you could adapt the code for our Auth0 action later to reflect your use case.

> If you are unfamiliar with Auth0 FGA, OpenFGA, or how to get started, read [this blog](https://auth0.com/blog/fine-grained-access-control-with-okta-fga-nextjs/) post to learn more.

## The OpenFGA Authorization Model

Our [model](https://openfga.dev/docs/getting-started/configure-model) will contain a “user,” an “organization,” and a “document” type. An organization can have admins who are defined users and members who are either directly defined users or any user who’s already an admin for the organization. One or more organizations can own documents, and access rights are determined by the “doc_creator” and “doc_admin” relations from these organizations.

```
model
schema 1.1

type user

type organization
relations
    define admin: [user]
    define member: [user] or admin
    define doc_creator: [user] or member
    define doc_admin: [user] or admin

type document
relations
    define owner: [organization]
    define can_create: doc_creator from owner
    define can_delete: doc_admin from owner
```

### OpenFGA Test Tuples

These are [the tuples](https://openfga.dev/docs/getting-started/update-tuples) I’ve added to our Auth0 FGA Store. The ``auth0|62...7f`` is a user identifier within Auth0 and will be part of the Access Token as the `sub` claim. We’ll use these user IDs in our action code to look up all organizations belonging to the current user.

```js
[
    {
      "object":"organization:devrel",
      "relation":"admin",
      "user":"user:auth0|62...7f"
    },
    {
      "object":"organization:openfga",
      "relation":"member",
      "user":"user:auth0|62...7f"
    }  
]
```

## Let’s Write Our Auth0 Action

We can create our [Action](https://auth0.com/features/actions) from the Library page under the Actions menu item. Once we’ve navigated to this page, click the “Create Action” button in the top-right corner. This will allow us to install an action from the marketplace, start from an existing template, or write one from scratch. We’ll choose “Choose a template”, as there’s a template available that can serve as a solid basis from which to start.

![Let’s Write Our Auth0 Action](https://images.ctfassets.net/23aumh6u8s0i/6MUa1wOTUXVfJjelvLvUNT/d006cd1500a5dd4531ba4b6f0e9190a5/enrich-auth0-access-tokens-with-auth0-fga-data_01.png)

On the next page, select the “Enrich profile” use case and click on the “Add Email to Access Token” template. This template will add an email address to your access tokens, but we’ll adapt it to add organizations from Auth0 FGA instead.

![Template for Actions](https://images.ctfassets.net/23aumh6u8s0i/4NDnN6YTO3fMSBNBGUfYXh/ff765bc5ef61b437d2b8862cda074bc3/enrich-auth0-access-tokens-with-auth0-fga-data_02.png)

You can now preview the code from the template and click on the “Use This Template” button to install it. The following popup will ask you to give a name to the new action. We will leave the “post-login” trigger and node runtime as is and click “Create”.

![Add Email to Access Token](https://images.ctfassets.net/23aumh6u8s0i/3UhXvF3kmvyW5JuqLILbHn/4f2c28ffb2af2d164ba3bdc5ed2bf9a9/enrich-auth0-access-tokens-with-auth0-fga-data_03.png)

![Create Action](https://images.ctfassets.net/23aumh6u8s0i/6JWXbwZJVcgnltt0oI7JXM/c1a7905d5d73d68f6964bc7798493d17/enrich-auth0-access-tokens-with-auth0-fga-data_04.png)

### Namespace our custom claim

The [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#AdditionalClaims) recommends adding a namespace to [custom claim](https://auth0.com/docs/secure/tokens/json-web-tokens/create-custom-claims#namespaced-guidelines) names. The first few lines of code in our `onExecutePostLogin` function do just that. They check for a secret called `namespace` and ensure that it ends with a trailing slash.

We can add the namespace to the secrets by clicking on the Key icon in the left-side menu of the Action editor and clicking on the “Add Secret” button. Namespaces are usually a URI, so we will add `https://example.com` as a `NAMESPACE` secret. Feel free to change this to a more appropriate namespace.

### Install and configure the OpenFGA SDK

The Actions editor also conveniently allows us to install packages from NPM. We can add the OpenFGA SDK by clicking on the box icon on the left side and clicking on the “Add dependency” button. The package name will be `@openfga/sdk`, and the version can remain “latest”. This will install the [`@openfga/sdk`](https://www.npmjs.com/package/@openfga/sdk) package so we can import and use it in the Action codebase.

Add the following line to the top of the Action’s codebase:

```js
const { OpenFgaClient, CredentialsMethod } = require('@openfga/sdk');
```

Now that we’ve imported the OpenFGA client, let’s create a new instance and configure the credentials. 

```js
const fgaClient = new OpenFgaClient({
    apiUrl: event.secrets.FGA_API_URL,
    storeId: event.secrets.FGA_STORE_ID,
    authorizationModelId: event.secrets.FGA_MODEL_ID,  // Optional, by default it will use the latest model
    credentials: {
        method: CredentialsMethod.ClientCredentials,
        config: {
            apiTokenIssuer: event.secrets.FGA_API_TOKEN_ISSUER,
            apiAudience: event.secrets.FGA_API_AUDIENCE,
            clientId: event.secrets.FGA_CLIENT_ID,
            clientSecret: event.secrets.FGA_CLIENT_SECRET,
        }
    }
});
```

It is a good idea to create a new authorized client through the [Auth0 FGA dashboard’s](https://dashboard.fga.dev/) settings page for us to use in the Actions editor. Once you’ve created this new client, you can add its Client ID and secret to the Actions editor’s secrets, together with all other necessary configuration parameters. 

Here’s a quick overview of what they should look like. Be sure to change the `eu1` region in the API URL and Audience to `us1` or `au1` depending on which jurisdiction you choose when creating your store.

```
FGA_API_URL=https://api.eu1.fga.dev
FGA_API_AUDIENCE=https://api.eu1.fga.dev/
FGA_API_TOKEN_ISSUER=auth.fga.dev
FGA_CLIENT_ID=0U...4q
FGA_CLIENT_SECRET=pB...kf
FGA_STORE_ID=01...1M
FGA_MODEL_ID=01...9C
```

### List all assigned organizations from Auth0 FGA

Auth0 FGA exposes a `list-objects` endpoint that can return a set of objects of a particular type assigned to a user, such as all organizations for which a user is a member. This will also consider all indirect relationships, such as when a user is a member because they are an admin for a specific organization.

To use this endpoint, the OpenFGA client we just created exposes a `listObjects` method where we can pass a user, relation, and object type. Notice that we pass along the `user_id` from `event.user`. This is the actual ID of the user who is currently trying to log in.

Add the following snippet below the OpenFGA client initialization code in our Action.

```js
const {objects} = await fgaClient.listObjects({
    user: `user:${event.user.user_id}`,
    relation: "member",
    type: "organization",
})
```

### Add the Assigned Organizations to the Access Token

The last thing left to do is to add the returned organization to our access token. We can re-purpose the last existing line from the template by adding the email to add our organizations instead. With some minimal changes, that code will look something like this.

```js
api.accessToken.setCustomClaim(
  namespace + 'organizations', 
  objects.map(organization => organization?.replace('organization:', ''))
);
```

The `list-objects` endpoint returns the object type together with the actual objects, so in our case, we can strip `organization:` from each returned organization. This will keep the organization names, which we can add to the custom claim.

### Putting it All Together

If we add some error handling, we’ll end up with an action that should look like this. 

```js
const { OpenFgaClient, CredentialsMethod } = require("@openfga/sdk");

exports.onExecutePostLogin = async (event, api) => {
  let namespace = event.secrets.NAMESPACE || "";
  if (namespace && !namespace.endsWith("/")) {
    namespace += "/";
  }

  try {
    const fgaClient = new OpenFgaClient({
      apiUrl: event.secrets.FGA_API_URL,
      storeId: event.secrets.FGA_STORE_ID,
      authorizationModelId: event.secrets.FGA_MODEL_ID,
      credentials: {
        method: CredentialsMethod.ClientCredentials,
        config: {
          apiTokenIssuer: event.secrets.FGA_API_TOKEN_ISSUER,
          apiAudience: event.secrets.FGA_API_AUDIENCE,
          clientId: event.secrets.FGA_CLIENT_ID,
          clientSecret: event.secrets.FGA_CLIENT_SECRET,
        },
      },
    });

    const { objects } = await fgaClient.listObjects({
      user: `user:${event.user.user_id}`,
      relation: "member",
      type: "organization",
    });

    api.accessToken.setCustomClaim(
      namespace + "organizations",
      objects.map((organization) => organization?.replace("organization:", ""))
    );
  } catch (error) {
    api.access.deny("Could not list organizations");
  }
};
```

The issued access token will now have a custom `https://example.com/organizations` claim, and when decoded, it can look something like the following:

```js
{
  "iss": "https://<your-tenant>.eu.auth0.com/",
  "sub": "auth0|62...7f",
  "aud": [
    "https://example.com",
    "https://<your-tenant>.auth0.com/userinfo"
  ],
  "iat": 1740579493,
  "exp": 1740665893,
  "scope": "openid profile email address phone",
  "jti": "rDk6D9GigyYTfi2WN492AB",
  "client_id": "T1...aW",
  "https://example.com/organizations": [
    "devrel",
    "openfga"
  ],
}
```

## Wrapping Up

In this article, we’ve gone through the steps to create a new Auth0 Action. This action will run every time a user logs into our application and adds all organizations that the user is a member of to the Access Token. We can use this information in our backend systems by decoding the Access Token, which will be a JSON Web Token, and looking for our custom claim `https://example.com/organizations`.

The action does the following steps to accomplish this:

* Import the [OpenFGA Node.js SDK](https://github.com/openfga/js-sdk).
* Make sure we have a namespace configured and that it ends with a slash.
* Create a new instance of the imported OpenFGA client.
* Use this client to list all organizations assigned to the user by using the exposed `listObjects()` method.
* Return the list of organizations as a custom claim prepended by our namespace in our Access Tokens.


Enrich Auth0 Access Tokens with Auth0 FGA Data

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

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

If you’re curious about how to stay ahead of increasingly sophisticated attacks without putting your business goals at risk with excessive friction, this resource is for you.

Identity is the connective tissue between every person and technology in your ecosystem. This connective role also places Identity at the center of your risk profile. It’s no surprise that Identity remains the No. 1 attack vector in today’s threat landscape —  over 80% of data breaches involve some form of compromised Identity.

Properly addressing this fact means taking a serious and expansive look at your organization’s approach to Identity — because here’s the thing: Identity is more than just a login box. A rigorous, modern approach to Identity mitigates threats before, at, and after authentication.

Accordingly, technology leaders can’t limit themselves exclusively to Identity-related threats. They must also consider the impact their Identity solution has on core business priorities such as revenue, customer satisfaction, and growth goals.

This blog dives into how technology leaders can deliver Identity security solutions that also drive growth. If you’re curious about how to stay ahead of increasingly sophisticated attacks without putting your business goals at risk with excessive friction, this resource is for you.

## It’s Time to Ditch Dated Identity and Excessive Friction

Protecting customers from account takeover and other malicious actions is crucial. But when that protection creates frustrating stumbling blocks for customers, like passwords, frequent CAPTCHAs, and multi-factor authentication (MFA) fatigue, your business is at risk. By introducing excessive friction into customer journeys, good-faith security efforts built on legacy Identity methods can lead to abandoned customer journeys, lower conversion rates, and lost business.

It’s a raw deal, and the worst part is that Identity security that burdens your customers doesn’t necessarily translate to better security. For example, traditional usernames and passwords with SMS as a second factor are vulnerable to social engineering and SIM-swapping attacks.

The clock has run out on legacy Identity. It’s time to embrace a modern approach that leverages Identity as more than a login box and, instead, drives better security and better business.

## Protect Every Stage of the Customer Journey

If the stats on pervasive Identity-related breaches teach us anything, it’s that legacy Identity simply isn’t enough in today’s threat landscape. Technology leaders need Identity security that can discover weaknesses, protect against vulnerabilities, and limit access if an adversary gets in.

In order to modernize security, you must modernize Identity. Auth0’s layered defense strategy improves security before, at, and after the login box alongside a SecOps dashboard, tools, and integrations. Here’s how our Auth0 Identity platform drives stronger security, privacy, and user experience (UX) across the customer journey.

### Before login

Bots make up 42% of all internet traffic today and 65% of these are bad bots.A versatile, scalable method for bad actors to carry out automated attacks, bots are also a major drain on your marketing budget. Whenever bots sign up for new accounts, they eat into your sign-up bonuses and block new connections with real customers.

Generative AI is poised to add gas to the bot fire: Between 2023 and 2030, AI adoption in cybercrime is expected to rise by 37%. Soon, businesses will be dealing with an even higher number of sophisticated bots capable of outsmarting simple bot-detection CAPTCHAs.

Modern Identity should stop bad bots in their tracks while maintaining customer-friendly experiences that protect revenue. Auth0 Bot Detection continuously monitors Identity threats across hundreds of millions of users, enabling us to detect bad bots and respond in real time with user-friendly challenges like the time-based authentication challenge. In addition, our Bot Detection solution now features a machine-learning model designed for signup attacks. Tailored models greatly improve detection and prevention of bots across the user journey, while reducing bot challenges presented to real customers.

Auth0 SOLUTIONS TO EXPLORE FURTHER:

* [Bot Detection](https://auth0.com/docs/secure/attack-protection/bot-detection)

### At login

Ultimately, driving your business forward comes down to providing customers with a simple and seamless user experience without compromising on security. Customers want on-demand convenience — fast, easy access with flexible login options — which means digital teams need to design phishing-resistant authentication experiences that also deliver a quick and easy customer journey.

Modern Identity can provide that perfect balance with flexible, secure passwordless login options. Passkeys allow users to log in quickly and securely, similar to how they unlock their mobile devices. They are also a phishing-resistant alternative to less user-friendly login options like the commonly used username and password plus MFA combination. Adaptive MFA can also reduce MFA fatigue by assessing risk signals such as a new device, network, or location, impossible travel, and untrusted IP, only triggering a second challenge for higher-risk authentication attempts.

In addition to login options, Auth0 offers layered security features for login. Auth0 Breached Password Detection and Credential Guard screen for and block compromised credentials. Auth0’s Brute-Force Protection and Suspicious IP Throttling help prevent account takeover attacks that target single and multiple user accounts, respectively.

Auth0 SOLUTIONS TO EXPLORE FURTHER:

* [Single Sign-On](https://auth0.com/docs/authenticate/single-sign-on) 
* [Passwordless](https://auth0.com/docs/authenticate/passwordless),[ Passkeys](https://auth0.com/docs/authenticate/database-connections/passkeys) 
* [Multi-Factor Authentication](https://auth0.com/docs/secure/multi-factor-authentication)
* [Adaptive MFA](https://auth0.com/docs/secure/multi-factor-authentication/adaptive-mfa)
* [Suspicious IP Throttling](https://auth0.com/docs/secure/attack-protection/suspicious-ip-throttling)
* [Breached Password Detection and Credential Guard](https://auth0.com/docs/secure/attack-protection/breached-password-detection)
* [Brute Force Protection](https://auth0.com/docs/secure/attack-protection/brute-force-protection)

### After login

The ongoing rise in post-login threats also necessitates a defense-in-depth, layered security approach at every step of the user journey. The stakes are high, and the pain caused by breaches has the potential for extensive reach. Breaches not only incur painful financial losses but also lead to substantial brand and compliance-related effects that threaten the core business. Modern Identity can help avoid these outcomes.

Modern Identity elevates security, privacy, and experience post-login to protect sensitive customer interactions and user sessions. For example, with Auth0 Highly Regulated Identity, configure your organization to send financial-grade contextual approval requests to customers’ devices for sensitive interactions like account updates or money transfers. With Auth0 Continuous Session Protection, your organization can also continuously monitor user sessions to detect and prevent hijacking attempts, revoke suspicious sessions, and set custom timeouts.

Auth0 SOLUTIONS TO EXPLORE FURTHER:

* [Highly Regulated Identity](https://auth0.com/docs/secure/highly-regulated-identity)
* [Continuous Session Protection](https://auth0.com/docs/secure/continuous-session-protection)

## SecOps

Security is a team sport, which is why Auth0 enables better collaboration between security, product teams, and developers with real-time insights and ready-made integrations that connect Auth0 functionality to a broader security apparatus.

For example, Auth0’s Security Center helps organizations detect and respond to attacks faster and fine-tune their security posture with intelligent insights and custom threshold alerting for Identity-related events, anomalies, and general efficacy. Security Log Streaming further supports faster event response by allowing the streaming of relevant Customer Identity Cloud activity to third-party SIEM tooling.

Auth0 SOLUTIONS TO EXPLORE FURTHER

* [Security Center](https://auth0.com/docs/secure/security-center)
* [Security Log Streaming](https://auth0.com/docs/secure/security-center/prioritized-log-streams)

## The Perfect Blend of Security and Usability

It’s tempting to think of Identity as a box to be checked. Equip your customer-facing applications with SSO and MFA–check. It's time to dust off your hands and declare victory, right? If only it was that easy.

To adapt to the ever-shifting risks of the business landscape with equal attention to security and revenue, technology leaders need an approach to Identity-based security that also functions as a business driver. That means integrating secure, seamless Identity functions into your security and revenue strategies at each customer touchpoint.

Legacy approaches to Identity fall far short of this goal. But, by entrusting your organization’s Identity with a leader in modern Identity, you can position your business to lead the pack in customer Identity security and core business KPIs.

## It All Starts with Auth0

[Thousands of customers](https://www.okta.com/customers/) worldwide trust Auth0 to strike the perfect balance of robust security and seamless customer experience across more than 10 billion monthly authentications.

We’ve invested in a layered defense strategy to improve security before, during, and after the login box — plus a dashboard and tools for SecOps that improve visibility and enable faster responses to potential and emerging threats.

Curious about how the Auth0 can help you build trust with your customers, secure your applications, and protect revenue?[ Reach out to our team](https://auth0.com/contact-us?place=header&type=button&text=contact%20sales) to schedule a demo.


Identity Security 101: How to Drive Trust and Loyalty across the User Journey

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

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 allows you to integrate passkeys into your native applications and offers a smooth user experience with all the benefits of passkeys.

Native login with passkeys allows you to seamlessly integrate [passkeys](https://learnpasskeys.io/introduction) into your mobile applications. If you wanted to add passkeys before, you had to integrate a web redirect flow that uses Universal Login. 

Today, we are announcing Limited Early Access to Native Login with passkeys for Android applications. 

## How Does It Work? 

In order to use Native Login with passkeys in your Android application, there are a few requirements:

* **Enable and configure your passkey policy**: First of all, you need to enable passkeys for your tenant. Learn how to do it using [our documentation](https://auth0.com/docs/authenticate/database-connections/passkeys/configure-passkey-policy).
* **Configure a Custom Domain**: you can learn how to configure a custom domain using [our documentation](https://auth0.com/docs/customize/custom-domains).
* **Enable Android App Links Support**, which you can do following [our docs](https://auth0.com/docs/get-started/applications/enable-android-app-links-support).

Native login is available on the Android SDK from version 3.2.0 and Android API 28. 

### Sign Up 

To sign up, you’ll need to use the "`signupWithPasskey`" method from the "`AuthenticationAPIClient`". When successful, you can handle the passkey creation from your device using Android’s CredentialManager following [Android’s official docs](https://developer.android.com/identity/sign-in/credential-manager#create-passkey). Here’s an example implementation in Kotlin:

```java
val account = Auth0.getInstance("{YOUR_CLIENT_ID}", "{YOUR_DOMAIN}")

val client = AuthenticationAPIClient(account) 

client.signupWithPasskey(
            UserData(
                email = "jndoe@email.com"
            ), "{realm}"  
        ).start(object : Callback<PasskeyRegistrationChallenge, AuthenticationException> {
            override fun onSuccess(result: PasskeyRegistrationChallenge) {
                val passKeyRegistrationChallenge = result
                val request = CreatePublicKeyCredentialRequest(
                    Gson().toJson(
                        passKeyRegistrationChallenge.authParamsPublicKey
                    )
                )
                var response: CreatePublicKeyCredentialResponse?

        // start credential creation on the device 
                credentialManager.createCredentialAsync(requireContext(),
                    request,
                    CancellationSignal(),
                    Executors.newSingleThreadExecutor(),
                    object :
                        CredentialManagerCallback<CreateCredentialResponse, CreateCredentialException> {

                        override fun onError(e: CreateCredentialException) {
                        }

                        override fun onResult(result: CreateCredentialResponse) {

                            response = result as CreatePublicKeyCredentialResponse
                            val authRequest = Gson().fromJson(
                                response?.registrationResponseJson,
                                PublicKeyCredentials::class.java
                            )

       // once the device created the key pair and signed the challenge you can sign in to Auth0 
                            client.signinWithPasskey(
                                passKeyRegistrationChallenge.authSession,
                                authRequest,
                                "{realm}"
                            )
                                .validateClaims()
                                .start(object : Callback<Credentials, AuthenticationException> {
                                    override fun onSuccess(result: Credentials) {
                                        credentialsManager.saveCredentials(result)
                                        Snackbar.make(
                                            requireView(),
                                            "Hello ${result.user.name}",
                                            Snackbar.LENGTH_LONG
                                        ).show()
                                    }

                                    override fun onFailure(error: AuthenticationException) {
                                        Snackbar.make(
                                            requireView(),
                                            error.getDescription(),
                                            Snackbar.LENGTH_LONG
                                        ).show()
                                    }
                                })
                        }
                    })
            }

            override fun onFailure(error: AuthenticationException) {
                Snackbar.make(
                    requireView(),
                    error.getDescription(),
                    Snackbar.LENGTH_LONG
                ).show()
            }
        })
```

The `signupWithPasskey` method starts the passkey creation ceremony. It generates the challenge for the authenticator to sign once it has created the public key credential pair. In your case, your Android device acts as the authenticator and you create the key pair and sign the challenge when you use the `CreatePublicKeyCredentialRequest` method from Android’s Credential Manager. 

Then, you can use Android’s Credential Manager method `createCredential` or `createCredentialAsync` to start the creation. Once successful, you can use the result from the creation to send that data to Auth0 and sign in using the ``signinWithPasskey`` method, which is covered below.

### Login 

To sign in, you’ll have to first initiate the passkey challenge by using the `passkeyChallenge` method from the `AuthenticationAPIClient`. When the call is successful, you can initiate the credential retrieval using Android’s [`getCredential` method from the `CredentialManager`](https://developer.android.com/identity/sign-in/credential-manager#sign-in).

When your device retrieves the credential successfully, you can then initiate the sign-in process with Auth0. An example implementation could be:

```java
val account = Auth0.getInstance("{YOUR_CLIENT_ID}", "{YOUR_DOMAIN}")
val client = AuthenticationAPIClient(account)

client.passkeyChallenge(realm)
            .start(object : Callback<PasskeyChallenge, AuthenticationException> {
                override fun onSuccess(result: PasskeyChallenge) {
                    val passkeyChallengeResponse = result
                    val request =
                        GetPublicKeyCredentialOption(Gson().toJson(passkeyChallengeResponse.authParamsPublicKey))
                    val getCredRequest = GetCredentialRequest(
                        listOf(request)
                    )
                    credentialManager.getCredentialAsync(context,
                        getCredRequest,
                        CancellationSignal(),
                        executor,
                        object :
                            CredentialManagerCallback<GetCredentialResponse, GetCredentialException> {
                            override fun onError(e: GetCredentialException) {
                                Log.w(TAG, "Error fetching public key credential")
                                callback.onFailure(handleGetCredentialFailure(e))
                            }

                            override fun onResult(result: GetCredentialResponse) {
                                when (val credential = result.credential) {
                                    is PublicKeyCredential -> {
                                        val authRequest = Gson().fromJson(
                                            credential.authenticationResponseJson,
                                            PublicKeyCredentials::class.java
                                        )
                // initiate signin process with Auth0
                                        client.signinWithPasskey(
                                            passkeyChallengeResponse.authSession,
                                            authRequest,
                                            realm
                                        )
                                            .validateClaims()
                                            .addParameters(parameters)
                                            .start(callback)
                                    }

                                    else -> {
                                        Log.w(
                                            TAG,
                                            "Received unrecognized credential type ${credential.type}."
                                        )
                                        callback.onFailure(AuthenticationException("Received unrecognized credential type ${credential.type}"))
                                    }
                                }
                            }
                        })

                }
```

For more detailed examples, you can check out the [Android SDK sample folder on Github](https://github.com/auth0/Auth0.Android/tree/main/sample).

If you need [Java examples, you can check out this doc](https://github.com/auth0/Auth0.Android/blob/main/EXAMPLES.md#passkeys).

## What Use Cases Are Supported?

The initial early access release provides support for the following use cases:

* **Sign Up with a passkey**: users can register a new passkey for Auth0/your app and store it in the device credential manager for future use. 
* **Login with a passkey**: users can retrieve passkeys using the device’s credential manager and use them to log in. 

## How Can You Apply?

If you are interested in joining the early access program, please reach out to your account manager.

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

Native Login with Passkeys Is Now in Limited Early Access for Android Applications!

paulo-nascimento

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

Machine Learning Engineer

Paulo Nascimento

Waleed Manzoul

Staff Product Designer

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

## Introduction

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

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

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

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

## User Lifecycle Management Using SCIM

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

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

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

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

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

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

## How Does SCIM Provisioning Work?

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

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

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

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

SCIM supports a number of key operations, such as:

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

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

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

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

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

## SCIM vs SAML

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

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

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

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

## SCIM vs. SSO

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

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

## Inbound SCIM with Auth0

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

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

## Conclusion

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


Streamline Account Provisioning and Management with SCIM

sam-yapkowitz

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

Specialist Solutions Engineer

Sam Yapkowitz

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

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

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

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

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

## Use Case

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

## Prompting a User with a Form

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

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

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

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

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


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

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

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

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

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

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

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

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

```

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

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

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

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

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

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

```

## Conclusion

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

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

External User Verification with Forms

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.

Andrea Chiarelli

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

peterfernandez_360

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

Peter Fernandez

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

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

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

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

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

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


## Examine the ID Token

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

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

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

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

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

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

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

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

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

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

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

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

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

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


### What’s in the ID token?

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

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

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

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

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

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


## Get the User’s Information

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

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

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

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

import JWTDecode

// [ More code here ]
```

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

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

// [ More code here ]

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

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

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


## Display the User’s Information

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

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

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

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

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

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

// [ More code here ]

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

// [ More code here ]
```

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

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

🛠 Update `logout()` as shown below:

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

// [ More code here ]

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

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

// [ More code here ]
```


## Run the App Again

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

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

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

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


## Next Steps

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

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

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

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

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

Join the Okta event for developers who care about the security of their applications and the identity of their users.

Mark your calendars for **September 24th** for Okta's event designed by developers for developers: **Developer Day 2024**!

Like every year, you'll learn how Auth0 helps you secure your applications and users' identities. But this year, it will be different. You will be hearing many exciting news at the event and discover how much Okta cares about working with you to build a more secure world.

But it's not just about announcements. You will have the opportunity to put the new features into practice through **curated sessions and hands-on labs**.

Developer Day 2024 will be a **free virtual event open to anyone from anywhere in the world**. DevDay will kickoff at **9:00 AM BST** (10:00 AM CEST) with a captivating Keynote followed by 35+ developer sessions and labs that dive into how devs can use the latest features from Auth0.

If you are a developer who cares about the security of your application and your users, you cannot miss this opportunity to learn directly from the experts in the field.

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

Curious about the event's agenda? It will be revealed around mid-August, so stay tuned and keep an eye on the [Developer Day website](https://developerday.com/) to be the first to know the cool topics in store for you.

What are you waiting for? **[Register now](https://developerday.com/register)** to ensure your access to this outstanding event!


Developer Day 2024 Is Here!

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

Staff Developer Advocate

Juan Cruz Martinez

Learn how to seamlessly integrate Auth0 into your newsletter sign-up process, ensuring compliance with GDPR regulations. This simple guide walks you through different methods to collect user consent for newsletter signups.

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

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

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

## Method 1: Customize Signup and Login Prompts

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

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

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

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

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

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

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

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

Which will inject the following HTML after the login form.

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

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

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

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

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

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

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

### Key considerations for this approach:

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

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

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

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

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

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

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

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

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

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

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

### Key considerations for this approach:

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

## Best Practices for Obtaining Explicit Consent

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

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

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

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

## Conclusion

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

Thanks for reading!

Using Auth0 to Collect Consent for Newsletter Signups

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

Let’s take an overview of the new Session Management API, which allows you to manage your user sessions.

User session management allows developers to implement features ranging from controlling session concurrency to monitoring and terminating sessions. In this article, we will discuss the Session Management API, which allows you to manage user sessions in applications that integrate with Auth0.

## The Need for Managing User Sessions

When a user logs in to your application using Auth0, at least two sessions are initiated:

- The *Local Session* (*Application Session*). This session exists on your application's side. It typically uses cookies or similar mechanisms to store information like the user's login status, preferences, or any other data relevant to your application's functionality. Its primary role is to indicate to your application whether the user is currently logged in and authorized to access specific resources or features.
- The *Authorization Server Session* (*Auth0 Session*). This session is managed by Auth0's servers. It's typically stored in a cookie within the *auth0.com* domain or a custom domain associated with your Auth0 tenant. It's primarily used by Auth0 to facilitate features like Single Sign-On (SSO) and to determine if a user needs to re-authenticate when accessing other applications within the same Auth0 tenant.

> In case the user authenticates using a third-party Identity provider, such as Google, Facebook, GitHub, or others, you have a third session, the *3d party IdP session*, which tracks the interactions between the user and that Identity provider. See [this document](https://auth0.com/docs/manage-users/sessions/session-layers) for more info.

Your application's sessions are entirely in your hands, although Auth0 SDKs can help you with session creation. Auth0's session management is under Auth0's control. However, thanks to the new [Session Management API](https://auth0.com/docs/manage-users/sessions/manage-user-sessions-with-auth0-management-api), you can now manage Auth0 sessions from your application as well. The ability to manage authenticated user sessions in Auth0 can meet a few needs, such as:

- You can allow users to list their active sessions and close them by remotely logging out.
- You can allow an administrator to list all the user sessions and possibly force any of them to log out for security reasons.
- You can limit the number of concurrent user sessions.

Let's explore how you can use this new API.

## Set Up Access to the Session Management API

To use the Session Management API, you need the [Enterprise plan](https://auth0.com/pricing). If you don't have this plan but want to test the API, you can create a new tenant and get a free trial period.

You can use the Session Management API as you do with all the [Management API](https://auth0.com/docs/api/management/v2): basically, you need to enable your client application, [get an access token](https://auth0.com/docs/secure/tokens/access-tokens/management-api-access-tokens), and call the API endpoints.

### Enable your client

As a first step, you need to enable your client application to use the required scopes to use the Session Management API. In particular:

- The scope `read:sessions` enables your client to list sessions and get details about them.
- The scope `delete:sessions` allows your client to close a session, i.e., logging a user out.

To enable a client to these scopes, go to your [Auth0 dashboard](https://manage.auth0.com/) and select the application you want to enable. Make sure this is a [Machine to Machine application](https://auth0.com/docs/get-started/auth0-overview/create-applications/machine-to-machine-apps). Select the APIs tab on the application page and then toggle the *Authorized* switch button corresponding to the Auth0 Management API, as shown in the following picture:

![Auth0 Management API authorization](https://images.ctfassets.net/23aumh6u8s0i/2Lo0IwblYRUHaYSZumG0KV/5ba4a67cf84835252167fac11102c2c4/auth0-management-api-authorization.png)

Then, expand the Auth0 Management API section and filter the permissions list using the `session` keyword. You should get the `read:sessions` and `delete:sessions` items. Check them as shown in the following picture:

![Auth0 Management API session scopes](https://images.ctfassets.net/23aumh6u8s0i/6hTwgUYPtXviFLa5BlZtph/7167f08b695580ac2aac827a9e0a809f/auth0-management-api-session-scopes.png)

Don't forget to click the *Update* button to save your changes.

### Get an access token

Now, your application must request an access token to call the Management API. Depending on your specific scenario, you can get an access token in different ways. For example, in a test scenario you can [get it manually](https://auth0.com/docs/secure/tokens/access-tokens/management-api-access-tokens/get-management-api-access-tokens-for-testing#get-access-tokens-manually) from the Auth0 dashboard or you can use cURL, while in a production scenario, your application must request an access code programmatically.

For demonstration purposes, let's see how you can request an access token via cURL:

```bash
curl --request POST \
  --url https://YOUR_AUTH0_DOMAIN/oauth/token \
  --header 'content-type: application/json' \
  --data '{"client_id":"YOUR_CLIENT_ID","client_secret":"YOUR_CLIENT_SECRET","audience":"https://YOUR_AUTH0_DOMAIN/api/v2/","grant_type":"client_credentials"}'
```

Replace the placeholders `YOUR_AUTH0_DOMAIN`, `YOUR_CLIENT_ID`, and `YOUR_CLIENT_SECRET` with the respective values from your client configuration.

This request generates a response as the following:

```bash
{ "access_token":"eyJhbGci...",
  "scope":"read:sessions delete:sessions",
  "expires_in":86400,
  "token_type":"Bearer"
}
```

You will use the value of the `access_token` property to demonstrate that you are authorized to call the Management API.

### Call the API

Now that you have the access token, you can call the API endpoints by passing it in the `Authorization` header, as shown in the following cURL request:

```bash
curl --request GET \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/AUTH0_API_ENDPOINT' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
  --header 'content-type: application/json'
```

Replace the placeholders `YOUR_AUTH0_DOMAIN`, `YOUR_ACCESS_TOKEN`, and `AUTH0_API_ENDPOINT` with the respective values.

## Managing the User Sessions

Once we have enabled the client and obtained the access token, let's see how to actually use the Session Management API.

Let's start by listing the active sessions of a specific user. You can use the `/api/v2/users/{userId}/sessions` endpoint as shown in the following example:

```bash
curl --request GET \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/users/auth0%7C8374f7459j7493u84335/sessions' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

In this example, you send a GET request to the endpoint by specifying your Auth0 domain, the user ID, and the access token. As a response, you will get a JSON object like the following:

```bash
{
  "sessions": [{
    "id": "2Lw8dT76wJpOl924",
    "user_id": "auth0|8374f7459j7493u84335",
    "created_at": "2024-05-10T12:04:22.3452",
    "updated_at": "2024-05-10T12:04:22.3452",
    "authenticated_at": "2024-05-21T11:29:12.4251",
    "authentication": { "methods":[
      {
        "name": "pwd",
        "timestamp": "2024-05-21T11:29:12.4251"
      }
    ]},
    "idle_expires_at": "2024-05-21T12:29:12.4251",
    "expires_at": "2024-05-21T18:29:12.4251",
    "device": {
      "initial_ip": "142.250.184.206",
      "last_ip": "142.250.184.206",
      "user_agent": "Mozilla/5.0...",
      "initial_asn": "8612",
      "last_asn": "8612"
    },
    "clients":[ {"client_id": "Hwo482a51heU632d34"} ]
    }
  ]
}
```

This is an object with the `sessions` array that lists the user's active sessions. Each session is represented by an object with some properties: the session ID (`id`), the user ID (`user_id`), the time stamp of their authentication (`authenticated_at`), the authentication method (`authentication`), the device on which the session is active (`device`), the application client used by the user (`clients`), etc.

In the example above, only one session is returned for that user.

If you have a session ID, you can access the data about that session by using the `/api/v2/sessions/{id}` endpoint. You can get a session ID from the `sid` claim of the ID or [Logout token](https://auth0.com/docs/authenticate/login/logout/back-channel-logout#tokens-in-oidc-back-channel-logout-communications). The following example shows how to get the session details given its ID:

```bash
curl --request GET \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/sessions/2Lw8dT76wJpOl924' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

You will receive a JSON object representing that single session, as shown in the following:

```bash
{
  "id": "2Lw8dT76wJpOl924",
  "user_id": "auth0|8374f7459j7493u84335",
  "created_at": "2024-05-10T12:04:22.3452",
  "updated_at": "2024-05-10T12:04:22.3452",
  "authenticated_at": "2024-05-21T11:29:12.4251",
  "authentication": { "methods":[
    {
      "name": "pwd",
      "timestamp": "2024-05-21T11:29:12.4251"
    }
  ]},
  "idle_expires_at": "2024-05-21T12:29:12.4251",
  "expires_at": "2024-05-21T18:29:12.4251",
  "device": {
    "initial_ip": "142.250.184.206",
    "last_ip": "142.250.184.206",
    "user_agent": "Mozilla/5.0...",
    "initial_asn": "8612",
    "last_asn": "8612"
  },
  "clients":[ {"client_id": "Hwo482a51heU632d34"} ]
}
```

## Forcing Session Termination

In addition to getting information about the user sessions, you can also terminate them if your application has the `delete:sessions` scope enabled. You can call both endpoints `/api/v2/users/{userId}/sessions` and  `/api/v2/sessions/{id}` using the `DELETE` method. For example, the following cURL command terminates a specific user session:

```bash
curl --request DELETE \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/sessions/2Lw8dT76wJpOl924' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

The following command deletes all the sessions of a specific user:

```bash
curl --request DELETE \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/users/auth0%7C8374f7459j7493u84335/sessions' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

Session termination does not automatically log a user out of the application. As mentioned earlier, multiple sessions are involved in an application, and logout must be handled properly. Read [this article to get an idea of logout complexity](https://auth0.com/blog/the-not-so-easy-art-of-logging-out/).

In particular, session termination events are connected to the [OpenID Connect Back-Channel Logout](https://auth0.com/docs/authenticate/login/logout/back-channel-logout) mechanism. Therefore, to trigger application logout through the Session Management API, your application must be configured to use the `session-revoked` initiator. Read [this document](https://auth0.com/docs/authenticate/login/logout/back-channel-logout/oidc-back-channel-logout-initiators#configure-oidc-back-channel-logout-initiators) to learn how to configure your application to use the `session-revoked` initiator.

## Sessions and Refresh Tokens

Session termination forces the user logout. However, if an application requests a refresh token at login time, this refresh token is still available to the application even after the user session terminates.

This may be an intended or unintended situation, depending on the application's specific requirements. For example, consider an application that needs to call an API on a scheduled basis. It needs a refresh token to ensure an access token even if the user does not have an active session. On the other hand, your application can use a refresh token only to renew an access token with a limited lifetime, but you do not want the refresh token to survive the user session.

In the first case, terminating a user session will work as shown so far. You don't need to take an extra step to revoke the refresh token.

In the second case, the session termination is not enough. You also need a way to invalidate the current refresh token. For this purpose, you can use a few endpoints to help you manage refresh tokens.

> To enable your client application to manage refresh tokens, you have to add the `read:refresh_tokens` and `delete:refresh_tokens` scopes to the Management API configuration in the Auth0 dashboard.

The following command shows how to list all the refresh tokens associated with a given user:

```bash
curl --request GET \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/users/auth0%7C8374f7459j7493u84335/refresh-tokens' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

You get a JSON object containing the list of the refresh tokens with all the details, as in the following example:

```bash
{
  "refresh_tokens": [{
    "id": "6srfsU4dh510",
    "user_id": "auth0|8374f7459j7493u84335",
    "client_id": "Hwo482a51heU632d34",
    "created_at": "2024-05-10T12:04:22.3452",
    "updated_at": "2024-05-10T12:04:22.3452",
    "idle_expires_at": "2024-05-21T12:29:12.4251",
    "expires_at": "2024-06-21T18:29:12.4251",
    "session_id": "2Lw8dT76wJpOl924",
    "rotating": true,
    "resource_servers": [{ audience: "http://myapi.com", scopes:"read:users"}] 
  }]
}
```

To delete this specific refresh token, you can call the `/api/v2/refresh-tokens/{tokenId}` endpoint as in the following example:

```bash
curl --request DELETE \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/refresh-tokens/6srfsU4dh510' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

Notice how you specify the ID of the refresh token to delete.

If you want to delete all the refresh tokens associated to a user, you can use the following command:

```bash
curl --request DELETE \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/users/auth0%7C8374f7459j7493u84335/refresh-tokens' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'
```

> Consider that refresh token revocation through the `DELETE` command on the endpoints shown above runs asynchronously. This means that refresh tokens are not immediately revoked when the command finishes running.

## Summary

This article has given you an overview of Auth0's Session Management API with some examples of endpoint invocation via cURL. We started with activating the client application and getting the access token, then moved on to getting a user's session list and terminating a specific session.

You then learned about the relationship between sessions and refresh tokens and how to revoke refresh tokens associated with a user.

Now that you have a basic understanding of how to use the Session Management API, you can build a better security experience for your users.


Introducing the Auth0 Session Management API

Learn how to create customizable and secure login pages that match your branding to enhance user experience and conversion rates.

So, you've built an outstanding application. Your landing page is meticulously designed, compelling, and has a high conversion rate. You've carefully crafted every detail of the user experience, but what about the entry points to your app – the signup and login pages?

Often overlooked in the design process, these critical touchpoints serve as the users’ gateways into your application. They should be as compelling, user-friendly, and beautiful as the rest of your application. Just as the landing page captures the user's attention, the login and signup pages are where you can truly start to engage users, encouraging them to join your application.

In this article, we'll explore how Auth0 makes it easy to build login and signup experiences that not only align seamlessly with your branding but also provide a superior user experience. A poorly designed login page can lead to user frustration and higher abandonment rates, whereas a well-designed one establishes trust and encourages engagement. Because every aspect of your application, even the seemingly mundane, should be nothing short of beautiful.

Let's dive into how Auth0 can elevate your login experience, covering the importance of UI and UX, and offering practical tips to create extraordinary login flows.

## The Importance of the Login Page Design

The login page is often the first impression a user has of your application. It sets the tone for the entire user experience and can make or break a user's decision to continue using your app.

The design of a login page encompasses both UI and UX. It should not only be pretty but also easy to use while conveying a sense of security and trustworthiness to the user.

If you need inspiration or to learn some tips on what makes good login pages extraordinary, check out these [ten tips](https://www.invisionapp.com/inside-design/login-page-design/).

## Getting Started

Auth0 offers a variety of [customization options to match your application's branding and design](https://auth0.com/blog/customize-auth0-universal-login-with-auth0-cli/). With Auth0, you can rest assured that your login and signup pages will be not only beautiful and match your brand but also secure and reliable.

In many scenarios, those out-of-the-box settings are all you need to make your login and signup pages match your brand and style. But in case you want a completely customized page, Auth0 offers the possibility to create your own styles and designs using [HTML, CSS, and JavaScript templates](https://auth0.com/docs/customize/universal-login-pages/universal-login-page-templates). 

> Custom templates require enabling [custom domains](https://auth0.com/docs/customize/custom-domains), which is a paid feature.

In this article, we’ll focus on creating our own template to have full control over the login experience. However, if you would like to know how to set up your branding settings instead, you can refer to this article on [Customize Auth0 Universal Login with Auth0 CLI](https://auth0.com/blog/customize-auth0-universal-login-with-auth0-cli/).

You can work with templates either through the [Auth0 Dashboard](https://manage.auth0.com/#/login_page) with an integrated code editor and preview mode, or you can use the [Auth0 CLI](https://github.com/auth0/auth0-cli) with your editor of choice and [Storybook](https://storybook.js.org/) to preview your designs.

Throughout the article, we'll use the Auth0 CLI to customize the templates as it provides a rich developer experience.

## Setting up the Auth0 CLI

The Auth0 CLI is a powerful tool that allows you to manage your entire Auth0 tenant from the command line. The Auth0 CLI helps you simplify your workflows and set up automation on your Auth0 account.

### Install the Auth0 CLI

The Auth0 CLI is available for macOS, Linux, and Windows. To install it on your preferred OS, please follow [these installation instructions](https://github.com/auth0/auth0-cli#installation).

After your installation completes, you can verify the installation by running the following command:

```bash
auth0 -v
```

### Connect the CLI to your Auth0 Account

To connect the CLI to your Auth0 account, you'll need to log in. Run the following command in your terminal and follow the instructions to authenticate:

```bash
auth0 login
```

First, the CLI will prompt for one of two authentication methods, `As a user` or `As a machine`. For now, we’ll select `As a user` since it is the recommended option for a personal computer. However, for automation scenarios, it is recommended to select the latter.

Next, we need to authenticate in the browser using [device authorization flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow). The Auth0 CLI will show a code on the screen and will open a browser session, where the code should match, and after verification, you’ll have to authorize the CLI on all the requested scopes.

## Activate a Custom Domain

As mentioned before, a requirement for editing custom templates is to activate custom domains, which is a good practice for production. Since custom domains come in different configurations and multiple steps, I won’t be covering them in this article. Instead, I can refer you to the [custom domains documentation](https://auth0.com/docs/customize/custom-domains), where you can find all the information you’ll need with step-by-step instructions.

Once you have a custom domain set up on your account, you can continue with the rest of the article.

## Customizing the Universal Login UI

To start customizing the Universal Login UI, run the following command on your terminal:

```bash
auth0 universal-login customize
```

This will open the Auth0 customization editor on your browser which will allow you to change any visual settings in Universal Login, from colors, logo, texts, and you can design your own templates with live preview in this app.

![Auth0 Universal Login Editor Preview](https://images.ctfassets.net/23aumh6u8s0i/5YNs9FYoGfPXrMon6OMpkY/88008ca9b492268c60724883011271f0/Screenshot_2024-04-18_at_09.41.25.png)

Any changes that you make locally can then be deployed to your Auth0 tenant from the same UI.

### Exploring the UI

The UI customization tool is divided into three sections:

- **Navigation bar**: It allows you to work on different areas of customization, from settings, theme, page template and custom texts. It also allows you to navigate through the different prompts like login, signup, etc.
- **Editor**: On the left side, it's the editor. It will display information about the current state of your page in either JSON for settings or HTML code for the page template editor.
- **Preview window**: The preview window gives you a live preview of your changes and how your UL page will look like when deployed to your tenant.

## Building a Beautiful Template

If you jump into the **Page Template** section, the editor will load the current template available for your tenant. If you have never customized your template, it will display the default template which looks like this:

```html
<!DOCTYPE html>
<html>
  <head>
    {%- auth0:head -%}
  </head>
  <body>
    {%- auth0:widget -%}
  </body>
</html>
```

There's some custom code in that template, let's explore what each of those sections do:

- `{%- auth0:head -%}`: This will set all the head elements that are required for universal login to work, like importing scripts, basic styles, etc.
- `{%- auth0:widget -%}`: This will place the login widget on the screen.

Templates use [Liquid syntax](https://shopify.github.io/liquid/basics/introduction/), with variables you can use to further customize your experience. You can read about all variables available [here](https://auth0.com/docs/customize/universal-login-pages/universal-login-page-templates).

One of the benefits of using Auth0's rich templating system is the ability to customize logic depending on the current prompt. For example, you could have some parts of the UI shown on the signup screen but not on the login or other prompts. The term prompt is used to refer to a specific step in the login flow. Each prompt can have one or more screens. For example, the `reset-password` prompt would have multiple screens for resetting password requests, checking your email, entering a new password, and confirming your change. You can find the complete list of prompts and screens on the [official template variables documentation](https://auth0.com/docs/customize/universal-login-pages/universal-login-page-templates#:~:text=screen%20being%20rendered.-,The%20term%C2%A0prompt,-is%20used%20to).

You can do that by implementing conditionals over the variable `prompt.name`. Here's an example that renders additional content when the user is signing up.

```text
{% if prompt.name == "signup" %}
Show this only if the user is signing up
{% end %}
```

As part of templating, you can also set custom brand parameters, such as the brand's primary color, background, and logo, which you can use throughout the template by accessing the `branding` variable.

For example, if you need a button that aligns with the branding's primary color, you could implement it as follows:

```html
<button style="background-color: {{branding.colors.primary}}" ...>My Button</button>
```

Now that we know what we can do with the templating system, it's time to build your own.

Here's what I'll build. Feel free to copy and paste this template and customize it to your application or use it as a baseline for your own.

- Signup screen:
	![Custom Signup Screen](https://images.ctfassets.net/23aumh6u8s0i/5u5pK7O3FLMInWmakSjRAr/99dce5b115abc63d90ea271440f1afa6/custom-template-signup.png)
- Login screen:
	![Custom Login Screen](https://images.ctfassets.net/23aumh6u8s0i/3dzWx5rQ3xiIgqUTyBTqXT/0fee59fa6b4f593f5771ed4e25d8100d/custom-template-login.png)

What’s interesting about this design is that the signup page looks different from the rest as it provides additional information about the product, so users know what they are signing up for. I also make use of variables to set the branding color on custom elements and I added some responsive elements for tablets and mobile devices.

Here is my template for your reference:

```html
<!DOCTYPE html>
<html>
  <head>
    {%- auth0:head -%}

    <style>
        body {
            background-color: #fff;
        }

        .wrapper {
            max-width: 80rem;
            margin: 0 auto;
        }

        {% if prompt.name == "signup" %} 
        .container {
            width: 100%;
            height: 100vh;
            display: grid;
            grid-template-columns: 1fr 1fr;
            align-items: center;
        }

        @media screen and (max-width: 720px) {
            .container {
                display: flex;
                flex-direction: column;
            }
        }

        .container > .info {
            max-width: 28rem;
            padding: 1rem;
        }
        {% else %}
        .container {
            width: 100%;
            height: 100vh;
            display: flex;
            align-items: center;
            justify-content: center;
        }

        .container > .info {
            display: none;
        }
        {% endif %}

        .container > .info h2.title {
            font-size: 3rem;
            line-height: 1.2;
            margin-bottom: 1.5rem;
            font-weight: bold;
        }

        .container > .info p.subtitle {
            color: #718096;
        }

        .container > .info ul {
            list-style-type: none;
            margin: 0;
            padding: 0;
        }
        
        .container > .info li {
            color: #1A202C;
        }

        .container > .info li svg {
            color: #5CC98D;
            vertical-align: text-bottom;
            margin-top: 1.5rem;
        }

        .container > .login-box {
            position: relative;
            display: flex;
            align-items: center;
            justify-content: center;
            padding: 0 4rem;
        }

        .container > .login-box svg {
            position: absolute;
            width: 100%;
        }
    </style>
  </head>
  <body>
    <div class="wrapper">
        <div class="container">
            <div class="info">
                <h2 class="title">My Product</h2>
                <p class="subtitle">My product is awesome and it offers the following features:</p>
                <ul role="list">
                    <li>
                        <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" focusable="false" role="presentation" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><path d="m10 15.586-3.293-3.293-1.414 1.414L10 18.414l9.707-9.707-1.414-1.414z"></path></svg>
                        Feature 1
                    </li>
                    <li>
                        <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" focusable="false" role="presentation" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><path d="m10 15.586-3.293-3.293-1.414 1.414L10 18.414l9.707-9.707-1.414-1.414z"></path></svg>
                        Feature 2
                    </li>
                    <li>
                        <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" focusable="false" role="presentation" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><path d="m10 15.586-3.293-3.293-1.414 1.414L10 18.414l9.707-9.707-1.414-1.414z"></path></svg>
                        Feature 3
                    </li>
                    <li>
                        <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" focusable="false" role="presentation" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><path d="m10 15.586-3.293-3.293-1.414 1.414L10 18.414l9.707-9.707-1.414-1.414z"></path></svg>
                        Feature 4
                    </li>
                    <li>
                        <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" focusable="false" role="presentation" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><path d="m10 15.586-3.293-3.293-1.414 1.414L10 18.414l9.707-9.707-1.414-1.414z"></path></svg>
                        Feature 5
                    </li>
                </ul>
            </div>
            <div class="login-box">
                <svg width="1013" height="890" viewBox="0 0 1013 890" fill="none" xmlns="http://www.w3.org/2000/svg">
                    <path d="M180.462 795.681L40.8315 567.776C19.5801 533.09 8.95466 515.747 4.64446 497.091C0.831363 480.586 0.608543 463.413 3.99145 446.712C7.81567 427.835 17.9843 409.924 38.3214 374.102L184.235 117.101C203.682 82.8483 213.405 65.722 227.028 52.9648C239.084 41.6743 253.303 32.9153 268.81 27.225C286.332 20.7958 306.003 19.8141 345.345 17.8502L644.507 2.91668C685.874 0.851143 706.557 -0.18069 725.22 4.94606C741.731 9.48141 757.023 17.479 770.074 28.4042C784.827 40.7544 795.51 58.1913 816.877 93.066L955.838 319.878C977.009 354.434 987.595 371.712 991.91 390.3C995.728 406.747 995.98 423.86 992.649 440.515C988.883 459.337 978.815 477.215 958.678 512.969L811.011 775.156C791.315 810.127 781.466 827.612 767.593 840.563C755.316 852.023 740.811 860.86 724.997 866.515C707.127 872.905 687.074 873.638 646.968 875.103L350.229 885.943L350.228 885.944C309.449 887.433 289.06 888.178 270.689 882.944C254.434 878.313 239.396 870.318 226.557 859.48C212.045 847.23 201.517 830.047 180.462 795.681Z" fill="{{branding.colors.primary}}"/>
                    <path d="M179.711 769.196L58.7659 539.848C40.3585 504.942 31.155 487.489 28.2839 469.088C25.744 452.808 26.7984 436.065 31.3778 419.97C36.5543 401.778 47.9229 384.859 70.66 351.022L233.792 108.259C255.534 75.9041 266.405 59.7266 280.801 48.0099C293.543 37.6402 308.23 29.8499 323.963 25.1169C341.74 19.7693 361.233 19.8416 400.221 19.9857L696.692 21.0815C737.687 21.2325 758.184 21.3089 776.23 27.2798C792.194 32.562 806.699 41.1538 818.774 52.4806C832.423 65.2849 841.676 82.8321 860.183 117.928L980.548 346.176C998.887 380.95 1008.06 398.337 1010.94 416.674C1013.49 432.897 1012.46 449.584 1007.94 465.636C1002.82 483.778 991.558 500.669 969.023 534.451L803.775 782.175C781.734 815.216 770.713 831.737 756.054 843.629C743.084 854.153 728.106 862.004 712.074 866.687C693.957 871.978 674.104 871.643 634.398 870.973L340.624 866.016L340.623 866.016C300.251 865.335 280.065 864.994 262.316 858.934C246.611 853.572 232.358 844.996 220.486 833.765C207.067 821.072 197.948 803.779 179.711 769.196Z" fill="{{branding.colors.primary}}"/>
                </svg>
                {%- auth0:widget -%}
            </div>
        </div>
    </div>
  </body>
</html>
```

## Explore Your Own Designs

By the end of this article, you can now design and customize signup and login experiences with Auth0 that are as beautiful and user-friendly as the rest of your application. With the power of custom templates, you can integrate your brand's color palette, unique fonts, and more. I'd love to see the unique and effective login experiences you create! Please share screenshots or links in the comments below.

Thanks for reading!

Building Beautiful Login Pages with Auth0

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

How to authenticate and manage your business users in a multi-tenant app with Organizations.

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <b>This tutorial uses the Auth0 Organizations feature, which is <a href="https://auth0.com/startups/vip"> available to early-stage startups </a>through our Auth0 for Startups program, free for one year.</b><br> 
</div>

## The Challenge

Developers on a tight schedule need to quickly implement a secure solution. You need to build a product with scalable infrastructure that can be iterated on weeks/months/years down the line. And you need to adhere to ever-changing industry standards and regulations.

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

Building B2B applications comes with many technical challenges, not least of which is how to set up [multi-tenancy](https://auth0.com/docs/get-started/auth0-overview/create-tenants/multi-tenant-apps-best-practices). [Multi-tenancy](https://auth0.com/docs/get-started/auth0-overview/create-tenants/multi-tenant-apps-best-practices) is when a single instance of software runs on a server that is accessible to multiple groups of users – managing this across various business communities can be broken down into three different considerations:

* Customizing the login experience for each business, from branding to SSO options,
* Managing users for each business with restricted access based on specific permissions,
* And giving businesses the ability to manage their own members.

## The Solution

Auth0 Organizations is our solution to multi-tenancy from an auth perspective – it’s a feature for developers to manage business users. **Simply put, each business is an Organization. Each Organization has members. Each member can have roles that define their permissions.**

When users log into your application, how they log in depends on the requirements defined by each business. For example, let’s say you have three customers with varying needs:

* Organization A is a small business, so they’re comfortable with letting their members log in with Google or another preferred[ Social identity provider (IdP)](https://marketplace.auth0.com/features/social-connections);
* Organization B is a larger corporation, so they’re expecting to leverage not only[ Enterprise IdPs](https://marketplace.auth0.com/features/enterprise-connections) but also multi-factor authentication (MFA) as an additional layer of security;
* Organization C is a brand new startup with only one employee – the founder – and all they want is a seamless experience.

The typical app user needs to be able to log in to the app and do some basic tasks. All of your business customers also want to distinguish a role for Admins who have additional permissions, like sending invites to cool new members or kicking problematic members out.

![Your App](https://images.ctfassets.net/23aumh6u8s0i/4y486Q5HiJbXmlVq5k71pc/57ab4fbab5c49c769a442b8e781d624e/shreyapost.jpg)

## The Process

Let’s explore what a potential solution with Organizations would look like. (Check out the video for a visual walkthrough.)

### Get Started

1. Open your [Auth0 Dashboard](https://manage.auth0.com/dashboard)
2. Select your Application (left menu) and [configure it for business users](https://auth0.com/docs/manage-users/organizations/configure-organizations/define-organization-behavior)
3. [Create Organizations](https://auth0.com/docs/manage-users/organizations/configure-organizations/create-organizations) for each business customer
4. Enable Social and Enterprise [Connections](https://auth0.com/docs/manage-users/organizations/configure-organizations/enable-connections) and [MFA](https://auth0.com/docs/secure/multi-factor-authentication/enable-mfa)
5. [Create roles](https://auth0.com/docs/manage-users/access-control/rbac), [invite members](https://auth0.com/docs/manage-users/organizations/configure-organizations/invite-members) and [assign roles](https://auth0.com/docs/manage-users/organizations/configure-organizations/add-member-roles)

### Get Technical

Integrate this login experience into your React app (or [explore other SDKs](https://auth0.com/docs/libraries)). Follow the[ React SDK quickstart](https://auth0.com/docs/quickstart/spa/react/interactive) for detailed instructions.


1. Install the Auth0 React SDK

```
cd <your-project-directory>
npm install @auth0/auth0-react
```

2. Configure the Auth0 provider component

```js
import React from 'react';
import { createRoot } from 'react-dom/client';
import { Auth0Provider } from '@auth0/auth0-react';
import App from './App';

const root = createRoot(document.getElementById('root'));

root.render(
<Auth0Provider
    domain="{yourDomain}"
    clientId="{yourClientId}"
    authorizationParams={{
      redirect_uri: window.location.origin
    }}
  >
    <App />
  </Auth0Provider>,
);

```

3. Add login to your Application

```js
import { useAuth0 } from "@auth0/auth0-react";
import React from "react";

const LoginButton = () => {
  const { loginWithRedirect } = useAuth0();

  return <button onClick={() => loginWithRedirect()}>Log In</button>;
};

export default LoginButton;
```

4. Add logout to your Application

```js
import { useAuth0 } from "@auth0/auth0-react";
import React from "react";

const LogoutButton = () => {
  const { logout } = useAuth0();

  return (
    <button onClick={() => logout({ logoutParams: { returnTo: window.location.origin } })}>
      Log Out
    </button>
  );
};

export default LogoutButton;
```

5. Show user profile information

```js
import { useAuth0 } from "@auth0/auth0-react";
import React from "react";

const Profile = () => {
  const { user, isAuthenticated, isLoading } = useAuth0();

  if (isLoading) {
    return <div>Loading ...</div>;
  }

  return (
    isAuthenticated && (
      <div>
        <img src={user.picture} alt={user.name} />
        <h2>{user.name}</h2>
        <p>{user.email}</p>
      </div>
    )
  );
};

export default Profile;
```

6. If you need to retrieve the organization the user belongs to, you can use the property [`org_id` in the user object](https://auth0.com/docs/manage-users/organizations/using-tokens), for example you can add the following line of code:

```
<p>{user.org_id}</p>
```

### Go Beyond

Eventually, you may want to do more. You could:

1. [Require multi-factor authentication for users outside their corporate network](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow#enforce-custom-mfa-policy) to increase security,
2. [Assign default roles to users on sign-up](https://auth0.com/blog/assign-default-role-on-sign-up-with-actions/) or at another point in the identity flow,
3. And allow customers to self-manage their Organizations using an [admin portal](https://auth0.com/docs/get-started/architecture-scenarios/business-to-business/profile-management#admin-portal).

## The Next Step

Multi-tenancy is a common feature requirement for most B2B apps, but you shouldn’t have to spend all your time on building it. This is just the tip of the iceberg for what you can accomplish using Organizations. [Try it yourself for free](https://auth0.com/signup?utm_source=blog&utm_medium=auth0&utm_campaign=b2bsaas), and [let us know if you have any questions](https://community.auth0.com/)!

Are you an early-stage startup? [Apply now](https://auth0.com/startups/vip) to the Auth0 for Startups program, which is **free for one year** and supports 100 Organizations in prod (and much more).

## More Resources

* Get started with our [React quickstart](https://auth0.com/docs/quickstart/spa/react/interactive)
* Dive deep into the [Organizations docs](https://auth0.com/docs/manage-users/organizations)
* Read about [Solving Digital Identity Management for Your SaaS Application](https://auth0.com/blog/digital-identity-management/)
* Learn more about [Auth0 for Startups](https://auth0.com/startups)
* Ask questions in our [Community forum](https://community.auth0.com/)
* Don't have an app? Check out our [sample B2B app](https://github.com/auth0-developer-hub/auth0-b2b-saas-starter/)

[Open a ticket](https://support.auth0.com/tickets/new) for technical support (available for customers in the Startup plan or other paid plans)


Build a Secure and Scalable B2B SaaS App in React

Learn the best practices for securing ID, access, and refresh tokens in your .NET MAUI applications and keeping a consistent user experience.

Managing Tokens in .NET MAUI

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

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

Add Authentication to .NET MAUI Apps with Auth0

Your identity platform is critical to growing and scaling your SaaS application. Accelerate business growth and keep your users secured with Auth0 by Okta

For today’s SaaS builders, the pressure to rapidly innovate and seamlessly scale can be intense.

Evolving macroeconomic pressures mean companies building SaaS applications need to do more with less. And every B2C innovation amps SaaS customer expectations. AI has further transformed the competitive landscape, presenting both an opportunity for product differentiation and a threat. [There’s just more that attackers can do now](https://www.securitymagazine.com/articles/99832-study-finds-increase-in-cybersecurity-attacks-fueled-by-generative-ai) — and they can do it faster. 

SaaS companies also need to do more — and they need to see speed and security gains just so customers can keep up with the rate of change. And honestly, they need to deliver more than what’s expected in order to stay relevant in this fast-paced society. 

Since SaaS is in this ever-evolving space, companies must keep up at the business level to stay ahead of their competition. In turn, developers must continuously learn new back-end methods to keep up with the new SaaS technologies.

Let us show you how Auth0 by Okta keeps up and makes your life easier.

## How Auth0 by Okta can help your SaaS

Robust identity management is crucial for ensuring seamless user experiences, maintaining data security, and complying with regulatory requirements. Auth0, the leading identity and access management (IDaaS) platform, stands out as the ideal solution for SaaS applications due to its comprehensive features, ease of use, and robust security measures.

Auth0 simplifies the authentication and authorization process for SaaS applications, enabling developers to focus on building core functionalities rather than building their own identity solutions and managing identity infrastructure.

[Universal Login](https://auth0.com/features/universal-login) provides a centralized and unified login experience for users across all your applications, supporting a wide range of authentication flows, devices, and screen sizes. Universal Login enhances user experience and simplifies the integration process for developers. With Universal Login, users can sign in using [passkeys](https://auth0.com/docs/authenticate/database-connections/passkeys) or use their existing credentials from social media platforms, enterprise directories, or email addresses, eliminating the need to create separate accounts for each application.

In addition to Universal Login, Auth0 provides a comprehensive set of SDKs for various programming languages and frameworks, making it easy for developers to integrate Auth0 into their applications. These SDKs handle everyday authentication tasks, such as login forms and password resets, ensuring consistent and secure user experiences across applications. For more customized scenarios, Auth0's powerful APIs provide granular control over authentication and authorization flows, allowing developers to tailor them to specific requirements and integrate seamlessly with third-party services.

**Here are some specific benefits of using Auth0 for SaaS applications:**

* **Streamlined user onboarding**: Universal Login eliminates the need for users to create separate accounts for each application, making it easier for them to get started.
* **Improved user experience**: A seamless and consistent login experience across all applications enhances user satisfaction and reduces friction.
* **Customizability**: The Universal Login page can be customized to match your brand and needs. At the same time, [Auth0 Actions](https://auth0.com/features/actions) enable developers to extend Auth0 beyond its core functionality and incorporate custom logic such as integrations with APIs (CRMs, billing, email automation, marketing tools, etc) or write custom policies into the authentication and authorization flows.
* **Reduced development time**: Developers can save time and effort using pre-built Universal Login components and SDKs, simplifying the integration process.
* **Global or regional scalability**: Auth0's public and private cloud-based infrastructure scale seamlessly to accommodate user demand internationally and fluctuating traffic spikes.
* **Security Center and Log Streaming**: Auth0 provides robust security features to protect your SaaS application users and your business. With Attack protection features such as bot detection and breached password detection, you can offer comprehensive protection against credential-stuffing attacks. You can also offer streamlined security and follow compliance with MFA and RBAC. In addition, you can monitor your applications and detect identity-driven attacks with Security Center and integrate activity logs with your security toolkit with Log Streaming.
* **Expanded support for various platforms**: Universal Login and SDKs are available for various programming languages and frameworks, enabling developers to build secure and scalable SaaS applications across various platforms.
* **Future-Proof Features**: Auth0 continuously invests in innovation, incorporating the latest security and authentication technologies. By integrating with Auth0, SaaS applications can leverage these future-proof features, ensuring they remain secure and compliant with evolving industry standards.

## B2B Ready with Auth0 Organizations

For some SaaS applications, the B2B aspect is baked into the core design, with a clear understanding of the requirements for managing users from different organizations. However, for many SaaS applications, the need to support B2B scenarios may arise as a requirement that needs quick implementation. This can add complexity to development and require significant effort to integrate and maintain separate identity management systems for each organization.

Auth0 addresses this challenge with [Auth0 Organizations](https://auth0.com/organizations) by providing a unified platform for managing B2B relationships, enabling SaaS applications to efficiently onboard, manage, and secure user identities across multiple organizations.

Auth0 customers can use Organizations to:

* Represent their business customers and partners in Auth0 and manage their membership.
* Allow your business customers to securely manage and customize how their end-users access apps, with the ability to add as many organizations as they need to their Customer Identity Cloud (Private Cloud) tenant.
* Configure branded, federated login flows for each business.
* Build administration capabilities into their products, using Organizations APIs, so that those businesses can manage their own organizations.
* Supports your multi-tenant product out-of-the-box, conveniently serving from a single Customer Identity Cloud tenant.

![Organizations](https://images.ctfassets.net/23aumh6u8s0i/kZUAmaE3qFsxXaeTwxeOb/3dbe661afe612b1596fe4e990803d248/saas01.png)

## Enterprise Ready

In the realm of enterprise-grade SaaS applications, the need for comprehensive identity management extends far beyond traditional user authentication. Enterprises demand a robust solution that seamlessly integrates with existing IT infrastructure, manages complex access policies, and complies with stringent security standards.

Auth0 enables SaaS applications to connect seamlessly with enterprise systems without building custom integrations, eliminating the need for developers to maintain multiple integrations and reducing development time and effort by providing:

* **Seamless Integration with Enterprise Identity Systems**: Auth0 Organizations seamlessly integrate with existing [enterprise identity providers](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers), such as Active Directory, LDAP, and SAML IdPs.
* **Single Sign-On (SSO) for Enterprise Applications**: Auth0 Organizations supports SSO for enterprise applications, enabling employees to sign in to multiple applications using a single set of credentials. This streamlines the user experience and improves productivity.
* **Activity Auditing for Enterprise Compliance**: Auth0 provides detailed activity auditing for enterprise compliance, allowing organizations to track user activity and access patterns. This auditing functionality helps to identify suspicious activity, investigate potential security breaches, and ensure compliance with regulatory requirements.

## Built-in Security

With built-in security features and continuous innovation, Auth0 provides developers with the tools and expertise to build secure SaaS applications that safeguard user identities, sensitive data, and applications from a wide range of threats. Auth0's security features are not only beneficial to developers; they are also a key selling point for SaaS providers who want to ensure their customer’s data and applications are safe and secure.

Here are some of the built-in security features of the Auth0 platform:

### Attack Protection

Auth0's attack protection features can detect and stop malicious attempts to access your application by blocking traffic from specific IPs, displaying CAPTCHAs, and more.

Auth0 offers the following attack protection options:

* **[Bot Detection](https://auth0.com/docs/secure/attack-protection/bot-detection)**: Bots, automated programs often employed by malicious actors performing credential-stuffing attacks, pose a significant threat to online applications and services. Auth0's bot detection capabilities utilize sophisticated techniques to identify and block these bots, preventing them from accessing your applications and disrupting user experiences.
* **[Suspicious IP Throttling](https://auth0.com/docs/secure/attack-protection/suspicious-ip-throttling)**: Blocks traffic from any IP address that rapidly attempts too many logins or signups. This helps protect your applications from high-velocity attacks that target multiple accounts.
* **[Brute Force Protection](https://auth0.com/docs/secure/attack-protection/brute-force-protection)**: Brute force attacks involve repeatedly attempting to guess user login credentials, often automated through scripts or botnets. To combat these attacks, Auth0's brute force protection feature limits the number of failed login attempts from a single IP address. Once a threshold of failed attempts is reached, the IP address is temporarily blocked, preventing further attempts and mitigating the risk of successful brute-force attacks.
* **[Breached Password Detection](https://auth0.com/docs/secure/attack-protection/breached-password-detection)**: Auth0 tracks large security breaches that occur on major third-party sites. If Auth0 identifies that any of your users’ credentials were part of a breach, the breached password detection security feature triggers keeping your accounts safe.

![attack protection](https://images.ctfassets.net/23aumh6u8s0i/6T8KTzpEpJ0YrNMX7qDIMM/a93051c4295c9fd66acbb752fcbdaa08/saas02.png)

Auth0's attack protection features are based on industry-standard security protocols, and they can help you protect your applications from a wide range of attack vectors. To implement Auth0's attack protection features, you can integrate Auth0 into your application. Once integrated, Auth0 will automatically protect your application from attacks.

## Extensibility

Auth0 goes beyond providing a robust authentication and authorization platform; it also offers a wide range of extensibility capabilities, enabling developers to tailor the platform to their specific application requirements and integrate it with their existing infrastructure.

### Auth0 Actions

[Auth0 Actions](https://auth0.com/features/actions) is a powerful extension mechanism that empowers developers to modify Auth0's authentication and authorization flows. These JavaScript functions can be executed at various points in the authentication process, allowing developers to:

* **Modify access tokens with custom claims**: Add, update, or remove custom claims to access tokens, enabling granular control over user permissions and data sharing.
* **Integrate with external services**: Connect to external services like CRM systems, customer data platforms, and payment gateways to enrich user profiles and facilitate seamless user journeys.
* **Enhance user experiences**: Personalize the login and registration experience, customize error messages, and provide user context-aware support.
* **Implement custom logic**: Add custom logic to handle specific scenarios, such as verifying two-factor authentication codes or managing user roles.

You can write your own custom Auth0 Actions writing JavaScript code or browse and install any Action from a curated collection at the [Auth0 Marketplace](https://marketplace.auth0.com/). In the marketplace, you can find Actions providing a wide range of functionalities, such as:

* **Social login integrations**: Connect with popular social networks like Facebook, Google, and LinkedIn to facilitate user authentication and signup.
* **Identity Proofing**: Identity proofing allows you to verify a user's real-world identity based on life history (a credit report), biometrics (a facial scan), and other factors before granting access.
* **Compliance and security solutions**: Implement compliance solutions like fraud detection and data privacy controls.

And much more...

## Get Started with Our SaaS Starter Kit

Embarking on developing a SaaS application can be an exciting yet challenging endeavor. To simplify the process and accelerate time to market, Auth0 offers a [SaaS Starter Kit](https://developer.auth0.com/resources/guides/web-app/nextjs/saas-basic-authentication) that provides a jumpstart for building secure and scalable SaaS applications.

The SaaS Starter Kit is a guide and boilerplate you can use to build a Next.js SaaS application tailored for the following use cases:

* SaaS Multi-tenancy with Auth0 Organizations in a single Auth0 tenant.
* A tiered pricing model using Auth0 Actions and User Profile[ App Metadata](https://auth0.com/docs/manage-users/user-accounts/metadata#metadata-types).
    * Support Trial, Personal, Teams, and Enterprise plans in a SaaS application.
* Trial plan expiration and user conversion using Auth0 Actions.
    * Use Actions to update user profile data, enrich an ID or Access Token with custom claims, or call 3rd-party APIs, such as the Stripe API, to manage user subscription status.
* Self-service SSO for business users using the Auth0 Management API and Enterprise connections with support for OIDC connections.
* Self-service User Management using the Auth0 Management API.

With the [Auth0 SaaS Starter Kit](https://developer.auth0.com/resources/guides/web-app/nextjs/saas-basic-authentication) as your foundation, you can build secure, scalable, and feature-rich SaaS applications that provide a seamless user experience while adhering to industry best practices for authentication and authorization.

## The Customer Identity Platform for Startups

[Auth0 for Startups](https://auth0.com/startups) is a program that provides the convenience and security of Auth0 by Okta to eligible startup customers FREE for a year, so you can get your SaaS application up and running quickly while keeping your users’ data secure.

Some of the benefits of the program are:

* Up to 100k Monthly Active Users
* Up to 5 Enterprise Connections
* All the B2B features you need to scale your business

> Learn more and apply for the program in[ the customer identity platform for startups](https://auth0.com/startups).

Solving Digital Identity Management for Your SaaS Application

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

Detect hackers with Auth0 Actions and special accounts designed to catch them in the act.

Use Honeytokens and Auth0 Actions to Catch Malicious User Logins

Now that you can create dates and times in Swift, learn how to display date and time values to your users.

Introduction to Date and Time Programming in Swift, Part 2

A quickly implemented Auth0 Action can enhance security by requiring users to log in from trusted IP addresses or blocks.

Ensure Users Log in from Trusted Networks with Auth0 Actions

Auth0 Actions allow you to customize your registration flows to fit your needs. Let's learn how to add a default role to a user when they sign up to your application.

When building an application requiring access control, you might have the need to use roles and permissions. In this blog post, you'll learn roles and permissions, the difference between the two, and how to assign a default role for your users using Auth0 Actions. 

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

## Roles and Permissions

The first step to add authorization to your application is to add authentication. Once you guarantee that only authenticated users can access it, you should have more control over who can access what. 

In an organization, [a role defines what a user can or can't do](https://auth0.com/blog/what-is-rbac-and-how-to-implement-it-rails-api/#What-are-Roles). Roles are often used to reflect the organizational structure, departments, etc. In relatively small authorization systems, using roles is a fast way to manage access control of resources. 

A [permission](https://auth0.com/blog/permissions-privileges-and-scopes/#What-Are-Permissions) is a declaration of an action that can be executed on a resource.

[In Auth0, a role is a collection of permissions](https://auth0.com/docs/manage-users/access-control/rbac#roles) that you can apply to users, which can facilitate how you add, remove, and manage permissions because you handle them as a group rather than assigning them to users individually. For example, you could have a role `author`, and as permissions, you could have `create:article`, `edit:article`, and so on.  

### Creating and Assigning Roles with Auth0

For this blog post you'll need an Auth0 account and a [registered API with Auth0](https://auth0.com/docs/get-started/apis), 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</a>.

<include src="SignupCTA" text="Get an Auth0 Account for free." linkText="Get started →" />

### Create a Role on Auth0

From the [Auth0 Dashboard](https://manage.auth0.com/), click on **User Management** on the sidebar, then **Roles**. Click the **+ Create Role** button to create a new role. Let's say we want a default role for users, so you can name it `default_role` and add a meaningful description, then click on **Create**.

![Create a new Role Auth0](https://images.ctfassets.net/23aumh6u8s0i/4GuPwI9qt9FxfM0H8w4mcR/702130453889177b12c87989c9cd4d62/Screenshot_2023-10-20_at_18.11.42.png)

## Assigning Roles with Auth0 Actions

Now that you have the role, you need to be able to send it to your application. A simple way to do this with Auth0 is by adding the user's role using the [Management API](https://auth0.com/docs/manage-users/access-control/configure-core-rbac/rbac-users/assign-roles-to-users#management-api)

Adding roles to sign-up is not a built-in feature, so adding an [Auth0 Action](https://auth0.com/docs/customize/actions) to the **Login Flow** is a way to do it. An Action is a JavaScript function that allows you to customize the standard behavior of different Auth0 flows. 

> Note: you'll use the Login Flow and not Post User Registration flow. 

The Post User Registration flow is triggered after a user is added to a Database or Passwordless Connection. The actions that you use in this flow are non-blocking; they run asynchronously, which means the Auth0 pipeline will continue to run without waiting for the Action to finish its execution. 

![Post User Registration Flow Diagram](https://images.ctfassets.net/23aumh6u8s0i/7HbRIH2EDFHblUTh9v20Fx/0c75bd64d3cff33f34f18c638847aa7e/post-user-registration-flow.png)

What about the other connections? Well, if your user's sign up using a Social Connection, the Post User Registration flow will not be triggered, but the Login Flow will, because in Auth0, whenever a user signs up, they are immediately logged in afterward. 

In the Login Flow, the post-login trigger will be executed after a user logs in and when a Refresh Token is requested, which is exactly what you need because you want your action to execute regardless of the database connection used. 

![Login Flow Diagram](https://images.ctfassets.net/23aumh6u8s0i/6Thx4RkK5XheYYUwzXrkPP/4906424ad7476516cef5615db5a6659b/Login_Flow__1_.png)

You can check out the official docs to learn more about [Actions Flows and Triggers.](https://auth0.com/docs/customize/actions/flows-and-triggers)

From the Auth0 Dashboard, click on **Actions** and then **Library**. Next, click on the **Build Custom** button. In the modal that opens up, add a name for the action, select the **Login/Post Login** trigger, and then click on **Create**.

![Create new Action](https://images.ctfassets.net/23aumh6u8s0i/4se18ePBFxTJmNaljcZlsw/e143d7bbb0897ee026500cec6865daf9/auth0-create-action.png)

[The Actions editor will open](https://auth0.com/docs/customize/actions/write-your-first-action#create-an-action), and inside the `onExecutePostLogin` function, add the following code: 

```js
/**
* Handler that will be called during the execution of a PostLogin Flow.
*
* @param {Event} event - Details about the user and the context in which they are logging in.
* @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login.
*/
exports.onExecutePostLogin = async (event, api) => {

  // Check if the user has a role assigned
  if (event.authorization && event.authorization.roles && event.authorization.roles.length > 0) {
    return;
  }

  // Create management API client instance
  const ManagementClient = require("auth0").ManagementClient;

  const management = new ManagementClient({
    domain: event.secrets.DOMAIN,
    clientId: event.secrets.CLIENT_ID,
    clientSecret: event.secrets.CLIENT_SECRET,
  });

  const params =  { id : event.user.user_id };
  const data = { "roles" : ["YOUR_ROLE_ID"] };

  try {
    await management.users.assignRoles(params, data);
  } catch (e) {
    console.log(e);
  }
};
```

Let's take a look at what this code does, starting with the first `if` statement: 

```js
if (event.authorization && event.authorization.roles && event.authorization.roles.length > 0) {
  return;
}
```

You are checking that the user has a role assigned, which, in the particular use case of this blog post, means the user has logged in previously. **Remember you care about the user's first login, and in Auth0, that happens right after they sign up.**

[You're using the `event` object from the Login Flow](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow/event-object). The `event.authorization` object contains information describing the authorization granted to the user who is logging in, and one of its properties is `roles`, an Array of strings that contains the names of the user's assigned roles. 

Then, by using the `auth0` NPM package, you create a new Management API client instance and initialize it with the values for `domain`, `clientId`, and `clientSecret`:

```js
const ManagementClient = require("auth0").ManagementClient;

const management = new ManagementClient({
  domain: event.secrets.domain,
  clientId: event.secrets.cliendId,
  clientSecret: event.secrets.clientSecret,
});
```

For this code to work, you must install the [`auth0` NPM package](https://www.npmjs.com/package/auth0). You can do so using the [dependency manager on the sidebar in your Actions Code Editor.](https://auth0.com/docs/customize/actions/manage-dependencies#add-a-dependency-using-the-actions-code-editor)

You also need to add the values for `domain`, `clientId`, and `clientSecret` to the [Actions' Secret Manager](https://auth0.com/docs/customize/actions/write-your-first-action#add-a-secret). You can find the values for these variables in your [Auth0 Application Settings page](https://auth0.com/docs/get-started/applications/application-settings).  

Next, you're initializing the payload to send it to the management API. To add a role to a user, you'll use the method [`assignRoles`](https://auth0.github.io/node-auth0/classes/management.UsersManager.html#assignRoles), which associates a role with a user. The first parameter is an object with the user's ID, and the second is an object with an array of `roles`. 

```js
const params =  { id : event.user.user_id };
const data = { "roles" : ["YOUR_ROLE_ID"] };
```

Note here you're passing `YOUR_ROLE_ID`; here, you'd need to pass the role ID, which you can find on the Auth0 Dashboard by navigating on the sidebar to **User Management> Roles**. Select the role you want to see details of, and you'll see the Role ID.

![Role Details Screen](https://images.ctfassets.net/23aumh6u8s0i/27FKFQMJ8MJOerHoIjtl3M/4f9c43afed9cc9eeea16fda94cb165ea/Screenshot_2023-10-20_at_17.53.37.png)

Finally, you're making the call to the Management API's method `assignRoles` and passing the parameters you initialized in the previous step:

```js
try {
  await management.users.assignRoles(params, data);
} catch (e) {
  console.log(e);
}
```

You can **test the action within the editor** using the user ID of a test user you have already created but has no role assigned yet. After logging in, the user should have the role assigned!

Once you're happy with your action, you can go ahead and click on the **Deploy** button in the top-right corner. 

The last step is to **add your action to the Login Flow**. From the Auth0 Dashboard sidebar, go to Actions > Flows > Login. 

Once in the Login Flow view, click on **Custom** on the right side to add the action you just created. Then, drag your action into the Login Flow and place it between the Start and Complete steps.  

![Login Flow - drag and drop role action](https://images.ctfassets.net/23aumh6u8s0i/590X9hg6UI8FpkOlty1hD4/1abcac0f26e411ed69e3c08db3ff1e9d/Screenshot_2023-10-20_at_18.04.36.png)

## Summary 

In this blog post, you learned about roles and permissions and that in Auth0, a role is a collection of permissions. 

Then, you implemented an Auth0 Action to assign users a default role after signing up. For that, you added the `auth0` NPM package, created secrets using the Actions Code Editor, and tested and deployed your action. 

Assigning a Default Role to Users on Sign-Up with Auth0 Actions

Auth0 by Okta now supports passkeys! Here’s how you activate them so your users can enjoy passwordless login.

## Passkeys Are Now Available in Auth0 by Okta!

Passkeys are a replacement for passwords, and they’re now a feature in Auth0! Your users can enjoy the convenience and enhanced security that passkeys provide.

If you’d like to find out more about what passkeys are, what the user experience is like, and how they work, take a look at this article on the Okta blog: [*_Adding Passkeys to Your Applications with Okta Customer Identity Cloud Powered by Auth0_*](https://www.okta.com/blog/2023/10/adding-passkeys-to-your-apps-with-okta-cic-powered-by-auth0/). It will provide you with plenty of background information about this new feature.

If you want to activate passkeys for your users, read on! You’ll be pleased that the process takes very few steps.

<include src="LearnPasskeysCTA"/>

## Activating Passkeys

Passkeys are available as a feature on all Auth0 plans — even the free ones! This means that if you want to familiarize yourself with passkeys and their user experience, 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)">set up a free tenant and add passkey-enabled authentication to your applications at no cost</a>.

### Good news for developers: you don’t have to update any code!

![Developer in chair with a laptop in their lap, arms raised in victory.](https://images.ctfassets.net/23aumh6u8s0i/2HWOHOwXs1jU1XmXWPAJJP/91161bac9d396cf9b57d0a7d281593e1/cheering_developer.png)

You don’t have to change any of your application code to support passkeys. The code that displays the Universal Login box with the email and password displays the new version with the _Continue with a passkey_ button once you enable passkeys in your tenant.

### How to activate passkeys

To enable passkeys for your users, sign into the Auth0 Dashboard, and if necessary, select a tenant.

In the left column menu, select _Authentication_ → _Database_. You will be taken to the _Database Connections_ page:

![Database Connections page](https://images.ctfassets.net/23aumh6u8s0i/3XfCfsP4PJcdX6M2Q8vqFP/e13422d9053117bf7305e6913379ee82/01.png)

Remember that with passkeys, the authentication server stores the users’ public keys. This means that in order to enable passkeys, user information must be stored in an Auth0 database. **You cannot use a custom database if you want users to sign in with passkeys.**

Choose an existing Customer Identity Cloud database from the list or create a new one by clicking the _+ Create DB Connection_ button and then choose that database. In this example, we’ll enable passkeys on the default _Username-Password-Authentication_ database connection.

You should now be on the Settings tab of the database connection:

![Settings page of the Username-Password-Authentication database connection](https://images.ctfassets.net/23aumh6u8s0i/64SMnTqwOg5tBH0ySuvXIZ/11030b48bbaa9a315262c69a7a509849/02.png)

Click the _Authentication Methods_ tab. This is where you activate passkeys:

![Authentication Methods tab, with Passkey switch in the “off“ position](https://images.ctfassets.net/23aumh6u8s0i/7fVIRsMNCunbLv6R9Fclig/4695bcd2c8e72a803306127ec71f0da3/03.png)

Turn on the _Passkey_ switch. This will activate passkeys for the tenant’s users.

Depending on your current database setup, you might need to change some settings before you can enable passkeys. You’ll know this is the case if you click the _Passkey_ switch and see a pop-up like this:

![Pop-up showing missing passkey prerequisites](https://images.ctfassets.net/23aumh6u8s0i/4ofnZJpwGuWaNvSBGDxbPa/977ba453f6dab114a2eec4667b861b5e/04.png)

Click the link for any item marked _PENDING_ and make the required changes. For example, if “New Universal Login Experience must be enabled:” is _PENDING_, click that link to go to the login experience page and enable the New Universal Login.

Here are all the required configurations for passkeys:

* Enable these features:
	* **Identifier First login flow.** The _Identifier First_ login flow presents the user with a screen where they enter their identifier, followed by another step where the user provides proof of their identity, such as a password or confirmation from a face or fingerprint recognition system. It differs from the _Identifier + Password_ login flow, which presents the user with a single screen to enter both their email and password.
	* **New Universal Login Experience.** The New Universal Login Experience provides many improvements over the Classic Universal Login Experience, including support for the W3C/FIDO Web Authentication API, which is necessary for passkeys.
* Disable these features:
	* **Custom Login Page.** Currently, the login flow for passkeys does not support custom login pages.
	* **Requires username.** With passkeys, there is no need for an additional text field for the user to enter a username.
	* **Use my own database.** Passkeys require a specific database setup, so only the Customer Identity Cloud database is allowed when passkeys are enabled.

Once you’ve met all the prerequisites for passkeys, you can enable them. The page should look like this:

![Authentication Methods tab, with Passkey switch in the “on“ position](https://images.ctfassets.net/23aumh6u8s0i/Qlr00CvgsFGd46cOZR9or/7b2e1170a6a09fab9d24ed28e14db36a/05.png)

You can now configure the settings for passkeys. Do this by clicking the _Configure_ link for the _Passkey_ item. This will take you to the _Passkey Policy_ tab of the _Policies_ page for the database connection:

![Passkey Policy tab of Policies page](https://images.ctfassets.net/23aumh6u8s0i/643sxiccQjpWdUsBvL528s/3df48433375f1a95fce38f26c2d043e2/06.png)

Let’s take a closer look at each of the settings areas on this page.

The first section is the _Passkey Challenge_ section, which defines how Universal Login presents passkey options to the user:

![Passkey Challenge section](https://images.ctfassets.net/23aumh6u8s0i/2uTtiGuRmEJuejdOR6SPSd/7614660c58cef4565af973f121348bed/07.png)

The default selection, _Both_, results in a Universal Login box that looks like this:


<img src="https://images.ctfassets.net/23aumh6u8s0i/3AO5dXLKgt0kb4lscxD0Sr/abbe5b17cfc5576639e1070ea1589557/7a.png" alt="Universal Login box featuring both email address text field and “Continue with a passkey” button" width="500"><br>


This version of the Universal Login box provides two options for logging in with a passkey. First, there’s the very obvious _Continue with a passkey_ button at the bottom, which presents a list of passkey options when pressed.

There’s also the less obvious autofill. It appears when you click on the _Email address_ field, also providing passkey options:

<img src="https://images.ctfassets.net/23aumh6u8s0i/5RDJGPagC2loJtpOqxh4IA/278ef844d3768669badd009770cacebc/7b.png" alt="Universal Login box with a pop-up menu appearing beside the Email address text field" width="500"><br>

This is where the “discoverable” part of passkeys comes in. The user doesn’t have to type in their email address to log in because the browser is able to discover this information.

Since passkeys will be new to most users, we recommend providing users with as many options as possible by selecting the _Both_ option.

The next section contains the enrollment controls:

![Progressive Enrollment and Local Enrollment sections](https://images.ctfassets.net/23aumh6u8s0i/1CzIy25CTpwJczGVjD3fuO/3a41e2cce254ea1b864ef1a9db0f55b5/8.png)

We recommend that you turn on both _Progressive Enrollment_ and _Local Enrollment_, as they make for a better user experience. This is especially true for the _Local Enrollment_ option, which lets users create a new passkey on their local device.

## Take Passkeys for a Test Run

Now that you’ve enabled passkeys, it’s time to try them out. Click on _Getting Started_ in the left column menu, then click the _Try it out_ link in the _Try your Login box_ section:

![The Getting Started page](https://images.ctfassets.net/23aumh6u8s0i/6xIukz0MFdFz2qXLu2Vhvw/5e617d07eedb8067ff7f14760d06fde2/09.png)

You’ll see the Universal Login box:

<img src="https://images.ctfassets.net/23aumh6u8s0i/3AO5dXLKgt0kb4lscxD0Sr/abbe5b17cfc5576639e1070ea1589557/7a.png" alt="Universal Login box featuring both email address text field and “Continue with a passkey” button" width="500"><br>

Create a new account by clicking the login box’s _Sign up_ link. You’ll see this:

<img src="https://images.ctfassets.net/23aumh6u8s0i/72c8onNnTqteldYZyVSWvo/260381b65f9b03cd128639d07b4a3e01/10.png" alt="The “Create Your Account” window” button" width="500"><br>

Enter an email address into the field and click the _Continue_ button. You’ll be given the option to create a passkey:

<img src="https://images.ctfassets.net/23aumh6u8s0i/10NFQPGZWt0J812WYRXmBh/55f1ed8742ab35d711c315928793aa89/11.png" alt="Create a passkey for All Applications on this device" width="500"><br>

Click the _Create a passkey_ button. You’ll see this pop-up:

![The “Create a passkey” pop-up](https://images.ctfassets.net/23aumh6u8s0i/3fCLK6elDLVoKzGZVG02Pa/e942165fe827e794b21c16b84cc64293/12.png)

Select the _This device_ option. The pop-up will be replaced with this:

![The follow-up “Create a passkey” pop-up](https://images.ctfassets.net/23aumh6u8s0i/VGmCSE5HBr7xCb2j4xet0/29469f0cbb14a88e441d2be9622921fc/13.png)

Click _Continue_ to create a passkey on your computer.  You’ll then be asked to verify your identity with your computer:

![“Google Chrome is trying to verify your identity” pop-up](https://images.ctfassets.net/23aumh6u8s0i/2fj9aoDANJQnlmkdERZ8VY/0197f8812ddcb65110081b9556e9b032/14.png)

Once you’ve authenticated yourself, you’ll see this sign of success:

![The Deashboard’s “It Works!” screen](https://images.ctfassets.net/23aumh6u8s0i/1cdCf7Oq00Q7XvDsbDnFb4/41acb1dfd02feda06a42e446ca3b6a34/15.png)

Congratulations! You’ve successfully enabled passkeys on your tenant!

Try creating passkeys using your tenant’s applications and then logging in. Here’s one of my mobile apps authenticating against my passkey-enabled tenant:

![Universal Login screen with passkeys activated, as seen on an iPhone 14](https://images.ctfassets.net/23aumh6u8s0i/1lMA2ZcOHf9etfLx24v3au/23dda036a2aa52a0d882332a5e59e12a/16.png)

## Conclusion

Activate passkeys now and see how you can give your users a more convenient, more secure login experience!

* If you’re new to Okta Customer Identity Cloud Powered by Auth0, <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 trial account!</a>
* If you already have an account, you’ll want to look at our [passkeys documentation](https://auth0.com/docs/authenticate/database-connections/passkeys).
* Be sure to read the companion article to this piece, [*_Adding Passkeys to Your Applications with Okta Customer Identity Cloud Powered by Auth0_*](https://www.okta.com/blog/2023/10/adding-passkeys-to-your-apps-with-okta-cic-powered-by-auth0/)!


Activate Passkeys and Let Your Users Log in without a Password

bonfida

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

Bonfida.sol

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

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

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

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

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

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

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

## A Better Experience for Solana Users

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

Sign in with the Solana Name Service Powered by Auth0

Learn how to use the Auth0 Python SDK to query and store user data in this step-by-step tutorial.

The **Auth0 Dashboard** offers a wide range of tools for managing your application's authentication and authorization. You can create and delete users, assign roles, ban IPs, and much more. Although it's convenient to manage users directly from the dashboard, there may be scenarios where you need control from within your application.

Say, for example, that you want to store UI preferences such as dark/light mode settings or the user’s preferred theme directly on the user’s profile so that, independently from which device they connect to your application, they will have their favorite settings ready.

In scenarios like this, where your application directly processes and manages users' information, you can use the [Auth0 Management API](https://auth0.com/docs/api/management/v2), which allows you to work with users' data and programmatically access most features available in the Auth0 Dashboard.

In this article, we’ll explore how to use the Auth0 Management API from Python applications using the Auth0 Python SDK to read and store information about users, and at the end, we’ll build a lottery system to pull a random lucky user from the system.

## Accessing the Auth0 Management API

The Auth0 Management API allows you to programmatically create, access, update, and delete resources from your Auth0 tenant. It is an API built for back-end servers or trusted parties to perform administrative tasks such as user management or DevOps.

You can access the [Auth0 Management API](https://auth0.com/docs/api/management/v2) via HTTP requests directly or use one of the SDKs we provide for such a purpose. In any scenario, you’ll need a few things before starting the management API.

- **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>.
- **A machine-to-machine application**
- **A short-lived token** for production access to the API

### Set up your Auth0 account

Once you have an <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Auth0 account</a> you can navigate the the [Auth0 Dashboard](https://manage.auth0.com/#/applications) and access your applications list.

![Auth0 application's dashboard](https://images.ctfassets.net/23aumh6u8s0i/3QEFGVXK0EW2UlGNfaU8jK/bebbcfa41f716523f000c45b6ba863a0/auth0-ma-create-app.png)

Once on the page, click on the “Create Application” button on the top right and enter the following information:

- **Name**: A descriptive name for your application, e.g., User Management App
- **Application Type:** Because we’ll be connecting to this Auth0 application from another system, e.g., your Python application, you need to select “Machine to Machine Applications.”

Then click on “Create”.

![Creating a machine to machine application](https://images.ctfassets.net/23aumh6u8s0i/6F51sEhfGP6lOGXmldL8s7/c274315a617ae8f42c5278e61e91aa41/auth0-ma-create-app-details.png)

In the following dialog, you’ll select which API you’ll authorize this application to access. In our case, you’ll choose the **Auth0 Management API** already available in your tenant. Before authorizing the API, Auth0 will list all the permissions associated with it. There are many available. For our use case, you'll authorize the following: `read:users`, `update:users`, `read:users_app_metadata`, and `update:users_app_metadata`. Finally, click on “Authorize”.

![Assigning permissions to an API](https://images.ctfassets.net/23aumh6u8s0i/6eWpQ9QUTcOT9gT2gb5Do0/b4605872f7de2186401c747f044cd21e/auth0-ma-authorize-api.png)

> You can update your application’s permissions at any point from the Auth0 dashboard.

### Get a Test Token from the Auth0 Dashboard

Now you are ready to test your Auth0 Management API. Visit the API entry on the [Auth0 Dashboard](https://manage.auth0.com/#/apis).

![Auth0 API dashboard](https://images.ctfassets.net/23aumh6u8s0i/4ap0GxPP1WrjfaueqzfovG/150363bf27096f8bda6997aa5f49ced2/auth0-ma-apis.png)

Once there, click on the Auth0 Management API and head on to the “Test” tab. After a few seconds, you’ll see a screen like the following:

![Getting API Access Token from the Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/5HJDsh75FgjFB5fbfFhSLN/38ed227a790b4be7632ecaaa32c0af9e/auth0-ma-api-test.png)

Before continuing, ensure you have the correct application selected on the drop-down; next, you can copy your `access_token` from the UI. Make sure to copy just the value without the quotes. You’ll need this token next.

You can test your API directly on the [API documentation page](https://auth0.com/docs/api/management/v2). You can explore and test all the API endpoints there, though we’ll focus on the list [user’s endpoint](https://auth0.com/docs/api/management/v2#!/Users/get_users) for now.

![Auth0 Management API docs](https://images.ctfassets.net/23aumh6u8s0i/6tZBiNtrWUf8fmGeji8FUS/112e38d8ae05bf8376b402b9ccc04699/auth0-ma-list-users.png)

On the “List or Search Users” section, you’ll find the different parameters you can use to query users. For now, we’ll leave them all to the default values, and if you look to the right of the screen, you’ll find a button, “Test Endpoint”, at the end of the section.

The button is currently disabled as the documentation page is not authorized to make calls to the management API yet. To test endpoints on the documentation page, you'll need to provide an API Token using the "Set API Token" on the top right of the screen.

![Set API Token to make API calls](https://images.ctfassets.net/23aumh6u8s0i/6UO3HenV2TLVG6xTjVVFsF/24eaa6acff4b6728849588e434f7a202/auth0-ma-set-api-token.png)

Next, paste your access token from the Auth0 dashboard into the modal window and click “Set Token”. If you copied the token value correctly and tried the endpoint again, you should now see your list of users.

![Example response for the list users API endpoint](https://images.ctfassets.net/23aumh6u8s0i/5fse9EYIe0xXci2oPtxDXU/2980f08b1cdca89640fc4a0e6f787fa1/auth0-ma-list-users-list.png)

## How to Consume the Auth0 Management API with Python

To make your life easier when working with the Auth0 Management API, Auth0 offers a set of tools in multiple programming languages. In the case of Python, we have the [Auth0 Python SDK](https://github.com/auth0/auth0-python) that allows for easy and convenient access to all the features in the management API.

To consume the Auth0 Management API with Python, we will use the Auth0 Python SDK. To install it, run the following command:

```bash
pip install auth0-python
```

After installing the library, you must get a short-lived access token and initialize it programmatically. You’ll need information about your Auth0 tenant domain and the machine-to-machine application you created before. You’ll need the “Client Id” and the “Client Secret”, which can be found on the [Auth0 Dashboard](https://manage.auth0.com/#/applications) under your application’s settings.

![Domain, Client Id, and Client Secret are available in the app settings](https://images.ctfassets.net/23aumh6u8s0i/72vTRKfXxiFPXNIxTAGZkb/9be57cda028c928c9091d00c638c2d00/auth0-ma-app-settings.png)

Once you can access these values, you set the Auth0 SDK with the following code:

```python
from auth0.authentication import GetToken
from auth0.management import Auth0

domain = 'mydomain.auth0.com'
client_id = 'myclientid'
client_secret = 'myclientsecret'

get_token = GetToken(domain, client_id, client_secret=client_secret)
token = get_token.client_credentials('https://{}/api/v2/'.format(domain))
mgmt_api_token = token['access_token']
auth0 = Auth0(domain, token['access_token'])

auth0 = Auth0(domain, mgmt_api_token)
```

And finally, if you, for example, want to list your users, you can run:

```python
users = auth0.users.list()
print(users)

# Example Output
{
    "start": 0,
    "limit": 25,
    "length": 25,
    "users": [
        {
            "created_at": "2023-07-14T11: 01: 09.493Z",
            "email": "###.#####@###.com",
            "email_verified": False,
            "identities": [
                {
                    "connection": "Username-Password-Authentication",
                    "provider": "auth0",
                    "user_id": "64b12af5c157759fdf791d4d",
                    "isSocial": False
                }
            ],
            "name": "###.#####@###.com",
            "nickname": "###.#####",
            "picture": "https: //s.gravatar.com/avatar/.........png",
            "updated_at": "2023-07-14T11:01:09.493Z",
            "user_id": "auth0|64b12af5c157759fdf791d4d",
            "last_login": "2023-07-14T11:01:09.491Z",
            "last_ip": "2a01:c23:c480:7900:6c:a31c:9c46:f435",
            "logins_count": 1
        },
        ...
    ],
    "total": 40
}
```

## Updating Users’ Profile Information

Auth0's user profiles store basic information about each user, including a unique identifier, name, contact details, and identifying information such as their profile picture. This information is helpful during the authentication process, but you may also require additional information as the user logs in, such as:

- User preferences, such as the application’s theme or color scheme, etc.
- Flags that the user opt-in in the application, such as notification preferences, getting started tutorial completion, etc.
- Others, such as the last read announcement, subscription status, and more.

Auth0's user profiles can store such information as metadata, which your app can access once the user logs in successfully. Although your app could store this information in its own storage system, utilizing Auth0's user profile metadata offers the advantage of immediate availability during and after the login process.

A significant benefit of using metadata is that it is associated with the user's account rather than tied to a specific device. This ensures that if a user switches between the mobile and web versions of your app, their settings and preferences based on metadata will remain consistent across both versions.

Auth0 supports two types of users’ metadata:

- **User metadata:** refers to information the user can see and update, such as user preferences and settings
- **App metadata:** refers to information about the user that is only accessible by the application, for example, feature flags, last read announcement, and more.

Let’s now write a Python script to update the user’s name and metadata to store their preferred theme and an application flag enabling extra features on the user’s account.

```python
# As we did before, we need to get an instance of the Auth0 client
from auth0.authentication import GetToken
from auth0.management import Auth0

domain = 'mydomain.auth0.com'
client_id = 'myclientid'
client_secret = 'myclientsecret'

get_token = GetToken(domain, client_id, client_secret=client_secret)
token = get_token.client_credentials('https://{}/api/v2/'.format(domain))
mgmt_api_token = token['access_token']
auth0 = Auth0(domain, token['access_token'])

auth0 = Auth0(domain, mgmt_api_token)

# Next, we can proceed to update the user's name using the user's id
user_id = '{YOUR_USER_ID}'
auth0.users.update(user_id, {
    'name': 'My name is...'
})

# We can also update the user's metadata
auth0.users.update(user_id, {
    'user_metadata': {
    'theme': 'light'
  },
  'app_metadata': {
    'experimental_features': True
  }
})

# Let's add some more information to see what the end result is
auth0.users.update(user_id, {
    'user_metadata': {
    'font_size': '16px'
  },
  'app_metadata': {
    'notifications': False
  }
})

# Query the user information
user_info = auth0.users.get(user_id)
print(user_info)

# Output
{
    "created_at": "2023-07-14T09:22:19.151Z",
    "email": "###.#####@###.com",
    "email_verified": False,
    "identities": [
        {
            "connection": "Username-Password-Authentication",
            "user_id": "64b113cb6a989b51063087ce",
            "provider": "auth0",
            "isSocial": False
        }
    ],
    "name": "My name is...",
    "nickname": "###.#####",
    "picture": "https://s.gravatar.com/avatar/...",
    "updated_at": "2023-07-14T11:29:53.139Z",
    "user_id": "auth0|64b113cb6a989b51063087ce",
    "user_metadata": {
        "theme": "light",
        "font_size": "16px"
    },
    "app_metadata": {
        "experimental_features": True,
        "notifications": False
    }
}
```

Note that when calling the `update` method, we don’t need to send all the information about the user, but only those fields we would like to change. This makes working with data really simple, as we don’t need to worry about overriding critical fields. Even on the `user_metadata` and `app_metadata` fields, we don’t need to send the full JSON we want to store but rather the individual key-value pairs, Auth0 will automatically merge the existing values with the new ones.

We can also access the user information from the [user’s entry in the Auth0 Dashboard](https://manage.auth0.com/#/users).

![Viewing user's profile and metadata information in the Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/12wH1mxn2Od5hcOQ7SwOTG/d8f45e0725c7eaeeab916bf94a6b9723/auth0-ma-list-user-data.png)

## Query Users

Whether you are building a user dashboard, gathering some statistics, or needing your users’ information to process in your application, the Auth0 Management API and the Auth0 Python SDK allow you to access the information you need and how you need it.

Previously we used the method `users.list` to retrieve a list of all users in the Auth0 database, which may be all that you need. However, that method offers advanced query functions worth knowing and exploring.

First, let’s start with paginating results. By default, paging is disabled. However, you can quickly specify the page and the number of items per page you want to retrieve with these two parameters:

- **page**: Page index of the results to return. The first page is 0.
- **per_page**: Number of results per page.

Here is an example querying the second page of users, up to ten users per page

```python
users = auth0.users.list(page=1, per_page=10)
```

Another common parameter in usage is sorting operations. For this purpose, the SDK exposes the `sort` parameter to specify the field and direction. For example:

```python
users = auth0.users.list(sort="name:1")
```

Use `field:order` where the order is `1` for ascending and `-1` for descending.

Lastly, one of the most powerful functions is the ability to perform complex queries, for example, getting all the users whose names start with `J` or even filtering by custom metadata, listing all the users that prefer the dark mode theme. Auth0 uses [Lucene query string syntax](http://www.lucenetutorial.com/lucene-query-syntax.html) for those complex queries, though there are some limitations, as some query types cannot be used on metadata fields, for details see [Searchable Fields](https://auth0.com/docs/users/search/v3/query-syntax#searchable-fields).

Example 1: List all users whose name starts with `J`

```python
users = auth0.users.list(search_engine='v3', q='name:j*')
```

Example 2: List all users that prefer dark mode

```python
users = auth0.users.list(search_engine='v3', q='user_metadata.theme:dark')
```

You can also mix multiple search criteria, for example:

```python
users = auth0.users.list(search_engine='v3', q='name=j* AND user_metadata.theme:dark')
```

To learn more about how to form queries, check the [Lucene query string syntax](http://www.lucenetutorial.com/lucene-query-syntax.html).

## Selecting a Random User

For the events we attended this year, we created a fun game using Python, Flask, and Auth0 to give some fabulous prizes away to lucky contestants. The game was pretty simple. It consisted of people signing up for our application at events like PyCon. During the day, users registered to the game using the Auth0 Universal Login page. Then, when it was time to give prizes away, we would use the same Flask application to withdraw a lucky winner. The winner would then get a special award from Auth0.

To select the lucky winner, we built a special page using the `users.list` method. There was a caveat: the same user couldn’t win twice. The way we solved it was by using `app_metadata` to store information about the users who had already won and then using Lucene syntax to filter them out when pulling for a new winner.

Though not critical for our situation, we wanted the script to be efficient and thus not pull the whole user’s database, as it could be quite extensive, so instead, we first pulled the API to know how many users were in total with a minimum query, and then we accessed a random user from the pull and extracted only that user’s information.

```python
import random

# List only 1 user just to retrieve the total number of users that match the given query
user_count = auth0.users.list(per_page=1, include_fields=False, search_engine='v3', q='NOT app_metadata.winner:true')["total"]

# Then, use the same trick of listing one user per page to get a random page between 0 and the total number of users
# That resulting user is our lucky winner
winner_user = auth0.users.list(page=random.randint(0, user_count - 1), per_page=1, include_fields=False, search_engine='v3', q='NOT app_metadata.winner:true')['users'][0]

# Before we do anything else with the results, update the user's metadata to reflect them as winner
auth0.users.update(winner_user.get('user_id'), {
    "app_metadata": {
        "winner": True
    }
})
```

## Summary

Today you learned about the Auth0 Management API and how to work with it from the documentation as well as from any Python application. You also learned how to work with user information, user, and app metadata, and how to query users from the Auth0 database using simple and more complex queries.

Thanks for reading!

Use the Auth0 Python SDK for Querying and Storing Users’ Data

Use Auth0’s Management API and account metadata to collect user information a little bit at a time instead of all at once.

Add Progressive Profiling to Auth0 Authentication in Android Apps Built with Jetpack Compose

Andrew Whitman

Andrew is a Customer Identity and Access Management specialist at Okta and loves solving complex identity challenges for his customers. His background in mobile application architecture and development has given him the opportunity to keep pace with the rapid changes that have taken place with authentication over the last 10 years.

Senior Solutions Engineer

Extending core identity functions to fit your application’s unique needs

Identity is a complex domain, and beyond a set of foundational functions, every business has unique needs. But with finite resources (likely already stretched thin by other demands), how can developers build custom solutions that extend and integrate with core identity functions?

Or — put another way — how can development teams do more with less?

To help answer that question, we will explore [Okta Customer Identity Cloud (Auth0)](https://www.okta.com/customer-identity/) Redirect Actions capability with progressive profiling and coupon promotions as two example use cases.

## Actions and Actions Integrations

[Actions](https://auth0.com/docs/customize/actions) are secure, tenant-specific, versioned functions written in Node.js that execute at specific points in identity flows. Actions are used to customize and extend Auth0's capabilities with custom logic, providing developers with the versatility needed to achieve [a wide variety of use cases](https://auth0.com/docs/customize/actions/use-cases).

To accelerate your Identity innovations, the [Auth0 Marketplace](https://marketplace.auth0.com/) includes a long (and ever-growing) list of [Actions Integrations](https://marketplace.auth0.com/features/actions) — partner-built solutions that can be quickly added to extend your identity flow with no-code ease. We recommend looking at the Marketplace before embarking on any custom Actions development because there’s a good chance what you need is already waiting for you.

But, as identity continues to evolve, developers will also have new use cases. And we want to illustrate how Actions can do a lot of heavy lifting as you implement new use cases.

![Build Your Own Integration](https://images.ctfassets.net/23aumh6u8s0i/7hXtS4g7a9TUncVFswrY7Y/bb290371ce4bf09eb9682d1f9c339ea1/01_Build_Your_Own_Integration.png)

## Implementing Progressive Profiling with Redirect

[Progressive profiling](https://auth0.com/docs/manage-users/user-accounts/user-profiles/progressive-profiling) is the process of incrementally collecting additional information about your users as they engage with your website or application. For example, you could collect the user's name, email, and password during sign-up, then ask for their company’s name and job title the next time they log in. This bite-sized approach helps you avoid long sign-up forms that can negatively impact the customer experience (or maybe turn them off your service entirely).

Auth0 [introduced progressive profiling flows in 2020](https://auth0.com/blog/progressive-profiling/#Getting-The-Most-From-Your-Progressive-Profile-Funnel), and we’re happy to see this approach used by modern applications more frequently. But the platform has evolved since the feature debuted, so it’s time to revisit some details on setting up progressive profiling with Actions (versus the original implementation using Rules).

More than that, we also want to highlight how the Redirect flow can apply to more than just onboarding users. Or, put another way, the Redirect feature is powerful, and the progressive profiling use case will help us to illustrate some of its capabilities that developers may have overlooked.

### General approach

Redirects occur during login and allow you to take your user to an external page before granting access to the application. This technique can be useful for progressive profiling because, at this point of authentication, the user has already entered their proper credentials, they have a purpose for visiting the site, and they likely have the intrinsic motivation to answer questions presented to them so they can proceed.

The [Redirect with Actions](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow/redirect-with-actions) documentation goes over this process in detail and discusses the various ways to pass data with this flow. For our purposes, we will use [the front channel approach](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow/redirect-with-actions#send-data-on-the-front-channel) that roughly follows this sequence:

![Front Channel Approach](https://images.ctfassets.net/23aumh6u8s0i/ey2pLXDDxHwWxlgywXv16/5a18cb2bc6c68ed9a4b4f15abbe39bf7/02_Front_Channel_Approach.png)

Within this overall process, the Action flow itself has three main steps:

1. Determining if the Action should execute
2. Preparing, passing, and receiving the data
3. Utilizing the received data

### Action step #1: Determining if the Action should execute

We don’t want to use Redirect every time users access our application, so we need to make sure we have criteria at the start of our Action that will result in it only triggering when appropriate.

The criteria can come in many forms, giving developers precise control over Redirects. Examples include the number of times the user has logged in previously, the last time they received a prompt via a redirect, or the current state of their profile information. 

### Action step #2: Preparing, passing, and receiving the data

To ensure data is exchanged securely with our Redirect application, we first pass over an auto-generated state value and a signed JSON Web Token (JWT).

The signed JWT will use a shared secret to allow the Action to send over additional context to the URL and for the URL to do the same with the data the user has entered. 

### Action step #3: Utilizing the received data

When the user has finished interacting with the Redirect application and is brought back to complete their authentication journey, the Auth0 Action will first validate the state value and inspect the signed JWT.

If everything is valid, the Action can use the newly received data to update the user profile. Next, the Action can determine and flag if additional Redirects are required, after which the login flow proceeds to the next Action or completes the authentication.

### The user experience

Actions can be used to implement anything from simple flows to extraordinarily complex ones, but any complexity takes place behind the scenes. Here’s what the three-step flow above looks like to the end user.

![End User View](https://images.ctfassets.net/23aumh6u8s0i/1eBVWkKnfJ4d6KXv7d5HDY/021339a816c968f0ae2aab672b5b5237/03_End_User_View.png)

### Redirects to improve cart transactions

In addition to acquiring customer information and preferences, e-commerce sites can also utilize Redirect to help drive conversions — for example, by adding a coupon incentive when a user logs in for the first time and verifies their email.

Since Actions has context on the authenticating user and session, we can redirect to additional pages (e.g., a coupon code alert) to ensure the user is aware of the promotion and to encourage them to complete their first transaction.

And importantly, Actions can store (within a user’s profile) data that is exchanged during these Redirects, enabling other applications functions to interact with it. 

![Redirect end user](https://images.ctfassets.net/23aumh6u8s0i/TRrNbjiSqOljtxBFXKuWx/92f1ab43e68132302d42426514c9bf0b/04_Redirect_end_user.png)

## Let’s Dive In

Now, let’s build our own Redirect Action in our tenant.

This demo requires the following:

1. An Auth0 tenant (sign up and create one [here](https://manage.auth0.com/))
2. A remixed copy of [this Glitch App](https://glitch.com/edit/#!/okta-cic-pp-demo)
3. The following [Login Action code](https://github.com/awhitmana0/cic-redirect-actions/blob/main/redirect-intro-profile-data.js):

![action_example_1](https://images.ctfassets.net/23aumh6u8s0i/3aKYVGUzqjj3gIYehtsHS6/199a048f76b63a0010504693ba0b98b1/05_action_example_1.png)

### Instructions

1. Go to [**https://glitch.com/edit/#!/okta-cic-redirect-actions**](https://glitch.com/edit/#!/okta-cic-redirect-actions) and remix the app. Copy your remixed URL so we can add it to our Action.

![glitch-url-example](https://images.ctfassets.net/23aumh6u8s0i/iCyB2jcLxxgUOxTO7ABiM/9b5204fd30f2d581804607126908ec48/06_glitch-url-example.png)

2. We will use environment variables to configure this template to work with our application. 
 1. **Shared secret**: You will need to generate your own secured shared secret that only your app and tenant can access. Generate a string for `APP_SECRET_KEY` using openssl rand -hex 32 from your shell.
Take note of this value so we can add that to our Action and redirect page.
 2. **Auth0 Application domain, secret, client ID**: These can be found in your Auth0 tenant settings and will be set under `AUTH0_DOMAIN`, `AUTH0_CLIENT_SECRET`, `AUTH0_CLIENT_ID` respectively.
(Note: If you are linking from an existing app, you can ignore this step.)

![Glitch Environment Variables](https://images.ctfassets.net/23aumh6u8s0i/42UMb4cNEmrJrxTALZhFmJ/dde8474c199605a7fc9c4d910cd42540/07_Glitch_Environment_Variables_.png)

3. Copy the Action code from the starting section.
4. Create a new custom [login flow](https://auth0.com/docs/customize/actions/flows-and-triggers/login-flow) Action in your Auth0 tenant.
5. Paste the code copied in step 3 into your new login flow Action.
6. [Create two new secrets](https://auth0.com/docs/customize/actions/write-your-first-action#add-a-secret): `FORM_URL` and `SESSION_TOKEN_SECRET`. <br>
Set `FORM_URL` = `https://NEW-GLITCH-URL/prog/universal` <br>
Set `SESSION_TOKEN_SECRET` = secret created in step 2a <br>
7. Save and deploy the Action and add it to your login flow.
8. COMPLETE: Test your new login Redirect flow by signing up a new user!

## Extending the Flow: Checking Marketing Preferences

Since Actions are composed of code, we can build more complex use cases in our Auth0 environment.

This sample Action is set up to be extremely flexible and to let the receiving URL act as an empty vessel to display forms, and the configuration and theming of the page can all occur within the Action itself. In practical terms, this means that you can use the same URL with multiple different Actions to achieve different functionality.

For example, by slightly modifying the original Action, we can easily create a “marketing preferences check” that only triggers on the third login:

![Marketing permissions check](https://images.ctfassets.net/23aumh6u8s0i/ylYXM36ZyCWJXNOm1nfy0/8d9a06472cbafb2f157d87d4f234d2fb/08_Marketing_permissions_check_.png)

Use the [following Action code](https://github.com/awhitmana0/cic-redirect-actions/blob/main/redirect-marketing-consent.js).

![action_example_2](https://images.ctfassets.net/23aumh6u8s0i/4a3A2QV5JlY129nSA5FqJ7/8e794621354a1bd90e8c34255634aa9f/09_action_example_2.png)

<include src="Vidyard" id="iHp52FNwzSGRQGpW4pnFLb" />

## Only the Beginning...

The examples above represent only a fraction of what’s possible, as the Redirect capability can enable much more functionality that you may wish to leverage during a user’s authentication flow. For example, the same pattern can be used to:

* Require Identity proofing;
* Implement consent management;
* Integrate with customer data platforms;
* Trigger MFA protections; and
* Enable Web3 and decentralized identity
* Plugin data to the underlying connected system
* Prevent fraudulent user access
* Enrich uUser profiles
* and more

And Redirects are themselves only a small part of the larger set of Actions capabilities. Auth0 Actions open a large possibility of very sophisticated identity workflows that can be powered, hosted, and protected by Auth0. In addition, Auth0 Actions help to achieve many possible use cases throughout the sign-in flow; before, during, and after sign-in.

By design, the Auth0 platform is built so you can use Actions to solve a variety of problems that are unique — whether broadly or in the smallest details — to you.

Identity as a domain may be hard, but extending the Customer Identity Cloud’s core functions to meet your application’s specific needs is easy.

## Integrate with Auth0

Learn everything you need to know about our extensibility features, build your own solution, plus understand the process all the way to publishing. We’ve got you covered with helpful docs and resources. Visit [auth0.com/integrate](http://auth0.com/integrate) to learn more.

Using Redirect with Actions to Gather User Info and Increase Conversions

How Hypotenuse AI Uses Auth0 to Streamline User Onboarding

[Hypotenuse AI](https://www.hypotenuse.ai/) is an artificial intelligence platform that helps you optimize your business processes. The goal of the Hypotenuse AI platform is to reduce manual labor and automate the tedious, time-consuming tasks associated with business processes. It automates decision-making and analysis by providing intelligent solutions and insights, allowing you to make better decisions faster. 

_Can we let you in on a little secret? We used Hypotenuse AI to write the paragraph above._

The AI-driven technology is designed to help companies save time and money by automating routine tasks and customer interactions. With its powerful algorithms, Hypotenuse AI can analyze customer data to provide timely and accurate customer service. It can also deliver personalized product recommendations to customers that match their preferences, needs, and budget.

_That paragraph was written by Hypotenuse, too._

> “We’re not aiming to replace humans. I don’t think anything will ever replace that level of creativity, direction, and strategy that you need from a human to drive a content process and to really drive what a brand wants to talk about. But, it’s more of a tool to get the grease into the cogs so that things move a bit smoother.” - Low Lin-Hui, Co-Founder.

## The Origins of Hypotenuse

We sat down with [Low Lin-Hui](https://sg.linkedin.com/in/lowlinhui), Co-Founder, to learn more about Hypotenuse AI and the growing artificial intelligence industry. The platform started as a chat function that helped customers search on e-commerce websites and has evolved into a robust suite of content tools. “What we’re trying to put together is this holistic, start-to-finish content creation process,” said Lin. She shared that this product is for companies looking to streamline content production. Some of their products and features include [a content detective](https://www.hypotenuse.ai/features/content-detective), [blog articles](https://www.hypotenuse.ai/ai-article-writer), [Hypo Art](https://www.hypotenuse.ai/ai-image-generator), [Instagram captions](https://www.hypotenuse.ai/instagram-caption-generator), and even [rewriting support](https://www.hypotenuse.ai/paraphrasing-tool). At this point, we’re thinking, what can’t Hypotenuse AI do?

Hypotenuse AI initially envisioned their audience as enterprise customers that wanted a tailored solution, and while they do serve many [notable enterprise customers](https://www.hypotenuse.ai/), there was also demand for a self-service option. They saw a lot of interest in simple products that people could use immediately, even if these products weren’t always customized to a specific brand voice or use case. They currently offer two self-service plans that you can try for free. 

## Deploying Secure Authentication with Auth0 

When the team was looking for an authentication solution, they were trying to find something that was fast, secure, and reliable. On top of being customizable, it was important to Hypotenuse that their solution had a commitment to [user privacy and data protection](https://auth0.com/security). Auth0 fits the bill.

Hypotenuse AI started to use Auth0 when they opened their product to subscriptions. As they grew, they needed to programmatically add pre-user registration validation processes. They were able to solve this by using [Actions](https://auth0.com/blog/introducing-auth0-actions/) and Flows. This automated solution handles the majority of user onboarding tasks, ultimately saving the team time and effort. “Overall, Auth0 has allowed us to significantly enhance the performance of our login UX and streamline our user onboarding.” 

![Checklist](https://images.ctfassets.net/23aumh6u8s0i/2c5CVLNi3wSpLnjXE7Bn0N/f4bd1b473c1a3788e76987476304eabd/Checklist-1.png)

## Join Hypotenuse AI and the Other 1700+ Startups That Benefit from Auth0

The [Auth0 for Startups](https://auth0.com/startups) program brings the simplicity, extensibility, and scalability of Auth0 to qualifying startups – **all free for one year**. We are passionate about helping startups get their applications up and running while we take care of identity needs. So much so that we recently [expanded our eligibility](https://auth0.com/blog/auth0-for-startups-expands-eligibility/) by increasing the funding limit to $5M, doubling our previous cap. If you have any questions, you can find us at [startups@auth0.com](mailto:startups@auth0.com) or apply [here](https://autheco.atlassian.net/servicedesk/customer/portal/4/group/9/create/53). 

A special thank you to Lin, the entire Hypotenuse AI team, and Hypotenuse AI for helping us write this profile. If your organization is looking to create content in seconds, [get started](https://www.hypotenuse.ai/) today. 

_This profile is the first installment in our series highlighting members of the Auth0 for Startups program. The Auth0 for Startups program began in 2020 and has since worked with 1700+ startups._

Startup Stories: Hypotenuse.ai

Come and learn what you can do as a developer to keep your app users' identities safe.

**Developer Day** is back! Okta's event for developers will take you into the world of Identity to repeat last year's success.

This year's event will be **virtual** and take place over two days, **May 16th and 17th**, with two themes: "**Take Control of Identity**" and "**Enterprise Readiness**". Come and learn how to put your users in control of their identities and provide a great user experience with your applications. You will learn how the Identity space is evolving and what technologies and best practices are available to grant security for your user identities.

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

The event is **free**. Designed  **by developers for developers**, it will feature inspiring keynotes and hands-on sessions from industry leaders. You'll meet Okta team members who will answer your questions and guide you through online workshops.

Each of the two days will focus on one of Okta's offerings. On **May 16th**, the focus will be on **Customer Identity Cloud (Auth0)** and the "Take Control of Identity" theme. On **May 17th** the focus will be on **Workforce Identity Cloud** and the "Enterprise Readiness" theme. The event will be live-streamed from the Okta New York City Experience Center and the Okta San Francisco Headquarters.

![Developer day 2023](https://images.ctfassets.net/23aumh6u8s0i/27maf1AqRqeGjVY5rL4swF/f37146eaf7e8c906838706531a3907b0/developer-day-2023.png)

Just because it's virtual doesn't mean you can't connect with other developers and Okta people. You can enjoy your Developer Day in four cities around the world: **Toronto**, **London**, **Frankfurt**, and **Sydney**. Join your local community and celebrate your Developer Day!

[Register](https://developerday.com/register/?utm_source=auth0_blog&utm_medium=sc&utm_campaign=blog_announcement) today to make sure you don’t miss this opportunity to learn about Identity evolution from experts! And keep an eye on the [Developer Day website](https://developerday.com/?utm_source=auth0_blog&utm_medium=sc&utm_campaign=blog_announcement) for the agenda and more information.


Join Developer Day 2023!

amin-abbaspour

G'day. I look after Professional Services in APAC. I'm passionate about helping customers build and secure their applications and get the best value out of their investment with Auth0. Besides work, I love spending time with my kids, Ryan and Adeline, as well as reading, weightlifting and watching NRL (National Rugby League).

Lead Solutions Architect

Amin Abbaspour

Learn how to add user authentication to Flutter apps using OAuth 2.0 and OpenID Connect.

Get Started with Flutter Authentication

Ruchita Shah

Ruchita is a Product Marketer for Okta’s Customer Identity products. With an engineering and product marketing background, she is focused on showcasing how organizations can create secure and seamless digital experiences for their end users using Okta’s identity products. She spends her spare time hiking, reading and watching Formula1

Senior Product Marketing Manager, Customer Identity

The Auth0 React Native SDK v2.16.0 improves both developer and the user experience

We’re excited to announce the released version 2.16.0 to our Auth0 React Native SDK. Major features we delivered in this release include:

* Expo support
* Hooks API
* Secure Credentials Manager

## Support for Expo

Expo is a popular framework that adds a suite of features to React Native apps. We have added support for this tooling to make it much easier to work with our SDK in conjunction with Expo, as it provides a [number of benefits](https://www.mozestudio.com/journal/what-is-expo-and-why-it-matters-for-app-development/) when used to build React Native apps.

We added this support in response to growing customer demand. We received various feedback across our channels that indicated to us that this would be a valuable addition to our SDK. In an excellent demonstration of the power of open-source software, our implementation actually started life as a pull request from the community, which was able to review, tidy up, and merge into our codebase for the benefit of others. 

Given Expo’s growing popularity among the React Native community, it was clear this was an opportunity to provide first-class support in the SDK. To that end, we also now provide an [Expo-specific quickstart](https://auth0.com/docs/quickstart/native/react-native-expo/interactive) in addition to our standard React Native quickstart so that developers can get up and running even quicker.

## New React Hooks API

This release adds support for using the SDK using[ React Hooks](https://reactjs.org/docs/hooks-intro.html). This was primarily driven by our own desire to modernize the SDK and provide an API that felt more natural to modern React developers. React Hooks have been in React Native 0.59 (released around March 2019). Our hooks wrap our pre-existing WebAuth classes, so the developer can choose to use Hooks or to continue using the provided classes should they wish.

In addition, we updated our [React Native quickstart](https://auth0.com/docs/quickstart/native/react-native/interactive) to use the new Hooks API by default.

![New React Hooks API](https://images.ctfassets.net/23aumh6u8s0i/5mdxN3EK60eYe1LS3E9jP5/90150f525eea0d0209ba87c50753d14d/react-sdk.png)

### How to use the new Hooks API

Previously, the developer could instantiate a class and use the properties and methods provided to implement authentication into their apps.

```js
import Auth0 from 'react-native-auth0';
import jwt_decode from 'jwt-decode';
 
const auth0 = new Auth0({
     domain: 'YOUR_AUTH0_DOMAIN',
     clientId: 'YOUR_AUTH0_CLIENT_ID',
});
  
const App = () => {
 
   let [user, setUser] = useState(null);
 
   const onLogin = () => {
       auth0.webAuth
           .authorize({
               scope: 'openid profile email'
           })
           .then(credentials => {
                 const payload = jwt_decode(credentials.idToken);
                 setUser(payload)
           })
           .catch(error => console.log(error));
   };
 
   return (
       <View>
         {!user && <Button onPress={onLogin} title="Log in" />}
         {user && <Text>Logged in as {user.name}</Text>}
       </View >
   );
}
 
export default App;
```

Now, the developer can use Hooks to implement login, providing an idiomatic way to implement reactive code in a React Native app using function components:

```js
// App.js
import {Auth0Provider} from 'react-native-auth0';

const App = () => {
  return (
    <Auth0Provider domain="YOUR_AUTH0_DOMAIN" clientId="YOUR_AUTH0_CLIENT_ID">
      {/* YOUR APP */}
   </Auth0Provider>
 );
};
```
```js
// Component.js
const Component = () => {
    const {authorize, user} = useAuth0();
   
    const login = async () => {
      await authorize();
    };
   
    return (
      <View>
        {!user && <Button onPress={login} title="Log in" />}
        {user && <Text>Logged in as {user.name}</Text>}
      </View>
    );
   };   
```

## Secure Credentials Manager

Up until this release, the developer was in charge of storing and managing the tokens that were returned to the app from Auth0 without any assumptions from the SDK as to how and where tokens were stored. Now, we provide a built-in secure credentials manager that automatically stores these tokens.

This was another feature that was driven by community asks but one that makes a lot of sense if we’re interested in making things as frictionless for the developer as possible. We had a number of requests across our channels for this, and we’re pleased to be able to provide it as a first-class addition to the SDK

This mechanism uses the thoroughly tested credentials manager instances provided by [Auth0.Swift](https://github.com/auth0/Auth0.swift/) and [Auth0.Android](https://github.com/auth0/Auth0.Android).

Automatically refreshes the access token when it expires.

Automatically stores and clears tokens when using the Hooks API.

Support for platform-specific Biometric Authentication

## Summary

The Auth0 React Native SDK v2.16.0 improves both developer and the user experience. On the one hand, it provides flexibility for developers to be up and running in less time. On the other hand, it provides a more secure credentials manager that can automatically manage tokens.

For further reading: [Introducing the Auth0 Flutter SDK](https://auth0.com/blog/introducing-the-auth0-flutter-sdk/)

Introducing Auth0 React Native SDK v2.16.0

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

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

Learn how to add login, logout, and sign-up to Vue.js using a plugin, how to create vue-router guards, and how to make secure API calls from a Vue.js app.

The Complete Guide to Vue.js User Authentication with Auth0

Learn how to add user authentication to Angular using Observables and HTTP Interceptors.

The Complete Guide to Angular User Authentication with Auth0

Learn how to add user authentication to React using Context and Hooks

The Complete Guide to React User Authentication with Auth0

Samuel Frank

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

Senior Product Manager

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

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

## Unstoppable Domains

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

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

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

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

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

## Web3 Signal Sign-On

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

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

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

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

## How It Works

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

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

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

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

## What's Next?

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

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


Sign in with Unstoppable Domains, Now on Auth0 Marketplace

Salman Ladha

As a Product Marketing Manager, I’m responsible for communicating the value of identity for SaaS application builders and our public sector vertical. I’m particularly passionate about the role identity plays in accelerating business growth, promoting product adoption, and establishing trust. Outside of work, you can catch me reading, working out, or watching the latest Marvel movie.

Senior Product Marketing Manager

Increase user security, convenience, and privacy by enabling authentication using device biometrics

A future where passwords no longer exist may be right around the corner—for real, this time.

Earlier this year, ironically, on [World Password Day](https://www.firstpost.com/world/world-password-day-2022-history-and-importance-of-passwords-in-current-times-10635471.html), Apple, Google, and Microsoft collectively announced plans to [extend their support](https://www.forbes.com/sites/davidbirch/2022/07/25/thanks-to-apple-microsoft-and-google-passwords-will-finally-die/?sh=31f8e4a92072) for passwordless authentication, building from the specification created by the [FIDO Alliance](https://fidoalliance.org/specifications/#:~:text=FIDO%20UAF%20supports%20a%20passwordless,%2C%20entering%20a%20PIN%2C%20etc.) and the [World Wide Web Consortium (W3C)](https://www.w3.org/2019/03/pressrelease-webauthn-rec.html.en). Through a technology called [Passkey](https://www.trustedreviews.com/explainer/what-is-passkey-4231178), users will be able to authenticate into compatible websites and applications by taking the same action they use to unlock their phones. This eliminates the need to remember a password. 

For any consumer-facing business where digital engagement has become a crucial component of the [customer experience](https://www.pwc.com/us/en/zz-test/assets/pwc-consumer-intelligence-series-customer-experience.pdf), this announcement highlights an important technology trend for future innovation in their overall customer identity and access management (CIAM) strategies. Most consumers don't like remembering hundreds of passwords, so this is a prime opportunity to promote the adoption of passwordless authentication. 

In light of that, we thought we’d break down a handful of common misconceptions associated with passwordless authentication, specifically using device biometrics, as we gear up for a future where arbitrary strings of characters will perhaps take a back seat in how we log in.

![Passwordless Misconception](https://images.ctfassets.net/23aumh6u8s0i/50DnWYiAPCa18mVZOfrOBP/c29ceb90bd492ae124f89ff23ca1f237/Debunking_Misconceptions_About_Passwordless_Separator_V01_3x.jpg)

## Misconception #1: Passwordless Is Not Secure

Since its inception in the 1960s, the username and password challenge has been the de facto experience for how we log in to applications. As a result, it's only natural to feel like anything without a password is insecure. The reality is that we've been tricked into a false sense of security. 

When we look at the data, passwords consistently pose security challenges. [Nordpass](https://nordpass.com/most-common-passwords-list/) highlights that the average consumer must remember around 100 passwords for all their online accounts. Due to the sheer volume of credentials, we have to remember [that 86% of consumers admit to reusing a password](https://info.auth0.com/expectation-vs-reality_confirm.html), which presents a massive opportunity for attackers. 

The [2022 Verizon Data Breach Investigation Report](https://www.verizon.com/business/resources/reports/dbir/) found that almost half of all data breaches start with stolen credentials. Unfortunately, the financial and social cost of these breaches can cost a business an average of [six million dollars annually](https://www.akamai.com/lp/report/ponemon-the-cost-of-credential-stuffing-report). In an environment where password reuse among consumers is the norm, cybercriminals are capitalizing on poor behavior, and companies are suffering the consequences, passwords are proving to be a less than ideal form of authentication. 

Passwordless authentication using [WebAuthn](https://webauthn.guide/) (a specification written by W3C and FIDO) device biometrics presents a unique solution to this problem as it's effectively a two-factor authentication experience. Rather than having users authenticate based on something they know, they log in using something they have (the device) and something they are (their biometric information). This is why some sources go as far as saying passwordless authentication with WebAuthN device biometrics is the only standards-based authentication method that is [unphishable](https://www.w3.org/2018/Talks/06-WebAuthn.pdf). 

>💡 <span style="text-decoration:underline">Reality</span>: Passwordless authentication using device biometrics is actually more secure than username and password credentials because it's a 2FA experience. 

## Misconception #2: Passwordless Doesn't Benefit the Business

On the surface, the relationship between passwordless authentication and business value might not be obvious. The friction consumers experience is the key to debunking this myth. CIAM has evolved from being seen as a cost center line item to a revenue-generating activity due to the positive impact it can have on increasing user conversions as consumer applications have become ubiquitous and central to most aspects of everyday life, [every signup and sign-in is a built-in opportunity](https://auth0.com/resources/whitepapers/CIAM-conversion-retention) to engage with customers.

Historically, identity was solely the responsibility of IT teams. Now that customer identity offers an opportunity to provide seamless experiences at every touchpoint in the customer journey, it has become the responsibility and consideration of sales and marketing teams as well. If a customer is frustrated by the signup process, as [83% of respondents](https://info.auth0.com/expectation-vs-reality) are, according to an Auth0 survey, these customers will abandon what they're doing in search of a friction-free registration and login process. 

Revenue is on the line; [88% of online shoppers](https://www.smallbizgenius.net/by-the-numbers/ux-statistics/#gref), for example, report that they would not return to a website after having a bad experience. A good experience starts from the first click, and passwordless frees users from having to create yet another username and password—[a source of frustration for 53% of global consumers](https://www.intelligentcio.com/apac/2021/05/06/auth0-survey-reveals-frustrations-with-password-management/).

> 💡 <span style="text-decoration:underline">Reality</span>: Passwordless authentication can help grow top-line revenue by offering a superior customer experience. 

## Misconception #3: Passwordless Introduces Data Privacy Concerns

From both a financial and brand reputation perspective, businesses need to be sure that they meet the ever-changing and demanding requirements of data privacy laws. [Google Trends data](https://trends.google.com/trends/explore?date=all&q=data%20privacy) shows that search inquiries for "data privacy" have climbed 53% in the past decade. This aligns with heightened consumer and government concerns about how businesses collect and monetize personal data. [Sixty-nine percent of consumers](https://www.internetsociety.org/resources/doc/2019/trust-opportunity-exploring-consumer-attitudes-to-iot/) are worried about how their personal information is used by organizations. At the same time, governments around the world continue to introduce new laws and regulations designed to protect citizens' personal information, [increasing globally from 10 to 144 in 2021](https://iapp.org/news/a/report-efforts-toward-data-localization-increasing-globally/)—the California Consumer Privacy Act (CCPA) and the European Union's General Data Protection Regulation (GDPR) are two examples. 

Given the rapidly evolving nature of this area—and the [steep financial consequences](https://www.tessian.com/blog/biggest-gdpr-fines-2020/#:~:text=The%20EU%20General%20Data%20Protection,financial%20year%E2%80%94whichever%20is%20higher.) for infringing on the law—there might be some apprehension about adopting passwordless authentication using device biometrics. The concern revolves around how organizations handle (e.g., store and secure) biometric data. Fortunately, the WebAuthn specification forces all biometric data to be used as a private key to be contained within the device. Users never hand over their biometric information to the application they're accessing. From a hardware perspective, some companies take it a step further by employing[ dedicated subsystems](https://support.apple.com/en-ca/guide/security/sec59b0b31ff/web) to segregate sensitive data. 

> 💡 <span style="text-decoration:underline">Reality</span>: Using WebAuthn, businesses do not have to worry about handling biometric data. The specification demands that biometric data be contained within the device being used. 

## Misconception #4 - It's Difficult to Encourage Users to Use Passwordless

Humans are hard-wired to resist change, especially when that change threatens our security. Though the adoption of passwordless is a[ long way away from being ubiquitous](https://www.forbes.com/sites/forbestechcouncil/2021/11/23/whats-blocking-the-adoption-of-passwordless-authentication/?sh=7cbf808077f1) with authentication, businesses can take a few steps to gradually prime and convert users to authenticate into applications using their biometric information. 

From a design perspective, changing the way you look at the login flow can have a strong impact. Instead of the usual username and password challenge, opt for an[ identifier-first flow](https://auth0.com/docs/authenticate/login/auth0-universal-login/identifier-first) to slowly change user behavior. With an identifier-first approach, users are first asked for an identifier, such as email address, phone number, or member ID. From there, they can select an authentication option that works best for them, such as biometrics, a magic link, or even a password. It's a slight change but one where users are actually empowered to choose an option they feel comfortable with. 

From an education perspective, communicating the value of passwordless authentication for what it is—minimum friction with maximum security—is also a great start. Not only does it offer a seamless two-factor authentication experience, it's also more convenient. Our own data shows that WebAuthn has a[ better completion rate (95%) than other authentication methods, but it also has a lower time to complete (5 seconds)](https://auth0.com/blog/mfa-with-webauthn-for-fido-device-biometrics-now-available/). 

> 💡 <span style="text-decoration:underline">Reality</span>: Product design and education are two avenues to promote the adoption of passwordless authentication with users. 

## Misconception #5 - It's Too Hard to Go Passwordless

Because passwordless authentication is contingent on getting CIAM right in the first place, there is some truth to this misconception. Identity is inherently complex. Burdening your developers with this additional responsibility that draws their focus away from core product innovation might be met with frustration—especially if you've built an identity system in-house. Working with a CIAM provider who solely focuses on identity is one way to get started with passwordless authentication today.

> 💡 <span style="text-decoration:underline">Reality</span>: Partnering with an Identity-as-a-Service (IdaaS) provider dedicated to CIAM can accelerate your journey to going passwordless.

![Passwordless Misconception](https://images.ctfassets.net/23aumh6u8s0i/4EmRhsgk2yQw5l21Xqwbr7/a99be0023a811661bb7e7e02784d0b53/Debunking_Misconceptions_About_Passwordless_Separator_V02_3x.jpg)

## Get Started with Passwordless

At Auth0, we work with companies around the world to deliver seamless yet secure login experiences. Our platform is a developer-friendly authentication and authorization solution. Built on a set of composable building blocks, exposed through APIs and protocols, the Auth0 Identity Platform provides the creators within your business to tackle any customer identity use case. 

Importantly, you'll be able to implement the latest, most innovative identity capabilities into your applications to the benefit of your customers without burdening your developers. Whether it's [ Adaptive MFA](https://auth0.com/multifactor-authentication),[ WebAuthn](https://auth0.com/docs/secure/multi-factor-authentication/fido-authentication-with-webauthn), or[ Social Login](https://auth0.com/blog/how-to-use-social-login-to-drive-your-apps-growth/), you can provide the identity experience that makes sense for your customers with the flip of a switch—it's actually a radio toggle, but you get the idea.                          

With the right identity solution, you can make incremental changes to your customer's login experience and rack up wins with passwordless authentication. 

If you're interested in learning more about how Auth0 can help your organization on its way to a passwordless future,[ reach out to our team. ](https://auth0.com/contact-us)

<include src="asides/AboutAuth0" />