SamanthaMurphy2025

Samantha Murphy is a Product Marketing Senior Manager for Auth0. 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.

Senior Manager, Product Marketing, Auth0

Samantha Murphy

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

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

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

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

## Moving Beyond Less Secure Security Questions and OTPs

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

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

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

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

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

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

Let’s walk through an example workflow.

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

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

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

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

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

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

## Achieving Better Business with CIBA

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

### Stronger Security and Privacy

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

### A Financial-Grade Protocol

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

### Non-Repudiation for Trust

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

### Enhanced Customer Experience (CX)

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

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

## CIBA in Action: Real-World Examples

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

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

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

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

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

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

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

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

andrea-chiarelli

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

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

Principal Developer Advocate

Andrea Chiarelli

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

Add Auth0 Authentication to Blazor Hybrid Apps in .NET MAUI

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

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

## When a Client Secret Is Not Enough

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

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

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

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

## Private Key JWT Authentication

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

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

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

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

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

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

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



## Highly Regulated Identity and Private Key JWT Authentication

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

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

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

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

## The Sample Project

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

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

You will get two .NET projects:

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

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

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

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

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

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

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

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

## Create and Register Your Public Key

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Get Your Access Token

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

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

```json
// HealthCheckWebApp/appsettings.json

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

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

```csharp
// HealthCheckWebApp/Program.cs

// ...existing code...

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

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

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

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

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

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

## Credential Rotation

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

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

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

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

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

## Summary

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

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

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

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



Use Private Key JWTs to Authenticate Your .NET Application

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 and Python.  

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. 

Staff Developer Advocate

Carla Urrea Stabile

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

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

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

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

## What is a Passkey?

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

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

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


## The Passkey Lifecycle

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

### Creation 

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

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

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

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

### Read

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

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

### Update

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

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

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

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

### Delete

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

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

<include src= "LearnPasskeysCTA"/>

## List Passkeys with Auth0

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

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

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

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

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

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

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

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

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

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

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

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

## Revoke a Passkey in Auth0

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

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

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

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

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

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

## Summary 

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

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

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 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

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

matt-raible

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

Developer Advocate

Matt Raible

Learn how to build a Spring Boot application that authenticates against Okta and Auth0 with Spring Security's SAML support.

Get Started with Spring Boot and SAML

sandrino-di-mattia

Principal Architect

Sandrino Di Mattia

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

Juan Cruz Martinez

Learn how (and where) to authenticate your user in the different deployment models that exist for Next.js

The Ultimate Guide to Next.js Authentication with Auth0

asehmi

I work with a few tech start-ups providing technical strategy and product development advice and seed investment. I've rediscovered the joys of hands-on software development and actively engage with various developer communities to learn myself and educate sharing what I know. Previously, I was CIO at Oxford Economics for 10 years bringing 25 years’ prior experience in capital markets and high-technology software industries, enterprise software architecture and solutions development. Before that I spent eight years at Microsoft as a global business manager and award-winning software architect and technical evangelist. <br>
Earlier in my career, I was CTO at a start-up building advanced social media analytics products followed by a couple of years as an executive coach and mentor, and IT change management and strategy consulting to a number of small and medium sized businesses.

Startups Strategy Advisor

Arvindra Sehmi

In this article, I will show you how to build a Streamlit Component to authenticate users in Streamlit applications and external APIs with Auth0.

Streamlit User and API Authentication with Auth0 Next.js SDK

dan-lourenco

Guest Author

Dan Lourenco

Learn how to programmatically authenticate against Auth0 in your Cypress tests in a manner that adheres to both Cypress and Auth0 best practices.

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Important Announcement</strong><br> 
  <b>This blog post is no longer maintained and it may be out of date</b>. Please use the following resources created by the Cypress team to learn how to use Cypress to test a Single-Page Application (SPA) that uses Auth0: 

  * <a href="https://cypress.io/blog/2022/04/25/cypress-9-6-0-easily-test-multi-domain-workflows-with-cy-origin/">Cypress 9.6.0: Easily test multi-domain workflows with cy.origin</a> (Blog post)
  * <a href="https://www.youtube.com/watch?v=Fohrq5GZSD8">How to test multiple domains or origins with Cypress</a> (Video) <br>

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

**TL;DR:** This post discusses how to authenticate against Auth0 in your Cypress end-to-end tests successfully. You will use a small sample React application to illustrate patterns you can use to programmatically log your user into Auth0 while running Cypress tests, in a manner that adheres to most Cypress and Auth0 best practices. To see a working example of the techniques described in this article, please feel free to clone [this repo](https://github.com/dlo83/auth0-cypress-demo).

<include src="TweetQuote" quoteText="Learn how to perform end-to-end integration tests on SPAs secured with Auth0."/>

## Prerequisites

As mentioned, you will be using a React application written with modern JavaScript language features (ES2015+), so a good understanding of modern web technologies is recommended. If you’re not quite there yet, there are a wealth of fantastic resources for modern JS development, including courses from [Wes Bos](https://es6.io/), [Tyler McGinnis](https://tylermcginnis.com/), and others.

You will also need to have Node.js and NPM installed. [Check out the Node.js website](https://nodejs.org/en/download/) for download links and an installation guide.

You are also expected to have an Auth0 account and have valid user permissions so that you can authenticate into your application. So, if you don't have an Auth0 account yet, <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 now</a>.

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

Lastly, a basic understanding of what Cypress is and why it’s useful is expected. If you do not know Cypress, check out [this article](https://auth0.com/blog/cypress-write-automated-tests-to-validate-web-applications/) for more.

## Auth0 Setup & Configuration

To see the whole process in action, you will need to create an Auth0 Application on your Auth0 dashboard. To do so, head to [the Applications section of your dashboard](https://manage.auth0.com/#/applications) and click on the _Create Application_ button. When you click on this button, you will see a dialog. On this dialog, you will have to add a name for your application (e.g., "Cypress E2E Testing") and you will have to select _Single Page Web App_ as its type.

Now, clicking on the _Create_ button will make Auth0 redirect you to the _Quick Start_ page of your new application. From there, you can head to the _Settings_ tab and configure it as follows:

* Scroll down to the _Allowed Callback URLs_ field and enter in the following value: `http://localhost:3000/callback`. After user authentication occurs, Auth0 will only redirect successfully if the route in question is listed here.
* Enter `http://localhost:3000` into the **Allowed Web Origin** field.
* Enter `http://localhost:3000` into the **Allowed Logout URLs** field.
* Scroll down to the bottom of the **Settings** page and click **Show Advanced Settings**.
* Click on the **Grant Types** tab, and check the **Password** grant.
* Click **Save Changes**.

Now, you can create a user account for the end-to-end testing scripts. To do so, head to [the _Users_ section of your dashboard](https://manage.auth0.com/#/users) and click on _Create User_. On the dialog shown by Auth0, fill the form as follows:

* _Email_: Enter a random email address (e.g., `e2e-testing@mydomain.com`)
* _Password_: Enter a random password (e.g., `s#m3R4nd0m-pass`)
* _Repeat Password_: Enter the same password.
* _Connection_: Use the `Username-Password-Authentication`

After that, click on _Save_ to finish the process.

Lastly, you will have to go to [your tenant's settings](https://manage.auth0.com/#/tenant) and set `Username-Password-Authentication` as the value of the _Default Directory_ property. As mentioned in this page, this field defines the "name of the connection to be used for Password Grant exchanges". In this case, the `Username-Password-Authentication` value comes from the default the default [_Database Connections_](https://manage.auth0.com/#/connections/database) that Auth0 adds to all new tenants.

![Auth0's default database connection.](https://images.ctfassets.net/23aumh6u8s0i/WIYNDHA9YBusXqhZJn13E/f3750b39784c88804197a33f7b728e5b/auth0-default-database-connection)

Just don't forget to save the changes made to your tenant.

## The Sample App

First things first, clone [this repo](https://github.com/dlo83/auth0-cypress-demo) and check out the `base` branch:

```bash
# clone the repo
git clone https://github.com/dlo83/auth0-cypress-demo.git

# move into it
cd auth0-cypress-demo

# checkout the base branch
git checkout base
```

> **Note:** You can also refer to the finished product on the `master` branch. Then, be sure to `npm install` and `npm run start` in your terminal to spin up the application.

This app will be quite simple: it is a React application with a few routes, powered by React Router 4. One of the routes will be protected — that is, only accessible for authenticated users — and the other, public.

There will be one other route which serves an important purpose: the `/callback` route. This route is where the user is redirected after successfully entering their Auth0 credentials. When this route is hit, the application checks to ensure that the state information in the URL's query string matches the state stored in the persisted cookie.

If these protected route patterns are unfamiliar to you, I highly recommend checking out [Bruno Krebs' article](https://auth0.com/blog/react-tutorial-building-and-securing-your-first-app/) for more.

## Cypress

Cypress is a modern front-end testing tool that makes writing integration tests a breeze. This tool is, essentially, a one-stop shop for all your end-to-end testing needs, combining a _fast_, state-of-the-art testing framework, graphical and headless test runners, and easy-to-use assertion library in one package.

### Authentication with Cypress

So you’re sold on Cypress and you’re using Auth0 for your authentication needs. Now, it is time to see how you can make the two play nicely together!

Imagine that you want to write a test to ensure that a user can visit a page only available behind authentication. How would you do this?

The naive approach would be to:

* Visit the web application and invoke a redirect to the Auth0 login page (via a button click, route change, etc.)
* Enter in your Auth0 username and password
* Submit the form
* Wait for the redirect to your web application and proceed as needed

There’s a problem with this, though. To paraphrase co-founder of Cypress, [Brian Mann](https://github.com/cypress-io/cypress/issues/1342#issuecomment-366747803):

> The best practice is never to visit or test third-party sites over which you have no control.

Then, since you don’t have control over the Auth0 website, it doesn’t make sense to try and mimic a user’s login flow through the UI.

So what do you have to do?

<include src="TweetQuote" quoteText="Don't waste time covering services that you do not control on your end-to-end tests."/>

### Cypress Best Practices

Thankfully, a Cypress contains an [example recipe](https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/logging-in__single-sign-on) that can help you. The general pattern for dealing with Single Sign-On authentication is as follows:

*  Use Cypress’ `cy.request()` command to make an HTTP request to your authentication service (in this case, Auth0)
*  Parse the tokens in the response
*  Set tokens on local storage

> **Note:** Auth0 now recommends [using cookies in lieu of local storage](https://auth0.com/docs/security/store-tokens#don-t-store-tokens-in-local-storage). Not a problem. You will adhere to this recommendation in your implementation.

Now that you have a strategy in place, you can get started.

### Cypress Commands

As stated above, your first course of action is to make an HTTP request against Auth0 using Cypress `cy.request()` command. A request with Cypress would look something like this:

```javascript
const options = {
  method: 'POST',
    url: 'https://my.url.com/endpoint',

    body: {
      username: 'my_username'
      password: 'my_password'
      ...
    }
}

cy.request(options)
```

That's great and all, but you can imagine that having to write the code above every time you want to log in could be quite cumbersome and violate DRY (Don't Repeat Yourself) principles. Thankfully, Cypress has a feature called [Custom Commands](https://docs.cypress.io/api/cypress-api/custom-commands.html#Syntax) that allow you to encapsulate this code and make it reusable across your tests.

So, insert the following code to the end of the `cypress/support/commands.js` file:

```javascript
Cypress.Commands.add('login', (overrides = {}) => {
  Cypress.log({
    name: 'loginViaAuth0',
  });

  const options = {
    method: 'POST',
    url: Cypress.env('auth_url'),
    body: {
      grant_type: 'password',
      username: Cypress.env('auth_username'),
      password: Cypress.env('auth_password'),
      audience: Cypress.env('auth_audience'),
      scope: 'openid profile email',
      client_id: Cypress.env('auth_client_id'),
      client_secret: Cypress.env('auth_client_secret'),
    },
  };
  cy.request(options);
});
```

Now, when you want to trigger a request to authenticate against Auth0, you simply have to call `cy.login()` from your code. The custom command name to use in your consuming code (in this case, `login`) corresponds to the first argument given to the `add()` method.

OK, so you have your custom Cypress login command, but what's with the `Cypress.env` values for the keys in the body object?

### Cypress Environment Variables

Because you re providing sensitive information in your Cypress request to Auth0, you need to authenticate. And, it's imperative to store this information outside of your test suite.

At the root of your project, create a file called `cypress.env.json` and, before populating this file, add this line to your `.gitignore` file:

```gitignore
cypress.env.json
```

This ensures that you do not accidentally commit any sensitive details to your Git repository. _Please, **do not forget** this step!_

Now, back in your `cypress.env.json` file, add the following code to it:

```json
{
  "auth_audience": "https://my_tenant.auth0.com/api/v2/",
  "auth_url": "https://my_tenant.auth0.com/oauth/token",
  "auth_client_id": "my_client_id",
  "auth_client_secret": "my_client_secret",
  "auth_username": "my_username",
  "auth_password": "my_password"
}
```

You will have to update each one of the properties above with your own Auth0 values:

- `auth_audience`: For this one, you will have to replace `my_tenant.auth0.com` with your own Auth0 domain (e.g., `blog-samples.auth0.com`). You can find this information on the Auth0 application you created before.
- `auth_url`: Here, you will have to do the same thing. You will have to replace `my_tenant.auth0.com` with your own Auth0 domain.
- `auth_client_id`: In this case, you will have to use the _Client ID_ property of the Auth0 Application you created before.
- `auth_client_secret`: Lastly, for this property, you will have to use the _Client Secret_ property of the Auth0 Application you created.

![Copying the Auth0 Application properties to configure your Cypress end-to-end testing scripts.](https://images.ctfassets.net/23aumh6u8s0i/1zI1K62EuZ5hEcDcV3BgzK/f72c67890bb1f3358df8f731429806e6/copying-auth0-application-properties)

For the last two properties (`auth_username` and `auth_password`) you will have to use the credentials used while creating the end-to-end testing user.

### Configure React App Environment Variables

Cypress isn't the only tool in your application that has to take environment variables. You will have to define environment variables for your React application as well, albeit in a different file.

* Rename the `.env.sample` file in the root of the project to simply `.env`.
* Replace the `my-tenant.auth0.com` value (on the `REACT_APP_AUTH0_DOMAIN` variable) with your tenant domain (e.g., `blog-samples.auth0.com`).
* Insert your _Client ID_ for the `REACT_APP_AUTH0_CLIENT_ID` variable. Unlike the `cypress.env.json` file, there should be no quotes around this value here.

### Grant Strategies

While creating your Auth0 Application, you enabled the Password grant. But what exactly is a grant, anyway?

[Auth0](https://auth0.com/docs/applications/application-grant-types) defines a grant as follows:

> OAuth 2.0 supports several types of grants, which are methods by which you can gain access tokens. Different grant types allow different types of access and, based on the needs of your app, some grant types are more appropriate than others.

That last sentence is the key here. Normally, when authenticating with Auth0, you are redirected to log in through Auth0's hosted login page. *But*, since you are in a testing environment (and again, you don't want to test what you don't control), you have to find some other way to authenticate against Auth0 without redirecting away from your application. That's where the Password Grant comes in. The Password grant relies on authenticating a user via provided username and password credentials.

## Writing tests using Cypress Login Command

OK. You have created your Cypress Custom Command for login. Also, you have configured your Auth0 account and you have updated your Cypress environment variables. Now, you will see how you can take advantage of everything you've done to log into Auth0 programmatically using Cypress!

In your project, create a new directory called `integration` inside `cypress`. Then, add a file called `login.js` to it with the following code:

```javascript
describe('login', () => {
  it('should successfully log into our app', () => {
    cy.login()
      .then((resp) => {
        return resp.body;
      })
      .then((body) => {
        const {access_token, expires_in, id_token} = body;
        const auth0State = {
          nonce: '',
          state: 'some-random-state'
        };
        const callbackUrl = `/callback#access_token=${access_token}&scope=openid&id_token=${id_token}&expires_in=${expires_in}&token_type=Bearer&state=${auth0State.state}`;
        cy.visit(callbackUrl, {
          onBeforeLoad(win) {
            win.document.cookie = 'com.auth0.auth.some-random-state=' + JSON.stringify(auth0State);
          }
        });
      })
  });
});
```

Now, in your terminal, run the following commands from the root directory of your React project:

```bash
# install all dependencies
npm install

# run the React app on the background
npm start &

# run cypress
npm run cypress:open
```

This will make the Cypress dashboard open.

![Cypress dashboard](https://images.ctfassets.net/23aumh6u8s0i/1JdvnCY4VmEIXOFCmuoFqo/bdcdf89014bc58b285c1b2fc08ec6a21/running-the-cypress-dashboard)

From there, you can click on the `login.js` integration test in the Cypress test runner. You should now see an instance of Chrome launched, with your user automatically logged in to Auth0! Click on the **Profile** page to see your logged in user's email address for verification.

![Running the E2E testing scripts with Cypress and Auth0.](https://images.ctfassets.net/23aumh6u8s0i/4ZSK4oPQf8PXPlld8b81bI/d3a85580fa2ebc214bcab7df9d43d484/running-the-e2e-testing-scripts-with-cypress-and-auth0)

<include src="TweetQuote" quoteText="I just learned how to perform end-to-end integration tests on SPAs secured with Auth0."/>

## Wrap Up

In this article, you started by learning about one of Cypress' core tenets when it comes to testing: avoid testing sites over which one does not have control. Next, you took a quick look on _Cypress Custom Commands_ and how they make your lives easier by encapsulating repetitive testing logic. Then, you learned about _Grant Strategies_, which are methods by which you can gain access tokens. More specifically, you learned about the _Resource Owner Password Grant_ strategy, which allows you to receive a token by providing username and password credentials, thereby circumventing the need to visit the Auth0 login page.

> **Note:** Keep in mind that you must not use this grant on your public clients. This is an exception to this rule because it is an end-to-end test that won't be used by real users.

Finally, you learned about how you can use your custom login command in a test, set your access token in memory, and successfully log into your application as part of your Cypress test.

I hope you've enjoyed reading this article, and have gained an understanding of how you can incorporate Cypress into your Auth0 application. If you have any questions or concerns, please feel free to leave a comment down below.

Thanks for reading!


End-to-End Testing with Cypress and Auth0

adam-mcgrath

I've been working as an Engineer on the web for over 20 years at companies including the BBC, Google and IG. At Auth0, I build and maintain our JavaScript SDKs for servers and browsers.

SDK Engineer

Adam McGrath

Learn how to authenticate users with Auth0’s Next.js SDK



**TL;DR:** Auth0 announces the release of [nextjs-auth0](https://www.github.com/auth0/nextjs-auth0), a new [Next.js](https://nextjs.org/) SDK that makes it super easy to add authentication to your Next.js apps. Get it [here](https://github.com/auth0/nextjs-auth0).

Next.js blurs the line between frontend and backend, so there is more than one way to do authentication on a Next.js app.

To identify which authentication pattern you should use, you must first understand the [data-fetching strategy](https://nextjs.org/docs/basic-features/data-fetching) you want. The predominant patterns are:

### Fetching user data client-side

You will use [Static Generation](https://nextjs.org/docs/basic-features/pages#static-generation-recommended) to generate the page’s HTML at build time. The HTML will then be reused on each request and can be cached by a CDN. The user will be quickly served an [app shell](https://developers.google.com/web/fundamentals/architecture/app-shell), usually a loading indicator, before the client-side code fetches the user’s data to populate the content.

Your typical authentication for this type of application will be that of a SPA, where the user’s tokens are stored on the client.

For fetching user data client-side, we recommend using [auth0-react](https://github.com/auth0/auth0-react); we have an [example Next.js app](https://github.com/auth0/auth0-react/tree/master/examples/nextjs-app) using auth0-react for authentication in the project’s repository [here](https://github.com/auth0/auth0-react/tree/master/examples/nextjs-app).

### Fetching user data server-side

When the server receives a request for a page, it will fetch your user’s data and construct the page at the request time. This will be slower than returning the page from a CDN but doesn’t need to display an app shell while the frontend fetches the user data.

Your typical authentication for this type of application will be that of a Regular Web App, where the user’s tokens are stored in a secure session that is not directly accessible from the client-side and therefore not vulnerable to the more [common XSS attacks](https://auth0.com/docs/security/prevent-common-cybersecurity-threats).

>💡As you can see from the two models described above, there are various tradeoffs for performance and security. For more information, check out our[ Ultimate Guide to Next.js Authentication with Auth0](https://auth0.com/blog/ultimate-guide-nextjs-authentication-auth0/).

For fetching user data server-side, we recommend our new Next.js SDK [nextjs-auth0](https://github.com/auth0/nextjs-auth0/).

## Adding Session Based Authentication to a Next.Js Application

In a few lines of code [nextjs-auth0](https://github.com/auth0/nextjs-auth0/) adds server-side login, logout, and session management. It also offers a suite of tools to access the user’s session from the server and client-side.

Create a **Regular Web Application** in the [Auth0 Dashboard](https://manage.auth0.com/) and configure the following URLs for your application under Application URIs:

* **Allowed Callback URLs**: [http://localhost:3000/api/auth/callback](http://localhost:3000/api/auth/callback)
* **Allowed Logout URLs**: [http://localhost:3000/](http://localhost:3000/)

Take note of the **Client ID**, **Client Secret**, and **Domain** of your application because you’ll need it in the next step.

Install the SDK using npm or yarn, eg.

``` bash  
npm install @auth0/nextjs-auth0
```


The library needs the following required configuration keys. These can be configured in a .env.local file in the root of your application (See more info about [loading environmental variables in Next.js](https://nextjs.org/docs/basic-features/environment-variables)):

``` bash  

#A long secret value used to encrypt the session cookie
AUTH0_SECRET=LONG_RANDOM_VALUE
#The base url of your application
AUTH0_BASE_URL=http://localhost:3000
#The url of your Auth0 tenant domain
AUTH0_ISSUER_BASE_URL=https://YOUR_AUTH0_DOMAIN.auth0.com
#Your Auth0 application's Client ID
AUTH0_CLIENT_ID=YOUR_AUTH0_CLIENT_ID
#Your Auth0 application's Client Secret
AUTH0_CLIENT_SECRET=YOUR_AUTH0_CLIENT_SECRET

```

For a [full list of configuration options](https://auth0.github.io/nextjs-auth0/modules/config.html) see the docs.

Then, create a [Dynamic API Route handler](https://nextjs.org/docs/api-routes/dynamic-api-routes) at `/pages/api/auth/[...auth0].js`.


``` js  
import { handleAuth } from '@auth0/nextjs-auth0';

export default handleAuth();
```


This will create the following urls: `/api/auth/login`, `/api/auth/callback`, `/api/auth/logout` and `/api/auth/me`.

That’s it! The server-side is now setup and you can visit [http://localhost:3000/api/auth/login](http://localhost:3000/api/auth/login) to login.

To access the user on the client-side, wrap your `pages/_app.js` component in the `UserProvider`component.

``` js  
//pages/_app.js
import React from 'react';
import { UserProvider } from '@auth0/nextjs-auth0';
export default function App({ Component, pageProps }) {
  return (
    <UserProvider>
      <Component {...pageProps} />
    </UserProvider>
  );
}

```

This will populate a React Hook `useUser` you can use to check the user object. You can also log them in and out from the front end by redirecting to the appropriate `/api/auth/*` route.

``` js  
// pages/index.js
import { useUser } from '@auth0/nextjs-auth0';

export default () => {
  const { user, error, isLoading } = useUser();

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

  if (user) {
    return (
      <div>
        Welcome {user.name}! <a href="/api/auth/logout">Logout</a>
      </div>
    );
  }

  return <a href="/api/auth/login">Login</a>;
};
```

Go checkout the [QuickStart](https://auth0.com/docs/quickstart/webapp/nextjs) for a more detailed setup and also [the examples](https://github.com/auth0/nextjs-auth0/blob/main/EXAMPLES.md) for more ways to use the new [nextjs-auth0](https://github.com/auth0/nextjs-auth0/) SDK.

Happy coding!


Introducing Auth0's Next.js SDK

jessica-sealby

Jessica drives public relations and global communications efforts for Auth0 across Asia Pacific. Outside Auth0, she frequents Melbourne’s live music venues and chases after her two energetic dogs.

PR Manager - APAC

Jessica Sealby

Australian software giant provides simple login experience for customers; focuses on security and identity.



**BELLEVUE, WA – May 18, 2020 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, is powering identity management for [Atlassian](https://www.atlassian.com/), a leading provider of team collaboration and productivity software. Atlassian has been using Auth0 to secure and simplify its identity and authentication process for customers and millions of users around the world.

Atlassian builds collaboration and productivity software to help businesses organize, discuss, and complete shared work, including Walmart Labs, Merrill Lynch, Bank of America, and Verizon. With the multitude of products it provides (Jira, Confluence, Trello, Opsgenie, and more), Atlassian relies on Auth0 for flexible, configurable authentication that has allowed it to balance better collaboration for users and the security controls needed by administrators. Outsourcing authentication also enables Atlassian to focus its valuable development team on product innovation. 

As Atlassian continues its rapid growth, it is placing a renewed focus on a Single Sign On (SSO) solution to all its products and support systems for millions of users worldwide, placing a high importance on identity. Auth0’s identity platform is providing a simple login experience removing a barrier to entry for many Atlassian cloud customers as they expand their use of Atlassian products. 

Working with Auth0 has helped Atlassian build out key identity features like multi-factor authentication (MFA), Security Assertion Markup Language (SAML) support, and OAuth, which has helped evolve its third-party ecosystem and address security and privacy needs among its customer base.

“The security of our customers is very important to us, and we want to ensure our administrators’ information is held securely. Auth0 has been integral in offering our administrators and users that level of confidence,” said William Bath, Head of Engineering for Identity at Atlassian. 

Atlassian is constantly innovating and bringing new product capabilities to the market. Working with Auth0 gives Atlassian simple, powerful, and developer-friendly identity building blocks so they can free up resources to focus on its core business value. It has also allowed the company to quickly and simply keep pace with new integrations such as Sign in with Apple and login through Microsoft Accounts. 

“The best login experience is one that you barely notice, yet keeps your account secure,” added Bath. “Auth0 allows us to offer a simple, fast, reliable, and secure login experience. With that, we’re helping more and more teams collaborate and have a greater impact.” 

“Atlassian has been an incredibly valued customer for some time, and we are thrilled to continue to serve as an identity partner to them as they expand their global footprint with the highest quality collaboration and productivity software and services,” said Richard Marr, General Manager for the Asia Pacific at Auth0. “Auth0 provides a simple, extensible, and scalable platform to secure identities so Atlassian can concentrate on the innovation that drives its success.”

<include src="asides/AboutAuth0" />

### Media Contacts
Jessica Sealby<br>
Auth0 APAC Communications<br>
[press@auth0.com](mailto:press@auth0.com)


Atlassian Authenticates Millions Of Users with Auth0

auziros:mckenzie-mayer

Customer Identity (CIAM) Product Comms lead, driving collective storytelling across Okta and Auth0. Making technology accessible for everyone.

Customer Identity Product Comms Lead at Okta

McKenzie Mayer

Online travel agency authenticates millions of users across multiple platforms with Auth0


<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i> Download Press Release as PDF<br/>
  <strong><a href="https://cdn.auth0.com/blog/pdf/holidaycheck-makes-digital-identity-easier-for-users-final-eng.pdf">English</a><br/></strong>
   <strong><a href="https://cdn.auth0.com/blog/pdf/holidaycheck-erleichtert-digitale-Identifizierung-für-urlauber-final-de.pdf">German</a><br/></strong>
</div>

**LONDON July 24, 2019** [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), today announced that it has deployed its identity management platform for hotel rating and travel booking portal, [HolidayCheck](https://www.holidaycheck.de/).

In concrete terms, this enables users to simply, securely, and conveniently authenticate themselves via the portal's website or mobile app to book a holiday and submit ratings. In total, HolidayCheck has more than 1 million hotels, 9.4 million hotel ratings, and over 10 million photos and videos.

As the second-largest online travel agency in the German-speaking market, HolidayCheck deals with numerous users every day whose data must be managed securely and smoothly. This is particularly true during the holiday season, when users of the portal have to identify themselves to quickly book last-minute offers. HolidayCheck wants to strengthen trust and loyalty in the brand by accelerating the entire identity management process to offer its customers an Urlauber*-friendly service.

"Auth0's authentication solution allows us to quickly and easily authenticate millions of users each month across multiple platforms, so they can book their holiday with us without a long time delay and give feedback smoothly," says Björn Zapadlo, director of technology at HolidayCheck.

"It's great to work with like-minded individuals who are not only seeing value from your product, but also share your values as a company. A shared focus on trust makes our partnership with HolidayCheck that much better, and we look forward to helping them become the most holidaymaker-friendly company in the world," said Steven Rees-Pullman, GM of EMEA at Auth0.

The Auth0 solution has enabled HolidayCheck to handle more than 21 million authentication transactions in the last 30 days. With Auth0, Zapadlo and his team are improving their ability to personalise the online experience and bookings for many different types of buyers. More details on [HolidayCheck's implementation of Auth0 can be found here](https://auth0.com/case-studies/holidaycheck/).

_* Urlauber [uːɐlaʊbɐ] is the German term for vacationer, holidaymaker._

## About HolidayCheck

HolidayCheck enables every Urlauber to find and book the individually suitable holiday thanks to authentic evaluations, the expertise of their own travel agency, and the knowledge of the community. It is based on over 9.4 million hotel evaluations, its own TÜV-certified online travel agency with around 220 travel experts, and the offers of more than 100 tour operators and other tourism providers. Urlaubers can also find lots of helpful information and inspiration in the travel forum with up to 2.9 million visitors per month, in the HolidayCheck online magazine Away, and on the new HolidayCheck cruise platform. HolidayCheck AG, a subsidiary of the HolidayCheck Group, was founded in 2003 and is based in Bottighofen, Switzerland, near the German border town of Constance.

<include src="asides/AboutAuth0" />

### Media Contacts:

Silvia Hänig<br/>
shaenig@wireside.com<br/>
haenig@i-kom.org<br/>
0173-3838572<br/>
089-44848127<br/>

Mark Fowler<br/>
Racepoint Global for Auth0, EMEA<br/>
[auth0@racepointglobal.com](mailto:auth0@racepointglobal.com)<br/>
+44 (0) 77 1124 4113


HolidayCheck Makes Digital Identity Easier for Users

Leading media companies choose Auth0 to authenticate and monetise digital subscribers



LONDON  ** June 3, 2019 ** [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), today announced rapid customer growth in Northern Europe. In the last year alone, Auth0 has tripled its customer base in the region, signing on well-known enterprises Elsevier and Atea Norge; as well as prominent media leaders, such as TV 2 Danmark, broadcaster of the Danish "X-Factor" show; Danish Broadcasting Corporation; and Alma Media.

Northern Europe boasts the EU's [top five most advanced digital economies](https://ec.europa.eu/digital-single-market/en/desi), and the Nordic countries lead the world in [paying for online news](http://media.digitalnewsreport.org/wp-content/uploads/2018/06/digital-news-report-2018.pdf?x89475) through subscription, membership, donations, or per-article payments, according to Reuters. The digitisation of the media industry in the region has created an urgent need for identity management, as media companies seek to reduce friction for their users to sign up and access content, and turn free users into subscribers.

"What if an extra 10 percent of visitors to your app or online publication decided to spend money with you? Identity makes this possible, giving companies the tools to streamline their login, collect first-party data, and personalise experiences for their customers, which drive additional revenue opportunities," said Steven Rees-Pullman, GM of EMEA at Auth0. "Northern European companies understand this value, and turn to Auth0 for a modern identity platform and a roadmap for getting started."

Danish Broadcasting Corporation (DR), Denmark's largest media company and producer of a broad variety of Danish content, uses Auth0 to authenticate users of their various video, audio, and live voting apps. Auth0 supported both the implementation and assisted DR in mapping out an identity strategy for the near-and far-term.

For more on how Auth0 supports the media sector, including a case study with [Finland-based Alma Media](https://auth0.com/learn/alma-media-sees-30-total-savings-seamless-brand-access/), please visit: <https://auth0.com/media-publishing/>.

<include src="asides/AboutAuth0" />

### Media Contacts:

Mark Fowler<br/>
Racepoint Global for Auth0, EMEA<br/>
(auth0@racepointglobal.com)[mailto:auth0@racepointglobal.com]<br/>
+44 (0) 77 1124 4113


Auth0 Expands European Presence with Customers in Benelux and the Nordics

auziros:jeana-tahnk

Jeana has been in the tech industry for 15+ years, both as a communications professional and writer. As Director of Global Communications at Auth0, she works with her internal team and external agencies to amplify the company's visibility worldwide and establish its leadership in the identity industry. When she is not working, she can most likely be found on a field watching one of her three kids playing sports, or cleaning up after her one-year-old retriever who chews everything.

Senior Director, Global Communications

Jeana Tahnk

Popular third-wave coffee brand makes app experience seamless for devotees



**BELLEVUE, Wash. -- August 7, 2018 --** [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), today announced that its Universal Identity Platform is being used to authenticate users for [Philz Coffee](https://www.philzcoffee.com/)’s new mobile app. The highly-publicized app has been getting attention for its unique user experience, and serves as an easy way for Philz Coffee loyalists to easily place a custom order from their phones. 

Philz, a national coffee company with more than 40 locations in California and Washington DC, is expanding rapidly and wanted to cater to coffee drinkers devoted to its highly personalized "One Cup at a Time" approach. As an extension of its dedication to customers, the Philz mobile app provides a simple and quick way for people to order online, preview the full menu of drink offerings, and view additional locations. 

Philz is using Auth0 to provide authentication to its mobile app for both iOS and Android. They implemented Auth0 for the release of the new app, and since its launch, there has been a dramatic increase in downloads and it is now being used by more than 50,000 customers. App adoption is expected to continue growing as more store locations are added.

"Our mission at Philz is to better people's days through warmth and connection, ‘One Cup at a Time'," said Francisca Hawkins, VP of Digital at Philz Coffee. "When we set out to make our app, we wanted it to reflect the care we take with each customer interaction, and Auth0 provided the best authentication platform to support our app goals." 

"Anyone who knows Philz Coffee knows that it’s a brand dedicated to a highly-personalized experience," said Eugenio Pace, CEO and Co-founder of Auth0. "The app is part of the holistic Philz Coffee experience and we are happy to provide our technology to the brand and its very loyal following."

<include src="asides/AboutAuth0" />

### **Media Contact:**

Jeana Tahnk<br>
Corporate Communications<br>
Auth0<br>
[jeana.tahnk@auth0.com](mailto:jeana.tahnk@auth0.com)

Kasia Hall<br>
Matter for Auth0<br>
[khall@matternow.com](mailto:khall@matternow.com)<br>
971-246-7898


Philz Coffee Authenticates Mobile App Users with Auth0

kapehe-jorgenson

Kapehe is an R&D Content Engineer for Auth0 with a passion for learning and teaching. With her primary focus on ReactJS and JavaScript, she is impressed with what code can create for the web. Technology and web development are constantly evolving and naturally bring that need for continual learning. She enjoys writing tutorials, hosting local meetups, and learning with others to expand coding knowledge.

R&D Content Engineer

Kapehe Jorgenson

Learn how to build and authenticate an EmberJS 3 Single Page Application

Build and Authenticate an EmberJS 3 Application

jenny-obrien

I'm a former business journalist who's fascinated by the intersection of tech and business strategy — in particular how the right solution can transform an idea into reality. I specialize in ROI, data privacy, and identity.

Business Content Manager

Jenny O'Brien

Auth0's Universal Identity Management platform will securely authenticate voters as they log in MiVoz’s decentralized platform



Trusting elections is tough when more than [two-thirds of Uruguayans surveyed](http://en.mercopress.com/2017/12/31/corruption-in-uruguayan-government-very-much-extended-says-opinion-poll) believe that their politicians are corrupt, nonprofit [MiVoz](https://mivoz.uy/) sees an answer in injecting innovative technology into the election process.

“The political part of our society is really old — 200 years. We were thinking that the main reason democracy exists is so that people can really feel that they are living in the society that they want”, says [Leonardo Giovanetti, Technical Leader for MiVoz and the Digital Party](https://www.linkedin.com/in/leogiovanetti/).

Social media has programmed people to trust information found via their social networks for both good and bad outcomes. What if that interaction, trust, and energy could be harnessed in a way that allowed each voter to have a say in each political decision, instead of waiting years to weigh in during the election of a representative?

MiVoz is hoping to prove that direct democracy doesn’t have to be unwieldy or even time-consuming. By creating an effective and secure digital platform, taking part in democracy could become a more seamless part of modern lives.

## Mending Trust with Digital Values like Transparency

But changes to long-established institutions and processes can take time.

For the initial phase, MiVoz is targeting Uruguay’s National Elections of 2019 and the following year’s departmental elections. They only need to sign up 30,000 people to secure a representative who will vote in accordance with how citizens vote on MiVoz’s online platform.

“We're intending to promote the usage of an online platform to bring up participation levels and to bring transparency to decision-making on financial reports, which is something that political parties here in Uruguay have lost,” says Giovanetti

As a nonprofit, MiVoz needed the most efficient and low-cost method of securely authenticating voters. But the big issue was trust. Based on past experience with political parties, citizens in Uruguay were reluctant to place their trust in yet another political party.

“We really want to let people know that they can use the tool that we're providing because it's really safe because one vote needs to correspond to one person. Auth0 was really a blessing from my perspective because it's really the best way to go,” says Giovanetti.

While MiVoz is still exploring fully digital means of uploading and validating voter credentials, currently, government-issued identification will be used to validate each voter in person via various locations throughout Uruguay. After that initial effort, Auth0 will securely authenticate voters as they sign in to access MiVoz’s platform.

## Encouraging Participation through Collaboration and Delegation

The initial rollout is focused on the 2019 elections, but later plans include the ability for voters to weigh in on each decision their representative faces — including the possibility of delegating votes on topics like energy or education to close friends. “No one knows everything about every single topic,” says Giovanetti. “We're trying to provide the right tools for people to really represent themselves, sometimes through a trustee who can make a better decision than ourselves because of their background.”

Originally, MiVoz tried DemocracyOS for collecting votes, but after exploring their voting process, they shifted to Sovereign’s decentralized platform. In addition to encouraging collaboration and discussion through tools like Discourse, MiVoz plans to store credentials using blockchain accessed via an Auth0 plug-in.

“We're really passionate about making democracy for this millennium. We’re looking to involve people instead of having them vote and forget about it, but still complain on Facebook or Twitter. Our idea is to put up a platform that could really bring people together for new causes for democracy in their society.”


Nonprofit MiVoz Hopes to Upgrade Democracy with Auth0

956290?s=200

Luke Oliff

You can't escape Phoenix if you're looking for a good framework to build on when using Elixir.

Elixir & Phoenix Tutorial: Build an Authenticated App

keith

Keith Kowal

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



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

---

## Introducing Authenticated Identities

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

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

## Setting up the Trusted Key App

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

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

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

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

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

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

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

## Getting a Client ID / Secret

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

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

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

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

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

## Setting Up Auth0

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

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

### Standard Trusted Key Social Connection Setup

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

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

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

### Authenticated Identity Trusted Key Social Connection Setup

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

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

**Scope**: `openid email profile`

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

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

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

        const ui = JSON.parse(body);

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

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

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

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

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

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

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

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

## Testing it Out

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

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

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

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

## Conclusion

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


Implementing Authenticated Identity with Trusted Key and Auth0

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g avatar

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g

Former Auth0 Employee

Robin Percy

Continuing on from my Introduction to Crystal article, this time we're going to build our first Crystal web app and authenticate users via JSON Web Tokens.

Building Your First Crystal Web App & Authenticating with JWTs

eHk3ciM

I am the Group Manager, Developer Content at Okta, and a Google Developer Expert in Web Technologies and Angular. I'm passionate about identity, authentication, constant learning, and developer communities. As a developer advocate, engineer, mentor, and international speaker, I love learning from and sharing with other inhabitants of the tech space.

Group Manager, Developer Content

Kim Maida

Inferno is a fast, small, React-like JavaScript UI library.

Learn About Inferno JS: Build and Authenticate an App

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

I'm currently a Senior Developer Advocate at MongoDB. I'm also a Google Developer Expert for Web Technologies and spend most my time giving talks at conferences and meetups, mentoring developers and running workshops, and creating online content to help technology professionals.

Ado Kukic

The NGINX Plus R10 release comes with native support for the JWT authentication standard. Learn how this can change the way your app handles authentication.



---

**TL;DR** NGINX Plus R10 brings native [JSON Web Token (JWT)](https://jwt.io/introduction/) support to the popular server. This enhanced capability allows NGINX Plus to validate JWTs and reject requests that do not have valid JWTs associated with them. This is very useful in protecting API clients and in this post we'll take a look at how we can leverage this new feature in our applications. 

---

[NGINX Plus R10](https://www.nginx.com/blog/nginx-plus-r10-released/) has only been out for a few weeks but it's got us very excited. The latest release boasts many new features and improvements including: "Dual-stack" support for ECC and RSA Certificates, transparent proxy support, nginScript support, and more. The feature we are most excited about is native support for **JSON Web Tokens (JWT)**.

With the R10 release, NGINX Plus makes it easy to protect your APIs and services with JWTs. In this post, we'll look at why you would want to offload the authorization aspect of your app to NGINX and then we'll build an application that does exactly this. We'll use Auth0 to issue the JWTs for us, but the same workflow is applicable to any JWT issuer.

## NGINX Plus JWT Support

Many companies employ NGINX as a reverse proxy or load balancer for their applications. This means that NGINX sits between the users making requests and your actual application servers. NGINX is the first point of contact between a request and your API or service. From here, the request is routed to the correct server for further processing and finally a response is served. If your API requires a user to be authenticated to access a resource, the validation of the request is typically performed after the request has passed through NGINX.

If the user requesting a protected resource is not authenticated, they've just wasted CPU cycles on both your NGINX server, bandwidth between NGINX and your application server, and resources on your application server, all so you could tell them they need to login.

The NGINX Plus `auth_jwt` directive verifies that the user is authenticated and has permissions to access a resource before the request is routed to your application server. If the request coming in does not have a valid JWT, the request is short-circuited and NGINX replies with an appropriate `401 Unauthorized` response. No additional resources wasted.

In addition to not wasting resources, having NGINX Plus handle JWT verification allows developers to focus on implementing business logic instead of building authentication systems. Since NGINX Plus can pass the authenticated user claims directly to the application server, performance gains could also be argued as the app server has less to do. The overhead of adding JWT verification to NGINX is also trivial, as NGINX is rarely the bottleneck in the infrastructure.

<include src="TweetQuote" quoteText="NGINX Plus native JWT support means developers can offload JWT verification and focus on business logic"/>

## Configuring NGINX Plus with JWT Support

With the benefits of having NGINX Plus handle JWT verification for us clear as day, let's see how we can get this implemented. 

*Since NGINX Plus is only available on Linux distributions, we'll be using an Ubuntu virtual machine for our demo.*

### Building our Application Server

For starters, let's create a mock API server. I'll just create a quick server with Node.js and Express and expose a couple of different routes. Take a look at the implementation of our application server below:

```js
// Declare dependencies
var express = require('express');
var app = express();

// Add some public routes that are accessible to everyone
app.get('/', function(req, res){
	res.send('<h1>Welcome to the Hompeage. <small>(Everyone can view this page)</small></h1>');
})

app.get('/about', function(req, res){
	res.send('<h1>Welcome to the about page<small>(Everyone can view this page)</small></h1>');
})

// Add some protected routes that only authenticated users will have access to
app.get('/api/leads', function(req, res){
	res.json({leads:[{id: 12345, name: 'ACME Corp'}, {id: 23456, name:'LeadGen'}, {id:45677, name: 'Organic Leads'}]})
})

app.get('/api/employees', function(req, res){
	res.json({employees:[{name: 'Ado Kukic', username:'@ado'}, {name: 'Diego Poza', username:'@tony'}, {name:'Prosper Otemuyiwa', username:'@unicodedeveloper'}, {name:'Sebastian Peyrott', username:'@speyrott'}, {name:'Kim Maida', username:'@kim.maida'}]})
})

app.listen(9000);
```

Our server exposes four routes. Two public, two protected. Without NGINX Plus to protect our API routes, we'd have to add a couple more dependencies, add some middleware to check and verify that the incoming request had a valid JWT, implement logic for when the token is not valid and more. Luckily, we are using NGINX Plus, so we don't have to do a single other thing. We can simply deploy this server by running `node server.js` and accessing our application at `localhost:9000`.

### Configuring NGINX Plus

NGINX Plus is a premium product. It requires an annual fee, but you can also try it for free [here](https://www.nginx.com/products/). You can find the installation instructions on the official NGINX Plus [website](https://www.nginx.com/resources/admin-guide/installing-nginx-plus/). I'll assume that you already have NGINX Plus installed on your machine. If you have an older version of NGINX Plus installed, you can easily upgrade to the latest R10 release by running:

```bash
// Debian or Ubuntu
sudo apt-get update
sudo apt-get install nginx-plus

// RHEL, CentOS, or Amazon Linux
sudo yum upgrade nginx-plus

// FreeBSD
sudo pkg upgrade nginx-plus
```

Before continuing, check that the version of NGINX Plus installed on your machine is `nginx-plus-r10` or higher. With the appropriate version installed, let's configure our NGINX Plus server. Open the `nginx.conf` file and paste the following:

```
user nginx;
worker_process auto;

events {}

http {
  # Here we are defining the server that we'll pass the requests to
  upstream api_server {
    server 127.0.0.1:9000;
  }
  server {
    # Our NGINX Plus server will listen on Port 80
    listen 80;

    # By default all routes will proxy to our Node.js server at localhost:9000
    location / {
      proxy_pass http://api_server;
    }

    # For any of the /api/* routes, we'll ensure that the user has a valid JWT
    location /api/ {
      # We'll name our domain or realm our Auth0 Domain
      # This is not required so you can name it anything
      auth_jwt "YOUR-AUTH0-DOMAIN.auth0.com";
      # We'll need to load a JWK that contains our secret credentials that will be used to verify incoming JWT's
      auth_jwt_key_file /etc/nginx/secret.json;

      # If an incoming JWT is valid, we'll proxy to our Node.js server
      proxy_pass http://api_server;
    }
  }
}
```

We'll need to create a `secret.json` file next. You can create this file anywhere, as long as it's accessible by NGINX, so we'll just create it our nginx directory.

The `secret.json` file will contain a [JSON Web Key (JWK)](https://tools.ietf.org/html/rfc7517) which will hold our signing key. This file can either be a `.json` file or a `.jwk` file, as long as the format is correct. Learn more about what compromises a JWK [here](https://tools.ietf.org/html/rfc7517).

For our implementation, our JWK will look like:

```json
{"keys":
    [{
        "k":"YOUR-AUTH0-SECRET",
        "kty":"oct"
    }]
}
```

Let's go ahead and get our Auth0 client credentials so we can test our implementation. If you don't already have an Auth0 account, sign up for a free one <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">here</a>. Log in to your [management dashboard](https://manage.auth0.com), navigate to the client you wish you to use, and retreive your **Domain** and **Client Secret**. Replace the `YOUR-AUTH0-DOMAIN` from the `nginx.conf` file and with your domain and `YOUR-AUTH0-SECRET` with your secret and save the files.

![Auth0 Management Dashboard](https://images.ctfassets.net/23aumh6u8s0i/5VmGAcLFkxC2f9WMGuptQK/442660c778bf0f59c828881ec6a814f6/management-dashboard)

To start your NGINX server, run the `sudo nginx` command.

Navigate to `localhost`. You'll see the response from the Node.js server we created earlier and the text displayed: "Welcome to the Homepage". Our proxy server works. NGINX took the request from `localhost:80` and forwarded to our Node.js server at `localhost:9000`.

![Our Node.js Application](https://images.ctfassets.net/23aumh6u8s0i/7MJRdejJyEJPWTZLRXtvN5/e39694d35cfd7777e1b01796680c9f3d/our-app)

Now, let's try to access an API route, navigate to `localhost/api/leads`. You will see a `401 Unauthorized` message served from NGINX. We didn't write this page or have an implementation for it in our Node.js server. When NGINX received the request, it looked for a JWT and since we didn't pass one in, the request was rejected.

![Unauthorized NGINX Plus request](https://images.ctfassets.net/23aumh6u8s0i/4n8PaH6Oy7WEOpGVG57c21/71506bd4ed1455ffaf7f1c0c5857788d/unauthorized)

Let's send a request with a valid JWT. The easiest way to get a valid JWT for our Auth0 implementation is to visit the [Auth0 playground](https://auth0.github.io/playground/). Here, all you need to do is add your ClientID and Domain and you will be able to login with the Lock widget. Let's `console.log` the token we get upon a succesful login and copy it. For reference, our Auth0 playground code will be:

```
var domain = 'YOUR-AUTH0-DOMAIN.auth0.com';
var clientID = 'YOUR-AUTH0-CLIENTID';

var lock = new Auth0Lock(clientID, domain);
lock.show({
  focusInput: false,
  popup: true,
   authParams: {
    state: 'foo'
  }
}, function (err, profile, access_token, state, token) {
  // Console.log the access_token or JWT
  console.log(access_token)
});
```

![Auth0 Playground](https://images.ctfassets.net/23aumh6u8s0i/3Ph31s2T4ZbhFY0zBmUIi6/0bb7812e2001fee4a576229d02ae0796/auth0-playground)

Now that we have a valid JWT, let's make another request to our NGINX server, this time passing the JWT alongside the request. To accomplish this, we'll use `curl`, but you can use a GUI app like Postman to do this as well. Our command to the server will be as follows:

```bash
curl http://localhost/api/leads -H "Authorization: Bearer {JWT}"
```

The `-H` flag will append a header which we'll define as the Authorization header. The Authorization header value requires the word `Bearer` followed by a space and then the JWT. Let's run this command by hitting the return or enter key and our response will be the list of leads we defined in our Node.js server.

![Curl with valid JWT](https://images.ctfassets.net/23aumh6u8s0i/4gXuDaHbOJSPttXXdOsnpk/a4dd45a4158860a593504a76e49f9170/curl-with-jwt)

To double check and make sure that this works, try making a request without passing the Authorization header. Try running `curl http://localhost/api/leads` and you'll see the `401 Unauthorized` response.

![Curl without valid JWT](https://images.ctfassets.net/23aumh6u8s0i/11qW4xkFruCigZolxL1bhB/74cab3f377e412ce245a024bfe2f63b8/curl-without-jwt)

By default NGINX Plus looks for the Authorization header with the JWT, but we can easily change this so we can send the token as a query parameter or even a cookie. For directions on how to do that, check out [this post](https://www.nginx.com/blog/authenticating-api-clients-jwt-nginx-plus/) on the NGINX Plus blog.

*Note: Notice that on your local machine, you can go to `localhost:9000/api/leads` and see the response. This is intended as we are not validating JWTs on our Node.js server. In a real world scenario, you would not allow direct access to `localhost:9000` outside of your private network.*

## Conclusion

Today, we looked at how NGINX Plus can take the burden of validating JWTs off our application servers. We showed how you can integrate Auth0's identity platform to handle the issuance of JWTs. Since we adhere to standards, everything we covered today is also applicable to non-Auth0 JWT implementations, but for the quickest and most secure option, give us a <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">try</a>. 


Use NGINX Plus and Auth0 to Authenticate API Clients

7752008352217db815996ab04aec46e6?s=80 avatar

7752008352217db815996ab04aec46e6?s=80

Matias Quaranta

Document your ASP.NET Core Web APIs with Swagger and auto-generate authenticated clients quickly and easily with Autorest.

ASP.NET Core APIs in the fast lane with Swagger and Autorest

d5365965372e0c5843d836f660b51a84?size=200 avatar

d5365965372e0c5843d836f660b51a84?size=200

Jeff Smith

Using JWTs to authenticate your React Native app will help it to be both secure and easy to integrate with a variety of services.

Adding Authentication to Your React Native App Using JSON Web Tokens

6222081fd7dcea7dfb193788d138c457?s=60 avatar

6222081fd7dcea7dfb193788d138c457?s=60

Jerrie Pelser

Learn how to use the new OAuth middleware in ASP.NET Core to authenticate a user.

Authenticating a user with LinkedIn in ASP.NET Core

001c9ddc5ceb9829b6aaf24f5d28502a

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

Senior Engineer

Sebastian Peyrott

Learn how to implement social logins on Android with Facebook, Google, Twitter and Instagram as providers

Authenticate on Android Using Social Logins

Damian Schenkelman

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

VP R&D (Auth0Lab)

Most APIs today use an API Key to authenticate legitimate clients. API Keys are very simple to use from the consumer perspective:  You get an API key from the

Most APIs today use an **API Key** to authenticate legitimate clients. **API Keys** are very simple to use from the consumer perspective:

1. You get an **API key** from the service (in essence a shared secret).
2. Add the key to an `Authorization` header.
3. Call the API.

It can't get simpler than that, but this approach has some limitations.

The last couple of months, we've been working on our [API v2](https://docs.auth0.com/apiv2). We wanted to share what we've learnt implementing a more powerful security model using [JSON Web Tokens](http://jwt.io).



Using a JSON Web Token offers many advantages:

* **Granular Security**: API Keys provide an all-or-nothing access. JSON Web Tokens can provide much finer grained control.
* **Homogenous Auth Architecture**: Today we use cookies, API keys, home grown SSO solutions, OAuth etc. Standardizing on JSON Web Tokens gives you an homogenous token format across the board.
* **Decentralized Issuance**: API keys depend on a central storage and a service to issue them. JSON Web Tokens can be "self-issued" or be completely externalized, opening interesting scenarios as we will see below.
* **OAuth2 Compliance**: OAuth2 uses an opaque token that relies on a central storage. You can return a stateless JWT instead, with the allowed scopes and expiration.
* **Debuggability**: API keys are opaque random strings. JSON Web Tokens can be inspected.
* **Expiration Control**: API keys usually don't expire unless you revoke them. JSON Web Tokens can (and often do) have an expiration.
* **Devices**: You can't put an API key that has full access on a device, because what is on a phone or tablet can easily be stolen. But you can put a JWT with the right set of permissions.

If you'd like an in-depth introduction to **JSON Web Tokens**, check out our **free** ebook below.

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

## Granular Security

One of the most interesting benefits of using JWTs is the first one listed above. Back in the old days, when databases were at the center of our client-server applications, we could create users with specific permissions on the database:

<a href="https://images.ctfassets.net/23aumh6u8s0i/2paJRM6vdAq4RO2k6ypich/b960d3ab0c364b327b2d4a2f1afc66c4/permissions-sql" target="_blank"><img src="https://images.ctfassets.net/23aumh6u8s0i/s9tyvnrUrUjg7i39zWBOn/db84bd0b3a904e879c3484841d34cd1a/permissions-sql.png"/></a>

_Remember this?_

APIs are becoming central pieces of our distributed systems architecture. They are now the "gatekeepers" of our data. But in contrast with what was available in databases, virtually all API keys provide all-or-nothing access. Readers will likely be familiar with the `scope` parameter of OAuth2 based systems that offers this finer grained consent to access.

There are many situations in which you want to keep the simplicity of an **API Key** but only for a subset of all possible API operations.

[GitHub acknowledged this requirement](https://help.github.com/articles/creating-an-access-token-for-command-line-use/) and now provides a way of creating a token with the scopes you need (mimicking the OAuth2 consent):

![](https://images.ctfassets.net/23aumh6u8s0i/6fdGKpvxjgD7seKbyvjb9O/4d82a5cb332aa836d93cb7e3044b5707/token_scopes)

In the next section, we will go through the details of how this can be implemented.

### How to implement it?

We don't know how GitHub implemented it (they probably used Ruby), but we will use it as an example. Let's say we want to implement an endpoint in the API to **create new repos**. You could model this with the following **JSON Web Token** payload. If you provide any of those scopes, then you can create repos:

```
{
  iat: 1416929109, // when the token was issued (seconds since epoch)
  jti: "aa7f8d0a95c", // a unique id for this token (for revocation purposes)
  scopes: ["repo", "public_repo"]  // what capabilities this token has
}
```
_Look at this token in <a href="http://jwt.io?value=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE0MTY5MjkxMDksImp0aSI6ImFhN2Y4ZDBhOTVjIiwic2NvcGVzIjpbInJlcG8iLCJwdWJsaWNfcmVwbyJdfQ.XCEwpBGvOLma4TCoh36FU7XhUbcskygS81HE1uHLf0E" target="_blank">jwt.io</a>_

The API endpoint would simply check for the presence of the right **scope** atribute (this example is written in node.js but any language would work):

```
// intercept all calls to API and validae the token
app.use('/api', express_jwt({secret: SECRET, userProperty: 'token_payload'}));

// for POST /user/repo validate that there is a scope `repo` or `public_repo`
app.post('/api/user/repo',
        check_scopes(['repo', 'public_repo']),
        function(req, res, next) {
    // create a repo
    ....
});

```

Notice the `check_scopes` middleware on the `/api/user/repo` route. This is how the `check_scopes` function is implemented:

```
function check_scopes(scopes) {
  return function(req, res, next) {
    //
    // check if any of the scopes defined in the token,
    // is one of the scopes declared on check_scopes
    //
    var token = req.token_payload;
    for (var i =0; i<token.scopes.length; i++){
      for (var j=0; j<scopes.length; j++){
          if(scopes[j] === token.scopes[i]) return next();
      }
    }

    return res.send(401, 'insufficient scopes')
  }
}

```

> Notice that no one can change the scopes variables. JWTs are digitally signed, so its content cannot be tampered with.  

Documenting an API is equally important. What would be a good way for surfacing this on an API explorer?

For Auth0, we decided to build our own documentation using [swagger](http://swagger.io/). Since we are a multi-tenant system, each tenant has an API Key and Secret that is used to sign the token. As a developer, you mark which scopes you need and a token will be auto-generated. You can copy and paste it to [jwt.io](http://jwt.io) to see the structure (this is the __debuggable__ piece, by the way).

<a href="https://images.ctfassets.net/23aumh6u8s0i/33kBdPt5Hlzt2UEt0yoRQp/e7227bdb1d82dc16fed9a145dc64896b/api-explorer3" target="_blank"><img src="https://images.ctfassets.net/23aumh6u8s0i/7uKm8Sq6OiHUEs5v9AoKT7/3550cf71dfa93c43bbd0eb2b2b2c2191/api-explorer3.gif"/></a>

Scopes required by each operation are clearly identified:

<a href="https://images.ctfassets.net/23aumh6u8s0i/4FDPqZmzwJWGdg9YGSUcEf/5f6ecef62c9d7f3ae0f64edad904a3a1/api-scopes2" target="_blank"><img src="https://images.ctfassets.net/23aumh6u8s0i/4FDPqZmzwJWGdg9YGSUcEf/5f6ecef62c9d7f3ae0f64edad904a3a1/api-scopes2"/></a>

Our token format is a bit different from the one in the example we showed for GitHub. The good thing about JWTs is that they can contain _any_ data structure:

```
{
  iat: 1416929061,
  jti: "802057ff9b5b4eb7fbb8856b6eb2cc5b",
  scopes: {
    users: {
      actions: ['read', 'create']
    },
    users_app_metadata: {
      actions: ['read', 'create']
    }
  }
}
```

The string representation of the scope is `read:users` but in the JSON Web Token, we are using a more structured representation (note the hierarchy), this allows us to be more consistent. It also allows us to have an easy way to extend it for other scenarios.

## Conclusion & Resources

We have shown a new way of securing APIs based on JSON Web Tokens. This approach has some interesting benefits, in particular around _granular security_. In future posts we will go over other aspects, starting with how to revoke tokens.

Below are some of the resources that we used in our node.js backend implementation:

* The [hapi.js](http://hapijs.com) framework to create the API.
* A [fork](https://github.com/auth0/hapi-auth-jwt) of [hapi-auth-jwt](https://github.com/ryanfitz/hapi-auth-jwt) with [support for multitenant apps](https://github.com/ryanfitz/hapi-auth-jwt/pull/10) to handle authentication with JWTs.
* The awesome [ratify](https://github.com/mac-/ratify) library to both validate API input using [JSON schemas](http://json-schema.org) and automatically generate [swagger](http://swagger.io/) from said schemas for our docs.
* Swagger's support for arbitrary [authorizations objects](https://github.com/swagger-api/swagger-spec/blob/master/versions/1.2.md#514-authorizations-object) and a slightly [customized swagger-ui template](https://github.com/swagger-api/swagger-ui#customize) to render the scopes per operation.

If you want to see an example of this working, you can check out our API v2: <https://docs.auth0.com/apiv2>

We would love to hear your thoughts about this approach!

[Discuss here](https://ask.auth0.com/t/using-json-web-tokens-as-api-keys/357)

<include src="asides/Jwt" />

Using JSON Web Tokens as API Keys

eugenio-pace-new-avatar

Pace co-founded Auth0 in early 2013 with CTO and “brother-in-arms” Matias Woloski while living 7,000 miles apart from each other. Since then, Pace has played an instrumental role in growing Auth0 into a leading identity management company that is loved by developers and trusted by global enterprises. He loves traveling and has visited more than 35 countries for business and pleasure. He currently lives in Redmond, Washington with his wife, two sons, and their labrador retriever. In his spare time, he enjoys the outdoors, rowing, riding bikes, spending time with his family, restoring his 1970 Karmann Ghia, writing his blog, and reading history and philosophy.

CEO and Co-Founder

Eugenio Pace

Today Amazon announced a new Login Service, which allows you to connect with millions of their customers

Today Amazon announced [a new Login Service](http://login.amazon.com), which allows you to connect with millions of their customers:

From their [press release](http://phx.corporate-ir.net/phoenix.zhtml?c=176060&p=irol-newsArticle&ID=1824961&highlight=):
> Today, Amazon launched __Login with Amazon__, a new service that will enable the over 200 million active Amazon customers to securely and simply login to apps, games, and websites. Login with Amazon allows developers to easily reduce sign-in friction for their customers, leading to higher engagement and order conversion.

The good news for those using Auth0, is that connecting with Amazon is just a click away. We launched support for Amazon today:

![SSO Amazon](https://images.ctfassets.net/23aumh6u8s0i/1i9UzNljbW660b6J3V2UgQ/5140b7e0b57be3a15622447bf6c7edbf/auth0-amazon-connection)



Auth0 gives you the ability to connect Amazon accounts with _any_ application: web, mobile or native; regardless of what platform it is written on, or what identity protocols it supports. Auth0 supports .NET, Java, Ruby, iOS, Android, Windows, and others with very few lines of code, and minimum intrusion.

And this extends of course to popular apps like __Salesforce__, __Zendesk__, __Dropbox__, __SharePoint__, __MSCRM__, among others. We keep adding popular apps and the list grows quickly!

There are two permission scopes available today in Amazon:

* __Basic Profile__, the default permission that allows you to retrieve the user's name, e-mail and a unique id.
* __Postal Code__, that allows you to retrieve the location of the user.

These two are very easily configured with Auth0 dashboard:

![SSO Amazon](https://images.ctfassets.net/23aumh6u8s0i/5ziOzwL0ROXtyy7UbFQl2y/6310397cd8dbf0a6b7df3f046c6c911d/auth0-amazon-dashboard)

Registration of your instance of Auth0 with Amazon is very straightforward and [fully documented](https://docs.auth0.com/amazon-clientid) right were you need it.

[Try Auth0 yourself!](https://auth0.com)

Authenticate users with Amazon accounts

Supporting SharePoint is a prime scenario in Auth0 and it's fully integrated into it. In this post we show how SharePoint can accept users authenticated

Supporting SharePoint is a prime scenario in Auth0 and it's fully integrated into it. In [this post](http://blog.auth0.com/2013/03/04/On-Premises-SharePoint-Federated-with-Office-365-and-Google/) we show how SharePoint can accept users authenticated in Google and Office365. In [this other one](http://blog.auth0.com/2013/03/07/On-Premises-SharePoint-Federated-with-Partner-AD/) we do the same with a partner using Active Directory.

In this post, we show how easy it is to **configure** SharePoint for claims based authentication.



We have fully integrated the experience into Auth0 control panel so setup is as simple as:

-1. Entering your SharePoint URL
-2. Running the PowerShell scripts we generate for you on your SharePoint box

And that's it!

![SharePoint SAML Federation](https://images.ctfassets.net/23aumh6u8s0i/42Yqn0JZANWEgdlrtxSz5r/5dffe2c889fc75aa502bd979da1ff378/auth0-sharepoint-setup)

Another example of our "just works" approach to identity management in Auth0.

[Try Auth0 yourself!](https://auth0.com)

Automating SharePoint Federation Setup with Auth0

Windows Azure Mobile Services (WAMS) is a really neat technology by Microsoft to get you started very quickly with simple mobile apps.

[Windows Azure Mobile Services](http://www.windowsazure.com/en-us/develop/mobile/) (WAMS) is a really neat technology by Microsoft to get you started very quickly with simple mobile apps. It's a _"Mobile Backend as a Service"_. It also provides a nice extensibility model for more advanced scenarios with server-side JavaScript.

WAMS already ships with support for single-sign-on with social identity providers (e.g Facebook, LiveID), but no support for enterprise providers: Google Apps, Office 365 and Active Directory; or even custom SQL user databases. Even for social providers, it currently doesn't allow finer grain control on what information the user has to consent to disclose.



For Microsoft Accounts (Live ID), for example, WAMS will ask the user for the following rights: name, gender, display picture, contacts and friends. You might not need all these, and you might turn away customers by asking too much.

Auth0 addresses these two issues:

- You can connect to __any__ supported identity provider: social and enterprise
- You have __full control__ on what information to request from your users

![](https://images.ctfassets.net/23aumh6u8s0i/3PlSohd19T8Ct8Hrdv99Hv/a53c2d72fe83a7e0abbab96322bf68d7/auth0-wams-ad-others)

Enabling WAMS integration is as simple as entering the WAMS masterkey in Auth0 (so we can sign the token). That's it!

![Azure Mobile Services Authentication](https://images.ctfassets.net/23aumh6u8s0i/4kZd4JhaDRwt6G7dTbUT7D/58d57576eeaff25b27c55ceefe4ebeee/auth0-wams)

After enabling the add-on, Auth0 will generate JSON Web Token that you can then use to call WAMS endpoints.

This is how it works on a sample test app we wrote:

- John has an account with Fabrikam's Active Directory and is using an iPhone
- John opens an app to query for invoices (and endpoint on WAMS)
- John taps on __Login with Widget__
- Using the Auth0 helper library for iOS, the __Auth0 Login Widget__ is displayed

![iphone SSO](https://images.ctfassets.net/23aumh6u8s0i/756QLiDMNXuho6a4ZMPp7e/54726a86033dcbbae94fa69d970aad50/auth0-wams-ios1)

- John selects Active Directory for the list
- Auth0 sends John to AD for authentication
- Upon successful authentication, Auth0 returns a JWT (seen on the debug screen on top)
- The app calls the WAMS endpoint with the JWT

![iphone SSO](https://images.ctfassets.net/23aumh6u8s0i/MUhmYEZKSyOeDEPFsNXvk/f943894828cd82cc9b4e5a185042792d/auth0-wams-ios2)

The code behind the login process is very straight forward using the helper libraries we ship with __Auth0 SDK__:

	- (IBAction)loginWithWidget:(id)sender
	{
	    Auth0Client *client = [Auth0Client auth0ClientWithWidget:tenant clientId:clientId returnUrl:returnUrl];

    	[client showInViewController:self allowsClose:NO withCompletionHandler:^(BOOL authenticated) {
        	if (!authenticated) {
            	NSLog(@"Error authenticating");
        	}
        	else{
            	self.accessTokenView.text = [client.accessToken copy];
            	jwtToken = [client.jwtToken copy];
            	self.jwtTokenView.text = jwtToken;
        	}
    	}];
	}

All token negotiation is handled by the __Auth0Client__ class. Calling WAMS is equally simple: notice how we are just setting the authentication token to what Auth0 returned in the previous step. The rest of the code is just plain WAMS.

	- (IBAction)getInvoices:(id)sender
	{
    	MSUser *user = [[MSUser alloc] initWithUserId:@"eugeniop"];
    	user.mobileServiceAuthenticationToken = jwtToken;

	    MSClient *client = [MSClient clientWithApplicationURLString:@"https://auth0-tests.azure-mobile.net"];
    	client.currentUser = user;

    	MSTable * invoices = [client getTable:@"invoices"];

    	[invoices readWithCompletion:^(NSArray *items, NSInteger totalCount, NSError *error)
    	{
	        if(error)
	        {
	            NSLog(@"Error");
	        }
	        else
	        {
	            self.invoices.text = [NSString stringWithFormat:@"Got %d invoices", [items count]];
	        }
    	}];
	}

>[Matias'](https://twitter.com/woloski) demo'ed this integration on his webcast on [CloudCover](http://blog.auth0.com/2013/03/03/Real-World-Windows-Azure-with-Auth0-Matias-on-CloudCover/). (see from minute 13 to 19).

[Try Auth0 yourself!](https://auth0.com)

"authenticate"