Abbie Carlson

As a Product Marketing Manager, I'm responsible for communicating the value of Identity for consumer apps as well as focusing on the developer experience. I'm forever curious about how Identity plays a role in our everyday lives as consumers and how a great Customer Identity solution can make or break a business through patron loyalty and retention. 

Outside of work can catch me watching Seattle sports, going to as many concerts as I can or listening to true crime podcasts.

Senior Product Marketing Manager

CX is the new competitive battleground — here’s how CIAM helps you attract, retain, and delight your users.

Today’s digital giants have set new customer experience (CX) standards, and in doing so, they’ve raised customer expectations across the board. For example:

* [Salesforce found that](https://www.salesforce.com/content/dam/web/en_us/www/documents/research/salesforce-state-of-the-connected-customer-fifth-ed.pdf) 73% of customers expect companies to understand their unique needs. (Salesforce, 2022)
* [McKinsey found that](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/five-fundamental-truths-how-b2b-winners-keep-growing) 65% of B2B buyers would switch vendors based on the omni-channel experience. (McKinsey, 2024)
* Okta’s [Customer Identity Trends Report 2023](https://www.okta.com/customer-identity-trends-report/) revealed that nearly 60% of consumers would be more likely to spend money when services offered _“a simple, secure, and frictionless login process,”_ with the much-coveted younger demographic especially favoring such convenient experiences. (Okta, 2023)

Organizations across industries are looking for ways to improve the CX that they deliver, and those at the leading edge are recognizing that a modern customer identity capability is essential for achieving this goal.

![Customer Identity’s Foundational Role in CX](https://images.ctfassets.net/23aumh6u8s0i/1fjzGfRtdlHhMCsxgeDZdp/86223bf45b185cfa9ddee428eefa28b6/CIAM_ecommerce_recorte2.png)

## Customer Identity’s Foundational Role in CX

Customer identity, also known as Customer Identity and Access Management (CIAM), integrates across an organization’s wider technology stack to establish a single, authoritative record of each customer’s identity.

To do so, an effective CIAM implementation fulfills four foundational identity functions:

* **User registration** to create the behind-the-scenes record associated with each user
* **Proper authentication** to establish with confidence that the users logging into accounts are who they say they are, using one or more factors to do so
* **Effective authorization** to provide users with the appropriate level of access to resources, applications, etc.
* **Comprehensive identity management** to enable customers and administrators to make updates and changes to users’ data and access

While these functions may seem straightforward or basic, they provide the essential building blocks for your organization to deliver the modern customer experiences your customers have come to expect.

### Identity flows are fundamental parts of the customer journey

Identity flows are key parts of the customer journey. For example, most organizations with an online presence include the following customer interactions:

* Signing up for your service / registering an account with your organization
* Logging in to their existing account
* Providing you with consent to collect and use their data
* Updating their information and preferences
* Completing a transaction
* Resetting their password

But it isn’t enough simply to implement these flows — it’s critical that you do so in a manner that contributes to (or at least doesn’t detract from) the overall customer experience. Practically speaking, this means crafting streamlined and responsive customer journeys free of unnecessary friction.

### Fighting friction with customer identity

In the digital world, we can consider friction to be anything that slows down or unnecessarily complicates a user’s interactions with your service.

While *some* amount of friction during customer interactions is required (e.g., to provide security controls) and perhaps even welcomed (e.g., to establish trust), unnecessary friction should be minimized or eliminated altogether. To drive home this point, consider that:

* According to [research published by UserPilot](https://userpilot.com/blog/customer-onboarding-statistics-saas/), 74% of potential enterprise customers will switch to other solutions if the onboarding process is complicated. (UserPilot, 2022)
* [A study from the Beryl Institute](https://theberylinstitute.org/wp-content/uploads/woocommerce_uploads/2022/11/The-State-of-PX-2021-igxfyk.pdf) showed that 87% of healthcare patients consider their experience as important as the actual treatment outcomes. (Beryl Institute, 2021)
* And in retail, [a Baymard study](https://baymard.com/lists/cart-abandonment-rate) found that 22% of U.S. consumers abandoned an online cart because of too long, overly complicated checkout processes. (Baymard, 2025)

Compounding the problem, by causing abandonment or by inadvertently driving anonymized interactions (e.g., guest check out), friction undermines your efforts to gather the data needed to build accurate customer profiles — ultimately impairing strategic decisions and negatively impacting acquisition, retention, and overall revenues.

Fortunately, customer identity helps minimize friction in your digital channels and SaaS applications through secure passwordless authentication, progressive profiling for seamless data capture, and optimized backend processing. These measures streamline user interactions, enhancing convenience.

However, providing speedy and convenient experiences only scratches the surface of how CIAM creates positive customer experiences.

Let’s now take a deeper look…

![5 Ways CIAM Creates Great Customer Experiences](https://images.ctfassets.net/23aumh6u8s0i/5rQhP0U1KzmX0aJfsAuZh3/dbc28afb39fa3f557119114372a086bc/CIAM_ecommer_e_recorte1.png)

## Beyond the Basics: 5 Ways CIAM Creates Great Customer Experiences

Simply put, to deliver a customer experience that meets the expectations of today’s users, you need a modern CIAM solution. That’s because customer identity either drives or significantly contributes to many of the (often interrelated) factors that shape a user’s overall experience, including:

1. Personalization
2. Cross-channel consistency and continuity
3. Customer Loyalty
4. Privacy and consent management
5. Fraud prevention and security

### 1. Personalization
As a customer, there’s perhaps no better feeling than dealing with a provider who ‘gets’ you, as an individual, and who uses their familiarity with you to craft an experience that feels tailored.

A prerequisite of such personalization is the single, authoritative customer record that captures all of a user’s relevant information.

But building that record isn’t nearly as straightforward as one might expect. For example:

* Organizations often have many customer entry points and a number of channels
* An individual customer might have provided different contact information to different channels, and their information may change over time; they may also have multiple accounts, perhaps due to losing their login information
* Mergers and acquisitions can lead to significant overlap between customer databases

An effective CIAM implementation creates a single source of truth for customer identity that unifies multiple customer entry points, plus front- and back-end systems. It also provides new options for gathering the zero-party data (ZPD) and first-party data (FPD) that are becoming critical for building accurate customer profiles. Through integration with customer data software like Customer Relationship Management (CRM) systems and Customer Data Platforms (CDPs), as well as analytics tools, customer identity contributes to a richer understanding of your customers — including their preferences, behaviors, and where they may be encountering friction when accessing your services — surfacing and informing opportunities for personalized outreach and continuous improvement.

This unified, accurate, and complete view of customer identity enables seamless identity orchestration, which is required to drive the personalization — special offers, customized interfaces, preferred flows, etc. — that contributes to a positive overall customer experience.

### 2. Omni-channel consistency and continuity
Two things brands that are serious about customer experience do very well are maintaining *consistency* (e.g., of look and feel, of behavior) and *continuity* (e.g., of actions, state, flows, etc.) across their many channels. Implicit within both of these is personalization.

By managing omni-channel identity flows and orchestrating identity through two-way integrations, CIAM goes beyond simply making login experiences familiar across channels. It enables organizations to deliver seamless, consistent, and continuous omni-channel experiences, helping users quickly and conveniently achieve their goals.

### 3. Customer loyalty
Loyalty programs that reward repeat customers and provide incentives for customers to share ZPD and FPD with your organization (to feed the virtuous cycle of personalized rewards) are proven ways to foster long-term relationships. Naturally, CIAM’s ability to link a user’s activity, again, regardless of channel, with their loyalty program membership is essential to such initiatives.

However, the most successful brands recognize that earning loyalty takes more than rewards and other incentives. For example, the factors we’ve examined already — personalization and omni-channel consistency and continuity — are also significant contributors.

However, perhaps the most important factor is trust. In the privacy-conscious age (and in a world in which the availability of third-party cookies is no longer a sure thing), establishing trust and acquiring consent are prerequisites for creating loyalty, as well as for complying with regulations.

### 4. Privacy and consent management
Users take their privacy seriously. In fact, Okta’s [Customer Identity Trends Report 2023](https://www.okta.com/customer-identity-trends-report/) revealed that about 80% of all consumers considered control over their data to be important. (Okta, 2023)

So, how do you build the trust of customers so that they feel comfortable providing their data in the first place? By showing that you’re deserving of their trust.

Customers will only share data and opt in to marketing programs if they feel confident that their data is safe and being used in the way they’ve agreed to, and that sharing it will benefit them in some way — say, by providing more personalized and convenient interactions, regardless of the channel they are using to engage with your brand.

This means that brands that want to build long-term customer loyalty should:

* Be transparent about what data is needed and how it’s used to power a private, secure, and convenient experience
* Capture the customer’s clear, informed consent whenever required to collect and use their data only for that purpose
* Provide customers with tools to manage their preferences

> CIAM is the foundation for all of these things.

For example, CIAM helps you automate consent management by simplifying how consent is requested, stored, and updated across all of your channels. In addition, ensure that your CDP or CRM system only contains data that customers have consented to share for marketing/personalization purposes. This level of clarity and control also helps you easily respond to consumers’ inquiries or proactively communicate policies or policy updates regarding what data you store for them.

#### Contributing to compliance

Because of identity’s essential role in securely connecting users to the technology and resources they need, and its proximity to sensitive data, identity as a domain is governed by an increasing — and increasingly complex — array of data privacy (e.g., HIPAA in healthcare, GLBA in finance, GDPR in the EU, LGPD in Brazil, CCPA/CRPA in California, etc.) and open data sharing regulations and standards (e.g., PSD2, UK Open Banking, the Dodd-Frank Act Section 1033, FDX).

Among other things, these regulations typically require you to:

* Implement effective safeguards to protect credentials, Personally Identifiable Information (PII), Protected Health Information (PHI), and other personal and sensitive data highly valued by cybercriminals
* Put users in control of their own data — how it’s used, by whom, for what — through mechanisms that allow them to share data across digital touchpoints, to provide consent for use, and to take their data with them if they choose to end a relationship with a service provider
* Interoperate within the open data economy — an emerging web of industry (e.g., healthcare, finance) and identity (e.g., social login) ecosystems that will enable vast new consumer value and efficiencies while also preserving data privacy and security.

Through a combination of attributes and capabilities — including centralized management, built-in interoperability, user-friendly identity management features, cutting-edge security measures, and appropriate data management and residency practices — Customer identity can help address the compliance burden, dramatically reducing the costs associated with meeting the many needs of regulations, frameworks, and standards ([Forbes, 2025](https://www.forbes.com/councils/forbesbusinesscouncil/2025/01/29/the-economics-of-identity-security-balancing-cost-and-risk/)).

### 5. Fraud prevention and security
> In today’s threat environment, **Identity is Security**.

For instance, Okta’s [The State of Secure Identity Report 2023](https://www.okta.com/the-state-of-secure-identity-report/) (Okta, 2023) highlights common threats such as signup fraud, credential stuffing, and multifactor authentication (MFA) bypass—challenges faced by nearly every organization with an Internet-facing login box or API. 

At the same time, AI agents are increasingly being used to enhance customer experiences. For example, virtual assistants can streamline customer support by resolving common inquiries, AI-powered recommendation engines personalize user experiences, and automated financial advisors provide real-time investment insights. However, as AI agents access sensitive data and perform critical tasks on behalf of users, organizations must manage the risks of unauthorized access, outdated permissions, and weak authorization controls.

These attacks, both human and non-human, have major consequences for the organizations being targeted, who incur costs to investigate and remediate abuse and who face severe regulatory penalties and reputational damage should a data breach occur. For example, IBM’s [2024 Cost of a Data Breach report](https://www.ibm.com/reports/data-breach) (IBM, 2024) highlights the average cost of a breach across various industries, with costs reaching millions of dollars in sectors ranging from healthcare (with an average breach cost of $9.77M USD).

A robust CIAM implementation creates strong safeguards — before, at, and after login — that aren’t part of your wider security stack, including:

* Host, platform, and application-layer defenses to detect and respond to malicious entities such as bad bots before they can even access the login box or API
* Login-layer defenses that prevent fraudulent signups and account takeovers
* Post-login defenses to secure sessions and authorization controls to manage access (e.g., viewing sensitive information, conducting transactions, updating account info, changing security settings) after a user has authenticated
* Observability tools that allow you to identify potential attacks, quickly respond to them in real time, share information with security operations tools (e.g., SIEM, SOAR, XDR), and optimize your security posture
* Strong encryption, modern hashing algorithms, API security, robust data management, and system access procedures — and much more behind-the-scenes infrastructure

Crucially, a modern CIAM platform can implement these safeguards without introducing unnecessary or overly burdensome friction for users. Plus, an *extensible* CIAM platform can also provide the ability to:

* Engage an [identity proofing solution](https://marketplace.auth0.com/categories/identity-proofing) to verify a user’s real-world identity
* Integrate with [fraud management solutions](https://marketplace.auth0.com/categories/fraud-prevention) to reduce exposure to banking and credit card fraud

Beyond protecting human identities, modern CIAM solutions can also create safeguards for AI agents by providing authentication and authorization frameworks to verify AI identities and their permissions. 

## Wrapping Up

To meet revenue objectives and stay relevant in the digital-first world, organizations of all sizes in virtually all industries need to enable great customer experiences.

At the same time, they also need to comply with strict regulations governing data privacy, customer control, and interoperability — a task made all the more challenging when a company operates in multiple jurisdictions.

Existing at the intersection of customer experience, security, privacy, and analytics — and providing essential tools needed to manage customer identity through the entire lifecycle — CIAM provides an answer.

You can read more about how a modern customer identity infrastructure can support seamless and secure growth in [Why Customer Identity?](https://auth0.com/resources/whitepapers/why-customer-identity)

And if you’d like to learn more about other important CIAM topics, please consider these additional resources:

* [Customer Identity and the extensibility imperative](https://auth0.com/resources/whitepapers/extensibility-imperative)
* [Why Auth0?](https://auth0.com/resources/ebooks/why-auth0-by-okta)

CIAM: The Key to Differentiated Customer Experiences

37590801?s=460&v=4

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

Software Engineer

Dan Arias

Essential practices for securing AI-generated code, key security considerations for your full-stack application, deployment, and infrastructure precautions.

Generate More Secure Code With AI-Powered Tools

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

Staff Developer Advocate

Juan Cruz Martinez

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

An Introduction to MCP and Authorization

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

Take control of your encryption keys using the BYOK security model in your Auth0 tenant.

As the cloud continues to spread and sensitive data is entrusted to service providers, customers wonder how it is protected and how they can exercise control over the security of their data. One way to allow a customer to take control of the confidentiality of their data is to use the Bring Your Own Key (BYOK) approach. In this article, you'll learn what BYOK is and how you can leverage it in Auth0.

## What Is Bring Your Own Key?

Cloud service providers secure customer secrets and data using [envelope encryption](https://en.wikipedia.org/wiki/Hybrid_cryptosystem#Envelope_encryption). This is a proven security mechanism that ensures a high level of protection of customer data using a hierarchy of encryption keys. Specifically, to encrypt data, the cloud provider platform uses Data Encryption Keys that are wrapped by a Root Key. So, to access the Data Encryption Key, a service needs access to the Root Key. Optionally, other intermediate keys can exist between the Data Encryption Keys and the Root Key.

This hierarchy not only enables data protection but also aims at protecting the encryption keys. Encryption and decryption of data are performed by a Key Management System (KMS) that leverages this key hierarchy. In addition, most cloud providers use a Hardware Security Module (HSM) to store the Environment Root Key, ensuring the strongest protection.

In the end, customers' sensitive data are encrypted using the Data Encryption Key, but due to this key hierarchy, only those who have access to the root key of this hierarchy can actually access the unencrypted data.

### Why BYOK?

Usually, the cloud service provider issues and manages the Root Key. Ultimately, the cloud service provider has control over the key hierarchy, the data encryption, and the security of the customer data. However, this is not always the situation that a customer wants. There may be several reasons why a customer doesn't want the cloud service provider to control the Root Key and then the key hierarchy:

- They may need to comply with some key provenance requirements.
- They may need to comply with some data protection requirements.
- They may need to attain control of the lifecycle of the cryptography for users' sensible data.

Think of the financial or healthcare sectors, where data confidentiality is key. In these cases, cloud service providers allow customers to issue and use their own encryption key as the Root Key for the key hierarchy, hence the name **Bring Your Own Key** (BYOK) for this approach to take control of the encryption in a cloud environment.

## BYOK in Auth0

As with any cloud service provider, Auth0 by Okta uses envelope encryption to secure customer data, too. To encrypt data, Auth0 uses Data Encryption Keys that are wrapped by a Tenant Master Key, which in turn is wrapped by the Environment Root Key. Take a look [here](https://auth0.com/docs/secure/highly-regulated-identity/customer-managed-keys#auth0-key-hierarchy) to have more details on the Auth0 key hierarchy.

Auth0 stores the Environment Root Key in a Hardware Security Module (HSM), which is deployed in a highly available, multiple geographic configuration. In other words, the HSM will failover to another region in case of a severe region-wide incident. The HSMs are available for [the two private cloud deployments](https://auth0.com/docs/deploy-monitor/deploy-private-cloud) supported by Auth0 &mdash; AWS and Azure &mdash; with [different encryption algorithms](https://auth0.com/docs/secure/highly-regulated-identity/customer-managed-keys#environment-root-key).

With BYOK, Auth0 allows tenant administrators to securely import their own Root Key to the respective cloud provider's HSM. They can use the Auth0 Dashboard or Management API to replace the Auth0 Environment Root Key with their own Customer Provided Root Key, as you will see in the next section.

> Bring Your Own Key is available on [Enterprise plans](https://auth0.com/pricing) with [Highly Regulated Identity](https://auth0.com/docs/secure/highly-regulated-identity) add-on.

## How to Bring Your Key in Auth0

In this section, you will learn how to import your own encryption key in your Auth0 environment using the Auth0 dashboard. Make sure you have an Enterprise plan with the Highly Regulated Identity add-on to be able to use this feature. Basically, the process consists of three steps:

1. Generate and download a wrapping encryption key from the Auth0 dashboard.
2. Generate your own encryption key and wrap it with the downloaded wrapping encryption key.
3. Upload the wrapped encryption key via the Auth0 dashboard.

For demo purposes, you will use OpenSSL to generate and wrap your encryption key, but in a real-world scenario, you should use an HSM, either on-premises or cloud-based, for key generation.

> Make sure you have [OpenSSL](https://www.openssl.org/) installed on your machine. If you have a macOS machine, be aware that it ships with [LibreSSL](https://www.libressl.org/), which is a fork of OpenSSL and has some differences.

### Get the wrapping encryption key

The first step is to get the wrapping encryption key from Auth0. Go to your [Auth0 dashboard](https://manage.auth0.com), click the *Settings* menu item, and select the [Encryption Keys](https://manage.auth0.com/#/tenant/encryption_keys) tab. You will see the following screen:

![Encryption keys management in the Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/3PBjaL5gFyc2iULvFb8ZSk/ad53ccc8484a587cdbea4ed60dec1efd/auth0-dashboard-encryption-keys.png)

Now, click the *Upload Key* button and you will get the modal shown below:

![Download Auth0 wrapping encryption key](https://images.ctfassets.net/23aumh6u8s0i/2ED5p9T6aUpnWPZkGffLcn/ac4069f77c95709a1034d6c80bc3bbef/download-wrapping-encryption-key.png)

Click the *Download* button to get the wrapping encryption key from Auth0. This ensures that your own key will be securely transferred to Auth0.

> Until you have uploaded your own key, Auth0 will continue to use the built-in Environment Root Key.

### Generate and wrap your own key

If you are using a Hardware Security Module to generate your key, follow its specific instructions. For test purposes, we are using Open SSL here, which requires some preprocessing of the content of the PEM file you downloaded from Auth0, the key generation, and then the actual key wrapping. Let's examine each step.

#### Preprocess the wrapping key

Open the file with a text editor and manually remove the PEM header and footer, i.e., the `-----BEGIN PUBLIC KEY-----` and `-----END PUBLIC KEY-----` strings. Then, remove all the line breaks in the file. The result will be a one-line file with the bits of the key.

Now, decode the content of this file from Base64 to binary. In Linux-based systems and macOS, you can use the [`base64`](https://www.gnu.org/software/coreutils/manual/html_node/base64-invocation.html) builtin tool as shown in the following example:

```bash
cat wrapping-key.pem | base64 -d > wrapping-key.bin
```

Assuming that your Base64-encoded file is named `wrapping-key.pem`, the previous command generates the binary decoded version into the file named `wrapping-key.bin`.

On Windows systems, you can use the [`certutil`](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil) tool as follows:

```powershell
certutil -decode wrapping-key.pem wrapping-key.bin
```

#### Generate your own key

Each [cloud provider has its own requirements](https://auth0.com/docs/secure/highly-regulated-identity/customer-managed-keys/customer-managed-keys-dashboard#cryptographic-material-requirements) for the key you should generate, so you should use the appropriate settings for the [CKM\_RSA\_AES\_KEY\_WRAP](https://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/cos01/pkcs11-curr-v2.40-cos01.html#_Toc408226894) algorithm parameters.

Assume you are using AWS as your Auth0 cloud provider in our example. You can generate your 32 bytes (256 bits) symmetric key as follows:

```bash
openssl rand -out customer-key-material-key.bin 32
```

You also need a 32 bytes-long ephemeral AES encryption key that is required for AES Key Wrap with padding step:

```bash
openssl rand -out ephemeral-aes-kek-kwp.bin 32
```

Now you have two new files:

- `customer-key-material-key.bin`, which contains your symmetric key that will be used instead of the Auth0 Environment Root Key. Let's call it the *customer key*.
- `ephemeral-aes-kek-kwp.bin`, which contains another symmetric key that will be used to wrap the *customer key*, as [required by AWS](https://auth0.com/docs/secure/highly-regulated-identity/customer-managed-keys/customer-managed-keys-dashboard#auth0-on-aws-cloud). Let's call it the *ephemeral key*.

#### Wrap your own key

Let's start by wrapping the *customer key* with the *ephemeral key*. Use the following command:

```bash
openssl enc -id-aes256-wrap-pad \
        -K "$(xxd -p < ephemeral-aes-kek-kwp.bin | tr -d '\n')" \
        -iv A65959A6 \
        -in customer-key-material-key.bin \
        -out customer-key-material-wrapped.bin
```

You will get the `customer-key-material-wrapped.bin` file.

Now, wrap the *ephemeral key* with the wrapping key you downloaded from Auth0 and preprocessed earlier:

```bash
openssl pkeyutl \
    -encrypt \
    -in ephemeral-aes-kek-kwp.bin \
    -out ephemeral-aes-kek-kwp-wrapped.bin \
    -inkey wrapping-key.bin \
    -keyform DER \
    -pubin \
    -pkeyopt rsa_padding_mode:oaep \
    -pkeyopt rsa_oaep_md:sha256 \
    -pkeyopt rsa_mgf1_md:sha256
```

The result of this command will be the `ephemeral-aes-kek-kwp-wrapped.bin` file.

As the final step, concat the two wrapped files you generated and encode the result with Base64:

```bash
cat ephemeral-aes-kek-kwp-wrapped.bin customer-key-material-wrapped.bin | base64 > encrypted-key-material-b64
```

The file `encrypted-key-material-b64` is the file you will upload to Auth0 to complete the BYOK process.

### Upload your newly created Root Key

Go back to your Auth0 dashboard and follow the steps again to open the modal to upload the key. This time, click the *Choose File* button and select the `encrypted-key-material-b64` file you created in the previous step:

![Upload customer key to complete BYOK](https://images.ctfassets.net/23aumh6u8s0i/5MSJvTULvP0zSYga5Nzjhq/22c95f9d6faa2e2a3a7ad27c457cc647/upload-customer-key-byok.png)

Click the *Save* button to complete the BYOK process.

Congratulations! Now Auth0 will be using your own encryption key as your Environment Root Key:

![Auth0 dashboard with BYOK enabled](https://images.ctfassets.net/23aumh6u8s0i/6cKLg7wB5TYxqGRL8WRfGr/3b4a64b4d61ce3cff640f46ccddbfd5a/auth0-dashboard-with-byok-enabled.png)

> Keep in mind that by importing your own encryption key, you implicitly deauthorize Auth0 from managing the lifecycle of the Environment Root Key. This means that now you are in charge of rotating the key periodically.

## Automate the Key Generation and Wrapping

As you can see, there are a few manual steps to generate and wrap the encryption key to upload to Auth0. Fortunately, you can blend it all into one script as the following (only for Bash):

```bash
#!/bin/bash

# Check if a .pem file is passed as an argument
if [ -z "$1" ]; then
    echo "Usage: $0 <path to pem file>"
    exit 1
fi

PEM_FILE="$1"

#Ensure the file exists
if [ ! -f "$PEM_FILE" ]; then
    echo "File not found: $PEM_FILE"
    exit 1
fi

#1. Remove the first line (BEGIN CERTIFICATE)
#1. Remove the last line (END CERTIFICATE)
#1. Remove  all line breaks
#4. Remove any trailing characters like whitespace

CERT_DATA=$(sed '1d;$d' "$PEM_FILE" | tr -d '\n\r' | tr -d ' ')


if [ -z "$CERT_DATA" ]; then
    echo "Cleaned certificate is empty"
    exit 1
fi


echo "Processed certificate data: $CERT_DATA"

PUBLIC_WRAPPING_KEY=public-wrapping-key.bin

printf "%s" "$CERT_DATA" | base64 -D  > $PUBLIC_WRAPPING_KEY

if [ ! -f "$PUBLIC_WRAPPING_KEY" ]; then
    echo "Public Wrapping key file does not exist"
    exit 1
fi

openssl_operations() {
    echo "Running OpenSSL..."

    openssl rand -out customer-key-material-key.bin 32
    openssl rand -out ephemeral-aes-kek-kwp.bin 32
    openssl enc -id-aes256-wrap-pad \
        -K "$(xxd -p < ephemeral-aes-kek-kwp.bin | tr -d '\n')" \
        -iv A65959A6 \
        -in customer-key-material-key.bin \
        -out customer-key-material-wrapped.bin

    openssl pkeyutl \
    -encrypt \
    -in ephemeral-aes-kek-kwp.bin \
    -out ephemeral-aes-kek-kwp-wrapped.bin \
    -inkey public-wrapping-key.bin \
    -keyform DER \
    -pubin \
    -pkeyopt rsa_padding_mode:oaep \
    -pkeyopt rsa_oaep_md:sha256 \
    -pkeyopt rsa_mgf1_md:sha256

    cat ephemeral-aes-kek-kwp-wrapped.bin customer-key-material-wrapped.bin | base64 > encrypted-key-material-b64 

    rm customer-key-material-key.bin ephemeral-aes-kek-kwp.bin customer-key-material-wrapped.bin ephemeral-aes-kek-kwp-wrapped.bin public-wrapping-key.bin

    # echo "$DECODED_CERT" | openssl ...
}

openssl_operations
```

This simplifies the generation and wrapping steps, making the process more straightforward, as you can see in the following video:

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

<NonAmpContent>
<div
  className='embed-container'
  style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;">
    <iframe
      style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"
      src='https://www.youtube.com/embed/InbHi6fRMKo'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>

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

## Conclusion

This article showed you how Auth0 supports Bring Your Own Key, an approach that lets you control the provenance of the root key used to encrypt your secrets and data in the Auth0 environment.

You used OpenSSL as a testing tool to generate and wrap your own key and learned how to use the Auth0 dashboard to configure your environment with it.

A special thanks to Filip Palach and Lucas Gomes for their work on the OpenSSL process and the script.

If you want to learn more about BYOK in Auth0, leave a message below.


Bring Your Own Key (BYOK) in Auth0

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

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

## When a Client Secret Is Not Enough

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

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

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

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

## Private Key JWT Authentication

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

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

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

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

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

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

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



## Highly Regulated Identity and Private Key JWT Authentication

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

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

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

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

## The Sample Project

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

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

You will get two .NET projects:

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

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

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

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

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

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

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

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

## Create and Register Your Public Key

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Get Your Access Token

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

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

```json
// HealthCheckWebApp/appsettings.json

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

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

```csharp
// HealthCheckWebApp/Program.cs

// ...existing code...

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

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

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

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

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

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

## Credential Rotation

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

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

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

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

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

## Summary

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

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

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

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



Use Private Key JWTs to Authenticate Your .NET Application

eric wu

With over 7 years of experience in product marketing, I am passionate about creating and delivering impactful marketing strategies that drive customer value, business growth, and competitive differentiation. I have a strong background in launching new products, especially in Security, Generative AI and Cloud domains, where I have led several successful end-to-end product releases. I currently work as a Senior Product Marketing Manager at Okta, a leading identity and access management platform that empowers organizations to securely connect their people and technology.

Product Marketing Manager - Customer Identity Cloud

Eric Wu

SaaStart allows devs to easily explore, gain experience with, and demonstrate key Customer Identity functionality

Getting started with Customer Identity and Access Management (CIAM) — especially for B2B SaaS apps — can be intimidating. What began as a fairly straightforward login box has grown into a comprehensive set of capabilities encompassing authentication, authorization, user lifecycle management, federation, and Identity security — all of which must comply with [a daunting array of ever-evolving regulations and standards](https://auth0.com/security).

At the same time, there’s no substitute for learning through hands-on experience. But the reality is that devs are already under enough time constraints and don’t always have the luxury of building sandboxes or proofs-of-concept from scratch.

That’s why we’re excited to unveil [SaaStart](https://saastart.app/), a reference B2B SaaS application built using Next.js and Auth0 by Okta.

Intended primarily for developers building B2B SaaS apps, [SaaStart](https://saastart.app/) provides a fast, safe, and accessible way for devs to explore, experiment, and get up and running with Customer Identity. You can easily deploy a sample Auth0 template from within [the SaaStart GitHub repository](https://github.com/auth0-developer-hub/auth0-b2b-saas-starter).

## Get Hands-on with Customer Identity

In Identity terms, essential features of an effective B2B CIAM solution include:

* **User registration**, to create the record that makes everything else possible
* **Authentication,** to establish with confidence that the users logging into accounts are who they say they are, using one or more factors to do so
* **Authorization,** to help organizations provide a user with the appropriate level of access to resources or applications
* **Delegated administration,** to enable customers and administrators to make updates and changes to users’ data and access

But — just as describing a car as a combination of engine, drivetrain, wheels, and steering mechanism is woefully insufficient at capturing what you can do with one or how to build one — simply summarizing these Identity elements doesn’t come close to telling the CIAM story.

To help fill in the blanks with practical experience, [SaaStart](https://saastart.app/) allows devs to explore CIAM within the look, feel, and functionality of a modern B2B SaaS application.

Using [SaaStart](https://saastart.app/), devs can get hands-on with:

* **Multi-tenant access control,** including administrative roles with control over the app’s configuration

![SaaStart](https://images.ctfassets.net/23aumh6u8s0i/19r62j5wQAyA9WaC03j62T/d4bc78054cbb4e4843d5154a4b8261be/Uploaded_from_Speed_up_Your_Customer_Identity_Journey_with_Auth0_SaaStart)

![SaaStart](https://images.ctfassets.net/23aumh6u8s0i/2g4TA8C7AkVObsBT9LTx4t/57a14e32fb52f571d52db9503c9b0653/Uploaded_from_Speed_up_Your_Customer_Identity_Journey_with_Auth0_SaaStart)

<br>

* **Log-in options for the modern extended workforce,** including Single Sign-On (SSO) for enterprise employees and email-based authentication for early adopters and smaller customers without their own Identity Providers

![SaaStart](https://images.ctfassets.net/23aumh6u8s0i/2HdILnTFaOOb7jfePCuJhG/57087f523ecea46c6a8ee89e5f13d6f0/Uploaded_from_Speed_up_Your_Customer_Identity_Journey_with_Auth0_SaaStart)

* **Security policies,** from enforcing a range of Multi-Factor Authentication (MFA) options and domain-based SSO to configuring session timeouts

![SaaStart](https://images.ctfassets.net/23aumh6u8s0i/35qq2OrUXesaKoxdSyX3ww/5990471670bd41b204cfe0b8d742ba8f/Uploaded_from_Speed_up_Your_Customer_Identity_Journey_with_Auth0_SaaStart)

* **User provisioning,** including just-in-time provisioning or automated user management using the System for Cross-Domain Identity Management (SCIM) - _coming soon_

* **API client management** with self-service create/delete capabilities - _coming soon_

## Everything Developers Need to Implement Customer Identity

SaaStart is just a taste of what’s possible with Auth0 by Okta.

With 10+ years as a pioneer in the CIAM space, we’ve leveraged cutting-edge technologies and architectures to create [a modern solution with an impressive collection of features and functions](https://auth0.com/blog/why-auth0-by-okta/).

Whether you’re building a B2C, B2B, or Hybrid application, Auth0 provides the foundational requirements out of the box with broad support for [open standards](https://auth0.com/learn/how-auth0-uses-identity-industry-standards) and a range of developer resources — including [Quickstarts](https://auth0.com/docs/quickstarts), [APIs](https://auth0.com/docs/api), and [30+ SDKs](https://auth0.com/docs/libraries).

In fact, with a few lines of code, you can integrate Auth0 into any app written in any language and any framework.

Plus, we’re proud to offer a number of discounted offerings that can help you get started and — thanks to a long list of features — are often sufficient for the longer term:

* Self-service options, including a [free trial plan](https://auth0.com/signup) that lets you get off the ground with up to 7,500 active users and unlimited logins — while also including social login, DB connection for securely storing Identity information, branded login, extensibility, and security capabilities (brute force and suspicious IP throttling), support for five regions (US, UK, EU, JP, AUS), and even passkeys
* [Auth0 for Startups](https://auth0.com/startups), which brings the convenience and security of Auth0 to eligible startup customers so they can focus on their core value propositions rather than spending more time than is necessary on Identity
* Our [Nonprofit Offering](https://auth0.com/nonprofits/get-started), which provides preferential pricing that makes the leading Identity service even more accessible to organizations on a mission to make the world a better place

## Speed up Time-to-Market with Auth0

We understand that developers would rather spend their time solving hard problems and leveraging their creative side to build really fun solutions. Auth0 enables you to do those by offloading some of the more mundane and frankly dull parts of creating a standards-based CIAM solution.

And [there’s ample evidence](https://auth0.com/customers) that outsourcing Customer Identity is the prudent approach. For instance, Okta’s 2023 report [How Development Teams Purchase SaaS](https://www.okta.com/resources/whitepaper-how-development-teams-purchase-saas-report/thankyou/) revealed that:

* **Authentication takes the third-most time and work to build and maintain in-house**, behind only “data management and storage” and “DevOps tooling and automation.”
* **Third-party authentication reduces time to market more than any other SaaS component** — 88% of organizations that use a third-party SaaS platform for authentication report reducing time to market

We invite you to visit our [Developer Center](https://developer.auth0.com/) to learn about Auth0, explore tutorials, download code samples, connect with us, find resources, and more.

If you have feedback about SaaStart or suggest other features to explore in future versions or new apps, please drop us a comment or open an issue on [the GitHub repo](https://github.com/auth0-developer-hub/auth0-b2b-saas-starter).

<include 
    src="LinkCard" 
    title="A B2B SaaS Application Primer Using Auth0" 
    link="https://auth0.com/blog/b2b-saas-application-primer-using-auth0/" 
    description="Are you building a B2B SaaS application using Auth0? Then check out our primer for more on delivering IAM functionality using the Auth0 Organizations feature."
img="https://images.ctfassets.net/23aumh6u8s0i/44Jbuzdh6CvHDaCJ6LJNLh/2a8d0114b1bd7b03a92a386cced73e6b/square-hero.jpg"
/>

Speed up Your Customer Identity Journey with Auth0 SaaStart

jimena-garbarino

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

Spring Cloud Developer

Jimena Garbarino

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

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

sofia-prosper

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

Senior Developer Advocate and Partner Manager of the Auth0 Marketplace

Sofía Prósper Díaz-Mor

Eutelo Pena

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

Head of Product at Alice Biometrics

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

## Introduction

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

## The Power of Facial Biometrics

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

### Face Recognition

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

### Face Liveness Detection

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

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

## How Facial Biometrics Enhance Businesses Processes

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

### Digital Onboarding

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

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

### Authentication

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

### Bot Prevention

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

### Account Recovery

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

### Password Reset

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

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

## Adding Security to Business Processes

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

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

## Conclusion

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

Facial Biometrics: The Key to Digital Transformation and Enhanced Security

Pradheepa Pullanieswaran

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

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

## Introduction

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

## Key Features of WebAuthn

### Phishing resistant

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

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

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

### Seamless user experience

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

## WebAuthn Roles

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

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

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

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

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

## How WebAuthn Works

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

### Registration flow

#### A User visits a website

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

#### Initiating registration

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

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

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

#### The Authenticator sends back the user credentials

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

#### The Website stores the user credential

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

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

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

### Authentication flow

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

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

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

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

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

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

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

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

## How to Implement the WebAuthn API

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

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

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

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

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

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

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

```

The following section describes each variable in detail.

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

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

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

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

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

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

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

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

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

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

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

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


```

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

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

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

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

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

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

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

The following section describes each variable in detail.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Conclusion

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

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

WebAuthn - A Short Introduction

alisa-duncan

Alisa Duncan is a Senior Developer Advocate at Okta, a full-stack developer, and a community builder who loves the thrill of learning new things. She is a Google Developer Expert in Angular and organizes coding workshops and community events locally and internationally. Her background is primarily working on enterprise software platforms, and she is a fan of all things TypeScript and JavaScript.

Senior Developer Advocate

Alisa Duncan

OAuth 2.0 provides a more secure model than API keys for machine-to-machine communication. Learn why.

Why You Should Migrate to OAuth 2.0 From API Keys

A walk-through of building a microservices architecture with JHipster, Keycloak, Auth0, and Google Kubernetes Engine (GKE) deployment.

Identity in Spring Boot with Kubernetes, Keycloak, and Auth0

Samuel Frank

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

Senior Product Manager

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

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

## How Web3Auth is an Advance in Web3 Usability

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

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

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

This solution provides a developer:

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

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

## How It Works

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

### Regular Web Application Flow

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

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

### Setup Steps

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

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

## What's Next?

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

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

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

manfred

Under the leadership of Manfred Steyer, ANGULARarchitects.io supports companies with the implementation of web-based business applications with Angular. <br>
 
At the Angular seminars he designs, he combined his profound knowledge of Angular, for which he was recognized by Google as a Google Development Expert (GDE), with his experience, which he worked as a team leader in the field of software development, as a Professor at a university of applied sciences and as an external member of the Angular team. <br>
 
Manfred has published books at O'Reilly, Microsoft Press, and Hanser and writes for Heise Online, windows.developer, and the Java magazine. He also regularly shares his knowledge at conferences.

Trainer and Consultant with focus on Angular

Manfred Steyer

Module Federation allows loading Micro Frontends at runtime. Common dependencies like Angular or the Auth0 library can be shared and hence don't need to be loaded several times. This is also the key for sharing data like the current user or global filters.

**TL;DR:** Module Federation allows loading Micro Frontends at runtime. Common dependencies like Angular or the Auth0 library can be shared and hence don't need to be loaded several times. This is also the key for sharing data like the current user or global filters.

## Micro Frontends

Recently, there have been a lot of discussions about Micro Frontends. The underlying idea is quite tempting: Splitting a huge software system into smaller parts and assigning each part to an individual team:

![Each micro frontend can be developed by an autarkic team](https://images.ctfassets.net/23aumh6u8s0i/38DpehwkPwiMTNBOvOQowG/ce345e71277e19f211f23add38a0ae4e/microfrontends.png)

As these teams are -- more or less -- autonomous, they can work in a more flexible way and don't need to coordinate that much with others. This shows that Micro Frontends are mostly about scaling teams. Hence, if you don't have several frontend teams, Micro Frontends might be overkill. 

## Module Federation

Splitting software systems into several parts is, however, only one side of the coin. Even though we developers might like this idea, the users don't! They aren't interested in starting several frontends but expect an integrated solution. 

Accordingly, we need to find a way to make all our micro frontends appear as one (single page) application. Very often, this involves loading micro frontends into a shell application.

For instance, the example used here mimics a simple shopping system. One of its micro frontends deals with shipping:

![Example micro frontend dealing with shipping products](https://images.ctfassets.net/23aumh6u8s0i/3Zs0it0naO2U4W1GwBMpNn/caa76eb2a246ab2dfa5d5394c6ed89c5/example-shipping.png)

For the purpose of integration, this micro frontend needs to be loaded into a shell:

![Example of a shell loading the shipping micro frontend](https://images.ctfassets.net/23aumh6u8s0i/iJOA5Lg4AHYGHBt0SK06U/8bdb25c11b8ac571f259f57217ff72eb/example-shipping-in-shell.png)

The shell loads this but also other micro frontends on demand.

For such an implementation, you needed a lot of tricks in the past. Fortunately, Module Federation makes this task straightforward. 

Module Federation is an integrated part of webpack 5, and hence, it works with all modern web frameworks. Also, as webpack is highly used in nearly all communities, Module Federation immediately becomes a widespread solution.

In order to allow loading separately compiled and deployed micro frontends, Module Federation defines two roles: the host and the remote:

![Schematic representation of Module Federation](https://images.ctfassets.net/23aumh6u8s0i/6RTBbIScEwfnZm97MMe7nJ/2138d86c99a988b286f9852d020097a4/module-federation.png)

In our case, the host is the shell, while the remote is the micro frontend. Both can be configured with their webpack configurations. 

The host defines virtual URLs pointing to remotes. In the previous picture, for instance, the URL ``mfe1`` pointing to a micro frontend, also called ``mfe1``, is defined.

The remote, in turn, exposes files -- or, to be more precise: EcmaScript modules -- for the host. To prevent that, the latter one needs to know the remote's file structure; exposed files can get a shorter alias. The example in the last picture goes with the alias ``Cmp``. 

Exposed EcmaScript modules can easily be loaded into the host by using a dynamic ``import`` together with the mapped URLs and defined aliases. The best: From Angular's perspective, this is just like lazy loading. 

As Angular doesn't even recognize that the application loads a micro frontend, we can use it exactly as it was intended to be used. We don't need any tricks or meta frameworks orchestrating different SPAs in our browser window. This eases our endeavor dramatically.

## Module Federation in Angular

Since version 12, the Angular CLI uses webpack 5. Hence, we also get Module Federation out of the box. To activate it, we need a custom builder that, e. g. ships with the community solution ``@angular-architects/module-federation``. As it comes with respective schematics, you can easily ``ng add`` it to your CLI workspace:

```bash
ng add @angular-architects/module-federation
```

![Adding @angular-architects/module-federation to your project](https://images.ctfassets.net/23aumh6u8s0i/3eoqQDVCE5OK0QfzoYmXt8/378fda04d26bd28ffc798754f3150819/ng-add.png)

The well-known CLI extension [Nx](https://nx.dev/) is supported too. The schematic asks about the name of the project in your workspace you want to enable module federation for. Also, it asks which port to assign for ``ng serve``.

After that, it generates several files, e. g. a partial webpack configuration we need to adjust for our needs. Also, it registers the custom builder in our ``angular.json``.

For the example used here, I ran this command twice: Once for the shell and once for the above-shown shipping micro frontend. The latter one is just called ``mfe1`` here.

## Configuring the Micro Frontends

Now, we need to adjust the webpack configurations generated for the shell and the micro frontend. As the Angular CLI is generating most parts of the webpack configuration, we just need to define the remaining details for the module federation. First and foremost, this is about configuring the ``ModuleFederationPlugin`` that ships with webpack.

Let's start with the configuration for the micro frontend:

```javascript
// projects/mfe1/webpack.config.js

[...]
plugins: [

  new ModuleFederationPlugin({
    
      // For remotes (please adjust)
      name: "mfe1",
      filename: "remoteEntry.js",
      exposes: {
          './AddressModule': './projects/mfe1/src/app/address/address.module.ts',
      },        
      
      shared: share({
        "@angular/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
        "@angular/material": { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: true },

        ...sharedMappings.getDescriptors()
      })
          
  }),
],
[...]
```

The property ``name`` is normally the project name and should be unique across all micro frontends. The ``filename`` points to a file webpack generates when building the project. It's often referred to as the remote entry point. This JavaScript file provides all the metadata the shell needs to know for loading the micro frontend.

While normally you can go with the generated values for ``name`` and ``filename``, you very likely need to adjust the ``exposes`` section. As discussed above, it contains the aliases for the files to expose.

With ``shared``, you define all the npm packages you want to share across the shell and the micro frontends. These packages are only loaded once at runtime. This is vital because having ten micro frontends doesn't mean you want to load Angular or other packages ten times!

Of course, when sharing packages at runtime, we might end up with version conflicts. Fortunately, Module Federation also got us covered here: It provides several strategies for dealing with version mismatches. 

In our case, the combination of ``singleton: true`` and ``strictVersion: true`` is used. Hence, only one version of the shared packages is allowed, and if Module Federation detects several versions at runtime, it throws an Error. While this seems to be quite harsh at first sight, it allows our integration tests to immediately find out about version mismatches.

More details on [strategies for preventing version mismatches](https://www.angulararchitects.io/en/aktuelles/getting-out-of-version-mismatch-hell-with-module-federation/) can be found [here](https://www.angulararchitects.io/en/aktuelles/getting-out-of-version-mismatch-hell-with-module-federation/).

Besides ``singleton`` and ``strictVersions``, there are two further properties used: ``requiredVersion`` and ``includeSecondaries``. If we set the first one to ``auto``, ``@angular-architects/module-federation`` assumes the version found in your project's ``package.json``. This avoids several [pitfalls](https://www.angulararchitects.io/aktuelles/pitfalls-with-module-federation-and-angular/). 

The option ``includeSecondaries`` is provided by ``@angular-architects/module-federation`` too. It automatically adds all secondary entry points to the list of shared libraries. In the case of libraries like Angular Material, this saves you a lot of typing as they provide one such entry point per component, e. g. ``@angular/material/input`` or ``@angular/material/button``.

Now, let's have a look at the exposed ``AddressModule``: 

```typescript
// projects/mfe1/src/app/address/address.module.ts

[...]

@NgModule({
  imports: [
    [...]
    RouterModule.forChild([{
      path: 'address', 
      component: AddressComponent
    }])  
  ],
  declarations: [
    AddressComponent
  ],
})
export class AddressModule { }
```

As you see, it's just an ordinary Angular module. However, as it has child routes, we can immediately route to them after loading the whole module into the shell. 

## Configuring the Shell

The shell's ``webpack.config.js`` is a bit simpler. Here, we only need to define the shared libraries:

```javascript
// projects/shell/webpack.config.js

[...]
plugins: [
  new ModuleFederationPlugin({

      shared: share({
        "@angular/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
        "@angular/material": { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: true }

        ...sharedMappings.getDescriptors()
      })
      
  }),
],
[...]
```

In addition, we also could map URLs here, as outlined above. This would look like this:

```typescript
// Alternative that maps URLs upfront
new ModuleFederationPlugin({
  remotes: {
    "mfe1": "mfe1@http://localhost:3000/remoteEntry.js"
  },
  [...]
})
```

The key is the mapped URL, and the value defines the name of the micro frontend as defined in its ``webpack.config.js``. Here, the value also contains the location of the micro frontend's remote entry point. To load ``mfe1``'s exposed Module, we could use a dynamic ``import``:

```typescript
// Using mapped URL:
import('mfe1/AddressModule')
```

As the TypeScript compiler doesn't know the file ``mfe1/Module``, we also needed a type definition. For this, we could create an arbitrary with the ending ``.d.ts``:

```typescript
declare module "mfe1/AddressModule";
```

However, while mapping URLs this way is simple, it also requires us to know about the micro frontends and their locations upfront. Hence, I'm using a more dynamic approach that does not demand us to define URLs for compile time. 

Instead, we can tell Module Federation about possible Micro Frontends at runtime. To make use of it, I use the helper function ``loadRemoteModule`` provided by ``@angular-architects/module-federation`` together with lazy routes:

```typescript
// projects/shell/src/app/app.module.ts

[...]
RouterModule.forRoot([
  {
    path: '',
    component: HomeComponent
  },
  {
    path: 'mfe1',
    loadChildren: () => loadRemoteModule({
      remoteEntry: 'http://localhost:3000/remoteEntry.js',
      remoteName: 'mfe1',
      exposedModule: './AddressModule',
    }).then(m => m.AddressModule)
  }
])
[...]
```

The ``loadRemoteModule`` function takes the location of the remote entry point, the remote's name, and the alias of the exposed EcmaScript module. All these values are defined in the micro frontend's webpack configuration. 

As these properties are just strings, we could even retrieve their values from a configuration file or from a service endpoint.

## Trying It Out

After starting both projects, e. g. with ``ng serve shell, `` and ``ng serve mfe1``, we can use the lazy route shown above to load the micro frontend into the shell. It's also interesting to inspect the loaded files in your browser's dev tools:

![The browser loads the shared libraries](https://images.ctfassets.net/23aumh6u8s0i/5YzAFolOzvMYTspPsgZ5Wb/73d1fb9772e1128fca2eca404a1aa0ce/share.png)

At first sight, it really looks like lazy loading. However, when looking more closely, we see that the lazy chunks come from the micro frontend's origin. Also, for all the shared libraries, a bundle of its own is loaded. This is necessary because the module federation decides at runtime when to load which shared package. 

## Authentication for Micro Frontends

Sometimes we need to share some information between micro frontends and the shell, e. g. context information like the current user or global filters like the selected customer. The example used here allows logging in the user via the shell:

![Logging in the current user](https://images.ctfassets.net/23aumh6u8s0i/2XumqnUE2Cp56cB0nWJt2w/37480acbfca69c8036e36d38b94fbcd2/logged-in.png)

However, when loading the micro frontend on demand, it also knows about the current user:

![Sharing information about the logged in user](https://images.ctfassets.net/23aumh6u8s0i/2BdJ84YhuAxliC349B9A2Q/6294f33fd3d8b940789da984d41efe8c/logged-in-shipping.png)

To achieve this, we just need to share a package that holds the information to share. In our case, this is ``@auth0/auth0-angular`` as we are using Auth0 as our identity provider. It's available via npm:

```bash
npm i @auth0/auth0-angular
```

To make this work, I've configured a web application at https://manage.auth0.com/. If you want to try this out, don't forget to register your SPA's URL, e. g. http://localhost:4200, under _Allowed Callback URLs_. Besides this, I went with the default values proposed by the web portal.

To get started, we need to import the ``AuthModule`` provided by ``@auth0/auth0-angular`` into the ``shell``'s but also into ``mfe1``'s ``AppModule``:

```typescript
// projects/shell/src/app/app.module.ts
//  and
// projects/mfe1/src/app/app.module.ts

[...]

import { AuthModule } from '@auth0/auth0-angular';

[...]

@NgModule({
  imports: [
    AuthModule.forRoot({
      domain: 'dev-ha-6vf7s.us.auth0.com',
      clientId: 'pQXuZGn3bfOfHpFd9ch7Wfa4xP4KhKlS'
    }),
    [...]
  ],
  [...]
})
export class AppModule { }
```

The values for ``domain`` and ``clientId`` can be found at https://manage.auth0.com after registering your application.

After that, we can use the ``AuthService`` in the shell to login the current user:

```typescript
// projects/shell/src/app/home/home.component.ts

import { Component } from '@angular/core';
import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.scss']
})
export class HomeComponent {

  user$ = this.auth.user$;

  constructor(private auth: AuthService) {}

  login(): void {
    this.auth.loginWithRedirect();
  }

}
```

I also decided to display the user's name after they logged in:  

```html


<h1>Welcome!</h1>

<p *ngIf="user$ | async as user">
    User: {{user.name}}
</p>

<div>
    <button (click)="login()" mat-flat-button color="primary">Login</button>
</div>
```

In the micro frontend's ``AddressComponent``, I'm also using the ``AuthService`` to get some information about the current user:

```typescript
// projects/mfe1/src/app/address/address.component.ts

[...]

import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-address',
  templateUrl: './address.component.html',
  styleUrls: ['./address.component.scss']
})
export class AddressComponent {

  [...]

  constructor(
    private auth: AuthService,
    private fb: FormBuilder) {

    this.auth.user$.pipe(take(1)).subscribe(user => {
      if (!user) return;
      this.addressForm.controls['firstName'].setValue(user.given_name);
      this.addressForm.controls['lastName'].setValue(user.family_name);

    });

  }

  [...]
}
```

In order to make this work, we need to share the ``@auth0/auth0-angular`` package:

```javascript
// projects/shell/webpack.config.js
//  AND
// projects/mfe1/webpack.config.js

[...]
shared: share({
  [...]
  
  // Add this:
  "@auth0/auth0-angular": { singleton: true, strictVersion: true, requiredVersion: 'auto' },

  ...sharedMappings.getDescriptors()
})
[...]
```

This ensures there is only one ``AuthService`` at runtime we can use to share information about the current user. 

After changing the webpack configuration, we need to restart our applications. If everything works well, we can log in the user via the shell and read the user's name in the lazy loaded micro frontend.

## Summary

Module Federation allows loading separately compiled applications at runtime. Also, we can share common dependencies. This also allows sharing common data like information on the current user or global filters.

As Module Federation allows runtime integration, it is also the key for plugin systems and micro frontend architectures. However, this approach turns to compile-time dependencies into runtime dependencies; we need a sound set of integration tests to detect issues. 

In general, Micro Frontends only makes sense if you want to scale a project by splitting it into several smaller applications developed by different autarkic teams. If you only have one frontend team, Micro Frontend architectures are very likely an overhead.

Micro Frontends with Angular, Module Federation, and Auth0

joey devilla headshot 900px

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

Joey deVilla

Here’s an easy-to-understand analogy to help your non-technical friends and customers understand public keys and private keys, and how they relate to cryptography and digital signatures.

**If you work in cybersecurity or any computer-related field, sooner or later, you’ll have to explain public-key cryptography and digital signatures to non-technical people.** With the recent rise of remote work and stories about system breaches, computer security has become a topic of discussion even among laypeople.

After trying to explain public-key cryptography and digital signatures to some clients with varying degrees of success, I wanted to develop an analogy that explained them and was easy to remember. I’ve found that even techies get confused by the formal definitions, and many non-technical explanations just seem unsatisfying.

That’s when I stumbled upon [Panayotis Vryonis’](https://twitter.com/vrypan) article, [*Public-key cryptography for non-geeks*](https://blog.vrypan.net/2013/08/28/public-key-cryptography-for-non-geeks/). It became my go-to analogy until my computer science professor, [Dr. Robin Dawes](http://research.cs.queensu.ca/home/dawes/) pointed out a flaw. I refined it with his help, and a suggestion from Matthew Ernest, and the result is below. I hope you find it helpful when trying to explain these concepts to anyone!


## The Box

Imagine a box with a special lock, as pictured below:

![Photo of a box with a lock. There is a key inserted into the lock. Caption: "The box has a lock with three positions: Locked (at the 9:00 position), unlocked (at the 12:00 position), and locked (at the 3:00 position)."](https://images.ctfassets.net/23aumh6u8s0i/4nm7EvXpqVqMxfOPkjUlXe/bca6b7d8d0a00658045dd4f3fd0a5c7f/the_box_has_a_lock_with_three_positions.png)

The lock has three positions:

1. When the lock is at the “9:00” position, the box is locked, and its contents are inaccessible.
2. When the lock is at the “12:00” position, the box is unlocked, which means you can open it and view its contents.
3. When the lock is at the “3:00” position, the box is locked, and its contents are inaccessible.

In order to avoid wandering into endless “What if...?” tangents, assume that it’s prohibitively costly to pick the lock or break the box.


## The Keys

There are two kinds of keys that work with the box’s lock.

### The private key

The first kind of key belongs to you, and only you. You don’t share it with anyone else, which is why it’s called the **private key**. You might make a backup copy in case of emergencies, but you keep it in a safe place that only you know.

![Photo of a single key. Caption: "You keep the private key to yourself."](https://images.ctfassets.net/23aumh6u8s0i/2PJXCaqzggdgTpN4FSm8Qj/4a1228e2e8a6a46ad103c01ffd197e58/you_keep_the_private_key_to_yourself.png)

The private key fits the lock, but it has a particular limitation: it can only turn *clockwise*.

![Photo of the box with lock and key. An arrow indicates that the key is being turned clockwise. Caption: "The private key only turns clockwise."](https://images.ctfassets.net/23aumh6u8s0i/qqPVi6JTc2HOW4SuE4sEj/8fcd841021e55b659a3c5b92ad9b2da2/the_private_key_only_turns_clockwise.png)

### The public key

You treat the second kind of key very differently. Unlike the first key, you’ve made many, many copies of these keys. You’ve given them to everyone you know, and even people you don’t know. You’ve left them in as many public places as you could reach: restaurants, stores, busy streets, dark alleys, and any place you happened to pass through. You’ve even left them in other towns, and even other countries! Because of the way you treat this key, it’s called the **public key**.

![Photo of hundreds of keys hanging on hooks on a wall. Caption: "You hand out copies of the public key freely."](https://images.ctfassets.net/23aumh6u8s0i/2LTNf9JxfjDuB4rMZyM7K6/4a3a6264b81bf2b90efaffe469d3406c/you_hand_out_copies_of_the_public_key_freely.png)

Like the private key, public keys also fit the lock, and they also have a particular limitation — but in the opposite direction. They can only turn *counterclockwise*.

![Photo of the box with lock and key. An arrow indicates that the key is being turned counterclockwise. Caption: "The public key only turns counterclockwise."](https://images.ctfassets.net/23aumh6u8s0i/6QVsGSSoLuNdRgpfHznh6H/b5f42c68a9d5aa9e322e898cac14aeb3/the_public_key_only_turns_counterclockwise.png)


## How They Work Together

The lock, private key, and public keys work together to produce these interesting outcomes:

* If the box is locked with a public key, only the private key can unlock it.
* If the box is locked with the private key, only a public key can unlock it.

The keys are designed so that you can’t use one key to figure out how to make the other key.

We can use the box and keys to create two useful kinds of secure communication:

1. I can send you a secret message.
2. You can send me a message with proof that you (and not some impostor) sent it and that it wasn’t altered *en route*.

Let’s take a closer look at each of these kinds of secure communication.

## Sending Secret Messages

Suppose I wanted to send you a message that I wanted only you to read. We have enemies in common who’d love nothing more than to know what’s in the messages I send you.

We each have a cadre of minions to deliver our messages. We trust them... to a limited extent. It would be all too easy for our foes to intercept our messages through force or bribery. 

There must be a way to send messages to you secretly, and that’s where the box comes in. I can use the box to send the message so that no one but you can read it. 

You have the only private key. Everyone else has at least one of the public keys because you’ve been giving them away like candy. 

I put my message in the open box. Since it’s open, it’s unlocked, which means the lock is at the “12:00” position. 

I use one of the many copies of the public key that I own to lock it, turning it counterclockwise from the unlocked “12:00” position to the locked “9:00” position.

![Photo of the box with lock and key. An arrow indicates that the key is being turned counterclockwise. Caption: "I lock the message in the box with the public key..."](https://images.ctfassets.net/23aumh6u8s0i/3WnNKlXN7MC0BfDdEU8GyX/2bcc1521f829c80ff548cf7234078bba/i_lock_the_message_with_public_key.png)

The message is now ready for a minion to deliver to you.

I’m not worried that my minion or anyone other than you will be able to read the message while it’s in transit. Even though anyone can easily find the public key, they can’t use it to unlock the box. Only the private key can unlock the box if it’s been locked with the public key.

When you receive the box, you use the private key to unlock it, turning the key clockwise from the “3:00” position to the “12:00” position.

![Photo of the box with lock and key. An arrow indicates that the key is being turned clockwise. Caption: "...and you unlock it with the private key."](https://images.ctfassets.net/23aumh6u8s0i/2kwG5ogtYDYCkDtjC0MqgN/75f2cb365ea0014a0af58a7dbc90c481/you_unlock_it_with_the_private_key.png)

In summary: to send you a secret message, I use a public key to lock the message so nobody can read it, and you use a private key to unlock the message so that you can read it.

This is the general idea behind public-key encryption: **encrypt with the public key, decrypt with the private key.**

## Signing Messages

The “secret messages” use case for the box and private and public keys is intuitive: anyone with a public key can lock a message, but only the holder of the private key can unlock it.

There’s another way to use the box and keys: you can lock a message with the private key, which anyone with the public key can unlock. What could a possible use case there be for a system where anyone can unlock the box?

Suppose one of our common enemies has been trying to break up our alliance and that I’ve been receiving very hurtful messages that appear to have come from you. (I’ll leave the content of those messages to your imagination.)

That enemy has either been sending fake messages or has been intercepting and altering your real ones. There has to be a way to package a message in order to prove that it’s actually from you!

There *is* a way: the box!

In this scenario, you put your message in the open box. Since it’s open, it’s unlocked, which means the lock is at the “12:00” position. 

Using the private key, you “sign” the message by locking it, turning the key counterclockwise from the “12:00” position to the “9:00” position.

![Photo of the box with lock and key. An arrow indicates that the key is being turned clockwise. Caption: "You 'sign' the message with the private key..."](https://images.ctfassets.net/23aumh6u8s0i/1U2aOr7mKgMtGdZM8lPLWT/82ff89d7160d93b04fff8ac635fd41d7/you_sign_the_message_with_the_private_key.png)

One of your minions delivers the box to me.

Since you locked the box with the private key, anyone can unlock it with any one of the many public keys you have distributed. Our common enemy, knowing that this message is in transit, could intercept it and replace your invitation to tea with a “top ten” list of very cutting insults that would surely dissolve our alliance.

The problem with the enemy’s plan is that it won’t work. Intercepting and altering the message means that they would have to do one of two things before forwarding the box to me.

1. They could leave the box unlocked. Since the box is supposed to arrive locked, this is an obvious sign that the message may have been tampered with.
2. They could lock the box. They would have to do it with a public key, which means that only the private key can unlock it. I wouldn’t be able to unlock the box with the only key I had — the public key — which would lead me to conclude that someone had unlocked the box before I did.

If the box arrives at my doorstep and...

* It’s locked
* I can unlock it with the public key

...then, I can be assured that the message came from you and wasn’t changed *en route*.

![Photo of the box with lock and key. An arrow indicates that the key is being turned counterclockwise. Caption: "...and I verify your 'signature' with the public key."](https://images.ctfassets.net/23aumh6u8s0i/4Fax8BanX5Qts7KJzW7166/b4dc34b169f6eca961c8d8f3c7452af4/i_verify_your_signature_with_the_public_key.png)

In summary: to send me a message with proof that you are the sender, you use the private key to lock the message. You’re the only person with the private key, and only a public key can unlock messages locked with the private key. If one of the public keys can unlock that message, I know that it came from you.

This is the general idea behind digital signatures: **sign with the private key, verify with a public key.**

## How About Sending a Message That’s Both Secret *and* Signed?

You might think that sending a message that is both secret and signed is paranoid. I would answer by saying, “Paranoia is the ***mistaken*** impression that people are out to get you.”

Suppose I wanted to send you a secret signed message. I could do it with two boxes:

1. A smaller box, which I own. It will prove that I sent the message. I have the private key for this box, and you have one of its public keys.
2. A larger box, which you own. It will keep the message secret. You have the private key for this box, and I have one of its public keys.

I would lock the message in my smaller box using my private key and then lock it in your larger box using your public key.

When you receive the delivery, you will unlock your larger box first, using your private key. This would reveal my smaller box inside, which you would unlock with my public key.


## It’s Not Keys and Boxes, but Numbers and Algorithms

Of course, we’re not really dealing with boxes, keys (at least the kind that goes into locks), or minions. Here’s a list of elements in these stories and their real-world equivalents:

* **The message**: Anything that you’d want to send that can you can view or edit with a computer. It could be text, one or more pictures, an audio or video recording, a database, or even an application. As far as the computer is concerned, messages are just a long series of numbers.
* **The private and public keys**: Very large numbers that are used in a lengthy math process to encrypt, decrypt, sign, and verify messages.
* **The box**: An algorithm that takes the message and keys and performs the math process to encrypt, decrypt, sign, and verify messages.
* **Minions**: The way in which the message is sent. This could be the internet but could just as easily be an actual minion, such as an unsuspecting summer intern with a USB key.

In the alternate universe where messages are sent with boxes and keys, everyone would have their own set of boxes with their own private keys, as well as copies of other people’s public keys. In the real world, we run applications that run public-key encryption and digital signature algorithms to secure our messages. We still use public and private keys in the real world; they’re just digital.

How to Explain Public-Key Cryptography and Digital Signatures to Anyone

apoorv-tyagi-author

I write about algorithmic solutions for software engineering problems, interesting programming tips, tricks & resources. May also include machine learning, NLP & Blockchain.

Apoorv Tyagi

A reply-to-mention Twitter bot that can reply to every tweet where it got mentioned with a specific keyword with an auto-generated image.

How to Make a Twitter Bot in Python using Tweepy

daniel-krzyczkowski-2020

Software Engineer passionate about Microsoft technologies. Awarded with Microsoft Most Valuable Professional title. The main part of his activities is to share knowledge and passion about Microsoft Azure, IoT, Universal Windows Platform and DevSecOps.


Daniel Krzyczkowski

How to securely access secrets stored in the Azure Key Vault service using the new Azure SDK and managed identities.

Secrets Access with Managed Identities in .NET Applications

yoav-kadec

Yoav is a Product Manager at Auth0 working on Auth0 Insights and Analytics. He brings vast experience from previous roles as a Product Manager and Developer working in various industries. He especially enjoys the creative process of learning from the end user and conceiving high-impact and usable products.

Product Manager

Yoav Kadec

Access key, actionable insights right in the Auth0 dashboard


We’re excited to announce the first availability of the new [Activity](https://auth0.com/docs/get-started/dashboard/activity) page in Auth0’s dashboard. With the refresh, customers have access to actionable insights that give them a high-level understanding of their tenant data without the overhead of third-party tools.

With [Activity](https://auth0.com/docs/get-started/dashboard/activity) analytics, developers can ensure that their Auth0 implementation is working and report back usage and utility. Security engineers can quickly gauge failed logins and monitor security events for potential audit. And product owners can easily understand usage and relay that information to relevant stakeholders.

The new [Activity](https://auth0.com/docs/get-started/dashboard/activity) page drives more data-driven outcomes by enabling customers to:

### Visualize metrics such as active users and failed logins

![Visualize metrics such as active users and failed logins](https://images.ctfassets.net/23aumh6u8s0i/3KOXWutqR0jb945kUQDLyj/d9566d3a4609689a9d3b86369e4f649c/Visualize_metrics_such_as_active_users_and_failed_logins.jpg)

### Compare data across previous time periods

<img src="https://images.ctfassets.net/23aumh6u8s0i/7bp46Tj5eIAxB2ZyTqNEbt/c589fa843ea1f698b94a7d465d72188b/05_hover.png" alt="Compare data across previous time periods" width="500" height="476">

### Filter data by specific timeframes

![Compare](https://images.ctfassets.net/23aumh6u8s0i/2myyhfrQckB2v8F5rwTIKI/f29e4373bbe8d648f8ec9669c9644627/06_date_picker.png) 

### Segment active users across connections and applications (Coming Soon)

![Segments](https://images.ctfassets.net/23aumh6u8s0i/60RNmKfiNtCUy0QoBe7ErN/d1fdc4f5090ba70a2d799aa733be9ce8/04_segments.png)

### Rollout

The new Activity page is now Generally available to all tenants.

### Feedback

We’d love to hear what you think about the new [Activity](https://auth0.com/docs/get-started/dashboard/activity) page. Be sure to comment and share your thoughts about the experience. Your feedback shapes where we go, so keep it coming!

<include src="asides/AboutAuth0" />

Auth0 Levels Up Analytics Experience

andres

I’ve been at Auth0 since 2017. I’m currently working as a Product Manager for the Auth0 FGA and OpenFGA products. Previously, I worked in the teams that owned the Login and MFA flows. <br>
I spent my entire 20+ year career building tools for developers, wearing different hats. When I'm not doing that, I enjoy spending time with my family, singing in a choir, cooking, or trying new kinds of local cheese.

Andrés Aguiar

Announcing support for WebAuthn with FIDO Security Keys for Multi-Factor Authentication in Auth0



Companies of all sizes are under attack, targeted by numerous phishing attacks that are coming at an ever-increasing rate. Even if the tech industry continues to improve how organizations identify and defend against those attacks, the problem is bigger than ever. According to ProofPoint's [2020 State of The Phish Annual Report](https://www.proofpoint.com/sites/default/files/gtd-pfpt-uk-tr-state-of-the-phish-2020-a4_final.pdf), 88% of organizations faced a targeted phishing attack in 2019, and 65% of US organizations experienced a **successful** phishing attack.

There are options for decreasing the chances of successful phishing attacks targeting your company. Things like employee training and security policies, such as using password managers and enforcing multi-factor authentication (MFA), are all steps in the right direction. 

However, if you want to neutralize the threat completely, you need to enable authentication methods that cannot be phished. That's [what Google did](https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing) in 2017 to neutralize phishing of its employees. Google now requires all employees to use U2F Security Keys to authenticate to corporate websites. 

U2F evolved into the WebAuthn specification, which is now supported by the latest versions of browsers and operating systems. Auth0 is now supporting WebAuthn with FIDO security keys for multi-factor authentication. You can start protecting your users with Auth0 today, using the same technology as Google.

## About WebAuthn

The Web Authentication API (also known as WebAuthn) is a [specification](https://www.w3.org/TR/webauthn/) written by the World Wide Web Consortium (W3C) and The Fast IDentity Online Alliance, known as FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. The API allows servers to register and authenticate users with public-key cryptography instead of a password.

When it comes to security, many people think you have to sacrifice security in the name of user experience, and vice versa. However, the key to maximizing both variables is to reduce the number of times we prompt the user for authentication and to allow the user to authenticate with secure factors that provide low friction. WebAuthn promises to be the holy-grail of authentication factors, as it accomplishes exactly that by combining maximum security with a low-friction user experience.

WebAuthn allows users to authenticate using one of two options:

* **Roaming authenticators** — These are removable and cross-platform devices, like a [Yubikey](https://www.yubico.com/products/) that can be used on multiple devices. To authenticate with a roaming authenticator, you simply connect it to the device (through USB, NFC, or Bluetooth), provide proof of presence (e.g., touching it), and optionally an additional authentication factor like a PIN or fingerprint recognition.

* **Platform authenticators** — This option includes the MacBook's TouchBar, Windows Hello, iOS Touch/FaceId, and Android's fingerprint/face recognition. Integrated into the device being used, these only work on that device.

When doing multi-factor authentication, we want to challenge the user with something they know (like a password), something they have (like a security key), and something they are (e.g., their fingerprint).

Note that a Roaming Authenticator + PIN **combines two factors in one** (you have the key, and you know the pin), and a Platform Authenticator also does (you have the device, you are the person with that fingerprint/face, or you know the passcode).

In recent months the WebAuthn API has been implemented in major browsers and operating systems, enabling support for both options.

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

## The Case for Security Keys

Using a Security Key allows you to authenticate users with the strongest possible authentication factor. This helps you to solve several problems at once by:

* Protecting sensitive data and employee accounts
* Providing secure access from outside the corporate network
* Allowing your employees to authenticate to shared computers
* Enabling MFA in scenarios where users cannot carry their mobile phone

It also offers several advantages when compared with using a smartphone only authenticator for MFA:

* Protects against phishing and man-in-the-middle attacks
* Strengthens user privacy as it doesn't require a personal device
* Provides one-touch login without having to take your mobile phone to complete an authentication challenge
* Has no battery or signal dependency
* Has no moving parts, so it's practically indestructible
* Allows users to register multiple keys, minimizing business disruption and the chances of account lockout

## WebAuthn With Security Keys for Multi-Factor Authentication

Auth0 with WebAuthn support for Security Keys is available starting today. You can enable the factor in the WebAuthn with Security Keys MFA configuration section of the admin dashboard:

![Multi-Factor Authentication 1](https://images.ctfassets.net/23aumh6u8s0i/5LAUWUPRO5gvYQ9t56rNPa/f9c2d823965b8070c22e6ab3151d2665/01-factors-updated)

After it is enabled, users will go through the enrollment flow below. At some point, their browser will show a native dialog to ask users to engage the security key. In the example below, we show the Android dialog:

![Multi-Factor Authentication 2](https://images.ctfassets.net/23aumh6u8s0i/4l0n2zVBk0Byf8P2MfWvaf/51a1b3ebb7248719a7cc17b32a4765a4/02-welcome)

The next time they login, the flow will look like this:

![Multi-Factor Authentication 3](https://images.ctfassets.net/23aumh6u8s0i/5f9tqz1pR3RgrkFZSOcp2F/41df6128ee37f040c0389dbd7db9dda8/03-waiting-for-your)

## Stay Tuned!

In addition to supporting WebAuthn with roaming authenticators, we are currently working on a unique approach that will greatly improve the usability and adoption of WebAuthn platform authenticators. Check out Vittorio Bertocci's session "[Democratizing WebAuthn for Developers and End Users](https://authenticatecon.com/session/democratizing-webauthn-for-developers-and-end-users/)" from FIDO's Authenticate conference for the scoop!

WebAuthn is an exciting technology, and Auth0 is committed to providing the best possible implementation, maximizing security without sacrificing user experience. Check out our new [WebAuthn](https://auth0.com/docs/mfa/configure-webauthn-security-keys-for-mfa) offering and let us know what you think on our [Feedback page](https://auth0.com/feedback) or in the [Auth0 Community](https://community.auth0.com).

<include src="asides/AboutAuth0" />


FIDO Security Key Support Comes To Auth0

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

Industry veterans Sue Barsamian, Sameer Dholakia, and Simon Parmett join Board



**BELLEVUE, Wash. – Jan. 12, 2020** – The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced the addition of three industry leaders to its Board of Directors: Sue Barsamian, former Chief Sales and Marketing Officer for Hewlett Packard Enterprise (HPE) Software; Sameer Dholakia, former CEO of SendGrid; and Simon Parmett, former CEO of MuleSoft. Barsamian, Dholakia, and Parmett each have deep technology and SaaS industry experience and will play a key role in guiding Auth0 on its next chapter of growth. 

* [**Sue Barsamian**](https://www.linkedin.com/in/suebarsamian/) has more than three decades of marketing, sales, product, and business operations experience in both early-stage and Fortune 50 organizations, including HPE and Mercury Interactive. She also serves as a board member for Box, Gainsight, NortonLifeLock, Xactly Corp, and formerly Segment (acquired by Twilio in November 2020).

* [**Sameer Dholakia**](https://www.linkedin.com/in/sameerdholakia/) most recently served as the CEO of SendGrid was instrumental in SendGrid’s successful IPO in November 2017 and led the company through its $3 billion acquisition by Twilio in February 2019. He has more than two decades of experience in scaling high-growth companies, including VMLogix, Inc. (acquired by Citrix Systems), Citrix Systems, SendGrid, and Twilio. Dholakia also serves as a board member for PagerDuty.

* [**Simon Parmett**](https://www.linkedin.com/in/simon-parmett/) is a seasoned leader with three decades of experience leading global companies, including Agile Software, Oracle, and MuleSoft. Most recently, Parmett was CEO and General Manager of MuleSoft and was previously President of Field Operations, where he designed and led MuleSoft’s growth to over a billion dollars in revenue. He was also instrumental in shaping MuleSoft’s successful IPO in 2017 and subsequent $6.7 billion acquisition by Salesforce in 2018.

“Sue, Simon, and Sameer offer broad expertise, and we are honored to welcome them to our Board,” said Eugenio Pace, CEO, and co-founder of Auth0. “Their experience in scaling high-growth technology companies will be very valuable to Auth0. We are thrilled they will be applying their experience and counsel to our work on growing and scaling the company.”

These new appointments add to the existing levels of tech industry leadership and experience in Auth0’s Board of Directors. Jennifer Ceran, former CFO of Smartsheet, joined the Board in May 2020.

<include src="asides/AboutAuth0" />
### Media Contacts
Auth0 Global Communications<br />
[press@auth0.com](mailto:press@auth0.com)<br />

Matter for Auth0<br />
[auth0@matternow.com](mailto:auth0@matternow.com)<br />


Auth0 Adds Three Key SaaS Leaders to its Board of Directors

ghazi-masood

I'm a seasoned business leader with nearly a 25 year track record in Sales running and managing teams of all sizes working in leadership positions for world class organizations.  Nowadays, you can find me at Auth0 leading all aspects of Revenue growth  for the Americas business.

Auth0 Vice President and General Manager, Americas.

Ghazi Masood

A customizable Identity and Access Management (IAM) solution is key to improving CX in mixed environments.



## Every Environment Is a Mixed Environment

Software implementations are often discussed in terms of “[build vs. buy](https://auth0.com/resources/whitepapers/build-vs-buy-evaluating-identity-management),” meaning that for each functionality desired in the tech stack, an organization needs to decide whether to develop the functionality in-house (build) or go with a third-party solution (buy). The latter essentially means entrusting the functionality, whether that’s team communications or identity and access management (IAM), to a dedicated expert.

But what if your environment comprises both built and bought solutions? For many companies, particularly at the enterprise level, the build vs. buy thinking doesn’t necessarily capture their experience. Instead, they’re working with legacy architecture that’s a highly customized combination of purchased and built-to-spec apps. Sometimes the reality is that, in the words of one CISO, “every environment is a mixed environment.”

## IAM Alleviates Pain

In a mixed environment, ensuring a frictionless customer experience can be a challenge. Having more applications in your architecture creates more opportunities for friction to disrupt the user experience. And now that identity is disseminated across so many different platforms and devices, with users needing the flexibility to log in anywhere, from any device, it’s more important than ever to support [federated identity](https://auth0.com/blog/why-auth0-b2b-federation-is-your-secret-weapon-for-enterprise/). But how can you ensure that you’re prepared to solve the constantly-shifting identity challenges presented by distributed and mixed environments?

IAM lightens the burden on companies struggling to manage identity in mixed environments. Implementing IAM empowers companies to increase security, work more efficiently, and deliver a painless customer experience regardless of tomorrow’s fresh challenges and unforeseen pain points. 

An identity-as-a-service provider like Auth0 manages authentication across all of your applications, so the login experience is both seamless and secure. A flexible IAM solution gives your team the access and insight they need to accelerate innovation, deliver more value to users, and strengthen your security posture — not just in response to the identity challenges you’re encountering now but those you’ll encounter in a year or five years. 

## Customization Is the Key

To address today’s rapidly evolving use cases, you need to add modern, greenfield functionality to your tech stack. Companies often add that functionality through third-party microservice providers: cloud-based software-as-a-service (SaaS) companies like Salesforce, ZenDesk, or Trello. At the same time, your legacy environment is powering your business, so while you might see the benefits of moving completely to the cloud, you may not be ready for the disruption of a full-scale cloud migration.

Fortunately, customization is the middle ground that can alleviate much of the pain you feel without creating additional headaches by forcing you into a migration strategy that’s not right for your situation. 

Auth0 powers customizations that integrate easily with your legacy system, driving revenue and allowing you time to adjust your strategy and reach consensus before moving forward with full-scale digital transformation. The right IAM solution helps you minimize disruption for users and customers during replatforming and other transitions, so you can minimize turnover and limit missed opportunities.

## Use Identity to Bring Business Logic Into Focus 

The process of implementing an identity strategy clarifies what your company needs to do. Put a different way, to make your identity strategy work; you need to understand the structure and needs of your business at a deep level. Implementing IAM creates opportunities for discussion that brings business logic into sharper focus and allows you to build innovation into your company’s DNA.

Building a product that is as flexible, extensible, customizable, and responsive to change as you need it to be also create the opportunity to take this same approach to higher-level conversations. When leadership sets lofty business goals, you can execute on these goals quickly, equipped with an identity solution that speeds time-to-market (TTM).

## Real-World Example: Bluetooth Special Interest Group (SIG)

Let’s look at an example of an enterprise environment where a flexible IAM solution helped mitigate the pain of a mixed environment that encompassed multiple different apps — and presented multiple challenges.

Formed in 1998, [the Bluetooth SIG](https://auth0.com/case-studies/bluetooth-sig/) is the not-for-profit trade association that oversees Bluetooth® technology. In support of more than 34,000 member companies, the Bluetooth SIG facilitates the collaboration of its members to create new and enhanced specifications that expand the technology, drives global interoperability via a world-class product qualification program, and grows the brand by increasing the awareness, understanding, and adoption of Bluetooth technology.

Bluetooth SIG needed a modern identity solution with single sign-on (SSO) to support all of the company’s homegrown and third-party SaaS apps. They had to be able to implement the solution while keeping the existing platform operating and mapping a path for full migration in the future. It was also essential to establish user roles and access to ensure proper protection for confidential information.

Auth0 fulfilled all of Bluetooth SIG’s requirements. Our solution was easy to implement and allowed the Bluetooth SIG team to add SSO and modern authentication. Without disrupting the legacy system, a migration plan was developed and carried out. Implementation of Auth0 took days, compared with the months it would have taken to implement an in-house platform. 

Top-tier documentation with detailed code samples helped Bluetooth SIG engineers get up to speed quickly on their modern identity solution. Bluetooth SIG and Auth0’s developer success engineers worked together to develop a proof of concept showcasing the platform’s capabilities. Ultimately, Auth0’s full suite of technology, documentation, and expert support gave Bluetooth SIG the solution they were looking for.

## Support Business Processes With Software, Not the Other Way Around

Software should support your core business functions — not the other way around. With an [identity-as-a-service (IDaaS)](https://auth0.com/blog/what-is-idaas/) provider like Auth0, you’ll have the functionality and extensibility to accomplish what you need to without wasting time and resources on a solved problem. IAM is a rapidly evolving specialty in which the only constant is the change. That’s why an out-of-the-box identity solution or an in-house authentication platform can only take you so far. 

Auth0 believes in the business value of entrusting identity to an IDaaS provider, but we also understand the power of code. That’s why we feel an IDaaS+code approach gives you the best of both worlds: identity services managed by an easy-to-use service, plus the same customizability and control you’d have if you’d coded the entire solution from scratch. 

To learn more about how the right identity solution can provide enhanced data protection and a seamless customer experience in your mixed environment, [reach out to the team at Auth0](https://auth0.com/contact-us?place=blog%20post&type=link&text=contact%20us).

<include src="asides/AboutAuth0" />


How to Improve Customer Experience in Your Mixed Environment

Vittorio

Vittorio Bertocci is a Principal Architect for Auth0. Before Auth0, he had a lengthy career with Microsoft, where Vittorio worked with Fortune 100 and Global 100 companies, including working on Microsoft’s Azure Active Directory team as principal program manager focusing on the developer experience. He contributed to the inception and launch of Microsoft's claims-based platform components (Windows Identity Foundation and ADFS, ADAL and MSAL SDKs, ASP.NET middleware). Vittorio is a well known speaker, educator and published author.

Principal Architect

Vittorio Bertocci

Brian Campbell joins the show to discuss sender constraint and associated specifications.



### The Overview

On the first episode of _Identity, Unlocked_, host Vittorio Bertocci, Principal Architect at [Auth0](http://www.auth0.com?utm_source=podcast&utm_medium=blog&utm_campaign=identity-unlocked), is joined by Brian Campbell. Brian joins the show to discuss the sender constraint and associated specifications. 
 
The mechanism described by OAuth2 for using the access token to access resources, as defined in the bearer token usage specification ([RFC6750](https://tools.ietf.org/html/rfc6750)), simply entails attaching a token to the request to the API. The approach is extremely simple to implement, but token leaks can have disastrous consequences: nothing stops an attacker from using a stolen bearer token to access a resource successfully. 

"Sender constraint" indicates a series of techniques that bind tokens to a particular sender, for example, by forcing the token to travel on a specific channel or requiring proof of knowledge of a given key. The goal is to guarantee that only the legitimate sender can successfully use a token to access resources, thus making it impossible for an attacker to access a resource using leaked tokens. 

There are two different specifications in the OAuth 2 family offering viable sender constraint capabilities today: OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens (MTLS, [RFC8705](https://tools.ietf.org/html/rfc8705)) and OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer ([DPoP](https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html)). 

MTLS is robust and stable, but not easy to implement in various important scenarios. For a while, the identity community worked on an alternative, a set of specifications under the general token binding moniker (main one: [RFC8471](https://tools.ietf.org/html/rfc8471)); however, support from key industry players disappeared or never materialized, making token binding non-viable.

DPoP quickly emerged as an easy to implement an alternative that could fill that gap, and although it is still in draft state, it is already very popular and making quick progress.

Brian touches on all those specs during the episode, walking us through the trajectory that led us to today's situation and taking the time to dig deeper into the trade-offs, strengths, and attention points of the various approaches. The episode concludes with important practical considerations to keep in mind when planning an implementation strategy for the sender constraint in your solutions today.  

Read on for more in-depth information on this episode and make sure to subscribe and join us for the next episode, where [Aaron Parecki](https://twitter.com/aaronpk) (Senior Security Architect) talks about what's new with OAuth2.1.

### Highlights:

In the following, we highlight key passages of the interview. We added some background information here and there to make it easier to follow the conversation if you aren't already familiar with the topic.

**[4:45]** - What is sender constraint and what problem is it trying to solve?

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=9506a0f1&embed=true"></iframe> 

The figure below shows a typical OAuth 2 flow for calling an API- a good example to understand how bearer tokens are meant to work.

![Bearer](https://images.ctfassets.net/23aumh6u8s0i/3IJk6fHvBHJcUj5za8yAmt/78444158ad7ab009e2c2a1bddf66b027/1-bearer)

In the first leg of the diagram, a client requests an access token - this might be the redemption of an authorization code, of a refresh token, anything that leads to an access token being issued to the client as shown in step 2.
In this particular example, we are issuing tokens that are digitally signed by the `authorization` server via its private key (other token encodings are possible).

In step 3, the client calls the API by simply attaching the access token to the request (typically by placing it in the authorization HTTP header).

In step 4, the API validates the incoming access token (in this example, that includes validating the signature with the public key associated with the authorization server), and the call succeeds. 

The following diagram shows what happens when a bearer token is leaked.

![BearerAttack](https://images.ctfassets.net/23aumh6u8s0i/5TsCBLxiteQCHodPQYdMhp/3657fc2c592b822f960b90395be69cc0/2-bearerattack)

In step 1, an attacker steals an access token. For the purpose of highlighting the problem with bearer token leaks, it doesn't matter how the leak occurs (the token might be leaked from a cache, a referral header, an HTTPS tunnel termination, erroneously forwarded to a malicious address etc., etc.) as it doesn't change the consequences of the leak.
Once an attacker has the token, all they need to do to access the API successfully is to attach it to an API call - the API will perform the same validation we had observed in the former diagram when the call was originating the legitimate sender. 
This is the key limitation of bearer tokens: everything hinges on not making them fall into the wrong hands, as when that happens, there's no easy recourse.

**[11:35]** - What are the current standards with sender constraint?

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=1e5c3b2a&embed=true"></iframe>

The main specifications extending OAuth 2 with sender constraint capabilities are:

* MTLS ([RFC8705](https://tools.ietf.org/html/rfc8705))
* DPoP ([DPoP](https://www.ietf.org/id/draft-ietf-oauth-dpop-01.html))
* Token binding ([RFC8471](https://tools.ietf.org/html/rfc8471))

Token binding is mentioned out of exhaustiveness, but it isn't really a viable option as of today. 
For the other ones, we give more details later on in the interview.

**[11:51]** - Brian explains mutual TLS profile for OAuth 2.

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=d98141ee&embed=true"></iframe>

Here's a super quick primer to explain how MTLS works in OAuth 2. This leaves out lots of details, so if you are interested, you should consider taking a look at the spec itself ([RFC8705](https://tools.ietf.org/html/rfc8705)).
Please consider the diagram below.

![MTLS](https://images.ctfassets.net/23aumh6u8s0i/3nVuTSuMHCkIm7XS3pyxDw/5a97276eaa4f3a1a8e7f1c45d1a08274/3-mtls)

The client application has access to an X509 certificate, which it uses to perform client TLS authentication (hence proving possession of the corresponding private key) when requesting a token from the authorization server.
The authorization server issues a token containing (or referencing, if other token encoding methods are used) a claim cnf carrying the thumbprint of the X.509 certificate used to establish the channel. 
Important note: the access token is still meant to be signed by the authorization server, and the API is still meant to validate that signature, but we are omitting it in all diagrams from now on for simplicity. 

In step 2, the client establishes a channel with the API/resource server, again using its X509 certificate to establish client TLS. 

In step 3, the API validates the incoming token as usual, and additionally, it verifies that the certificate thumbprint corresponds to the certificate used to establish the TLS channel. If the two matches, the call is considered valid.  

![MTLSAttack](https://images.ctfassets.net/23aumh6u8s0i/479dKTr0VNwPDUT3i8Fwyl/e57676ac4b63edca06a5409ba42d6e3a/4-mtlsattack)

Consider now the case in which an attacker successfully steals a token. The attacker does not have access to the same certificate as the legitimate client; hence it cannot establish a client TLS channel with the API when attempting to use the stolen token - or it has to use a different certificate.
However, the API will easily spot that the certificate thumbprint carried by the cnf claim in the incoming access token does NOT correspond to the certificate used in client TLS authentication by the attacker; hence the API will deny access.

**[15:32]** - Brian explains DPoP. 

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=36aff654&embed=true"></iframe>

To help you follow the discussion, here’s a diagram exemplifying how DPoP works. 

![DPOP](https://images.ctfassets.net/23aumh6u8s0i/xrkq0ZMdUIwjiCeuZ6aXf/f333027993663e18e5f714e7d7d43d7f/5-dpop)

The idea is simple: the client uses some keys when requesting a token, those keys are referenced by the access token issued by the authorization server, and the client demonstrates knowledge of the same keys to the resource server when using that access token to call an API. Let's break that down in the steps shown in the diagram.

The client generates a private-public keys pair. It then creates a JWT, called DPoP proof, including in it a claim `jwk`carrying the public key from the pair, an `htu` claim indicating the intended destination of the call (in this case, something like [`https://server.example.com/token`](https://server.example.com/token)), a claim `htm` the HTTP method to be used in the call, and (not shown in the diagram) a `jti` claim (identifier) and an `iat` claim (issuance instant). It then proceeds to digitally sign the JWT with the private key from the generated pair.

In step 1, the client attaches the DPOP proof in a DPOP HTTP header to a token request to the authorization server.

In step 2, the authorization server uses the public key in the `jwk` claim from the DPoP proof to validate its signature, verifying that the sender does indeed have access to the corresponding private key. That done; it issues a new access token (once again, the token signature is omitted, but it is there, just like in the first diagram in this post) and embeds in it a `cnf` claim containing the public key received from the client.

In step 3, the client calls the API. Using the DPoP, the client creates a new DPoP proof, including the same `jwk` with the generated public key, a `htu` with the URL of desired API endpoint (for example, [`https://resource.example.org/protectedresource`](https://resource.example.org/protectedresource)) and `htm`, `jti`, and `iat` claims of the appropriate value. The client then attaches the DPoP proof and the access token to the request to the API.

In step 4, the client validates the incoming access token as it would do in a normal bearer case. In addition to that, it validates the DPoP signature with the `jwk` it carries, validates that the content of the DPoP proof accurately describes the targeted API and thatthe thumbprint of the key embedded in the `cnf` claim in the incoming access token corresponds to the `jwk` in the DPoP proof. If all that checks out, the API has proof that the caller is indeed entitled to use that token and allows the request to succeed.
The failure case here is very similar to the one shown in the MLTS diagram. An attacker stealing a token would not have access to the private key the legitimate client-generated at request time; hence it would not be able to manufacture the appropriate DPoP proof that would convince the API to accept the stolen access token. Bam. Sender constraint!

**[18:42]** - If DPOP blossoms like some anticipate, is there any reason to continue mutual TLS?

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=db16444d&embed=true"></iframe>

**[23:23]** - Brian’s opinion on how DPoP can be rolled out.

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/4d4e8add?clip=dcdf8d37&embed=true"></iframe>

### Links/Resources:

Learn more about [Brian Campbell](https://www.linkedin.com/in/bcampbell)<br />
Brian Campbell on [Twitter](https://twitter.com/__b_c)<br />

Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
Vittorio Bertocci on [Twitter](https://twitter.com/vibronet)<br />

Learn more about [Identity, Unlocked](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/episodes)<br />
Learn more about [Auth0](https://auth0.com/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />


Identity, Unlocked... Explained | Episode 1

joan-pepin

As CSO, Joan is responsible for the holistic security and compliance of Auth0's platform, products, and corporate environment. She brings 20 years of experience to the role, with a career that has spanned a wide variety of industries, including healthcare, manufacturing, defense, ISPs, and MSSPs. <br /><br />Previously, Joan served as Business Information Security Officer (BISO) at Nike, Inc, CISO, and VP of Security at Sumo Logic, and held different positions at Guardent/Verisign/Secureworks organization. Joan holds a patent for developing the methodology to assess whether a communication contains an attack. <br /><br />She is also is a well-recognized thought leader and has spoken at major events, such as RSA, WhiteHat Security Summit, and Forrester Security Summit, and is frequently called upon for her expertise and commentary in Cloud Security and Compliance in large-scale and DevOps/CI environments.

Chief Security Officer (CSO)

Joan Pepin

A look at why shaming proved to be a productive strategy


Sometimes shaming works.

[Nearly two years ago](https://www.linkedin.com/pulse/thoughts-rsa-international-womens-day-joan-d-pepin/), I called out the RSA Conference for the lack of keynote speaker diversity at the largest and arguably the most influential Information Security conference in the world, specifically citing their lack of women speakers. In 2018, women made up only 11% of the cybersecurity workforce, but since then that’s improved. According to the (ISC)[^2]’s latest study, pay disparity remains, but women now make up roughly 24% of the cybersecurity workforce.

I wasn’t the only one shaming RSA. 

[Mashable](https://mashable.com/2018/04/18/rsa-conference-tech-diversity/) noted that while Cisco Chief Security and Trust Officer John Stewart was on the RSA 2018 keynote stage saying that diversity in tech is "not about this politically correct thing” 19 of the 20 keynote speakers were men.

After a fair a lot of press and social media response, RSA announced a [Diversity Initiative](https://www.businesswire.com/news/home/20181113005339/en/RSA%C2%AE-Conference-Unveils-New-Diversity-Inclusion-Initiative) that included expanding its advisory board, greater outreach during the call for speakers, and the elimination of all-male panels in the keynotes stages.

<include src="TweetQuote" quoteText="Two years ago @mashable dinged the @RSAConference for lack of keynote speaker diversity. And they changed. Why shaming sometimes works."/>

Since then RSA has vastly improved its keynote ratio. By current count, [17 of their 42 keynote speakers](https://www.rsaconference.com/usa/keynote-speakers/keynotes) for the 2020 conference are women. Still less than half, but an improvement. 

Let’s unpack what had to happen to make that change because it’s not just RSA who holds full responsibility for the level of diversity at their conference.

## Diversity Action Shouldn’t Take Forever

Back in 2015, [RSA banned “booth babes,](https://www.infosecurity-magazine.com/news/rsa-bans-booth-babes/#ftag=YHF87e0214)” publishing a dress code that required booth attendees to wear “business or business casual attire.” While making a gesture in the right direction, the same year, they were still presenting talks [dominated by white males](https://finance.yahoo.com/news/lack-diversity-2015-rsa-security-185602235.html). It took a lot of shaming for things to change. Meanwhile, the research continued to roll in.

<iframe width="560" height="315" src="https://www.youtube.com/embed/e2UIeHW1D-M" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

Countless studies have proven the benefits of diverse teams and leadership, including this recent one from [BCG](https://www.bcg.com/en-us/publications/2018/how-diverse-leadership-teams-boost-innovation.aspx) which found that companies with above-average diverse leadership also brought in a 19% increase in innovation revenue. Real diversity results in diverse thinking, which benefits the bottom line.

## What It Takes to Drive Change

The visibility of these studies may be part of what drove sponsors like Microsoft to send a woman to RSA this year. Or it may be that more women have risen to powerful roles. Or that the shame of negative press just wasn’t worth it. 

But since RSA changed its rules and specifically said that they support diversity, the change is there. That means sponsors were required to meet those standards.

<include src="TweetQuote" quoteText="@CloudCISO_Joan on why speaking opportunities are an easy area to do good. And why @ @RSAConference improved their keynote speaker diversity ratio."/>

Ideally, the male chief architect or senior VP took action as an ally, turning down the opportunity for the exposure they don’t truly need and took the opportunity to say  “Hey, no. There is this woman in my team who would be perfect.” 

Companies have a monetary motivator to make changes in-house. But there’s also pragmatic and moral responsibility (which circles back to why shaming works): We need a diverse set of people and perspectives (skills) and since tech is one of the Gold Rushes of our time. We should endeavor to make sure that opportunity is distributed fairly. This is one of those moments where we can do a lot of good easily.


RSA Improves Keynote Diversity

andrew-akers

I'm a product marketing manager who loves learning about technology, information security, and identity. My goal is to turn that knowledge into positive outcomes for our customers. Before Auth0, I was a product marketing manager at Cisco in the network security division. In my spare time, you can find me spending time with my family, reading, writing, and working on endless home improvement projects.

Product Marketing Manager

Andrew Akers

Find out how step-up authentication can make media paywalls more user-friendly while discouraging churn.



## Think Paywalls Always Mean Unhappy Customers? Think Again.

CTO's in the media world are constantly juggling multiple, sometimes conflicting, priorities with how they manage access to their content. They have to combat user churn, drive revenue through a mix of ads and subscriptions, and maintain healthy traffic and SEO rankings.

In recent years, the paywall has evolved into an effective tool for balancing these needs, boosting subscriptions by restricting what content non-registered users can access.

The [_New York Times_](https://www.forbes.com/sites/greatspeculations/2017/05/04/new-york-times-digital-subscriptions-continue-to-drive-growth/#2a20a548295c), for example, increased its revenue through digital subscriptions under its paywall, even as ad revenue declined. However, using a paywall often comes at a cost to user experience (UX), and companies are wary of driving away users by forcing them to enter in their credentials.

[Step-up authentication](https://auth0.com/docs/multifactor-authentication/step-up-authentication) offers a way for media companies to balance security and UX, by only demanding that users enter their credentials under certain circumstances.

## How Step-Up Authentication Applies to Media

As we explained in our [introduction to the topic](https://auth0.com/blog/what-is-step-up-authentication-when-to-use-it/#Step-Up-Authentication-vs--Multi-Factor-Authentication-vs--Adaptive-Authentication), step-up authentication allows you to make some content easily accessible to users, but request authentication when users want to access more secure content.

One of the primary use cases for step-up authentication is a membership model that only grants full access to a site to paying, registered users, i.e., a paywall.

So how do you define more secure content? If you have a [metered paywall](https://auth0.com/blog/the-role-of-ciam-in-implementing-a-sound-paywall-strategy/), a registration box appears once a customer has visited their allotted number of pages per month. For a hard paywall, users might have to register to see the vast majority of a site’s content. And in a freemium model, certain pieces of content are reserved for paying users.

Step-up authentication becomes important for users who are already logged in but engaging in riskier behaviors than just browsing through content. For example, if a customer attempts to change their payment information, that would trigger a request for [multi-factor authentication (MFA)](https://auth0.com/docs/multifactor-authentication). MFA requires an additional form of credential, such as a one-time code or a fingerprint scan, to confirm that the person accessing this restricted area of your site is who they claim to be.

![Media companies can use Identity Management to solve challenges](https://images.ctfassets.net/23aumh6u8s0i/20LwKMDP0CXFzTiYeMRwXI/4d2cb9bdd4161bde760e2f1ee0f23c8c/media-industry-dismantle-01)

Having an extra layer of security that “steps up” to protect payments is crucial since [phishing and credential-stuffing attacks](https://auth0.com/blog/11-of-the-worst-data-breaches-in-media/) are on the rise. Generally, friends sharing the same set of credentials for a subscription is a low-level worry in media, but hackers using stolen credentials poses a much more serious threat. But even in the face of this threat, a good step-up authentication solution won’t represent an unpleasant disruption for users. Auth0’s [Guardian MFA](https://auth0.com/multifactor-authentication) makes the authentication process as easy and unobtrusive as possible. With Guardian, media companies can let users authenticate with a push notification on their smartphone, rather than forcing them to log in to their email or remember the answer to a years-old security question.

## How Step-Up Authentication Makes Paywalls User-friendly

[User churn](https://amplitude.com/blog/2016/01/27/understanding-user-retention) is the great enemy of media companies. A [Lenfest Institute study](https://centerforcooperativemedia.org/wp-content/uploads/sites/5/2018/04/Skibinski-Lenfest-MSU-Presentation.pdf) found that publishers’ online products have a median churn rate of 50% over a year, and while some customer turnover is inevitable, holding on to existing subscribers is still hugely important to maintaining a healthy media company.

Naturally, media companies are reluctant to make engagement more difficult by introducing friction around authentication. Forcing your readers to log in every time they want to access content is bad business, which is why step-up authentication only imposes that requirement under special circumstances.

The good news is that customers will tolerate authentication requests, provided they are employed thoughtfully. In a [2018 Experian study](https://www.experian.com/assets/decision-analytics/reports/global-fraud-report-2018.pdf), 66% of surveyed consumers reported that they like online security protocols because they make them feel safer.

When you employ step-up authentication with Auth0, you can still keep friction at a minimum with long-lived sessions, which can keep a user logged in to your site for up to a year. Auth0 would only require them to enter their credentials if they attempt to access more sensitive areas of your site.

Another major UX advantage for [multi-brand media companies](https://auth0.com/blog/how-enterprise-architects-can-cut-manteinance-costs-in-multi-brand-media/) is Single Sign-On (SSO). When you enable SSO across all your properties, users with bundled subscriptions can navigate freely between them. But even with SSO, you can use different paywall models across different brands. This way, one brand could have a metered paywall, while another could offer freemium content. Step-up authentication will act as a gatekeeper to ensure users only see what they’re paying for, but since they’re still logged in, you never lose sight of their [identity](https://auth0.com/blog/the-role-of-ciam-in-implementing-a-sound-paywall-strategy/) and behavior, which are crucial to refining your understanding of your users.

<include src="TweetQuote" quoteText="The media companies having the most success with paywalls are the ones that don’t treat them as rigid barriers. Find out more about Auth0 step-up authentication."/>

## Experimentation and Customization are Key

The media companies having the most success with paywalls are the ones that don’t treat them as rigid barriers. Instead, they experiment with how much content to put behind a paywall, and when to request authentication.

_The Economist_ spent [six months tinkering](https://digiday.com/media/economist-tightens-paywall/) with its number of free articles per month before landing on five as the magic number, while simultaneously publishing a significant amount of content in front of the paywall. Its circulation profits have [doubled](https://www.economistgroup.com/pdfs/2018_Annual_report.pdf) in the past five years. The Washington Post traditionally removes its paywall for [hurricane-related coverage](https://twitter.com/washingtonpost/status/1168138800121438211), which attracts readers and acts as good PR.

The most effective paywall strategy is unique to every media company, but to discover what the right mix is for you, your authentication solution has to be flexible and allow for easy alterations. Auth0’s platform, with its easily customizable [Rules](https://auth0.com/docs/rules), lets you quickly change what content falls in and outside the paywall.

![Users can access content using multiple devices](https://images.ctfassets.net/23aumh6u8s0i/5thwMutvBKJsFi5CoBpJkG/4982337f9d017cafd180b8568cd36933/media-industry-dismantle-02)

You can customize further with adaptive or contextual authorization, which are interrelated concepts with step-up authentication. Adaptive authentication is triggered by user behavior, rather than the content they are trying to access. This type of behavior could be a user signing on to a new device, multiple devices at once, or from a suspicious location. For example, if a user logs on in Australia and then logs on fifteen minutes later in Delaware, this will trigger an authentication request.

Whether or not to implement adaptive authentication depends on your business model. HBO, for instance, is quite liberal in allowing shared credentials logged in at the same time, whereas other media companies are more restrictive. Whatever your needs, Auth0 has highly customizable MFA capabilities around adaptive authentication.

## Step Up to Security That Won’t Drive Users Away

As media companies seek to limit their reliance on ads, and customers become more comfortable with subscribing to their preferred media, paywalls will increase in prevalence and importance. A [2019 Imperial College/Brave Software study](https://arxiv.org/abs/1903.01406) showed that the trend is already taking hold, with 33% of sites on the top-1000 news index using some form of paywall.

<include src="TweetQuote" quoteText="Step-up authentication offers a way for media companies to balance security and UX, by only demanding that users enter their credentials under certain circumstances."/>

But all paywalls are not created equally, and the media companies who use them effectively will be those with an approach to authentication that doesn’t increase churn. According to the Imperial study, a quarter of news sites outsource paywall functionality to a third-party, but of course, those aren’t created equally either. Given how high the stakes are, it’s essential to outsource this crucial function to an authentication partner like Auth0, with the customizability to implement step-up authentication under just the right circumstances.

<include src="asides/AboutAuth0" />


Step-Up Authentication is Key to Making Paywalls Work in Media

eva-sarafianou

Eva is a Product Security Engineer with a special interest in Cryptography that loves building, securing, and breaking software. At Auth0, Eva works on making our identity platform secure and trusted. She spends her spare time playing the piano, taking dance lessons, and doing outdoors activities.

Product Security Engineer

Eva Sarafianou

marius-mogyorosi

As an Application Security Engineer at Auth0, Marius champions security throughout the software development process with practices ranging from threat modeling to operational application security. Off-hours, he enjoys barbecuing and learning about most things.

Application Security Engineer

Marius Mogyorosi

Cryptography has three key properties: confidentiality, integrity, and authenticity. Let’s learn which of these apply to encryption, hashing, encoding, and obfuscation.

How Secure Are Encryption, Hashing, Encoding and Obfuscation?

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

London digital consultancy on why a culture of learning is key to continuous innovation


Founded by digital heavyweight Nuno Job, London-based [YLD](https://www.yld.io/) helps the world's leading organizations like [Canon](https://www.yld.io/case-study/canon-giving-stories-a-new-form), [Joyent](https://www.joyent.com/) (now part of Samsung), Microsoft and Google, build digital products used daily by millions.

Before YLD, [Job](https://www.linkedin.com/in/nunojob/) was Chief Commercial Officer at Nodejitsu responsible for the world's largest Node.js cloud. He joined forces with [Anthony Mann](https://uk.linkedin.com/in/anthony-mann-11251214), an Apple alum and founder of digital product agency, [Make Us Proud, now part of YLD](https://medium.com/yld-blog/yld-announces-a-merger-with-make-us-proud-cc53b8ad00e2). Together they are building a software engineering and design consultancy focused on continuous innovation.

"We embed ourselves within our clients' teams to ensure they learn and develop the capabilities to succeed well beyond our engagement," says Job. "This is how we achieve our goal of helping the world's leading companies stay ahead of the curve."

YLD actively contributes to the [open source community](https://www.yld.io/open-source/) (check them out on [Github](https://github.com/yldio) and [StackOverflow](https://stackoverflow.com/jobs/companies/yld)), proud members of OS foundations, and run meetups and tech conferences to teach new skills to current and prospective clients.

At Auth0, we are democratizing identity knowledge — see our [Learn Identity video series](https://t.co/2tntMIFpip?amp=1) and [Identicons](https://t.co/pKgxaCZFRl?amp=1), an open-source visual language for identity. YLD is a natural partner for us, and we recently hosted a joint training on how to build a [React Native App with Auth0](https://ti.to/yld-academy/auth0-yld-training-react-native-app) integration in two days.

Here we explore two case studies where we worked together to help a joint customer and YLD employees succeed in their digital business strategies.

## Customer Case Study: Gula Adds Auth0 to iOS and Android Apps in One Day

YLD put their culture of learning into practice by creating YLD Labs, a subsidiary company focused on ventures. Their newest venture project is [Gula](https://www.gula.pet/), a mobile app that offers video consultations with a local vet. The app enables timely, affordable, and relevant healthcare that addresses pet health problems and improves owner understanding of their pet.

YLD built Gula using [React Native](https://www.yld.io/speciality/react-native/) and chose Auth0 to cut time to market and offer a great customer experience. [Auth0 Rules](https://auth0.com/resources/videos/learn-how-to-use-auth0-rules) allowed YLD to deeply integrate user signup with Gula's app with no infrastructure needed. Using Auth0, they implemented authentication in Gula's iOS and Android apps [in one day](https://auth0.com/blog/the-real-roi-of-auth0-part-1-time-to-market/).

Auth0 also allowed Gula to offer social login with Google and Facebook with no extra effort.

![Gula's login using Social Login by Auth0](https://images.ctfassets.net/23aumh6u8s0i/XDwzYijcUghAWvEOP00qg/e3c13036dd5e09b14d3a1e8e1fca17fe/gula-social-login-with-auth0)

Thanks to Auth0 and React Native, Gula went from an idea to an app in the hands of consumers in less than two months. The customisable solutions will allow them to swiftly manage change and support additional login capabilities, like [Sign In with Apple](https://auth0.com/blog/auth0-adds-sign-in-with-apple-as-ootb-integration/).

## Employee Case Study: YLD Builds Product Management Tool in Weeks Using Auth0 and PouchDb

With a culture of continuous innovation, YLD is always pushing themselves to improve internal processes by applying emerging technologies. By investing in Auth0 they were able provide frictionless authentication for several employee tools including a product management tool, called the "confidence framework," and a budget manager.

The confidence framework tool is a product management web app that incorporates the core concepts of a product management framework developed by YLD. Using Auth0 and [PouchDb](https://pouchdb.com/users.html), YLD built a working prototype of this tool in weeks. It leverages auth0.WebAuth, allows users to sign in with their company Google email, and is now used by YLD employees at client projects.

![Product Management Tool YLD built with Auth0 and PouchDb](https://images.ctfassets.net/23aumh6u8s0i/29Iw76uADIbTnu4BuDHUtV/66cea262b3ec27ab14a176916cda92f7/yld-product-management-tool-built-with-auth0-and-pouchdb)

Additionally, YLD built a budget manager that leverages auth0.WebAuth, allows users to sign in with their company Google email, and restricts sign-ups to relevant employees. This tool enables employees across the business to access the budget for their department and the finance team to manage all budgets. Auth0 enabled YLD to create access control rules easily and in very little time.

![YLD created access control rules with Auth0](https://images.ctfassets.net/23aumh6u8s0i/5tWi3EZ61ldwPbMnw0thKD/badfb60bc4ccfe41867f9e05b44c24cf/yld-using-control-rules)

## Digital Business Requires Continuous Innovation

According to KPMG, 71% of 1,000 UK workers agree that embracing [digital transformation is a key priority at their workplace](https://www.itproportal.com/news/uk-workers-are-seeing-digital-transformation-happening-at-work/). But becoming a truly digital business is not a quick-fix or one-time project. It requires a company-wide commitment to empowering people with the right tools, skills, and knowledge to succeed today and tomorrow, and Auth0 and YLD can help.

To learn more about how Auth0 and YLD can support your specific project or digital transformation, contact an [Auth0 resource](mailto:%20sales@auth0.com).

For more information on Auth0's Partner Program, visit: <https://auth0.com/partners>.


Partner Spotlight: YLD

diegopoza

System Engineer, geek, foodie, technology lover, speaker.

Sr Manager, Developer Advocacy

Diego Poza

Key solutions like anomaly detection, universal login, and custom security rules delivered by Auth0 helps its customers protect sensitive user data.



Tight infrastructure security is critical — but if you don't remember to secure your web applications, customer data remains exposed.

There are several [common threats to web-app security](https://auth0.com/blog/common-threats-in-web-app-security/):

- A lack of encryption between your web browser and their servers
- XSS (cross-site scripting) that occurs when malicious scripts are injected into web applications
- Clickjacking (when an attacker injects transparent or opaque objects into a web application)
- Cross-site request forgery (where the attacker impersonates an authorized user and requests sensitive information, such as passwords)

These threats are continuing to multiply and become more complex by the day. To mitigate breaches, particularly in a time of [heavy regulatory scrutiny](https://auth0.com/docs/compliance/gdpr), Auth0 offers three major strategies:

1.  Anomaly Detection
2.  Universal Login Support
3.  Customizable Rules

Auth0 allows you to combine these features to further amplify protection for your app's end users. While you can always attempt to develop these and similar solutions in-house, outsourcing app security will give you access to a team of experts who work 24/7 to keep up with the latest trends in a constantly evolving space.

## Anomaly Detection

Auth0 provides three built-in shields that [detect anomalies](https://auth0.com/docs/anomaly-detection) among users in an app's system. Used separately or in combination, the shields have the ability to stop malicious access attempts before they occur. Administrators receive alerts of suspicious activity and can then block future login attempts by an aberrant user.

<include src="TweetQuote" quoteText="Learn more about how Auth0 provides three built-in shields that detect anomalies among users in an app's system."/>

### Brute-Force Protection

Within its [Brute-Force Protection](https://auth0.com/docs/anomaly-detection) feature, Auth0 has two distinct shields:

1.  Shield 1 is triggered after 10 failed login attempts on a single account from the same IP address.
2.  Shield 2 is triggered after 100 failed login attempts from a single IP address via different usernames in 24 hours or after 50 sign-up attempts in one minute from the same IP address.

When Shield 1's threshold is reached, an email is automatically sent to the user, which an administrator can edit however he or she wishes. This initial email looks like:

![Affected user email](https://images.ctfassets.net/23aumh6u8s0i/7Hf4QzvX6IDVi6gl4hGRp4/8fc62d71de2ae3698d64c087b89c730c/affected-user-email)

An administrator can easily edit the template by accessing the Auth0 [Dashboard](https://auth0.com/docs/dashboard) and following Emails > Templates.

When Shield 2 is triggered, dashboard administrators are notified. Brute-Force Protection will also block the suspicious IP address. When the issue is resolved, an administrator simply locates the user in the Auth0 [Dashboard](https://auth0.com/docs/dashboard) and files an action to unblock. A user can also click on the "unblock" link provided in the email above or change their password.

### Breached-Password Detection

The third shield is breached-password detection. This is easy to turn on and customize in the Anomaly Detection section of the Auth0 dashboard.

![Breached-password anomaly detection with Auth0](https://images.ctfassets.net/23aumh6u8s0i/3Oe0VufANczOhCpPtuL8iV/99ffa473077e16cd7733334c25a9c73d/breached-password-shield)

Breached-password detection is useful in instances where Auth0 suspects that a user's email has been compromised in a major security breach. (Auth0 consistently tracks these on third-party sites.) If this occurs, Auth0 will trigger the shield, notify the user, and block them from logging in until they reset their information. Breached-password detection is becoming increasingly helpful as many individuals use the same or similar iterations of the same password on multiple sites.

<include src="TweetQuote" quoteText="When Auth0 suspects that a user's email has been compromised in a security breach, Auth0 will trigger a protective shield, notify the user, and block them from logging in until they reset their information"/>

## Universal Login

Auth0 supports [universal login](https://auth0.com/blog/authentication-provider-best-practices-centralized-login/) on customer apps. In contrast to embedded login, this offers increased security and a shorter setup time.

![Auth0 Universal Login offerings](https://images.ctfassets.net/23aumh6u8s0i/21BR2xIUfU721nga9W1FqO/184597f0a961d89938bb9923b08e6a73/centralized-embedded-diagram)

Universal login is a more seamless experience for the user. On the front end he or she sees a simple authentication request; on the back end, credentials remain within the same domain instead of being sent across origins. This makes it a far more secure method than exposing the information to outside sources. When personal data moves from one origin to another, [phishing attacks](https://auth0.com/blog/all-you-need-to-know-about-the-google-docs-phishing-attack/) and [man-in-the-middle attacks](https://auth0.com/docs/security/common-threats#man-in-the-middle-mitm-attacks) become common.

In addition to an enhanced customer experience, universal login is simpler for administrators to maintain and provides the benefits of single sign-on (SSO).

## Auth0 Security Rules

Auth0 has developed customizable [Rules](https://auth0.com/docs/rules/current) for its app-security features. Rules are JavaScript functions that execute when a user authenticates to your application. Rules can be helpful when customizing and extending Auth0's existing capabilities. For example, the [Force Email Verification](https://auth0.com/rules/email-verified) and [User Fraud Score](https://auth0.com/rules/socure_fraudscore) Rules can be incorporated into Auth0's existing tools like Anomaly Detection to better determine if a user truly is who they say they are.

### Force Email Verification

Force Email Verification only allows app access to users who have verified their emails. Incorporating Force Email Verification into an app instead of a browser version is a good UX practice with powerful back end capabilities.

![Force Email Verification code](https://images.ctfassets.net/23aumh6u8s0i/6MhbfE6DYpGdnku3wGI9Rn/4dd87042b24817242ccde8b52d16c781/verify-email-code)

[[Source](https://auth0.com/rules/email-verified)]

For example, if you are working with a large set of emails that belong to a network, e.g., `@university.edu` or `@company.edu`, Force Email Verification can help parse individuals in a group to make sure that a fake user hasn't set up an account to blend in with the others. Force Email Verification requests that users cross-check their information; anyone who returns information that doesn't match or does not return additional information at all will be blocked from logging in.

### User Fraud Score

Like Force Email Verification, you can tack on the User Fraud Score to a variety of features. If you've built an online marketplace — like Etsy, for example — you can use this rule to cross-check everyone conducting business and thus add an extra layer of protection to purchases. The Rule calculates a fraud score for every user, based on their email address and IP address.

```javascript
function (user, context, callback) {
  // score fraudscore once (if it's already set, skip this)
  user.app_metadata = user.app_metadata || {};
  if (user.app_metadata.socure_fraudscore) return callback(null, user, context);

  if(!user.email) {
    // the profile doesn't have email so we can't query their api.
    return callback(null, user, context);
  }

  const request = require('request');

  // socurekey=A678hF8E323172B78E9&email=jdoe@acmeinc.com&ipaddress=1.2.3.4&mobilephone=%2B12015550157
  request({
    url: 'https://service.socure.com/api/1/EmailAuthScore',
    qs: {
      email:  user.email,
      socurekey: configuration.SOCURE_KEY,
      ipaddress: context.request.ip
    }
  }, function (err, resp, body) {
    if (err) return callback(null, user, context);
    if (resp.statusCode !== 200) return callback(null, user, context);
    const socure_response = JSON.parse(body);
    if (socure_response.status !== 'Ok') return callback(null, user, context);

    user.app_metadata = user.app_metadata || {};
    user.app_metadata.socure_fraudscore = socure_response.data.fraudscore;
    user.app_metadata.socure_confidence = socure_response.data.confidence;
    // "details":[
    //     "blacklisted":{
    //        "industry":"Banking and Finance",
    //        "reporteddate":"2014-07-02",
    //        "reason":"ChargeBack Fraud"
    //     }
    // ]
    user.app_metadata.socure_details = socure_response.data.details;

    auth0.users.updateAppMetadata(user.user_id, user.app_metadata)
      .then(function(){
        context.idToken['https://example.com/socure_fraudscore'] = user.app_metadata.socure_fraudscore;
        context.idToken['https://example.com/socure_confidence'] = user.app_metadata.socure_confidence;
        context.idToken['https://example.com/socure_details'] = user.app_metadata.socure_details;
        callback(null, user, context);
      })
      .catch(function(err){
        callback(null, user, context);
      });
  });
}
```

In the Auth0 Dashboard, copy the code block above, and replace placeholders with the appropriate values. The rule will pull the fraud score from socure.com and store it on app_metadata. A full set of Auth0 Rules can be found [here](https://auth0.com/docs/rules/current).

For fraud detection, Auth0 partners with [ThisData](https://auth0.com/blog/anomaly-detection-safer-login-with-thisdata-and-auth0/). ThisData allows real-time detection of any account takeovers across both web and mobile apps.

## No Better Time To Secure Your Apps

Securing your app with the best tools is always a good decision — but it is especially timely, given the slew of new regulations: GDPR deadline has passed, but [it's not too late to comply](https://auth0.com/blog/your-quick-gdpr-compliance-checklist/), and several countries and states in the U.S. have followed the EU with [similar privacy initiatives](https://auth0.com/blog/brace-yourself-the-gdpr-ripple-effect-in-california/). In line with these events, Auth0 has developed additional [strategies](https://auth0.com/gdpr-assessment/) for getting your team into alignment quickly, including [customer identity and access management (CIAM) protocol](https://auth0.com/blog/digital-success-through-customer-identity-and-access-management/).

While it might be easy to forget your apps in the swirl of demands around your core operations — making sure you plug any holes here is key to ensuring that you don't become another [data-breach statistic](https://consequenceofsound.net/2018/06/ticketfly-hacker-data-breach/).


How Auth0 Makes Your Apps More Secure

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing.<br/><br/> Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas


Financial institutions are under intense scrutiny by regulators as well as customers to be sure that their user data is secure. Legal pressures are mounting, and customers are increasingly [vocal and demanding](https://auth0.com/blog/cambridge-analytica-and-facebook/) that companies are more transparent and responsible with their information. Finance, over and above other industries, demands a higher level of protection. Behemoth institutions like [J.P. Morgan](https://dealbook.nytimes.com/2014/12/22/entry-point-of-jpmorgan-data-breach-is-identified/?mtrref=www.google.com&gwh=7D07D481AE355F1F8949A1C514F4B11C&gwt=pay&assetType=nyt_now) and [Equifax](https://finance.yahoo.com/news/equifax-reveals-many-ssns-credit-cards-passports-hacked-182355107.html) continue to be top targets for cybercriminals.

One concrete step that these institutions, along with smaller firms, can take is to secure their consumer apps. Traditionally, apps with authentication systems require users to provide a single identifier, such as an email address, username, or phone number, along with a correct password or pin to gain access; however, with financial apps, this isn't always enough.

**Two-factor authentication** or ***2FA*** adds an additional step to the process. Like a double security door — if a thief unlocks the first one, he's blocked by another.

## Breaking Down Common 2FA Approaches

In general, there are [three factors](https://preview.pcmag.com/feature/358289/two-factor-authentication-who-has-it-and-how-to-set-it-up) in authentication:

1. Something you know (such as a password you created)
2. Something you have (such as a cell phone or other piece of hardware)
3. Something you are (such as your fingerprint, gait, or facial features)

Two-factor authentication requires that you have two of these options. In addition to a password that you “know,” 2FA can request you “have” a cell phone or other device handy for a TOTP (a time-based one-time password algorithm) or that you present a biometric, such as a thumbprint.

### Time-based one-time password algorithm (TOTP)

A time-based one-time password algorithm or TOTP generates one short-lived (~30 seconds or less) password from a secret key in combination with a current timestamp. A [cryptographic hash function](https://www.lifewire.com/cryptographic-hash-function-2625832) connects these two.

The [Microsoft Authenticator](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/end-user/microsoft-authenticator-app-how-to) is a common option that generates a TOTP:

![Microsoft Authenticator generates a time-based one-time password (TOTP)](https://images.ctfassets.net/23aumh6u8s0i/77LXTM6VFF3ZAkPcn7hvn/8e09b57c1939e64b314c6f96d16fd214/microsoft-authenticator-generates-a-totp.png)

Prior to logging into an app, users will go to Microsoft Authenticator, generate their code, and, before it expires, use it to log into the app. Other leaders in the space include the Google Authenticator, along with smaller providers like Twilio, Authy, Duo Mobile, and the LastPass Authenticator. These providers offer 2FA solutions for both mobile and desktop platforms.

### Biometrics

Biometrics have made big strides in recent years, including the launch of Apple’s iPhone X facial recognition feature. Widely used biometrics for identity verification include iris or retina recognition, facial, fingerprint, hand, and even DNA usage.

Many consumer financial apps, like TD Bank's app for basic checking, savings, and transfer options, employ the thumbprint as a second authenticator:

![TD Bank employs the thumbprint as a second authenticator.](https://images.ctfassets.net/23aumh6u8s0i/GPD4cX5JIXBjbCmuyhpzX/c66fe2fe191fdbc53cda4080eb774a18/td-bank-employs-thumbprint-for-2fa)

[Source: PhoneArena News](https://www.phonearena.com/news/How-to-use-your-fingerprint-scanner-to-log-in-websites-on-a-Samsung-smartphone_id73835)

Users are prompted to place their thumb on the home button for identification prior to entering the app. Several established firms, including [Vanguard](https://personal.vanguard.com/us/insights/article/mobile-touch-id-062016?lang=en) and other asset managers, have incorporated Touch ID as well as [voice verification](https://investor.vanguard.com/account-conveniences/voice-verification) for certain transactions.

<include src="TweetQuote" quoteText="Despite the proven ability of 2FA to reduce the threat of a security breach, the trick is getting users to opt in."/>

## The Challenge: Get Users to Opt In

Despite the proven ability of 2FA to reduce the threat of a security breach along with the ease of setup (no advanced security or developer skills are [required](https://auth0.com/learn/two-factor-authentication/)), 2FA has yet to become mainstream. It can be unclear for many users how to set up 2FA. For example, with services like [PayPal](https://www.paypal.com/us/selfhelp/article/how-do-i-enable-2fa-(two-factor-authentication)-for-my-paypal-powered-by-braintree-user-faq3500), users have to log into their control panel, navigate to their account, and enable 2FA with a QR code or another supported app:

![PayPal supports 2FA with mobile or security key cards](https://images.ctfassets.net/23aumh6u8s0i/wwNSq8sW8ky2GQE9uopOw/7b1d58cba76d2a661b1610ea4062d05b/paypal-supports-2fa-with-mobile-or-security-keys)

It can be difficult for a user without 2FA knowledge to know which option to choose — after already puzzling out how to get to this stage without clear directions in the first place. While some may opt for SMS (first option), the second option (TOTP) doesn't rely on incoming text messages and has proven to be more secure.

For financial firms looking to gain customer trust, making the 2FA setup simple (or figuring out a way to integrate it into their app's UX in a seamless way) will go a long way toward distinguishing themselves from the pack. Customers are particularly looking for a high level of security with their financial information. If you can clearly communicate your enhanced strategy, you will gain a competitive advantage.

<include src="TweetQuote" quoteText="Customer happiness and high engagement are the biggest determinants of its success."/>

### Discourage Password Use

One way to help users understand the importance of 2FA is to discourage the use of passwords alone. Passwords are historically vulnerable due to human error (we're often lazy about re-creating lengthy, secure, and unique passwords and instead recycle the same or iterations of the same password for the majority of accounts) and the ease with which hackers can access this first level of authentication. Explaining that breaches of personal information happen daily — due to phishing and additional criminal tactics that get the user to unknowingly reveal their password — can prompt your customers to consider an alternative. While a [password manager](https://www.pcmag.com/article2/0,2817,2407168,00.asp) is one option, 2FA brings another dimension to the security game altogether. If one or multiple passwords are compromised, a hacker still cannot access the account without acquiring the second factor.

### Balance UX and Practicality

In many cases, customer happiness with a new feature and a [high level of engagement](https://www.youtube.com/watch?v=30f_lVQBzYs) with it are the most important determinants of its success. With cybersecurity features, however, where do you draw the line between ease and enjoyment of use and practicality? Should something so critical be fun? Do users want to see the same types of design for 2FA integrations that they see with, say, e-commerce apps? You don't necessarily have to sacrifice a pleasant user experience due to the serious nature of a 2FA feature; at the same time, you should be conscious that 2FA is distinct in its functionality. Consider a design that is utilitarian, clear, and makes the user understand the power behind the tool.

The Google Authenticator, for example, balances clarity, capability, and a splash of color:

![Google Authenticator balances clarity, capability, and design](https://images.ctfassets.net/23aumh6u8s0i/7mg1gsfPl51QE6co76WWfv/80258abc625c467ee0ec0567048b85fa/google-authenticator-balances-clarity-capability-design)

[Source: GeekyGadgets blog](https://www.geeky-gadgets.com/google-authenticator-ios-app-update-removes-user-accounts-04-09-2013/)

Whichever authenticator tool you offer your users it should reflect your brand and focus. Further reading on the topic that we've found helpful includes:

1. [UX vs. Cybersecurity](https://medium.com/@4Barel/ux-vs-cybersecurity-3eedf77ed6e7)
2. [Cyber Security Requires an Important Ingredient: Strong UX](https://hackernoon.com/cyber-security-requires-an-important-ingredient-strong-ux-d0727a0c076)
3. [What is two-factor authentication, and which 2FA apps are best?](https://www.pcworld.com/article/3225913/security/what-is-two-factor-authentication-and-which-2fa-apps-are-best.html)

## Conclusion: Be There for Your Customers

Figuring out how to integrate 2FA into your consumer financial apps in ways that will make your customers opt-in and enjoy the process will give them peace of mind, help ensure your firm is [compliant](https://auth0.com/gdpr), and even allow you a competitive advantage in the race to gain user support and trust.

<include src="asides/AboutAuth0" />


How Two-Factor Authentication (2FA) Can Help Financial Institutions Reduce Data Breaches

Enterprise wins and channel program momentum are key factors in regional growth




**BELLEVUE, Wash. -- April 18, 2018** -- [_Auth0_](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), today announced rapid expansion across EMEA, a region which has already seen 550% year-over-year growth. Key contributors to Auth0’s momentum include contracts signed with well-known brands in retail, travel, transport, and financial services, as well as EMEA-wide agreements with key partners, such as [_AppXite_](https://globenewswire.com/news-release/2018/03/20/1442485/0/en/Auth0-Announces-Key-Distribution-Partnership-with-AppXite.html).

“In today's world with cloud computing services and microservices, integrating with other packages which specialize in a specific industry is usually a lot more cost- and time-efficient than just doing it all by yourself,” says Auth0 customer, Nicolas Dormont, Vice President of Information Systems, abas USA and Corporate Product Manager, abas AG. “We would have had to probably delay the projects at least six months to get to a point where we are with Auth0. To implement Auth0, we are talking days, not even weeks.”

A [_Forrester Research* report_](https://www.forrester.com/report/The+IAM+Market+Will+Surpass+13+Billion+By+2021/-/E-RES138932) predicts that the IAM industry will surpass $13 billion by 2021. This market growth coupled with major ongoing initiatives like digital transformation, an increased focus on data protection (GDPR), and migration from restrictive, in-house identity solutions, is driving the demand for an extensible, secure, and easy-to-implement platform. Auth0 is well-positioned to satisfy strategic identity needs for businesses in EMEA as it continues its global expansion.

“It is fantastic to see such incredible growth in EMEA. The combination of our technology with a high-performing team, led by EMEA General Manager Steven Rees-Pullman, is landing deals with world-class businesses,” said Eugenio Pace, CEO and Co-founder of Auth0. “In 2018, we will double down and continue to invest more resources into our team and partners in the region, with the primary goal of supporting our customers now, and in the future.”
To ensure that Auth0 continues to deliver high-quality solutions and value to customers and partners, growth objectives for 2018 include [_doubling the size_](https://auth0.com/careers) of the EMEA team. In 2017 globally, Auth0 added 140 employees, bolstering its leadership with [_key appointments_](https://auth0.com/blog/auth0-expands-leadership-team/), and [_added offices_](https://auth0.com/blog/auth0-announces-record-year/) in London, Sydney, and Tokyo.

(*Report available to Forrester subscribers or for purchase.)

<include src="asides/AboutAuth0" />














Auth0 Continues Rapid Expansion in EMEA

End-to-end identity management now available to all AppXite resellers.



**LONDON, UK - March 20, 2018** – [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), has announced a new partnership with [AppXite](https://appxite.com/), a global leader in SaaS solutions aggregation and fully owned subsidiary of [Atea](https://www.atea.com/). Auth0’s identity and access management platform will be added to AppXite’s SaaS offering, adding even more value to its global reseller offering.

Auth0’s Universal Identity platform will now be accessible to AppXite’s extensive global network of managed service providers (MSPs), value-added resellers (VARs), and systems integrators (SIs) around the world. AppXite’s reseller network can integrate Auth0’s identity platform into their own offering to increase profitability, expand market share, and help their customers thrive in today’s cloud economy.

"Over the past few years, we have noticed a marked increase in demand for identity management. Companies are realizing the complexity of trying to handle internally and are turning to us for solutions," said Nicolas Albana, CEO of AppXite. "We strongly believe in Auth0 as a proven, industry standard authentication and authorization solution provider and we use their solutions in all our IP development efforts as strategic vendor."

AppXite selects technology solutions based on their ability to provide its partners with recurring revenues, strong margins, and competitive advantages. The company has even implemented Auth0 internally based on its value to the organization in easily managing the digital identities of their customer, partners, and employees.

"Our growth in 2018 will be attributed, in part, to the incredible partnerships we make in the channel that enable us to reach a wider network of customers," said Andrew Morris, EMEA Alliances and Channels Director. "Our partnership with AppXite marks an exciting step and we are looking forward to providing our identity platform to their huge reseller network."

Auth0 also recently joined the [Google Cloud Platform](https://auth0.com/learn/gcp/) as a technology partner. For more information on the Auth0 Partner Program, or to join, please visit: [https://auth0.com/partners](https://auth0.com/partners).

<include src="asides/AboutAuth0" />


Auth0 Announces Key Distribution Partnership with AppXite

In advertising, Data is king, but that doesn't always mean it's put to good use. Until now.



Companies today are generating and collecting more data on their customers than ever before. This information is a cornerstone of contemporary advertising because it offers companies a way to better tailor every aspect of their content to prospective customers. This means smarter ad spending and more cost-effective campaigns.

But understanding what types of data your company can collect is not easy. And how you can use that wealth of information only complicates matters.

Looking at today's consumer information landscape, the easiest place to start crafting better ads through consumer information is by utilizing first-party data. Not only is first-party data readily available to companies, it can be easy to collect. And using it to boost ad revenue doesn't have to be complicated. It's about being savvy with your data and building on what you already have.

## What is first-party data?

First-party data is data that you collect yourself. It could be data about how your customers use your product or website, demographic data, information you collect from surveys, social data, pretty much anything that you collect firsthand yourself.

![First-party, Second-party, Third-party data](https://images.ctfassets.net/23aumh6u8s0i/7EZnv3zqZsGN2OvCpGNeqi/a2577697e133cce911ccbffd987ddb79/partydata)

This is different from second or third party data because there's no intermediary between you and the information. Second party data is first-party data that is not your own. You might acquire it in a business partnership, for example.

Third party data is data that you have no affiliation with but is available to you, usually for purchase. For example, an organization could buy first party data from different companies, repackage it together, and then sell it. Usually, you have little idea where, exactly, this data is coming from.

If you set yourself up well, first-party data is your highest-quality, cheapest option for data collection.

### First-Party data in advertising today

As software becomes more and more embedded in advertising, first-party data's role will increase. Programmatic advertising, wherein software is responsible for automating key parts of running an ad, like choosing target demographics, is already on the rise. This isn't as complicated as it sounds, tools like [AdEspresso](https://adespresso.com/), which automates Facebook ads, have been on the market for years. “More than [50%](http://west.gannettuscp.com/images/uploads/attachments/eMarketer_US_Digital_Display_Advertising_Trends-Eight_Developments_to_Watch_for_in_2016.pdf) of all US digital video ad spending will flow via automation in 2016,” and advertisers will be reliant on data to help these programs make better decisions.


As much of the leg work of advertising is automated in this way, knowing more details about your consumers will allow you to maximize the power of automation. A unified view of subscriber demographic and behavior will be critical to make this strategy relevant. Consumers are already shifting to expect relevant, timely advertising across channels, and a mix of information and programming will be key to delivering this in the future.

So, now that we know what first-party data is and how it's important, let's look at how you can use it to make better, more cost-effective ads.

### 1. Leverage social login

Social logins are great for both consumers and companies. With a good identity management system, they're easy to add and can be a great way to start getting serious about your first-party data.

An important way that social login helps you better collect information yourself is by adding a layer of transparency. Consumers generally feel uncomfortable if they find out a company is gathering all their information to do what they will with. A prime example of this? Unroll.me [selling](https://theintercept.com/2017/04/24/stop-using-unroll-me-right-now-it-sold-your-data-to-uber/) their first-party data to other companies, like Uber, causing widespread outrage.

Social logins give your consumers choice, because they can opt-in to what information they want to share. When a user signs in for the first time, you can notify them what data you'd like to receive (e.g. location, friends list) and have them check or uncheck what they feel comfortable sharing.

<include src="TweetQuote" quoteText="Social logins give your consumers choice, because they can opt-in to what information they want to share."/>

This builds trust with your consumer, while still allowing you to get the data you need.

Take, for example, the Washington Post. You can sign in via email, but also with your Amazon and Facebook accounts.

![Login Options](https://images.ctfassets.net/23aumh6u8s0i/4Iwoow7H7rWUyqtZLotIt8/20234d1b2a9c9e710886051f679c5f07/loginoptions)

This helps their ad strategy, because it allows them to look at what customers are interested in. What they're [liking on Facebook](https://www.sellbrite.com/blog/generating-facebook-ad-content/) and buying or [looking at on Amazon](https://www.sellbrite.com/blog/amazon-ppc-7-secrets-for-maximizing-return/) directly informs the ads that subscribers get on the Washington Post.

This kind of data could even help broader efforts, not just hyper-personal ads. As a hypothetical example, if frequent readers of the “economy” section check in to restaurants on Facebook more than any other section, then restaurants who want to advertise with the Washington Post can ask for and receive prime ad space because the Washington Post has the data to inform that choice.

### 2. Link accounts to nail personalization

For accurate first-party data, you want every user to be associated with one profile in your system. This is where you can store information about them to draw from when making any number of decisions, so you want to make sure that it's a good representation of your customers.

If someone logs in via Facebook one day and email the next, they could end up with two profiles in your system. This will skew your data and make it harder for you to make accurate insights, you need to [link those accounts](https://auth0.com/docs/link-accounts) together into one central profile.

It can also negatively impact the way you remarket to customers. If you don't have accurate information of a customer's use or purchase history, you may end up annoying them by blasting their social account with ads for things they've already purchased while logged into an account via email.

![Central Profile](https://images.ctfassets.net/23aumh6u8s0i/4mqgavgS2k1YYLvDCf0tQx/70e9b65e5b60b3d446e88f909a23ac56/centralprofile)

Relevance and personalization are key when it comes to ads today. Nobody wants to see irrelevant ads, and people will mark ads on social as annoying or unnecessary when they get flooded by them. Some will even go so far as to use an ad blocker, which proves how impersonal and spammy ads can seem.

<include src="TweetQuote" quoteText="Relevance and personalization are key when it comes to ads today."/>

You can cut down on irrelevant ads by linking accounts because you have a full picture in your first-party data on any given customer. This helps you serve each individual user better, but also helps you [better identify trends and behaviors](https://www.interana.com/blog/10-stories-companies-changed-users-behavior/) that you would otherwise botch because it looks like several people are doing the actions of one.

### Provide an omnichannel experience

Social login also allows your users to have the same [customer experience](https://www.zendesk.com/resources/why-companies-should-invest-in-the-customer-experience/) when logging in across any device. This keeps your brand consistent and helps make you more customer-friendly. While retailers are still figuring out how to provide a truly seamless experience, [omnichannel](https://auth0.com/blog/the-three-best-ways-to-create-the-single-vision-of-a-customer/) is the future of how you interact with your customers.

You can keep tabs on users easily across channels. If they're using social login on their phone one day and their computer the next, you can keep all that information stored in their profile. All their consumer data, that first-party data you want, is consistently paired with their profile with no effort on your end.

This means it's easier to serve the right ads to the right people and it's also easier to see how each individual is reacting to the ads. This feeds directly back into the personalization that's so important in digital advertising.

## Better segmentation, higher rate cards

When you're a media publisher, first-party data can help not only with how you understand your own customers, but also with how third-party advertisers access them as well.

When you've collected first-party data on your customers, you can better segment your audience. Demography, common interests, device usage, likes and dislikes, among other things, can help you understand exactly what your audience wants and what they're looking for, which helps you make third-party ad placements more effective.

Rate cards for publications can be segmented in any way the publication chooses. Some choose to specify primarily on placement, like the Food Network Magazine:

![Rate base](https://images.ctfassets.net/23aumh6u8s0i/6FyYat4AK7oJrWY8f8E2vN/86dd25d2238b188d77426719d2db295c/ratebase)
_Source: [foodnetworkmediakit.com](http://www.foodnetworkmediakit.com/digital-edition)_

Others, like Adweek have a variety of options for placement and targeting:

![Ratecard](https://images.ctfassets.net/23aumh6u8s0i/1iYZXqejhWgKliCBwyrIf8/4946d739c2614d4ef2e967eed3fa5295/ratecard)
_Source: [adweek.com](http://www.adweek.com/files/2014-Digital-Rate-Card-101414.pdf)_

When you have the information on your users to be able to offer more effective ads on your publication or site, that can enable you to increase your ad rate cards, which is great for your business. You can use your data to segment the ads you run by age, demographic or behavior and charge more for people that buy more, or are more suited to a particular advertiser's product.

Advertisers will be more confident that their placement with you is a good fit and will provide a return on investment. And your consumers will be more intrigued by ads instead of feeling annoyed by them. It's a win-win-win.

## Knowledge is power

Now more than ever before, information is free-flowing and available. For advertising, it's all about harnessing the power of the consumer to give them better, more relevant content. With programmatic advertising on the rise and [more user data available](https://www.interana.com/blog/understanding-value-data/), working existing systems to their fullest potential with first-party data is the easiest way to get started bettering your advertising.


3 Key Strategies for Leveraging First-Party Data to Improve Your Ads

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.

Former Auth0 Employee

Ado Kukic

AWS re:Invent continues with day three and Andy Jassy, the CEO of AWS, delivered his annual keynote address. Here is our recap of the exciting announcements he shared.



Thank you for tuning back in to our TL;DR of the AWS re:Invent conference. Day three kicked off with a keynote by AWS CEO Andy Jassy where he announced a large number of new services that really go above and beyond, and cement AWS as the premier cloud platform for organizations large and small. I was also able to sneak into a couple of great talks and sessions after the keynote, but the highlight of the day was the keynote. Here's a TL;DR of all the announcements.

## Compute

### New EC2 Instances

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">New instances. M5 as predicted, H1 for <a href="https://twitter.com/hashtag/BigData?src=hash&amp;ref_src=twsrc%5Etfw">#BigData</a> and I3M bare metal hi io. <a href="https://twitter.com/hashtag/ReInvent?src=hash&amp;ref_src=twsrc%5Etfw">#ReInvent</a> <a href="https://twitter.com/hashtag/Live?src=hash&amp;ref_src=twsrc%5Etfw">#Live</a> <a href="https://twitter.com/hashtag/launch?src=hash&amp;ref_src=twsrc%5Etfw">#launch</a> <a href="https://t.co/2og9C1IfM9">pic.twitter.com/2og9C1IfM9</a></p>&mdash; Peter Joseph (@CloudyNetwork) <a href="https://twitter.com/CloudyNetwork/status/935908201035325440?ref_src=twsrc%5Etfw">November 29, 2017</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

AWS already has one of the broadest sets of compute offerings. Today, they announced three more elastic compute instances: **M5**, **H1**, and [**I3M**](https://aws.amazon.com/blogs/aws/new-amazon-ec2-bare-metal-instances-with-direct-access-to-hardware/), a bare metal offering for organizations wanting to have direct access to the hardware. In addition to the new instances, they also announced a new pricing model for their spot instances, which allows developers to use EC2 resources at reduced prices.

### ECS for Kubernetes

[Kubernetes](https://kubernetes.io/) is making some pretty large waves in the container orchestration space and until now it was very much a manual process to set up Kubernetes on AWS. That is about to change with [Amazon Elastic Container Service for Kubernetes](http://www.businesswire.com/news/home/20171129006075/en/AWS-Announces-New-Container-Capabilities%E2%80%94Amazon-Elastic-Container) or EKS which is launching in preview this week. Amazon EKS fully manages the availability and scalability of the Kubernetes control plane for each cluster and will allow organizations to easily run Kubernetes without having expert Kubernetes knowledge.

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Managed Kubernetes for AWS - The Elastic Container Service for Kubernetes (EKS) <a href="https://twitter.com/hashtag/reinvent?src=hash&amp;ref_src=twsrc%5Etfw">#reinvent</a> <a href="https://t.co/lqKpwoYjOK">pic.twitter.com/lqKpwoYjOK</a></p>&mdash; AWS re:Invent (@AWSreInvent) <a href="https://twitter.com/AWSreInvent/status/935909627224506368?ref_src=twsrc%5Etfw">November 29, 2017</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>


### AWS Fargate

What if you didn't want to manage container clusters at all? AWS may just have a solution for that as well. [AWS Fargate](https://aws.amazon.com/blogs/aws/aws-fargate/) is a service that they announced today that can deploy and manage containers for you so you don't have to manage any of the underlying architecture.

![AWS Fargate](https://images.ctfassets.net/23aumh6u8s0i/2tGG8qFC9PW2VgIQprffeu/127696ae3fbf08139e93c34cf2a651c4/fargate)

## Databases

I have a love/hate relationship with databases. They power the applications that I build and I actually have fun working with traditional relational database systems, especially PostgreSQL, but I hate setting up database servers. Andy had a few announcements in the database space that really got me excited for the future of database management—or should I say lack of management?

### Amazon Aurora Serverless

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Aurora Serverless &lt; <a href="https://twitter.com/ajassy?ref_src=twsrc%5Etfw">@ajassy</a> and <a href="https://twitter.com/awscloud?ref_src=twsrc%5Etfw">@awscloud</a> team is stealing my dreams and making them real<br><br>AMAZING NEW SERVICE/FEATURE<a href="https://twitter.com/hashtag/reinvent?src=hash&amp;ref_src=twsrc%5Etfw">#reinvent</a> <a href="https://t.co/MJFOOUOS2y">pic.twitter.com/MJFOOUOS2y</a></p>&mdash; Mark Nunnikhoven (@marknca) <a href="https://twitter.com/marknca/status/935913290676428802?ref_src=twsrc%5Etfw">November 29, 2017</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

We already have serverless functionality for our applications, why not our databases? That is the question Amazon is asking as well. [Aurora Serverless](https://aws.amazon.com/blogs/aws/in-the-works-amazon-aurora-serverless/) aims to bring the benefits of serverless computing to database management where you only get charged for the resources that you consume. This is perhaps the biggest announcement of Andy's keynote for me personally, and in my opinion, a real game-changer in the database management space.

### Amazon DynamoDB Global Tables

[DynamoDB](https://aws.amazon.com/blogs/aws/new-for-amazon-dynamodb-global-tables-and-on-demand-backup/) is Amazon's key/value database offering and it is a pretty impressive one at that. During Prime Day, DynamoDB served over 12.9 million requests per second bringing a whole new meaning to the term big data and web scale. Over 3.34 trillion requests were served for Prime Day in total. DynamoDB Global Tables provides a fully managed multi-region NoSQL database that allows you to provide localized reads and writes to your data wherever your users may be.

### Amazon Neptune

Graph databases have been growing in popularity recently and Amazon will have an official player in the game with [Amazon Neptune](http://www.businesswire.com/news/home/20171129006077/en/AWS-Announces-New-Capabilities-Amazon-Aurora-Amazon). The promise of this graph database is that it will be fast, reliable, and of course fully managed by AWS. Another big benefit of Neptune is the ability to use multiple graph query languages such as TinkerPop and SPARQL.

## Machine Learning

If "Big Data" was the buzzword that dominated our industry the last five years, "Machine Learning" will be the buzzword that dominates the next five. The promise of machine learning is that it will allow organizations the ability to provide much more personal and relevant experiences to each and every user. We're seeing machine learning used in everything from image recognition, recommendation engines, to healthcare. AWS had lots of announcements in this space.

### Amazon Rekognition Video

The [Amazon Rekognition](https://aws.amazon.com/rekognition/) service provides developers with an API to make sense of images. For example, you feed it an image and it will tell you what it sees, for example, correctly identifying humans and other objects. [Amazon Rekognition Video](https://aws.amazon.com/blogs/aws/launch-welcoming-amazon-rekognition-video-service/) does the same exact thing, but for video content. It will be able to track people, detect various activities, recognize various objects, celebrities, and even inappropriate objects. This can be done with existing video and even live streams, which opens up a wide array of potential use cases.

### Amazon Transcribe

[Amazon Transcribe](https://aws.amazon.com/blogs/aws/amazon-transcribe-scalable-and-accurate-automatic-speech-recognition/) will equip developers with automatic speech recognition (ASR), allowing them to easily add speech-to-text capability to their applications.

### Amazon Translate

With more and more apps reaching a global audience, having correct localized translations for various languages is a challenge that [Amazon Translate](https://aws.amazon.com/blogs/aws/introducing-amazon-translate-real-time-text-language-translation/) is hoping to tackle with its neural machine translation service. The service promises to allow developers to localize websites and applications for international users with ease.

### Amazon Comprehend

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Announcing Amazon Comprehend. A full managed natural language processing service. Extract entities, key phrases &amp; sentiment <a href="https://twitter.com/hashtag/reInvent?src=hash&amp;ref_src=twsrc%5Etfw">#reInvent</a> <a href="https://t.co/gZE4i7TUNM">pic.twitter.com/gZE4i7TUNM</a></p>&mdash; AWS re:Invent (@AWSreInvent) <a href="https://twitter.com/AWSreInvent/status/935933201888944130?ref_src=twsrc%5Etfw">November 29, 2017</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

[Amazon Comprehend](https://aws.amazon.com/blogs/aws/amazon-comprehend-continuously-trained-natural-language-processing/) is an interesting service that uses natural language processing and machine learning to find insights and relationships in text. Developers can use this API to extract places, people, brands, and events to get a better understanding of what is presented in the text. Analyzing large quantities of documents, developers will be able to extract key topics and meaning from their datasets.

### Amazon SageMaker

If you aren't looking to translate, transcribe, or understand your content, perhaps you want to do something else with it. [Amazon SageMaker](https://aws.amazon.com/blogs/aws/sagemaker/) is a fully managed service enabling data scientists to build, train, and deploy machine learning models for any dataset. SageMaker will work with a variety of different platforms such as [TenserFlow](https://www.tensorflow.org/), [MXNet](https://mxnet.incubator.apache.org/), and others. Through its managed capability, it will help data scientists make sense of their data faster and with greater accuracy.

![Amazon SageMaker](https://images.ctfassets.net/23aumh6u8s0i/2OiSpncfThoA5vfBUWiDIJ/847e1cacaa18aa3d9db6e7c008d6664d/sagemaker)

### AWS DeepLens

[AWS DeepLens](https://aws.amazon.com/blogs/aws/deeplens/) is a wireless video camera and development kit that allows developers to get a better understanding of machine learning concepts. DeepLens will be released next year and will come with various samples to help developers learn more about what's possible with machine learning and how to get started.

## IoT

IoT is another buzzword that has been around for a little while but seems ready to take the world by storm. AWS had many announcements that will make working with IoT a much more pleasant experience than before.

### AWS IoT 1-Click

[AWS IoT 1-Click](http://www.businesswire.com/news/home/20171129006079/en/AWS-Announces-Slew-New-IoT-Services-Brings) is a service that makes it easy to trigger [AWS Lambda](https://aws.amazon.com/lambda/) functions from devices. If you've used [Amazon Dash](https://www.amazon.com/Dash-Buttons/b?ie=UTF8&node=10667898011) buttons in the past, the concept is fairly similar, only applied to any IoT device.

### AWS IoT Analytics

[AWS IoT Analytics](https://aws.amazon.com/blogs/aws/launch-presenting-aws-iot-analytics/) will give developers greater insight into the data their IoT devices collect. This fully managed service will collect, process, enrich, and analyze IoT device data at scale.

### Amazon FreeRTOS

[Amazon FreeRTOS](https://aws.amazon.com/blogs/aws/announcing-amazon-freertos/) is an IoT operating system for low-power edge devices that is easy to program, deploy, secure, connect to, and maintain. It is available free of charge, is fully open source, and best of all, available to all today.

## Security, Identity, and Compliance

I was very excited to learn about what identity and security announcements Amazon was going to announce today, and I have to say, I did not leave disappointed. Cognito is becoming a fully fledged identity platform, but that's not all Andy had up his sleeve.

### Advanced Security Features for Amazon Cognito

Amazon announced a number of advanced security features for [Amazon Cognito](https://aws.amazon.com/cognito/) including multifactor authentication, breached password detection, and various anomaly detection features. All of these features launched in beta today. If you need these features in a production-ready capacity right now, we at Auth0 also provide [multifactor authentication](https://auth0.com/multifactor-authentication), [breached password detection](https://auth0.com/breached-passwords), and [anomaly detection](https://auth0.com/docs/anomaly-detection).

### Amazon GuardDuty

Keeping your servers secure is important. [Amazon GuardDuty](https://aws.amazon.com/blogs/aws/amazon-guardduty-continuous-security-monitoring-threat-detection/) aims to make security a little easier by providing a managed threat detection service that allows your DevOps team to continuously monitor and protect your AWS accounts and workloads. The best part? It can be enabled with a few simple toggles in the AWS management console.

That sums up the major announcements from today's keynote. I'm sure we missed a couple as they were coming at us one after another. Werner Vogels, CTO of AWS, will deliver his two-hour keynote tomorrow and we will be sure to cover all of the announcements that he makes as well. As for the sessions I attended today, two really stood out:

## Session: AWS Security State of the Union

Steve Schmidt, chief information security officer of AWS, delivered the AWS Security State of the Union talk. The key takeaway from his talk was his mechanisms to drive security in an organization, and they are:

* **Buy-in from leadership** - security cannot be an afterthought.
* **Radically restricting and monitoring human access to data** - humans and data don't mix, follow the principle of least privilege.
* **Source code security**.
* **Patching** - everybody hates doing it, but it must be done.
* **Log retention duration** - storage is fairly cheap; once deleted, logs are lost forever.
* **Credential blast radius detection** - use IAM roles properly to ensure that if credentials are leaked, damage will be minimal.
* **Credentials lifespan reduction** - no long-lived tokens and continuous rotation of credentials.
* **TLS implementation** - encrypt data in motion and at rest.
* **AWS encryption everywhere**.
* **Canaries and invariants for security functionality**.

At Auth0, we follow many of these principles to the T to ensure that we are delivering the most secure platform for our customers and users.

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">That’s a lot of 0’s... AWS <a href="https://twitter.com/hashtag/reInvent?src=hash&amp;ref_src=twsrc%5Etfw">#reInvent</a> Security State of The Union <a href="https://t.co/1PX9zuViS8">pic.twitter.com/1PX9zuViS8</a></p>&mdash; Teri Radichel (@TeriRadichel) <a href="https://twitter.com/TeriRadichel/status/935978817440530433?ref_src=twsrc%5Etfw">November 29, 2017</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>


## Session: Best Security Practices in the Intelligence Community

This breakout session included guest speakers from the US Intelligence Community, including Scott Kaplan, Deputy Chief of the NGA and John Nicely, Chief of Cloud Security for the US Government. They shared their lessons learned from moving their infrastructures from on-premise deployments to the cloud and how it allowed their organizations to respond quicker and with greater accuracy. This is definitely a talk I look forward to revisiting once it is posted online after AWS re:Invent 2017 concludes.

## Aside: Auth0 and AWS

If you are using AWS to manage your infrastructure, whether it be traditional, serverless, or a mix, and are looking to better manage identity in your applications, Auth0 can help you to:

* Add authentication through traditional username/password databases.
* Add support for linking different user accounts with the same user.
* Support for generating signed JSON Web Tokens to call your APIs and flow the user identity securely.
* Analytics of how, when, and where users are logging in.
* Pull data from other sources and add it to the user profile, through [JavaScript rules](https://docs.auth0.com/rules).
* Achieve [SSO (Single Sign-On)](https://auth0.com/docs/sso) seamlessly.

<a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up</a> for a free account today and enjoy fast, seamless, and hassle-free authentication in your apps.

## Summary

Day three of AWS re:Invent 2017 was very eventful. Andy's keynote has set the tone for the rest of the conference and that tone is "everything is everything." AWS wants to give you the best infrastructure to build and deploy your applications. Currently, the number of services offered by AWS is approaching 4,000! I can't wait to see what tomorrow has in store for us.

Previous recaps:

* [Day One](https://auth0.com/blog/aws-reinvent-day-1-recap/)
* [Day Two](https://auth0.com/blog/aws-reinvent-day-2-recap/)


AWS re:Invent Day 3 Recap

keith

Guest Author

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

1097492785caf9ffeebffeb624202d8f?s=200 avatar

1097492785caf9ffeebffeb624202d8f?s=200

Prosper is a great speaker, community leader, open source hacker, technical consultant, and a fervent Developer Advocate. He is a full-stack software engineer who has worked on biometric, health and developer tools. Prosper recently co-founded a startup called Eden that’s focused on improving the quality of lives in Nigeria and currently leads the engineering team. He also co-founded forloop, the largest developer community in Africa.

Prosper Otemuyiwa

Learn how to build and secure RESTful APIs with KeystoneJS

Developing Web Apps and RESTful APIs with KeystoneJS

Industry leaders join company to drive next stage of growth


**BELLEVUE, WA - OCTOBER 5, 2017** - Auth0, the global leader in Identity-as-a-Service (IDaaS), announced three additions to its executive team, further strengthening its core leadership. The recent expansion of the leadership team is in response to [Auth0’s rapidly accelerating growth in revenue, enterprise customers, and headcount.](https://auth0.com/blog/auth0-announces-record-year/)

The new executives are:

* **Joan Pepin, Chief Information Security Officer:** Joan is responsible for the holistic security and compliance of Auth0's platform, products, and corporate environment. She is a recognized thought leader in security and previously held positions as Business Information Security Officer at Nike and CISO at Sumo Logic, a leader in cloud-based log management and analytics.

* **Lewis Carpenter, Chief Marketing Officer:** Lewis oversees the company’s brand strategy and leads the team driving Auth0’s marketing efforts. He is the former CEO of Winshuttle, a leader in Application Data Management, and has helped build several market-leading technology companies.

* **Jeremy Freeland, General Counsel:** Jeremy is responsible for all legal affairs of the company. He has worked as inside and outside general counsel for several early and mid-stage information technology companies, and has significant experience with technology based transactions.

"Our tremendous success over the past year has been fueled by the amazing people who work at Auth0," said Eugenio Pace, CEO. “The addition of Joan, Lewis, and Jeremy provides us with deep expertise in each of their respective areas, and bolsters an already outstanding leadership team that will manage the next stage of growth for Auth0. We’re thrilled to have them on board for the journey.”

According to [Forrester Research](https://www.forrester.com/report/The+IAM+Market+Will+Surpass+13+Billion+By+2021/-/E-RES138932?objectid=RES138932 ), the identity and access management market is expected to surpass $13 billion by 2021. This growth is due to an ever-changing digital landscape and customer demand for secure and seamless authentication across all channels. Companies need an extensible and robust identity and access management platform more than ever and are turning to Auth0 to handle their most complex identity needs, quickly and securely.

<include src="asides/AboutAuth0" />

**Media Contact:**

Jeana Tahnk

Auth0

[jeana.tahnk@auth0.com](mailto:jeana.tahnk@auth0.com)


"key"