william_johnson

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

Developer Advocate

Will Johnson

jess-author

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

Sr. Developer Advocate

Jessica Temporal

Learn how to use Auth0 to secure a remote MCP server built with Cloudflare Workers to access a protected API.

**TL;DR** - Auth0 is collaborating with Cloudflare to make it easier for developers building remote MCP servers to configure authentication and authorization. Remote MCP servers will allow AI applications to access external services securely. This post details how to use Auth0 to secure a remote MCP server built with Cloudflare Workers to access an external service. It uses a sample Todo API as that external service.

## What are MCP Servers?

Developers are using large language models (LLMs) and AI applications to help build and deploy their code. Those applications are great when using data LLMs have already been trained on, but what if they could connect to external services to get even more information? That’s where the [Model Context Protocol (MCP)](https://auth0.com/blog/an-introduction-to-mcp-and-authorization/) comes in. MCP is a protocol that allows LLMs to connect with external tools and APIs in a standardized way. Using MCP, AI applications can connect with external services without knowing how each API works. MCP achieves this by using a client-server model.

* **MCP Client** &mdash; A client maintains the connection to MCP servers from inside of an LLM-based application.
* **MCP Server** &mdash; A server is always running and listening to be called by an MCP Client. 

Remote MCP servers are accessible on the Internet. Users sign in, and grant permissions to MCP clients using authorization flows with which they are already familiar. This opens up new use cases for users who may not want to run a MCP server locally on their machine, but are comfortable interacting with APIs and granting access online.

## Securing a Remote MCP Server with Auth0 and Cloudflare

Auth0 has collaborated with Cloudflare to help developers secure remote MCP servers powered by [Cloudflare Workers](https://developers.cloudflare.com/workers/). With the pace of MCP adoption rapidly increasing, Cloudflare has continued to keep up with innovation - [adding features to its platform](https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/) that handle the hard parts of building remote MCP servers, like `workers-oauth-provider`, an OAuth Provider that makes authorization easy. By [securing your MCP server with Auth0](https://auth0.com/blog/an-introduction-to-mcp-and-authorization/), AI applications can now interact with an external API by connecting through the remote MCP server and make API calls on behalf of an authenticated user.

In the rest of this blog post, we will walkthrough a practical example of this. We will set up and use an AI application to connect with a sample Todos API using an MCP server secured by Auth0. The server and API are Cloudflare Workers projects and will use Auth0 to request and receive access and refresh tokens.

![Diagram of request from MCP Client to a Todo API using Auth0 and Cloudflare](https://images.ctfassets.net/23aumh6u8s0i/1ycXxkqfevcl9XgqrtAL7E/b69b63cd6936a09343f7664229e07919/mcp-8.png)

We will first create the necessary accounts and set up the Todos API, then deploy and configure an MCP server that will connect to Auth0, and finally, the MCP Client can request information from the Todos API.

## Get Started

To follow along, you will want to set up your local developer environment. To get started:

* Create an [Auth0 Account](https://auth0.com/signup?place=header&type=button&text=sign%20up).
* Create a [Cloudflare Account](https://www.cloudflare.com/).
* Install Visual Studio Code (or your favorite code editor).

Once you create those accounts, you will want to 

* Install [Node.js](https://nodejs.org/en/download) (v18+).
* Install [Git](https://git-scm.com/downloads).
* Install the Cloudflare Wrangler CLI. [Read the documentation on installing Wrangler here](https://developers.cloudflare.com/workers/wrangler/install-and-update/).

### Get the Todo API and Remote Auth0 MCP server sample applications

The sample Todos API and remote MCP server are within the [Cloudflare AI monorepo](https://github.com/cloudflare/ai). Clone the repo, navigate to each application, and install the dependencies using the following commands in the terminal.

For the **Todos API**:

```
git clone https://github.com/cloudflare/ai.git
cd ai/demos/remote-mcp-auth0/todos-api
npm install
```

The TodosAPI is built with the [Hono web framework](https://hono.dev/),

For the **remote MCP** Server:

```
cd ../mcp-auth0-oidc
npm install
```

With both of the projects available locally and dependencies installed, proceed to the next step to secure the Todos API with Auth0.

### Configure the Todos API with Auth0

Let’s configure the Todos API to be secured by Auth0. Doing this will allow the remote MCP server to receive both access and refresh tokens and perform actions on behalf of the end user. To get started, [login to your Auth0 account](https://auth0.com/api/auth/login?redirectTo=dashboard) to visit the Auth0 Dashboard.

Create an API on the Auth0 Dashboard by going to [Applications > APIs](https://manage.auth0.com/#/apis/). Then click **Create API**.

![Create API modal in Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/klUW8q2EKjmE0CnTpaTU6/bb20af2cc6123644879ec38f09c51c73/Screenshot_2025-04-10_at_3.27.31_PM.png)

Next, enter the following values in the following fields:

* In the **Name** field, enter “Todos API”.
* In the** Identifier** field, enter `urn:todos-api`. This value will be used as the audience parameter when the MCP server makes an authorization call to the Todos API.
* Press the **Create** button

The next step is to allow a refresh token to be retrieved when requested by the remote MCP server. Go to [Applications > APIs](https://manage.auth0.com/#/apis/) and click on the entry for the Todos API. Visit **Settings**, scroll down to **Access Settings**, and toggle the **Allow Offline Access** button to enable it. Then click **Save**.

![Screenshot of API Access Settings in Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/6qoFrMXPUzyt5Z6SWK9o9w/517bf73eac7a9f701c984d18aec18fdf/Screenshot_2025-04-10_at_3.33.40_PM.png)

Toggling on the Allow Offline Access, allows a [refresh token](https://auth0.com/docs/secure/tokens/refresh-tokens) to be retrieved by the MCP server, so the user doesn’t have to keep re-authenticating when an access token expires.

As a final step - the permissions (scopes) need to be configured in the Auth0 Dashboard. These will be granted when a user authorizes an application to gain access to an API. In the API settings for the Todos API, go to the **Permissions** tab and add `read:todos` and `read:billing` as permissions, add a description, and press the **+ Add** button to effectively create the permissions.

![Screenshot of API Permissions tab on Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/4KSfabe2W5eQh5TuOF2cts/3ddf1ea4fd1eceadbff80d31ad5eed6c/Screenshot_2025-04-10_at_3.37.04_PM.png)

With the permissions in place, the Todos API is created and configured within Auth0. You need to give the Todos API the information from Auth0.

Open the Todos API project in your preferred code editor, set configuration values to connect it to the API you just created in the Auth0 Dashboard, and then deploy it via the Wrangler CLI.

In the root of the Todos API project, create a `.dev.vars` file. With the following format:

```
AUTH0_DOMAIN=
AUTH0_AUDIENCE=urn:todos-api
```

Note that you already have the `AUTH0_AUDIENCE` from when you created your API. Now, you’ll need to fill in the Auth0 Domain.

Whenever a new API is created in the Auth0 Dashboard, you also get a test application that allows you to get access tokens and make requests to your protected API. You can see the test application under [Applications>Applications](https://manage.auth0.com/#/applications).

Now that you are in the Applications section of the Dashboard click on the “*Todos API (Test Application)*”, which will load the settings and copy the **Domain** value. The domain will be used in the next step when we update the Todos API project. 

![Screenshot of Todo API application settings in the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/1tYPzi9JnFGx0UfzIIU2p9/ea37c64f67666bc254ea05e6aef3d352/Screenshot_2025-04-07_at_1.03.54_PM.png)

Update your `.dev.vars` file to contain the Domain like so:

```
AUTH0_DOMAIN=Your Auth0 domain (e.g., acme.auth0.com)
AUTH0_AUDIENCE=urn:todos-api
```

### Testing the Todos API

With the Todos API configured both in Auth0 and locally, you can make requests to it.

Run the Todos API with the following command:

```
npm run dev
```

This will start the worker and allow you to make requests to the Todos API. 

To get the `access_token` to call the API, on the Auth0 Dashboard go to **Applications > APIs, **click on the** Todos API **then select the **Test** tab. This will give you the cURL command to request the access token.

![Screenshot of Todos API Test Tab](https://images.ctfassets.net/23aumh6u8s0i/3aXJxxBRZP75mib0aGAJyS/22204edc710ede9ae7c7b4a706dbe2d8/Screenshot_2025-04-09_at_1.52.22_PM.png)

In your terminal, run the command from the **Test** tab, and be sure to use the `client_id` and `client_secret` values from Auth0.

```
curl --request POST \
 --url https://dev-aggvwbxi.us.auth0.com/oauth/token \
 --header 'content-type: application/json' \
 --data '{"client_id":".....","client_secret":".....","audience":"urn:todos-api","grant_type":"client_credentials"}'
```

The cURL command will show the response with the access token like below:

```
{
 "access_token": ".......",
 "token_type": "Bearer"
}
```

Next, make a request to the API passing the access token in the Authorization header.

```
curl --request GET \
 --url http://localhost:8788/api/me \
 --header 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6Im...'
```

On a successful call, you will see the claims of the JWT token in the response.

## Deploy the Todos API to Cloudflare

The Todos API is a Cloudflare Workers project, which means it can process Wrangler commands. With everything you have in place so far, you can use Wrangler to set secrets locally and deploy the API to Cloudflare. Using the terminal, navigate to your project folder and run the following commands:

```
wrangler secret put AUTH0_DOMAIN
wrangler secret put AUTH0_AUDIENCE
```

Now that the secrets are set, you can deploy the Todos API to Cloudflare with the following command:

```
wrangler deploy
```

Now that the Todos API is deployed to Cloudflare and secured by Auth0. Keep the project open as we’ll use the terminal in the next step to configure and deploy the remote MCP server.

## Configure and Deploy the Remote MCP Server

In this step, we will configure the remote MCP server secured with Auth0 and make requests to the Todos API. This includes creating an application for it in the Auth0 Dashboard and deploying it to Cloudflare.

Head back to the Auth0 Dashboard and create a web application by going to [Applications → Applications](https://manage.auth0.com/#/applications). Click **Create Application** and enter the following values:

* For the **Name** field, enter “Remote MCP Server”
* Choose **Regular Web Applications** as the Application Type
* Click the **Create** button

![Create Application Modal in Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/3HJs03fVbMD1dRZzGpcLGh/efa94e5434af3d0bc12dfd7565eae4fd/Screenshot_2025-04-07_at_1.53.58_PM.png)

Next, we will configure the callback URL, which is the URL to which the application will be redirected back to the caller after the user authenticates. To set this, head to the MCP Server application Settings, scroll to **Allowed Callback URLs** in the **Application URIs** section and add the following URL.

```
http://localhost:8788/callback
```

> *Note:* This URL will change when you deploy it to production. 

![Application URIs in application settings on Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/3VygdrL3LQBItkNhTVy7v7/fc558fd1a2492454302948c7c3d584e0/Screenshot_2025-04-10_at_4.10.52_PM.png)

Next up is creating a [Cloudflare Workers KV](https://developers.cloudflare.com/kv/) namespace. This namespace is used by the remote MCP server and `workers-oauth-provider` to handle authorization requests.

To create a **KV namespace** with Wrangler, in the terminal, run the following command:

```
wrangler kv namespace create "OAUTH_KV"
```

Open the Remote MCP Server project in your code editor and paste the resulting values in the existing `wrangler.jsonc` file using the format below:

```js
//wrangler.jsonc

{
 "kv_namespaces": [
 {
 "binding": "OAUTH_KV",
 "id": "<BINDING_ID>"
 }
 ]
}
```

Now that the KV namespace has been created, the next step is to update configuration values for Wrangler to deploy the remote MCP server to Cloudflare. To configure the application you’ll need a few values from your application settings in the Auth0 Dashboard. 

Go to [Applications → Applications](https://manage.auth0.com/#/applications), then click on the Remote MCP Server application. There, you can take note of your Auth0 Domain, Client ID, and Client Secret. 

![Auth0 application settings](https://images.ctfassets.net/23aumh6u8s0i/3HJs03fVbMD1dRZzGpcLGh/efa94e5434af3d0bc12dfd7565eae4fd/Screenshot_2025-04-07_at_1.53.58_PM.png)

With the project open in your preferred code editor, create a .dev.vars in the root of the project and add the following values:


```
AUTH0_DOMAIN=Your Auth0 domain (e.g., acme.auth0.com)
AUTH0_CLIENT_ID=The Client ID of the application created in Auth0
AUTH0_CLIENT_SECRET=The Client Secret of the application created in Auth0
AUTH0_AUDIENCE=urn:todos-api
AUTH0_SCOPE=openid email profile offline_access read:todos
NODE_ENV=development
API_BASE_URL=http://localhost:8789
```

### Deploy the MCP Server to Cloudflare

To deploy the remote MCP server to Cloudflare, you first need to set the secrets in Wrangler. To do this, run the following commands:

```
wrangler secret put AUTH0_DOMAIN
wrangler secret put AUTH0_CLIENT_ID
wrangler secret put AUTH0_CLIENT_SECRET
wrangler secret put AUTH0_AUDIENCE
wrangler secret put AUTH0_SCOPE
wrangler secret put API_BASE_URL
```

Once the secrets are set, run the following commands to deploy the MCP Server to Cloudflare.

```
wrangler deploy
```

With the MCP server deployed, we can update the **Allowed Callback URLs** in the Application settings within the Auth0 Dashboard using the deployed MCP server URL using this URL pattern.

To change the Allowed Callback URLs, on the Auth0 Dashboard go to **Applications > Applications**, click on **Settings**, scroll down to **Application URIs** and then add the following URL.

```
https://mcp-auth0-oidc.<your-subdomain>.workers.dev/callback
```

![Auth0 Application URI settings](https://images.ctfassets.net/23aumh6u8s0i/69X5vC9Cna1nKKvicpWTp6/79de976d5939062bc416d46037c550f6/app-urls-callback.png)

This will make sure that after the user authenticates, they will redirect back to the remote MCP server to make calls to the Todos API. With these steps in place, it’s now time to see the remote MCP server in action.

### Test the Remote MCP Server Call

To test making calls to the Todos API, use the Workers AI LLM Playground. Navigate to [Cloudflare’s AI Playground](https://playground.ai.cloudflare.com/) and connect to the Remote MCP Server URL:

```
https://mcp-auth0-oidc.<your-subdomain>.workers.dev/sse
```

Place the URL in the section labeled MCP Servers and click **Connect**.

![Cloudflare AI workers playground](https://images.ctfassets.net/23aumh6u8s0i/1Jwt30QY8vuTTO3ZMNTZXr/5757f0dc6a99600d8ab404eca3f97061/Screenshot_2025-04-10_at_12.33.42_PM.png)

Then you’ll go through the authorization flow; you need to allow access:

![MCP server access request](https://images.ctfassets.net/23aumh6u8s0i/57yVFkdC5sEhBIXEICo9jo/00327fda1167ae4b61f6d64582f78934/auth-request.png)

This will open the browser, have the user authenticate with Auth0, and allow the remote MCP server to access the resources of the Todos API. 

![Auth0 universal login](https://images.ctfassets.net/23aumh6u8s0i/MJX7hQveJh6BYaMKmIHDn/3ef06aa1a2a047c649278d9a0ee37de9/auth-ul.png)

Once permission is given, you can use the LLM to make requests to the MCP server to get information from the Todos API.

![cloudflare AI playground](https://images.ctfassets.net/23aumh6u8s0i/1sO7ZqO9aF7o0VzYEex9VZ/2aa6f63cf1bd01862dde09a0efdfe221/playground.png)

The Todos API allows requests for todos and billing information. Note that the billing information request will fail to show that the LLM can only make requests for information that it has permissions for.

## Configuring a Remote MCP Server in Claude

Now that you understand how to secure a remote MCP server with Auth0 and know how to deploy it to Cloudflare, it might be good to see how to set it up to your favourite MCP Host. Let’s set up your server in Claude Desktop.

Open Claude Desktop, navigate to the Settings then click on Developer and Edit Config. This will show you Claude’s folder on your computer and the file named `claude_desktop_config.json`.

![Claude Desktop Config JSON file](https://images.ctfassets.net/23aumh6u8s0i/4JAy6wjNRtCEVaLIUSJxDv/ebab95cd543009cac72cf1a22fb90e1e/claude-desktop-config-in-folder.png)

Open that file in your favorite editor, and add the following:

```json
{
 "mcpServers": {
 "math": {
 "command": "npx",
 "args": [
 "mcp-remote",
 "https://mcp-auth0-oidc.<your-subdomain>.workers.dev/sse"
 ]
 }
 }
}
```

Remember to update the URL to use your Remote MCP Server URL in the arguments list. This configuration names a “`math`” server that runs with `npx` as command and passes the package `mcp-remote` and the URL as parameters to `npx`.

[The `mcp-remote` package](https://www.npmjs.com/package/mcp-remote) is responsible for connecting an MCP Host with `stdio` like Claude Desktop and Cursor to securely access a Remote MCP Server like the one you just deployed.

Once you save the configuration and restart Claude, you’ll be able to prompt Claude about your list of todos:

![Claude using the Remote MCP Server to show the todos list](https://images.ctfassets.net/23aumh6u8s0i/7HE3fATATP2E1Mxr69V11J/84d1c2267567d095f4b9b5cf5a1bbadb/claude-todos-list-mcp-server-and-api.png)

## Conclusion

In this post we walked through the steps needed to secure a MCP Server with Auth0, and connect it to a third party API. You also learned how to deploy your MCP Server to Cloudflare. The MCP server uses Auth0 as a third party identity provider and allows AI tools to call the protected API on behalf of the user.

Remote MCP Servers offer tools that can make LLMs more convenient and give faster access to the information that matters to users. If you are building with GenAI you should check out our brand new product [Auth for GenAI](http://a0.to/ai-content), to enable AI agents to securely access tools, workflows, and data with fine-grained control and just a few lines of code.

You can take a look at the code that was used in these demos [on GitHub](https://github.com/cloudflare/ai/tree/main/demos/remote-mcp-auth0) to try it out for yourself.


---

_This blog may contain hyperlinks to non-Okta websites that are created and maintained by third parties who are solely responsible for the content on such websites._

Secure and Deploy Remote MCP Servers with Auth0 and Cloudflare

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

Deploy a cloud-native Java Spring Boot microservice stack secured with Auth0 on Google GKE using Terraform and Kubernetes.

Deploy Secure Spring Boot Microservices on Google GKE Using Terraform and Kubernetes

Nesh Popovic

As a Developer and Solutions Engineer for the past 20+ years, I've been involved in developing and selling secure and robust software solutions. When not helping my sales team deal with the complexities of software platforms, you can usually find me playing pickleball, basketball or backgammon.

Principal Solutions Engineer - CIAM

Learn how to set up an Amazon API Gateway and secure the REST API with Okta Customer Identity Cloud (CIC) Adaptive MFA Risk Score

Protecting REST APIs Behind Amazon API Gateway Using Okta

Deploy a cloud-native Java Spring Boot microservice stack secured with Auth0 on Azure AKS using Terraform and Kubernetes.

Deploy Secure Spring Boot Microservices on Azure AKS Using Terraform and Kubernetes

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

Product Manager

Andrés Aguiar

Now, you can deploy Auth0 FGA in several AWS regions with high availability and requests per second.

We are thrilled to announce that [Okta Fine Grained Authorization](https://fga.dev/) (FGA) is now available as an AWS private cloud deployment option.

Authorization is where Authentication was a decade ago. We aim to simplify Authorization for developers, just as we did with Authentication. In early March, we made significant progress toward this goal by [launching Okta Fine Grained Authorization](https://www.okta.com/blog/2024/03/setting-the-bar-for-authz-okta-fine-grained-authorization-is-now-generally-available/). Auth0 FGA is an authorization service that enables developers to implement centralized, flexible, scalable, and easy-to-use authorization.

Auth0 FGA has two deployment options: public cloud and private cloud. The public cloud option is a multi-tenant SaaS service available in three geographies: the United States, Europe, and Australia, offering a highly available multi-region deployment. The private cloud option, on the other hand, is tailored for enterprises seeking dedicated resources. Auth0 FGA Private Cloud [leverages the same architecture principles](https://auth0.com/blog/securing-auth0s-new-private-cloud-platform/) that have been battle-tested with Auth0 for over two years.

**Benefits of Running Auth0 FGA in Private Cloud**

* **Higher RPS**: Private cloud instances are optimized for high request-per-second (RPS) performance, scaling up to five times the average RPS based on your application’s needs. 
* **Data Residency and Compliance**: Deploy your Private Cloud environment in any AWS region to help meet specific data residency and compliance requirements. Initial regions include the US, Germany, Ireland, the UK, France, Japan, India, Singapore, Australia, and Brazil.
* **Reduced Latency**: Choose the AWS region closest to your application servers, which will significantly reduce latency for faster access control checks.
* **Multi-Geography Deployments:** Businesses can replicate the same authorization data across multiple regions worldwide, allowing them to maintain low-latency authorization services even for globally distributed applications. For example, a company can have the same data in the US, EU, and Australia, have their authorization data replicated across all regions, and have their applications routed to the closest region.
* **Automated, Hardened Release:** Benefit from automated weekly releases that are previously validated in Okta’s public cloud deployments.
* **Centralized Management:** Manage both private and public cloud instances seamlessly from the Auth0 FGA dashboard.

The availability of Auth0 FGA in Private Cloud on AWS marks another significant milestone in our vision of running Auth0 FGA across all major cloud providers and regions. Stay tuned for further updates, and [Contact Us](https://auth0.com/contact-us?place=header&type=button&text=contact%20sales) to learn more.

Auth0 Fine Grained Authorization is now Available in Private Cloud on AWS

matt-raible

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

Matt Raible

This tutorial shows you how to build a microservices architecture with Spring Boot and Spring Cloud.

Java Microservices with Spring Boot and Spring Cloud

pawan bhardwaj

Pawan is a seasoned business and technology enthusiast who welcomes challenges and pushes boundaries for value creation. In addition to his passion for technology, he also enjoys learning about music, art, architecture, and philosophy as lifelong pursuits.

In his career, he has worked in the domains of product management, solutions architecture, cybersecurity, cloud, telecom, and software engineering. He has led SaaS scaling initiatives in Cybersecurity (IAM), portfolio evolutions to cloud and telecom APIs, and deep partner engagements.

He has an MBA from Sonoma State University and an MS from the University of Delhi.

Principal Product Manager

Pawan Bhardwaj

jc tierney

JC Tierney was born and raised in the suburbs of Chicago, and is a life-long Blackhawks, White Sox and Bears fan.

He graduated from Benet Academy in Lisle, Illinois. He went on to attend the University of Dayton, where he graduated with a degree in Management Information Systems, and loved every minute of the experience.

Director, Engineering

JC Tierney

Efficiency on a robust foundation: Exploring multi-subscriber (Public Cloud) deployment on Auth0's converged platform architecture.

**TL;DR:** Auth0’s SaaS services are available via two modes of cloud deployment:

* Multi-subscriber (shared infrastructure, a.k.a. Public Cloud) 
* Single subscriber (dedicated infrastructure, a.k.a. Private Cloud). 

These offerings now have a converged platform architecture that increases business agility, developer productivity, scalability, reliability, and security by using industry-leading tools and fully automated operations.

This article continues a series of earlier ones focused on Private Cloud deployments. Unlike the single-subscriber Private Cloud, the Public Cloud hosts thousands of subscribers. In multi-subscriber deployments, data isolation, security, and elimination of noisy neighbor problems are paramount.

Public Cloud leverages the converged architecture composed of three tiers - the Central tier, Points of Presence (PoPs), and Spaces. The Central tier and PoPs are for control, operations, and shared services. Spaces are environments that provide customer identity services as per customers’ needs.

We leverage Kubernetes for lifecycle and runtime management of Auth0’s cloud-native containerized solution. Auth0 is composed of stateless services that are easier to scale. We use MongoDB, PostgreSQL, and Redis as required by the situation. We ensure a robust and performant solution through network isolation and extensive use of edge networks for DDoS protection, rate limiting, and low-latency DNS resolution (including custom domains). The converged architecture's intra-region High Availability (HA) and inter-region geo-failover characteristics help us meet the availability SLAs of Public Cloud deployments.

## Auth0 Services on Multi-Subscriber (Public Cloud) and Single-Subscriber (Private Cloud) Deployments

Auth0 is a Software-as-a-Service (SaaS) solution with two deployment models - Public Cloud and Private Cloud. The Public Cloud is a multi-subscriber environment where resources are shared between customers and is available in the United States, Europe, Australia, Japan, and now in the United Kingdom. Private Cloud deployments, on the other hand, are single-subscriber environments that provide customers with dedicated infrastructure and can be deployed in most regions across Amazon Web Services (AWS) and Microsoft Azure.

The Public Cloud offering is deployed on AWS and addresses the needs of a vast majority of customers. However, customers may choose Private Cloud for a variety of reasons, such as: 

* Geographical requirements that dictate deploying in an area not served by Public Cloud (e.g. for data residency and/or latency reduction)
* Industry-specific needs (e.g., PCI compliance)
* Preference for Microsoft Azure instead of AWS
* Higher transaction volume than allowed on Public Cloud

![Auth0 Services on Multi-Subscriber (Public Cloud)](https://images.ctfassets.net/23aumh6u8s0i/6ex2w8DgyfbKhdJLx1lIPi/60a5ba0c641c9059317da35e9f6aab1c/multi-subscriber-public-cloud-01.png)

## Why Converged Architecture?

The converged architecture allows us to deploy and manage both Public and Private Cloud offerings on the same underpinning. This architecture is built on the following premises:

* Multi-cloud: AWS and Azure cloud support through a common interface
* Container orchestrated: use of container images instead of installing packages
* Stateless: scalable and replaceable by design
* Immutable: run only trusted code and configuration
* Fully automated: provisioning, upgrades, and decommissioning are done by machines
* GitOps: enhanced DevOps, push code and safely reproduce it thousands of times

![Architecture](https://images.ctfassets.net/23aumh6u8s0i/57nIODdJEv5clLYYswHEl5/12fabdd26c7eddf4db40754196ef1659/multi-subscriber-public-cloud-02.png)

The benefits of a single underlying architecture for developing, deploying, and operating services across different environments are manifold. The primary reason is the ability to offer new capabilities to customers faster and at a lower expense. The architecture also allows us to ensure feature parity across different deployment environments seamlessly.

The converged architecture helps in focusing the organization’s energy on a common infrastructure that yields higher developer productivity/velocity. It results in improved platform scalability to address various scaling demands from both multi-subscriber and single-subscriber deployments. It provides a constructive space for assessment and adoption of security practices that might be perceived as unique to one deployment environment type, but have practical implications on the other as well. It also helps with reliability refinements and enhancements across the board. 

Besides optimizing engineering resources, a converged architecture has several other internal benefits through unified automation, toolsets, and processes. It has expedited identification and realization of infrastructure and operational cost optimizations across the board, which helps deliver good value to our customers.

## Deployment Characteristics of Multi-Subscriber Services 

As a reminder, the Public Cloud is designed to host thousands of subscribers over shared resources, whereas a Private Cloud deployment is designed for a single subscriber. 

Ensuring optimal performance and security for the different Public Cloud subscribers is paramount. While the underlying compute, storage, database, networking, domain name, and other resources are shared in a multi-subscriber deployment, this solution ensures each subscriber is isolated within this shared environment.

The database and application workloads are partitioned to ensure an appropriate level of data isolation and security. The Auth0 Public Cloud combines pooled partitioning (i.e., partitioning of data by subscriber identifier) and on-demand subscriber-specific workload instances. The architecture is refined continuously to eliminate “noisy neighbor” problems.

## Public Cloud Platform Infrastructure Architecture

### Tiers - Central, PoPs, and Spaces

Once again, the converged architecture has three tiers - Central, Points of Presence (PoPs), and Spaces. Besides these, the Edge network for DNS and DDoS protection, and Auth0 HQ based systems for analytics and operations complete the picture.

![Tiers - Central, PoPs, and Spaces](https://images.ctfassets.net/23aumh6u8s0i/5wVpjNsZNeyRnxGmRIHLwM/deee78839a615f2ebc1679b65eafc873/multi-subscriber-public-cloud-03.jpg)

It’s important to note that the solution has been designed with isolated fault domains; the control plane and data plane separation allows the central control plane to be offline/under maintenance without impacting customers’ authentication flows.

* **Central**: A globally unique component that contains the platform control plane and other centralized global infrastructure. The control plane manages the creation of Public Cloud environments and keeps them updated with continuous (daily) releases.
* **PoPs**: An intermediate point of infrastructure pinned to a specific cloud region (e.g., AWS us-east-1). The PoP hosts internal visibility tools and securely proxies messages from the central down to the regional Public Cloud environments.
* **Space**: The Public Cloud environment is located ‘beneath’ a PoP in a particular AWS region. These spaces have cross-region geo-failover capabilities to ensure resiliency.

### Aspects - control and runtime, scalability, datastores, networking, and reliability

When Auth0 took on the converged platform project, it started as a small team, initially focused on our single-subscriber (Private Cloud) offerings. This team comprised a cross-section of our platform teams with expertise ranging from Kubernetes to API, tooling, infrastructure, and datastores. They were focused on developing a proof of concept for the converged platform.

As we learned from our experiments — and as the converged platform evolved and matured — we launched single-subscriber environments for general availability. You may read more about this in a series of posts we shared outlining the technical, security, and architectural decisions we made:

* [A Technical Primer of Auth0’s New Private Cloud Platform](https://auth0.com/blog/a-technical-primer-of-auth0-s-new-private-cloud-platform/)
* [The Architect’s View of Auth0’s New Private Cloud Platform](https://auth0.com/blog/the-architect-s-view-of-auth0-s-new-private-cloud-platform/)
* [Securing Auth0's New Private Cloud Platform](https://auth0.com/blog/securing-auth0s-new-private-cloud-platform/)
* [Data Pipelines on Auth0’s New Private Cloud Platform](https://auth0.com/blog/data-pipelines-on-auth0-s-new-private-cloud-platform/)
* [How We Do Releases in Auth0’s New Private Platform](https://auth0.com/blog/how-we-do-releases-in-auth0-s-new-private-platform/)
* [Optimizing Cost and Performance of Auth0's Private Cloud](https://auth0.com/blog/optimizing-cost-and-performance-of-auth0s-private-cloud/)

We continued the logical progression with the converged platform, and adopted it for Public Cloud. Behind the scenes, the team continued to grow, and eventually, as we began to gain more and more traction from the converged platform, we organized the team into specialties to best support growth.

* **Runtime -** Heavily focused on our Terraform and Kubernetes layers. Ensuring that the core of the platform functions and that automation has the flexibility to meet the needs of product delivery teams.
* **Control -** Owners of our controlling API and platform CLI. The tooling that is used for operating the platform in all cases both normal and incidents.
* **Datastores -** Focused on our data storage technologies and interacting with our product delivery teams and the most efficient way to utilize the available stores.
* **Networking -** Owners of our edge technologies and supporting the myriad of ways in which our customers leverage the edge.
* **Sizing -** Partners with other internal teams to establish the performance characteristics of our offerings and additionally adds improvements to our platform including auto-scaling.
* **Services -** Owners of tooling and services leveraged by product delivery in their development. This includes abstractions that allow for easier access to the underlying platform.
* **Data -** Responsible for ensuring the data flow from the individual environments to the regional Points of Presence (PoPs) and beyond. This includes application logs for support as well as abstracted metrics. 

In order to get the technology behind a solution right, it's critical to fully enable the people behind the technology to co-create innovative solutions. At Okta, we cultivate a BLOC culture, which stands for “Builder, Learner, Owner, and Collaborator.” These values foster a high-functioning, well-oiled machinery that can take on big and small challenges effectively and efficiently.

![BLOC culture](https://images.ctfassets.net/23aumh6u8s0i/1uDGWPkHZzzH5CKHlrvEbJ/114d89fab2474e4cb2aec9272dea795f/multi-subscriber-public-cloud-04.png)

With the different team specializations, collaboration becomes all the more important. At Auth0, we value documentation not only for informing but also for decision-making. Our Engineering teams follow a simple mantra for collaboration: "Write. It. Down." We use Request For Comment (RFC) documents to record architectural designs and Decision Record documents to discuss and align ideas across teams. These documents also provide important context for new team members about what we're building and how we arrived at the decisions we've made and served as an important knowledge base as we began onboarding service owners to the new converged platform. These core tenets have become critical for sustaining the growth of the platform and introducing new capabilities over time.

### Reliability

The converged architecture provides a highly reliable and available solution leveraging not only the High Availability (HA) constructs across three Availability Zones within an AWS region, but also geo-failover capability between Active and Failover regions.

![Reliability](https://images.ctfassets.net/23aumh6u8s0i/2jbDdi3fCuZ1hm6D0qyWCI/ffe5decea1a0c72156636d38073d1975/multi-subscriber-public-cloud-05.png)

The geo-failover regions are always synchronized from the datastores’ perspective, with demanding RPO/RTO and 99.99% availability SLA targets. Once the failover decision is made, a fully automated process is initiated for the failover to take effect.

![Reliability](https://images.ctfassets.net/23aumh6u8s0i/5HQ6xBqVyquDFEK7ewW4kC/299cf5878d8cee63c706c633cc0b1abf/multi-subscriber-public-cloud-06.jpg)

In the event of a multi-region failure (an extremely rare event), we can perform an automated restore from the last backup.

The historical availability metrics are a testament to the robustness of the Auth0 solution. We continue to meet our targets in Private Cloud with the converged architecture and expect to continue meeting or exceeding these targets with Public Cloud deployments on this architecture.

![Private Cloud](https://images.ctfassets.net/23aumh6u8s0i/3xjskcZcaHUYxFuePah6r4/fdd40e7755462d852c29d16293a3bc2e/multi-subscriber-public-cloud-07.png)

## What Next?

Auth0’s Public Cloud offering continues to be boosted across different facets. The availability of Public Cloud across geographies will continue to expand. The launch of the UK Public Cloud region in April 2023 is the latest example, providing yet another regional point of presence for customers with data residency and latency sensitivity needs. Also, support for a Public Performance tier in H2 2023 caters to customers’ higher performance needs on Public Cloud.


We look forward to continuing to deliver new and enhanced customer identity capabilities, ease of use, platform resilience, scalability, and security in our Private Cloud and Public Cloud offerings through the new converged architecture.

Multi-Subscriber (Public Cloud) Deployment on Converged Architecture

deepu-sasidharan

Deepu is a polyglot developer, Java Champion, and OSS aficionado. He mainly works with Java, JS, Rust, and Golang. He co-leads JHipster and created the JDL Studio and KDash. He's a Staff Developer Advocate at Okta. He is also an international speaker and a published author.

Staff Developer Advocate

Deepu K Sasidharan

Deploy a cloud-native Java Spring Boot microservice stack secured with Auth0 on Amazon EKS using Terraform and Kubernetes.

Deploy Secure Spring Boot Microservices on Amazon EKS Using Terraform and Kubernetes

Storing secrets in your code is a bad idea. Learn how to use Spring Cloud Config and HashiCorp Vault to make your app more secure.

Secure Secrets with Spring Cloud Config and Vault

Join us at KubeCon + CloudNativeCon Europe on April 17th, 2023, for the official launch of OpenFGA v1.0

We’ve been talking to hundreds of developers who consistently tell us that they want to change how authorization is implemented in their applications. Authorization logic is embedded in the code and implemented differently in each service. It’s not flexible enough to define complex policies or finer-grained authorization. They struggle with load at scale. The existing RBAC/ABAC solutions can’t handle this complexity. That’s why we built OpenFGA.

We are thrilled to announce the release of [OpenFGA](https://openfga.dev) v1.0, a modern, flexible authorization system inspired by [Google's Zanzibar](https://zanzibar.academy). OpenFGA, designed for reliability and low latency at scale, has been embraced by the developer community since its open-sourcing in June 2022. As a Cloud Native Computing Foundation (CNCF) Sandbox Project, OpenFGA is having a significant impact in the world of authorization.

## OpenFGA v1.0: A Host of Enhancements

OpenFGA v1.0 brings a wealth of improvements since it was open sourced, raising the bar for authorization systems and providing developers with the tools they need to create secure, scalable applications. Here's a rundown of the new features:

1. Enhanced Authorization Model Language: OpenFGA v1.0 offers a [significantly improved](https://openfga.dev/docs/modeling/migrating/migrating-schema-1-1) language for defining authorization models, making them easier to read and author.
2. ListObjects API: This [new API](https://openfga.dev/docs/interacting/relationship-queries#listobjects) lets you retrieve all resources that a user can access based on the defined authorization policies, greatly simplifying auditing and access controls.
3. Elevated Observability: OpenFGA v1.0 takes [observability to new heights](https://openfga.dev/docs/getting-started/setup-openfga/docker#telemetry) with Open Telemetry tracing, Prometheus metrics, and prof profiles, providing insights into your authorization system's performance.
4. Effortless Deployment: Deploying OpenFGA to Kubernetes has never been easier, thanks to [official Helm chart](https://artifacthub.io/packages/helm/openfga/openfga) support. Get your Kubernetes cluster provisioned with just one command.
5. Postgres Storage Adapter Performance Boost: OpenFGA v1.0's Postgres storage adapter is supercharged, ensuring rapid performance and seamless scalability.
6. New Python SDK: A brand-new [Python SDK](https://pypi.org/project/openfga-sdk/) makes it even more convenient for Python developers to integrate OpenFGA into their projects.
7. Batching support in SDKs: OpenFGA v1.0's enhanced SDKs support batching queries, providing greater efficiency when making authorization requests, available for [JavaScript](https://github.com/openfga/js-sdk#batch-check) and [.NET](https://github.com/openfga/dotnet-sdk), [Go](https://github.com/openfga/go-sdk) coming pretty soon!

## Experience OpenFGA v1.0 at KubeCon + CloudNativeCon Europe, April 17, 2023

Mark your calendars and join us at KubeCon + CloudNativeCon Europe for the official launch of OpenFGA v1.0. Be among the first to discover the future of authorization systems and learn how OpenFGA can transform your cloud deployments and bolster your application security.

You’ll be able to connect with the OpenFGA team in different ways:

* Find us at Kiosk #27 in the Project Pavilion in the afternoons.
* Join the [OpenFGA project meeting](https://kccnceu2023.sched.com/event/1JWSb) on April 18, 9:30 AM CST in Room D406, Congress Center
* Participate in the Cloud Native Authorization Birds of a Feather meeting on April 21st from 11 AM - 12:30 PM CST. You can register [here](https://kccnceu2023.sched.com/event/1KW9e).

## Join us!

An open-source project is only as good as its community, so we are extending a warm welcome to everyone who wants to get involved. 

The project already has more than 30 contributors from multiple companies, and it’s being deployed in production by many of them.

The community has contributed a [MySQL Storage Adapter](https://github.com/openfga/openfga/pull/210), SDKs for [ASP.NET Core](https://github.com/Hawxy/Fga.Net), [Elixir](https://github.com/msutkowski/fga-elixir-sdk),  [Kotlin](https://github.com/Ozee-io/fga-kotlin-sdk) and integrations with [Quarkus](https://github.com/quarkiverse/quarkus-zanzibar), [Open Policy Agent](https://github.com/thomasdarimont/custom-opa-openfga), [Keycloak](https://github.com/embesozzi/keycloak-openfga-workshop), [Kratos](https://github.com/tx7do/kratos-authz) and [SCIM](https://github.com/SUSE-Skyscraper/openfga-scim-bridge).

You can help by simply trying the product, providing feedback, and engaging with other OpenFGA users in [Discord](https://discord.gg/6xzMMuU8YR) / [Github Discussions](https://github.com/orgs/openfga/discussions), attending our [monthly meetings](https://github.com/openfga/community/blob/main/community-meetings.md), or [contributing](https://github.com/openfga/.github/blob/main/CONTRIBUTING.md) to the project.

Find out more by checking out the Github repository [https://github.com/openfga/openfga](https://github.com/openfga/openfga), and learn how to use it in our [documentation](http://openfga.dev). Keep up to date with the latest news by following us on [Twitter](https://twitter.com/openfga).


Announcing OpenFGA v1.0: A New Milestone in Cloud Native Authorization Systems

johnathan-campos

Johnathan Campos is a Senior Product Marketing Manager at Okta focused on platform infrastructure and scalability. Johnathan is responsible for helping customers and partners understand the value of the Okta platform. Prior to joining Okta, Johnathan was a Senior Product Marketing Manager of the Observability Practitioner team at Splunk. During his time at Splunk, he helped practitioners understand the details of why Observability is the new necessary for native cloud deployments. When not focused on platform infrastructure and scalability, John enjoys tinkering in his garage, learning new things, spending time with family, and is an avid motorcycle fan.

Senior Product Marketing Manager, Global Platform Service

Johnathan Campos

With our new UK Region, we can enable local subscribers to achieve compliance and benefit from the quickest login response times available.

**TL DR;** The UK joins our available public cloud regions across EMEA to help with compliance requirements, data residency, and performance for our subscribers based in the UK.

We are thrilled to announce the launch of our newest region across our Customer Identity Cloud (Powered by Auth0) service in the UK. This new offering will provide a high-performance and secure way to manage customer identities while helping subscribers comply with UK data privacy regulations. As our first public cloud region on our converged platform architecture, this brings the latest cloud-native design and employs cutting-edge tools and fully automated operations to enhance business agility, developer productivity, scalability, reliability, and security for both our subscribers and platform teams. We encourage you to check out our blog series [here](https://auth0.com/blog/a-technical-primer-of-auth0-s-new-private-cloud-platform/) to learn more about our converged platform, and if you want to double-click even further on architecture, check out this blog [here](https://auth0.com/blog/the-architect-s-view-of-auth0-s-new-private-cloud-platform/) by my colleague, Leonardo Zanivan.

This public cloud region is also a major milestone in supporting UK customers with data residency needs. UK-based data centers will enable subscribers to store their data within the UK, helping ensure compliance with UK regulations for those that need it. This is particularly important for businesses that operate in heavily regulated industries, such as finance or healthcare, where data residency requirements can often be strict. To choose their preferred location, subscribers can easily select from a menu when creating their new tenant where the UK is now available. 

![UK](https://images.ctfassets.net/23aumh6u8s0i/7oWDzK3Dj7HVHwHlQ8XuoV/4f01fd4cb8bdaa926b07ab83c9009419/UK.png)

In today's constantly connected environment, where numerous users - from staff to customers - need access to mobile applications, websites, APIs, and portals from any location and device, we are proud to provide our subscribers with an IDaaS solution that delivers the essential scalability, reliability, and accessibility organizations require. Our goal has always been to simplify identity management for developers and IT professionals worldwide. 

With the new launch, users in and around the UK can experience reduced latency while logging in and solve many challenges faced with data privacy regulations. Don't hesitate to contact us for any questions or help regarding the newly launched UK Region. We are always here to help!

The UK Joins Existing EMEA Regions for Public Cloud Deployments!

bernardo

Bernardo is an Engineering Manager at Auth0 focusing on improving its Performance and Resilience posture. He is a technical leader who is passionate about building quality software that is scalable and resilient to failure, so we can meet the rising expectations of our customers.

Engineering Manager (Performance and Resilience Testing)

Bernardo Guerreiro

How Auth0 uses Performance Engineering to balance infrastructure cost and performance.

Auth0 is providing a world-class service empowering the critical path of millions of logins around the world, so it’s important that we ensure our services are performing well while keeping our infrastructure efficient. The Performance and Resilience Testing team was established in late 2021, as Auth0 made a lot of improvements in its resilience posture. Together with Platform and Product teams, we work toward upholding that performance, reliability, and resilience posture that is such an important pillar of Auth0. 

During 2022, the [development of Auth0’s new Kubernetes-based platform ramped up](https://auth0.com/blog/the-architect-s-view-of-auth0-s-new-private-cloud-platform/), which allows for a more repeatable and automated deployment of public and private cloud environments. Since then, our team began a natural partnership with the Platform teams and started working on defining the Private Cloud offerings for our customers. 

One of our key responsibilities has been to define performance tiers for private cloud customers based on different RPS (requests per second) thresholds - 100 RPS, 500 RPS, and 1500 RPS (with more to come). This initiative, called Tier Right-Sizing, is essential to ensuring Auth0 is able to provide our customers with offerings whose infrastructure costs are efficient for their needs, allowing our sales teams to more accurately sell to customers based on their capacity and performance needs. This blog post outlines the process we followed to define these tiers.

## Our Performance Testing Tooling

As you’ll find out as you read the blog post, in order to define these tiers, our team (and many other individuals at Auth0) ran countless performance tests of varying durations. One of the key things our team works on is the tooling and infrastructure for Performance Testing for the whole Engineering organization.

For the last three years, we’ve used [Artillery](https://www.artillery.io/) to run Performance Tests at Auth0, and it has allowed us to scale easily as usage of our framework organically grew within the company. This was important for a few reasons:

- Firstly, because in the last year and a half, the adoption of our framework went from a few people running Performance Tests at Auth0 to almost every engineering team;
- Secondly, because the scope of our tests also grew. For example, in December 2022, as part of the Tier Sizing for a larger customer, we ran 6,000+ RPS tests, which Artillery was able to easily handle thanks to leveraging AWS Fargate’s horizontal scaling.

We’ve also written our own CLI (a wrapper around the Artillery CLI called Airstrike), which has allowed us to standardize Artillery usage across the organization and cater to Auth0-specific use cases. Developers can now run authentication flows they’re familiar with by name, point it at an environment of their choice and simply type a target RPS, all without having to use an Artillery config. This abstracts even further the work of running a Load Test, which is especially helpful for teams that might not be product experts but still need to understand the performance impact of their work, such as platform teams. For example, anyone can run the `authorizationCode` scenario in a specific internal environment at any given RPS, for the duration they need, and with their desired load profile. All they need to do is run this fully configurable command:

```
airstrike run authorizationCodeNew --env tus1 --targetRPS 100 --targetDuration 3600 --loadProfile spike
```

Additionally, the latest Artillery offering, Artillery Dashboard, was also an important part of this Tier Right Sizing effort. Since Airstrike programmatically adds the relevant tags to tests by default, we were able to leverage the dashboard as a centralized location to view all our Performance Test reports for this effort, by filtering by tags to get the relevant test executions. Any load test report is available there for easy historical reference with all its results, logs, and graphs, and we found it easy to consume for stakeholders and developers alike.


![Auth0 Artillery Dashboard](https://images.ctfassets.net/23aumh6u8s0i/1ZpGlYTzV4cNJShIKMk9eq/f1d22eb93f77fe897cd2d75f91cda7bd/auth0-artillery-dashboard.png)


## Tier Right Sizing

My team followed a thorough four-step process which I’ll outline in this section. This process was followed for each of the tiers we’ve defined (5 private cloud tiers total). For all phases, a subset of core authentication scenarios was chosen by our Product team, which represents key product patterns our customers use. 

### Phase 1 - Exploratory Investigations

During this phase, the team worked together with Platform experts on experimenting with several infrastructure sizings and configurations, including:

- Number of resources needed for main services;
- Database Instance Sizes;
- Burstable Instance types;
- Kubernetes Nodes Instance Sizes;
- Kubernetes resource allocation;
- etc.

Since there were a lot of permutations to try, each experiment was only a 10-15 minute load test. This phase can almost be compared to “Exploratory Testing”. Apply an infrastructure change, run a load test, analyze results, rinse and repeat. It gave my team a good sense of the “gotchas” of the new platform, and served to develop an instinct for what would work and what wouldn’t. 

Once the team had arrived at what they believed to be an optimal configuration, it was time to prove that.

### Phase 2 - 1-Hour Baseline Load

This phase was the main acceptance criteria given to us by Product. Once we reached a stable configuration in Phase 1, the intent was to prove that it could hold the Performance SLA for 1 Hour at the defined Max RPS for the tier, for each of the core scenarios (ran sequentially).

If it failed the SLA, it was then necessary to go back to Phase 1 with more experiments until the team narrowed down a working configuration again.

### Phase 3 - 6-Hour Synthetic Load 

The previous phase (1-Hour Baseline Load) gave us confidence in the performance of each individual scenario at peak load, but that’s not always a typical traffic pattern. Realizing this, we decided to borrow from a concept we have in our Staging environments we call “Synthetic Load”, which emulates production-like traffic by running multiple weighted scenarios at the same time. 

For this effort, we added to our existing core scenarios a few more scenarios that customers are likely to have in their environments (Management API, Extensibility, etc.), creating a 6-hour Synthetic Load test, with a total RPS of the Max RPS for the Tier. This gave us confidence that the Tier would perform under more normal production-like conditions, when a lot more services are being hit.

### Phase 4 - 72-Hour Soak Test

The final piece of due diligence was to ensure that we didn’t see a performance impact from any memory leaks, cron jobs, database background operations, etc. For that reason, after consulting with a few experts in the system, we decided to be safe and run long soak tests. These gave us confidence that we wouldn’t see a problem manifest itself over time.

This ended up being a crucial part of the process and actually revealed a few important performance improvements that had to be done in our platform.

### Rollout

After the new tier definitions were live, all new customers used the new tier definitions. However, in a few cases, we had customers already migrated to our new Private Cloud platform, but not yet in our new optimized tiers. In order to guarantee a seamless transition to the newly defined tiers, a dedicated Platform team worked on a release plan. 

All infrastructure changes were gradually rolled out to customers through our [automated release pipeline](https://auth0.com/blog/how-we-do-releases-in-auth0-s-new-private-platform/). Changes were broken down into small batches, and thanks to our automated testing and the soak time built into our release pipeline, Platform teams were able to monitor each change going in to ensure no issues had been introduced, therefore minimizing any risk during this transition. 

## Conclusion

Right Sizing infrastructure is a game of balancing infrastructure cost and performance. There is no right final answer, and while this effort has taken us quite a bit of time, it will likely never be fully done - we will continue to optimize and improve on this over time. In a few cases, we have also had to do this exercise for specific customers with more unique and large-scale use cases (adapting which scenarios were used), so we will be working on generalizing some of these customer patterns.

I want to leave a final note that we were very excited to support this effort on the road to providing a modern platform for our customers. On a personal note, I am incredibly proud of my team for their contributions to this project, from the work in the tooling that eventually supported this effort to the people who directly worked on the project. It’s exciting to take our new platform to higher limits and take on bigger and bigger customers!

Optimizing Cost and Performance of Auth0's Private Cloud

Samuel Frank

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

Senior Product Manager

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

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

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

## NFTs in Identity and Access Management (IAM)

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

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

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

## Token Gating

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

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

## EVM Compatible, Open Source Coming Soon

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

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

## Unlocking NFTs for Your Application

### How it Works

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

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

### Installation

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

## What’s Next?

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

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

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

Cyril David

Cyril is a Platform System Architect at Auth0. He is a seasoned engineer with over a decade of experience in building distributed systems.

Platform System Architect

Designing for quality, reproducibility, and determinism.

**TL;DR**: Releasing individual services today is largely a solved problem. The complexity arises when we need to factor in the combinations of services, the configs and secrets necessary for a given service version, and the underlying infrastructure supporting those services while ensuring quality, reproducibility, and determinism.

## What’s in a Service?

When we talk about services, we largely focus on the code — but other things we might need to account for are:

* Config and Secrets
* Database related migrations
* Related infrastructure dependencies for a particular service version
* Implicit dependencies with other services

## Introducing the Concept of a Release Manifest

Given these problem constraints, we introduced a **release manifest** concept, which we define as a versioned JSON file describing a point-in-time representation of the entire Auth0 product stack, which includes: all service versions and the infrastructure version it was deployed on.

Configs and secrets are also versioned for every release manifest, which are snapshotted in our config/secrets storage.

Just to make it more concrete, here’s a hypothetical snippet:

```json
{
	"version": "v202221.99.0",
	"services": {
		"productpage": {
			"entity": {
				"name": "productpage",
				"default_vcs_branch": "main",
				"stacks": ["STACK_AUTH0"]
			},
			"artifact": {
				"version": "1.464.0",
				"vcs_revision": "dc62808d3a75a814a0748827d74e0936669dfec9",
				"vcs_url": "https://github.com/auth0/productpage",
				"reference": "sample.jfrog.io/docker/productpage:1.464.0",
				"metadata": {
					"build_number": "464",
					"build_started": "2022-05-24T18:52:34.753+0000",
					"build_url": "https://samplebuilds.auth0.net/job/productpage/job/main/464/"
				}
			}
		},
		"reviews": {
			"entity": {
				"name": "reviews",
				"default_vcs_branch": "main",
				"stacks": ["STACK_AUTH0"]
			},
			"artifact": {
				"version": "1.31.0",
				"vcs_revision": "dc62808d3a75a814a0748827d74e0936669dfec9",
				"vcs_url": "https://github.com/auth0/reviews",
				"reference": "sample.jfrog.io/docker/reviews:1.31.0",
				"metadata": {
					"build_number": "31",
					"build_started": "2022-05-24T18:52:34.753+0000",
					"build_url": "https://samplebuilds.auth0.net/job/reviews/job/main/31/"
				}
			}
		}
	}
}
```

A couple of notes:

* The version `v202221.99.0` is based on a year/week scheme (e.g., year`2022`, week `21`) and just a monotonic minor version which represents an atomic change.
* In this example, we only have two services called `productpage` (versioned `1.464.0`) and `reviews` (versioned `1.31.0`).
* This file is committed within our central git ops repository, with a matching tag `v202221.99.0` where the underlying infrastructure as code is also versioned for that specific point in time.
* Config/secrets aren’t versioned in git — but instead are stored separately in our config/secrets storage where we have the ability to snapshot them based on a specific version (in this case, all secrets/config have the same version `v202221.99.0`attached as metadata).

With this construct defined, we now have a baseline primitive for ensuring the properties we set out to solve initially:

* **Quality** — we can easily run our suites of system tests against a given version to ensure that our features work as expected.
* **Reproducibility** — we can create as many different spaces for testing or for onboarding new customers.
* **Determinism** — we’re guaranteed we have the same combination of service versions, config/secrets, database migrations, and infrastructure.

## A Note about Database Migrations

Database migrations themselves are a vast topic that is beyond the scope of this blog post, but the core properties we need to ensure are:

* **Forwards and backwards compatibility** – that a new version can be read by old code, and new code can work with the old schema.
* **Idempotency** – that any transient failures are wrapped in a transaction so we can retry the entire job if it fails. In addition, being able to run the same job once completed should be a no-op.

We utilize kubernetes jobs as the underlying primitive to run these database migrations and write them in such a way that retries during transient failures are ok — and that if we have to roll back, the previous service version will work with the new database migration.

Rollback is only within a reasonable constraint – in our case, the constraint is one major version away, which means a weekly version. So we only need to ensure backward/forward compatibility one major version away.

## Deploying a Release Manifest-Version

Given that we have all the necessary information codified in a release manifest version, the next step is to deploy older versions to a new version. Taking our hypothetical example:

* We have the current version `v202221.99.0`
* We need to deploy to a new version `v202222.105.0`

### Maintenance windows

Our private cloud customers can define a maintenance window where their space gets deployed every week. This means that these versions can only go out during that maintenance window — and that if anything potentially goes wrong, we have the ability to stop the release and Rollback to the prior version.

### Promotion pipeline

Like any release pipeline, we define a hierarchical set of channels; let’s imagine the following hypothetical example:

```
stage
+- internal
   +- free
      +- enterprise
         +- private cloud dev
            +- private cloud prod
```

So, in this case, if the stage had the version `v202221.99.0`, it means we need to deploy it _first_ to `v202222.105.0` before we can deploy `internal` to `v202222.105.0` and so forth.

### Rolling back

If, for any reason, a deployment encounters an error, we can roll back by shifting traffic back to the previous stable cluster.

## What’s Next?

The new release pipeline we’ve developed is only the beginning – and we’re planning to build more innovative tools for our platform in order to consistently deliver excellent service and reliability to our customers.

We are publishing a series of technical posts on how and why we replatformed. They’ll be linked at the bottom of this post as they publish and are also findable on our blog. If you have technical questions or ideas for future posts, please reach out to us via the [Auth0 Community](https://community.auth0.com/). (Our marketing team also tells us we would be remiss if we didn’t include a link to talk to Sales, so that is [here](https://auth0.com/contact-us), too.)

How We Do Releases in Auth0’s New Private Platform

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

Juan Cruz Martinez

Use Pulumi to provision Auth0 resources using your familiar programming languages

Pulumi is a fantastic solution for IaC (Infrastructure as Code). It allows you to manage your cloud services with high-level SDKs for popular programming languages like TypeScript, C#, GoLang, and Python. The familiarity and characteristics of those programming languages make it easier to set up, maintain and write code for your cloud services, including your friendly authentication provider Auth0.

This blog post will show you how to provision Auth0 resources using TypeScript and Pulumi. We will use the Pulumi tool to create and manage our infrastructure as code which is a great way to keep your infrastructure in a safe, version-controlled repository.

Let's get started!

## What Is Pulumi

![Pulumi](https://images.ctfassets.net/23aumh6u8s0i/1B42BPCAgRpINA6tClMT0O/36c34bd180b6eccb98c57b431e028b5e/logo-on-white.png)

Managing your cloud infrastructure can be a daunting task. When even automated, you need to learn a new programming language (or multiple languages) to write code for your cloud services.

Pulumi is a tool that enables developers to write code for their cloud services using familiar programming languages like TypeScript, C#, GoLang, and Python. This makes it easier than ever to get started with Infrastructure as Code.

Pulumi also abstracts away the cloud provider-specific resources and provides a unified view of all your resources in one place. This makes it easy to see what changes need to be made when you want to migrate to a different cloud provider.

## What Is Auth0 and the Auth0 Marketplace

Auth0 is a cloud-based identity and authentication management platform. It provides a platform for developers to add user authentication to their applications and supports a variety of authentication methods, including social login, username and password, and SSO.

The [Auth0 marketplace](https://marketplace.auth0.com) is where developers can find and use pre-built integrations for their applications. These integrations provide user authentication, management, and security features. The Auth0 marketplace offers a variety of integrations, including social login, enterprise federation, and developer tools.

## Setting Up Pulumi with Auth0

For this tutorial, you don't need to have prior knowledge of either Pulumi or Auth0, and we will guide you through the process of signing up, installing, setting up, and seeing your cloud resources created.

### Installing Pulumi

The first step before we start working on our project is to install Pulumi.

Pulumi is easy to install but slightly different on each operating system.

On a Mac, open your terminal, and enter.

```bash
brew install pulumi/tap/pulumi
```

On Linux, similarly, open your terminal, and enter:

```bash
curl -fsSL https://get.pulumi.com | sh
```

On Windows, it does require downloading an installer, so visit their [official installation guide](https://www.pulumi.com/docs/get-started/install/) for more information.

Once installed on any OS, you can verify that it is properly installed by running the following command on your terminal:

```bash
pulumi version
```

If everything is fine, it will output the current Pulumi version at the time of writing `v3.40.1`.

### Signing up for Pulumi

Pulumi is an open-source project and completely free to use; it requires having the Pulumi CLI installed and a backend system where the state and other configurations are installed.

You can set up and run a [self-managed backend instance](https://www.pulumi.com/docs/intro/concepts/state/#logging-into-a-self-managed-backend) or use Pulumi's cloud service, which is [free for individuals and offers several prices for teams and enterprises](https://www.pulumi.com/pricing/).

![Pulumi Sign up screen](https://images.ctfassets.net/23aumh6u8s0i/3KGglqkAt1OvK5Gey6N3au/29e794127f2390baf0aa002540b14a8c/pulumi-signup.png)

Since we want to get started quickly, we will [sign up for a FREE account](https://app.pulumi.com/signup) using any authentication provider.

After you log in to pulumi.com, go to your terminal and run the following command:

```bash
pulumi login
```

You will see an output like

```bash
Manage your Pulumi stacks by logging in.
Run `pulumi login --help` for alternative login options.
Enter your access token from https://app.pulumi.com/account/tokens
 or hit <ENTER> to log in using your browser : 
```

Hit `<Enter>` to log in through your browser, and it's done. Alternatively, you can manually login into https://app.pulumi.com/account/tokens to generate a token and enter it into the CLI.

### Create an Auth0 application for the Pulumi service

Pulumi can manage a lot of the resources of your Auth0 account, but it can't create one for you. Fortunately, that's easy to do. Go ahead and <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account</a> now.

While on the [Auth0 dashboard](https://manage.auth0.com/dashboard/), navigate to the "Applications" section on the left-side menu.

![Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/5ycVL5iWad2WI70iVG3Y3M/92c626c2ddfcd5bca16f881190ac48f1/auth0-dashboard.png)

Next, the new application dialog appears; enter an application name, e.g., "Pulumi App", and select the "Machine to Machine Applications" type.

![Auth0 new app dialog](https://images.ctfassets.net/23aumh6u8s0i/2ssONixKyuoHY6YgZMdPdi/72fd242d7701892ebeb165f03c5ed088/auth0-create-app.png)

Since we selected the "Machine to Machine" type, we won't need a user for Pulumi; instead, we will use client credentials. But first, we need to authorize the app to access an API, and in our case, we will select the _Auth0 Management API_, which is available by default with your tenant.

![Auth0 authorize machine to machine application dialog](https://images.ctfassets.net/23aumh6u8s0i/0IaEdXG0RMXv7c9CXBrKo/1de4c982417dd75f1811ffef6576ac8a/auth-authorize-app.png)

After selecting the API, the dialog will expand, listing all the permissions available for that API. We recommended that you follow the [principle of least-privilege](https://www.okta.com/identity-101/what-is-least-privilege-access/) and choose the authorizations carefully based on your project requirements, and no more.

With that said, and only because this is a sandbox account, we'll select all to continue, so you are not limited while following this tutorial and dealing with unauthorized access due to missing grants.

### Create a new Pulumi project

We are done with all the platform sign-ups and configurations, and we are ready to start coding.

When working with Pulumi, or any other IaC tool, you'll have to decide if you want to include your Pulumi code alongside your application code or on a separate repository. The steps won't differ, though you may want to name and place directories differently.

To start, let's create a new working directory where we'll place all our Pulumi code:

```bash
mkdir pulumi-auth0-quickstart && cd pulumi-auth0-quickstart
```

Next, we will generate a new project using the Auth0 template:

```bash
pulumi new auth0-typescript
```

> Note that we specified the template name `auth0-typescript`, but there are other languages available. You can read more about Auth0 and Pulumi in the [Auth0 Marketplace](https://marketplace.auth0.com/integrations/pulumi) and the [Pulumi registry docs](https://www.pulumi.com/registry/packages/auth0/).

Once you run the command above, the terminal window will prompt you for a few values:

- Project name: A unique project name.
- Project description: A short description of your project.
- Stack name: typically referred to as the environment or the organization plus the environment, e.g., "dev" or "auth0/dev".
- auth0:clientId: The Auth0 client id for the Pulumi App; we'll go into details on how to get this information next.
- auth0:clientSecret: The Auth0 client secret for the Pulumi App.
- auth0:domain: The Auth0 domain where your Pulumi App is running.

#### How to capture the Auth0 values from my Auth0 account

Heading back to the [Auth0 dashboard](https://manage.auth0.com/dashboard/) and into the recently created application "Pulumi App", you'll see the app overview, then click the _Settings_ tab to access the information we need.

![Auth0 Application Quick Start](https://images.ctfassets.net/23aumh6u8s0i/37CfC12yd0FCOg7lKYWw4F/c25e701c2b6f420836885fa6557e7fba/auth0-app-home.png)

Once on the settings page, the three values we need, clientId, client secret, and domain, are readily available to copy on your screen.

![Auth0 application settings](https://images.ctfassets.net/23aumh6u8s0i/H6CftW0mFWlOYj7VK7pAW/d669e9c327a1ef495e57b95f74ba6da1/auth0-app-settings.png)

Finally, enter those values in the terminal and way for the project to generate. It may take a minute or two, depending on the programming language.

And don't worry about adding your client secret here, it will be only [stored encrypted](https://www.pulumi.com/learn/building-with-pulumi/secrets/), and you can decide the level of control and encryption provider of your choice if necessary.

#### Pulumi and Auth0 quick start project structure

After your project completes, Pulumi will have generated an npm project with three essential files:

- `index.ts`
- `Pulumi.[env].yaml`: Configuration file where all your Auth0 values are stored.
- `Pulumi`: Project related metadata

Let's next take a look at the generated `index.ts` file;

```typescript
import * as pulumi from "@pulumi/pulumi";
import * as auth0 from "@pulumi/auth0";

const client = new auth0.Client("client", {
 allowedLogoutUrls: ["https://www.example.com/logout"],
 allowedOrigins: ["https://www.example.com"],
 callbacks: ["https://example.com/auth/callback"],
 appType: "regular_web",
 jwtConfiguration: {
 alg: "RS256"
 },

})

export const clientId = client.clientId
export const clientSecret = client.clientSecret
```

It is a simple file that will create a new _Auth0 Client_ (or _Auth0 application_), and will set configurations like the application type, logout URLs, callbacks, and allowed origins, all the typical settings you'll need to set up a regular web application.

### Set up the auth0 provider into an existing Pulumi project

If you already have an existing Pulumi project and would like to provision Auth0's resources, you'll first have to install the Auth0 provider for your programming language.

If using typescript, from your terminal, on the root of your Pulumi project, run:

```bash
npm i @pulumi/auth0
```

If you are using other programming languages, check out their official documentation on [how to install the Auth0 provider](https://www.pulumi.com/registry/packages/auth0/installation-configuration/)

After installing the provider, you'll have to configure the Auth0 clientId, client secret, and domain from your "Pulumi App".

To capture the value, check the previous section [How to capture the Auth0 values from my Auth0 Account](#how-to-capture-the-auth0-values-from-my-auth0-account) and, on your terminal, enter the following command with the updated values:

```bash
pulumi config set auth0:domain XXXXXXXXXXXXXX
pulumi config set auth0:client_id YYYYYYYYYYYYYY --secret
pulumi config set auth0:client_secret ZZZZZZZZZZZZZZ --secret
```

Don't forget to use `--secret` for _client_id_ and _client_secret_ as that will tell Pulumi to encrypt the values.

## Running Pulumi and Provisioning the Auth0 Resources

Now we are ready to use Pulumi to provision our Auth0 resources.

On your terminal, run:

```bash
pulumi up
```

Pulumi will first compare the current state (generated by the written code) versus the previously saved state (empty since it is our first execution) and will prepare a plan based on the results.

Here is what it looks like on the terminal:

```text
Previewing update (dev)

View Live: https://app.pulumi.com/bajcmartinez/pulumi-auth0-quickstart/dev/previews/e93bebef-eecf-49ec-a58f-86d0b7ea11db

 Type Name Plan 
 + pulumi:pulumi:Stack pulumi-auth0-quickstart-dev create 
 + └─ auth0:index:Client client create 
 
Outputs:
 clientId : output<string>
 clientSecret: output<string>

Resources:
 + 2 to create

Do you want to perform this update? [Use arrows to move, enter to select, type to filter]
 yes
> no
 details
```

Since it is the first time we run Pulumi for this project, it will create a new Pulumi stack on the backend and will provision the Auth0 application as we defined it in the `index.ts`.

Since we agree with the plan, we proceed to execute by selecting the option `yes` on the screen.

Now Pulumi is creating all the resources and will print the results on the terminal when it finishes.

```text
Updating (dev)

View Live: https://app.pulumi.com/bajcmartinez/pulumi-auth0-quickstart/dev/updates/1

 Type Name Status 
 + pulumi:pulumi:Stack pulumi-auth0-quickstart-dev created 
 + └─ auth0:index:Client client created 
 
Outputs:
 clientId : "ltiZx0e53LJoqr5IpIJrmZHAuwhsj2WZ"
 clientSecret: [secret]

Resources:
 + 2 created

Duration: 7s
```

What would happen if I were to run `pulumi up` again? It should be totally safe, so let's try it and see the results.

```text
Previewing update (dev)

View Live: https://app.pulumi.com/bajcmartinez/pulumi-auth0-quickstart/dev/previews/7fd259e6-cadf-43ab-8b74-3e2329ed818c

 Type Name Plan 
 pulumi:pulumi:Stack pulumi-auth0-quickstart-dev 
 
Resources:
 2 unchanged

Do you want to perform this update? [Use arrows to move, enter to select, type to filter]
 yes
> no
 details
```

As expected, Pulumi doesn't detect any changes, the state variable hosted in Pulumi's service and the local configuration given in the code match.

**But what exactly happened in our Auth0 account?** If we go back to the [Auth0 dashboard](https://manage.auth0.com/dashboard/), a new application will appear with the name `client-{unique identifier}`, e.g. `client-8c41df9`. Pulumi, by default, adds that unique identifier at the end of each resource name to prevent name clashing.

![Example of application created with Pulumi in the Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/5qA7YmlNDvzg5GIYngXN0b/e906f8c2e552eeb91420c533fce37d31/auth0-provisioned-app.png)

## Use Case Examples for the Pulumi Auth0 SDK
Let's see next some examples of what can be done with the Pulumi Auth0 SDK.

### Provision a new Auth0 application
One of the most common tasks when automating the provisioning of Auth0 resources is to create applications, and as we discussed, we do that by leveraging the [_Client module_](https://www.pulumi.com/registry/packages/auth0/api-docs/client/).

The [official documentation](https://www.pulumi.com/registry/packages/auth0/api-docs/client/) goes into detail on all the parameters and presets for applications, but here is a small sample for a typical scenario for a SPA application (since we already covered web apps):

```typescript
const client = new auth0.Client("my-spa", {
 allowedLogoutUrls: ["https://www.my-spa.com/logout"],
 allowedOrigins: ["https://www.my-spa.com"],
 callbacks: ["https://my-spa.com/auth/callback"],
 appType: "spa",
});
```

### Provision a new Auth0 user
Another typical use case is to create users. This is commonly done for admins, other super users, or even test users.

Let's see an example of creating an _admins_ role and a user belonging to the group.

```typescript
const adminGroup = new auth0.Role("admin", {description: "Administrator"});
const jc = new auth0.User("bajcmartinez", {
 connectionName: "Username-Password-Authentication",
 givenName: "Juan Cruz",
 familyName: "Martinez",
 email: "youremail@yourcompany.com",
 password: "very-secure-!nitial-passw0rd",
 emailVerified: true, // We don't want to email the user to confirm its registration
 roles: [adminGroup.id],
});
```

In the example above, we use the [default database connection](https://auth0.com/docs/authenticate/database-connections) "Username-Password-Authentication". Optionally you can create and use other connections.

> Remember that the user requirements from your connection will apply even when using Pulumi, and if a condition does not match, e.g., "Password is too weak", then the resource will fail to create.

### Set your Branding and personalization with Pulumi and Auth0
Another area where Auth0 excels is personalization, allowing you to personalize the experience with your brand, your colors, logo, messages, email addresses, and even email templates.

You can customize everything about your user's experience through the Auth0 dashboard, but if you are using Pulumi, you can change those parameters through code, thanks to the modules like [Branding](https://www.pulumi.com/registry/packages/auth0/api-docs/branding/), [Email template](https://www.pulumi.com/registry/packages/auth0/api-docs/emailtemplate/), [Prompts](https://www.pulumi.com/registry/packages/auth0/api-docs/promptcustomtext/) and more.

Here is an example of how to change your brand colors and logo using TypeScript:

```typescript
const myBrand = new auth0.Branding("my_brand", {
 colors: {
 pageBackground: "#000000",
 primary: "#0059d6",
 },
 logoUrl: "https://mycompany.org/logo.png",
 universalLogin: {
 body: "<!DOCTYPE html><html><head>{%- auth0:head -%}</head><body>{%- auth0:widget -%}</body></html>",
 },
});
```


### What resources are available with the Pulumi Auth0 integration?
With Pulumi, you can set up pretty much everything you can do with the Auth0 dashboard, so no surprise there are quite a few modules available for us to use, like [Actions](https://www.pulumi.com/registry/packages/auth0/api-docs/action/), [Client Grants](https://www.pulumi.com/registry/packages/auth0/api-docs/clientgrant/), [Attack Protection](https://www.pulumi.com/registry/packages/auth0/api-docs/attackprotection/).

You can read the full list on [Pulumi's official docs](https://www.pulumi.com/registry/packages/auth0/api-docs/).

## Final Thoughts
More and more companies embrace DevOps and infrastructure as code to provision, manage and maintain the ever-increasing complexity of cloud services.

Pulumi helps individuals and teams to handle their IaC strategy through familiar programming languages, reducing the effort and skills needed.

Thanks to its extensibility with libraries, you can provision your servers, databases, queues, and, for example, Auth0 resources to build and customize the online identity experiences of your apps.

Thanks for learning!

Provisioning Auth0 resources with TypeScript and Pulumi

MatthewHughes

I'm a Liverpool-based technology writer with a passion for usability and security. When I'm not churning out copy, you'll find me walking my two dogs: Luna and Apollo

Business Content Writer

Matthew Hughes

When it comes to SaaS applications, performance matters. Private Cloud SaaS helps you scale the performance of your growing SasS applications.

Performance matters. You know this, of course. Every second of additional latency translates into [lower conversions and tougher customer retention](https://businessmondays.co.uk/tackling-cart-abandonment-with-improved-login-experiences/). It's why you agonize over every individual detail, why your cloud infrastructure vibrates with the well-oiled efficiency of a Formula One engine.

As your business scales, staying fast becomes much harder. Essential SaaS (software-as-a-service) components that worked well when you were a smaller company now struggle to contend with your higher traffic volumes. 

Fortunately, there's an alternative. Private cloud SaaS offers the flexibility of a self-hosted application with none of the downsides. And, for performance-sensitive applications, it offers the boost necessary to deliver an incredible, slick user experience. 


## The Need for Speed 

Virtually every company and public sector organization uses SaaS in some form. Why? It's often the most practical and affordable option. Hiring and training someone to operate and provision a system takes time, money, and resources. With SaaS, the vendor handles long-term maintenance and upgrades. As most use a subscription model, there are no major upfront costs.

Most SaaS applications, by design, are multi-tenant environments. Multiple customers — whether individuals or organizations — share the same computational resources. This model is cheaper but has several trade-offs. Customers have little choice in where the application is deployed. They lose control. They can't make the subtle tweaks that ultimately result in faster, more responsive applications. 

Private cloud SaaS applications are different. They combine the benefits of a SaaS app (low costs, low maintenance, faster time-to-market) with the flexibility and autonomy of a self-hosted application. Customers can choose where, how, and with whom to deploy their application. They are the sole tenants, and they set the rules.

This control helps organizations comply with the ever-increasing number of data residency laws worldwide. But it can also deliver meaningful performance benefits, resulting in more responsive applications and better user experience outcomes.


## Reducing Latency One Millisecond at a Time

Have you ever wondered why Google only shows you ten results for each page? It seems counterintuitive, doesn't it? Google is a search engine. Its job is to show you relevant results for your queries. More is better, surely?

Not necessarily. In 2006, Marissa Mayer, then the company's Vice President of Search, [shared the results of an internal experiment](http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html) at the Web 2.0 Conference. Google asked a select group of users if they wanted to see more results with their queries. Most said yes. 

In response, Google provided random users (not just those in the focus group) with 30 results per page — triple the normal amount. 

What happened next? Frustration. Load times more than doubled for those in the test cohort, soaring from 0.4 seconds to 0.9 seconds. That 0.5-second delay had a measurable effect on user activity and satisfaction. Traffic and revenue from the test group dropped 20%. As Mayer said at the time: "Users really respond to speed." 

How does this relate to private cloud SaaS? Well, there are limits to how far you can optimize an application for speed with efficient coding and generous resourcing alone. 

If your primary application is located in Amsterdam but relies upon a component hosted in Los Angeles, you'll find a measurable delay as packets make their long journey through a network of submarine cables. You add 135ms to your load times – give or take 10ms.

You can't speed this process up. You are constrained by the speed of light. That's fast, but when you are trying to deliver an incredible experience to your customers, it feels like an eternity. 

You have only one solution: bring that component physically closer to your core application. 

The private cloud SaaS model lets you deploy resources in the same continent, country, and even data center. By eliminating performance bottlenecks in your product, your customers will benefit from a faster, more responsive experience. 


## How Private Cloud SaaS Can Help You Scale 

As your business grows, you may feel constrained by the limitations of multi-tenant, public cloud SaaS applications. Many vendors limit the number of requests that can be made per second (RPS) in order to preserve the quality of the service. While most SaaS companies are prepared to oblige larger customers with bespoke plans, this isn't always a given. 

And you cannot always predict when demand will spike. Take lab-testing and diagnostic services provider (and Auth0 customer) [BioReference Labs](https://auth0.com/case-studies/bioreference), for example. BioReference had begun transitioning to a patient-centric model, where customers could access their lab results without going through an intermediary — like their physician. As a result, it invested in Auth0's multi-tenant customer identity and access management (CIAM) platform. 

At the start of the COVID-19 pandemic, demand for its services jumped 25 times. Its monthly active users increased from 8,000 to 148,000. In response, the company migrated its identity infrastructure to a private instance of Auth0's Identity Platform, giving it essential breathing room to meet existing demand and add more customers in the future.

By opting for a private cloud SaaS application, you can provision your environments with the resources necessary to meet existing demand. And you have the flexibility to change your environment as circumstances dictate. 


## Becoming Resilient with Private Cloud SaaS 

Nobody likes downtime. Not your customers, who rely on your product. And certainly not you. 

Performance issues can devastate your bottom line. As load times and instability increase, conversion rates drop. Unfortunately, these problems are often beyond your control. In a multi-tenant SaaS environment, seasonal demand spikes — like those during the holiday shopping season — can result in longer wait times and instability for your customers. 

The private cloud SaaS model can insulate your business from any disruption in the public cloud SaaS application. With control over the environment, you can structure your SaaS infrastructure to be highly resilient, with custom disaster recovery protocols and redundant failover systems. 

You can establish custom backup and restore procedures. Mitigating against data center-level disruption becomes easy. Should the underlying cloud infrastructure fail, you can automatically switch operations to an unaffected environment, keeping downtime to a minimum. And with bespoke update rules, you can deploy patches and new features at a time when your customers are least active. 


## Nimble SaaS, Happy Customers

For most companies, it makes sense to use a multi-tenant public cloud SaaS product. But as your needs increase, you may find it sensible to switch to a dedicated environment. 

Private Cloud SaaS offers the best of both worlds. It requires little maintenance but offers the flexibility of a self-hosted application. You become able to make the choices necessary to deliver a lightning-fast, highly resilient product.

The Auth0 Identity Platform is available in both multi-tenant and private cloud versions. When you opt for a private environment, you get all the benefits of our industry-leading CIAM platform, but with the flexibility to choose how and where it's deployed. To find out how it can benefit your company, reach out to our team.

How Private Cloud SaaS Can Boost Application Performance

Dan McCorriston

Senior Product Marketing Manager

Now, all Auth0 customers - including those on our private cloud platform - have access to all the offerings on the Auth0 Marketplace.

Auth0 is excited to announce a newly expanded offering for [our new private cloud platform](https://auth0.com/blog/a-technical-primer-of-auth0-s-new-private-cloud-platform/) customers - Actions Integrations are now available from the Auth0 Marketplace. What that means is all Auth0 customers that utilize our new private cloud platform have access to all the offerings on the Auth0 Marketplace - SSO, Social Connections, Log Streaming Integrations, and now, Actions Integrations.

Actions Integrations will start to appear in the Development/Staging space now and will be ready in the Production environment in the coming weeks dependent on various release cadences.

### What are Actions Integrations and the Auth0 Marketplace, and why should I care?

At Auth0, we realize that many customers have unique needs, and as a result, they want the ability to customize their identity product. In order to serve these additional customer needs, Auth0 built a variety of tools to extend the functionality of identity. This concept is called **extensibility.**

Auth0 Actions and Actions Integrations is the next generation of **extensibility**. Actions is the low-code offering, and Actions Integrations allows customers to use pre-written no-code, drag and drop options to add other functionality such as ID proofing and consent management. Auth0 provides this additional functionality through integrations with **our Ecosystem partners** offered in the Marketplace.

The Auth0 Marketplace and Auth0 Actions are the two complementary ways we extend Auth0. Customers and their end users need the ability to resolve their unique identity requirements — which may include payments, subscription management, signing terms of services, etc. — to complete a successful user access journey into their application or service.

### What is Private Cloud?

Auth0’s [Private Cloud offering](https://auth0.com/cloud) provides the flexibility and agility offered by cloud deployments but also allows a customer to maintain the control and security they need to protect their customers and their businesses. Many customers that have high security and regulatory concerns - those in the financial services industry, for example - may require certain standards of uptimes, updates, failovers, and support for their deployments. The Auth0 Private Cloud deployment models come in both Standard and Managed levels, depending on the customer’s requirements.

Auth0 [recently invested in retooling the Private Cloud platform](https://auth0.com/blog/a-technical-primer-of-auth0-s-new-private-cloud-platform/) to support more automation, adopt current technologies and help scale the Private Cloud to thousands of environments.

### Benefit of Private Cloud and Actions Integrations

Private Cloud has a strong appeal for customers who have high volume or who are from certain verticals. For example, verticals like banking, where shared databases are a concern. Or customers who have data residency requirements or even those who prefer to deploy in a specific region close to their customers. Private Cloud customers do not have to be concerned with sharing space, public cloud request limits, and multiple customer’s data being present in the same deployment. 

Many of the same customers that have a need for Private Cloud also have extensive use cases for extensibility and the no-code integrations available in the Auth0 Marketplace. Easy-to-use integrations such as Identity Proofing and Customer Data Management. With Actions Integrations, developers no longer need to build or maintain custom code or make changes when we alter programming models or release new versions of Node. These Actions Integrations are built and maintained by our Ecosystem partners and are available right in the Auth0 Marketplace. 

A couple of examples of Actions Integrations available in the Auth0 Marketplace:

* [**Deduce Intelligent MFA**](https://marketplace.auth0.com/integrations/deduce-intelligent-mfa): Deduce prevents consumer-facing Account Takeover (ATO) and registration fraud via the constantly growing Deduce Identity Network, with over 400M profiles and in excess of 1.2B daily activities. Deduce risk signals significantly reduces false positive MFA challenges.
* [**Tealium User Login**](https://marketplace.auth0.com/integrations/tealium): Tealium connects customer data - web, mobile, offline, Internet of Things (IoT) - so brands can connect with their customers. Tealium empowers companies to create a unified, real-time customer data infrastructure and makes customer data more valuable, actionable, and secure.

### Is this an increased opportunity for Ecosystem Partners?

Now that Private Cloud customers have access to Actions Integrations in the Auth0 Marketplace, our Ecosystem Partners have a new and expanded pool of potential customers to reach through building and publishing Actions Integrations into the Marketplace. There’s never been a better time to become an Ecosystem Partner and market your Actions Integrations through the Auth0 Marketplace.

Make sure to visit the [Auth0 Marketplace](https://marketplace.auth0.com/) to see if there is an integration that optimizes your customer’s identity experience. To find out more about becoming a [Private Cloud](https://auth0.com/docs/deploy-monitor/deploy-private-cloud) customer, please [send an inquiry](https://auth0.com/get-started?place=documentation%20post&type=link&text=contact%20auth0%20sales) and someone from Auth0 will contact you about whether it’s a good fit for your business.

Actions Integrations Now Available in Private Cloud

Uploaded from Data Pipelines on Auth0’s New Private Cloud Platform

Andrew is a Staff Engineer at Auth0 focusing on bytes that move for the new Auth0 platform. He is a startup co-founder with over a decade of experience delivering developer focused products at scale. When not at the computer, you can find him hiking up mountains, watching improv comedy, or spending quality time with his wife and son.

Staff Engineer

Andrew Hawker

“Data goes in; data goes out. You can’t explain that.”

**TL;DR:** Auth0 has replatformed our private cloud offering onto Kubernetes. As part of this new architecture, we’ve had the opportunity to apply modern practices to the data infrastructure that powers near real-time features and provides the necessary knobs for data governance.

_Hello friends! Before we get started, I recommend that you check out “[A Technical Primer of Auth0’s New Private Cloud Platform](https://auth0.com/blog/a-technical-primer-of-auth0-s-new-private-cloud-platform/)”, “[Architecture of the New Platform](https://auth0.com/blog/the-architect-s-view-of-auth0-s-new-private-cloud-platform/)”, and “[Security of the New Platform](https://auth0.com/blog/securing-auth0s-new-private-cloud-platform/)”. These wonderful posts cover foundational aspects of the platform that I will build upon here._

## Introduction

“Data is the new oil,” quipped Clive Humby in 2006, and the industry has been chanting “Drill, baby, drill” ever since. Just like oil, data needs to be refined/processed/transformed to unlock its full value. As the saying goes, “Necessity is the mother of invention,” so the industry has birthed an entire specialization around Data (Science, Engineering, Platform, Warehouse) to extract that value. The analogy remains apt because, just like oil, data is now being respected as a potentially hazardous material. With GDPR, CCPA, and their future brethren, we’ve come to understand the importance of proper packaging and safe keeping of our data assets. No more ziplock bags of data goop in the trunk of my Dodge Neon. Neatly stacked steel crates with big padlocks under 24/7 surveillance that can be crypto shredded at a moment's notice is the future of data management. With this New Platform initiative at Auth0, we’ve had the opportunity to apply some modern practices to our data infrastructure and take another step towards that dystopian data future.

![Introduction](https://images.ctfassets.net/23aumh6u8s0i/5GGILFTY6KNSabp6Ixn2dA/1b6a7923fa10b614f320c94cf436c2b9/Uploaded_from_Data_Pipelines_on_Auth0_s_New_Private_Cloud_Platform)

Taking a page from Leo’s 10k foot view in “[Architecture of the New Platform](https://auth0.com/blog/the-architect-s-view-of-auth0-s-new-private-cloud-platform/)”, we’ll be touching on the highlighted sections of the platform in this post. We’ll start with some introductory context, discuss our guiding principles, dive into the tools we chose, and then exercise them with a few sample scenarios commonly seen at Auth0.

Put down that bag of data goop, and let’s get started!

## What is a Data Pipeline?

_“In a world where SaaS and microservices have taken over...”_ — Movie Voiceover Guy

*Looks around*

“Hey, he’s talking about us!”

Software is on a hockey stick growth curve of complexity. We’ve got an ever-increasing number of disparate systems hoarding data and even higher demand on us to unlock value from it.

1. “Show me the region where credential stuffing attacks are originating from” — A customer dashboard
2. “Let me run custom code in an Auth0 Action immediately after a user is deleted” — A feature request
3. “Show me failed login counts from the past 60 days for all tenants on the Performance tier that have been a paying customer for more than one year” — An upsell opportunity

Before we can begin to actually answer any of those questions, we need the connective tissue to ship data from Point A to Point B enriched with E and transformed by T. That’s the role of the Data Pipeline.

That’s not to say that Data Pipelines just carry simple domain/product events. Application logs, exception stack traces, Stripe purchase orders, Salesforce billing updates, etc., are all events that can be emitted and flow through a pipeline.

_“The Data Pipeline is a series of tubes.”_ — Michael Scott

Eh, close enough.

## Our Guiding Principles

Before jumping into implementation, it’s important to understand that _our_ requirements are not necessarily _your_ requirements. The decisions we’ve made might not be the correct decisions for you! When evaluating solutions and discussing tradeoffs, these are some of the key points that helped guide us.

### Event Durability

Event durability is a supremely important requirement for us; missing and out-of-order events are a non-starter.

If we imagine emitting a simple event, e.g., “UserCreated,” there are a few approaches:

1. Integration/domain event from application code
2. [Outbox Pattern](https://microservices.io/patterns/data/transactional-outbox.html)
3. [Change Data Capture (CDC)](https://en.wikipedia.org/wiki/Change_data_capture)

Discussing tradeoffs between these is a blog post in itself, so I’ll just simply say that they’re complementary and fit different needs, with the main tradeoff being durability vs. coupling.

Events emitted by application code can get lost with failures during dual writes. Outbox Pattern struggles if you don’t have strong transactional guarantees with your database of choice and doubles your write load. Change Data Capture (CDC) is the most durable of the three but “ships” the database table schema in each event, promoting unnecessarily tight coupling and having limited access to only the modified row.

### Data Governance (O Data, Where art thou?)

Data Pipelines come in different shapes and sizes.

* Are messages serialized as Avro, JSON, or Protobuf? XML? _Crickets._
* Are they encrypted or plain text?
* What is the expected throughput? Sustained or burst?
* Streaming or batch processing?
* Do producers retry or drop events during downtime?
* What enrichments/transforms do we need to apply?

Before discussing these technical details of a pipeline, we must first consider what is **_in_** the pipeline.

1. Do messages within the pipeline contain Customer Data?
2. Do messages within the pipeline need to leave the region where they originated?

If you answered “Yes” to one or more of the previous questions, calmly go outside and light your computer on fire. Joking aside, by asking and answering those questions, you can begin to understand the security/compliance posture you must take. This is likely to lead you down the road of even more questions.

* What region is data being shipped to relative to where it’s generated?
* Are we sending aggregated data or individual records?
* How is this data encrypted in transit and at rest?
* What Customer Data (down to each individual field) are we processing?
* Are there treatments that are sufficient for each field to be compliant while still fulfilling the business need? Masking, partial redaction, hashing, encryption, etc.

Remember that data is a valuable resource but can also be a hazardous material and must be handled properly. If you discover cases of processing Customer Data and shipping it across geographic boundaries, find yourself a buddy in the compliance department to help sort it out.

### Inertia

Event streaming technology is an active area of development, with many new companies and products entering the space. This is great because we can stand on the shoulders of giants, but if you’re not careful, it can leave you prone to painful churn, deprecation, incompatibility, or entire products going bust.

While we don’t want to fully jump into the [Boring Technology Club](https://boringtechnology.club/) pool, we _do_ want to build on robust tools that will survive a hype cycle. If a project doesn’t have enough inertia and community buy-in to survive the departure of the original stewards, it might be best to consider an alternative.

### Composition

The only constant in life is changing, especially technological and business requirements. We need to consider how our technology choices can be composed, merged, bent, broken, and smeared together to get the job done. If we choose a solution too rigid, it’ll be re-written often. A solution too flexible is unlikely to be fully understood. We should try and use tools that provide a healthy balance.

## It's Dangerous to Go Alone! Take This

We’re not the only company building on data pipeline technologies, thankfully. We can stand on the shoulders of those before us. Using our guiding principles outlined above, here’s the alphabet soup of open source technologies we chose to plug together to make our data go.

#### Kafka

The original Auth0 platform was built to run only on AWS and heavily leveraged Kinesis, SQS, and RabbitMQ. When evaluating cloud-agnostic solutions for the new platform, it was difficult to say no to [Kafka](https://kafka.apache.org/). With most cloud providers offering a hosted solution (or API-compatible layer), it’s becoming the lingua franca for durable event backends. With relatively sane approaches to implementing encryption at rest or in-flight, it meets most of our needs right out of the gate.

#### Kafka Connect

[Kafka Connect](https://docs.confluent.io/platform/current/connect/index.html) has a solid ecosystem of integrations that is relatively plug-and-play (although schema vs. schema-less can be a pain). The [AWS S3](https://docs.confluent.io/kafka-connect-s3-sink/current/overview.html) sink connector was available to us immediately, and an open-source [Opensearch](https://github.com/aiven/opensearch-connector-for-apache-kafka) connector popped up quickly after the Elasticsearch license fork snafu.

[Single Message Transforms (SMT)](https://docs.confluent.io/platform/current/connect/transforms/overview.html) within a connector are simple mechanisms for stateless transformation/enrichment of all messages. This works well for us to inject static metadata from the new platform like Space, POP, Cloud, current deployment version, etc.

#### Schema Registry

Kafka Connect heavily utilizes the[ Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/index.html) for message serialization and validation. While some connectors support “schemaless” messages, you’ll find yourself, as we have, swimming upstream if you don’t leverage the registry with these tools. We haven’t fully realized our vision here and plan further investment over the next few quarters.

#### Debezium

As I mentioned before, event durability was an extremely important requirement for us, so we started with Change Data Capture (CDC) powered by [Debezium](https://debezium.io/). With their [MongoDB](https://debezium.io/documentation/reference/stable/connectors/mongodb.html) and [Postgres](https://debezium.io/documentation/reference/stable/connectors/postgresql.html) source connectors, we’re immediately plugged into the Kafka Connect ecosystem.

#### Data Shield

When it comes to data policy enforcement for streaming messages, there didn’t seem to be many free/open-source solutions we could take off the shelf. For this, we wrote our own in-house solution in [golang](https://go.dev/).

Data Shield handles data policy enforcement with schemas, data mutation, and topic muxing. With it, we can define events flowing through a topic using an IDL like [protobuf](https://developers.google.com/protocol-buffers). The IDL is not tied to the serialization format in the topic, e.g., we can use a protobuf IDL for JSON events.

Let’s walk through a quick example. Let’s say we emit events of Company records that have a field for their EIN.

```
message Company {
  string name = 1;
  string address = 2;
  string ein = 3;
  string url = 4;
}
```

Field enforcement is zero-trust by default, so any fields not defined in the IDL are automatically excluded. This is a critical capability for us since we receive many JSON/BSON-based events with loose schemas where fields can easily be added/removed by the upstream producer. This minimizes the blast radius of an upstream service accidentally or intentionally producing new fields with Customer Data on streams that leave the region.

Using the IDL, we annotate fields with policy details like classification and treatment rules. From our Company example, let's assume the **_ein_** field is classified as Personally Identifiable Information (PII). We could model this as:

```
  string ein = 3 [
    json_name = "ein",
    (auth0.proto.options.fields.v1.classification) = {
      classification: PII,
    },
    (auth0.proto.options.fields.v1.transform) = {
      processor: {
        name: OPENSEARCH,
        transforms: [
          { mask: { length: 4, character: "*", reverse: true } }
        ]
      },
      processor: {
        name: FRAUD_DETECTION,
        transforms: []
      },
      processor: {
        name: EU_DATA_LAKE,
        transforms: [
          { drop: { } }
        ]
      },
      }
    }
  ];
```

Each separate data processor of the stream can apply their own independent rules based on their business function. In this case, our Observability stack in Opensearch has the last four characters masked, our Fraud Detection feature receives the value in plain text, and the Data Lake processor in the EU doesn’t receive it at all.

With this IDL definition and some minor service configuration, we can tell Data Shield to enforce the policy on one or more topics. In the simple case, it will take the incoming “dirty” topics and output “clean” topics, one for each data processor with their specific rules applied.

![IDL](https://images.ctfassets.net/23aumh6u8s0i/3ka0jensdx70UoBfYmdnrd/c85e55476cde1771e397710a63058d61/Uploaded_from_Data_Pipelines_on_Auth0_s_New_Private_Cloud_Platform)

This multiplexing increases our storage costs but allows us to leverage different retention policies and Kafka ACLs so consumers can only access data from their assigned topics. While this is a cost we are (currently) willing to pay for strict data isolation, it is an area for future investment with a potential “decryption and schema enforcement on reading” strategy.

As we’ve iterated on the Data Shield concept, we’ve added a few more features to make our lives easier.

* One-to-many topic to IDL schema mapping for topics with heterogeneous message types. This is very helpful for topics that contain app/service logs.
* Schema format conversions, e.g., read JSON, write Avro
* Extend IDL to support field enrichment with generated runtime values
* Golang API for pluggable actions to modify processing pipeline as events flow through
* Rate-based sampling for sinks that can be overwhelmed

## Scenarios

With our guiding principles leading us to those tools, let’s diagram out a few simplified versions of scenarios we run on the new Auth0 platform.

### Application logs for incident response

In this scenario, we’re using [Fluent Bit](https://fluentbit.io/) to consume service logs from all pods within the Space Kubernetes cluster. They’re shipped to Kafka, where Data Shield consumes the raw log messages, applies its enforcement rules, and produces them back to Kafka. They’re consumed by Opensearch connectors, who ship them across the private link to the POP, where they’re accessible to Operations teams for incident response.

![Application logs for incident response](https://images.ctfassets.net/23aumh6u8s0i/5LkE9v6OyZJpJA85G1lJM7/1e3a523222efba8065f4359b47e456c4/Uploaded_from_Data_Pipelines_on_Auth0_s_New_Private_Cloud_Platform)

### Events for autocomplete search

In this scenario, we’re using Debezium to consume MongoDB change streams to emit events for Auth0 Users into Kafka. Data Shield consumes them, applies its enforcement rules, transforms the structure, and produces them back to Kafka. They’re consumed by another service that processes them and writes them into Postgres running in the same region.

![Events for autocomplete search](https://images.ctfassets.net/23aumh6u8s0i/6WCxg7eRdAuOdGm0MslthE/2886847192f02ae1b1c1cdef18514760/Uploaded_from_Data_Pipelines_on_Auth0_s_New_Private_Cloud_Platform)

### Event counts to a data lake

In this scenario, we’re using Debezium to consume the Postgres logical replication protocol to emit events for Auth0 Connections into Kafka. Data Shield consumes them, applies its enforcement rules, and ships them back to Kafka. They’re consumed by S3 connectors that ship them to an S3 bucket running in a different region.

![Event counts to a data lake](https://images.ctfassets.net/23aumh6u8s0i/4BlUDX70CAZfZ0wl1JOU39/5ce6cf28061d37de489e51bede949ea6/Uploaded_from_Data_Pipelines_on_Auth0_s_New_Private_Cloud_Platform)

### User requested backups 

In this scenario, we're emitting product events for Auth0 Tenants into Kafka. Prior to processing by Data Shield, they’re backed up in-region to object storage. The backups are then periodically rolled up and offered as a data download upon user request in a dashboard.

![User requested backups ](https://images.ctfassets.net/23aumh6u8s0i/6PzHrtwKWMgRzKsp7Hun2V/ee40263dbe880df9975304e07d517945/Uploaded_from_Data_Pipelines_on_Auth0_s_New_Private_Cloud_Platform)

## We’re Just Getting Started

Although these sample scenarios aren’t terribly complex, they really show the power of composability. We can mix and match a few Kafka connectors with Data Shield to meet the needs of our customers while providing the data controls we require. With more data-intensive use cases on the horizon needing stream processing and OLAP databases, this composability means our pipelines can easily evolve to support them. More importantly, even with a team experienced in stream processing and OLAP databases, we’ll still plan an R&D phase to make sure our choices once again align with our guiding principles.

Interested in hearing more about streaming joins, windowing, and OLAP databases? Well, you’ll have to wait for my next blog post then! Muahaha.

I would be remiss if I did not tell you that Auth0 (and specifically my team) are [hiring](https://auth0.com/careers)! Join me in building the next Auth0 data platform solving real problems for real people. Interested in solving problems for fake people instead? Visit the social network nearest you.

Data Pipelines on Auth0’s New Private Cloud Platform

Jon May

Jon May is a Principal Security Engineer at Auth0 where he is responsible for securing the platform and infrastructure of the Auth0 Identity Platform. He has over 10 years experience in cybersecurity and technology and holds a bachelor’s degree in economics from Brown University. Prior to joining Auth0, Jon was a Security Architect at Bridgewater Associates where he was responsible for designing and implementing cloud and enterprise security controls.

Principal Security Engineer, Platform Security

Architecting and building a new platform that is secure by design.

**TL;DR:** Auth0 replatformed our private cloud offering into a multi-cloud Kubernetes architecture. This large architectural change brings with it new threats and new security challenges. We took the opportunity to design and integrate security into the platform from the start, as opposed to "bolting it on" at the end.

In this post, we'll discuss how we approached securely replatforming the Auth0 Identity Platform into a large, multi-cloud architecture. We'll walk through the risks that most concern Auth0's Security team and the threats that could result in those risks becoming real, tangible, negative outcomes. After that, we'll discuss the challenges our team encountered while addressing those threats in a multi-cloud environment alongside the principles we applied to address them. Finally, we'll review the controls Auth0 put in place to mitigate the identified threats.

If you haven't read the previous posts yet, [A Technical Primer of Auth0's New Private Cloud Platform](https://auth0.com/blog/a-technical-primer-of-auth0-s-new-private-cloud-platform/) and [The Architect's View of Auth0's New Private Cloud Platform](https://auth0.com/blog/the-architect-s-view-of-auth0-s-new-private-cloud-platform/), I encourage you to check them out first. They provide foundational knowledge and context which will help you better understand this post. 

## Understanding What Risks Affect Us

At the highest level, Auth0's Security team is responsible for identifying, assessing, and mitigating risks to our business and, in effect, our customers. It's our job to reduce the impact and/or likelihood of undesirable business outcomes caused by security events. Specifically, we're interested in mitigating security and privacy risks, such as those involving:

1. **Product/platform compromises**: bad actors gaining control of a product or platform component
2. **Customer or Auth0 data loss**: unintended deletion or unauthorized access to customer or Auth0 data
3. **Service disruptions and outages**: disrupting the Auth0 service and causing an outage for our customers

There are more risks than the three listed above and more nuance as well, but we'll use them for brevity. These high-level risks help us enumerate our list of threats.

## Identifying How the Platform Will be Attacked

This new Kubernetes-native, multi-cloud architecture is large and complex, which makes it challenging to secure. Our approach is to start by enumerating the areas of the architecture most likely to be targeted and how they can be attacked. This process, called threat modeling, helps us determine where to focus our resources and implement countermeasures (also known as security controls). These "areas to focus on," or threats, are circumstances or events that could cause one of the risks highlighted above to occur.

![Platform](https://images.ctfassets.net/23aumh6u8s0i/3kEf7N3gMeLfxUtIOqqEZP/5a7ee4be2c16df0549cdf2528eb1749e/01_private_cloud.png)

The threat modeling process results in a long list of threats of varying severity. For the purposes of this post, we'll focus on a short list of significant ones:

1. **Employee account takeover**: an attacker compromises or gains access to employee credentials and utilizes them to access Auth0 systems
2. **Malicious insiders**: an internal employee abuses existing authorized access to Auth0 systems 
3. **Service or application compromise**: an attacker gains control of an Auth0 product or platform service, third-party managed service, or a cloud provider service
4. **Software supply chain compromise**: an attacker tampers with or exploits misconfigurations/vulnerabilities in software dependencies used by the Auth0 product or platform

This list of threats informs what secure design patterns and security controls we deploy into the platform's architecture.

## Securing Multi-Cloud Architecture is Hard

Now that we have defined the list of threats we're protecting against (the "what"), we can start determining the design changes, secure design patterns, and security controls that will address those threats (the "how"). But first, before jumping into that, let's take a step back and understand the challenges with securing a platform that utilizes multiple cloud providers. In Auth0's case, we use both Amazon Web Services (AWS) and Microsoft Azure.

### Increased complexity

Using multiple cloud providers increases the architecture's overall complexity. Each cloud provider has similar general capabilities such as computing, networking, storage, and logging. However, each cloud provider implements these capabilities in their own ways. What we end up with are multiple implementations of the same core capability, like virtual machines or blob storage. These nuances between cloud providers introduce complexities that are challenging to secure.

Let's use an example to illustrate these differences. The Auth0 product requires [blob storage](https://auth0.com/blog/azure-storage-introduction/), so let's compare AWS S3 and Azure Storage Accounts and only focus on the different access methods.

![AWS S3 and Azure](https://images.ctfassets.net/23aumh6u8s0i/6DKlibDUAMicDy2oQaUKez/a66838c5086a3e1203d513dc7c3d1eef/table.png)

Another example is AWS Security Groups (SG) vs. Azure Network Security Groups (NSG) and how each handles rule evaluation. AWS SG rules are additive (i.e., allow the superset of all applicable rules), while Azure NSG rules are assigned a priority value and evaluated in that order. These are only two examples of the many differences between AWS and Azure we accounted for in the new platform's architectural design. 

### Larger attack surface

Using multiple clouds means potentially securing multiple, similar services for each cloud provider, e.g., AWS S3 _and_ Azure Storage Accounts. The complexity mentioned above and an increased number of services result in a larger attack surface. Today, for instance, we need to secure two cloud service providers (AWS and Azure), and that means securing two sets of each cloud-specific service required to run Auth0. It also means our Detection and Response team needs to ingest and monitor multiple sets of cloud-specific log sources to properly monitor and investigate the activity. That's a large surface area to secure.

### Cross-cloud connectivity

Communication between services within the same cloud is straightforward. We simply need to use the cloud provider's own mechanisms, and it should "just work." However, there are different points in our new platform's architecture that require some form of communication between AWS and Azure. Network connectivity, for example, needs to be established between Azure Points-of-Presence (PoPs) and Auth0 Central (which runs in AWS). We don't have the ability to use either cloud's PrivateLink service in this scenario (which would be preferred). In another example, Azure Spaces need to upload usage metrics into Auth0 Central (AWS). In single cloud architecture, we could simply use Azure RBAC configured with the proper role assignments. However, that's not possible in this scenario; the Azure Kubernetes Service (AKS) cluster/pod will need to authenticate using AWS S3 authentication methods.

## Addressing Multi-Cloud Challenges

So far, we reviewed the risks Auth0 is most worried about, enumerated a short list of threats to help guide our security decision-making, and discussed some of the challenges Auth0 experienced securing a multi-cloud architecture. Next, let's walk through the principles we applied to determine how we address those threats in the context of those multi-cloud challenges.

### View all security-related decisions through a risk-based and threat-centric lens.

That means all secure design decisions or security controls implemented were directly related to the risk and threats we enumerated during the previous sections. Prioritization is key, and using this lens influences where we need to spend available resources and which countermeasures would be most effective.

### Apply secure design principles and integrate security into the platform early and often. 

The Auth0 Security team is involved throughout the product life cycle, from ideation to design to build to operation and finally to deprecation. We are heavily involved in the design and build phases. This is important because it's easiest to make architectural changes before the technology is built.

### Establish clear, enforceable trust boundaries.

These trust boundaries inform how we implement various countermeasures such as access controls. They also encapsulate areas of risk, making them easier to manage. For example, our development and production environments are completely isolated and separate from one another. Operators cannot use development access to affect any part of the production environment.

### Balance cloud-native and cloud-agnostic capabilities.

This is a tricky one because each has its own benefits and challenges. Cloud-native capabilities (e.g., AWS managed databases) are tightly integrated with the cloud provider, which means you'll get those integrations — like GuardDuty or Microsoft Defender — out-of-the-box. On the other hand, cloud-native services are tightly coupled to their cloud, and deploying them for _both_ AWS and Azure increases the complexity and attack surface (as we discussed above). Compare that to cloud-agnostic capabilities, which can provide a single pattern and enable a simpler architecture with less attack surface. However, integrating with cloud provider services tends to require more work or "glue" to stitch them together. For example, our Auth0 product consists of Kubernetes workloads (cloud agnostic). We use managed Kubernetes services (AKS and EKS), and it's very easy to use the same services across both clouds. That means less complexity (i.e., one change to the Auth0 product will be applied to both clouds) and less attack surface (i.e., one service to secure).

## Selecting the Right Set of Security Capabilities

Finally, let's review the various security capabilities Auth0 implemented into the new platform to address the threats and multi-cloud challenges mentioned above. In addition to our own security capabilities, Auth0 takes advantage of the cloud's shared responsibility model. The shared responsibility model allows us to focus on securing other areas of the platform instead of worrying about the underlying cloud service provider infrastructure.

### Cloud Governance

All Auth0 Spaces, PoPs, Central, and Control Plane technology stacks are isolated into their own AWS Account or Azure Subscription. This provides clean and clear resource isolation, especially for single-tenant Spaces. We used AWS Organizations to create an Organization Unit (OU) hierarchy based on environment and functionality and add each account to a specific OU. We used Azure Management Groups to create a similar hierarchy for Azure Subscriptions. The hierarchies we created enable scalable, granular access controls and policy enforcement; we grant access or apply policies (Azure Policy and AWS Service Control Policies) to specific Management Groups / OUs or Spaces. For AWS, we grant access based on OU conditions and assign SCPs to OUs. For Azure, we assign roles and policies scoped to specific Management Groups. The access and policies are then inherited by the intended accounts or subscriptions.

![Cloud Governance](https://images.ctfassets.net/23aumh6u8s0i/ovvm1JDueXMwiN8ZKQThA/8f1684125fcc76f224b5e9329d5aa0fb/02_private_cloud.png)

### Identity and Access Management

Auth0 was built to secure identities, so we leverage Auth0 + Okta to secure authentication and authorization to our platform tooling. We manage all cloud providers and support application access using a least privileged RBAC model. We also require Multi-factor authentication (MFA) for all operator access to the platform; this includes cloud providers and all supporting applications. Operators are required to use Azure Privileged Identity Management (PIM) - which provides just-in-time access - for any administrative activities. Azure AD Identity Protection identifies and blocks any risky Azure tenant sign-ins.

### Network Security

All single-tenant and multi-tenant Spaces are logically isolated from one another with no interconnectivity between them. This strong isolation drastically reduces an attacker's ability to pivot into other Spaces or PoPs and further their attack. We further restrict inbound connectivity to spaces by using AWS and Azure PrivateLink to connect outbound from Spaces to a PoP. All traffic is encrypted in transit using TLS 1.2+. This includes network traffic between all cloud services, Kubernetes pod-to-pod traffic, and Kubernetes cluster-to-cluster traffic. For some workloads, we utilize mutual TLS (mTLS). On the network edge, we protect against DDoS attacks on our infrastructure, identify and block bots, enforce rate limiting, and block malicious traffic with web application firewall (WAF) rules. Operators must use VPN to access platform infrastructure, adding another layer to our defense-in-depth strategy.

![Network Security](https://images.ctfassets.net/23aumh6u8s0i/2DQcFgwaIkylGFaN479rmz/4a28c57f312f42a25052f84ae788b7b1/03_private_cloud.jpeg)

### Data Protection

All data is encrypted at rest using AES-256 or better, and encryption occurs at multiple layers (e.g., disk, file, database, and application layers). All data in transit is encrypted using TLS 1.2+. Auth0 encrypts platform secrets using HashiCorp Vault and takes full advantage of Azure Key Vault and AWS KMS for encrypting data in cloud services.

![Data Protection](https://images.ctfassets.net/23aumh6u8s0i/1XOTfQ1STNV4y9rTo7FcHf/3fd90c1fd4c3317f63804562e892d5e5/04_private_cloud.png)

### Detection and Response

Auth0 monitors the platform using a combination of cloud services and our own monitoring tools. We take advantage of AWS GuardDuty and Microsoft Defender for Cloud in addition to our own tooling. Auth0 ingests a vast amount of AWS and Azure platform logs for all of the cloud services used by the platform. These logs are ingested into a security data lake and monitored with detections defined as code.

![Detection and Response](https://images.ctfassets.net/23aumh6u8s0i/3aH0JsipzpNkdNubtfYwWN/6123b09fe51ae344fd4537e777081a22/05_private_cloud.png)

### Kubernetes Security

The [4C's of Cloud Native security](https://kubernetes.io/docs/concepts/security/overview/) is a good framework to use when thinking through Kubernetes security. We are, in varying aspects, responsible for security in the clouds we're using, the clusters we're running, the containers running on those clusters, and the code running within the containers. Auth0 uses the managed Kubernetes services Azure Kubernetes Service (AKS) and AWS' Elastic Kubernetes Service (EKS). These offerings from Azure and AWS are security feature-rich. Our worker nodes meet Kubernetes CIS Level 1 Benchmarks. Cluster access is restricted to operators, and least privilege is enforced using specific RBAC roles. We use Kubernetes NetworkPolicy objects to restrict pod network ingress and egress to authorized sources and destinations.

![Kubernetes Security](https://images.ctfassets.net/23aumh6u8s0i/48mIINcAPiqFzHe39D2I53/eeb1592c93f41b01ed465d6abd7bf349/06_private_cloud.png)

### Vulnerability Management

Our build and deploy pipelines continuously scan our cluster, containers, and code for vulnerabilities. Our security capabilities include the usual controls: static application security testing (SAST) on both code and infrastructure-as-code, dynamic application security testing (DAST) on our application and API endpoints, and software composition analysis (SCA) on our software dependencies and containers. Cloud Security Posture Management (CSPM) tooling identifies and responds to cloud misconfigurations (e.g., publicly accessible S3 buckets). Patching is a foundational security control; we continuously upgrade our containers and software dependencies. In the shared responsibility model, Azure/AWS are responsible for building upgraded node images, and Auth0 is responsible for deploying the images to our nodes. We accomplish this by rebuilding our Kubernetes nodes with the latest image during each Auth0 product release cycle.

### Automation is a must

We are dealing with a scale that makes it impossible to configure all of these security capabilities manually. To address his challenge, the Auth0 Security team created an in-house service that automates AWS account and Azure subscription creation and configuration. Similar to a production line, when new Spaces and PoPs are needed, this service creates AWS accounts and Azure subscriptions to meet our strict security standards using predefined templates. It effectively "stamps out" completely configured new accounts/subscriptions on-demand. When the account or subscription is no longer needed, the service will remove all resources, revoke all access, and decommission it.

## Continuously Improving Auth0's Security Posture

All of this work has culminated into a more secure, scalable platform that continues to meet or exceed the many requirements needed to achieve ISO 27001/27018, SOC 2, PCI, STAR, and HIPAA compliance.

The threat landscape is ever-changing and constantly evolving. The Auth0 Security team's job is never done, and a core principle is a continuous improvement. There are always ways to mitigate more risk and enhance our security posture, and we continually investigate additional security capabilities to make our platform and product even more secure for our customers.

We are publishing a series of technical posts on how and why we re-platformed. They'll be linked at the bottom of this post as they publish and are also findable on our blog. If you have technical questions or ideas for future posts, please reach out to us via the [Auth0 Community](https://community.auth0.com/). (Our marketing team also tells us we would be remiss if we didn't include a link to talk to Sales, so that is [here](https://auth0.com/contact-us), too.)

<include src="asides/AboutAuth0" />

Securing Auth0's New Private Cloud Platform

leonardo

Leonardo is a Senior Software Architect at Okta, working on the new Auth0 platform and cutting-edge product features. He is a seasoned technical leader with 17 years of experience in a wide range of segments, from enterprise to SaaS systems. As an Apache committer, he has contributed to various open-source projects. He is a self-learner, passionate about new technology, and has spoken at several developer events.

Senior Software Architect

Leonardo Zanivan

Replatforming to enhance agility, productivity, scalability, reliability, and security.

**TL;DR:** Auth0’s private and public cloud offerings are converging on a single platform to deliver an increase in business agility, developer productivity, scalability, reliability, and security for our customers and Auth0 by using industry-leading tools and fully automated operations.

Initially, Auth0 evolved our public and private cloud offerings as separate platforms because we could go fast and innovate on the public cloud and then work through the greater performance, compliance, and control expected by our private cloud customers. But over time, this led to feature discrepancies and, frankly, just wasn’t that efficient to maintain, scale, or innovate.

So we began an ambitious replatforming project. How could we re-architect all of Auth0 into a single platform? Could we support deployments on both Amazon Web Services (AWS) and Microsoft Azure? What about increasing geo-failover options? And we needed to continue our 99.99% SLA across both public and private clouds.

Let’s not forget that private cloud customers may also require extra add-ons like data residency, private links, and dedicated performance. This post will walk you through our approach to rearchitecting Auth0 to address those challenges.

## The Convergence Starting Point

While both platforms worked exclusively on AWS cloud, the private cloud was not using cloud-native solutions. It had three tiers — Basic, Perf, and Perf+ — available as environment sizes. These were selected based on the number of users and requests per second, versus an elastic scalable public cloud environment shared by multiple customers. The main difference is that private deployment usefully isolated and dedicated resources in any region. In comparison, public deployment uses shared resources for multiple customers in specific regions (United States, Europe, Japan, and Australia).

Our public cloud saw new features delivered on a weekly basis, but due to limited automation, our private cloud required high-touch operations for upgrading to new releases that rolled out on a bi-weekly cadence. 

Requirements for private cloud deployments set it up as a superset of the public cloud offering that already guarantees a 99.99% SLA, with a track record of 99.99+% over the last three years. This was across three availability zones and a geo-failover for regional redundancy and availability.

But we knew we also wanted to include extra add-ons like private links, [PCI compliance](), and meet the customer requests for [Azure Cloud]() support.

## New Cloud-Native Architecture

On a high level, the new cloud-native architecture delivers an increase in business agility, developer productivity, scalability, reliability, and security for our customers and Auth0 by using industry-leading tools and fully automated operations.

It closes the gap between Auth0 public and private deployments by packaging all the product features in a single software version and making them available depending on the customer subscription and add-ons. 

The ideation for the new platform is based on the following premises:

* **Multi-cloud: **AWS and Azure cloud support through a common interface
* **Container orchestrated:** use of container images instead of installing packages
* **Stateless**: scalable and replaceable by design
* **Immutable**: run only trusted code and configuration
* **Fully automated:** provisioning, upgrades, and decommissioning are done by machines
* **GitOps:** enhanced DevOps, push code and safely reproduce it thousands of times  

This removes the worry about the underlying infrastructure, allowing Auth0 developers to place their focus on our customers. This can be represented by the layers in the box below:

![Aplication Layer](https://images.ctfassets.net/23aumh6u8s0i/3yX9TOMT8XC0UPPKK6N57h/41dbdb93833d8c2e20e7c2be1bb445ef/88133_Private_Cloud_Campaign_Auth0.png)

* **Infrastructure layer**: It builds the infrastructure using AWS and Azure cloud services such as networking, virtual machines, key management, load balancers, container repositories, Kubernetes, and managed datastores (Mongo, PostgreSQL, Redis, Kafka).
* **Interface layer**: [Terraform](https://www.terraform.io/) is used for bootstrapping the infrastructure using code on different clouds. [Vault](https://www.vaultproject.io/) is used for platform secrets management and [Kubernetes](https://kubernetes.io/) as de-facto technology for application runtime along with custom plugins to describe services manifest, configuration, and secrets using the platform control plane component. [Argo CD](https://argoproj.github.io/cd/) is a GitOps continuous delivery tool used for applying for new software releases while [Argo Workflows](https://argoproj.github.io/workflows) is used for orchestrating the provisioning, upgrades, and decommissioning steps. This layer also contains integrations and agents for managing service discovery/DNS, logs, metrics, security audit, and datastores.
* **Application layer**: It is where the containers run. The Auth0 Identity Platform is built to allow multiple stacks with different sets of containers deployed accordingly to their usage. Auth0 products, PoP, Control Plane, and Central Services use a promotion pipeline for validating new releases and configurable release schedules. Everything is managed by control plane API and developers interact with the new platform CLI or Hub (web interface). One might wonder how identity is managed to access Kubernetes resources, it uses [Pomerium with Auth0 Identity Provider](https://www.pomerium.com/docs/identity-providers/auth0.html), dogfooding our own product.

Before we go deep into the technical details, the blog [A Primer on the New Private Cloud Platform](https://auth0.com/blog/a-technical-primer-of-auth0-s-new-private-cloud-platform/) provides more details about the Space, PoP, Control Plane and Central components of the new platform.

## The Components—A Ten Thousand Foot View

The diagram below demonstrates the main components of the platform and its links, including data flows and cloud regions. Internal services and network details are omitted.

![The Components—A Ten Thousand Foot View](https://images.ctfassets.net/23aumh6u8s0i/2bmBmIoidTViCeyw2dInNB/26a1c8a5cd9ac8a556488585edbb35d4/Arquitecture.png)

**Edge Network**: The global network provider, used by Auth0 for DNS, edge computing, CDN, DDoS protection, web application firewall, custom domain certificates, and speed-up end-user experience.

**Space**: Customer environment containing the dedicated application and datastores resources, deployed in any cloud region, maintaining security and data residency through tight access control for operators. Datastores use dedicated private networks isolated from the applications. New application deployments spin a whole new application cluster containing the new version and then slowly switch the traffic using a 'canary deployment' strategy. In addition to that, 'Data Shield' component is responsible for receiving a variety of data such as application logs and then scrubbing it, removing any PII or sensitive information. Only the clean logs are ingested and clean data is forwarded to Auth0 data analytics and detection & response teams for monitoring the system. The customer data never leaves the cloud region (e.g. Azure EastUS).

**PoP**: Point of presence of the platform in a given cloud region (same as the Space), required to host the container registry of software stacks used by the Kubernetes cluster. This component runs a set of shared services to support the platform, including the OpenSearch stack used by operation engineers to troubleshoot issues. It also runs regional services, shared between Spaces to support platform operations, such as forwarding data analytics, and internal Auth0 system supporting services requiring low network latency for fulfilling requests. It is important to note though that PoP doesn't have access to the Spaces network, it acts as a regional endpoint.

**Central & Control Plane**: A region in the European Union (EU) where the control plane services are deployed. They are internal to Auth0 operators and are used to interact with the customer Spaces and PoPs. It is secured by Zero Trust model and manages platform secrets and metadata using Terraform, Vault, and Argo. In addition to the control plane services, the central component is also designed to run other completely isolated application stacks to host global services accessible by customers and support engineers.

**Auth0**: The analytics aggregated data is sent to Auth0 headquarters and other global systems such as DataDog and Snowflake to be consumed by internal teams in many different departments, such as business analytics, customer support, and engineering teams. The data is categorized into different levels of access and doesn't identify any customer-sensitive information such as personally identifiable information (PII). The Detection & Response team is an exception and runs security software to analyze production traffic and usage patterns to actively detect & mitigate attacks.

## High Availability and Geo-failover

Auth0 guarantees a 99.99% SLA for production deployments. On a high level, the infrastructure is fully redundant, and all components are deployed into multiple availability zones, using at least 3 availability zones (AZ) combined primary and secondary regions, either in clustered mode or standby replicas. 

For web applications, the traffic is distributed across multiple Kubernetes nodes using load balancing. For datastores, Mongo and PostgreSQL are considered the system of record, i.e. the authoritative source of data, deployed in the primary region with a writer and at least a reader node for splitting write/read traffic and replicating the data to a secondary (failover) region in real-time. The caching (Redis) and stream (Kafka) components are deployed using sharding and failover capabilities, always providing high availability for runtime and data.

As for central services, control plane, and PoPs, they also run on high availability infrastructure and have the ability to failover, while this process is executing or in case of temporary or permanent network connectivity issues, the Spaces continue functioning as expected without any disruption. Spaces are isolated from each other and are fault-tolerant to other tiers' failures. 

The geo-failover is a fully automated process and is manually triggered by an operator during incident response for disaster recovery in case a cloud region is fully or partially unavailable. The process redirects all the traffic to the secondary region (determined by the customer) which switches the DNS of the cluster ingress and promotes the secondary region replicas to become the primary writer; there's no dependency on the primary region for the disaster recovery to successfully execute. 

The target RPO (Recovery Point Objective) is less than a minute, the time period in which data and events can be lost due to the disaster recovery procedure. At the same time, the RTO (Recovery Time Objective) is less than 15 minutes for the amount of downtime tolerated during the disaster recovery process.

The process of failback (revert the failover) from the secondary to the primary region is the same and can be triggered once the situation resolves.

The diagram below shows the Auth0 deployment containing a primary and a secondary warm standby region with high available datastores, and for simplifying purposes other AZs running only applications are omitted:

![Azure servers](https://images.ctfassets.net/23aumh6u8s0i/7f96vQ2UJukSjYJYc5flNt/a406ca7bac6ad54dc5e2bfc75c754dd8/Azure_servers.png)

We are publishing a series of technical posts on how and why we replatformed. They’ll be linked at the bottom of this post as they publish and are also findable on our blog. If you have technical questions or ideas for future posts, please reach out to us via the [Auth0 Community](https://community.auth0.com/). (Our marketing team also tells us we would be remiss if we didn’t include a link to talk to Sales so that is [here](https://auth0.com/contact-us), too.)

The Architect’s View of Auth0’s New Private Cloud Platform

1Vitor de Sousa_Auth0

As Regional Vice President, Vitor de Sousa supports Okta and Auth0's German customers in achieving their Identity and Access Management goals. With more than 20 years of experience in the consumer goods industry, as well as in technology and software sales, he develops strategically smart and creative solutions for the interplay of identity authentication, customer experience, and data protection.

Regional Vice President, Enterprise Sales - Germany

Vitor de Sousa

The pandemic accelerated digitization initiatives, a robust CIAM solution can assist in an iterative migration to the cloud

In the DACH region, trust is everything, and one of the first places you can build consumer trust is your login experience. German consumers say their main frustrations with signing up to a new app or online service are having to fill in long login or sign-up forms (42%) and entering private information (38%), followed by having to create a password that has to meet certain requirements (33%), and a new ID and password for every app or online service (31%). These statistics come from a [global research study](https://info.auth0.com/erwartungen-und-realitat.html) conducted by Auth0 and YouGov, including more than 2,000 consumers and 200 IT/marketing decision-makers in Germany.

One of the challenges organizations encounter when looking to launch new services or feature sets is the fact that many of these features are cloud-based while existing services that could benefit from integration are often legacy and hosted on-premises. Finding an [Identity as a Service (IDaaS)](https://auth0.com/blog/what-is-idaas/) provider who can link those legacy systems and modern cloud-first platforms is an important step towards creating a future-proof service. However, many organizations in the DACH region are still building their own identity solutions. Or they’re misusing tools designed for managing employee identities for customer-facing needs. Both of these scenarios can introduce additional pain points when it comes to joining legacy and modern systems.

## Digitization Projects Are Resource Intensive

IT departments have spent the better part of the last 18 months establishing work-from-home protocols, migrating critical systems to the cloud for better access, and ensuring that everyone’s data stays safe and secure throughout the transition. Despite the acceleration in these digitization projects brought on by the COVID-19 pandemic, many of these systems have to remain housed on legacy on-prem servers due to a lack of alternatives. Bridging the gap between these and the convenient cloud-based tools your customers need access to is a large undertaking, especially for IT teams that are already stretched thin supporting ongoing internal needs.

Your IT and development teams support the organization’s goals by creating and maintaining the best web applications for your customers and by keeping your infrastructure running smoothly. That way, everyone, both inside and outside of the company, has the best experience possible. Partnering with an IDaaS provider like Auth0 will free those teams to continue focusing on their primary goals by taking the task of user authentication off their hands — and putting it in the hands of identity experts. This ensures your users get the CX they’ve come to expect while you maintain control over your data and privacy.

## Legacy Workforce Identity Solutions Are Not Built To Face External Threats

The workforce [Identity and Access Management (IAM)](https://auth0.com/blog/what-is-iam/) tool you’re using today may look like an attractive option for your customer-facing needs. There are several problems with this idea, starting with the simple fact that IAM solutions are not focused on user experience (UX). Their priority is security, keeping your company’s intellectual property safe and secure from bad actors. 

The threats facing customer applications can be vastly different in type and scale. Workforce IAM verifies employee identity in order to approve access to just the tools they need to do their job effectively, from primarily company-owned devices. [Customer Identity and Access Management (CIAM)](https://auth0.com/blog/what-is-ciam/#:~:text=Auth0%20Docs&text=Customer%20Identity%20and%20Access%20Management,%2C%20customer%20experience%2C%20and%20analytics.) solutions, on the other hand, need to integrate protection against brute force attacks, password spraying attacks, along with other outside attack vectors. And they need to do that while maintaining identity verification across potentially millions of end-user devices and networks. Additional hurdles exist as well; for example, many IAM tools are on-prem only and unable to protect your new cloud-first infrastructure. 

## Growing Demand From Consumers for a Low-Friction Customer Experience

The acceleration and growth of online tools have increased consumer expectations for a safe and simple identity experience. They’re no longer willing to wait for slow pages to load or to endure lengthy and complex account creation flows. Your customers demand-responsive, intuitive design, or they’ll take their business elsewhere. In fact, 78% of German consumers say they have [abandoned an app or online service](https://info.auth0.com/erwartungen-und-realitat.html) due to an arduous login experience.

Addressing the systemic issues that need attention to keep up with this demand will put additional stress on your internal teams, pulling their attention away from those core goals we discussed above. You don’t need to sacrifice your user experience in order to create a user-friendly and trusted authentication experience. Auth0 provides a secure platform with a variety of cloud deployment options, including [private cloud deployments on Microsoft Azure](https://auth0.com/blog/auth0-on-microsoft-azure-as-a-private-cloud-deployment-option/) or AWS infrastructure, and public cloud options using AWS facilities in multiple regions, including Frankfurt. Built by and for development teams, Auth0 is easily customizable to create exactly the low-friction experience your customers demand without sacrificing security and extensibility.

## Auth0 Lets You Find the Right Mix of Security, Privacy, and CX

We’ve discussed three pain points organizations in the DACH region are likely to encounter when looking to deploy a new identity and authentication solution across both legacy and cloud-based systems. The Auth0 Identity Platform has a robust feature set designed to address these challenges and any others you may encounter as you embark on your own identity project.

### Extensibility allows you to quickly adapt your digitization project

Auth0’s founders wrote the book on identity management at Microsoft while helping development teams remove barriers to building applications in the cloud. The Auth0 Identity Platform is designed with developers in mind, with multiple [extensibility](https://auth0.com/extensibility) points that allow you to configure the exact authentication flows you want.

### Exhaustive integrations mean you can bridge the legacy/cloud gap easily and iteratively

No matter what systems you have housed on-prem or on legacy infrastructure and what you have already migrated to the cloud, our [Application Programming Interfaces (APIs)](https://auth0.com/docs/api) and [Software Development Kit (SDK) libraries](https://auth0.com/docs/libraries) mean, you can use one CIAM solution to bridge the gap. That allows you the flexibility to continue your deployment iteratively, knowing that your customer experience won’t suffer any negative impacts as you migrate more services to the cloud on your own schedule.

We’re able to integrate with most existing cloud-based SaaS services via our APIs and SDKs but can also integrate with your on-premise environments as long as they’re accessible via API or otherwise. We are also up to date with the [General Data Protection Regulation (GDPR)](https://auth0.com/docs/compliance/gdpr) enacted by the European Union in 2018, so we can help and support our customers in meeting their compliance requirements.

Additionally, [Auth0 Marketplace](https://marketplace.auth0.com/) and [Actions](https://auth0.com/actions) provide access to a wide array of out-of-the-box integrations with most line-of-business software and services. That means you can quickly connect your CMS and ERP to your new web app, and your users won’t see any change in their experience as it’s serverless, so there won’t be any interruption to your services.

### No-, low-, and pro-code options for creating a low-friction user experience

Between the pre-configured integrations in [Auth0 Marketplace](https://marketplace.auth0.com/) and our low-code [Actions](https://auth0.com/actions) capability, your development team can easily customize Auth0 to meet your customers’ expectations for a secure and low-friction authentication experience. For even more control, we still offer pro-code customization, as always, via our JavaScript editor.

The ability to have all your identity needs up and running quickly means your team can focus on serving their primary functions. Your developers can continue delivering top-quality experiences for your customers, and IT support can maintain your internal employees’ work environment, no matter where they’re working from.

## Partnering With Auth0 Ensures a Secure, Customizable CIAM Experience

You can rely on the identity professionals at Auth0 to help:

* focus your development team on innovation
* deliver the identity experience consumers have come to expect
* protect customer data with a deployment option that works for your business

That’s how you deliver an excellent user experience without compromising security or privacy along the way. Read more about our [compliance and certifications](https://auth0.com/docs/compliance), then [reach out to an identity expert](https://auth0.com/contact-us) to continue the conversation about how partnering with Auth0 can help your organization. 




Bridging Legacy Systems and Digital Transformation with CIAM

maniish_jaiin

I am Manish and I am a Software Engineer by profession. I have been writing on Medium for a year now. I write majorly because it fulfills my desire to share my knowledge and gives me a creativity boost. 
I write on a variety of topics like Software Engineering, Tech, Programming, Developer Productivity, Apple Products, and a few more. I have worked at ThoughtWorks and BCG Digital Ventures and I am currently living in Berlin.

Software Engineer

Manish Jain

Learn how to process streams of data from Apache Kafka topics using Spring Cloud Streams

**TL;DR:** Have you ever wondered how features like Google Maps' live traffic work? These systems have to gather and process data in real-time. The architecture of these systems generally involves a data pipeline that processes and transfers data to be processed further until it reaches the clients. In this article, we will see something similar with a simple example using Kafka Streams. The sample app can be found [here](https://github.com/auth0-blog/spring-cloud-stream-sample).

## Introduction to Spring Cloud Stream

Spring Cloud Stream is a framework designed to support stream processing provided by various messaging systems like Apache Kafka, RabbitMQ, etc. The framework allows you to create processing logic without having to deal with any specific platform. It helps you build highly scalable event-driven microservices connected using these messaging systems.

The framework provides a flexible programming model built on already established and familiar Spring idioms and best practices. The way it works is simple; you have to provide implementations (called Binder implementations)for the messaging system that you are using. Spring cloud stream supports:

* [RabbitMQ](https://github.com/spring-cloud/spring-cloud-stream-binder-rabbit)
* [Apache Kafka](https://github.com/spring-cloud/spring-cloud-stream-binder-kafka)
* [Kafka Streams](https://github.com/spring-cloud/spring-cloud-stream-binder-kafka/tree/main/spring-cloud-stream-binder-kafka-streams)
* [Amazon Kinesis](https://github.com/spring-cloud/spring-cloud-stream-binder-aws-kinesis)

And a few others. The links above will take you to the binder implementations. In this article, we will look into a simple application that uses Kafka Streams as a stream processor listening to events on a topic, processing the data, and publishing it to the outgoing topic.

## Introduction to Apache Kafka

Apache Kafka is a distributed publish-subscribe messaging system. It is a system that publishes and subscribes to a stream of records, similar to a message queue. Kafka is suitable for both offline and online message consumption. It is fault-tolerant, robust, and has a high throughput. Kafka is run as a cluster on one or more servers that can span multiple data centers. The Kafka cluster stores stream of records in categories called topics. Each record consists of a key, a value, and a timestamp. For more information on topics, Producer API, Consumer API, and event streaming, please visit this [link](https://kafka.apache.org/intro).

## Introduction to Kafka Streams

Kafka Streams is a library that can be used to consume data, process it, and produce new data, all in real-time. It works on a continuous, never-ending stream of data. Consider an example of the stock market. The stock prices fluctuate every second, and to be able to provide real-time value to the customer, you would use something like Kafka streams.

## Pre-requisites:

1. Basic knowledge of [Java 11](https://jdk.java.net/archive/).
2. Basic knowledge of [Spring Boot](https://spring.io/projects/spring-boot).
3. A basic understanding of [Apache Kafka](https://kafka.apache.org/intro).
4. [Docker](https://docs.docker.com/get-docker/) and [Docker Compose](https://docs.docker.com/compose/install/) for running Kafka locally.

## Setting up Spring Boot App

Let us first create a Spring Boot project with the help of the [Spring boot Initializr](https://start.spring.io/#!type=mavenproject&language=java&platformVersion=2.4.5.RELEASE&packaging=jar&jvmVersion=11&groupId=io.pratik&artifactId=springcloudsqs&name=springcloudsqs&description=Demo%20project%20for%20Spring%20cloud%20sqs&packageName=io.pratik.springcloudsqs&dependencies=web,lombok), and then open the project in our favorite IDE. Select Gradle project and Java language. Last but not least, select Spring boot version `2.5.4`. Fill in the project metadata and click generate.

For Spring Cloud, We need to configure Spring Kafka and Kafka Streams in our `gradle.build`:

```groovy

dependencies {
 implementation 'org.springframework.boot:spring-boot-starter'
 implementation 'org.apache.kafka:kafka-streams'
 implementation 'org.springframework.kafka:spring-kafka'
}

```

Let's setup the config for Kafka. We need to define a few parameters on how we want to serialize and deserialize the data. The config is easy to set up and understand. Since our application will be listening to a topic and producing the output to a different topic, our application is a producer and a consumer both. So, we need to define config for both producer and consumer.

In the application.yml file, we need to add these entries.

```yaml

kafka:
 bootstrap-servers: localhost:9092
 properties:
 schema.registry.url: http://localhost:8081

 producer:
 client-id: ${spring.application.name}
 key-serializer: org.apache.kafka.common.serialization.StringSerializer
 value-serializer: org.apache.kafka.common.serialization.StringSerializer

 consumer:
 client-id: ${spring.application.name}
 group-id: ${spring.application.name}-group
 key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
 value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
 auto-offset-reset: earliest

 streams:
 client-id: ${spring.application.name}-stream
 application-id: ${spring.application.name}
 properties:
 default.key.serde: org.apache.kafka.common.serialization.Serdes$StringSerde
 default.value.serde: org.apache.kafka.common.serialization.Serdes$StringSerde

```

If you look at the config carefully, we are setting up serializers and de-serializers for the producer, the consumer, and the streams (serde is just short for serializer-deserializer). This is the only setup we need for the Spring boot project.

Let's jump into creating the producer, the consumer, and the stream processor. I have taken a simple example here. We are producing random numbers every 2 seconds using a scheduler.

```java

@Component
@AllArgsConstructor
public class NumberProducer {

 NumberPublisher numberPublisher;

 @Scheduled(fixedRate = 2000)
 public void produceIntStream() {
 Random random = new Random();
 numberPublisher.produce(random.nextInt(1000));
 }
}

```

The number publisher is the actual publisher that puts the data on a topic. We set a key for the message and the data (which is a random number in our case).

```java

@Slf4j
@Component
@AllArgsConstructor
public class NumberPublisher {

 private final KafkaTemplate<String, String> kafkaTemplate;

 public void produce(Integer randomNumber) {
 String s = "Odd";
 if (randomNumber % 2 == 0) s = "Even";
 System.out.println("Produced number: " + randomNumber);
 kafkaTemplate.send(INPUT_TOPIC_NAME, s, String.valueOf(randomNumber));
 }
}
```

The key is defined as a String, which is either even or odd based on the number. We use the Kafka template to send the message; this comes from the spring-kafka library. It abstracts out the logic for publishing and consuming the messages.

Next up, we set up our stream processor that listens to the topic on which the publisher is putting the messages. This is where it gets interesting. We listen to the `INPUT_TOPIC` and then process the data. In this case, the job of the stream processor is to filter out the odd numbers and only send the even numbers on the `OUTPUT_TOPIC`.

```java

@Configuration
@EnableKafkaStreams
public class KafkaStream {

 public static final String OUTPUT_TOPIC_NAME = "even-number-topic";
 public static final String INPUT_TOPIC_NAME = "number-topic";

 @Bean
 public KStream<String, String> evenNumbersStream(StreamsBuilder kStreamBuilder) {
 KStream<String, String> input = kStreamBuilder.stream(INPUT_TOPIC_NAME);

 KStream<String, String> output = input.filter((key, value) -> key.equals("Even"));

 output.to(OUTPUT_TOPIC_NAME);
 return output;
 }
}

```

You might be wondering about that KStream in the return type of our method. I will give a brief overview here as it is outside the scope of this article.

KStream -> A Kafka stream that is append-only. When you provide data with the same key, it will not update the previous record. It provides several operations that are very useful for data processing, like a filter, map, partition, flatMap, etc. You can read more about KStreams [here](https://www.confluent.co.uk/blog/introducing-kafka-streams-stream-processing-made-simple/).

Finally, when we have processed the data, we put it on an `OUTGOING_TOPIC`. For the sake of simplicity and completion, I am listening to that topic in our application. This generally will not be the case, as there would be another application that would be consuming from that topic and hence the name `OUTGOING_TOPIC`.

```java

@Component
@EnableKafka
public class EvenNumberConsumer {

 @KafkaListener(topics = OUTPUT_TOPIC_NAME)
 public void receive(String value) {
 System.out.println("Received number: " + value);
 }
}

```

The application code is complete. Let's set up Kafka locally.

## Setting up Kafka Locally

Setting up Kafka is easy, but it requires some dependency to run, you just need to use the docker-compose file below, and it will start the Kafka server locally. Add the `docker compose.yml` to the repository's root directory. Start the required dependency using: `docker-compose up`.

```yaml

version: '3.7'

services:
 kafka:
 image: confluentinc/cp-kafka:5.5.0
 container_name: kafka
 hostname: kafka
 restart: always
 environment:
 KAFKA_LISTENERS: LISTENER_DOCKER_INTERNAL://:29092,LISTENER_DOCKER_EXTERNAL://:9092
 KAFKA_ADVERTISED_LISTENERS: LISTENER_DOCKER_INTERNAL://kafka:29092,LISTENER_DOCKER_EXTERNAL://localhost:9092
 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: LISTENER_DOCKER_INTERNAL:PLAINTEXT,LISTENER_DOCKER_EXTERNAL:PLAINTEXT
 KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
 KAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_DOCKER_INTERNAL
 KAFKA_AUTO_CREATE_TOPICS_ENABLE: "true"
 KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
 ports:
 - 9092:9092
 - 9999:9999
 depends_on:
 - zookeeper

 zookeeper:
 container_name: zookeeper
 hostname: zookeeper
 image: confluentinc/cp-zookeeper:5.5.0
 environment:
 ZOOKEEPER_CLIENT_PORT: 2181
 ports:
 - 2181:2181

 schema-registry:
 image: confluentinc/cp-schema-registry:5.5.0
 hostname: schema-registry
 container_name: schema-registry
 restart: always
 environment:
 SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS: "kafka:29092"
 SCHEMA_REGISTRY_HOST_NAME: schema-registry
 SCHEMA_REGISTRY_LISTENERS: "http://0.0.0.0:8081"
 ports:
 - 8081:8081
 depends_on:
 - zookeeper

```

That's it!

## Verify Sending, Processing, and Receiving of Events

Run the Spring Boot app:

1. Clone the sample code from the repo. Go to the root directory.
2. Use the Gradle plugin to run your Spring Boot app using the command in the project directory.

```shell
./gradlew bootRun
```

Just run the application. You should see logs like this.

```shell
Received number: 910
Received number: 320
Received number: 16
Received number: 526
Received number: 76
Received number: 936
Received number: 642
Produced number: 510
Received number: 510
Produced number: 996
Received number: 996
Produced number: 897
```

## Conclusion

Spring Cloud Stream provides a simple and convenient way to create apps that can process streams and publish data to different topics. You can build micro-services that talk to each other using Kafka messages and process data like you would process in a single application.

In this article, we have learned how to build a Spring Cloud Stream app that uses Kafka Streams. We saw how Spring Cloud Stream provides an easy way to set up and run an application that can consumer, process, and publish messages to Kafka topics without the hassle of configuring each. With such little code, we could do so much.

You can refer to the repository used in the article on [Github](https://github.com/auth0-blog/spring-cloud-stream-sample).

Spring Cloud Streams with Apache Kafka

kaycie-east

As PR Manager, Kaycie supports public relations and global communications efforts for Auth0 in the AMER region. When not promoting the Auth0 brand, Kaycie can be found hiking, traveling, or searching for the next best bite to eat.

PR Manager, AMER Region

Kaycie East

New private cloud deployment option offers customers greater choice, scalability, and reliability

**BELLEVUE, Wash. – Oct. 13, 2021 –** The [Auth0 Identity Platform](https://auth0.com/), a product unit within Okta (NASDAQ: OKTA), today announced the launch of the [Auth0 Identity Platform on Microsoft Azure](https://auth0.com/cloud/azure). The launch gives customers the ability to choose Azure as their cloud deployment option from Auth0. The addition of Azure as an Auth0 private cloud platform option unlocks a secure cloud deployment option for organizations seeking strategic fit with their technology stack, supporting regional data residency capabilities and higher control over customer data.

Today, organizations moving to the cloud and selecting a [Customer Identity and Access Management (CIAM)](https://auth0.com/blog/what-is-ciam/) solution require significant control over sensitive customer data and may require local data residency capabilities. They often have to make a hard choice of selecting either a CIAM solution that supports their product differentiation goals or one that meets their technical requirements and regulatory needs. Auth0’s modern identity platform eliminates the need to choose by providing organizations with tools designed to support security, compliance, and data residency needs that may apply to them across multiple regions globally. The platform’s design can accelerate their time to value and go-to-market strategies to meet their long-term growth goals. 

Key benefits of the Auth0 Identity Platform on Azure include:

* **Technology Stack Alignment:** Organizations have the flexibility to choose Azure as their preferred cloud vendor for greater technology stack alignment with existing investments in Azure. 
* **Data Residency:** Improved data residency capabilities for Auth0 customers with Azure’s widespread geographic infrastructure.
* **Streamlined Experience with Private Cloud:** A modern, cloud-native platform built with a focus on security and compliance at every level. Organizations requiring data residency options can take advantage of periodic feature updates while maintaining control over the timing and the ability to roll back without the hassle of having to maintain them — resulting in faster time to market and a more seamless experience for organizations and their customers.

“As more applications move to the cloud and expand globally, organizations depend on their identity service to protect and manage access for their most critical users, applications, and data,” said Shiv Ramji, Chief Product Officer at Auth0. “The Auth0 Identity Platform on Azure can help unlock a secure and compliant cloud deployment experience for organizations seeking support across CIAM use cases. This is especially true for organizations in industries like retail or financial services where selecting vendors that are not competitive to their business is top priority, organizations operating in regions where certain cloud providers have higher geographic availability, and those that have existing technology investments in Azure.”

“Companies like Auth0 add value by integrating their solutions with Microsoft Azure,” said Mandana Javaheri, Global Senior Director, SCI Business Development at Microsoft Corp. “With Azure, Auth0 customers have ultimate performance capabilities and control over their environment without the hassle of maintaining it, allowing customers to focus more on their core business proposition.”

More detailed information on the Auth0 Identity Platform on Azure can be found on [Auth0’s blog](https://auth0.com/blog/auth0-on-microsoft-azure-as-a-private-cloud-deployment-option). Auth0 will discuss this offering in greater detail with Okta at Showcase21 taking place today, Oct. 13, 2021. To learn more, visit: [https://www.okta.com/showcase/register](https://www.okta.com/showcase/register) 

<include src="asides/AboutAuth0" />
### Media Contacts:

Global Communications 
Auth0 
[press@auth0.com](mailto:press@auth0.com) 

Matter Communications for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com) 

### Investor Contact:
Investor Relations 
[investor@okta.com](mailto:investor@okta.com)

Auth0 Identity Platform Now Available on Microsoft Azure

Learn how to simulate AWS services locally using LocalStack with a Spring Boot application.

**TL;DR:** This article demonstrates the use of LocalStack and how it can simulate many of the AWS services locally. We will use Spring Cloud Messaging to create a publisher-subscriber sample application. We will use Amazon SNS and SQS to do that.

The sample app can be found [here](https://github.com/maniish-jaiin/spring-cloud-messaging-sample).

## Spring Cloud Messaging With AWS and LocalStack

### Introduction

With an ever-growing demand for cloud services, Spring provides amazing support to integrate with Cloud providers and relevant services. [Spring Cloud for Amazon Web Services](https://spring.io/projects/spring-cloud-aws) is one such project that makes it easy to integrate with AWS services using familiar Spring APIs.

In this article, we will look into a simple application that acts as a message producer and a consumer using Amazon SNS and SQS. On top of that, we will not create an AWS account or use AWS services directly from AWS. We will instead use LocalStack, which will allow us to create AWS resources locally.

The sample app can be found [here](https://github.com/maniish-jaiin/spring-cloud-messaging-sample).

### Pre-requisites:

1. Basic knowledge of AWS, [AWS CLI](https://github.com/aws/aws-cli), and related services like Amazon SQS.
2. Basic knowledge of [Java 11](https://docs.oracle.com/en/java/javase/11/docs/api/index.html) and Spring Boot `2.4.7`.
3. [Docker](https://docs.docker.com/get-docker/) and [Docker Compose](https://docs.docker.com/compose/install/) for the setup.

## Introduction to Amazon SNS and SQS

### Amazon SNS

[Amazon SNS](https://aws.amazon.com/sns/) is an acronym for Simple Notification Service. It provides developers with the highly scalable, cost-effective, and flexible capability to publish messages from an application and send them to other applications. It follows the pub-sub architecture to deliver messages from publishers to the subscribers. It is a highly decoupled service that can be linked to a variety of sources. It can be used to publish emails, messages to SQS, SMS, etc.

The Publisher (e.g., CloudWatch Alarm, S3 events, SNS, Micro-service) publishes the message on a Topic which is then published to all the Subscribers (web servers, email addresses, Amazon SQS queues, AWS Lambda) of that particular topic.

![SNS Architecture](https://images.ctfassets.net/23aumh6u8s0i/35P87aEWHIcpTOQxYTGWbz/03840ff6c13fdc4a94552ec8188c131e/sns_architecture.jpg)

### Amazon SQS

[Amazon SQS](https://aws.amazon.com/sqs/) is an acronym for Simple Queue Service, and the names convey a lot as it is really simple to use as it is a fully managed service from AWS. It follows similar messaging semantics of the producer putting a message on the queue and consumer reading from it.

Once consumed, the message has to be deleted from the queue. Deleting is important because SQS assumes that processing can fail. To prevent that, after the consumer receives a message, it is hidden from the queue for a defined period of time, and after that, if it is not deleted, the message shows up in the queue again.

Both SNS and SQS are fully managed lightweight, easy-to-use APIs. You can use Amazon SQS and SNS to decouple and scale microservices, distributed systems, and serverless applications and improve reliability.

### Introduction to LocalStack

[LocalStack](https://github.com/localstack/localstack) is an open-source mock of the real AWS services. It provides a testing environment on our local machine with the same APIs as the real AWS services. We switch to using the real AWS services only in the integration environment and beyond. There are plenty of reasons to use LocalStack, few out of which are more important than others, such as:

1. The ability to play with AWS services without interacting with AWS. All developers love to get their hands dirty, and what better way to learn something than to try. Localstack allows you to play with S3, SQS, DynamoDB, SNS, and the list goes on.
2. The ability to test the applications in the local dev environment. You can write integration tests for your application using LocalStack, driving down your costs and increasing the confidence in your code.

### Spring Cloud Messaging app linked to LocalStack

Spring Cloud AWS provides [Amazon SQS](https://aws.amazon.com/sqs/) and [Amazon SNS](https://aws.amazon.com/sns/) integration that simplifies the publication and consumption of messages. It reduces a lot of boilerplate code and does the heavy lifting for configuring and SNS and SQS. Let's set up a Spring boot project with support for SNS and SQS.

#### Setting up Spring Boot app

Let us first create a Spring Boot project with the help of the [Spring boot Initializr](https://start.spring.io/#!type=maven-project&language=java&platformVersion=2.4.5.RELEASE&packaging=jar&jvmVersion=11&groupId=io.pratik&artifactId=springcloudsqs&name=springcloudsqs&description=Demo%20project%20for%20Spring%20cloud%20sqs&packageName=io.pratik.springcloudsqs&dependencies=web,lombok), and then open the project in our favorite IDE. Select Maven project and Java language. Last but not least, select Spring boot version `2.4.7`. Fill in the project metadata and click generate.

For Spring Cloud, We need to configure Spring Cloud AWS BOM in our `pom.xml` file using this dependencyManagement block:

```xml
<dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>io.awspring.cloud</groupId>
 <artifactId>spring-cloud-aws-dependencies</artifactId>
 <version>2.3.1</version>
 <type>pom</type>
 <scope>import</scope>
 </dependency>
 </dependencies>
</dependencyManagement>
```

For adding the support for messaging, we need to include the module dependency for Spring Cloud AWS Messaging into our Maven configuration. We do this by adding the starter module `spring-cloud-starter-aws-messaging`:

```xml
<dependency>
 <groupId>io.awspring.cloud</groupId>
 <artifactId>spring-cloud-starter-aws-messaging</artifactId>
</dependency>
```

These are the dependencies required for Spring Cloud AWS. Next, we add some other dependencies such as Spring boot starter web and [Lombok](https://projectlombok.org/).

```xml
<dependencies>
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
 <version>2.4.7</version>
 </dependency>
 <dependency>
 <groupId>org.projectlombok</groupId>
 <artifactId>lombok</artifactId>
 <version>1.18.20</version>
 <scope>provided</scope>
 </dependency>
</dependencies>
```

This completes our setup process for the Spring boot project.

Let's jump into adding the SNS and SQS configs and start publishing our first message.

Amazon SNS Config:

```java
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.client.builder.AwsClientBuilder;
import com.amazonaws.services.sns.AmazonSNS;
import com.amazonaws.services.sns.AmazonSNSClientBuilder;
import io.awspring.cloud.messaging.core.NotificationMessagingTemplate;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Primary;

import static com.authga.springcloudaws.config.AWSConfigConstants.ACCESS_KEY;
import static com.authga.springcloudaws.config.AWSConfigConstants.SECRET_KEY;

@Configuration
public class SnsConfig {

 @Bean
 public NotificationMessagingTemplate notificationMessagingTemplate(AmazonSNS amazonSNS) {
 return new NotificationMessagingTemplate(amazonSNS);
 }

 @Bean
 @Primary
 public AmazonSNS amazonSNS(final AwsClientBuilder.EndpointConfiguration endpointConfiguration) {
 BasicAWSCredentials credentials = new BasicAWSCredentials(ACCESS_KEY, SECRET_KEY);
 return AmazonSNSClientBuilder
 .standard()
 .withEndpointConfiguration(endpointConfiguration)
 .withCredentials(new AWSStaticCredentialsProvider(credentials))
 .build();
 }
}
```

Here, we create a simple `AmazonSNSClient` with a custom endpoint and credentials. Spring has an auto-configured `AmazonSNSClient`, but that requires valid AWS credentials and actual resources. We instead want to run our service locally with AWS resources using LocalStack. More on this later. Let's finish this setup.

Amazon SQS Config:

```java
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.client.builder.AwsClientBuilder;
import com.amazonaws.services.sqs.AmazonSQSAsync;
import com.amazonaws.services.sqs.AmazonSQSAsyncClientBuilder;
import io.awspring.cloud.messaging.config.QueueMessageHandlerFactory;
import io.awspring.cloud.messaging.support.NotificationMessageArgumentResolver;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Primary;
import org.springframework.messaging.converter.MappingJackson2MessageConverter;
import org.springframework.messaging.converter.MessageConverter;

import java.util.List;

import static com.authga.springcloudaws.config.AWSConfigConstants.*;

@Configuration
public class SqsConfig {

 @Bean
 public AwsClientBuilder.EndpointConfiguration endpointConfiguration() {
 return new AwsClientBuilder.EndpointConfiguration(ENDPOINT, EU_CENTRAL_1);
 }

 @Bean
 @Primary
 public AmazonSQSAsync amazonSQSAsync(final AwsClientBuilder.EndpointConfiguration endpointConfiguration) {
 BasicAWSCredentials credentials = new BasicAWSCredentials(ACCESS_KEY, SECRET_KEY);
 return AmazonSQSAsyncClientBuilder
 .standard()
 .withEndpointConfiguration(endpointConfiguration)
 .withCredentials(new AWSStaticCredentialsProvider(credentials))
 .build();
 }

 @Bean
 public QueueMessageHandlerFactory queueMessageHandlerFactory(MessageConverter messageConverter) {
 var factory = new QueueMessageHandlerFactory();
 factory.setArgumentResolvers(List.of(new NotificationMessageArgumentResolver(messageConverter)));
 return factory;
 }

 @Bean
 protected MessageConverter messageConverter() {
 var converter = new MappingJackson2MessageConverter();
 converter.setSerializedPayloadClass(String.class);
 converter.setStrictContentTypeMatch(false);
 return converter;
 }
}
```

In the code above, we did the following:

- Similar to the `AmazonSNSClient`, we create the `AmazonSQSClient` with a custom endpoint and credentials.
- Setup `QueueMessageHandlerFactory` so it can convert incoming messages from SQS as String to the actual object we want, in this case, `Event`, using a `MessageConverter`.
- The converter will take care of converting the `String` message to the actual `Event` object.

The `Event` model is described below. I am using [Lombok](https://projectlombok.org/) to reduce the boilerplate code.

`Event.java`

```java
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class Event implements Comparable<Event> {
 private String eventId;
 private String version;
 private String occurredAt;
 private EventData data;

 @Override
 public int compareTo(Event o) {
 int otherVersion = Integer.parseInt(o.getVersion());
 int thisVersion = Integer.parseInt(this.getVersion());
 return Integer.compare(thisVersion, otherVersion);
 }
}
```

`EventData.java`

```java
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class EventData {
 private String orderId;
 private String owner;
 private EventType eventType;
}
```

`EventType.java`

```java
import java.io.Serializable;

public enum EventType implements Serializable {
 ORDER_CREATED, ORDER_CANCELLED
}
```

Producer code:

```java
import com.authga.springcloudaws.model.Event;
import io.awspring.cloud.messaging.core.NotificationMessagingTemplate;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import static com.authga.springcloudaws.config.AWSConfigConstants.ORDER_CREATED_TOPIC;

@Slf4j
@Service
public class SimpleMessageProducer {

 @Autowired
 private NotificationMessagingTemplate notificationMessagingTemplate;

 public void publish(Event event) {
 notificationMessagingTemplate.convertAndSend(ORDER_CREATED_TOPIC, event);
 }
}
```

- We use the `NotificationMessagingTemplate` created in the config above. It gives us several methods to send messages on an SNS topic. We will use the default `convertAndSend()` method that takes care of converting our object to a Message using the `MessageConverter` that we provide in the `SqsConfig` class.

Consumer code:

```java
import com.authga.springcloudaws.model.Event;
import io.awspring.cloud.messaging.config.annotation.NotificationMessage;
import io.awspring.cloud.messaging.listener.SqsMessageDeletionPolicy;
import io.awspring.cloud.messaging.listener.annotation.SqsListener;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;

import static com.authga.springcloudaws.config.AWSConfigConstants.ORDER_QUEUE;

@Slf4j
@Controller
public class SimpleMessageConsumer implements MessageConsumer {

 @Override
 @SqsListener(value = ORDER_QUEUE, deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS)
 public void consume(@NotificationMessage Event event) {
 if (event != null) {
 log.info("Received order event for consumer 1: " + event);
 }
 }
}
```

- We only need `@SqsListener` annotation that automatically makes our consume method get the messages from the queue.
- We also add `@NotificationMessage` annotation to have the correct deserialization and extract our Event from the SNS message because the SNS message is wrapped inside a `Message` object.

### Setup LocalStack and create resources

Setting up LocalStack is dead simple; you just need to use the docker-compose file below, and it will start SNS and SQS services locally. Add the `docker compose.yml` to the repository's root directory. Start the LocalStack using: `docker-compose up`.

```yaml
version: '3.0'

services:

 localstack:
 image: localstack/localstack:latest
 environment:
 - AWS_DEFAULT_REGION=eu-central-1
 - EDGE_PORT=4566
 - SERVICES=sqs,sns
 ports:
 - '4566:4566'
```

Once it is up and running, we can create the required AWS resources. We will create one SNS topic to which two SQS queues will be listening. The code to or publishing and listening is simple. Go to your command line, e.g., terminal, and execute the following commands.

To create the topic:

```shell
aws --endpoint-url=http://localhost:4566 sns create-topic --name order-created-topic
```

To create the queues:

```shell
aws --endpoint-url=http://localhost:4566 sqs create-queue --queue-name order-queue
aws --endpoint-url=http://localhost:4566 sqs create-queue --queue-name order-queue-2
```

To subscribe the queues to the topic:

```shell
aws --endpoint-url=http://localhost:4566 sns subscribe
--topic-arn arn:aws:sns:eu-central-1:000000000000:order-created-topic
--protocol sqs
--notification-endpoint arn:aws:sqs:eu-central-1:000000000000:order-queue

aws --endpoint-url=http://localhost:4566 sns subscribe
--topic-arn arn:aws:sns:eu-central-1:000000000000:order-created-topic
--protocol sqs
--notification-endpoint arn:aws:sqs:eu-central-1:000000000000:order-queue-2
```

To verify you can list queues and subscriptions:

```shell
aws --endpoint-url=http://localhost:4566 sqs list-queues
aws --endpoint-url=http://localhost:4566 sns list-subscriptions
```
That's it!

### Verify sending and receiving of events

Run the Spring Boot app:

1. Clone the sample code from the repo. Go to the root directory.
2. Use Maven plugin to run your Spring Boot app using the command in the project directory.

```shell 
mvn spring-boot:run
```

The groundwork is complete now. With the app running, we can send messages to the Amazon SNS Topic and read those messages from the queues. In the repo, I have created a controller to trigger the publishing of events. If you download the sample app, you should be able to run it, and going to [http://localhost:8080/create-order](http://localhost:8080/create-order) will trigger the publisher, which in turn will trigger the consumers. In the application logs, you should be able to see. This means that our producer code publishes the code to the SNS topic. The two queues that are subscribed to the topic receive those messages, and finally, the consumer receives those messages and prints the event.

```
Received order event for consumer 1:
Event{eventId='386cca76-3669-4d36-b2db-01f388bbce5f', version='0',
occurredAt='2021-06-19T13:42:32.946781Z', data=EventData(orderId=9a002b95-f10b-428e-8d39-cae90d1e631d,
owner=SampleProducer, eventType=ORDER_CREATED)}

Received order event for consumer 2:
Event{eventId='386cca76-3669-4d36-b2db-01f388bbce5f', version='0', occurredAt='2021-06-19T13:42:32.946781Z',
data=EventData(orderId=9a002b95-f10b-428e-8d39-cae90d1e631d, owner=SampleProducer, eventType=ORDER_CREATED)}
```

## Conclusion

LocalStack provides a simple and convenient way to simulate AWS services without having an actual AWS account. You can build applications using various AWS services like Amazon SNS, SQS, S3 DynamoDB, and many more.

In this article, we have learned how to build a Spring Cloud Messaging app that utilizes LocalStack. We saw how Spring Cloud Messaging provides a layer of abstraction to create an Amazon SQS listener and SNS publisher with just a few lines of code. Furthermore, we saw how to use Amazon SNS and SQS to create an event-driven application.

You can refer to the repository used in the article on [Github](https://github.com/maniish-jaiin/spring-cloud-messaging-sample).

Spring Cloud Messaging With AWS and LocalStack

adam-nunn

I'm a security and compliance professional with a passion for emerging cloud technologies. I specialize in risk, privacy regulations, and industry-standard security frameworks.

Sr. Director of Governance, Risk, and Compliance

Adam Nunn

If your organization stores customer data in the cloud, SOC 2 compliance is table stakes.

In the last two years alone, cloud-based cyberattacks[ more than doubled](https://www.trustwave.com/en-us/resources/library/documents/2020-trustwave-global-security-report/) — even though SaaS spending[ grew just 18%](https://www.statista.com/study/31317/software-as-a-service-statista-dossier/). 

While these numbers are merely a correlation from a statistical standpoint, it does indicate that if your business stores customer data in the cloud, it’s more important than ever for your business to take measures to secure that data. Especially given SaaS spending is[ expected to increase an additional 36%](https://www.statista.com/study/31317/software-as-a-service-statista-dossier/) between 2020 and 2022. 

A SOC 2 certification from the AICPA is a foundational step that will help every service provider reduce security risks. Below is a guide to SOC 2 compliance requirements and certification.

## What Is SOC 2?

SOC 2 is an independent audit report that evaluates the security controls a tech service business uses to protect the data they process in the cloud. Possession of a SOC 2 report is considered table stakes in the SaaS industry, as the answers to most security questions a customer may have about their business’s security posture can usually be pulled from this report.

### SOC 1 vs. SOC 2 vs. SOC 3

“SOC” stands for “System and Organization Controls” and was created by the American Institute of Certified Public Accountants (AICPA). SOC 2 is one of three SOC reports, each with different purposes and/or levels of transparency:

1. **SOC 1.** Used to audit internal controls relevant to a customer’s financial systems. Report usage is “restricted,” meaning its use is limited to auditors, the service organization, and authorized users.
2. **SOC 2.** Used to audit the overall management of customer data. Report usage is also “restricted” the same way SOC 1 is.
3. **SOC 3.** The same as SOC 2, but the report is simplified and publicly available to increase transparency.

![What Is SOC 2](https://images.ctfassets.net/23aumh6u8s0i/5LsphelbdnIZtLBd7NOrZQ/3e05f625deb2ff6588f9bffbf2dc3449/sep_compliance_02.jpg)

## Why SOC 2 Compliance Matters

SOC 2 compliance isn’t a legal requirement for a tech business. However, having a SOC 2 report is a common compliance objective for service providers that store their customers’ data in the cloud because it’s a necessity from an assurance (and therefore[ competitive](https://www.forbes.com/sites/forbesbusinesscouncil/2019/10/09/using-cyber-security-as-a-competitive-advantage/?sh=260c85237ff7)) perspective.

For many small to medium-sized operations that store marginally-sensitive data (for example, information that’s already publicly available), a SOC 2 report usually provides enough assurance of their controls and procedures to their customers. 

However, for businesses whose data is considered[ sensitive](https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/legal-grounds-processing-data/sensitive-data/what-personal-data-considered-sensitive_en) (health data, for example), a SOC 2 report is the minimum a business should have in order to assure their customers they’ve taken steps to protect their data.

![Why SOC 2 Compliance Matters](https://images.ctfassets.net/23aumh6u8s0i/2gAtMudqliW2LiC3h7imD9/db7be0b8025f315b137a7744e7d5d469/sep_compliance_03.jpg)

## The SOC 2 Certification Process

SOC 2 certification is completed by a third-party auditor who assesses the extent in which service provider’s controls comply with one or more of SOC’s five Trust Services Criteria (TSC): Security, Privacy, Confidentiality, Processing Integrity, and Availability.

SOC 2 is different from other security certifications because it lets each business decide how best to implement the SOC 2 framework. The auditor evaluates how well the business has implemented controls relative to each of the TSC and its operations and gives their opinion of overall effectiveness.

The auditor then compiles their opinion and findings into a report (the SOC 2 Report) you can then use to assure your customers of the steps you’ve taken to manage their data.

The SOC 2 Report comes in two different types (Type 1 and Type 2), and each has an impact on how the certification process proceeds. However, since each requires an evaluation of your practices against the five Trust Services Criteria (TSC), we’ll address those first and explain how each of the report types affects certification in more detail afterward.

### SOC 2 Trust Services Criteria

Tech service businesses can choose to certify in as many or as few of the TSC as they like. Most businesses choose to earn a certification for one to three of the criteria. However, businesses that process sensitive data will benefit from earning certification in all five.

Below is what earning certification in each of the SOC 2 Trust Services Criteria entails:

1. **Security.** An evaluation of both the electronic and physical controls a business uses to protect the customer data they process. Auditors will examine security measures, like, network security, vulnerability management, and security monitoring, as well as the steps you’ve taken to secure any access to the physical devices and locations your customers’ data, is stored on in order to prevent unauthorized access.
2. **Privacy.** An evaluation of how a service business collects and uses customer data. Auditors will compare a company’s privacy policy(ies) to the actual operational procedure(s) to ensure they’re in alignment with the AICPA’s Privacy Management Framework ([PMF](https://www.aicpa.org/interestareas/informationtechnology/privacy-management-framework.html)).
3. **Confidentiality.** An evaluation of how data is stored, accessed and shared. Auditors will examine the procedures and access controls you have in place to restrict who has access to customer data, as well as any technical measures, like encryption, you’ve implemented to keep data safe.
4. **Processing Integrity.** An evaluation of your quality assurance and processing-monitoring practices. Auditors will examine whether data is called from your servers in the same state it was stored — and that it’s only called for the people who are authorized to access it.
5. **Availability.** An evaluation of whether your customers have access to your system as outlined in their contractual agreement(s). Auditors will examine controls and procedures-performance monitoring, business continuity, disaster recovery, and incident management to ensure they match what was promised.

![SOC 2 Certification Process](https://images.ctfassets.net/23aumh6u8s0i/3lefYYa9FsqqIVecGGpIlV/88a934fa5d9dbb876787096be7536747/sep_compliance_04.jpg)

## The SOC 2 Report

Once an auditor completes their evaluation of the security measures you’ve implemented, you’ll receive either a SOC 2 Type 1 Report or a SOC 2 Type 2 Report (depending on which you chose to certify for). Both reports contain an explanation of everything you’ve done to keep your customers’ data safe:

1. The controls you’ve implemented
2. How they align with the Trust Services Criteria
3. An explanation of your company’s operations
4. How the auditing process was conducted
5. How you’ve implemented controls to secure the user environment

However, the differences between each report type mean that obtaining a SOC 2 Report can create a substantial increase in the effort and work required to comply.

### SOC 2 Type 1 Report

A SOC 2 Type 1 Report is an evaluation of the design of your controls at a specific moment in time. This means the certification process required for a Type 1 Report can occur relatively quickly (in the time it takes for an auditor to evaluate your systems and procedures).

### SOC 2 Type 2 Report

A SOC 2 Type 2 Report is an assessment of the operational effectiveness of your controls. The evaluation is done over a period of time to observe how effective those controls are in practice instead of just at one specific moment, as in a Type I Report.

A SOC 2 Type 2 Report typically requires months of auditing to obtain. But the increase in assurance it provides is often worth it for service organizations that process sensitive data. Traditionally a SOC-2 Type 2 covers a 6-12 month period. 

![Additional Security Certifications That Are Worth Pursuing](https://images.ctfassets.net/23aumh6u8s0i/Xb8Z3o1JWLQE9ZlM2vcQw/303397e92ee5a143b23112d7f055e4cb/sep_compliance_01.jpg)

## Additional Security Certifications That Are Worth Pursuing

A SOC 2 Report helps you demonstrate a baseline of security to your customers, and the more Trust Service Criteria you certify for, the more assurance you can provide (it’s why Auth0 meets all 5). 

But given[ the rate](https://www.mcafee.com/enterprise/en-us/assets/reports/rp-cloud-adoption-and-risk-report-work-from-home-edition.pdf) at which cloud-based cyberattacks are increasing in the wake of the pandemic (and[ the average cost of a data breach](https://auth0.com/blog/what-is-data-security/) across most industries), doing more than the minimum to secure your customers’ data is in your best interest.

Auth0 has earned certifications in several additional information security frameworks for this reason. We’ve created guides to earning certification with the ones we’re experienced with via the links below:

* **[ISO/IEC 27001](https://auth0.com/blog/auth0-achieves-iso-27001-certification/).** The International Organization for Standardization’s framework for building an information security management system (ISMS).
* **[ISO/IEC 27018](https://auth0.com/blog/what-is-iso-27018-2019-everything-executives-need-to-know/).** The International Organization for Standardization’s cloud-specific controls that cloud-based businesses should follow when certifying for ISO 27001.
* **[CSA STAR](https://auth0.com/blog/the-csa-star-program-a-business-guide-to-certification/).** The Cloud Security Alliance (CSA) offers some of the most relevant and cutting-edge controls for cloud security in the industry.

Learn more about how Auth0’s IDaaS platform can help you better secure and scale your authentication process[ here](https://info.auth0.com/video-platform-overview.html?_ga=2.10769394.753376883.1611345990-439625938.1611345989).

SOC 2 Compliance and Certification: What SaaS Businesses Need to Know

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

Nearly zero downtime now standard for Enterprise customers

**BELLEVUE, Wash. – March 3, 2021 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced its 99.99% availability service level agreement (SLA) guarantee for authentication services across all [Auth0 cloud](https://auth0.com/cloud) deployments&mdash;shared and dedicated environments. With private cloud deployments already supporting ‘four 9s’ availability, this SLA now extends to Auth0 public cloud deployments, making 99.99% a reality for all enterprise customers. 

Auth0 authenticates and authorizes more than four billion logins per month, demonstrating the scale at which its global customers operate. Whether authenticating consumers, business partners, or employees, reliability and uptime are crucial for every application&mdash;even more so for those with a continuously high volume of traffic. Any kind of downtime in high-demand applications can severely impact revenue, productivity, and brand perception. 

“We deeply understand how critical Auth0’s identity management platform is for the success of our customers’ businesses,” said Shiv Ramji, Chief Product Officer. “The 99.99% availability guarantee across all cloud deployments gives current, and future customers added reassurance of superior reliability and security, and an optimal end-user experience for all of their applications.” 

Auth0 continues to invest in improving the resilience of its platform and the reliability of its application services. While 99.99% is now a guarantee for customers on Auth0’s enterprise plan, platform uptime across Auth0’s U.S. public cloud environments in the past 12 months has been 99.999%+, or five 9s, as seen here: [https://status.auth0.com/](https://status.auth0.com/). 

More information about this reliability standard and Auth0’s cloud deployment options can be found here: [https://auth0.com/cloud](https://auth0.com/cloud). 

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

Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com)

Auth0 Guarantees 99.99% Availability on Public Cloud

Global identity management provider recognized as a top IT cloud management product

**BELLEVUE, Wash. – Feb. 17, 2021 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced that it was recognized on G2’s Best Software for 2021 list. The list ranks software companies and products based on G2’s thorough vetting process of verified user reviews of groups of similar products. Auth0 ranked #13 on the ‘[IT Cloud Management Products](https://www.g2.com/best-software-companies/top-it-management)’ list, based on its high levels of G2 user ratings for customer satisfaction and likeliness to recommend. 

G2 created the list based on data from over one million authentic, verified customer reviews. Winners were determined based on reviews left at G2.com between Jan. 1, 2020, and Dec. 31, 2020. All scores were calculated using G2’s algorithms, including for Satisfaction and Market Presence, explained in detail [here](https://www.g2crowd.com/static/g2_grid_scores). 

“Identity is essential and is a long-term business enabler&mdash;we are proud to help our customers around the globe meet their identity management and security goals by providing a trusted, extensible way to handle identity,” said Holly Files, SVP of Customer Success at Auth0. “We are grateful for our customers’ feedback and G2’s recognition of Auth0, and are honored to be recognized on the list along with companies like Amazon, Hashicorp Terraform, and IBM.”

“This isn’t a subjective list based on a few peoples’ opinions,” explains G2 CEO Godard Abel. “With the highest traffic and engagement, largest selection of products and services, and highest quality data, G2 analyzes more than four million data points to determine which products and companies make the list.”

Auth0 is a G2 Leader ranking in five categories: [Customer Identity and Access Management (CIAM)](https://www.g2.com/categories/customer-identity-and-access-management-ciam), [Identity Access Management (IAM)](https://www.g2.com/categories/identity-and-access-management-iam), [Single Sign On (SSO)](https://www.g2.com/categories/single-sign-on-sso), [User Provisioning and Governance](https://www.g2.com/categories/user-provisioning-and-governance-tools), and [Multi-Factor Authentication (MFA)](https://www.g2.com/categories/multi-factor-authentication-mfa). Learn more about what real users have to say (or leave your review of Auth0) on G2’s [Auth0](https://www.g2.com/products/auth0/reviews) review page.

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

Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com)

Auth0 Ranked on G2’s 2021 Best Software Companies List

Learn how ISO 27018 controls help cloud service providers reduce security risks for personal data.

ISO 27018 is the first international standard created specifically for [data privacy](https://auth0.com/blog/data-privacy-101/) in cloud computing. Its main objective, according to the [International Organization for Standardization (ISO)](https://www.iso.org/standard/76559.html), is to establish “commonly accepted control objectives, controls, and guidelines for implementing measures to protect Personally Identifiable Information (PII).”

ISO 27018 is part of the ISO 27000 family of standards, which define best practices for information security management. ISO 27018 adds new guidelines, enhancements, and security controls to the ISO/IEC 27001 and ISO/IEC 27002 standards, which help cloud service providers better manage the data security risks unique to PII in cloud computing.

Although ISO 27018 is not a law, there are a number of benefits to following its guidelines and earning certification (more on this below). And since [the standard isn’t free](https://www.iso.org/standard/76559.html) to the public, we’ve combed through it to help you make intelligent decisions on compliance and certification.

Below are the most important things you need to know about ISO 27018 and why it’s a good idea to follow.

## Version “2019” vs. “2014” - What’s New?

ISO 27018 was first created in 2014 (ISO/IEC 27018:2014) and was last revised in 2019 (ISO/IEC 27018:2019). The differences between the two versions are minor and do not change the best practices for protecting PII in cloud computing and public cloud applications in any major way.

As ISO states in Section 2 of the 2019 version, “This second edition cancels and replaces the first edition (ISO/IEC 27018:2014).” It goes on to explain that the revisions are primarily to correct an editorial mistake in Annex A.

However, **one noteworthy revision to point out**, from a certification standpoint, is that ISO 27018 is no longer referred to as a “standard” within the document itself. Instead, the latest revision replaces all mentions of “standard” with the word “document.”

In plain English, that means **ISO 27018 is now considered a set of guidelines and controls that enhance ISO 27001** (the standard for building an information security management system or ISMS), rather than a standard for organizations to certify against.

Cloud service providers should instead certify against ISO 27001 using 27018 guidelines in the event that they process PII.

## Why ISO 27018 Compliance Is Beneficial

[A study by PWC](https://www.pwc.com/us/en/services/consulting/library/consumer-intelligence-series/cybersecurity-protect-me.html) found that “85% of consumers will not do business with a company if they have concerns about its security practices.” Simply put, ISO 27018 compliance is a competitive advantage for both cloud service providers and their customers:

* **For cloud service customers**: If you can show consumers that their data is protected by comprehensive PII protection standards (by working with cloud service providers that follow ISO 27018), they’ll be more likely to do business with you.
* **For cloud service providers**: If you’re ISO 27018-compliant, it makes it easier to close deals with prospective customers because you can say, “We follow the most comprehensive data controls.”

Here are four additional ways ISO 27018 compliance benefits businesses.

### 1. Improved Global Operations

Since ISO 27018 is an extension of ISO 27001, it’s part of an internationally recognized standard. That means it’s easier for cloud service providers to provide assurances on their security practices if they’re doing business globally, as the standard is recognized in most countries.

_**Note**: Following ISO 27018 will streamline cloud privacy in many instances, given its global acceptance. However, it’s always important to consult a data privacy attorney skilled in the laws of the specific country you’re trying to do business in to ensure that you’re compliant._

### 2. Improved Security And Legal Protection

Earning the ISO 27001/27018 certification is an important part of establishing a baseline of security for any business that processes data in the cloud. Simply put, following these standards helps you reduce security risk since they are recognized as some of the comprehensive in cloud computing applications.

Implementing ISO 27018 controls and earning a certification also helps protect your business against charges of negligence or recklessness in the event that a breach was to occur.

Negligence charges can often incur more severe penalties ([as Equifax found out in 2019](https://www.theverge.com/2019/7/22/20703497/equifax-ftc-fine-settlement-2017-data-breach-compensation-fund)). But if a business is using a well-defined, risk-based approach to protect users’ personal data, it not only decreases the likelihood of a breach, but that also evidences a company’s focus on security.

The same goes for customers of cloud service providers. Working with ISO 27001/27018-certified cloud providers shows regulators you’re taking important steps to protect your users’ personal data.

### 3. Streamlined Sales Processes

Corporate security is a major friction point for a lot of IT sales deals. ISO 27018 helps reduce that friction because it simplifies the amount of information required for corporate security to sign off.

Instead of a long drawn out inquisition or questionnaire from prospective customers, an ISO 27001/27018 certified cloud service provider can simply have their customers review their Statement of Applicability (a list of in-scope security controls and implementation) to provide them the assurances they need to close the deal.

### 4. Better Security For A Postpandemic World

Cloud computing usage is rising at a significant rate ([spending is up 37% in 2020](https://www.pwc.com/us/en/industries/tmt/library/covid19-cloud-infrastructure.html), according to PwC) due to an [increase in remote work](https://news.gallup.com/poll/321800/covid-remote-work-update.aspx) as a result of COVID-19. This increase has also led to an increase in cyberattacks across the globe, according to [Interpol](https://www.interpol.int/en/News-and-Events/News/2020/INTERPOL-report-shows-alarming-rate-of-cyberattacks-during-COVID-19) and the [U.S. Chamber of Commerce](https://www.uschamber.com/series/above-the-fold/the-evolution-of-cybersecurity-threats-during-covid-19-and-what-you-can-do).

However, while many workers have already returned to the office, as of the end of 2020, [a survey by PwC](https://www.pwc.com/us/en/library/covid-19/us-remote-work-survey.html) shows that remote work will likely stay commonplace even after the pandemic is over. As a result, cloud usage will likely remain high to accommodate remote workers, and ISO 27018 compliance will continue to remain beneficial after COVID-19 is long gone.

## ISO 27018 Controls and Compliance

If you’re serious about following the controls laid out in ISO 27018 or earning an ISO 27001 certification, we highly recommend you read both standards to familiarize yourself with all that is required of you. 

To get a better feel for what you need to prepare for, here is an overview of the controls laid out in ISO 27018 and the process for certification through ISO 27001.

### ISO 27018 Controls Overview

The requirements below are a guideline for cloud service providers on how to update their procedures, technology, infrastructure, etc., in order to follow the controls laid out in ISO 27018.

Some of these recommendations will likely feel familiar, as they show up in regulations like the [GDPR](https://auth0.com/blog/your-quick-gdpr-compliance-checklist/) (just one example of how the ISO 27018 guidelines can help you meet regulatory requirements in different countries):

1. **Always process customer data according to a customer’s wishes**. Basically, you’ll need to show that you’re only using PII the way(s) its owners have explicitly said you can. Meaning, if a user says you’re not allowed to use their information for marketing and advertising, you should have processes for ensuring that never happens.
2. **Help cloud customers provide their users access to their data when they request it**. Or, in plain English, if your customers’ customers want to access their data, you need to have the processes and technology set up to help them do that.
3. **Enable cloud customers to comply with their notification obligations in the event of a data breach**. If breached, cloud service providers should help provide their customers’ visibility into their own data.
4. **Share information with the minimum required parties**. Basically, keep data private unless you’re required to turn it over. This helps keep personal information safe.
5. **Tell your customers about any subprocessors in your contract with them**. This includes notifying your customers about any location(s) where that data is being processed.
6. **Ensure you have a policy for disposing of (or returning) data that is no longer in use**. For example, if a customer ends their service agreement with you, you must have a plan for what to do with their data.
7. **Have your operations regularly reviewed and audited by a third party**. Certification is required annually by a third party. But if you make significant changes to your processing procedures, you’ll also need a third party to review them.
8. **Ensure that every employee with access to your customers’ data is under NDA**. This adds accountability and legal protection in the event that one of your employees is responsible for sharing data when they’re not supposed to.
9. **Ensure that your staff has adequate training**. All of your employees who have access to your customers’ data should be trained to handle it in accordance with ISO 27018 guidelines.

### ISO 27001 Certification Process Overview

As mentioned above, ISO 27018 certification is part of the certification process for ISO 27001 for cloud service providers. Certification for ISO 27001 is required every three years and is determined by an ISO-accredited third party. It typically happens in two stages:

1. **Stage 1: An informal review of your information security management system (ISMS)**. The purpose of Stage 1 is to familiarize auditors with your organization. During this stage, auditors will check up on key documentation and procedures (to ensure they exist).
2. **Stage 2: A formal compliance audit**. In Stage 2, auditors will perform detailed tests of your ISMS against the requirements in ISO 27001 and 27018, looking for evidence that it meets the requirements laid out in the standard. If your ISMS passes this stage, you’ll achieve certification for the year.

After certification, you’ll be required to participate in annual surveillance audits to ensure ongoing compliance. If your ISMS is on the newer side, they could occur several times a year to ensure that everything is in order.

## Are ISO 27018 Controls Worth Implementing?

While the controls laid out in ISO 27018 are not legally required, it’s a really good idea to follow them if you’re a cloud service provider who processes PII&mdash; especially if you’re doing business internationally.

It’s true that the costs of certification through ISO 27001 can be prohibitive for some (certification costs vary from business, depending on the size of your business, the scope of your cloud utilization, etc.). But a data breach isn’t cheap either ([$3.86M](https://www.ibm.com/security/digital-assets/cost-data-breach-report/#/), on average).

And although certification won’t prevent a breach altogether, the controls ISO 27018 recommends certainly can improve your chances of avoiding one (you’ll also have better coverage in the event a breach does occur), even if you don’t pursue a certification.

Especially when you consider the impact a breach can have on your brand ([65%](https://www.centrify.com/media/4772757/ponemon_data_breach_impact_study_uk.pdf) to [80%](https://www.forbes.com/sites/forbestechcouncil/2017/12/08/mind-the-trust-gap-how-companies-can-retain-customers-after-a-security-breach/#40b4b2806c95) of consumers lose trust in a company that’s been breached)!

<include src="asides/AboutAuth0" />

What Is ISO 27018:2019? Everything Executives Need to Know

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

Cloud-based identity management enables safe and convenient digital experiences for financial customers

**LONDON – 7 December 2020 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced that [Ninety One](https://ninetyone.com/en/south-africa/) has deployed its solution to authenticate retail fund investors in South Africa. Started in South Africa as Investec Asset Management, the firm spun out from parent Investec and rebranded as Ninety One this year. Ninety One replaced their on-premises identity solution with Auth0 as part to provide customers with a seamless login experience across its investment products.

Following the demerger and listing, Ninety One required its own [Customer Identity and Access Management (CIAM)](https://auth0.com/blog/what-is-ciam/) infrastructure, including Single Sign On, Multi-factor Authentication, and self-service password reset features. Ninety One’s own development team and a local transfer agency and administrative outsourcing partner, Silica, recommended Auth0 for ease of integration and the ability to host in the cloud while migrating users gradually from the previous on-premises system. 

“The move to Auth0 is indicative of our journey in other parts of the organization,” says Scott Carr, IT platforms manager at Ninety One. “We have embraced Auth0 as essential for our success as a new brand because they enable us to provide the caliber of safe and convenient digital experiences our financial services clients demand.”

IT security spending in the META region (Middle East, Turkey, and Africa) will cross $3.4B in 2023, driven by a focus on [digital identities and shifts to the cloud](https://www.biznesstransform.com/idc-predicts-major-spending-on-digital-transformation-by-the-ict-industry-in-meta/) (Source: IDC)[1]. Auth0 has been recognized as a top private cloud company in identity management on the [Forbes Cloud 100](https://auth0.com/blog/auth0-is-named-to-the-2020-forbes-cloud-100/) and by industry analysts for serving as a key enabler in customers’ [digital transformation](https://auth0.com/forrester-total-economic-impact) efforts.

“Digital transformation shouldn’t be underestimated, but it doesn’t have to be feared either,” said Steven Rees-Pullman, SVP International at Auth0. “Ninety One is looking to the cloud and replacing legacy systems with building blocks like Auth0 to be more adaptable and resilient while delivering great experiences for their clients. We’re pleased to help power their journey.”

[1] IDC Worldwide Black Book Live Edition, July 2020

## About Ninety One

Ninety One is an independent, active investment manager dedicated to delivering compelling outcomes for its clients, managing more than £119 billion/R2.6 trillion in assets (as at 30.09.20).

Established in South Africa in 1991, as Investec Asset Management, the firm started offering domestic investments in an emerging market. In 2020, almost three decades of organic growth later, the firm demerged from Investec Group and became Ninety One. Today the firm offers distinctive active strategies across equities, fixed income, multi-asset, and alternatives to institutions, advisors, and individual investors around the world.

[www.ninetyone.com](https://ninetyone.com/international) 

<include src="asides/AboutAuth0" />

### Media Contacts

Media Contacts 
McKenzie Mayer 
PR Manager, EMEA 
press@auth0.com 

Kotie Basson 
Head of Marketing, Africa Client Group 
Ninety One 
kotie.basson@ninetyone.com

Ninety One Chooses Auth0 as Foundation for Digital Transformation

diegopoza

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

Sr Manager, Developer Advocacy

Diego Poza

Official UK Digital Marketplace accreditation makes it easier for public sector organizations to access Auth0’s identity and authentication management

Auth0 has once again been named as a supplier in the Cloud Services category of the G-Cloud 12 framework, part of the United Kingdom's official [Digital Marketplace for the Public Sector](https://www.digitalmarketplace.service.gov.uk/). G-Cloud accreditation prequalifies Auth0 to participate in public sector tenders for critical software and security services. It is the gateway to servicing government departments (such as HMRC) and non-governmental organizations (such as Homes England and the NHS).

This is the fourth year in a row that Auth0 has achieved G-Cloud accreditation, demonstrating Auth0's commitment to the vital public sector. This accreditation ensures continued access to Auth0's world-class security platform for public sector organizations in the UK.

## What Is G-Cloud 12?

The G-Cloud 12 framework helps ensure that public sector organizations have the ability to make informed and competitive choices in choosing cloud service providers (CSPs). The platform's internal marketplace of pre-negotiated service terms provides transparency on CSP pricing models and allows the public sector to avoid negotiating per-product contracts. This significantly streamlines the tender process, providing a base level of legal protection and pricing benchmarks for public sector entities. 

![Auth0 Search Results](https://images.ctfassets.net/23aumh6u8s0i/6njj9d9z8Ud2dgohq8Wv8l/ca3e6746ed06452932631bde00097f3f/01-auth0-search-results)

The framework clearly outlines pricing structures, security protocols, cost, platform compatibility, and more, serving as a central repository that makes it easy for public sector organizations across the UK to assess the cloud-based software tools available to them.

G-Cloud 12 encourages organizations to make the best choices for their own use cases, allowing them to use implementations that might not be feasible through a traditional government procurement system. As in the private sector, public sector software needs aren't one-size-fits-all, and pre-approved pricing structures make it easier to try software on any scale. The G-Cloud hub is a vital resource helping the public sector update their workflows faster and more cost-efficiently.

As the UK Government moves to better serve the public by making online services more available, protecting user identity is a critical security priority. Building identity solutions themselves can tie up valuable resources and expose public sector entities to risk, so they are moving toward utilizing standardized solutions such as those offered by Auth0. These offer world-class security, reduce risk, and free up internal resources for other key tasks.

For example, the West Midlands Fire Service (WMFS) is one of the few government departments in the country with its own in-house software development team. WMFS has been a leader in [creating award-winning digital applications](https://www.itproportal.com/features/how-open-data-helps-put-out-digital-fires/), including Tymly, a low-code, an open-source software platform that allows businesses to create and use flexible applications to gather, process, and distribute data.

However, rather than spend months building its own authentication system for Tymly, WMFS chose to outsource it. WMFS used the G-Cloud framework for its search, ultimately choosing Auth0's Identity-as-a-Service (IDaaS) to provide GDPR-compliant, cloud-based authentication for the Tymly platform. 

Using Auth0, WMFS can implement multi-factor authentication (MFA), biometrics, single sign-on (SSO), and social login to provide ease of access and the high level of security needed for public sector data.

## Recent Changes to G-Cloud Frameworks

The G-Cloud 12 framework is the 2020 update of the cloud services portion of the UK's Digital Marketplace, the central hub for approved services and suppliers operated by the [Crown Commercial Service (CCS)](https://www.gov.uk/government/organisations/crown-commercial-service) since 2019.

The latest iteration is largely similar to G-Cloud 11, but with a few changes. 

New this year is a requirement that suppliers who hold or work with government data need to meet "buyer requirements in respect of AI ethical statements." The Government Digital Service (GDS) has joined with the Office for Artificial Intelligence (OAI) to offer guidance on using AI in the public sector, with the goal of making sure "the public sector is leading from the front in the safe and ethical deployment of AI and other emerging technologies."

This year, G-Cloud 12 also requires in-depth service definitions for each listing explaining the service and how it works — something that Auth0 has always provided for its G-Cloud listings.

![Auth0 Digital Marketplace](https://images.ctfassets.net/23aumh6u8s0i/3ek6TCIybEXqkMBVOXpUhP/2d158a8b6285aa918bb42d73d77f0782/02-auth0-digital-marketplace)

G-Cloud 11 features about 4,200 suppliers and nearly 31,100 services, both an increase over G-Cloud 10. CCS has tracked spend data since the inception of G-Cloud in real-time via an [online dashboard](https://app.powerbi.com/view?r=eyJrIjoiNTEyMTZhZDAtZGNiNi00OWQxLWI5ODYtMjg1ZWNlMmNkODVhIiwidCI6IjlmOGMwZDc5LTNlODctNGNkMy05Nzk5LWMzNDQzMTQ2ZWE1ZSIsImMiOjh9).

## Benefits of Identity Management in the Public Sector

The UK public sector has been criticized for being reactive to new technologies, which often doesn't take into account the complexities and sheer scale of public sector requirements. The G-Cloud regime is an ambitious program designed to help streamline the procurement of best in class CSPs &mdash; which, in the world of identity, means Auth0. 

Identity and access management are clearly critical issues for almost all public sector organizations, but adhering to the constantly changing standards is difficult when an organization is locked into a rigid software stack. Having the flexibility to pursue up-to-date software helps organizations nimbly respond to changing security needs and threats.

Auth0's ability to identify and protect against ever-evolving security threats and our agile development methodology ensures that our customers have accelerated access to security updates and enhancements. With our continued presence in the G-Cloud market, public sector organizations can also benefit from our expertise in this area. 

Our continued G-Cloud accreditation underscores our commitment to democratizing access to our software and mainstream security practices, much like the platform itself aims to improve accessibility and choice for the UK public sector.

## Auth0's Mission

We believe that world-class security protections don't have to be reserved for elite companies or users but should be applied in broad contexts and accessed on platforms such as G-Cloud 12. Auth0's mission is to provide users with secure access to any application with one click or less. Whether you're a public sector organization, a small business owner, or a security-minded user, Auth0 helps ensure that you can access the most up-to-date security standards with low overhead and a seamless user experience.

![Auth0 Identity Platform](https://images.ctfassets.net/23aumh6u8s0i/469d5UiPrrjSZE0cDLMAbC/27a2b8459e326c9b052ab326ca6d34f8/03-auth0-identity-platform)

<include src="asides/AboutAuth0" />

Auth0 named to G-Cloud 12 framework for fourth year in a row

ken-oestrich

Ken Oestreich is a Product Marketing and Product Management veteran. He's a serial achiever at introducing new products and categories, growing platform adoption, building marketing teams, and maturing new markets for B2B enterprise technologies. He has consistently anticipated and marketed new industry solutions in the IT space, including cloud workspaces, data center infrastructure automation, and federated identity management, and API/Integration technologies.

VP Product Marketing, Messaging, Content, DevRel.

Ken Oestrich

Apps are becoming componentized and API-based to facilitate reuse and agility; Identity management cloud services will help.

> _"In today's online-first, intensely competitive environment, creating a monolithic, inflexible CIAM system will quickly put the firm on the path toward extinction." - Forrester's Customer-Obsessed IAM Operating Model April 2020_

There is an "old-school" view of Identity and Access Management (IAM) that sees it purely as a security requirement for apps and websites. Simply put, IAM is there to keep the bad guys out and let the good ones in. 

A more progressive view recognizes how IAM can help provide a better level of user convenience and app-level [personalization](https://auth0.com/blog/how-identity-management-helps-you-personalize-your-user-experience/), as well as [lower-friction interactions](https://builtin.com/product-management/customer-friction). Plus, it can offer the business better CRM data, a lever for managing [data privacy](https://auth0.com/blog/data-privacy-101/) and [compliance](https://auth0.com/security) controls, and (if implemented properly) a consistent [security perimeter](https://www.itproportal.com/features/why-user-identity-is-becoming-the-new-security-perimeter/) across all apps/properties.

But there's a third level of benefit of IAM that IT often overlooks: _A consistent, flexible IAM foundation can contribute to the firm's overall [digital agility](https://auth0.com/digital-transformation)._ 

Here's why: IAM systems have traditionally been embedded into apps and frameworks (think: React, Angular, JS, etc.). Using that approach, each app runs the risk of becoming an IAM silo unto itself. And when it comes time to integrate those apps with other identity-driven systems, the approach can create a massively _inflexible_ infrastructure. 

Worse, firms should expect that many of their custom apps will have to work alongside other enterprise apps &mdash; e.g., marketing, digital experience, privacy/governance, business systems, and of course, security and analytics. However, the reality is that the logical topology surrounding your IAM system _will always be dynamic and distributed_ &mdash; plan for it. The nature of enterprise systems IAM needs to interface with will always change. But when business leaders don't plan a consistent IAM foundation, digital agility is one of the big losers.

![IAM](https://images.ctfassets.net/23aumh6u8s0i/sBencPL2DaZRTy2DXX8JJ/ebc8f6a50b2b5f9eb45442c49edb43b7/iam_digital_agility)

## Identity Has Become a Foundational Component of Digital Transformation, IT Agility, and Infrastructure Modernization

[_Digital transformation_](https://auth0.com/blog/what-digital-transformation-is-and-what-it-isnt/) initiatives are when progressive software-driven companies shift from rigid, monolithic IT infrastructures and apps into more componentized [API-first architectures](https://auth0.com/blog/the-business-value-of-api-first-design/). These are more easily reassembled/rearchitected and reused (see this great blog about [API strategies](https://blogs.informatica.com/2019/09/18/how-to-win-with-apis/) by Informatica). Component software also means that app updating can be done on a piece-part basis, without requiring the _entire_ application to be retested and QA'd. 

When shifting to an API-based strategy, there is often a simultaneous [replatforming](https://auth0.com/blog/what-is-replatforming) initiative for some (or all) of the components, shifting them into the cloud and/or onto serverless cloud platforms. These initiatives also help businesses respond more rapidly to fast-moving opportunities and/or competitive issues. The growth of API-first architectures and use of serverless execution platforms has been nearly geometric during the past few years.
![Growth API](https://images.ctfassets.net/23aumh6u8s0i/4dwfCPiVqFIyeaNqR5KFAN/8f3e34515b5bdb607e7d46620555dafc/growth_api)

### Distributed and loosely coupled

In software design, a loosely coupled system is one where each component has, or makes use of, little or no knowledge of the other components. This could include the coupling of software classes, interfaces, data, and other SaaS services. Loose coupling is important because it allows you to rearchitect specific components in the future with minimal impact to other components. 

Often, one of the loosely-coupled underpinning layers of these digital transformation initiatives is security and access management &mdash; certainly found at the application level, but also even at the _component_ level. With potentially millions of such API-first distributed components being deployed, each component, app, and composite application _must be reliably and consistently secured_, embracing the capacity to be _identity-aware_.

Decoupling identity from the application and/or app component means avoiding inconsistent IAM stores/DBs, yet ensuring a consistent privacy model, reliable access, and a strong security perimeter. 

## The auth0 Point of View: Your Identity Management Functions Must Be Componentized, Programmable, and Cloud-Neutral

Many of today's IAM technologies are embedded in programming frameworks and therefore hardwired to apps. We believe these IAM functions must &mdash; and will &mdash; become decoupled from the apps they support. Decoupling IAM helps release customers from the bonds of vertical integration stacks that are inherently siloed, brittle, and fundamentally non-optimized for the complexity of today's identity needs. 

IAM functions should also be released from mega-cloud lock-in. The market requires an IAM foundation that's open and customizable &mdash; rather than a foundation that binds customers to an Amazon, Azure, or Google agenda.

This matters because an IAM approach that's API-first, application-decoupled, and componentized also allows developers and their enterprises to rearchitect and dynamically deploy new updates, features, and functionality without disrupting the underlying identity infrastructure. That results in the ability to respond to business conditions and competitive situations more quickly and reliably.

<div class="alert alert-info alert-icon">
“Using microservices in containers has also allowed us greater flexibility when deploying IAM solutions. Typically IAM solutions have featured larger, more monolithic services that are harder to scale and upgrade. Microservices allow the structuring of an application as a collection of loosely coupled services. This architecture then enables the continuous deployment of complex applications, as it is less complicated to update smaller services incrementally than larger ones. It also allows the scaling of particular components (e.g. databases, LDAP servers, etc.) to meet demand as required.” 
~ IAM DevOps in Capgemini, Terence Stamp 
</div>

### Some closing recommendations 

For executives, technology agility equates to business agility. Work with your technical colleagues to understand what IAM underpinnings you currently have and how those will need to evolve to work alongside adjacent systems for marketing, digital experience, privacy/governance, business systems, and security and analytics. Urge technical partners to: 
* **Seek to componentize applications underpinned by a consistent IAM infrastructure**. Treat IAM as a reusable component service the way you use other reusable SaaS services (e.g., payments, databases). 

* **Measure and justify the benefits of IAM across your infrastructure**. Collaborate with colleagues in security, customer experience, web, and CRM teams; assess where identity can yield quantifiable top-line revenue and competitiveness.

* **Prioritize customer outcomes within digital transformation initiatives**. Digital agility and transformation program outcomes must be driven by a focus on responsiveness to customer needs and expectations. Identity management foundations not only contribute to a consistent/reusable infrastructure but also help build a comprehensive customer 360°.

* **Neutralize cloud vendor lock-in risk with an independent, cloud-neutral IAM system**. Long-term agility and avoidance of high switching costs are further enabled by using an independent, cloud-neutral IAM service.

For technologists, it's time to apply IAM like other loosely-coupled SaaS services you commonly use. For example: 
* **Use familiar API and microservices principles when adding IAM into your platform**. Select a reusable, easily-integrated cloud IAM service that's compatible with a broad set of programming languages and frameworks. 

* **Reduce IAM time to production; simplify app reuse**. Get your team started quickly with a solution offering SDKs, quickstarts, and implementation guidance. 

* **Consolidate user IAM systems and databases**. Use an IAM solution offering a range of migration tools and customer DB connections to fit the user migration scenario best for you. 

To learn more about how IAM contributes to overall digital agility, [explore our identity resources](https://auth0.com/resources/), or [reach out to sales](https://auth0.com/contact-us).

<include src="asides/AboutAuth0" />

Digital Agility: The Auth0 Point of View

Recognition highlights Auth0 as a top private cloud company for third consecutive year

**BELLEVUE, Wash. – September 16, 2020 –** [Auth0](http://www.auth0.com/), the identity platform for application teams, has been named to the [2020 Forbes Cloud 100](http://www.forbes.com/cloud100), ranking 19th out of 100 companies listed. The Forbes Cloud 100 is the definitive list ranking of the top 100 private cloud companies in the world, published by Forbes in partnership with [Bessemer Venture Partners](https://www.bvp.com/) and [Salesforce Ventures](https://www.salesforce.com/company/ventures/). Auth0 was also included on the list in [2019](https://auth0.com/blog/auth0-is-named-to-the-forbes-2019-cloud-100/) and [2018](https://auth0.com/blog/auth0-named-to-forbes-2018-cloud-100/).

As part of the rigorous selection process for the 2020 Forbes Cloud 100, Bessemer Venture Partners received submissions from hundreds of cloud startups. The Cloud 100 Judging Panel, made up of public cloud company CEOs, reviewed the data to select, score, and rank the top 100 private cloud companies from all over the world. The evaluation process involved ranking companies across four factors: market leadership (35%), estimated valuation (30%), operating metrics (20%), and people & culture (15%).

"Being included on the Forbes Cloud 100 for the third year in a row is an honor and an accolade we are incredibly grateful for. Thank you to Forbes, Bessemer Venture Partners, and Salesforce Ventures for their continual recognition of Auth0," said Eugenio Pace, CEO and co-founder of Auth0. "As companies and end-users give more of themselves away online, protecting personal data and user credentials is of paramount importance. We are proud to secure the digital world and serve as a key enabler in our customers' digital transformation and identity management efforts." 

Auth0 recently closed a [$120 million round of Series F funding](https://auth0.com/blog/auth0-helping-navigate-through-times-of-transformation/) in July, bringing the company's valuation to $1.92 billion and total capital raised to more than $330 million. Auth0's Series F round comes a little more than a year after the close of its [$103 million Series E funding](https://auth0.com/blog/auth0-closes-103m-in-funding-passes-1b-valuation/) last May, which launched the company into 'unicorn' status. After growing 70% in 2019, Auth0's rapid growth has continued through 2020 despite the uncertainty of the current global economic environment.

"The private cloud ecosystem continues to mature in light of rapid digital transformations, making the competition to land one of the coveted spots on the Cloud 100 list steeper than ever," said Byron Deeter, a top cloud investor, and partner at Bessemer Venture Partners. "Private cloud valuations are getting bigger as the market's appetite for cloud continues to grow. Over the past five years, the average Cloud 100 valuation has grown by a tremendous 2.5x, from $1 billion in 2016 to $2.7 billion in 2020. In fact, our 2020 Cloud 100 includes over 87 private cloud unicorns. These founders represent the absolute best in cloud computing today, and they will most certainly follow in the footsteps of our esteemed Cloud 100 alumni. More than a third of the companies of the Cloud 100 have exited either via strategic M&A, financial M&A or Initial Public Offering. Congratulations to these cloud leaders."

"In the face of this unprecedented time, digital is an urgent imperative, and the pace of innovation is accelerating. Companies around the globe, across all industries must adopt cloud technologies to enable their digital transformation," said Matt Garratt, Managing Partner, Salesforce Ventures. "The opportunity is massive for the cloud – there are now more than 25 public SaaS companies valued at over $10 billion whereas even five years ago there were only three. Sectors from collaboration and security to retail and healthcare, are being disrupted and becoming more digital. Salesforce Ventures is excited to be partnering with Bessemer Venture Partners and Forbes for the fifth year in a row to recognize those who are not just predicting what's coming but working to create the future."

"For five years now, we have ranked the best and brightest emerging companies in the cloud sector," said Alex Konrad, Forbes editor of The Cloud 100. "With so many businesses growing fast in the cloud, from data infrastructure to marketing, it's harder than ever to make the Cloud 100 list – but with more elite company if you do. Congratulations to each of the 2020 Cloud 100 honorees and the 20 Rising Stars honorees poised to join their ranks."

The 2020 Forbes Cloud 100 and 20 Rising Stars lists are published online at [www.forbes.com/cloud100](http://www.forbes.com/cloud100) and will appear in the September 2020 issue of Forbes magazine.

<include src="asides/AboutAuth0" />

## About Bessemer Venture Partners
Bessemer Venture Partners is the world's most experienced early-stage venture capital firm. With a portfolio of more than 200 companies, Bessemer helps visionary entrepreneurs lay strong foundations to create companies that matter, and supports them through every stage of their growth. The firm has backed more than 120 IPOs, including Pinterest, Shopify, Yelp, LinkedIn, Skype, LifeLock, Twilio, SendGrid, PagerDuty, DocuSign, Wix, and MindBody. Bessemer's 15 partners operate from offices in Silicon Valley, San Francisco, New York City, Boston, Israel, and India. For more information, please visit [www.bvp.com](http://www.bvp.com/).

## About Forbes
The defining voice of entrepreneurial capitalism, Forbes champions success by celebrating those who have made it, and those who aspire to make it. Forbes convenes and curates the most influential leaders and entrepreneurs who are driving change, transforming business and making a significant impact on the world. The Forbes brand today reaches more than 160 million people worldwide through its trusted journalism, signature LIVE and Forbes Virtual events, custom marketing programs and 40 licensed local editions in 70 countries. Forbes Media's brand extensions include real estate, education and financial services license agreements. For more information, visit the [Forbes News Hub](https://www.forbes.com/pr/#47fadf455a1c) or [Forbes Connect](https://www.forbes.com/connect/).

## About Salesforce Ventures
Salesforce is the global leader in Customer Relationship Management (CRM), bringing companies closer to their customers in the digital age. Salesforce Ventures, the global investment arm of Salesforce, invests in the next generation of enterprise technology that extends the power of the Salesforce Platform. Salesforce Ventures is building the world's largest ecosystem of enterprise cloud companies and extending that technology to customers. Portfolio companies receive funding, strategic advisory, and operating support, and can easily join [Pledge 1%](https://pledge1percent.org/) to make giving back part of their business model. Salesforce Ventures has invested in more than 400 companies, including DocuSign, GoCardless, Guild Education, nCino, Twilio, Zoom, and others across 22 countries since 2009. For more information, please visit [www.salesforce.com/ventures](http://www.salesforce.com/ventures).

### Media Contacts
Jeana Tahnk 
Global Communications 
Auth0 
[press@auth0.com](mailto:press@auth0.com) 
 
Hannah Carroll 
Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com)

Auth0 is Named to the 2020 Forbes Cloud 100

How to choose a cloud migration strategy based on ROI

When you’re transitioning your organization from on-premises servers to the cloud, you have to decide what to do with your legacy applications.

Broadly speaking, there are three paths for cloud migration:

1. You can **rehost** an application without making major changes, but you may miss out on many of the advantages of cloud migration.
2. You can **rearchitect** an application from the ground up, but that can be time-consuming and expensive.
3. You can **replatform**, in which you retool an application for the cloud without changing its core architecture. Think of replatforming is the middle path between rehosting and rearchitecting. 

Read on to learn about the advantages and risks of replatforming and how to decide when it’s the right approach.

![Replatforming 1](https://images.ctfassets.net/23aumh6u8s0i/4Vd4LySiS1OGMNpRmMlArz/a6a7af444800fde646514b989e95ffe6/replatforming-sep1)

## Rehosting, Rearchitecting, and Replatforming

To understand what replatforming is, we first need to differentiate it from other cloud migration options. Keep in mind that there are no hard lines between these three methods, just differences in how you allocate your company’s time, budget, and priorities.

### Rehosting

Rehosting is commonly referred to as the “lift and shift” approach because you lift an entire application from your internal servers and shift it to the cloud without changing anything.

**Advantages:** Rehosting is the most cost-effective option for cloud migration, or at least it requires the least cost upfront. It also requires the least time and technical know-how and avoids the risk of creating major problems by tinkering with legacy code.

**Disadvantages:** While rehosting projects are meant to be the simplest of all cloud-migration options, they can come with unexpected complications. As [the Doppler blog](https://www.cloudtp.com/doppler/what-is-so-complicated-about-lift-and-shift-cloud-migrations/) discusses, rehosting projects can suffer issues stemming from IP address changes, tangled webs of application dependencies, and longer-than-expected outage windows.

On top of that, even if a lift-and-shift project goes according to plan, you still miss out on the benefits of truly cloud-native features.

**When to use it:** The rehosting approach works for simple applications with few integrations and dependencies, as well as applications for which you need to migrate quickly, minimizing downtime. It’s worth noting that you can always start by rehosting an application and then make bigger changes to it later.

### Rearchitecting

Rearchitecting, also known as refactoring, involves changing significant portions of your application’s codebase to fit the cloud environment.

**Advantages:** Rearchitecting lets you fine-tune every part of an application to take advantage of the cloud. That can net significant savings if you pare down your resource use, so you’re not paying for cloud hosting you don’t need. Rearchitecting lets you build flexibility into your application and replace outdated code with modern, efficient code.

**Disadvantages:** Rearchitecting is the most costly and time-consuming cloud-migration process, and it requires the highest level of coding skills from your DevOps team. Even the best engineers risk introducing errors by tinkering with legacy code, especially if they didn’t write the original version.

**When to use it:** Rearchitecting is a good choice for long-term projects where you can afford to wait to reap the ROI benefits, and where those benefits will justify the initial cost. Rearchitecting is also a good choice for major retools, where you want to add multiple new components to an application at the same time rather than piece by piece.

### Replatforming

Replatforming involves changing and updating specific components of an application. These changes allow the application to function in the cloud, and often result in better scalability, user experience, security, or profitability. You can replatform while transitioning an on-premises application to the cloud or replatform an application you’ve already rehosted. The term replatforming is often associated with [eCommerce](https://www.sellbrite.com/blog/the-ultimate-guide-to-migrating-an-enterprise-ecommerce-website-to-a-new-platform/), but it applies to any industry.

**Advantages:** Replatforming requires less time and money than rearchitecting, so if you choose the right elements to update, you’ll see an ROI faster. These days, you can choose to purchase “plug and play” third-party SaaS components instead of coding all-new solutions in-house, so replatforming requires less specialized coding expertise. This approach lets you tackle one area of the application at a time while keeping the rest intact and functional in the cloud.

**Disadvantages:** Replatforming projects can balloon in scope until they’re essentially rearchitecting, so it’s crucial that you focus on changing only the specified features. Developers need to keep code-tinkering to a minimum and focus on integrating with cloud-native features and open-source code.

**When to use it:** Replatforming is the right path when you can identify a clear ROI for adding new features in the cloud but want to avoid the expense and downtime of a full rearchitecting. For example, one common candidate for replatforming is database hosting. Cloud database storage lets you scale up as needed, and data migration to the cloud makes data more resilient because an on-premises server can fail, but distributed cloud servers provide multiple layers of redundancy.

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

## Why Replatform Your Identity Solution

The first step in choosing what changes to make during replatforming is to weigh cost versus ROI. One appealing candidate that can deliver major savings is identity and access management (IAM).

In the past, IAM solutions were “hardcoded” into apps. Each one came with its own login system and its data silo for user management. But this approach made apps fundamentally brittle &mdash; incapable of integrating with one another to create a single view of users across applications. In that model, IAM was a cost rather than an asset.

Today, more organizations take advantage of cloud-native [identity-as-a-service (IDaaS)](https://auth0.com/blog/what-is-idaas/) platforms, which are designed with adaptability and transparency in mind. By updating your application with an IDaaS solution, you can take advantage of newer features, such as social login, multi-factor authentication (MFA), and single sign-on (SSO).

These features deliver a high ROI, both in terms of savings and top-line revenue benefits. For instance, social logins can increase conversions and improve customer experience because end users don’t have to fill in complicated registration forms to create an account. MFA is increasingly considered a requirement for cybersecurity. Offloading identity can also decrease the maintenance costs of updating protocols for legal compliance in a post-GDPR world.

These advantages hold true across use cases:

**Workforce IAM:** Cloud-native IAM allows for easy management of distributed and remote workforces, letting admins grant and revoke permissions with the flip of a toggle.

**B2B IAM:** An API-first architecture enables back-end integrations with enterprise customers who are already on the cloud, regardless of what stack or language they use. A sophisticated approach to identity helps companies meet the business requirements of their customers.

**[CIAM](https://auth0.com/blog/what-is-ciam/):** Providing a sophisticated identity platform is critical for user experience because legacy identity management frustrates customers and shows your application’s age.

![Replatforming 2](https://images.ctfassets.net/23aumh6u8s0i/BPWJiItmXzRZGWyIYRW0M/fc9778954bb666a793137090089320a3/replatforming-sep2)

## Replatforming Is Part of a Smart Digital Transformation

Generally speaking, your platform should be like CGI in a movie: if people take notice of it, it’s probably not very good. Your customers, employees, and business partners have all come to expect lightning-fast speeds, smooth interfaces, and appealing graphics from every application they use. Updating their most critical touchpoints is critical in keeping up with the state of the business. Replatforming lets you make the upgrades that count while making the most of your organization’s resources.

<include src="asides/AboutAuth0" />

What is Replatforming?

kapehe-jorgenson

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

R&D Content Engineer

Kapehe Jorgenson

Utilize the power of JAMstack and build a portfolio with Gatsby Cloud, Netlify, and DatoCMS.

<AmpContent>
<amp-youtube
 data-videoid="9t3kZ0rVDTw"
 layout="responsive"
 width="315" height="560">
</amp-youtube>

</AmpContent>

<NonAmpContent>

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

</NonAmpContent>

**TL;DR:** In today's article, we are going to be building a [JAMstack](https://jamstack.org/) application using [Gatsby Cloud](https://www.gatsbyjs.com/cloud/) and [Netlify](https://www.netlify.com/). Using the power of these two, we will see just how easy it is to go from ground zero to a fully deployed website. We will also go over the idea of JAMstack and how it's changing the way we think of web development.

## The Art of JAMstack

The term JAMstack was first coined and created by Netlify. It's probably safe to say that most of us have used JAMstack in one way or another in our web development. Okay, but what is JAMstack? Let's chat about it.

Let's go over what the JAM in JAMstack means.

* J: JavaScript - Arguably one of the most popular coding languages in the world, it makes sense we are using it. Creating apps with [React](https://reactjs.org/), [Vue](https://vuejs.org/), or even just plain vanilla JavaScript, this helps build the stack and keeps our requests client-side.
* A: API's - This one is cool because it utilizes the power of an API and takes away the need for a database or a backend that needs to host a server.
* M: Markup - Next, we can have templated markup that is prebuilt. Once we pull in a static site generator like [Jekyll](https://jekyllrb.com/) or [Gatsby](https://www.gatsbyjs.org/), we can get that content displayed quickly.

These three together make for some pretty fast load times. While these three are working hard to creating a fast website, we have so many resources out there. JAMstack takes JavaScript further than what we are used to in SPAs. JAMstack takes an extra step to generate a static version of the site, whereas SPAs are usually client-side rendered.

In today's project, we will be building a portfolio with Gatsby Cloud and Netlify. Let's go over those.

<include src="TweetQuote" quoteText="JAMstack is changing the way we think of web development!"/>

## What is Gatsby

In our project today, we are going to be using [Gatsby](https://www.gatsbyjs.org/). Gatsby is a React-based, static site generator that is powered by [GraphQL](https://graphql.org/). Being a static site generator means it takes our React applications and creates a static HTML file. Once we have that, then whatever JavaScript is needed is loaded on top of our site to add extra functionality. It takes the load off browsers as we are just serving HTML. We don't need to call any databases or to run any server code to generate our pages. We can utilize the power of JavaScript and API's to get our info.

Not only is it going to make things lightning-fast because HTML is faster for a browser to render than JavaScript, but it's also super easy to get started with. We will get into that in a bit when we start building our site.

### Gatsby Cloud

We will also be using [Gatsby Cloud](https://www.gatsbyjs.com/). Gatsby Cloud is a product provided by Gatsby that allows us to create and manage our Gatsby sites faster. Gatsby Cloud provides a few starter projects that we can use to connect Gatsby, a data source ([DatoCMS](https://www.datocms.com/) for this project), and a deployment tool (Netlify for this project). We can connect all of these things and have a site up in a few quick clicks.

We will talk more on DatoCMS in just a bit. We will also go over how to use this amazing new product, Gatsby Cloud, that Gatsby has given us.

<include src="TweetQuote" quoteText="Gatsby Cloud is a product provided by Gatsby that allows us to create and manage our Gatsby sites faster."/>

## What is Netlify

Before the days of [Netlify](https://www.netlify.com/), we had to use companies like [AWS](https://aws.amazon.com/) or [DigitalOcean](https://www.digitalocean.com/) to create a server and then host our website on that server. Today we have Netlify that takes care of that for us. Deploying a website to Netlify is almost too easy. (I was skeptical on my first deploy!)

There are many ways to get your website up and running. In today's project, we will be using Gatsby Cloud to connect to Netlify. Let's see just how easy it is to use Gatsby Cloud to deploy to Netlify!

## What is DatoCMS

Our content is going to live somewhere. Rather than building our own CMS (Content Management System), we are going to utilize a tool called [DatoCMS](https://www.datocms.com/). All of our content (portfolio items) will be managed there. This is great because we don't have to create our own dashboards or editors. All of this is taken care of for us in the DatoCMS built-in dashboard.

So let's say we have a blog, and we want just a single blog post to be updated. We can update that content, the data will live in DatoCMS, and when we deploy, it will rebuild that one item rather than the entire blog. Sounds time efficient!

Let's build!

## What We Will Build Today

In today's project, we are going to be building a portfolio! Using Gatsby Cloud, Netlify, DatoCMS, and the power of JAMstack, we will get a website built up in no time. Let's see how quickly a portfolio can be created in the JAMstack world!
 
## Starting Our Project

First things first, let's get a Gatsby site built. We are going to head over to [Gatsby Cloud](https://www.gatsbyjs.com/). Here we will see the homepage. Click on "Log in" and we will be redirected to a page with a button that says "Sign in with GitHub". Once we click on that, we are going to use our own GitHub credentials and log into the Gatsby Cloud.

> Note: We may need to authorize Gatsby Cloud at this point if we have never used it.

![Gatsby Cloud homepage](https://images.ctfassets.net/23aumh6u8s0i/1sMfmSEiTCLI7TjacXcfSi/2e04a961fd49786173a9cb84a30f7b7e/gatsby-cloud-2)

Next, we will want to create a new project. By clicking on the "Create new site +" button, we are going to start that process. We do not have a Gatsby site yet, so we are going to want to click on "I don't have a Gatsby site yet" and then hit, "Next".

![The step that shows "I don't have a Gatsby site yet"](https://images.ctfassets.net/23aumh6u8s0i/2tluYwoIs7wdZEIqAhnidn/321f50846c0539ae48c3c460262117c3/create-new-site-2)

Here we are going to see a four-step process to build our website.

### Four steps in the Gatsby Cloud

* Step #1 - Starter: From the starters list, we are going to use the "Portfolio with DatoCMS". Click on that starter and click "Next".

* Step #2 - Repository: Here, we will give our repository a name. Because of the link to our personal GitHub, Gatsby Cloud will create the repo for us and put it in our GitHub account. If our GitHub account has access to multiple GitHub organizations, we will need to choose the correct one that we want to use. Once the correct organization is selected, we will install Gatsby Cloud. Next, we will name it, and click "Next". In this tutorial, we will use `jamstack-portfolio`.

**Note**: Netlify requires that Site names are unique globally. If following along, a unique name must be used.

![Image of naming our project for GitHub repo name](https://images.ctfassets.net/23aumh6u8s0i/7EWzemqBqvkYHnneX1bqxu/b5ff59156048c5bc35680000fd9d7267/github-name-2)

* Step #3 - Connect CMS: In this step, we are going to either [create a DatoCMS account](https://dashboard.datocms.com/signup) or [connect to an existing one](https://dashboard.datocms.com/login). Click on the "Connect" button to be directed to "Authorize with DatoCMS". A popup will appear, and we will either create a new, free account with DatoCMS or log in to an existing one. Once we authorize all of that, we will return to see that we are indeed "Connected" to our DatoCMS. Once we see that, hit "Start my site".

![Image showing DatoCMS connection](https://images.ctfassets.net/23aumh6u8s0i/2q5pODvevF2RKIFIioXwA7/80af80dd8942531f3919b926a60fc6a5/datocms-connected-2)

* Step #4 - Summary: After just a moment, we will be redirected to the "Summary" tab. Here we have a bunch of information. We see that the set up was successful, we see the link to our DatoCMS project, and we also see our newly created GitHub link. Click on "Finish" to be redirected back to our [Gatsby Cloud dashboard](https://www.gatsbyjs.com/dashboard/sites).

Once on our dashboard, we will see that our newly created project is building. Give it a couple of minutes. Once it finishes, we should see a green checkmark and a "Deployed in (deploy time here)". 

> Note: To double-check that the repo was created, go to the GitHub account that was connected to Gatsby Cloud and go to "Repositories". There we will see our newly created repo!

### Quick recap!

So far, we have done the following:

1. We have created a GitHub repo that has all of our Gatsby code.
2. We have stored our data into DatoCMS, a headless CMS.
3. All of this is built as a static site via Gatsby Cloud.

This is a portfolio we are building, so we want to show off projects that we have built. Let's see how this is done!

## Updating Data in DatoCMS

All of our data lives in DatoCMS; let's go update it! We'll head on over to our [DatoCMS dashboard](https://dashboard.datocms.com/projects) and update an item.

![DatoCMS Dashboard view](https://images.ctfassets.net/23aumh6u8s0i/7Dxw3Q4Qk639dCLnOlwtDE/b2c7ea90b527b49ad104e737883b0775/datocms-dashboard-2)

Click on the project that we created earlier. In our case, we named it "jamstack-portfolio", so we should see that name in our list of projects. At the top of the page, we will see a button that says "Enter project", click on that.

Once we see the words, "Hello Admin!", we can update any of the data from there. 

Let's click on "Works". Here we are looking at the list of "Portfolio Items" that are viewed on our website. "Flyer 1", at the top of the list, happens to be one of the auto-generated items that we can go in and update. Let's go ahead and click on "Flyer 1", and we can update most everything on it. The title, the images, the content, anything! For this example, let's change the following:

* Title
* Cover Image
* Excerpt

It should look like this:

![Updating title, cover image, and excerpt in DatoCMS](https://images.ctfassets.net/23aumh6u8s0i/2JlsTnvqgWtGHmmRHGMYNU/2a464502f46937a8331da4e22eb5d235/editing-data-2)

Once we have updated all the things we want to, let's hit "Save" in the upper righthand corner of the page.

## Checking for Updates on Gatsby Cloud

Let's head on over to our [Gatsby Cloud dashboard](https://www.gatsbyjs.com/dashboard/sites), click on "jamstack-portfolio", and see how our site is doing. We are going to be double-checking that our changes were saved.

We should see our most recent deploy was run. If it's still running, make sure to let it finish deploying. There is a "Trigger build" button if needed, but we should not have to do that.

Once finished, click on the extremely long URL provided.

![Gatsby Cloud URL](https://images.ctfassets.net/23aumh6u8s0i/3EIgYLUq40xG6YmacWC4Ga/ad3908d16356d14431bf4fe353dda3d8/gatsby-url-2)

This URL shows a live version of our website! And we see that our content was updated in DatoCMS.

![Website homepage view](https://images.ctfassets.net/23aumh6u8s0i/4HICothDiKL3rp54ikmIDa/e72460f6ae47805f1914435a1356d8d3/previewing-site-2)
 
## Working on the Project Locally

Now that we have almost everything set up let's chat about adding other things to our website. If we wanted to do more than update the data we have set up through DatoCMS, we would clone the repo from GitHub, and open up our project in [VS Code](https://code.visualstudio.com/) or our editor of choice and do it there. Some of the things we could do are:

* Change the layout
* Change fonts or color
* Create a custom theme
* Create new types of pages
* Add in authentication
* Add more plug-ins for SEO purposes

We can find instructions in the `README.md` of the repo that was created for us. Once open in our editor of choice, run the following commands:

```bash
yarn install
```

> Be sure to have `yarn` installed. We can also use `npm` command instead.

We are going to want to create a `.env` file so we can store our token. This token is so we can get read-access from our DatoCMS project into Gatsby Cloud:

```bash
echo 'DATO_API_TOKEN=abc123' >> .env
```

To get that `DATO_API_TOKEN`, go to our [Gatsby Cloud dashboard](https://www.gatsbyjs.com/dashboard/sites), click into our project, and then click on "Site Settings". Once in there, click on "Environment variables" under "General" in the lefthand menu. There we will see "Build Environment variable" and a `DATO_API_TOKEN` that is starred out. If we click on "Edit" we will see the full token that we want in our `.env` file.

![Dato API Token view in Gatsby](https://images.ctfassets.net/23aumh6u8s0i/4kMwZW23Lt70AWu1Uj68yN/f5279cff29be6eef8a16367fb20a7315/dato-api-token-2)

To run the project locally in development mode, run the command:

```bash
yarn develop
```

To build the final static website, run the command:

```bash
yarn build
```

Again, all of this is in the `README.md` of our GitHub repo.

## Authentication with Auth0

Once inside VS Code or our editor of choice, we are going to be able to add authentication to our Gatsby site. There is an amazing blog post by [Sam Julien](https://auth0.com/blog/authors/sam-julien/) on [Securing Gatsby with Auth0](https://auth0.com/blog/securing-gatsby-with-auth0/).

This blog post will give you a step-by-step on how to secure a Gatsby site. We will need to <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account and we can do that here</a>. 

Auth0 will take care of the authentication process and give users a seamless experience.

## Deploy to Netlify

The URL that we were using earlier is extremely long and confusing; let's make it more readable. So to take care of that, let's deploy to Netlify.

Let's head back to our [project's dashboard in the Gatsby Cloud](https://www.gatsbyjs.com/dashboard/sites). Here we will see the URL that we clicked on earlier and above that is a banner that says, "Setup hosting". In that same banner, we see, "Do it now". Click on that.

We will see a list of different hosts that we can deploy to and we'll do the following steps:

1. Click on "Connect" that is next to Netlify. 
2. The "Netlify Integration" will appear, and we will want to click on "Connect". 
3. A Netlify login modal will popup, and we will want to log in here. 
4. We will then have to "Authorize" Gatsby Cloud for permission to our Netlify.
5. Our Netlify deployment site name will be auto-generated. We can change that if we want, but we'll just keep it that name for now. We will also want to select which Netlify team to add the site to. Then click on "Create":

![Create a new Netlify deployment site view](https://images.ctfassets.net/23aumh6u8s0i/354J3QxTRQ30re9eJGpHjz/8404ec39a4d838244259fdfb60e54140/deploy-netlify-2)

> Note: Remember that each Netlify Site name needs to be unique. Use the unique name that was used in your project.

Return to our [Gatsby Cloud dashboard](https://www.gatsbyjs.com/dashboard/sites) for the project and trigger a build. Once that is done, we can now visit our newly deployed website with our new URL, "unique-site-name.netlify.com.

![Final view of the deployed website homepage](https://images.ctfassets.net/23aumh6u8s0i/7bvVZtFySKmvBtjdnn0mS0/f79ca4059f9b350a4a42ebf5e324c234/deployed-site-2)

Yay!

<include src="asides/AboutAuth0" />

## Conclusion

Looking back, we can see the power of JAMstack, and how putting a couple of different resources together, it can create a dynamic site. By utilizing Gatsby Cloud, DatoCMS, and Netlify, we can create and deploy a website.

Feel free to make this your own and dive into the code and do custom styling or take that next step and authenticate the site. By having this foundation and understanding of JAMstack, we can create just about any website.

What is your favorite part of JAMstack? Which resources are your favorite? Let us know in the comments below!

---

Build a JAMstack App with Gatsby Cloud, DatoCMS, and Netlify

jenny-obrien

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

Business Content Manager

Jenny O'Brien

Gain cloud flexibility and agility while maintaining security and control

Amazon famously brought [book publishing “to its knees”](https://mashable.com/2014/07/30/amazon-has-killed-publishers-they-just-dont-know-it-yet/) by dominating distribution, creating eBooks, and transforming the publishing world with its own titles and opportunity for authors to self publish. 

In 2018, [Amazon entered the insurance market in India](https://www.insurancebusinessmag.com/us/news/breaking-news/amazon-set-to-file-for-insurance-licence-111581.aspx). [And in 2019, the U.S.](https://www.geekwire.com/2019/amazon-jpmorgan-roll-new-health-insurance-plans-part-haven-joint-venture/) 

After killing off [car insurance comparison tools](https://www.businessinsider.com/google-kills-auto-insurance-comparison-tool-2016-2), Google’s invested in [insurance agency software](https://www.insurancejournal.com/news/national/2019/01/02/513324.htm) and signaled further interest in the market. 

In other words, digital transformation is already here. 

While industry complexities afford some protection, they offer greater opportunity for insiders, says TechCrunch. 

A recent [J.D. Power survey](https://www.jdpower.com/business/press-releases/2019-us-home-insurance-study) on customer satisfaction with home insurance noted that the home insurance business model was “primed for change” and that “weak points in customer experience offered an opportunity for startups.” 

The other side of the desire for customer experiences that are real-time and online is the fact that FinServs are tasked with protecting hackers’ favorite data targets. And the [global rise in data privacy regulation](https://auth0.com/explore/data-privacy/) makes stronger protections important from customer, legal, and compliance perspectives.

While digital transformation can seem daunting for incumbents relying on decades of legacy code, the right identity solution can create seamless customer experiences while increasing your data protection — even if you’re an incumbent partnering with (or acquiring an) up and coming Insurtech startup.

Forbes expects [XaaS (everything as a service), UX, CX (User/Customer Experience), and digital privacy](https://www.forbes.com/sites/danielnewman/2019/07/14/top-10-digital-transformation-trends-for-2020/#3dfc8bdc76be) to “take center stage” in as a digital transformation trend 2020. Like other industries, the need to streamline services, reduce capital expenditures, and be increasingly agile and innovative is fueling FinServ’s change. But FinServ’s need for security, stability, and high availability kept many systems in On-Prem solutions that have proven expensive to scale and maintain — putting the ability to keep up with evolving customer expectations at risk.

For FinServ’s looking to innovate (or even just keep pace), Public Cloud is often touted as an option, but it isn’t the best choice. Public Cloud outages and uptimes provide a strong reason to go private. Auth0 Private Cloud helps (or eliminate) that risk, by providing a secure, flexible, extensible solution. 

![Deployment Options Diagram](https://images.ctfassets.net/23aumh6u8s0i/23TVeU9N9cKlxxrenpT6hA/ae7991f61be42885833856bed91a74f7/deployment_options_diagram)

## Why Is Private Cloud Particularly Suited for Finserv Environments

For many years, incumbent FinServs have been buffered by deep compliance capabilities and an established customer base. But FinTech disruptors have eroded that edge says a recent PWC [report](https://www.pwc.com/gx/en/financial-services/assets/pdf/technology2020-and-beyond.pdf), in part because successful disruptors are able to offer a stronger customer experience at a lower cost to customers and with less investment. 

To solidify standing and increase the customer base in this environment, FinServ’s need to:

* Improve customer experience
* Keep ahead of evolving data privacy regulations
* Reduce costs without sacrificing cybersecurity

The data that FinServs hold makes them a prime target for hackers — and the sheer company scale usually means millions of breached accounts, rather than thousands. Globally, the increase in data privacy laws like GDPR and CCPA demonstrates that regulators have lowered tolerance for breaches and expect greater protections to be in place. When not implementing features like multi-factor authentication (MFA) can hit an insurer with a large fine, like what happened to [Dutch public insurance company UWV](https://auth0.com/blog/gdpr-fines-hit-these-companies-hard-heres-how-to-avoid-them/), the need for greater security while still ensuring flexibility becomes more appealing.

<include src="TweetQuote" quoteText="The data that FinServs hold makes them a prime target for hackers — how Private Cloud can help."/>

From an identity perspective, let’s take a closer look at what Auth0 Private Cloud can mean for key digital transformation considerations.

### Performance at Scale
The most innovative solution in the world does zero good if it doesn’t offer you the performance you need. Auth0 Private Cloud offers request-per-second (rps) baseline is higher than public cloud, with the option of adding on capacity up to 1500 rps.

### Reliable High Availability
FinServ is more aware than most industries the dramatic impact of service interruptions, especially given the pressures of changing global conditions. High availability helps guard against those challenges, especially since Private Cloud can be deployed between two regions to provide failover.

### Control & Segregation
Managed Private Cloud offers a fully-isolated development environment that is updated independently from the production environment. Standard Private Cloud is a single instance production environment. Both Standard Private Cloud and Managed Private Cloud meet standards that require all data to be housed within specific regions.

### Free Developers to Improve Customer Experience
For a developer coming up with an innovative solution while working only On-Prem can feel like trying to code while wearing handcuffs — it’s hard to even get your hands on the keyboard. 

To keep up with the pace of customer’s hunger for real-time innovations, streams of data from connected vehicles and smart homes, and the data privacy compliance requirements from laws like GDPR and CCPA, developers need not only the flexibility but also the scale of a [cloud deployment](https://auth0.com/cloud). And they need that deployment to be secure and reliable enough to handle the demands of enterprises whose customers are often interacting during moments of high stress or need.

### Unify Legacy and New Data Stores
Unifying legacy and new data stores can be a giant headache, as well as a source of weeks of downtime without a plug-n-play identity solution that allows bulk imports, but can also streamline user migration without expensive forced password resets – whether unifying stores at a single organization or when an incumbent partners or acquires an insurance startup.

### Support for Different Languages/Architectures (SDK)
Aside from unifying data stores, incumbent companies often rely on a maze of programming languages and architectures. Shutting down one part of the maze can have unexpected consequences if all the interrelationships aren’t fully mapped out or even understood due to poorly commented code or loss of institutional knowledge due to attrition or staffing turnover.

Your devs will be a lot happier (and more productive) when working with an identity solution that can handle multiple programming languages and architectures and already has SDKs (software development kits) that can be dropped into place to provide rapid access to functionality. And the right solution gives you the flexibility to map the maze at your own pace, reducing costs by removing unnecessary middleware, maintenance, and security as you deem appropriate.

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

The real world is a messy place where you might have an out-of-the-box tool that needs to be integrated with custom code. The ability to inject code into the Auth0 Identity solution means that developers can handle the last-mile customizations that execute on the C-suite’s business strategy without weeks of downtime or missed opportunities. To delve into this topic in greater technical detail, you might also check out Auth0 Principal Architect Vittorio Bertocci’s whitepaper “[The Tao of Extensibility.](https://auth0.com/resources/whitepapers/tao-of-extensibility)”

## Support and Failover
Uptimes, updates, failovers, and support can have a big impact on the success of your deployment. 

With Public Cloud coming in with an uptime SLA of 99.90%, Private Cloud offers a stronger uptime SLA of 99.95% with the option to upgrade to maxim uptime guarantees of 99.99%. Geo redundancy can provide resiliency against catastrophic events. As mentioned above, Private Cloud offers failover between two geographic regions. 

For teams that would appreciate additional support, Auth0 offers a support SLA as an add-on, as well as the add-on option to work with the skilled identity experts on our Professional Services team.

## Managed Private Cloud vs. Standard Private Cloud
Let’s take a look at the different deployment Private Cloud models and benefits, including a checklist to help you assess deployment needs.

**Standard Private Cloud** is a low touch engagement model that offers additional power, security and compliance* benefits through an isolated tenant just for a single customer. Uptime SLA is 99.95% with an upgrade possible to 99.99%. PCI compliance is available as an add-on.

**Managed Private Cloud** is a high-touch engagement model where customers are much more involved with all aspects of this deployment model. Our team will work closely with the customer to ensure all aspects of their Auth0 environment are tuned for what best suits their business needs. Uptime is 99.99%. PCI compliance is available as an add-on.

**Reasons to choose Managed Private Cloud** * **Choice of update frequency** Coordinated with Auth0 (required once per 3 months). The update cycle begins with the Pre-Production Environment.
* **A separate DEV (Pre-Production) environment** Fully-isolated and independently updated instance for development and testing (Single Node)
* **On-demand scaling** WIll scale customer environment for any spikes * **Load Testing** 4x Load Testing per year with dedicated Auth0 MSE Support * **Customer-hosted AWS deployment** More **control** over the environment * **GEO-HA deployment option** Datacenter **redundancy** and automatic **failure handling**. 
 
**Reasons to choose Standard Private Cloud**
* ***Doesn’t require any of the Managed Private Cloud reasons***
* **More cost-effective**
* **Less involved with managing the deployment** The customer is looking for an offering that feels similar to a standard Public Cloud SaaS but has isolation and the other advantages of our Private SaaS Deployments. |

<include src="TweetQuote" quoteText="Legacy code can make #digitaltransformation feel like a high hurdle for FinServs. Find out how Private Cloud can help securely smooth the jum"/>

## Reduce Risk, Increase Innovation With Private Cloud
Like identity, digital transformation is not a one-and-done solution, but an ongoing need to keep pace with the evolution of technological change. Auth0 Private Cloud provides the flexibility, agility offered by cloud deployments but allows FinServ’s to maintain the control and security they need to protect their customers and their businesses. Your IAM solution is a critical component of your security strategy, but even if you’re dealing with decades of legacy code, you don’t need to sit down and build it in-house. The more secure option is to let identity experts protect those critical credentials, freeing your team (and resources) to focus on what you do best. Identity no longer needs to be a roadblock or an afterthought. Identity Access Management (IAM) is an essential component of customer security and privacy. If you’d like to learn more about how Auth0 Private Cloud might work for your particular situation, please reach out to an [Auth0 resource](https://auth0.com/).

"cloud"