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

Learn how to build a tool-calling AI agent using LangGraph, Vercel AI SDK, and Next.js. Integrate different kinds of tools in them. Use Google services like Gmail, Calendar, and Drive as tools secured using Auth0 Token Vault.

**AI agents** and **Operators** are the next big things in software development. In a [previous post](https://auth0.com/blog/genai-tool-calling-intro/), we discussed how AI agents are taking center stage by seamlessly integrating with multiple digital tools to be more efficient. In this post, we will be building a personal assistant that can use different types of tools. Both simple unauthenticated tools and more complex authenticated tools like Gmail, Calendar, and Google Drive.

If you haven't read the previous post, I recommend you do so before continuing to better understand tool calling in AI agents and how security is currently handled.

<include
 src="LinkCard"
 title="Tool Calling in AI Agents: Empowering Intelligent Automation Securely"
 link="https://auth0.com/blog/genai-tool-calling-intro/"
 description="Discover how AI agents are taking center stage by seamlessly integrating with multiple digital tools to be more efficient. Learn why it is important to secure them."
 img="https://images.ctfassets.net/23aumh6u8s0i/4LrNhImjPcdPVpmCIrhlG9/4efed8dfb26630e6cf48b4a478a1f550/genai-tool-calling-intro.png"
/>

To keep this post focused on tool calling, we will only focus on the AI agent part and not the UI. Each step of the tutorial, including building the UI, can be found as a distinct commit in the [GitHub repository](https://github.com/auth0-samples/auth0-assistant0).

## Technology Stack

We will use a [Next.js](https://nextjs.org/) application called **Assistant 0** as the base, Assistant 0 is an AI personal assistant that consolidates your digital life by dynamically accessing multiple tools to help you stay organized and efficient.

Apart from Next.js, we mainly use the following technologies:

- [LangGraph.js](https://langchain-ai.github.io/langgraphjs/) and [LangChain's JavaScript framework](https://js.langchain.com/docs/introduction/) for building agentic workflows.
- [LangChain community tools](https://js.langchain.com/docs/integrations/tools/).
- Vercel's [AI SDK](https://github.com/vercel-labs/ai) to stream response tokens to the client and display the incoming messages.
- The [Auth0 AI SDK](https://github.com/auth0-lab/auth0-ai-js) and [Auth0 Next.js SDK](https://github.com/auth0/nextjs-auth0) to secure the application and call third-party APIs.

## Prerequisites

> **You will need the following tools and services to build this application**:
>
> - [Bun v1.2](https://bun.sh/) or [NodeJS v20](https://nodejs.org/en/download)
> - An Auth for GenAI account. [Create one](https://a0.to/ai-content).
> - An OpenAI account and API key. [Create one](https://platform.openai.com) or use any [other LLM provider supported by LangChain](https://js.langchain.com/docs/integrations/llms/).
> - A SerpAPI account and API key. [Create one](https://serpapi.com/).
> - A Google account for Gmail, Calendar, and Drive. Preferably a new one for testing.

## Getting Started

First clone [the repository](https://github.com/auth0-samples/auth0-assistant0) and install the dependencies:

```bash
git clone https://github.com/auth0-samples/auth0-assistant0.git
cd auth0-assistant0
git switch step-1 # so that we skip building the UI and get straight to the AI agent

bun install # or npm install
```

Next, you'll need to set up environment variables in your repo's `.env.local` file. Copy the `.env.example` file to `.env.local`. To start you'll just need to add your OpenAI API key.

Now, start the development server:

```bash
bun dev # or npm run dev
```

Open `http://localhost:3000` with your browser to see the result! Ask the agent something, and you'll see a streamed response.

![Assistant 0](https://images.ctfassets.net/23aumh6u8s0i/ePzgV9PLYqmwdsqdJC2VU/3507e783ee8199b6a5599742ef81fed7/assistant-0.png)

### A Peek into the Code

The application is structured as below:

- `src/app`: Contains the Next.js application routes, layout, and pages.
- `src/app/page.tsx`: Home page with chat interface.
- `src/api/chat/route.ts`: API route for handling chat requests. This is where the AI agent is defined.
- `src/components`: UI components used in the application.
- `src/lib`: Services and configurations. This is where custom tools will be defined.
- `src/utils`: Utility functions

Let's take a look at the `src/api/chat/route.ts` file where the AI agent is defined.

```js
// src/api/chat/route.ts
// ...
const AGENT_SYSTEM_TEMPLATE = `You are a personal assistant named Assistant0. 
You are a helpful assistant that can answer questions and help with tasks. 
You have access to a set of tools, use the tools as needed to answer the user's question.`;

export async function POST(req: NextRequest) {
 // ... Process the request and get messages
 // Create a new OpenAI chat model
 const llm = new ChatOpenAI({ model: 'gpt-4', temperature: 0 });
 const tools = [];
 // Use a prebuilt LangGraph agent.
 const agent = createReactAgent({
 llm,
 tools,
 messageModifier: new SystemMessage(AGENT_SYSTEM_TEMPLATE),
 });
 // Stream back all generated tokens and steps from their runs.
 const eventStream = agent.streamEvents({ messages }, { version: 'v2' });
 // Log tool calling data. Only in development mode
 const transformedStream = logToolCallsInDevelopment(eventStream);
 // Adapt the LangChain stream to Vercel AI SDK Stream
 return LangChainAdapter.toDataStreamResponse(transformedStream);
}
```

The route uses a prebuilt LangGraph agent and OpenAI chat model. No tools are defined yet; we will add them in the next section.

Here is a high-level architecture of the application with the tools we will be adding in this post.

![Assistant 0 architecture](https://images.ctfassets.net/23aumh6u8s0i/6ZTtsivmBOPUmKGWx479Xm/d8d90c3bf3f24f1c8ce99ff703a1ba7d/architecture.jpg)

Now that the base application is running, let's start building our personal assistant with tool-calling capabilities.

## Add Tools to the Assistant

If you recall the previous post, we discussed authenticated and unauthenticated tools. Let's start with an unauthenticated tool and then proceed to add more complex tools like Gmail, Calendar, and Google Drive.

### Add a Calculator Tool

We will start with a simple calculator tool from LangChain community tools to perform basic arithmetic operations.

Install the `@langchain/community` package.

```bash
bun add @langchain/community # or npm i @langchain/community
```

Update the `src/api/chat/route.ts` file with the following code.

```js
// src/api/chat/route.ts
import { Calculator } from '@langchain/community/tools/calculator';
// ...
export async function POST(req: NextRequest) {
 // ...
 const tools = [new Calculator()];
 // ...
}
```

It's that simple! Now try asking the assistant to perform some calculations. For example, `what is (2+56) x 200`. You should see the answer in the UI. If you check the console where Next.js dev server (`bun dev`) is running, you should see the tool calling data like below.

```bash
Tool calls state: {
 "call_E3Za9klJcJ5TADWiMj8XfjdB": {
 "name": "calculator",
 "args": "{\n \"input\": \"(2+56) * 200\"\n}"
 }
}
 POST /api/chat 200 in 8382ms
```

### Add a Web Search Tool

Now let's add a web search tool to search the web for information. Let's use [SerpAPI](https://serpapi.com/) for this. It's an authenticated tool. But since this is going to be API usage and not a user impersonation, we can simply use an API key.

First, get an API key from SerpAPI and add that to your `.env.local` file.

```bash
SERPAPI_API_KEY=your-api-key
```

Now, update the `src/api/chat/route.ts` file with the following code.

```js
// src/api/chat/route.ts
import { SerpAPI } from '@langchain/community/tools/serpapi';
// ...
export async function POST(req: NextRequest) {
 // ...
 const tools = [new Calculator(), new SerpAPI()];
 // ...
}
```

Again, quite simple! Now try asking the assistant to search the web for information. For example, `What is the top 10 news today?`. You will see the response in the UI.

![Assistant 0 web search](https://images.ctfassets.net/23aumh6u8s0i/h4hWDQwBBTUiDh6gdaVET/137647c87dd51c6cc34ec0a44d6e453d/assistant-0-web-search.png)

If you check the console, you should see the tool calling data like the one below.

```bash
Tool calls state: {
 "call_e8vqAPW45vMsUbFiIF9SW5Yn": {
 "name": "search",
 "args": "{\n \"input\": \"top 10 news today\"\n}"
 }
}
 POST /api/chat 200 in 15443ms
```

This corresponds to the `step-2` branch in case you want to double-check your code.

```bash
git switch step-2
```

### Add Gmail Tools

Now, let's get into business. I know you are here for this part, not to learn about adding calculators and web search tools. But before we can add a Gmail tool, we need to add Auth0 authentication to the application since we will be using Auth0's [Token Vault](https://auth0.com/docs/secure/tokens/token-vault) feature to get access tokens to call the Gmail API via a tool.

#### Add Auth0 Authentication

First, let's add Auth0 as the authentication provider to the application.

Follow the [Auth0 Next.js quickstart guide](https://auth0.com/ai/docs/user-authentication) to set up the application.

> If you want to create the Auth0 application manually, create a new application (Type: **Regular Web App**, Callback URL: `http://localhost:3000/auth/callback`) and get the **client ID** and **client secret**.

Update the `.env.local` file with credentials, and create the `src/lib/auth0.ts` and `src/middleware.ts` files.

If you want to skip to the next step, check out the `step-3` branch. The [full changelog for this step is on GitHub](https://github.com/auth0-samples/auth0-assistant0/commit/9a6db1ec49511afa7c361080c3f5a1854ee8efe5).

```bash
git switch step-3
```

#### Configure Auth0 for Gmail

To use Gmail API with Auth0 via a Google Social Connection, you need to do the following:

- Create Google OAuth 2.0 credentials
- Configure Gmail social connection in Auth0

You can follow the [Google Sign-in and Authorization](https://auth0.com/ai/docs/google-sign-in-and-auth) guide from Auth0 to configure this.

#### Add Gmail Search Tool

We can add Gmail tools now that we have Auth0 authentication in place. Let's start with a Gmail search tool. This tool will allow the assistant to search for emails in the user's Gmail account.

First, we need to get an access token for the Gmail API. We can get this using the [Auth0 Token Vault](https://auth0.com/docs/secure/tokens/token-vault) feature.

Update `src/lib/auth0.ts` with the following code.

```js
// src/lib/auth0.ts
// ...
export const auth0 = new Auth0Client({
 // this is required to get federated access tokens from services like Google
 authorizationParameters: {
 access_type: 'offline',
 prompt: 'consent',
 },
});

export const getGoogleAccessToken = async () => {
 const { token } = await auth0.getAccessTokenForConnection({
 connection: 'google-oauth2',
 });
 return token;
};
```

Install the `googleapis` package.

```bash
bun add googleapis # or npm i googleapis
```

Import the `GmailSearch` tool from LangChain community tools and update the `src/api/chat/route.ts` file with the following code.

```js
// src/api/chat/route.ts
import { GmailSearch } from '@langchain/community/tools/gmail';
import { getGoogleAccessToken } from '@/lib/auth0';
// ...
export async function POST(req: NextRequest) {
 // ...
 // Update the LLM model to gpt-4o-mini to support a larger context window
 const llm = new ChatOpenAI({
 model: 'gpt-4o-mini',
 temperature: 0,
 });
 // Get the access token via Auth0
 const accessToken = await getGoogleAccessToken();
 // Provide the access token to the Gmail tools
 const gmailParams = {
 credentials: { accessToken },
 };
 const tools = [new Calculator(), new SerpAPI(), new GmailSearch(gmailParams)];
 // ...
}
```

We are all set! Now try asking the assistant to search for emails. For example, `What is the latest unread email?`. You should see the response in the UI.

![Assistant 0](https://images.ctfassets.net/23aumh6u8s0i/14n2drq2woolLeJybBMWk6/3bbc575f92493dc2322f485a6b4f4ac9/assistant-0-gmail-search.png)

If you check the console, you should see the tool calling data like the one below.

```bash
Tool calls state: {
 "call_rCzcZRjueyD8p2kzTmeZMiSK": {
 "name": "search_gmail",
 "args": "{\"query\":\"is:unread\",\"maxResults\":1,\"resource\":\"messages\"}"
 }
}
 POST /api/chat 200 in 10892ms
```

#### Add Gmail Draft Tool

We will add a Gmail draft tool next. This tool will allow the assistant to draft emails on behalf of the user.

Update the `src/api/chat/route.ts` file with the following code.

```js
// src/api/chat/route.ts
import { GmailDraft } from '@langchain/community/tools/gmail';
// ...
export async function POST(req: NextRequest) {
 // ...
 const tools = [
 new Calculator(),
 new SerpAPI(),
 new GmailSearch(gmailParams),
 new GmailDraft(gmailParams),
 ];
 // ...
}
```

Now, ask the assistant to draft an email. For example, `Draft an email to John Doe about the meeting tomorrow.` You should see the response in the UI.

![Assistant 0](https://images.ctfassets.net/23aumh6u8s0i/hWz4f6iUXTacbCNoqxwLz/c16c70d786027012b4c4944639339999/assistant-0-gmail-draft.png)

If you check the console, you should see the tool calling data like the one below.

```bash
Tool calls state: {
 "call_pPAk6rFYJSSyAuYkNWFf5KYX": {
 "name": "create_gmail_draft",
 "args": "{\"message\":\"Hi John,\\n\\nI hope this message finds you well. I wanted to … [Your Name]\",\"to\":[\"john.doe@example.com\"],\"subject\":\"Meeting Reminder\",\"cc\":[],\"bcc\":[]}"
 }
}
 POST /api/chat 200 in 7594ms
```

You can find the [full changelog of these two steps on GitHub](https://github.com/auth0-samples/auth0-assistant0/commit/ae2dd28b2fd2248d1d9ca76bd77269ea75817379).

This corresponds to the `step-4` branch in case you want to double-check your code.

```bash
git switch step-4
```

## Learn more about AI Agents and Auth for GenAI

You have successfully built an AI personal assistant that can search the web, search your emails, and draft emails. In the next chapter, we will add more tools like User Info, Google Calendar, Google Drive, and Slack to the assistant.

This tutorial is part of a series of posts on tool-calling Agents with [Auth for GenAI](https://a0.to/ai-content), we learned how to add tools to an AI agent and how to secure them using Auth0.

Sign up for [Auth for GenAI in Developer Preview](https://a0.to/ai-content).

Before you go, we have some great news to share: we are working on more content and sample apps in collaboration with amazing GenAI frameworks like [LlamaIndex](https://www.llamaindex.ai/), [LangChain](https://www.langchain.com/), [CrewAI](https://www.crewai.com/), [Vercel AI](https://vercel.com/ai), and [GenKit](https://firebase.google.com/docs/genkit). [Auth for GenAI](https://auth0.com/blog/introducing-auth-for-genai-launching-identity-for-ai-agents/) is our new product to help you protect your user's information in GenAI-powered applications. Make sure to join the [Auth0 Lab Discord server](http://a0.to/auth0-lab-discord) to hear more and ask questions.

Build an AI Assistant with LangGraph, Vercel, and Next.js: Use Gmail as a Tool Securely

shiven_ramji

Shiv is an experienced product executive and builder obsessed with creating beautiful products. He is the President of Customer Identity at Okta, managing a $1B ARR business and overseeing the company’s product, data, security, and technology strategy and execution. Before Auth0 and Okta, Shiv was the SVP of Product at DigitalOcean, leading DigitalOcean’s products, pricing, and partnerships. Additionally, Shiv has held product leadership positions at global brands, including Amazon, NBCUniversal, LiveIntent, and The Nielsen Company. Shiv was the recipient of the 2023 Top Global CPO Award by the Products That Count community. 

Beyond his current corporate focus, Shiv is deeply committed to fostering entrepreneurship and innovation, particularly in Africa. He is an active angel investor and startup advisor and also serves on the boards of [Products That Count](https://productsthatcount.com/) and [Aiven.io](http://Aiven.io).

President, Auth0

Shiven Ramji

Our commitment to delivering a Tier 0 service for our customers

Resiliency, reliability, and adaptability are foundational tenets to how we build at Auth0. Last year, we recognized the need to deliberately double down on our resilience efforts in order to address some of the failures we had seen. In November 2021, I wrote about our [plans to improve the resilience of our platform](https://auth0.com/blog/improving-our-platform-resiliency-and-upcoming-holiday-plans/) and the additional steps we were taking to address the peak holiday traffic. I’m proud of the hard work and diligence by our teams during the holiday season that moved us considerably towards our goal of providing a Tier 0 service. Today, I want to provide updates to that work, share the progress to date, as well as provide insight into our upcoming efforts.

## Update on Our Resiliency Focus Areas to Date

As a reminder, a big focus area for our team was to reduce the load on our datastores. We made significant progress in this area:  

*   Reduced the database read/write workload by 50%. Our initial target was a 10% reduction, so we greatly surpassed our initial estimates
*   Reduced 45% of inserts/deletes from our database in US-1, 50% in EU, and 20% in the rest of our environments. The team's initial target was 40% in US-1 so we also beat this estimate

We also actioned all the initially identified resiliency priorities. These were all implemented either prior to the Thanksgiving holiday in the US or in early December:  

*   Added noisy neighbor protection for our extensibility stack (Webtask)
*   Expanded our caching approach for common Authentication API requests
*   Enforced new Auth API global rate limits for all production tenants
*   Enforced 100 RPS for non-production enterprise tenants
*   Refactored our connections schema and deleted unused entries/rows; in US-1, we reduced the table size by ~25X.
*   Overprovisioning of our stack was done in anticipation of holiday traffic, we’ve since downsized based on usage data and some of the other protections put into place

While we made great progress on our improvement initiatives, I want to acknowledge that in December we experienced a few issues related to our network edge, which caused unfortunate customer impact. We have met with our network edge provider to ensure our expectations around incident response and service levels are understood and upheld. We’ve also initiated a new internal effort to review our Edge resiliency plan and kicked off the discovery work. We’ll provide further updates as we make meaningful progress on this effort.

## What’s Next in 2022

Resiliency has been and remains a top priority for Auth0 in 2022. The work that I outlined above has laid strong foundations that will serve as a springboard for our ongoing priorities. Below are a few key highlights of what to expect this year.

### New Environments
This is one of our top priorities for the first half of 2022. Construction efforts have kicked off for three new production environments that will enable us to shift load as required for our demand response strategies and limit the blast radius of disruptions and outages. These environments will be launched in 1H 2022 and will feature two new options in the US and one in the EU.

### Automated Tenant Migration Process

In addition to new environments, our team has been working on our capabilities to move tenants from one environment to another in order to further reduce the blast radius. The early design work began in Q3 2021, with a focus on high-touch migration of select targeted customers based on feature usage, workload, and configuration. As we iterate and learn from that effort, we will shape up our tenant migration process from “high-touch”/manual intensive to a more automated process.

### New Platform Rollout

We are laser-focused on our platform modernization efforts which have an underlying architecture that is responsive and resilient to meet all current and anticipated customer needs. The new platform is already powering our product that [launched on MS Azure](https://auth0.com/blog/auth0-on-microsoft-azure-as-a-private-cloud-deployment-option/) in November 2021. I will share details about the availability of this new platform on AWS as we get closer to launch in Q1 2022.

Thank you for the continued trust that you place in Auth0 to meet your identity needs. We have exciting things in the works that will enable us to continue our delivery of a Tier 0 service with all of the product innovation you have come to rely on for your applications.

A Look Back to Our Platform Resiliency and What’s Next

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

New global report highlights how identity is foundational in helping governments improve existing services, and launch new ones faster and more securely

**BELLEVUE, Wash.** **– January 12, 2022** –[ Auth0](https://auth0.com/), a product unit within[ Okta](https://www.okta.com/) (NASDAQ: OKTA), today released the findings of its first [Public Sector Identity Index](https://www.auth0.com/public-sector/identity-index-report), a global research report that provides government technology leaders with insight into the identity maturity of public sector organizations around the world. The report highlights the importance of a centralized identity strategy in putting safe and accessible services into the hands of citizens faster.

Over the past two years, many public sector organizations were prompted by the immediate need to deploy digital infrastructure to maintain continuity of their services amid the COVID-19 pandemic — such as offering citizens license renewals online and virtual education — and are now grappling with the impacts on cybersecurity and user experience. From the Executive Order on ‘Improving the Nation’s Cybersecurity’ in the U.S., to digital identity and Single Sign-On (SSO) initiatives in the UK and Australia, enabling employees, citizens, and other government entities to access all of these applications easily and securely has become a demand around the world. 

The 2022 Public Sector Identity Index, conducted by Auth0 and [Market Connections](https://www.marketconnectionsinc.com/), captures the perceptions of 850 IT and line of business decision-makers within national and state/local government organizations across the U.S., UK, and ANZ (Australia and New Zealand) with regard to their [Identity and Access Management (IAM)](https://auth0.com/resources/whitepapers/how-identity-forms-a-foundation-for-digital-govenrment) strategy.

The report’s key findings include:

* Only one in five are extremely confident in either the security (17%) or ease of use (19%) of their current authentication solution.
* Username and password is the most frequently used authentication method by citizens (86%), compared to very little usage of biometric or passwordless authentication (16%).
* Four in ten are currently building their own IAM solution in-house (41%), and cite speed to implementation (83%) and using internal staff to manage IAM internally (82%) as two of the biggest pain points in doing so.
* Most governments are looking to expand their digital services in the next two years (75%) and rank protecting citizen’s privacy and data as most important when thinking about citizen services (73%).

 

Regional analysis shows U.S. respondents rank ensuring citizens’ trust in digital services as an area of high importance (71%), but have less confidence in their organization’s ability to deliver this (56%). Similar discrepancies in importance versus confidence in delivery include speed in adding new services in the UK (66% importance vs. 48% confidence), and improving the user experience in ANZ (72% importance vs. 60% confidence).

Dean Scontras, Vice President of State and Local Government and Education (SLED) at Okta, said: “Digitization is likely to continue in light of Zero Trust mandates and mounting consumer expectations. Public sector organizations greatly benefit from bringing their identity management strategy in line with their digital goals. While there is a strong focus on securing citizen data, the vast majority of applications are still protected by a username and password, despite their well-documented security risks.”

According to Forrester Research, the public sector has a massive influence on the entire economy making up 30% of the global GDP and 33% of the global workforce, and the global research firm predicts that more governments will adopt Zero Trust frameworks to revive public trust in digital services.[^1]

An [Identity-First approach](https://www.youtube.com/watch?v=g7ZzOJQwRsE) puts identity at the center of government digital transformation, while also laying the foundation for a Zero Trust security model. Key to this approach are modern login technologies that replace traditional passwords, and introduce friction only when suspicious behavior is detected. By making the shift to Identity-First, organizations like [Larimer County](https://auth0.com/case-studies/larimer-county/) provide easy and seamless access for legitimate users, while decreasing the risk of security and compliance breaches.

Jessica Figueras, a cybercrime and digital identity advisor to governments and Okta consultant, said: “In the face of increasing digitization, skills shortages, and online harms, governments are taking a hard look at the technologies they can bring onboard to help them reach their digital goals. The research suggests that identity is one such technology that can help the public sector do more with less.”

To learn more and download the full report, please visit: [2022 Auth0 Public Sector Identity Index](https://www.auth0.com/public-sector/identity-index-report).

## Methodology

Auth0 engaged Market Connections to design an online survey of 850 IT and line of business decision-makers within national and state/local governments in the U.S. (200 federal, 200 state & local), UK (100 federal, 100 state & local), and ANZ (Australia and New Zealand) (155 federal/national, 95 state & local), fielded in September-October 2021.

<include src="asides/AboutAuth0" />

## About Okta

Okta is the leading independent identity provider. The Okta Identity Cloud enables organizations to securely connect the right people to the right technologies at the right time. With more than 7,000 pre-built integrations to applications and infrastructure providers, Okta provides simple and secure access to people and organizations everywhere, giving them the confidence to reach their full potential. More than 14,000 organizations, including JetBlue, Nordstrom, Siemens, Slack, Takeda, Teach for America, and Twilio, trust Okta to help protect the identities of their workforces and customers.

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

Okta 
[press@okta.com](mailto:press@okta.com) 

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

**Disclaimer:**
Research reports and related summaries referenced herein are provided for informational purposes only, and consist of the opinions of the organizations publishing such research and should not be construed as statements of fact. Okta and Auth0 make no representations, warranties, or other assurances with respect to such research.

[^1]: Public Sector Predictions 2022, Forrester Research, Inc., November 3, 2021.

Auth0 Public Sector Index Shows Governments Struggle to Provide Trustworthy Online Citizen Services

andrea-chiarelli

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

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

Principal Developer Advocate

Andrea Chiarelli

Learn how to secure an ASP.NET Core Web API by granting access only to authorized users through Auth0 authentication and authorization services.

Having control over who can access your API is a necessary requirement to make your application secure. This article will show you how to restrict access to your ASP.NET Core Web API to authorized users only.

## Setting up the Web API Application

Let's start by setting up the ASP.NET Core Web API application to be protected. You can download a glossary Web API from [this GitHub repository](https://github.com/auth0-blog/glossary-web-api-aspnet/tree/starter) by running the following command in a terminal window:

```bash
git clone --branch starter --single-branch https://github.com/auth0-blog/glossary-web-api-aspnet.git

```

This ASP.NET application provides you with a CRUD Web API to manage a glossary of terms. You can learn the details of its implementation by reading [this article](https://auth0.com/blog/building-aspnet-web-api).

Once you download the application, move to the `glossary-web-api-aspnet` folder and launch it by typing `dotnet run` in a terminal window. By pointing your browser to `https://localhost:5001/swagger`, you should see a page like the following to interactively test the APIs:

![Swagger UI for Web API](https://images.ctfassets.net/23aumh6u8s0i/39X3FZbdleAybhhvH5hCV7/b0276f9319a0a8110fcffc1dd583f602/webapi-swagger-ui.png)

The Web API application allows you to get a list of term definitions or a single term definition. It also lets you create a new definition and modify or delete an existing one.

The current implementation of this glossary Web API allows anyone to perform all the available operations on the glossary. Most probably, you want to allow everyone to get a single glossary item or the full glossary. Still, only authorized users should be enabled to create, update, and delete glossary items.

Let's go and see how to protect these three actions by integrating your ASP.NET Core Web API with [Auth0](https://auth0.com) services.

## Registering the Web API with Auth0

To start securing your API with Auth0, you need an Auth0 account. If you haven't got one, you can <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free one</a>. Now, you can register your Web API through the [Auth0 Dashboard](https://manage.auth0.com/). Move to the [API section of the Dashboard](https://manage.auth0.com/#/apis) and follow these steps:

1. Click on *Create API*
2. Provide a friendly name for your API (for example, *Glossary API*) and a unique identifier in the URL format (for example, *https://glossary.com*)
3. Leave the signing algorithm as RS256 and click the *Create* button

These steps make Auth0 aware of your Web API and will allow you to control access.

> **Note**: While you are in the Auth0 Dashboard, take note of your Auth0 domain. You will need it soon. This is a string in the form `YOUR-TENANT-NAME.auth0.com` where `YOUR-TENANT-NAME` is the name you provided when you created your account with Auth0. For more information, [check the documentation](https://auth0.com/docs/getting-started/the-basics#domains).

<details>
 <summary>Using the Auth0 CLI</summary>
As an alternative to the Dashboard, you can use [the Auth0 CLI](https://auth0.com/blog/introducing-auth0-cli/) to register your API with Auth0.


In this case, [install the CLI on your machine](https://github.com/auth0/auth0-cli#installation) and [configure it to access your Auth0 tenant](https://github.com/auth0/auth0-cli#login). Then, run the following command in a terminal window:

```bash
auth0 apis create --name "Glossary API" --identifier https://glossary.com --scopes ""
```

This command creates an entry for your API with the name *Glossary API* and the unique identifier `https://glossary.com`. You are not specifying any [scope](https://auth0.com/docs/scopes) for this application right now.

Running this command has exactly the same effect as registering your API through the Auth0 Dashboard.

After the registration, you will get an output like the following:

```bash
=== <YOUR_AUTH0_DOMAIN> API created

 ID 60ac3b89f0cd4a003d42e850 
 NAME Glossary API 
 IDENTIFIER https://glossary.com 
 SCOPES 
```

Take note of the values for the `<YOUR_AUTH0_DOMAIN>` placeholder and the identifier.
</details>

## Enabling Authorization Support

The next step is to adapt the ASP.NET Core Web API application's code to use Auth0 authorization services.

### Configuring the Web API

Back in your ASP.NET application, open the `appsettings.json` configuration file and replace its content with the following:

```json
{
 "Logging": {
 "LogLevel": {
 "Default": "Information",
 "Microsoft": "Warning",
 "Microsoft.Hosting.Lifetime": "Information"
 }
 },
 "AllowedHosts": "*",
 "Auth0": {
 "Domain": "YOUR_AUTH0_DOMAIN",
 "Audience": "YOUR_UNIQUE_IDENTIFIER"
 }
}
```

Replace the `YOUR_AUTH0_DOMAIN` placeholder with your Auth0 domain and the `YOUR_UNIQUE_IDENTIFIER` placeholder with the value you provided as a unique identifier of your API (`https://glossary.com`, if you kept the value suggested above).

### Integrating with Auth0

In order to interact with the Auth0 authorization services, your application needs to be able to handle tokens in the [JWT](https://jwt.io/) (*JSON Web Token*) format. You can accomplish this by installing the `Microsoft.AspNetCore.Authentication.JwtBearer` library. Move to your application folder and type the following command in a terminal window:

```bash
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer
```

When the installation is complete, open the `Startup.cs` file and add the `JwtBearer` namespace. The `using` section of the file should look as shown below:

```c#
//Startup.cs
...existing code... 
using Microsoft.OpenApi.Models;
using Microsoft.AspNetCore.Authentication.JwtBearer; //👈 new code

namespace Glossary
{
 //...existing code...
}
```

In the same file, replace the `ConfigureServices()` method of the `Startup` class with the following code:

```c#
//Startup.cs

// ...existing code...
 public void ConfigureServices(IServiceCollection services)
 {
 //👇 new code
 services.AddAuthentication(options =>
 {
 options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
 options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
 }).AddJwtBearer(options =>
 {
 options.Authority = $"https://{Configuration["Auth0:Domain"]}/";
 options.TokenValidationParameters = 
 new Microsoft.IdentityModel.Tokens.TokenValidationParameters
 {
 ValidAudience = Configuration["Auth0:Audience"],
 ValidIssuer = $"{Configuration["Auth0:Domain"]}",
 ValidateLifetime = true,
 };
 });
 //👆 new code

 services.AddControllers();
 services.AddSwaggerGen(c =>
 {
 c.SwaggerDoc("v1", new OpenApiInfo { Title = "Glossary", Version = "v1" });
 });
 }
// ...existing code...
```

You added the authentication service by specifying the JWT bearer scheme. You also configured the JWT handler by using the domain and audience values from the `appsettings.json` configuration file. In particular, you built the authority URL based on the Auth0 domain and set the parameters that allow the access token to be validated. Specifically, a token is considered valid if it meets the following criteria:

- it has the expected audience,
- it was issued by the expected domain,
- it is not expired.

Finally, replace the `Configure()` method of the `Startup` class with the following code:

```c#
//Startup.cs

// ...existing code...
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
 if (env.IsDevelopment())
 {
 app.UseDeveloperExceptionPage();
 }

 app.UseHttpsRedirection();
 app.UseRouting();
 
 app.UseAuthentication(); //👈 new code
 app.UseAuthorization();
 
 app.UseEndpoints(endpoints =>
 {
 endpoints.MapControllers();
 });
}
// ...existing code...
```

Compared to the previous version, you just added the `app.UseAuthentication()` statement to enable authentication for your application.

<details>
 <summary>Why do you need authentication?</summary>
You may wonder why you need to register the authentication middleware in your ASP.NET Web API. After all, you should only manage authorization. The authentication middleware is needed because it is responsible for creating the security context under which the code is running.


Also, the registration order is important: you need to register the authentication middleware before the authorization middleware.

For more details, check out the [ASP.NET Web API authentication and authorization documentation](https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api).
</details>

<include src="Auth0TemplatesForDotnetCTA" />

## Securing the API Endpoints

Almost everything is ready to secure your application. You just need to protect the actions that allow clients to create, update, and delete glossary items. So, open the `GlossaryController.cs` file in the `Controllers` folder and add the `Microsoft.AspNetCore.Authorization` namespace. The `using` section of the file will look like the following:

```c#
//Controllers/GlossaryController.cs
using System;
using System.Collections.Generic;
using Microsoft.AspNetCore.Mvc;
using System.IO;
using Microsoft.AspNetCore.Authorization; //👈 new code

namespace Glossary.Controllers
{
 // ...existing code...
}
```

Now, add the `Authorize` attribute to the `Post()`, `Put()`, and `Delete()` methods. As an example, your `Delete()` method should become like shown below:

```c#
//Controllers/GlossaryController.cs
// ...existing code...
 [HttpDelete]
 [Route("{term}")]
 [Authorize] //👈 new code
 public ActionResult Delete(string term)
 {
 var glossaryItem = Glossary.Find(item =>
 item.Term.Equals(term, StringComparison.InvariantCultureIgnoreCase));

 if (glossaryItem == null)
 {
 return NotFound();
 }
 else
 {
 Glossary.Remove(glossaryItem);
 return NoContent();
 }
 }
// ...existing code...
```

As you can see, the only difference is the `Authorize` attribute.

> **Note**: You may be wondering if the order of the attributes applied to a method or to a controller class matters. Their order is internally defined, and it depends on the stage of the HTTP pipeline they are bound to and on their scope (global, class, or method scope). So, from a syntactical point of view, it doesn't matter if you put, for example, the `Authorize` attribute before or after the `Route` one.
> For more information on this point, check the [official documentation](https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/filters?view=aspnetcore-3.0).

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

## Testing the Secure Web API

In order to ensure that all works as expected, run the application, point your browser to [https://localhost:5001/swagger](https://localhost:5001/swagger), and test the GET action on the `api/Glossary` endpoint. You should get the list of term definitions as before.

### Testing unauthorized accesses

Now, try to add a new item to the glossary by using the POST action on the `api/Glossary` endpoint as shown in the following picture:

![Calling HTTP POST on the Glossary Web API](https://images.ctfassets.net/23aumh6u8s0i/2Wj5qH5QGMcZC82KC47HVM/758a0589e4254ff6a013deb48808cba7/post-webapi-swagger-ui.png)

This time you should get a `401 Unauthorized` HTTP status code, as shown below:

![Unauthorized response from the Web API](https://images.ctfassets.net/23aumh6u8s0i/4GB1MoOEZ3VoKRddc5Vwxi/0510cf8164263b15d188fc5ab5751424/unauthorized-response.png)

This means that your endpoint is protected: only authorized users can add a new definition to the list. So, in order to add a new item to the glossary, you need to get an access token from Auth0 and make a request to the API endpoint using the [Bearer Authorization scheme](https://www.rfc-editor.org/rfc/rfc6750.html).

### Testing authorized accesses

However, before going ahead, you need a way to provide your access token to the interactive web API documentation. To achieve this goal, edit the `Startup.cs` file and apply the changes shown in the following code snippet to the `ConfigureServices()` method:

```csharp
//Startup.cs
// ...existing code...
 public void ConfigureServices(IServiceCollection services)
 {

 // ...existing code...
 services.AddControllers();

 services.AddSwaggerGen(c =>
 {
 c.SwaggerDoc("v1", new OpenApiInfo { Title = "MyProject", Version = "v1.0.0" });

 //👇 new code
 var securitySchema = new OpenApiSecurityScheme
 {
 Description = "Using the Authorization header with the Bearer scheme.",
 Name = "Authorization",
 In = ParameterLocation.Header,
 Type = SecuritySchemeType.Http,
 Scheme = "bearer",
 Reference = new OpenApiReference
 {
 Type = ReferenceType.SecurityScheme,
 Id = "Bearer"
 }
 };

 c.AddSecurityDefinition("Bearer", securitySchema);

 c.AddSecurityRequirement(new OpenApiSecurityRequirement
 {
 { securitySchema, new[] { "Bearer" } }
 });
 //👆 new code
 });
 }
// ...existing code...
```

You added a few additional configuration options to your API's Swagger instance. In particular, you defined a security schema and added it to the generated documentation as a security requirement.

Now, restart your ASP.NET Core Web API and take a look at the web page shown at the address [https://localhost:5001/swagger](https://localhost:5001/swagger):

![Protected Web APIs in Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/1rNBChKdbCr9fKdpbbYcKR/014f6ace0411febc726959cd88ed8e6a/protected-swagger-ui-webapi.png)

You see the new *Authorize* button and the lock icon on each action. You can configure Swagger to get a more accurate UI, but this topic is out of the scope of this article. Please check out [the official documentation for more details](https://github.com/domaindrivendev/Swashbuckle.AspNetCore#add-security-definitions-and-requirements).

At this point, let's get the access token from Auth0. The simplest way is to access [the API section of your Auth0 Dashboard](https://manage.auth0.com/#/apis) again, select the API that you created before and select the *Test* tab. In this section, you can get a temporary token to test your Web API by clicking the *Copy Token* icon as shown in the following picture:

![Copying temporary token from the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/1FENUfKNw5FrmexhvdWwv5/bb1c283a019dc0fd7322e357efd1bdb2/copy-token.png)

Now, head back to your browser and click the *Authorize* button. A window dialog opens, as shown in the following picture:

![Configure access token for Swagger UI](https://images.ctfassets.net/23aumh6u8s0i/18f9kh3tBXiOMbxjSA7j1k/c0ab1d1475b75ef51a50a1009ea3c5c1/access-token-swagger-ui.png)

Paste the token you copied from the Auth0 Dashboard into the text box and click *Authorize*.

With this step, you have configured the interactive documentation to add the Authorization header to each HTTP request. That header's value will be the access token in the form of a bearer token.

If you try to add a new glossary term through the POST action, you should get a successful `201 Created` HTTP status code as before securing the API. The following picture shows an example of such a response:

![A successful response from the protected Web API](https://images.ctfassets.net/23aumh6u8s0i/2iY4mvFFAZGrDcpXKZiFPU/b0f0b3d576e9d0fc19e7fc7574e089a3/success-response-webapi-post.png)

Now your Web API is ready to be securely consumed by clients.

## Recap

This article showed you how to protect your ASP.NET Core Web API to prevent unauthorized users from accessing specific endpoints. You learned how to register your Web API application with Auth0, how to enable your ASP.NET application to support authorization, and how to use the autogenerated interactive documentation to test the endpoints.

You can download the full source code of the application from [GitHub](https://github.com/auth0-blog/glossary-web-api-aspnet/tree/add-authorization).

Authorization for ASP.NET Core Web APIs

square-2

I develop software for a living, and then I go home and continue thinking about software because I just can’t get enough. I’m a full-stack engineer with infrastructure skills. I’ve led multiple agile delivery teams, being an individual contributor, driving architecture topics, and coaching and supporting other team members. 
I believe in high-quality software and advocate for Continuous Delivery, Test-Driven Development, and quick iteration. I <a href="https://hceris.com/blog">write</a> and <a href="https://hceris.com/talks">speak</a> about my experience regularly. Needless to say, all the opinions expressed in this blog are mine and only mine.

Staff Engineer

Mario Fernandez

Learn how to secure an API written using Ruby On Rails with Auth0 authorization services.

If you want to expose an API publicly on the Internet, authorization will be a requirement for you sooner or later. You want to verify that the client consuming the API has the appropriate permissions.

This guide is exactly about that. We'll be securing an API written using [Ruby On Rails](https://rubyonrails.org/), with [Auth0](https://auth0.com/) as the authorization server.

There's a repository with the code so that you can follow along in [Github](https://github.com/auth0-blog/rails-api-auth0).

## Securing an API

I didn't explain what I mean by securing an API yet. Essentially, we're ensuring that protected routes are accessible only for the users with enough rights.

When it comes to security, it's generally considered a bad idea to roll your own bespoke implementation. Instead, I'm using [OAuth](https://auth0.com/docs/protocols/protocol-oauth2), a battle-tested and widely used authorization framework for web applications.

In this context, Auth0 fulfills the role of the _authorization server_ and abstracts a significant part of the work away from us. That way, we can focus on delivering value to our users.

Without getting into too many details on how OAuth works, we assume that calls to our API will include a bearer token using the industry-standard [JWT](https://jwt.io/) format. The token contains a series of claims regarding its issuer, how long it is valid, and what rights it grants. Let's have a look at a sample token:

```json
{
 "iss": "https://yourTenant.eu.auth0.com/",
 "sub": "zHwnsh0j2sTj4u3ss6YedSFrzyb2",
 "aud": "https://targetAudience.com",
 "iat": 1621369130,
 "exp": 1791455530,
 "azp": "ThEkgdG1NndLlWoNMcEdEr2KJIs9vKad",
 "scope": "openid profile read:admin-messages",
 "permissions": ["read:admin-messages"]
}
```

We're going to implement verification for that token and reject requests that don't have the required permissions.

## Getting Started

We're getting started with our base application, bootstrapped with Rails 6. This [branch](https://github.com/auth0-blog/rails-api-auth0/tree/starter) is a good starting point. You can download it by running the following command in a terminal window:

```shell
git clone -b starter --single-branch https://github.com/auth0-blog/rails-api-auth0.git
```

The API has three endpoints with different levels of protection:

- `/api/messages/public`: Public route.
- `/api/messages/protected`: Requires a valid access token.
- `/api/messages/admin`: Requires a valid access token. Since Auth0 uses JWT as its access token format, we can inspect it and make sure it has a `permissions` claim that contains the scope `read:admin-messages`.

### Running the Application

To run the application, we first need the correct ruby version. The easiest way to do so is to use a version manager like [rbenv](https://github.com/rbenv/rbenv). Once you install it, run this command inside the repository to install the right version of ruby:

```shell
rbenv install
```

Install the dependencies for the application:

```shell
bundle install
```

And finally, run the application:

```shell
bin/rails s
```

You can verify that the application is working correctly with `curl`:

```shell
curl localhost:6060/api/messages/public
```

The command will return a 200 code, plus the message:

```json
{"message": "The API doesn't require an access token to share this message."}
```

### Creating an API on Auth0

To secure the API with Auth0, you need an Auth0 account. If you haven't one, you can <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 free</a> right now. In the *APIs* section of the [Auth0 dashboard](https://manage.auth0.com/), click *Create API*. Provide a name and an identifier for your API. You will use the identifier as an `audience` later, when you are configuring the access token verification. Leave the *Signing Algorithm* as RS256.

![Create API](https://images.ctfassets.net/23aumh6u8s0i/5y9rQHvjBzjxQo5aDIrsKE/842c2fadf99e521fc20a8326dfa8ee2e/create-auth0-api.png)

Once you create the API, go to the _Permissions_ tab in the API details and add a permission called `read:admin-messages`.

![Create permission](https://images.ctfassets.net/23aumh6u8s0i/jT9dzB4AcCM0BAoYgCizu/2abc44d5604d03267b957281e93749a8/configure-permissions.png)

> **Note**: While you are in the Auth0 Dashboard, take note of your Auth0 domain. You will need it soon. This is a string in the form `YOUR-TENANT-NAME.auth0.com` where `YOUR-TENANT-NAME` is the name you provided when you created your account with Auth0. For more information, [check the documentation](https://auth0.com/docs/getting-started/the-basics#domains).

## Preparing the Application for Validation

Alright, our application is ready to go and in dire need of some _security_. Before that, we need to add some configurations.

You dutifully stored the `domain` and the `audience` after creating the API, right? Let's use them. In the _Rails_ world, the convention is to add this in the `config` folder, using [YAML](https://yaml.org/). The file is called `config/auth0.yml`.

We don't want to store credentials in our code, so we'll export the values as environment variables, named `AUTH0_DOMAIN` and `AUTH0_AUDIENCE`. The configuration uses those values and keeps them safely away from source control!

```yaml
development:
 issuerUri: <%= ENV["AUTH0_DOMAIN"] %>
 audience: <%= ENV["AUTH0_AUDIENCE"] %>
```

Now, set `AUTH0_DOMAIN` and `AUTH0_AUDIENCE` environment variables to the `domain` and `audience` values for your API.

With this, the application is ready to connect with Auth0. Let's move on to the implementation.

## Validating the Access Token

Before we get started, let's talk for a second about authentication frameworks for rails. There are a bunch of alternatives in the ecosystem, such as [CanCanCan](https://github.com/CanCanCommunity/cancancan), or [devise](https://github.com/heartcombo/devise).

However, our case is an awkward fit for those. We don't want to take over user management. We only want to validate tokens issued by the authorization server. In this case, using a framework won't bring us as much benefit as something like, say, [Spring Security](https://spring.io/projects/spring-security). That's why we only rely on an extra gem, [jwt](https://github.com/jwt/ruby-jwt).

The code implementing the authorization check lives in the [add-authorization](https://github.com/auth0-blog/rails-api-auth0/tree/add-authorization) branch. Let's see how it works!

### Utilizing the JWT Library

The `jwt` library brings a lot of functionality to make our API able to validate and manage tokens in JWT formats like the ones issued by Auth0. We need to do three things:

- We need to fetch the [JWKS](https://auth0.com/docs/tokens/json-web-tokens/json-web-key-sets) configuration from _Auth0_ so that we know what is the public key to verify the access token signature
- With the public key, the issuer, and the audience, we want to verify the token
- After verifying the token, we're decoding it to access the `permissions` claim (or any other information contained in the token, really)

### Decoding the Token

Let's get down to business. We're implementing the verification/decoding logic in the `lib` folder, in a file called `json_web_token.rb`. We're starting by fetching the _JWKS_ data:

```ruby
# lib/json_web_token.rb
require 'jwt'
require 'net/http'

class JsonWebToken
 class << self
 def algorithm
 'RS256'
 end

 def key(header)
 jwks_hash[header['kid']]
 end

 def jwks_hash
 jwks_raw = Net::HTTP.get URI("#{issuer}.well-known/jwks.json")
 jwks_keys = Array(JSON.parse(jwks_raw)['keys'])
 jwks_keys.map do |k|
 [
 k['kid'],
 OpenSSL::X509::Certificate.new(Base64.decode64(k['x5c'].first)).public_key
 ]
 end.to_h
 end

 def issuer
 "https://#{Rails.application.config.x.auth0.issuerUri}/"
 end
 end
end
```

As you can see, through the `issuerUri` we know where to look for the data. Then, we parse the key so that we can consume it in the library.

The next step is to add an extra method to the class, `verify`, that verifies and decodes the token at the same time:

```ruby
# lib/json_web_token.rb
class JsonWebToken
 class << self
 def verify(token)
 JWT.decode(token, nil,
 true, # Verify the signature of this token
 algorithm: algorithm,
 iss: Rails.application.config.x.auth0.issuerUri,
 verify_iss: true,
 aud: Rails.application.config.x.auth0.audience,
 verify_aud: true) do |header|
 key(header)
 end
 end
 
 # ... existing code ...
 
 end
end
```

This is all the code that we need for the actual verification. Neat, isn't it? But our controllers are still insecure. Not for long, though.

## Protecting the Endpoints

To make it as convenient as possible, we're creating a hook that we're going to run before any route that needs authentication. To make it available for every controller, it lives in the `app/controllers/application_controller.rb`:

```ruby
# app/controllers/application_controller.rb
require 'json_web_token'

class ApplicationController < ActionController::API
 def authorize!
 valid, result = verify(raw_token(request.headers))

 head :unauthorized unless valid

 @token ||= result
 end

 private

 def verify(token)
 payload, = JsonWebToken.verify(token)
 [true, payload]
 rescue JWT::DecodeError => e
 [false, e]
 end

 def raw_token(headers)
 return headers['Authorization'].split.last if headers['Authorization'].present?

 nil
 end
end
```

We take the token from the standard _Authorization_ header. Then, we verify it with the code from the previous section. There are two possible paths after running `authorize!`:

- If the token isn't there, or it's invalid for any reason, the processing stops right there, and the call returns a 401
- If the token is valid, we continue the execution and store the token in `@token` so that it's available

We're protecting both the `protected` and the `admin` routes with this hook, thanks to [before_action](https://api.rubyonrails.org/v6.1.4/classes/AbstractController/Callbacks/ClassMethods.html#method-i-before_action):

```ruby
# app/controllers/api/messages_controller.rb
module Api
 class MessagesController < ApplicationController
 before_action :authorize!, except: %i[public]
end
```

### Custom Error Messages

Don't you feel better knowing that the application is not exposing private stuff anymore? I definitely do. But we got to help our users. A blank 401 message might not give them enough information to debug the issue. Let's extend the hook to return something more explicit:

```ruby
# app/controllers/application_controller.rb
class ApplicationController < ActionController::API
 def authorize!
 valid, result = verify(raw_token(request.headers))

 # 👇 old code
 # head :unauthorized unless valid
 # 👇 new code
 render json: { message: result }.to_json, status: :unauthorized unless valid

 @token ||= result
 end
```

Now we get a message that's more helpful than an HTTP code without a body.

## Testing the Protected Endpoints

Let's test the protected endpoint:

```shell
curl localhost:6060/api/messages/protected
```

The command will return a 401, because we're not authorized. We need to get a valid token from Auth0.

The simplest way is to access the [API section of your Auth0 Dashboard](https://manage.auth0.com/#/apis) again, select the API that you created before and click the *Test* tab. In this section, you can get a temporary token to test your Web API by clicking the *Copy Token* icon as shown in the following picture:

![Test Token](https://images.ctfassets.net/23aumh6u8s0i/6zmU9XWwgZLWIAFF0qu6IP/50e2aa27469142c138b814731aa0233d/copy-access-token.png)

Let's attach the token to the request:

```shell
export TOKEN=the-test-token
curl localhost:6060/api/messages/protected -H "Authorization: Bearer $TOKEN"
```

The request works now! 

```json
{"message": "The API successfully validated your access token."}
```

## Checking for permissions

There's one requirement pending. As you might recall, for `/api/messages/admin` a valid token isn't enough. Rather, we expect the correct permission in the `permissions` claim. This extra check allows us to define more granular access criteria for our endpoints. This functionality is implemented in the [add-rbac](https://github.com/auth0-blog/rails-api-auth0/tree/add-rbac) branch.

We're adding a new method in the `application_controller`, `check_permissions`. It takes the decoded token and looks for a given permission:

```ruby
# app/controllers/application_controller.rb
require 'json_web_token'

class ApplicationController < ActionController::API
 # ... existing code ...
 
 def can_read_admin_messages!
 check_permissions(@token, 'read:admin-messages')
 end
 
 def check_permissions(token, permission)
 permissions = token['permissions'] || []
 permissions = permissions.split if permissions.is_a? String

 unless permissions.include?(permission)
 render json: { message: 'Access is denied' }.to_json,
 status: :unauthorized
 end
 end
 
 # ... existing code ...
end
```

We use a `before_action` again to protect the `admin` endpoint:

```ruby
# app/controllers/api/messages_controller.rb
module Api
 class MessagesController < ApplicationController
 before_action :can_read_admin_messages!, only: %i[admin]
 
 # ... existing code ...
end
```

With this, each route in our sample application is safe the way we wanted.

### Testing Permissions

If you try to call the `/api/messages/admin` endpoint with the token we generated before, it will return a 401. Our token is valid but doesn't have the necessary permissions. Let's create a new one!

Back in your [API configuration page on the Auth0 Dashboard](https://manage.auth0.com/#/apis), select the *Machine to Machine Applications* tab. You'll get a list of applications, some of them with the *(Test Application)* label in the name. These applications are automatically created by Auth0 when you create an API there. They are meant as test clients from your API. One of them should have the *Authorized* switch on. Click the dropdown next to it and check the `read:admin-messages` permission:

![Adding Permissions](https://images.ctfassets.net/23aumh6u8s0i/2Iva8EtxfjdsunLbDTGVyD/71034bf799e82e51c7e5f7152ccd6adf/adding-permissions.png)

Then, click the *Update* button, move again to the *Test* tab, and copy the new token that has been generated for you. Let's try again:

```shell
export TOKEN=the-new-test-token
curl localhost:6060/api/messages/admin -H "Authorization: Bearer $TOKEN"
```

The request works now!

```json
{"message":"The API successfully recognized you as an admin."}
```

## Conclusion

In this guide, we've added authorization to a Rails API by using Auth0 as an authorization server. Thanks to the `jwt` gem, we don't have to invest much effort. We use the library to decode the bearer token that the API receives. After that, it's a matter of checking the relevant routes before each request.

Secure a Rails API with Auth0

shafiq-shivji

Shafiq leads Product Marketing for Auth0's Ecosystem and Extensibility domains. He brings vast experience from previous roles as a Product Manager and Sales Engineer working in adjacent SaaS industries like machine learning, web/mobile apps, and communications. He especially enjoys the creative process of conceiving and taking high-impact products to market.

Product Marketing Manager

Shafiq Shivji

Log streaming helps you respond to incidents in near real-time

You've probably heard the expression, "You don't know what you don't know." In other words, if you don't have access to all the usable data you need to inform business decisions, you won't even realize how much is missing from the equation. You need timely insights to empower your teams to work more effectively and deliver more value to users.

People around the world are spending an unprecedented amount of time working remotely and online. We use our personal devices to check in with work; we use our work devices in our homes. Considering all this, real-time monitoring and alerting is more critical than ever. In today's cloud-centric world, it's essential that engineering, architecture, and security teams have the tools they need to monitor their environments consistently, so they can respond to incidents and adapt to trends as close to real-time as possible.

## What Is Log Streaming?

A [log streaming service like Auth0's](https://auth0.com/docs/logs/streams) automatically saves logs to a third-party tool for storage and analysis, so you have the data you need to respond in near real-time to security threats, performance outages, and other issues. Event logs contain valuable insights about user activity, which makes them an important resource for improving operational health and security. Here are some key functionalities enabled by event logs:

* Troubleshooting connectivity problems
* Identifying configuration areas that could use performance improvements
* Identifying where and why service disruptions occurred
* Exposing metrics to identify a target audience
* Pinpointing prime usage times by region
* Identifying bad actors by IP address
* Detecting and optimizing user behavior patterns
* Enabling debugging and integration setup by exposing where customers are experiencing pain and where the flow may be broken

Auth0's log streaming service lets you stream events to a host of integration partners, such as Amazon EventBridge, or any given URL. Log streaming allows you to:

* Export logs to a tool or service you already use
* React to events, such as changed passwords or new registrations, with your own business logic by sending events to custom webhooks (for instance, you can use log streaming to drive automated marketing campaigns upon signup)
* Send events to Amazon EventBridge for processing with AWS Lambda or additional data pipelines

Without log streaming, you don't have the information you need to respond promptly when intervention is called for.

## See Critical Identity Information in Near Real-Time

Auth0's log streaming service gives you access to mission-critical information &mdash; identity activity, identity security, account operations, and more &mdash; in near real-time. With log streaming, you can continuously export tenant log events to your existing monitoring and alerting dashboards, streamlining operations, and realizing deeper insights into user behavior.

Auth0 log streaming works by sending micro-batches of streaming events as they are generated in Auth0, giving customers up-to-date information about their Auth0 tenant. Implementing log streaming delivers scalable, resilient, and low-latency access to your Auth0 events.

### Make informed development decisions

Tracking trends over time allows you to make informed decisions about product development and system architecture. For example, authentication data can be used to determine how to prioritize development resources: If more users are authenticating from mobile devices, mobile development goes to the top of your priority list.

Another example is tracking peak login times by geographic location to help system architecture teams determine when and where to scale up resources. The ability to scale rapidly allows you to change your IT deployments to support your current needs, so your developers can focus on adding value instead of tinkering endlessly with your infrastructure. Fast scalability is also crucial for delivering a smooth user experience in response to short-term events like Election Day or the World Cup.

### Respond to performance and security incidents immediately

Tracking identity information helps you detect and respond to security incidents and performance issues before they do too much damage. Equipped with the right information, your security team can configure thresholds and set up alerts to notify them when suspicious events or patterns are detected, enabling faster response times.

Whether it's general operational health or security, teams often rely on a rapid visual analysis to differentiate between normal and abnormal states and determine when they need to deep-dive to investigate and resolve potential issues. For instance, a massive spike in the number of unsuccessful login attempts could indicate an ongoing [credential stuffing attack](https://auth0.com/blog/what-is-credential-stuffing/) &mdash; one of the most common and damaging ways you can expect attackers to target your infrastructure.

Event logs also yield insights into performance issues and outages, so you can understand what went wrong, who's affected, and how to fix things before your customers experience pain.

## Manage Log Streaming With Auth0 Marketplace

An inherently extensible platform like Auth0 enables users to customize identity flows and integrate with third-party solutions to meet specific business needs &mdash; now and in the future. [Extensibility](https://auth0.com/resources/whitepapers/tao-of-extensibility) describes a system's capacity to support future growth via new functionalities and use cases, as well as the level of effort required to implement those extensions. 

Opening up our platform to third-party, partner-built integrations via [Auth0 Marketplace](https://marketplace.auth0.com/) accelerates innovation for Auth0, our customers, and our partners. The ecosystem gives our customers the tools they need to solve the range of use cases they encounter. With [Marketplace](https://auth0.com/blog/introducing-auth0-marketplace/), developers get more integrations to support more use cases, and vendors have more opportunities to capture business and deliver value. For vendors who haven't yet built integrations with Auth0, Marketplace creates that opportunity.

To provide our customers with enhanced security and operational and monitoring insights, Auth0 has partnered with the [following companies](https://marketplace.auth0.com/features/log-streaming):

### Amazon EventBridge

[Amazon EventBridge](https://marketplace.auth0.com/integrations/amazon-log-streaming) makes it easy to connect applications using data from your own apps, integrated SaaS apps, and AWS services. EventBridge delivers a stream of real-time data from event sources like Datadog, Pagerduty, or Zendesk, then routes that data to targets like AWS Lambda.

With EventBridge, you can set up routing rules to determine where to send your data to build application architectures that react in real-time to all of your data sources. EventBridge takes care of event ingestion and delivery, security, authorization, and error handling for you, making it easy to build event-driven applications.

### Azure Event Grid

[Azure Event Grid](https://marketplace.auth0.com/integrations/azure-log-streaming) simplifies event-based apps by providing a single service for managing routing of all events from any source to any destination. Designed for high availability, consistent performance, and dynamic scale, Event Grid lets you focus on your app logic rather than your infrastructure.

Event Grid simplifies event delivery by allowing you to build scalable serverless applications, microservices, and distributed systems. By using Event Grid to capitalize on guaranteed event delivery and high availability on the cloud, you can build better-performing, more reliable applications through reactive programming. Finally, Event Grid allows you to focus more resources on innovation: Connecting multiple possible sources and destinations of events helps you develop richer application scenarios.

### Datadog

[Datadog](https://marketplace.auth0.com/integrations/datadog-log-streaming) (NASDAQ: DDOG) is a monitoring and analytics platform for cloud applications that has become a critical enabler for many companies. Engineering, infrastructure, and security teams use Datadog to unify data from servers, containers, databases, and third-party services to make the stack entirely observable.

With this integration, Auth0 and Datadog combine resources to deliver mission-critical identity information to our joint customers. The integration allows customers to incorporate Auth0 logs into their existing monitoring and alerting dashboards without additional engineering work. Users can collect and visualize Auth0 data in order to identify trends &mdash; all without extra development time.

With Auth0-Datadog integration, engineering teams can visualize error rates and traffic data. Security teams can visualize authorization traffic and set up alerts for high-risk actions. Infrastructure teams can ensure stability by visualizing performance metrics and traffic data. For all of these use cases, identity data furnishes crucial insights, and the Auth0-Datadog integration helps you make full use of that information.

## Perch Security

[Perch Security](https://marketplace.auth0.com/integrations/perch-security-log-streaming) allows you to add managed threat detection and SIEM (security information and event management) without changing your existing stack. Perch Security is fast and simple to deploy, supports multitenancy and third-party integrations, and is backed by a 24/7 U.S.-based security operations center. 

With Perch, you receive alerts about atypical and potentially malicious events that happen within your Auth0 environment. You can also generate reports based on the log data collected from your Auth0 environment and retain those logs for future reference and to help satisfy auditory or regulatory requirements.

### Splunk

[Splunk](https://marketplace.auth0.com/integrations/splunk-log-streaming) is a data platform that allows companies to analyze data in any structure, from any source, across any timescale. Not only does Splunk make it easy for companies to understand the health of their operating system in terms of performance and traffic, but it also offers robust SIEM and SOAR (security orchestration, automation, and response) capabilities via Splunk Enterprise Security and Splunk Phantom. These capabilities encompass monitoring, detection, security, threat detection, and workflow automation.

Auth0's event data provides rich contextual information to help our customers make informed decisions about system architecture and development. The Splunk integration enables Auth0 to deliver mission-critical identity information in a fast, scalable way. Our shared customers can easily leverage this information to make more informed decisions. The integration also allows for easy visualization of security and operational signals from Auth0 within Splunk Cloud and Splunk Enterprise since customers can now incorporate Auth0 event logs into their existing Splunk environments with minimal engineering work.

In addition, the integration allows customers to build workflows to improve security posture by leveraging Auth0's event logs and Splunk's SOAR capabilities. For example, security teams can create a playbook within Splunk Phantom for Auth0's breached password detection event logs to automatically block an account and force the user to reset their password, all without any manual interaction. Security teams can also leverage security-specific events to automatically trigger proactive investigation and mitigation. 

As part of this integration, Auth0 has created a custom Splunk dashboard that automatically visualizes critical security signals coming from Auth0. This allows security teams to monitor authorization traffic, analyze anomalies, and set up alerts for high-risk actions with greater confidence.

## Meeting Tomorrow’s Identity Needs

With Auth0 Marketplace, we're recruiting best-in-class technology partners to innovate on our platform because we know that's the best way to give you the tools you need to solve whatever identity puzzles lie ahead.

To learn how to integrate with our log streaming partners, [start here](https://marketplace.auth0.com/features/log-streaming).

<include src="asides/AboutAuth0" />

Log Streaming: What It Is and Why It Matters

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

jameeka_aron

Jameeka has over 20 years of Information Technology and Cyber Security experience. She is a versatile leader, successfully leading teams as both a CISO and CIO across various industries including; Aerospace & Defense, Apparel, Retail, and Manufacturing at both Fortune 100 and privately held companies and many spaces in between. 
She is highly skilled in Business Engagement (International and U.S. based) Audit, Compliance, Vulnerability, Risk and Identity Management, Digital Transformation, Mergers, Acquisitions, Divestitures, and leading Cross-Functional and Matrixed teams.

CISO

Jameeka Aaron

Rapid change introduces workforce and app risks. Auth0 Security team’s advice on what to fix now.

Fast response allowed many organizations to survive and thrive in 2020. Orgs went remote overnight; businesses launched consumer-facing apps, and [consumers shifted buying patterns online](https://auth0.com/blog/how-brick-and-mortar-approaches-improve-digital-experiences/).

Going fast gets products to market, it gives consumers choices, and it helps companies scale. But when you jump ahead seven to 10 years in your digital road map, you risk leaving a few security and data privacy concerns behind. I reached out to key members of my security team, as well as our data privacy team, to put together this three-part series based on our industry experience and observations.

Each post will focus on protecting and securing two critical areas: your workforce and your consumer-facing apps. The first post will focus on security details to check and mitigate now. The second will focus on immediate data privacy concerns with the help of Auth0 Vice President, Privacy Lucy McGrath. And the third post will help you put together a plan for the future that will make it easier the next time you want to turn on the speed — and to remain current in an ever-changing security landscape.

The thing is that security is a global team sport. As more of us shift to working and living online, everything is more connected — and that can be a good thing. Securing your personal identity, your business identity, and helping increase security at your business can actually make an impact. Here’s what you can do to help make the internet safer for everyone.

## Why Remote Work Forced a Change in Security Thinking

Before the world started working remotely, a lot of companies used a castle-and-moat approach to security. They relied on a combination of physical security and internal networks to ensure that employees and outsiders only accessed necessary information. They might even have relied on SaaS companies to provide some of their protections, but the thinking was still pretty much “protect the castle.”

Suddenly workers were working anywhere in the world, maybe on their own devices. Without remote experience, your security team might not have had time to think through all of the security issues inherent with having remote endpoints. For example, to ensure that they properly protect these assets against current threats like ransomware and malware, it would be appropriate to install leading next-gen antivirus on these machines.

Role-based privileges and policies also abruptly needed to follow the user. I know I work for an identity company, but it was identity and policy [federation](https://auth0.com/blog/why-identity-federation-matters/) that anticipated this need and allowed for a rapid response.

[Now some companies are making work from home a permanent](https://www.businessinsider.com/companies-asking-employees-to-work-from-home-due-to-coronavirus-2020) part of their employee offering. Since Auth0 was built as a remote-friendly, globally dispersed company, we’ve had some time to think through the security concerns. Here’s what you need to consider to protect your customers, your business, and your employees:

1. **Secure the endpoints.** Services like CarbonBlack or CrowdStrike can help prevent malware or breaches occurring from endpoints.
2. **Update bring your own device policies.** Rethink how and where employees are accessing business and customer data. Do you need to restrict access in public spaces? Adjust policies?
3. **Update action policies**. What do your employees do if a work computer is stolen? What steps do they need to take if the information is exposed at home? A [1Password survey](https://www.darkreading.com/51--of-wfh-parents-say-children-have-accessed-work-accounts/d/d-id/1339754) found that 51% of work from home (WFH) parents surveyed said their children had accessed their work accounts, sometimes accidentally deleting necessary files. How can you support your employees??
4. **Human risk is increased.** Have a look at the next section.

## The Human Element

This is the critical part of this series — **the human element is the most important aspect of security and data privacy.**

> Security awareness training needs to happen at every single level of your organization.

A malicious actor is going to use everything you need to do business — email address patterns, information on your website, social media posts, and items gleaned from news articles all to try to gain entry to your system. While the attacks will vary, they usually follow this pattern: **human factor** + inject something into the code + lack of input validation + insufficient logging and monitoring.

If something looks like it’s coming from your CEO or payroll, an employee might fall for it and supply a way into your system. And once a bad actor is in, there’s lots they can do.

But if you train your entire team to watch out for phishing attacks, you can stop them at the first step. [This post is a good place to start.](https://auth0.com/blog/protecting-against-phishing-attacks/)

Attacks evolve, so even though security awareness is something you should pause and do now, it’s something you’re going to need to do regularly. Developing a security culture throughout your org provides great protection. To do business with some industries like finance or healthcare, the training will be required to cover specific areas and will need to be documented. The training you provide can also help protect your employees in their personal lives.

## Top 7 Things to Do Now to Check Your App’s Security

This can seem like a lot if you don’t have an in-house security team (and maybe if you do). One principle of security is encouraging diversity of thought not only because it’s the right thing to do but because studies show it makes teams more productive. In security, [diversity of thought](https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/innovation-in-a-crisis-why-it-is-more-critical-than-ever) makes it easier to spot potential threats. This is part of why even large teams rely on external testing vendors and may even need to provide proof of outside testing for certifications like [CSA Star](https://auth0.com/blog/the-csa-star-program-a-business-guide-to-certification/) and [PCI](https://auth0.com/blog/what-is-pci-a-business-guide-to-compliance/).

1. **Get an external third-party pen test — and implement the recommendations**. A penetration test is where you hire a verified third party to attempt to find your app’s vulnerabilities. They will sign a non-disclosure agreement (NDA) and provide a detailed report outlining their findings and usually with recommended fixes cataloged by severity. Discovering vulnerabilities can be scary, and there is the temptation to use fear to drive organizational change, but we’ve found that partnering and collaborating with other teams and leadership can often get changes implemented faster. 
2. **Review best practices for your cloud-based services.** When people go really fast, they may not take the time to fully understand the technology and security controls. This is a great time to go back and pay really close attention to the docs provided by your third-party vendors.

> “Many common AWS security issues, for example, happen as a result of not following AWS security best practice guidelines when setting up the infrastructure. This can lead to open and accessible EC2 security groups, public S3 buckets, unprotected EMR clusters, and more,” says Auth0 Detection and Response Security Engineer Troy Wegner (formerly of AWS and Amazon.com).

3. **[Perform static](https://www.overops.com/blog/static-vs-dynamic-code-analysis-how-to-choose-between-them/) and [dynamic code analysis](https://www.overops.com/blog/static-vs-dynamic-code-analysis-how-to-choose-between-them/)**. Static analysis reviews the code as it exists. Dynamic analysis looks for vulnerabilities while the code is being executed and for unexpected outcomes. Ideally, you want to move towards baking both into your Software Development Lifecycle (SDLC). Devs may not always enjoy adding this to part of their process—more on how to add this analysis to your long-term software development plans in the final post.
4. **Think through vulnerability management and updates**. Since humans are fallible and it’s humans who make code, it’s inevitable that you’re going to run into vulnerabilities. If you don’t have a plan for pushing updates, now’s the time to make one so you don’t hear about something BIG like the [Heartbleed Bug](https://www.vox.com/2014/6/19/18076318/heartbleed) and find yourself painfully updating ad-hoc.

> In general, you’re going to need to test every time your devs update something and whenever your tech stack libraries or any of the main operating systems updates. Services like Chef, Puppet and Terraform can make this easier by pushing updates from a central server to connected servers. In the final post, we’ll get into longer-term strategies for updates, like maintaining a Golden Amazon Machine Image (AMI) if you’re on AWS. For now, just document how and when you’re going to update and test.

5. **Threat model**. A lot of security is determining risks. Ideally, you’ve threat modeled before building your app, but in some ways, it’s easier to model after it’s live. Yes, you can hire a trusted third party to do this for you. To give you a sense of the thought process, I asked Troy to threat model this restaurant scenario. Security engineers often diagram vulnerabilities, so we also include Troy’s whiteboard as a reference.

Let’s say you’re a local restaurant who responded to COVID by offering the ingredients to make your tastiest dishes and recipes to your customers via curbside pickup. You hired someone to put the app together quickly, but now your region is opening up, and you’ve decided this channel of operations should continue contributing to your bottom line. 

![Whiteboard](https://images.ctfassets.net/23aumh6u8s0i/3qWEruezG4YZw2AwS2w4Nf/ccb3121e94d794c8baa0ec470e4b084d/diagram.jpg)
**Figure 1:** _Auth0 Senior Security Engineer - Detection and Response Troy Wegner’s whiteboard of our restaurant scenario._

* Start with authentication because you know customers need to authenticate in order to interact with your app. How are they authenticating? Are they only using a username and password? If they are only using a username and password for authentication, then you have just hit on your first major risk (user compromise/phishing/user impersonation). 
* As a way to address the first risk identified, you have chosen to go with two-factor authentication for your users. But here is where things get interesting; which 2-factor options do you want to support? There are authenticator apps, FIDO U2F, Push-based 2FA, and SMS (the weakest available option). Each option has its own pros and cons to consider.
* Since this is a restaurant, you’re also somehow connecting the app to the food supply. How are you measuring and validating your existing ingredients inventory to ensure you do not oversell based on your total ingredients available? Are you using a database to store this information? If so, where does this database live, is it protected or hardened information security wise, and if so, how is it hardened? How do you authenticate to the database, is it updated regularly, do you perform backups, etc. 
* If your service has gotten really popular, too many people might try to order at once, and that could overwhelm the app’s limits. The app could go down due to resource constraints based on how it is architected. This is basically the risk a DOS/DDOS would present in bringing your app down and making it no longer available to your customers. In order to mitigate a DDOS risk, you might have a plan to make your app more fault tolerant and highly available by using load balancing, increasing back-end servers to handle the load, or using a front-end CDN to help distribute load across various edge locations.
* Most likely, your app is taking payment and processing it in order to fulfill orders; how are customer payment and other sensitive information being handled/stored? If you accept credit cards or debit cards, PCI compliance is a concern you should address.
* Here is where you would now want to think through and fully diagram out the rest of how the app works and uncover any other risks or bottlenecks that currently exist with your app, place a severity on those risks, and determine by severity which risks you want to fix, and which ones you are ok accepting.


6. **Turn on your logs — and make sure they’re monitored**. Turning on logs can seem like common sense, but because there’s often an expense attached to logging and getting the data analyzed, the logs might not always be turned on. It’s really hard to know what to fix after a malware outbreak or other issues occur, especially if your logs aren’t turned on and are being actively analyzed. 

So this is where we tell you to turn on the logs for all the services you’re using. You should also make sure that a trusted third-party vendor or trained security engineer is watching your logs and building actionable detections based on those log sources to look for suspicious or anomalous activity.

7. **Take action**. Logs, vulnerability assessments, pen tests — these things can help you identify what needs to be fixed, but you still need to fix it. Breaches and ransomware are the obvious security problems you want to avoid. How your security challenges impact consumer behavior might not be as clear. Lost conversions, abandoned shopping carts, and low time on site are all indications that your target audience may not feel comfortable sharing their data with you. Our customers tell us that an app or site that feels secure (think smooth login, logical and smooth payment process) supports their business goals.

## If You Need More Help

Authentication is often a critical part of securing an app or workplace. If you’d like to understand how Auth0’s solutions might help make your app more secure, please reach out to the [team at Auth0](https://auth0.com/contact-us).

My next post will focus on immediate data privacy concerns with the help of Auth0 Vice President of Privacy Lucy McGrath.

<include src="asides/AboutAuth0" />

Accelerated Your Road Map? Go Fix Workforce and App Security

Global identity management provider recognized for commitment to government, education, and nonprofit customer success

**BELLEVUE, Wash. – April 14, 2021 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced that it has joined the [Amazon Web Services (AWS) Public Sector Partner (PSP) Program](https://aws.amazon.com/partners/public-sector/). The AWS PSP Program recognizes AWS Partner Network (APN) Partners with solutions and experience in delivering government, education, and nonprofit customer missions around the world.

Auth0 and AWS are teaming up to help serve public sector customers in solving their unique security, privacy, and user experience challenges to meet mandates, reduce costs, drive efficiencies, and accelerate innovation. As an AWS Public Sector Partner, Auth0 now offers its extensible authentication and authorization solutions to the public sector community on the AWS Marketplace. To be selected for the program, Auth0 had to meet pre-defined criteria, including deep expertise and commitment to delivering government, education, and nonprofit services on a global basis. 

“We are honored to join the AWS PSP Program—this recognition reflects Auth0’s commitment to helping the global public sector community,” said Bill Lapcevic, VP of Business Development at Auth0. “As a Public Sector Partner, we are enabling public sector customers to accelerate their business growth on AWS, and are in a unique position to help these customers achieve their cloud security goals as they scale.”

In addition, Auth0 announced the appointment of Dean Scontras, Senior Director of Public Sector Sales, to lead the company’s federal, state, and local business and sales strategy.

“For the public sector, in particular, the onset of COVID-19 has accelerated the transition to digital citizen services, and heightened the need for organizations across all industries to secure their valued assets and data more firmly,” said Scontras. “I’m honored to join the Auth0 team and aid the company’s continued efforts in helping government agencies at the local, state, and federal level as they move towards digital citizen services and the essential role identity will play in that move.” 

Auth0 is an AWS Advanced Technology Partner that is participating in [AWS Public Sector Summit Online](https://aws.amazon.com/events/summits/online/public-sector/?did=ep_card&trk=ep_card), taking place April 15, 2021. To learn more, visit: [https://info.auth0.com/auth0-at-aws-publicsectorsummit-2021.html](https://info.auth0.com/auth0-at-aws-publicsectorsummit-2021.html)

Auth0 achieved the [AWS Security Competency](https://auth0.com/blog/auth0-achieves-aws-security-competency/) status in 2020 and was one of the first AWS Partners to give AWS customers seamless access to [professional services in AWS Marketplace](https://auth0.com/blog/auth0-supports-the-launch-of-professional-services-in-aws-marketplace/). For more information, visit [Auth0’s AWS Partner page](https://partners.amazonaws.com/partners/001E000000YKGRTIA5/Auth0). 

<include src="asides/AboutAuth0" />

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

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

Auth0 Joins the Amazon Web Services Public Sector Partner Program

Your Auth0 implementation will continue to receive the same support and services you have come to expect



Over the last couple of days, following [the announcement that Okta has signed a definitive agreement to acquire Auth0](https://auth0.com/blog/okta-auth0-announcement/), we have seen an outpouring of excitement and celebration from our developer community around the news. We have also been listening closely and have heard concerns from a few developers/customers that they may need to change their production-code or re-engineer their Auth0 implementation. Let me just start by saying thank you for trusting us with your concerns and thank you to the overwhelming number of you who shared your excitement with us.

Now, while I can not make any future-oriented statements about the acquisition, I can tell you that Auth0 is and will continue to invest in the products, SDKs, and developer-centric platform that brought us to this place. In fact, just yesterday, we [announced](https://twitter.com/jamesqquick/status/1367196759026499589) that our new [Next.js SDK](https://github.com/auth0/nextjs-auth0) is live and ready for primetime. You can expect us to ship more exciting products this year and to continue to invest in the core of our platform. 

So let me talk specifically to the builders and developers who are worried their code will need to be re-written. **Your Auth0 implementation will continue to receive the same support and services you have come to expect**, including [99.99% availability](https://auth0.com/blog/auth0-guarantees-99-99-availability-on-public-cloud/). Even after the acquisition is closed, the Auth0 product will remain an independent platform, and it will continue to receive our high levels of investment, development, and support. Aside from regular maintenance of our libraries and tools, which occasionally require code refreshes or updates in the field, you can rest assured that your implementation will operate as expected, whether you are a team of 3,000 engineers or a dev shop of one.

Since 2013 the goal of our product teams has been shipping tools that enable the innovators, the developers, security engineers, the architects, in essence, all of you, to be able to build faster, scale more reliably, and build even better, more secure products for your customers. We at Auth0 are excited to continue to innovate on your behalf and look forward to being able to even better serve you in the future.

-Happy coding and stay healthy, Shiv.


Our Commitment to You, Developers

randy_nasson

Director of Product Management for Customer Identity Cloud (formerly Auth0) in our Identity and Access Management (IAM) domain. I joined Auth0 in 2018 and assembled a world-class IAM product team dedicated to delivering customer value and enabling developers to quickly implement secure, robust, and seamless identity solutions. In addition to my current work with CIC, I regularly work with our Auth0 Lab team on greenfield initiatives and with our Strategic and Technical Partner teams on opportunities to drive revenue.

Director, Product Management (IAM)

Randy Nasson

Delight users while providing a secure CIAM solution for accessing applications and services

## Summary

* Refresh tokens [can be effectively used for maintaining a seamless user experience](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/) in browser-based apps without suffering the limitations imposed by ITP2
* Configuring absolute lifetimes for refresh tokens helps reduce the risk of using RTs in single-page applications
* Inactivity lifetime enables refresh token lifetimes to be extended as long as the end-user interacts with the client within the configured period, resulting in less end-user friction
* **Auth0 now provides both absolute and inactivity lifetimes for refresh tokens, along with more secure refresh token defaults, as of December 16, 2020**
 

## Balancing Security and User Experience

Most businesses want to afford a friction-free experience for end-users when using their applications. Requiring people to manually enter credentials every time they visit a commerce site or open an app can yield frustration and hurt the business bottom line. A common request in business-to-consumer (B2C) industries is to only require users to log in once and then to never require them to log in again unless they are explicitly logged out, either by choice or necessity.

The practice of using long-lived [refresh tokens](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/) paired with short-lived Access Tokens is a common solution to delivering an uninterrupted experience, particularly in native mobile apps. With additional security capabilities such as [Refresh Token Rotation](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/) and [Automatic Reuse Detection](https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/#Automatic-Reuse-Detection), refresh tokens can safely be used in Single Page Applications (SPAs) to afford continuous access on the web.

![Refresh Token](https://images.ctfassets.net/23aumh6u8s0i/6lBzS4ElN5ZEULvNM50Hvi/1a84f912b03d26661286ec71b4016f71/01-image-refresh-token)

## Refresh Token Expiration

However, a refresh token is considered a powerful artifact in identity management. If a refresh token is leaked or stolen, it could be used to acquire a new Access Token. As such, the [OAuth 2.0 Best Current Practices (BCP)](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.12.2) states that refresh tokens **should** expire if the application (client) is inactive for too long, particularly when used in Public Clients (a client that cannot secure its own credentials, such as a native mobile app). This means that refresh tokens should expire at some point in time, but that expiration can be based on activity and not merely an arbitrary point in the future.

When the refresh token expires, it can no longer be used to get a new Access Token. The user will be required to re-authenticate the next time they use the application. More importantly, an attacker’s window for using a leaked token is limited. 

But, what about the business desire for only wanting the end-user to log in once and not again thereafter? For SPAs, this can still be afforded within the OAuth 2.0 BCP guidance provided that the end-user’s activity in the application remains consistent.

Let’s consider an example: A media company publishes content on a regular basis that is only available to authenticated subscribers. In addition, the company sells subscriptions and related goods (books, print media, access to premium video content, etc.) using stored payment methods associated with the account. 

In this scenario, the website is a SPA with Auth0 as the authorization server, and refresh tokens are used to overcome the session limitations incurred by ITP2 or similar privacy mechanisms. Because there is sensitive information in the account, maintaining an indefinite application session is not ideal.

Leveraging absolute lifetimes, end-users can be required to log in again after a predetermined period of time. But that experience is not optimal for the business or the end-user. Requiring re-authentication creates friction between the user and the content or purchases. What if the user could remain logged in as long as they were active in the application on a regular basis, for example, once every two weeks?

## Introducing Inactivity Lifetime

Unlike absolute lifetime, which expires a refresh token after a fixed period, inactivity lifetime extends the expiration period each time the client uses a refresh token to get a new access token. Using the example above, this effectively preserves the seamless user experience as long as there is an activity within the inactivity lifetime.

![Introducing Inactivity Lifetime](https://images.ctfassets.net/23aumh6u8s0i/6vutURQweArCulYsO5eBvL/f54e0ef9f358058bde3b185c474ab814/04-at-expiration-1-day-flow)

As of today, both absolute and inactivity lifetimes for refresh tokens are available for all Auth0 customers hosted in our cloud environment and will be available in December 2020 for private cloud customers. This enables you to configure refresh token lifetimes based on your own app usage data, for example, by evaluating your application log data to determine how often users return to your app so that people who use applications regularly can have that period extended as long as usage remains consistent. 

Auth0 makes it easy to configure refresh token lifetimes using the [Auth0 Management API](https://auth0.com/docs/api/management/v2#!/Clients/post_clients), our [Deploy CLI](https://auth0.com/docs/extensions/deploy-cli-tool), or the Auth0 Dashboard.

![Auth0 Management API](https://images.ctfassets.net/23aumh6u8s0i/4P5VvuP2z41wvUoBDlRzvH/840a1ebbbf639eb0827ad62b4ab645c2/05-refresh-token-expiration)

Inactivity lifetime can be used in all supported refresh token flows and in conjunction with Refresh Token Rotation.

## Using Inactivity and Absolute Lifetimes Together

Both inactivity and absolute lifetimes can be configured on a per-application basis, enabling you to craft experiences to suit the expected usage of your applications.

Setting absolute lifetimes for refresh tokens ensures that refresh tokens cannot be used to retrieve a new access token after the specified period. For example, if you set the absolute lifetime to 30 days, the refresh token issued to the application can be used for up to 30 days from its issuance to retrieve a new access token. If you are leveraging Refresh Token Rotation, the absolute lifetime [applies to the entire token family](https://auth0.com/docs/tokens/refresh-tokens/refresh-token-rotation#automatic-reuse-detection). After the lifetime expires, the user will be required to re-authenticate.

You can also use a combination of absolute and inactivity lifetimes to afford an uninterrupted user experience for much longer durations, provided that the user remains active within the inactivity lifetime. For example, you can set the absolute lifetime to 365 days and the inactivity lifetime to 14 days. This would allow a user who was active in your application at least once every two weeks to continuously stay logged in until the absolute lifetime expires.

You can also use an inactivity lifetime _without_ an absolute lifetime in a similar manner to achieve the effect of never having to log in again as long as the user remains active within the inactivity lifetime (and the user never explicitly logs out).

![Auth0 Management API](https://images.ctfassets.net/23aumh6u8s0i/1og3ppkzZWZlMEXh1NNqLM/c2f2998f7509d6568fd87ca40622fdcf/06-refresh-token-expiration-2)

## Guidance & Defaults

As part of Auth0’s continued commitment to securing applications and protected resources, we’ve updated default refresh token settings for new applications as follows.

### Confidential Clients

Confidential clients, such as machine-to-machine applications or traditional web applications that can securely store client credentials and can, therefore, prove that requests are coming from the client and not an illegitimate actor. As such, when refresh tokens are enabled, for confidential clients, default settings are optimized for convenience as follows: 

![Confidential Clients](https://images.ctfassets.net/23aumh6u8s0i/3ZABGcvqKpo7NIanSD1v4e/c83ca317f6483ccae212a9ac2db827fb/07-confidential-clients)

### Public Clients (Native Apps)

Because Public Clients, such as native mobile applications, cannot securely store client credentials and are susceptible to other attack vectors when refresh tokens are enabled for public clients, the default settings are optimized for security, as follows: 

![Public Clients](https://images.ctfassets.net/23aumh6u8s0i/5sUFHqXRJ1OQZnb4MvMOMu/62b5e02b574bbe4c1b74cfee434d628e/08-public-clients)

### SPAs

Until recently, refresh tokens were not recommended for use with SPAs because browsers are more vulnerable to token leakage than native applications. Leveraging Refresh Token Rotation, the risk of using refresh tokens in SPAs is lowered. Nevertheless, Auth0 recommends that SPAs use refresh tokens with Absolute lifetimes specified and sets the following defaults when refresh tokens are enabled for SPAs:

![SPAs](https://images.ctfassets.net/23aumh6u8s0i/1S9d6u2w8dgSZ4D3cEpwIa/b0d00b921376cf6ec28bb86ac5f95145/09-spas)

## Let’s Get Started

As of December 16, 2020, both absolute and inactivity lifetimes for refresh tokens are available for all Auth0 customers hosted in our cloud environment and will be available in December 2020 for private cloud customers. You can read more about refresh token expiration, absolute lifetimes, and inactivity lifetimes and how to configure them for use in your applications in the [Auth0 documentation](https://auth0.com/docs/tokens/refresh-tokens/configure-refresh-token-expiration). We hope that you find this new capability helpful for balancing user experience with added security.

Secure the applications that you care about. But do it in a way that delights the people who use them.

Achieving a Seamless User Experience with Refresh Token Inactivity Lifetimes

Global identity management provider one of the first AWS Partners to give AWS customers seamless access to professional services in AWS Marketplace

**BELLEVUE, Wash. – December 3, 2020** – The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced that it is participating in the launch of Professional Services in AWS Marketplace. Amazon Web Services (AWS) customers can now find and purchase professional services from Auth0 in AWS Marketplace, a curated digital catalog of software, data, and services that makes it easy to find, test, buy, and deploy software and data products that run on AWS. As a participant in the launch, Auth0 is one of the first independent software vendors to quote and contract services in AWS Marketplace to help customers implement, support, and manage their software on AWS. [Click here](https://aws.amazon.com/marketplace/seller-profile?id=0079abaf-bc2f-481c-9543-d2bfedb81003) for more information. 

As organizations migrate to the cloud, they want to use their preferred software solutions on AWS. AWS customers often utilize professional services from Auth0 to help implement the Auth0 platform and enable interoperability with their applications. Until now, AWS customers had to find and contract professional services outside of AWS Marketplace and could not acquire an identity platform solution and associated professional services in a single procurement experience. With professional services from Auth0 available in AWS Marketplace, customers have a simplified way to purchase and pay for both their subscription to the Auth0 platform and related professional services in a centralized place. 

“Auth0 is proud to offer professional services in AWS Marketplace and provide AWS customers with additional support they may need for any identity implementation,” said Bill Lapcevic, VP of Business Development at Auth0. “We are excited to be one of the first independent software vendors to offer professional services as part of this launch and look forward to providing an even more comprehensive identity offering for AWS customers.”

Auth0 is an AWS Advanced Technology Partner that is participating in AWS re:Invent 2020, taking place November 30 - December 18, 2020. To learn more, visit: [https://info.auth0.com/auth0-at-aws.html](https://info.auth0.com/auth0-at-aws.html). 

<include src="asides/AboutAuth0" />

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

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

Auth0 Supports the Launch of Professional Services in AWS Marketplace

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

37590801?s=460&v=4

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

Dan Arias

Learn how to use NestJS, a Node.js framework powered by TypeScript, to build a secure API.

<details>
<summary>Are you starting from this chapter?</summary>

Clone the application repo and check out the `getting-started` branch:

``` bash 
git clone git@github.com:auth0-blog/wab-menu-api-nestjs.git \
nest-restaurant-api \
--branch getting-started
```

Make the project folder your current directory:

``` bash 
cd nest-restaurant-api
```

Then, install the project dependencies:

``` bash 
npm i
```

Finally, create a `.env` hidden file:

``` bash 
touch .env
```

Populate `.env` with this:

``` bash 
PORT=7000
```

</details>

## Organize NestJS Apps Using Modules

A project of large size is easier to maintain and grow when its architecture is predictable and well-organized instead of being a spaghetti-like mess. NestJS uses modules to help you organize your application logically and to establish clear feature boundaries.

![NestJS takes you from messy code to organized code](https://images.ctfassets.net/23aumh6u8s0i/7fZuSQuPAWZY5gt3hjFMMQ/7ca680157e8314b68a423751c8ae4b22/nest-js-modules)

Each application has at least one module, the **root module**, and any number of **feature modules** that encapsulate components related to a specific application feature. NestJS uses the root module as a data structure to track and resolve the relationships between all your application components. 

This application needs **three modules**: the **root module**, `AppModule`, and **two feature modules**: `ItemsModule` to encapsulate logic related to the `items` resource and `AuthModule` to handle anything related to API authorization.

Start by creating an `ItemsModule` using the NestJS CLI, which was installed as one of your `devDependencies` when you scaffolded your NestJS project: 

``` bash 
nest generate module items
```

Under the `src` directory, the CLI creates a new `items` directory to host your module files, which includes `items.module.ts` to define the `ItemsModule`. As you can see, a module is a class annotated with a `@Module()` decorator, which provides metadata that NestJS uses to organize the application structure.

Additionally, as you create new feature elements (such as classes, controllers, and services), the NestJS CLI updates the dependencies of your modules automatically. Open `src/app.module.ts` and notice how `AppModule` lists `ItemsModule` as an element of its `imports` array:

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

import { Module } from '@nestjs/common';
import { ItemsModule } from './items/items.module';

@Module({
 imports: [ItemsModule],
 controllers: [],
 providers: [],
})
export class AppModule {}
```

<include src="TweetQuote" quoteText="As an architecture framework, NestJS takes the guesswork out of project structure and lets you focus on what matters the most: building robust applications"/>

## Create Data Models with TypeScript

Before creating any controllers and services, define the structure of the data you want to manage. A menu item has the following properties:

- `id`: (number) Unique identifier for the item record
- `name`: (string) Name of the item
- `price`: (number) Price of the item in dollars
- `description`: (string) Description of the item
- `image`: (string) URL pointing to the item's image

![WHATBYTE Dashboard full menu item](https://images.ctfassets.net/23aumh6u8s0i/wkMDo6PoCvR0u3QPD22BX/88843cd23660418920811bfdfc0aa08c/whatbyte-dashboard-full-menu-item)

With TypeScript, you can use either classes or interfaces to define and enforce the structure of objects during development. NestJS recommends using classes as these are preserved as real entities in the compiled JavaScript. Classes can also use decorators on its member variables to enhance them, which is quite helpful for data validation.

Using the CLI generate an `Item` class:

``` bash 
nest generate class item --no-spec
```

NestJS creates an `item.ts` file under the `src` directory for you. Open this file and populate it like so:

``` typescript 
// src/item.ts

export class Item {
 readonly id: number;
 readonly name: string;
 readonly price: number;
 readonly description: string;
 readonly image: string;
}
```

It would be best to put these objects of type `Item` in a key-value store with the `id` property serving as the key and the `Item` object as the value.

Using the CLI generate an `Items` class:

``` bash 
nest generate class items --no-spec
```

Update the newly created `src/items.ts` file as follows:

``` typescript 
// src/items.ts

import { Item } from './item';

export class Items {
 [key: number]: Item;
}
```

As you'll use these class definitions to type the methods of controllers and services that you'll create in the next sections, it's fine for these files to live under the `src` directory.

## Create a NestJS Service

Initially, you'll use an in-memory store to hold application data. Eventually, you'd want to persist those records in a [MongoDB](https://auth0.com/blog/auth0-tutorials-using-mongodb-atlas-as-a-custom-database/) or [PostgreSQL](https://auth0.com/blog/how-we-store-data-in-the-cloud-at-auth0/#PostgreSQL) store &mdash; or any other database. To migrate stores easily, you can use a pattern common to MVC architectures: lightweight controllers that delegate business logic to services. 

As such, you'll create a service to encapsulate all the business logic related to read and write operations on the menu items store. In turn, this service will expose an interface for your controllers to perform these data operations. You'll end up with a modular and reusable service that you can eventually modify to use different stores without changing the code of any of its consumers.

Use the NestJS CLI to create an `ItemsService` as follows:

``` bash 
nest generate service items --no-spec
```

> The `--no-spec` flag prevents the generation of files related to testing.

NestJS creates `items.service.ts` under the `src/items` directory. The newly defined `ItemsService` is also automatically registered as a provider of `ItemsModule`.

``` typescript 
// src/items/items.module.ts

import { Module } from '@nestjs/common';
import { ItemsService } from './items.service';

@Module({
 providers: [ItemsService],
})
export class ItemsModule {}
```

`ItemsService` will define an object to hold your store records along with methods to perform data operations on the store.

Update `src/items/items.service.ts` with the following code:

``` typescript 
// src/items/items.service.ts

import { Injectable } from '@nestjs/common';
import { Item } from '../item';
import { Items } from '../items';

@Injectable()
export class ItemsService {
 private readonly items: Items = {
 1: {
 id: 1,
 name: 'Burger',
 price: 5.99,
 description: 'Tasty',
 image: 'https://cdn.auth0.com/blog/whatabyte/burger-sm.png',
 },
 2: {
 id: 2,
 name: 'Pizza',
 price: 2.99,
 description: 'Cheesy',
 image: 'https://cdn.auth0.com/blog/whatabyte/pizza-sm.png',
 },
 3: {
 id: 3,
 name: 'Tea',
 price: 1.99,
 description: 'Informative',
 image: 'https://cdn.auth0.com/blog/whatabyte/tea-sm.png',
 },
 };

 findAll(): Items {
 return this.items;
 }

 create(newItem: Item): void {
 const id = new Date().valueOf();
 this.items[id] = {
 ...newItem,
 id,
 };
 }

 find(id: number): Item {
 const record: Item = this.items[id];

 if (record) {
 return record;
 }

 throw new Error('No record found');
 }

 update(updatedItem: Item): void {
 if (this.items[updatedItem.id]) {
 this.items[updatedItem.id] = updatedItem;
 return;
 }

 throw new Error('No record found to update');
 }

 delete(id: number):void {
 const record: Item = this.items[id];

 if (record) {
 delete this.items[id];
 return;
 }

 throw new Error('No record found to delete');
 }
}
```

Notice that the `create` method creates a unique `id` property automatically for you when a new `Item` object is created using the [JavaScript Date API](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date):

``` typescript 
const id = new Date().valueOf();
```

This `id` value is based on the number of milliseconds between `1 January 1970 00:00:00 UTC` and the current time.

<include src="tutorial/NextButton" nextPart="developing-a-secure-api-with-nestjs-creating-endpoints/" completedMessage="I've created my NestJS data models and a data service"/>

<include src="tutorial/IssueButton" communityTopic="developing-a-secure-api-with-nestjs/33026"/>

Developing a Secure API with NestJS: Creating Data Models and Services

PwC Germany, NTT DATA, Softchoice sign onto global Auth0 Partner Program

**BELLEVUE, Wash. – July 22, 2020 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced new growth and additions to its [Partner Program](https://auth0.com/partners). In the last five months alone, the program has outperformed all of 2019, added more than 20 new Solutions and Technology Partners from key regions, and expanded to new regions, including [Asia Pacific](https://auth0.com/blog/auth0-hires-former-aws-channel-head-jason-teo-to-lead-efforts-in-asia-pacific/) to support growing demand for digital identity management. 

As the world embraces the “new normal”, new application development and digital transformation are driving continued growth of Auth0’s Partner Program. Today [83% of applications require authentication](https://auth0.com/resources/whitepapers/state-app-assembly-2020), such as sign up (registration), sign in, and security and compliance functionality for protecting user identities. Channel partners play a primary role in helping organizations implement identity management in a way that works with their architecture, so they can bring applications to market faster and focus on their core value proposition for customers. 

Auth0 is answering global demand for identity management with new partnerships in key regions, including:

* [Cognizant](https://auth0.com/blog/auth0-expands-global-partner-network-with-cognizant/) (Nasdaq: CTSH) – Global professional services provider focused on digital transformation
* [NTT DATA](https://www.nttdata.com/global/en/) (TSE: 9613) – Global IT services provider and Auth0’s first GSI partner in Japan
* [Abacus](http://www.abacuscambridge.com) – Global business transformation services industry pioneer across MENA and the UK
* [PwC Germany](https://www.pwc.de/en.html) – Leading auditing and consulting services organization in Germany
* [Idento](https://idento.fr/) – Leading identity and access management consultancy and Auth0’s first partner in France
* [Softchoice](https://www.softchoice.com/) – One of the largest IT solutions and managed services providers in North America
* [OSC Korea](http://www.osckorea.com/) – Digital transformation specialist and Auth0’s first strategic partner in South Korea

“With rapid innovation along the identity value chain, flexible solutions for authentication, verification, and federation of identities are vital to allow convenient and secure customer experiences,” according to Thomas Hammer, an Open Banking expert for PwC Germany. “Especially with the increasing prevalence of identity ecosystems, it is important for businesses to provide interoperable, frictionless, and easy-to-use identity experiences that are an asset to their customers rather than an obstacle,” adds Maximilian Harmsen, Digital Identity Leader for PwC Germany.

Auth0 has also launched technology integrations with major players &mdash; [Amazon EventBridge](https://auth0.com/blog/get-more-out-of-your-auth0-logs-with-amazon-eventbridge/), [Microsoft Azure Event Grid](https://auth0.com/blog/integrate-azure-event-grid-with-auth0/), and [Datadog](https://auth0.com/blog/auth0-partners-with-datadog-to-deliver-mission-critical-identity-data-in-near-real-time/) &mdash; and deepened its partnership with Amazon Web Services ([AWS](https://auth0.com/blog/auth0-joins-the-aws-partner-network-global-startup-program/)), including recent selection as a [AWS Security Competency Partner](https://aws.amazon.com/partners/find/partnerdetails/?id=001E000000YKGRTIA5&did=pa_card&trk=pa_card) for security and technical expertise.

“The marked increase in demand for identity management has been an incredible catalyst for creating valued partnerships with leading firms globally,” said Bill Lapcevic, VP of business development at Auth0. “Customers see the utmost value from Auth0 when they combine the tight relationships they have with our mutual partners and Auth0’s best in class identity solution. Our partner relationships substantially enhance the ability to reach new territories and regions with Auth0. We look forward to working with our new partners to implement Auth0 and help their customers experience the immediate benefit of an identity and authentication solution designed to allow the addition of new capabilities and functionality over time.” 

For more information on the Auth0 Partner Program, please visit [https://auth0.com/partners](https://auth0.com/partners).

<include src="asides/AboutAuth0" />

### Media Contacts
Hannah Carroll 
Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com)

Mark Fowler 
Racepoint Global for Auth0, EMEA 
[auth0@racepointglobal.com](mailto:auth0@racepointglobal.com)

Demand for Identity Management Drives Auth0 Partner Growth

New survey reveals behaviors and usage patterns of application builders; authentication required in 83% of applications built

**BELLEVUE, Wash. – May 19, 2020 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today released a [**2020 State of Application Assembly**](https://auth0.com/resources/whitepapers/state-app-assembly-2020) survey, revealing that a majority of development teams are turning to best-in-class SaaS services and the adaptability of APIs for building unique features and functionalities into the many apps they are responsible for each year.

Surveying 426 global technical professionals across a variety of roles (developers, engineers, CTOs, directors of engineering, software architects) and company sizes, Auth0 determined that 51% of respondents are responsible for building two to five apps per year, and more than a quarter (28%) build 6-10+ apps per year, with three-quarters of these apps being used for external audiences. There are currently more than 4.1 million apps available on leading app stores ([Statista](https://www.statista.com/statistics/276623/number-of-apps-available-in-leading-app-stores/)), indicating the staggering amount of development these builders are responsible for. 

The survey explored application builder behavior around several services and key findings included: 

* For applications that required payment, 74% of respondents outsourced, with Stripe being the dominant tool of choice.
* For applications that required messaging, 71% outsourced this solution, with Twilio being the highly preferred tool.
* The third service explored was authentication, cited as a requirement in 83% of applications built. However, the numbers for outsourcing authentication were lower than the other two services, with respondents outsourcing 58% of the time. 

With a substantial percentage of companies still building authentication tools in-house – and because authentication is present in the majority of apps – there’s a large potential opportunity for application building teams to streamline their processes and improve efficiency by using a third-party IDaaS tool. 

The accelerated timelines that come with app launches are driving teams away from in-house development and towards microservices – app ‘building blocks’ – that provide features and functionality that would be nearly impossible to build and maintain themselves. Relying on third-party services that are adaptable to their specific needs, significantly frees the team’s resources to focus on core innovation and speed-to-market. 

“These results confirm a trend of application development teams increasingly relying on first- and third-party APIs and external SaaS services when assembling apps, to simultaneously decrease time-to-market and increase completeness and security,” said Martin Gontovnikas, SVP of Marketing and Growth at Auth0. “Whether it’s payments, messaging, or authentication, this survey shows that teams are turning more to a ‘must-have SaaS stack’ to expedite development and enable them to focus on their core product.” 

The move to outsource services that are proven and fully adaptable gives application teams a competitive edge in innovation and implementation. By 2022, 90% of all apps will feature microservices architectures that improve the ability to design, debug, update, and leverage third-party code. Combined with agile/DevOps approaches and methodologies, enterprises can dramatically accelerate their ability to push out digital innovation – at 50-100x (or more) the frequency of traditional approaches ([IDC](https://www.idc.com/getdoc.jsp?containerId=prUS44417618)).

Please visit the [State of Application Assembly](https://auth0.com/resources/whitepapers/state-app-assembly-2020) for further details and to view all survey results.


<include src="asides/AboutAuth0" />

### Media Contacts
Jeana Tahnk 
Auth0 Global Communications 
[press@auth0.com](mailto:press@auth0.com)

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

Majority of Application Development Teams Rely More On SaaS Services vs. Building In-House

eugenio-pace-new-avatar

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

CEO and Co-Founder

Eugenio Pace

We are offering free services to startups to help innovators tackle the challenges we are all facing

I know how difficult it is to start a business when the world is relatively calm, let alone the one we all find ourselves in now. Nothing is the same as it was. Between scrolling through rolling news channels and worrying about ourselves and loved ones, we are all looking for ways to help one another. For those companies trying to make progress during these times, I know how much harder it must be. 

We already offer a free tier of service to thousands of customers to help them innovate, but starting today, if you are a startup battling the impact of COVID-19 and meet our program criteria [1] , then you are eligible to get a **year of Auth0 Startup Relief for free**. From Single-Sign-On (SSO) to anomaly detection, we are making it easier to manage all of your users’ identities, however, they access your applications.

The “Auth0 Startup Relief” is designed for those who are doing any one of the following:

* Fighting the virus 
* Helping those who can’t work due to travel restrictions
* Enabling distance learning
* Helping small businesses who are struggling 

We want the best minds thinking about how to make things better, not worrying about authentication or authorization. And we are going to continue finding ways to make our technology available to those who need it most, as well as actively engaging with anyone who wants our help and advice during these times. [We also just announced free workforce authentication for businesses](https://auth0.com/blog/auth0-makes-workforce-authentication-free-through-august-2020/), through to August 31st, for up to 500 employees as well.

We at Auth0 hope this will further help these innovators fight COVID-19; we are rooting for you! 

## How It Works

1. Fill out your information [here](https://auth0.com/contact-us?utm_source=blog&utm_medium=oc&utm_campaign=businesspost&place=blog%20post&type=link&text=here) and don’t forget to include a mention in the message field that your startup is applying to the “Auth0 Startup Relief”
2. Our team will get back to you in less than 2 business days to confirm your eligibility and, assuming you meet the requirements, to help you start using Auth0 services for free for a year.

![Free Auth0 to help innovators fight COVID-19](https://images.ctfassets.net/23aumh6u8s0i/6n2zNChmRNytjOyp58cb0M/502f54c3101011828211819bcbda58d1/value-customer)

[1] In addition to meeting one of the Auth0 Startup Relief criteria, your company must meet these requirements as of the date of your application

* Less than $1M in Annual Recurring Revenue (ARR)
* Less than $2M in raised funding
* Less than 2 years old

<include src="asides/AboutAuth0" />

Auth0 Startup Relief: Helping Innovators Battle COVID-19

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

Leading professional services provider to integrate Auth0 for digital transformation initiatives

**BELLEVUE, Wash. – February 26, 2020 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced that [Cognizant](https://www.cognizant.com/) (Nasdaq: CTSH) has joined its [Partner Program](https://auth0.com/partners) and will use Auth0 as one of its main authentication providers for any of its customers’ identity management needs. Ranked 193 on the Fortune 500 list with nearly 300,000 employees, Cognizant is an integral partner in transforming global enterprises’ business, operating, and technology models for the digital era. 

“Cognizant’s broad portfolio of consulting, professional, and managed security services are designed to help our clients around the globe to meet their security challenges,” said Ryan Parthasarathy, Vice President of Cognizant Security. “Given the complexity of identity management, we’re proud to partner with a global expert and game-changer in the CIAM space to enhance our security offerings and deliver only the best for our customers.”

Known for its highly-scalable platform, Auth0 was recently ranked as a [Leader for CIAM](https://auth0.com/blog/auth0-named-a-leader-in-the-g2-winter-2020/) on G2, the world’s leading business solutions review website. With high-velocity growth and more than 9,000 customers worldwide, Auth0 is answering the demand for identity management with a simple, extensible, and powerful solution for any application, for any audience.

“We’re thrilled to partner with Cognizant, an experienced leader in complex identity projects, and combine our teams’ expertise with our extensible, flexible, and trusted platform to aid Cognizant customers in a successful and secure digital transformation journey,” said Bill Lapcevic, VP of business development of Auth0. “Identity management is a critical and complex step in any transformation process, and a strong CIAM system will help customers modernize their business in a quicker and more organized fashion to address identity and security needs.”

Learn more about the [Auth0 Partner Program here](https://auth0.com/partners) along with the recent [growth of Auth0’s global partner network](https://auth0.com/blog/auth0-partner-program-accelerates-global-growth/), now serving more than 60 partners worldwide.

For more information about Cognizant Security, please visit [www.cognizant.com/security](https://www.cognizant.com/security).

<include src="asides/AboutAuth0" />

### Media Contacts
Kaycie East 
Auth0 Global Communications 
[press@auth0.com](mailto:press@auth0.com) 
 
Ryan Schin 
Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com)

Auth0 Expands Global Partner Network with Cognizant

All employees, customers, and partners utilize 'Siemens ID' for seamless access to global apps and services

**BELLEVUE, Wash. – February 4, 2020 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced that it has partnered with global technology powerhouse, [Siemens AG](https://new.siemens.com/global/en.html) to develop and build ‘Siemens ID’, one centralized login for all Siemens internal and external applications. Siemens, headquartered in Munich, and the largest industrial manufacturing company in Europe, operates across 200 global offices with approximately €86.8 billion in annual revenue.

As one of the world’s largest producers of energy-efficient, resource-saving technologies, Siemens turned to Auth0 to help build Siemens ID for centralizing access to its global applications and services for hundreds of customers, partners, and as of September 2019, 385,000 employees across the world. Siemens ID relies on Auth0’s highly-scalable platform to provide a centralized way to store the user database and login page while enabling each division to customize the identity providers they want, manage the roles, and define the workflow they need to optimize the user experience (a concept called [multi-tenancy](https://auth0.com/blog/using-auth0-for-b2b-multi-and-single-tenant-saas-solutions/)).

“[Before Auth0] we applied strict internal identity management policies to external identity management which caused lots of overhead and complexity. When Siemens ID-as-a-service and Auth0 as a service provider stepped in, we could improve the processes around identity management, reducing efforts while increasing the acceptance of the internal stakeholders,” said Hugo Francisco, Service Owner, IAM Solutions at Siemens. “This also enabled our clients and partners to focus on doing business instead of managing accounts and several login credentials for several applications.”

[Multi-factor authentication (MFA)](https://auth0.com/docs/multifactor-authentication) was one of the mandatory requirements for Siemens ID to provide an extra layer of security when delivering applications to external clients or partners. With Auth0, Siemens can offer three distinct types of second-factor authentication, which was a key differentiator when selling the implementation to internal stakeholders. Since partnering with Auth0, Siemens has expanded its Auth0 features to include [Universal Login](https://auth0.com/universal-login) and [Anomaly Detection](https://auth0.com/learn/anomaly-detection/), enabling them to quickly integrate various identity management features into its applications to fulfill the Siemens ID promise of robust security.

“Global companies like Siemens need to be able to standardize and centralize on one identity platform while maintaining flexibility and security at the department level,” said Steven Rees-Pullman, Vice President, International at Auth0. “As Siemens continues to grow and expand, the service they’ve created with Auth0 can scale with them.”

Siemens is one of many [Auth0 customers in the DACH region](https://auth0.com/blog/auth0-announces-growth-in-dach/), including HolidayCheck and EnBW Energie Baden-Württemberg AG. More details on [Siemens’ implementation of Auth0](https://auth0.com/case-studies/siemens/) can be found on the company’s website. 

## About Siemens AG 
Siemens AG (Berlin and Munich) is a global technology powerhouse that has stood for engineering excellence, innovation, quality, reliability and internationality for more than 170 years. The company is active around the globe, focusing on the areas of power generation and distribution, intelligent infrastructure for buildings and distributed energy systems, and automation and digitalization in the process and manufacturing industries. Through the separately managed company Siemens Mobility, a leading supplier of smart mobility solutions for rail and road transport, Siemens is shaping the world market for passenger and freight services. Due to its majority stakes in the publicly listed companies Siemens Healthineers AG and Siemens Gamesa Renewable Energy, Siemens is also a world-leading supplier of medical technology and digital healthcare services as well as environmentally friendly solutions for onshore and offshore wind power generation. In fiscal 2019, which ended on September 30, 2019, Siemens generated revenue of €86.8 billion and net income of €5.6 billion. At the end of September 2019, the company had around 385,000 employees worldwide. Further information is available on the Internet at [www.siemens.com](https://www.siemens.com/).

<include src="asides/AboutAuth0" />

### Media Contacts
Jeana Tahnk 
Auth0 Global Communications 
[press@auth0.com](mailto:press@auth0.com) 

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

Auth0 Powers Centralized Login for Siemens’ Hundreds of Applications Worldwide

Auth0 selected for meeting criteria and providing demonstrated market fit for AWS customers

**BELLEVUE, Wash. - Dec. 4, 2019 -** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, announced today that it has joined the Amazon Web Services (AWS) Partner Network (APN) Global Startup Program. The APN Global Startup is a unique “white glove” support and go-to-market (GTM) Program for selected startup APN Partners so that they can build on their AWS expertise, better serve shared customers, and accelerate their growth. To be selected for the APN Global Startup Program, [Auth0](https://auth0.com/) has to meet pre-defined criteria, including a clear, demonstrated product-market fit for an innovative enterprise tech product, be backed and recommended by a top-tier venture capital firm, and have a strategic commitment to building their cloud expertise.

The APN Global Startup Program enables qualifying startups to gain product design wins, visibility, exposure, leads, and commercial opportunities made possible with exclusive APN resources and dedicated Startup Partner Development Managers (PDM) with deep AWS knowledge and startup business experience, that guide startups in their growth journey with AWS. By becoming an APN Global Startup Partner, [Auth0](https://auth0.com/) will receive benefits ranging from a tailor-made plan for mapping the startup needs and opportunities to a selection of AWS services and APN programs, promotion support to drive visibility and awareness around the startup offering, to resources for helping startups sell and deploy innovative solutions on behalf of AWS shared end-customers.

“Auth0 is honored to be part of the AWS Partner Network Global Startup Program. We look forward to taking advantage of the additional support and worldwide exposure they are providing as part of this program,” said Eric Snyder, senior director of partnerships at Auth0. “We are dedicated to being a valuable partner in the AWS network and providing the best identity management platform to all customers.”

Auth0’s universal platform provides out-of-the-box extensible identity management for customers of virtually any size, and any authentication or authorization needs. As a member of the AWS APN Global Startup Program, Auth0 will continue to help companies achieve their technology goals by leveraging the agility, breadth of services, and pace of innovation that AWS provides.

“[Working with Auth0](https://auth0.com/case-studies/chaossearch/) enabled us to deliver an SSO offering to the **CHAOS**SEARCH customers in a time frame that was impossible without them,” said Thomas Hazel, founder, and CTO, **CHAOS**SEARCH. “By choosing Auth0, we can meet our enterprise customer demand for federated identity in a simple and elegant deployment, allowing us to focus on the business value of our offering. The service was easy to implement and the team, from beginning to end, was exceptional.”

AWS is enabling scalable, flexible, and cost-effective solutions from startups to global enterprises. The APN is a global program helping partners build a successful AWS-based business, by helping organizations build, market, and sell their offerings. The APN provides valuable business, technical, and marketing support, to help startups achieve exponential growth. 

For more information on how AWS customers can have the quick, easily implemented identity solution they need for their specific application, please download the [Why Auth0 and AWS](https://auth0.com/resources/ebooks/aws-auth0-ebook) ebook.

<include src="asides/AboutAuth0" /> 

### Media Contacts 
Alex Plew 
Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com) 

Deepika Zafar 
Racepoint Global for Auth0, EMEA 
[auth0@racepointglobal.com](mailto:auth0@racepointglobal.com)

Auth0 Joins the AWS Partner Network Global Startup Program

andrew-akers

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

Andrew Akers

cami-cano

I am a product manager, and I am passionate about building great tools for software engineers. I am always looking to learn more about my customers in order to develop sustainable solutions for them. This approach to product management is always pushing me to collaborate with people across the entire company, which is my favorite part of the job. Before joining Auth0, I worked at GitHub, where I was a product manager on GitHub Enterprise. In my spare time, I enjoy spending time with my family, running, and reading non-fiction.

Product Manager

Cami Cano

This new integration connects Auth0 event logs to a variety of AWS services in near real time

At _AWS re:Invent 2019_, Auth0's integration with [Amazon EventBridge](https://aws.amazon.com/eventbridge/) was announced. This new integration connects Auth0 event logs to a variety of AWS services in near real time, unlocking a variety of new use cases that support [event-driven](https://aws.amazon.com/event-driven-architecture/) and [microservices](https://aws.amazon.com/microservices/) application architectures.

## What is Amazon EventBridge?

Amazon EventBridge is a serverless event bus that makes it easy to connect real-time data from your applications, SaaS applications, and AWS Services. It delivers a stream of data from event sources like Auth0 to targets such as AWS Lambda. You can set up routing rules to determine where to send your data to build application architectures that react in real time to all of your data sources. 
With EventBridge, you can use data from SaaS apps like Auth0 to trigger workflows for customer support, business operations and more. It simplifies the process of building [event-driven architectures](https://aws.amazon.com/event-driven-architecture/) that are loosely coupled and distributed, improving developer agility and application resiliency.

## Auth0 and EventBridge

The integration with EventBridge is Auth0’s first release of our log streaming capabilities. Auth0 log events are pushed automatically and continuously to EventBridge, which can then be connected to various AWS services.
Here is a quick overview of some of the use cases this integration unlocks:

![Auth0 Amazon EventBridge use cases](https://images.ctfassets.net/23aumh6u8s0i/3vNAjtRGyWWYNajUgZrE8g/57e662e6f3630cd4bf4b19fa16415597/auth0-eventbridge)

## Engage with Your Users

Delivering a strong user experience is critical to reducing churn and retaining users. Using Auth0 events and services like AWS Lambda, you can deliver more customized application experiences. For example, use this integration to create a product onboarding flow for first-time logins. Or increase user engagement by highlighting product areas that would be of interest to them based on their login behavior.

## Understand User Behavior

Understanding when users access your product, where they are signed in from, and what devices they use are important pieces of information that can drive your product development. By keeping track of these signals, via the events emitted by Auth0, you can develop an understanding of the product areas that you should be paying attention to. These signals can help you determine what browsers and devices to support, what languages to consider localizing your app in, and when your peak application traffic times are.
Use services like AWS QuickSight to uncover business intelligence, create dashboards, and utilize ML Insights.

## Manage User Data

Retaining and auditing user actions is crucial for maintaining security and complying with industry regulations. Besides, the ability to edit, remove, or export user data upon request is becoming increasingly important to comply with various data privacy laws, such as the European Union’s General Data Protection Regulation (GDPR).
By sending Auth0 logs to EventBridge, it is easy to develop the appropriate workflows and automation to retain audit trails and remain compliant. For example, you can store your audit trail in S3 buckets and interact or investigate it using AWS Athena.

## Learn More
Using Amazon EventBridge with Auth0 unlocks a variety of use cases. Learn how to set up the integration [here](https://auth0.com/docs/integrations/aws-eventbridge), or [sign up for a free Auth0 trial](https://auth0.com/signup).

<include src="asides/AboutAuth0" />

Get More Out of Your Auth0 Logs with Amazon EventBridge

CRN's Security 100 list recognizes security technology vendors for outstanding products and services

**BELLEVUE, Wash. – February 27, 2019 –** [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), announced today that [CRN®](http://www.crn.com), a brand of [The Channel Company](http://www.thechannelco.com/), has named Auth0 to its annual Security 100 list in the Identity Management and Data Protection category. The companies on CRN's Security 100 list have demonstrated innovation and creativity in product development, as well as a strong commitment to delivering those offerings through a vibrant channel of solution providers.

This list recognizes the coolest security vendors in five categories. In addition to Identity Management and Data Protection, additional categories include: Endpoint Security; Network Security; SIEM, Risk and Threat Intelligence; and Web, Email, and Application Security.

The Security 100 list recognizes security technology vendors for outstanding products and services, and also serves as a respected guide for solution providers trying to navigate the IT security market. The list helps prospective channel partners identify the vendors that can best help them improve or expand their security offerings.

The [Auth0 Partner Program](https://auth0.com/partners) works closely with its expanding global network of partners to provide their customers with the most extensible and powerful identity and access management platform. The widespread demand for an identity solution within digital transformation projects, new app development, and/or migrating to a new service, resulted in Auth0's Partner Program tripling its revenue in 2018.

"CRN's 2019 Security 100 list identifies top technology companies that are meeting high levels of demand with the most innovative security solutions on the market, enabling businesses to grow uninterrupted" said Bob Skelley, CEO of The Channel Company. "The core elements of today's businesses all depend upon secure, reliable cybersecurity solutions."

"We are excited to be recognized by CRN for our technology innovation and the ongoing growth of our Partner Program," said Eric Snyder, Senior Director of Business Development, Auth0. "We are grateful to our partners for becoming an integral part of their product offering, customer relations, and revenue stream &mdash; and grateful for this fantastic recognition of our efforts."

The Security 100 list will be featured in the February 2019 issue of CRN and online at [www.crn.com/security100](http://www.crn.com/security100).

<include src="asides/AboutAuth0" />

**About The Channel Company**

The Channel Company enables breakthrough IT channel performance with our dominant media, engaging events, expert consulting and education and innovative marketing services and platforms. As the channel catalyst, we connect and empower technology suppliers, solution providers and end users. Backed by more than 30 years of unequalled channel experience, we draw from our deep knowledge to envision innovative new solutions for ever-evolving challenges in the technology marketplace. [www.thechannelco.com](http://www.thechannelco.com/)

Follow The Channel Company: [Twitter](https://twitter.com/TheChannelCo), [LinkedIn](http://www.linkedin.com/company/the-channel-company) and [Facebook](https://www.facebook.com/TheChannelCompany?fref=ts)

_Copyright ©2019. CRN is a registered trademark of The Channel Company, LLC.  All rights reserved._

## **Media Contacts:**

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

Jennifer Hogan 
The Channel Company 
jhogan@thechannelco.com

Auth0 Recognized on CRN’s 2019 Security 100 List

Dirceu-Tiegs

What I enjoy the most about being an SRE at Auth0 is that it allows me to exercise different areas such as coding, architecture, writing, training, investigations, debugging, and incident response. It's great to be able to think deeply about all aspects related to reliability and then apply it to large-scale, real-world projects.

Site Reliability Engineering Team

Dirceu Tiegs

Learn more about how Auth0 architects its services to ensure scalability and high availability to handle more than 1.5 billion logins per month.

Auth0 provides authentication, authorization, and single sign-on services for apps of any type (mobile, web, native) on any stack. Authentication is critical for the vast majority of apps. We designed Auth0 from the beginning so that it could run anywhere: on our cloud, on your cloud, or even on your own private infrastructure.

In this post, we'll talk more about our public SaaS deployments and provide a brief introduction to the infrastructure behind [auth0.com](https://auth0.com/) and the strategies we use to keep it up and running with high availability. This is an updated version of the [2014 High Scalability post about Auth0's architecture](http://highscalability.com/blog/2014/12/1/auth0-architecture-running-in-multiple-cloud-providers-and-r.html).

A lot has changed since then in Auth0. These are some of the highlights:

- We went from processing a couple of million logins per month to 2.5 billion logins per month, serving thousands of customers, including [FuboTV](https://auth0.com/learn/sports-centric-streaming-service-fubotv-sees-50-roi-just-auth0s-security/), [Mozilla](https://auth0.com/blog/auth0-mozilla-partnership/), [InterMiles](https://auth0.com/learn/jetprivilege-case-study/), and more.

- We implemented new features like [custom domains](https://auth0.com/docs/custom-domains), [scaled bcrypt operations](https://auth0.engineering/bcrypt-as-a-service-9e71707bda47), vastly [improved user search](https://auth0.com/docs/users/search/v3), and much more.

- The number of services that compose our product in order to scale our organization and handle the increases in traffic went from under 10 to over 30 services.

- The number of cloud resources grew immensely as well; we used to have a couple dozen nodes in one environment (US), now we have more than a thousand over four environments (US, US-2, EU, AU).

- We doubled-down decided to use a single cloud provider for each of our environments and moved all our public cloud infrastructure to AWS.

## Core service architecture

![Auth0.com core service architecture](https://images.ctfassets.net/23aumh6u8s0i/2mden7W7brrYGv8LHDK2Lp/5347634d4197ae655555cf93b8209c2d/auth0-core-service-architecture)

The core service is composed of different layers:

- Core applications: Auto-scaling groups of servers running different services of our stack (authentication, management API, multi-factor authentication API, and much more).

- Data storage: Clusters of MongoDB, Elasticsearch, Redis, and PostgreSQL storing a variety of datasets for different applications and features.

- Transports/Queues: Kinesis streams and RabbitMQ, SNS, and SQS queues.

- Base services: Services for rate-limiting, bcrypt clusters, feature-flags, and more.

- Routing: AWS load balancers (ALB, NLB, and ELB from AWS) and some nodes running NGINX as a proxy.

## High Availability

In 2014 we used a multi-cloud architecture (using Azure and AWS, with some extra resources on Google Cloud) and that served us well for years. As our usage (and load) rapidly increased, we found ourselves relying on AWS resources more and more.

At first, we switched our primary region in our environment to be in AWS, keeping Azure as failover. As we began using more AWS resources like Kinesis and SQS, we started having trouble keeping the same feature set in both providers. As our need to move (and scale) faster grew, we opted to keep supporting Azure with a limited feature parity: if everything went down on AWS, we could still support core authentication features using the Azure clusters, but not much of the new stuff we had been developing.

After some bad outages in 2016, we decided to finally converge on AWS. We stopped all efforts related to keeping the services and automation platform-independent and instead focused on:

- Providing a better failover story inside AWS, using multiple regions and at least 3 Availability Zones per region.

- Increasing usage of AWS-specific resources like auto-scaling groups (instead of using fixed clusters of nodes), application load balancers (ALBs), and more.

- Writing better automation: we revamped our automation, completely embracing infrastructure as code using TerraForm and SaltStack to provision new Auth0 environments (and also to replace existing ones). This allowed us to grow from partially automated environments doing ~300 logins per second to fully automated environments doing more than ~3.4 thousand logins per second; using the new tooling makes it easier to scale up (and down, whenever it makes sense). The level of automation we achieved is not perfect but is allowing us to grow to new regions and create new environments in a much more convenient way.

- Writing better playbooks: with more time and focus, we saw that besides automation we also needed better playbooks in order to understand, manage, and respond to incidents related to our ever-growing mesh of services. This vastly improved scalability and reliability while also allowing us to onboard new employees faster.

<include src="TweetQuote" quoteText="Writing better automation let us grow from partially automated environments doing ~300 logins per second to fully automated environments doing more than ~3.4 thousand logins per second"/>

Let's take a look at our US environment architecture, for instance. We have this general structure:

![Auth0 US Environment Architecture](https://images.ctfassets.net/23aumh6u8s0i/4hGMwY5n4jk2aoJyyRAhjF/0ca131b596da7068aced34ca69fbbc5c/auth0-us-environment-architecture)

And this is the structure inside a single AZ:

![Auth0 Single Availablity Zone](https://images.ctfassets.net/23aumh6u8s0i/4EtOG7to5lHmyYnU5Q3aaC/a22b74fe7b0a58d0f54a78a6b801bbd2/auth0-single-availability-zone)

In this case, we use two AWS regions: us-west-2 (our primary) and us-west-1 (our failover). Under normal circumstances, all requests will go to us-west-2, being served by three separate availability zones.

This is how we achieve high availability: all services (including databases) have running instances on every availability zone (AZ). If one AZ is down due to a data center failure, we still have two AZs to serve requests from. If the entire region is down or having errors, we can update Route53 to failover to us-west-1 and resume operations.

<include src="TweetQuote" quoteText="We achieve high availability by running all services instances on every AWS availability zone"/>

We have different maturity levels for service failover: some services, like user search v2 (that builds a cache on Elasticsearch) might work but with slightly stale data; still, core functionality keeps working as expected.

In the data layer, we use:

- A cross-region cluster for MongoDB.

- RDS replication for PostgreSQL.

- Clusters per region for Elasticsearch with automated snapshot and restores running regularly to account for the lack of cross-region clustering.

We exercise failover at least once per year, and we have playbooks and automation to help new infrastructure engineers get up to speed on how to do it and what are the implications.

Our deployments are usually triggered by a Jenkins node; depending on the service we either use Puppet, SaltStack, and/or Ansible to update individual or groups of nodes, or we update our AMIs and create new autoscaling groups for immutable deployments. We have different types of deployments for new and old services, and this has been shown to be largely ineffective as we need to maintain automation, docs, and monitoring for something that should be unified.

We are currently rolling out blue/green deployments for some of the core services, and we intend to implement the same for every core and supporting service.

## Automated Testing

Besides unit test coverage on every project, we have multiple functional test suites that run in every environment; we run it on a staging environment before we deploy to production, and we run them again in production after finishing a deployment to ensure that everything works.

The highlights:

- We have thousands of unit tests in different projects.

- We use Pingdom probes that run every minute to check core functionality.

- We use a mix of Selenium and CodeceptJS-based functional tests before and after every deployment. The functional test suites test different API endpoints, authentication flows, identity providers, and much more.

<include src="TweetQuote" quoteText="Besides unit test coverage on every project, we have multiple functional test suites that run in every environment: staging before deploying to production and again in production after finishing deployment."/>

## CDN

Until 2017 we ran our own, custom-built CDN using NGINX, Varnish, and EC2 nodes in multiple regions. Since then, we transitioned to CloudFront, which has given us several benefits that include:

- More edge locations, which means less latency for our customers.

- Lower maintenance costs.

- Easier configuration.

There are a few downsides, like the fact that we need to run Lambdas to perform some configurations (like adding custom headers to PDF files and things like that). Still, the upsides definitely make up for that.

## Extend

One of the features we provide is the ability to run custom code as part of the login transaction, either via [_authentication rules_](https://auth0.com/docs/rules/current) or [_custom database connections_](https://auth0.com/docs/connections/database/custom-db). These features are powered by [_Extend_](https://goextend.io/), an extensibility platform that grew out of Auth0 and is now being used by other companies as well. With Extend, our customers can write anything they want in those scripts and rules, allowing them to extend profiles, normalize attributes, send notifications, and much more.

We have Extend clusters specifically for Auth0; they use a combination of EC2 auto-scaling groups, Docker containers, and custom proxies to handle requests from our tenants, processing thousands of requests per second and responding fast to variations of load. For more details about how this is built and run, check out this post on [how to build your own serverless platform](https://tomasz.janczuk.org/2018/03/how-to-build-your-own-serverless-platform.html).

## Monitoring

We use a combination of different tools for monitoring and debugging issues:

- CloudWatch

- DataDog

- Pingdom

- SENTINL

The vast majority of our alerts come from CloudWatch and DataDog.

We tend to configure CloudWatch alarms via TerraForm, and the main monitors we keep on CloudWatch are:

- HTTP errors from our main load balancers.

- Unhealthy instances in a target group.

- SQS processing delays.

CloudWatch is the best tool for alarms based on AWS-generated metrics (like ones from load balancers or autoscaling groups). CloudWatch alerts usually go to PagerDuty, and from PagerDuty to Slack/phones.

DataDog is a service we use to store and act on time-series metrics. We send metrics from Linux boxes, AWS resources, off-the-shelf services (like NGINX or MongoDB), and also custom services we have built (like our Management API).

We have many DataDog monitors. A few examples:

- Increase in response times in `$service` on `$environment`.

- Running out of space on `$volume` in `$instance` (`$ip_address`).

- Issue with `$process` on `$environment` / `$host` (`$ip_address`).

- Increase in processing time for `$service` on `$environment`.

- NTP drifting off / clock issue on `$host` (`$ip_address`).

- MongoDB replica-set change on `$environment`.

As you can see from the examples above, we have monitors on low-level metrics (like disk space) and high-level metrics (like MongoDB replica-set change, which alerts us if there was a change in the primary node definition, for example). We do much more and have some pretty sophisticated monitors around some services.

DataDog alerts are pretty flexible in their outputs and we usually send them all to Slack, sending to PagerDuty only those who should "wake people up" (like spikes of errors, or most things that we are sure that are having an effect on customers).

For logging we use Kibana and SumoLogic; we are using SumoLogic to record audit trails and many AWS-generated logs, and we use Kibana to store application logs from our own services and other "off-the-shelf" services like NGINX and MongoDB.

## The Future

Our platform evolved quite a bit in order to handle the extra load and the huge variety of use cases that are important to our customers, but we still have more room for optimizations.

Not only our platform grew, but our engineering organization increased in size: we have many new teams building their own services and are in need of automation, tooling, and guidance around scalability.
With that in mind, these are the initiatives in place for us to scale not only our platform but also our engineering practice:

- Build a Platform, PaaS style: As mentioned before, today we have different automation and deployment flows; this causes confusion and creates a barrier of entry for engineers as it's hard to experiment and scale up without touching too many repositories. We are developing a PoC for a platform (currently running on top of ECS) in which engineers can configure a YAML file and just deploy it to get computing resources, monitoring, logging, backups, and much more. All of that without having to configure it explicitly. This effort is in an early stage and might still change a lot (EKS?). However, we feel we are taking the right direction given our growing size and scalability constraints.

- Implement smoke tests for every new pull request: besides unit testing (that already runs on each new PR), we want to run integration tests on ephemeral environments wherever that's possible.

- Centralize our logging solution into just one provider. This might mean moving away from Kibana and using just SumoLogic, but we still need to evaluate feature set, data volume, and more.

- Automate metrics: Too much of our metric story is manual now: adding metrics-related calls to the code while deploying, and building dashboards and monitors using the DataDog interface. If we use a standard format and naming, we could do things like building dashboards/monitors automatically, extracting metrics from logs instead of explicitly adding calls to the code, and more.

- Ensure we have auto-scaling and blue/green deployments on every core service. This should come out-of-the-box from our new Platform, but while that is being built and tested we need to improve the scaling/deployment/rollback story for the core services that are still lacking in that regard.

<include src="asides/AboutAuth0" />

Auth0 Architecture: 5 Years In

Amazon Web Services customers can now implement Auth0’s Universal Identity Platform to build and scale new applications quickly

**BELLEVUE, Wash., – January 14, 2019 –** [Auth0](https://auth0.com/) today announced the public availability of its Identity-as-a-Service (IDaaS) platform on [AWS Marketplace](https://aws.amazon.com/marketplace/pp/B07YH11JH6). Customers can now add the cost of an Auth0 Enterprise Subscription to their Amazon Web Services (AWS) bill, and gain fast, flexible access to cloud-based identity management.

Auth0 is also an Advanced Technology Partner in the [AWS Partner Network (APN)](https://aws.amazon.com/partners/), which allows it to be hosted on or integrated with AWS. APN Advanced Technology Partners have demonstrated their commitment to AWS and deliver unique value to its customers. Auth0 will also take advantage of APN’s many benefits and framework for growth within AWS Marketplace, including technical training opportunities, business growth, and sales/marketing enablement. 

Auth0’s availability on AWS Marketplace makes it even more accessible to developers who need an extensible identity solution for new applications. Auth0 is quick to implement and easy for AWS customers to purchase, so developers can easily get new applications up-and-running. An Enterprise Subscription to Auth0’s highly scalable identity platform includes: Custom Domains, Unlimited Social Identity Providers, Unlimited Enterprise Identity Providers, HIPAA/BAA compliance, Single Sign On, and many other features. 
“Working with AWS offers us a powerful opportunity to continue expanding the global reach of our Universal Identity Platform,” said Eric Snyder, Senior Director of Partners at Auth0. “Enterprises can focus on innovation and achieve faster time-to-value by outsourcing their identity management to Auth0 for any audience, whether customers, business partners, employees, or even machines.”

For more information on the Auth0 Enterprise Subscription, please visit: [https://aws.amazon.com/marketplace/pp/B07YH11JH6](https://aws.amazon.com/marketplace/pp/B07YH11JH6).

<include src="asides/AboutAuth0" />

## **Media Contacts:**
Jeana Tahnk 
Corporate Communications 
Auth0 
[jeana.tahnk@auth0.com](mailto:jeana.tahnk@auth0.com)

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

Auth0 Now Available on AWS Marketplace

diegopoza

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

Sr Manager, Developer Advocacy

Diego Poza

Customer identity and management technology helps utilities reshape how they interact with users, improve their services, and tighten security.

Utility companies are in a unique position because of the sheer amount of data they collect and the number of users they manage. This affords them opportunities to generate value in ways that other companies can't.

But this wealth of information comes with several challenges. Users have [high expectations that many utility companies have yet to meet](https://www.powerengineeringint.com/articles/print/volume-26/issue-1/features/three-challenges-for-utilities-in-2018.html), and the [prevalence of inefficient customer management systems](https://www.appcues.com/blog/3-customer-engagement-strategies-that-make-users-feel-like-one-in-a-million) leaves many teams vulnerable to service outages and even cyberattacks.

Using customer identity and access management (CIAM) technology can help utility companies avoid three of the industry’s most common issues:

1. Inefficient trouble-shooting
2. A lack of personalized service
3. Security

Instead of tackling each with a separate set of tools and processes, a CIAM approach offers a single way to improve all three.

## 1. Quickly Fix Customer Access and Use Issues With a Central Dashboard.

Many utility companies have [decentralized and poorly planned processses](https://www.nccoe.nist.gov/sites/default/files/library/sp1800/es-idam-nist-sp1800-2a-draft.pdf) to let users access their power platform. Without a clearly defined system, utilities are more likely to feel the burden of service interruptions and suffer longer and more expensive delays in resolving them.

This can also make it difficult to help users in real time both with larger issues, such as power outages, and with simple fixes, such as password resets. Disorganization can diminish customer satisfaction and threaten a company's reputation in the industry as well as its ability to manage a large volume of users, obstructing productivity, and growth.

For companies looking to avoid these issues, a central dashboard can help [consolidate previously disparate streams of information](https://auth0.com/user-management) within an organization. In addition, if it's high quality, this product can, at any given moment, show which customers are logged in and provide their locations and current behavior.

![Central utility customer dashboard consolidates information streams](https://images.ctfassets.net/23aumh6u8s0i/4GgUoZRC73okir7MpR0W1w/7a588a02e3dac5fbf20311b66064e487/central-dashboard-consolidates-information-streams)

A robust dashboard will offer several ways to visualize the information, such as with a heat map of logins, along with pictures and users' personal details to help verify and learn more about them.

### Make Password Resets More Efficient

Internet users average [37 password resets a year](https://blog.dashlane.com/wp-content/uploads/2015/07/MailboxSecurity_infographic_EN_final1.jpg). Without an efficient process to tackle these, a simple fix can become frustrating and time-consuming. For utilities, a dashboard is an easy way for system admins to connect directly with end users on tasks like these.

In addition to greater overall user management, a dashboard allows admins to create a specific [password-reset page](https://auth0.com/docs/hosted-pages/password-reset), which they can tailor to their company's specific needs:

![Hosted login page for better password management](https://images.ctfassets.net/23aumh6u8s0i/5pvz5OyXVoS4npg1snIKE6/e27fe6683509cfc5c07518645ee91dd9/hosted-login-page-for-better-password-management)

The tool will enable users to change their passwords independently, without the added burden of IT support. It also allows a company to maintain consistency in the appearance of all associated pages—from login through password reset and more.

This approach can also help a team track the number of password resets happening at any given moment or determine how frequently specific users are requesting resets, helping admins identify and solve larger problems, including suspicious behavior.

## 2. Get to know your customers.

Many believe that [utilities are falling short in meeting customer needs](https://www.publicpower.org/periodical/article/utilities-missing-out-personalized-marketing-opportunities). As many [startups push the bar higher for customer success](https://www.forbes.com/sites/matthunckler/2017/08/23/the-top-3-strategies-for-customer-success-for-high-growth-tech-startups/#73ff49206805), a strong CIAM system can help buck the stereotype that established utilities aren’t innovative.

Being able to understand and meet the expectations of your customers is critical to [customer retention](https://www.appcues.com/blog/proven-customer-retention-strategies). CIAM technology will help you paint a fuller picture of each customer. In addition to incorporating data on their logins, devices, and utility usage, you can you can use [progressive profiling](https://auth0.com/blog/progressive-profiling/) to pull details like their location and their email addresses and even the interests they indicated at the login stage.

![Utility customer progressive profiling flow](https://images.ctfassets.net/23aumh6u8s0i/35XPMAPBa8EcYYET3tFRWI/44496d8d82c815206fbe3d512475805d/progressive-profiling-flow)

With a more comprehensive collection of data, teams can proactively match the right users to the right promotions. It can help organizations develop new services, boost engagement, and avoid being branded as a company that sends irrelevant spam messages and push notifications.

## 3. Block Suspicious Behavior.

On top of helping utility companies better understand and anticipate customer needs, a secure CIAM setup is crucial in an [industry facing an increase in cyber threats](https://www.bloomberg.com/news/articles/2018-04-04/cyberattack-bleeds-into-utility-space-as-duke-sees-billing-delay).

A recent IBM report found that the [average cost of a data breach for a utility company](https://www.ibm.com/blogs/insights-on-business/energy-and-utilities/security-breach-energy-utilities/) was approximately $3.5 million per incident in 2016. For companies based in the United States, that number jumped to an estimated $7.4 million, and just this year, an [American power company was fined an unprecedented $2.7 million](https://www.bankinfosecurity.com/us-power-company-fined-27-million-over-data-exposure-a-10715) for leaving customer records publicly exposed for 70 days.

CIAM offers simple but effective solutions that can help you quickly respond to suspicious behavior in your system and prevent a breach. Features like [anomaly detection](https://auth0.com/docs/anomaly-detection) will instantly block users with unknown addresses or repeated failed login attempts.

Not knowing who is in your system or what information they are accessing can cause more than just fines and lawsuits: Without a strong user-management system, companies are forced to inefficiently use IT resources and even take systems off-line while searching for the source of a breach. On top of losing money, these interruptions in service can draw even more attention to your failure to secure user data.

## Consolidating customer data will shape the future of utilities

The utilities industry is set to experience major shifts in the coming years thanks to new technologies and energy sources. As competition increases, companies that embrace strong access and identity technology will emerge as leaders that avoid costly mistakes and create deeper connections with their customers.

<include src="asides/AboutAuth0" />

How Utilities Can Use CIAM to Avoid 3 Common Problems

Argentina’s largest credit card issuer uses Auth0 for authentication of financial services

**BELLEVUE, Wash. -- August 13, 2018 --** [Auth0](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), today announced that it has been selected by [Naranja](https://www.naranja.com/), the largest credit card issuer in Argentina, as the sole identity and authentication platform for a wide range of new financial services, including bill pay, online account access, and mobile payments. 

As a leading financial services provider in Argentina, Naranja – along with Naranja VISA, Naranja MasterCard, and Naranja American Express – services more than five million consumers and 260,000 merchants for credit card and e-commerce services. With a mission of consumer connection through technology innovation, Naranja implemented a series of new APIs to accelerate the adoption of several new digital channels and needed an end-to-end identity platform. Auth0’s Universal Identity Platform will be standardized across all new apps. 

“In evaluating several leading identity platforms, it was clear that Auth0 was the most flexible and able to handle the diverse set of requirements for the Naranja API ecosystem that includes our internal apps, digital channels, and partner integrations,” said Javier Voos, Lead Architect at Naranja. “Another major selling point is that Auth0 can keep pace with the aggressive timeline that our digital transformation demands.”

“The potential reach of Naranja’s digital app rollout is astounding and something we’re very excited to be part of,” said Eugenio Pace, CEO and Co-founder of Auth0. “Flexibility and the ability to scale easily to tens of millions of users are foundational principles of our platform. Given the growth and breadth of Naranja’s use cases, we anticipate widespread growth across Latin America, and are honored to serve as the core identity platform across these new services.”

As financial service organizations modernize their offerings to suit the needs of today’s consumer, they realize the importance of a comprehensive identity platform to maximize customer experience, personalize interaction, and create a single view of the customer across every touchpoint. This is why they’re increasingly turning to Auth0. For more information on Auth0 in this sector, please visit: [https://auth0.com/financial-services](https://auth0.com/financial-services). 

<include src="asides/AboutAuth0" />

### **Media Contact:**

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

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

Naranja Chooses Auth0 for Identity Management Across New Digital Offerings

Eugenio Pace joins ranks of mold-breaking entrepreneurs in B2B Software and Services category

**BELLEVUE, Wash. -- June 19, 2018 --** [_Auth0_](https://auth0.com/), a global leader in Identity-as-a-Service (IDaaS), today announced that CEO Eugenio Pace has won the Entrepreneur Of The Year® 2018 Award in the B2B Software and Services category in the Pacific Northwest.

The award recognizes entrepreneurs who are excelling in areas such as innovation, financial performance, and personal commitment to their businesses and communities. Pace was selected by an independent panel of judges, and the award was presented at a special gala event at the Westin Seattle on June 15, 2018.

“To say that I’m truly humbled by this recognition is an understatement,” said Pace. “This award is a culmination of so many things - Auth0, our incredible team, customers, and my support system both inside and outside of the company. I am incredibly honored to be selected for this award.”

Pace continues to lead Auth0 through rapid growth, including more than 100% increase in customers and revenue in 2017 alone. The company also recently announced $55M in Series D funding and is experiencing global momentum as the demand for advanced, modern, and flexible identity management accelerates.

Since 1986, EY has honored entrepreneurs whose ingenuity, spirit of innovation and discipline have driven their companies’ success, transformed their industries and made a positive impact on their communities. Now in its 32nd year, the program has honored the inspirational leadership of such entrepreneurs as:

- Howard Schultz of Starbucks Corporation
- Pierre Omidyar of eBay, Inc.
- Jodi Berg of Vitamix
- Robert Unanue of Goya Foods
- Reid Hoffman and Jeff Weiner of LinkedIn
- Andreas Bechtolsheim and Jayshree Ullal of Arista Networks
- Hamdi Ulukaya of Chobani
- James Park of Fitbit
- J.W. “Bill” Marriott, Jr. of Marriott International, Inc.
- Lonnie Moulder and Mary Lynne Hedley, PhD, of TESARO, Inc.

As a Pacific Northwest award winner, Pace is now eligible for consideration for the Entrepreneur Of The Year 2018 National Awards. Award winners in several national categories, as well as the Entrepreneur Of The Year National Overall Award winner, will be announced at the Entrepreneur Of The Year National Awards gala in Palm Springs, California, on November 10, 2018. The awards are the culminating event of the Strategic Growth Forum®, the nation’s most prestigious gathering of high-growth, market-leading companies.

### _Sponsors_

Founded and produced by EY, the Entrepreneur Of The Year Awards are nationally sponsored in the US by SAP America, the Kauffman Foundation, and Merrill Corporation.

In the Pacific Northwest Region, sponsors also include Woodruff Sawyer.

## About Entrepreneur Of The Year®

Entrepreneur Of The Year®, founded by EY, is the world’s most prestigious business awards program for entrepreneurs, chosen from an independent panel of judges including entrepreneurs and prominent leaders from business, finance, and the local community. The program makes a difference through the way it encourages entrepreneurial activity among those with potential and recognizes the contribution of people who inspire others with their vision, leadership, and achievement. As the first and only truly global awards program of its kind, Entrepreneur Of The Year celebrates those who are building and leading successful, growing and dynamic businesses, recognizing them through regional, national and global awards programs in more than 145 cities in more than 60 countries. ey.com/eoy

<include src="asides/AboutAuth0" />

### Media Contact

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

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

Eugenio Pace of Auth0 Named EY Entrepreneur Of The Year® 2018 Award Winner in the Pacific Northwest

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

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

Former Auth0 Employee

Ado Kukic

The annual Amazon Web Services (AWS) re:Invent conference kicks off this week. Here's a TL;DR of all the big announcements as well as our observations and things we learned.

The AWS re:Invent conference is back in Las Vegas this week and with it comes **five** days of awesome talks, deep-dives, and of course, huge announcements that promise to boost developer productivity, make DevOps simpler, and help companies grow and scale. This year the conference is spread across five hotels on the Las Vegas Strip and features over 1,500 different talks. I would love to be able to attend each one, but since I can't be in 100 places at once, I will share what I learned at the talks I could attend as well as the general announcements that Amazon will have when they host their keynotes on Wednesday and Thursday this week.

![AWS Registration](https://images.ctfassets.net/23aumh6u8s0i/5NswEp40XSF5NMaDbrEIna/c7bf213ba0f229c022ccf629149dd3dc/registration)

At Auth0, we deeply care about **security, compliance, and identity**, and as luck would have it, re:Invent features 117 sessions on just that. The other topic that I focused on today was **serverless** computing and I learned a ton. Since there was no keynote today, below are things I learned at the breakout sessions.

## Session: IAM for Enterprises: How Vanguard Strikes the Balance Between Agility, Governance, and Security

This session was hosted by AWS Security Consultant Reef Dsouza and Senior Security Architect for [Vanguard](https://investor.vanguard.com/corporate-portal/), Rajeev Sharma. Reef set the stage by sharing some best practices when it comes to Identity and Access Management (IAM) and how AWS can help. Some general tips shared include:

* **Defense in Depth** - multiple layers of security.
* **Separation of Duties** - well-defined roles and permissions.
* **Principle of Least Privilege** - users should only have access to what they absolutely need.

Rajeev went on to explain how Vanguard, one of the largest investment companies in the world, applied these guidelines when moving their architecture to the AWS cloud and the numerous benefits that it brought them. 

Many of the best practices that Reef shared, we at [Auth0](https://auth0.com) have been very vocal about as well. [Read our five tips on how you can make your app more secure in less than 20 minutes](https://auth0.com/blog/5-ways-to-make-your-app-more-secure-in-less-than-20-minutes/). 

## Session: Serverless for Security Officers: Paradigm Walkthrough and Comprehensive Security Best Practices

This session, hosted by Jonathan Desrocher, Eugene Yu, and Henrik Johansson, focused on best security practices as they pertain to serverless applications. Serverless applications are gaining more and more momentum, and whether you go with [AWS Lambda](https://aws.amazon.com/lambda/), [Auth0 Webtask](https://webtask.io), or another serverless platform, you are sure to have questions on the various security considerations that arise when using these platforms.

![Serverless Security Paradigm](https://images.ctfassets.net/23aumh6u8s0i/27UjOgJJ8Gih7xp17BIOfq/559e2161bf0b8c9dae07d92e3a127477/security)

The good news is that essentially all the best security practices that pertain to traditional applications also apply to serverless applications as well. The bad news is that each function is a potential attack vector, so they require a bit more effort and attention to properly secure. Additionally, with serverless, the platform provider takes on a much larger role when it comes to securing the application, but at the end of the day, security is everyone's responsibility.

## Session: Credentials, Credentials, Credentials, Oh My!

Quint Van Deman of AWS hosted this **chalk talk**, which consisted of a 10-15 minute presentation on best practices when it comes to managing the various credentials in the AWS ecosystem, and then a 45 minute Q&A session where he asked the audience for use cases and worked out best practices for those use cases. We covered many complex use cases involving the various AWS credential services including Cognito, Secure Token Service (STS), and various forms of credential exchanges whether internal at AWS or exchanging credentials from a third party service like Auth0.

![AWS Credentials](https://images.ctfassets.net/23aumh6u8s0i/CAUKsPAy7O2OV0cO9Jfe3/2203138d67defc488c9607cacbc09869/credentials)

One of the key takeaways from this session was that having a centralized source of truth and federating that identity throughout your infrastructure was superior to having multiple identity stores for the different applications in your infrastructure. [Learn more about Single Sign On](https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/) and [how you can call AWS APIs with Auth0 tokens](https://auth0.com/docs/integrations/aws).

## Session: Evolution of Serverless Architectures Through the Lens of Community

Serverless is taking the development world by storm. This was a very enlightening talk by Peter Sbarski and Sam Kroonenburg of [A Cloud Guru](https://acloud.guru/), one of the early adopters of serverless technology. Sam, the founder of A Cloud Guru, even showed that their production account had no active Amazon EC2 instances. This session focused on the growth of serverless architectures over the last three years and highlighted some of the providers as well as consumers of serverless technologies. Sam also covered the growing community around serverless which included quotes from many prominent members of the community, serverless meetups around the world, and even a conference!

![Auth0 at AWS](https://images.ctfassets.net/23aumh6u8s0i/4qb5L0Fhet60RmV251mY6q/5faffafb398bea2c0e0208a102f311e4/auth0)

Auth0's [Webtask](https://webtask.io) also got a shout-out, as did [Auth0's identity solution](https://auth0.com). Sam closed out his talk by sharing some emerging patterns in the serverless community, especially [application modernization and microservices, which you can learn much more about here](https://auth0.com/blog/getting-a-competitive-edge-with-a-microservices-based-architecture/).

Finally, Hernan Garcia of [CityWallet](https://www.citywallet.net/) gave a real-world example of how he and his team achieved success with a serverless architecture when their more traditional methods failed and put their startup at risk.

## Session: Compliance and Top Security Threats in the Cloud—Are You Protected?

We closed out the day with a very informational session on top security threats that organizations face by Teri Radichel of [WatchGuard Technologies](https://www.watchguard.com/) and Boyan Dimitrov of [Sixt](https://www.sixt.com/). The top threats included were:

* **Unprotected keys and credentials.**
* **Broad permissions for engineers.**
* **Unpatched software.**
* **Malicious software updates.**
* **Open network ports.**
* **Flat network design.**
* **Broad permissions for applications.**
* **Bad configuration management.**
* and **Data Exfiltration.**

Teri discussed how these threats led to large data breaches such as the [Equifax Data Breach](https://auth0.com/blog/equifax-data-breach/) that leaked the Social Security Numbers of almost all Americans and the [WannaCry Ransomware](https://auth0.com/blog/a-massive-ransomware-attack-targets-organizations-around-the-globe/) which locked out banks, airlines, and even hospitals. 

Boyan discussed strategies on how to mitigate risk and the key takeaway was that compliance does not equal security. Many of the companies that experienced data breaches were compliant with many standards and organizations but were still breached. Security is something that must be constantly monitored to be effective.

## Aside: Auth0 and AWS

If you are using AWS to manage your infrastructure, whether it be traditional, serverless, or a mix, and are looking to better manage identity in your applications, Auth0 can help you to:

* Add authentication through traditional username/password databases.
* Add support for linking different user accounts with the same user.
* Support for generating signed JSON Web Tokens to call your APIs and flow the user identity securely.
* Analytics of how, when, and where users are logging in.
* Pull data from other sources and add it to the user profile, through [JavaScript rules](https://docs.auth0.com/rules).
* Achieve [SSO (Single Sign-On)](https://auth0.com/docs/sso) seamlessly.

<a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up</a> for a free account today and enjoy fast, seamless, and hassle-free authentication in your apps.

## Summary

Day 1 of the re:Invent was very eventful. I wish I could have attended more talks, but the talks I could make it to were very insightful and left me wanting more. Tune in the rest of the week as I cover more in-depth sessions as well as the keynotes. I hope you find this TL;DR useful.

AWS re:Invent Day 1 Recap

Integrating cloud security services into your app not only keeps you and your users safe, it can actually accelerate your development process.



Over the course of the 2010s, cloud computing has shifted from being a bleeding edge solution to a standard expectation in data management. Not only has it allowed consumers and the enterprise to flexibly scale their storage needs, it has also redefined the software industry towards a cloud-based service model.

There are a ton of other benefits, allowing developers to streamline their development process and offer users a more refined and accessible experience. But what's one cloud advantage that the mobile app industry hasn't taken full advantage of? Security.

By delegating specialized tasks like IAM and encryption to cloud services that are 100% committed to following the latest security standards, you can spend more time building out your app without sacrificing the security of your users. In a cutthroat marketplace, delegating high-stakes features such as IAM to cloud providers can give you the competitive advantage you need to succeed, all while improving the security practices of your users.

## Security Advantages of The Cloud

Relying on a distributed cloud model for your security and authentication needs is a bit of a no brainer, as a developer you'll have more time to commit to making your app the best it can be, all while making sure your users are well taken care of.

The main advantage of cloud services in security and authentication contexts stems from their distributed nature. If you had an in-house authentication or data storage platform, a single point of failure might emerge, leaving your users stranded. But by relying on distributed authentication or hosting services, with multiple backups and agile update schedules, you can count on a more stable and scalable backend to keep your users happy and safe.

![Amazon EC1](https://images.ctfassets.net/23aumh6u8s0i/1Biy5EkrCPetFFit29avAh/ff3dbcec5cab9ef7febc49eaf1d86dea/ecs1)
_[Source:](http://www.allthingsdistributed.com/2015/07/under-the-hood-of-the-amazon-ec2-container-service.html)  Amazon's EC2 Container Service helps reliably balance cloud resources and clusters within a system._

In the case of Amazon Web Services, their concept of [“systems containers”](https://aws.amazon.com/blogs/publicsector/improving-security-with-cloud-computing-six-advantages-of-cloud-security/) sheds light on how cloud security structures can actually serve as powerful analytics tools. Due to the bubble-like nature of cloud systems as they surround traditional systems, they can provide insight into irregular behaviors and perform load balancing. Even if a cloud system isn't actively aware of the inner workings of each system element, it can create reactive responses and protect the integrity of your platforms.

By allowing your backend to be self-regulating, scalable, and constantly updated to the latest standards, you can make your app far more responsive to changing security threats and technologies.

## Why Outsource Identity?

At the end of the day, most developers simply don't have the time or expertise to build out robust IAM or data encryption platforms — developers need to delegate in order to give their users access to the best service possible. Luckily, that's where the cloud services model has proven to be most valuable, enabling you to externalize the most difficult platforms to the experts.

### USE YOUR RESOURCES EFFICIENTLY

As a developer, one of the most overlooked aspects of the development process is figuring out how to design your app to adhere to the most stringent security and authentication standards. It's a tall order — you can't be expected to be an expert in everything, yet nightmares stemming from bad security practices loom large.

What's worse, many users rely on developers, designers and onboarding to nudge them towards responsible identity behaviors, but mandating the strictest security practices can be a turn-off — that's a lot to balance.

By integrating a cloud IAM framework into your app, not only are you able to ensure that your users are adhering to industry standards, you also can actually make both development and user experience easier.

### ADHERE TO INDUSTRY STANDARDS

One of the best practices for rock-solid IAM is to use [Multifactor Authentication](https://auth0.com/docs/multifactor-authentication)(MFA). MFA allows your app to verify users using multiple devices, such as SMS, allowing you to mitigate impostors.

![Guardian Push](https://images.ctfassets.net/23aumh6u8s0i/1snZRjltIO6EdRAmpAEDOx/c3372491fed8e2a459ce6dd01236209e/guardian-push)

_Source: Auth0's [Guardian](https://auth0.com/multifactor-authentication) multi-factor authentication platform makes it easy to add Identity verification in your app._

MFA has quickly become an industry standard, but it requires a ton of backend work, ranging from SMS integration architecture to hardware tokens. For smaller developers, creating an MFA strategy from the ground up is an inefficient use of resources, so it makes sense to use an external cloud-based service like Auth0 to integrate with your login and onboarding flows.

### STREAMLINE YOUR SIGNUP

Social login is popular because it helps users who are less motivated to sign up using their email and password to simply sign up using their Facebook or Google accounts in just 1 or 2 clicks, avoiding the often cumbersome nature of traditional signup flows.

As a result, social login is becoming increasingly ubiquitous, and it has allowed developers to become familiar with integrating Identity APIs in their code. If developers are willing to use plugins and APIs to make their users' experiences just a little bit easier, they should also consider external cloud IAM solutions to bolster their security strategy.

The decision to outsource identity is ultimately up to each developer, for use cases as audience needs are highly variable. But developers should consider how easy it is to add cloud services to their stack, and learn about the benefits of additional identity-driven [analytics capabilities](https://auth0.com/learn/powering-user-analytics-identity/) that they enable. In such a competitive market, any efficiency and/or experience improvement can have a profound impact on the success of products.

## How Auth0 implements Cloud Identity

While it might seem like it's overwhelming to implement a cloud IAM architecture like Auth0, it's actually quite easy. Auth0 is immensely flexible, offering SDKs for a wide range of platforms, ranging from Java, PHP, Python, and iOS, among others, and allows developers to build upon it with C# or JavaScript to suit their needs.

Structurally, Auth0 serves as a bridge between apps and users, aiding in authentication and identity processes using the [OAuth2](https://auth0.com/docs/protocols/oauth2) protocol. The OAuth2 protocol enables users to grant regulated permissions from one site onto a different site, without having to expose their credentials. This is done through access tokens, which represent the granted permissions:

![Mobile API](https://images.ctfassets.net/23aumh6u8s0i/7D51x7o8JqhfOlvkrN1cVb/901f5c1e1699aa5a6a3b5383da8b00b2/mobile-api)

By default, Auth0 runs in the public cloud, but you can choose to run it privately on large cloud hosting services like AWS, or even locally if you're so inclined. Regardless of the structure of your app and its dependence on either local or cloud platforms, Auth0's cloud IAM acts as a stable go-between that can provide consistent service and agile updates as security standards evolve.

Whether you're in a time crunch or simply just want to have bulletproof IAM built into your app, implementing Auth0 into your product is quick and easy. If you're an iOS developer, all you need to do is add a few lines of code into your app for the [Lock](https://auth0.com/docs/libraries/lock-ios/v2) embeddable login form to start working.

## Embrace Cloud Security for a Competitive Edge

When developing a new app, creating high-stakes tools for authentication and data security can seem insurmountable. Instead of building out an imperfect system and putting you and your customers at risk, you could always rely on a service like Auth0 to take care of the hard details, enabling you to make better use of your resources.

The app space can be incredibly cutthroat, so any way to make your app more efficient and robust can translate into a real competitive advantage. By delivering a product with top-tier IAM and cloud architectures, you can deliver a more scalable and agile product that will be able to stand out in the marketplace.


Moving Your App to the Cloud

bruno-krebs

I am passionate about developing highly scalable, resilient applications. I love everything from the database, to microservices (Kubernetes, Docker, etc), to the frontend. I find amazing to think about how all pieces work together to provide a fast and pleasurable experience to end users, mainly because they have no clue how complex that "simple" app is.

R&D Content Architect

Bruno Krebs

The New York State Department of Financial Services (DFS) has issued a new regulation that defines cybersecurity requirements for financial companies.



The New York State Department of Financial Services (DFS), the state's top banking regulator, proposed last year a set of cybersecurity requirements that must be implemented by banks, insurances and other services companies of the financial industry. This set of regulations, technically called [23 NYCRR 500](http://www.dfs.ny.gov/legal/regulations/adoptions/dfsrf500txt.pdf), aim on improving the overall security of information systems and data (nonpublic information) used by such companies.

The full document, detailing each requirement, [can be found on DFS's website](http://www.dfs.ny.gov/legal/regulations/adoptions/dfsrf500txt.pdf). Basically, it states that companies (referred as *Covered Entities* in the document) shall maintain a cybersecurity program designed to protect the confidentiality, integrity and availability of their systems. The regulation defines that this program must address topics like:

- *Cybersecurity Policy*, where companies must implement and maintain written policies,
approved by a Senior Officer, officializing the procedures that protect systems and nonpublic information.
- *Chief Information Security Officer*, where companies must designate a qualified individual
responsible for overseeing and implementing the program.
- *Penetration Testing and Vulnerability Assessments*, where companies must implement continuous monitoring, periodic penetration testing, and vulnerability assessments to validate the companies efforts.
- *Access Privileges*, where companies shall limit user access privileges to systems that provide access to nonpublic information.
- *Third Party Service Provider Security Policy*, where companies must define policies and
procedures designed to ensure the security of systems and nonpublic information that are accessible
to, or held by, Third Party Service Providers.
- *Multi-Factor Authentication*, where companies must define and use effective
controls to protect against unauthorized access.
- *Encryption of Nonpublic Information*, where companies must implement controls, like encryption, to protect nonpublic information held or transmitted.

The whole document includes a total of 18 topics (from where the excerpt above was extracted) with details about what financial companies must consider while implementing their cybersecurity programs. Besides these topics, the document also includes details about when the regulation becomes effective and details about transitional periods. [Another resource](http://www.dfs.ny.gov/about/cybersecurity.htm), also found on the DFS's website, summarizes the key dates as follows:

- *March 1, 2017*—the regulation becomes effective.
- *August 28, 2017*—transitional period of 180 days, where companies are required to be in compliance with requirements.
- *September 27, 2017*—30 day period for filing notices of exemption under the regulation.
- *February 15, 2018*—companies are required to submit the first regulation certification.
- *March 1, 2018*—transitional period ends for the requirements of sections 500.04(b), 500.05, 500.09, 500.12, and 500.14(b).
- *September 3, 2018*—transitional period ends for the requirements of sections 500.06, 500.08, 500.13, 500.14(a), and 500.15.
- *March 1, 2019*—transitional period end for the requirements of the other sections.

## Auth0 to the Rescue

As stated by this new regulation, companies of the financial industry that belongs to (or have branches in) the state of New York must define policies and procedures to ensure the security of systems and nonpublic information that are accessible by Third Party Service Providers. Auth0, as a security company that provides the best identity management solution possible, can help companies of this industry by providing, as a third party partner, identity and access management services based on the best security practices and tools available.

So, if you are a financial company, with a branch in the state of New York, we can help you to comply with the requirements defined in the **23 NYCRR 500** regulation. Over the years, we’ve defined a state of the art approach to security that layers protections throughout our entire application stack as well as regular security training and exercises for our workforce. Recently, we have released a [white paper](https://auth0.com/security) that details our approach to security so that suscribers can better understand how their data is protected.

Below, you can view the table of contents for the white paper. The whole document can be found [on the Auth0's security webpage](https://auth0.com/security).

```bash
- Introduction
- Dedicated Security Team
  |- People and Processes
  |- Background Checks
  |- Security Awareness
  |- Access Requests
  |- Security Policies
  |- Privacy
- Secure Product Development
  |- Specification Compliance
  |- Authentication Experts
  |- Code Review
  |- Development Tools
  |- Secret Management
  |- White Hat Program
  |- OWASP Compliance
  |- Deployment Process
- Third-Party Compliance
  |- SOC II Type 2
  |- External Security Assessments
- Infrastructure and Data Security
  |- Cloud Security
  |- Infrastructure as Code
  |- Network Security
  |- Security Monitoring
  |- Authentication
  |- Data Encryption
  |- Laptop and Mobile Device Security
- Disaster Recovery and Backup
  |- Business Continuity Plan
  |- Backup Strategy
- Vendor security
  |- Security Team Review
  |- Privacy Considerations
- Summary
```

One of the reliable and interesting services that Auth0 can provide to companies of the financial industry, is the easy-to-adopt [Multi-Factor Authentication (MFA) solution](https://auth0.com/multifactor-authentication). Exactly as referenced by the regulation, this method provides an additional layer of security, decreasing the likelihood of unauthorized access, as it requires users to identify themselves through two or more of the following methods:

- *Knowledge*: Something the user knows (e.g. a password).
- *Possession*: Something the user has (e.g. a cell phone).
- *Inheritance*: Something the user is (e.g. a fingerprint or retina scan).

The upside of adopting the MFA solution ([or any other solution for that matter](https://auth0.com/b2b-enterprise-identity-management)) provided by Auth0, is that it helps companies getting up to speed real quickly while resting assured that they are relying on a partner that has security as the first goal.

If you work for a company in the financial industry, or for any other company that cares about security and data integrity, [check out some case studies to understand how companies all around the world have successfully implemented secure identity management in their applications](https://auth0.com/b2b-enterprise-identity-management). We are on a mission to [lower the number of data breaches, and we don't want you and your users to be another victim](https://auth0.com/blog/data-breaches-by-the-numbers/).

## Aside: Securing Applications with Auth0

Are you building a [B2C](https://auth0.com/b2c-customer-identity-management), [B2B](https://auth0.com/b2b-enterprise-identity-management), or [B2E](https://auth0.com/b2e-identity-management-for-employees) tool? Auth0, can help you focus on what matters the most to you, the special features of your product. [Auth0](https://auth0.com/) can improve your product's security with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication).

[We offer a generous **free tier**](https://auth0.com/pricing) so you can get started with modern authentication.


Attention! New Regulation for New York Financial Companies

9d2e715baab928f5bedb837bfcb70b2b

Guest Author

Gabor Soos

Learn how to test HTTP services in Angular. We will start by writing tests for requests and finish by refactoring them to a cleaner format.

<div class="alert alert-info alert-icon">
 
 Get the "Migrating an Angular 1 App to Angular 2 book" for Free. Spread the word and <a href="https://auth0.com/e-books/migrating-to-angular2">download it now!</a>
</div>

When we write a web application, most of the time it has a backend.
The most straightforward way to communicate with the backend is with HTTP requests.
These requests are crucial for the application, so we need to test them.
More importantly, these tests need to be isolated from the outside world.
In this article I will show you how to test your requests properly and elegantly.

This article is the second part of a series in which
I share my experiences testing different building blocks of an Angular application.
It relies heavily on Dependency Injection based testing and
it is recommended that you read [the first part](https://auth0.com/blog/angular-2-testing-in-depth-services/)
if you are not familiar with the concepts.

- [Services](https://auth0.com/blog/angular-2-testing-in-depth-services/)
- HTTP Services (this article)
- [Components](https://auth0.com/blog/angular-testing-in-depth-components/)
- Pipes
- Routing

### Testing our first request


 <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-http-services/github-logo.png" alt="Angular Testing Framework"/>


To get started we will test a basic request, the GET request.
It will call a parameterized url without a body or additional headers.
The [Github API](https://developer.github.com/v3/) has an endpoint for retrieving public profile information about users.
The profile information is returned in JSON format.

```typescript
import { Injectable } from '@angular/core';
import { Http, Response } from '@angular/http';
import 'rxjs/add/operator/map';

@Injectable()
export class GithubService {
 constructor(private http: Http) {}

 getProfile(userName: string) {
 return this.http
 .get(`https://api.github.com/users/${userName}`)
 .map((response: Response) => response.json());
 }
}
```

The ```getProfile``` method sends a GET request to the API and returns the response.
Every request made with the ```HttpModule``` returns an ```Observable.```
The returned value will always be a ```Response``` object, which can return the response body.
With the help of the ```json``` or ```text``` method we can transform the value of the Observable.

The first thing we have to do is to set up the test dependencies.
The ```Http``` dependency is required.
If we don't provide it, we will get this error message: ```No provider for Http!```.

```typescript
beforeEach(() => {
 TestBed.configureTestingModule({
 providers: [GithubService],
 imports: [HttpModule]
 });
});
```

The problem with the real ```HttpModule``` is that we will end up sending real HTTP requests.
It is an absolutely terrible idea to do this with unit tests, because it breaks the test's isolation from the outside world.
Under no circumstances will the result of the test be guaranteed.
For example, the network can go down and our well-crafted tests will no longer work.

Instead, Angular has a built-in way to fake HTTP requests.

```typescript
import { MockBackend, MockConnection } from '@angular/http/testing';
import { Http, BaseRequestOptions, Response, ResponseOptions, RequestMethod } from '@angular/http';

...

beforeEach(() => {
 TestBed.configureTestingModule({
 providers: [
 GithubService,
 MockBackend,
 BaseRequestOptions,
 {
 provide: Http,
 useFactory: (mockBackend: MockBackend, defaultOptions: RequestOptions) => {
 return new Http(mockBackend, defaultOptions);
 },
 deps: [MockBackend, BaseRequestOptions]
 }
 ]
 });
});
```

Instead of providing ```Http``` as a module,
it is better to use the factory provider and pass the ```MockBackend``` instance to the ```Http``` constructor.
This way the fake backend captures every request and can respond accordingly.

Before writing the first test it is also important to get an instance of the ```MockBackend,```
because without it we won't be able to respond to requests.

```typescript
beforeEach(inject([GithubService, MockBackend], (github, mockBackend) => {
 subject = github;
 backend = mockBackend;
}));
```

Let's write the first test that checks the result of the request.

```typescript
it('should get profile data of user', (done) => {
 let profileInfo = { login: 'sonic', id: 325, name: 'Tester' };
 backend.connections.subscribe((connection: MockConnection) => {
 let options = new ResponseOptions({ body: profileInfo });

 connection.mockRespond(new Response(options));
 });

 subject.getProfile('blacksonic').subscribe((response) => {
 expect(response).toEqual(profileInfo);
 done();
 });
});
```

Requests made are available through the ```connections``` property of the fake backend as an ```Observable.```
When it receives the request through the ```subscribe``` method we can respond with a JSON object.

In our example only the response body is set. In addition, you can set the status and the headers of the request.

Another new element is the ```done``` callback that is passed into the test function.
It is needed when writing asynchronous tests.
This way the test doesn't end when the execution of the function ends.
It will wait until the ```done``` callback is called.
Of course, there is a timeout for hanging tests that don't call this ```done``` method within a given interval.

HTTP requests are asynchronous by nature,
but the fake backend we use responds to them synchronously (it calls the ```subscribe``` method synchronously).
You may wonder what makes the test asynchronous, then.

The answer is false positive tests.
If we comment out the response to the request, the test will still pass, even though we have an assertion.
The problem here is that the ```subscribe``` callback never gets executed if we don't respond to the request.

```typescript
it('should get profile data of user', () => {
 // backend.connections.subscribe...

 subject.getProfile('blacksonic').subscribe((response) => {
 expect(response).toEqual(profileInfo);
 });
});
```
### Checking the request

Until now we haven't made any assertions for the request.
For example, what was the called url, or what was the method of the request?
To make the test more strict we have to check these parameters.

```typescript
backend.connections.subscribe((connection: MockConnection) => {
 expect(connection.request.url).toEqual('https://api.github.com/users/blacksonic');
 expect(connection.request.method).toEqual(RequestMethod.Get);

 ...
});
```

The original ```Request``` object resides on the ```MockConnection``` object.
With its ```url``` and ```method``` property, we can add the assertions easily.

### Digging deeper

GET requests are good for retrieving data, but we'll make use of other HTTP verbs to send data.
One example is POST.
User authentication is a perfect fit for POST requests.
When modifying data stored on the server we need to restrict access to it.
This is usually done with a POST request on the login page.


 <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-http-services/auth0-logo.png" alt="Angular Testing Framework"/>


Auth0 provides a good solution for handling user authentication.
It has a feature to authenticate users based on username and password.
To demonstrate how to test POST requests, we will send a request to the Auth0 API.
We won't be using their recommended package here, because it would abstract out the actual request,
but for real-world scenarios I would recommend using it.

```typescript
@Injectable()
export class Auth0Service {
 constructor(private http: Http) {}

 login(username: string, password: string) {
 let headers = new Headers({
 'Content-Type': 'application/json'
 });
 let options = new RequestOptions({ headers });

 return this.http
 .post(
 'https://blacksonic.eu.auth0.com.auth0.com/usernamepassword/login',
 { username, password, client_id: 'YOUR_CLIENT_ID' },
 options
 )
 .map((response: Response) => response.text());
 }
}
```

The main difference between this example and the previous one is that here we are sending a JSON payload to the server
and appending additional headers onto it.
We don't have to manually ```JSON.stringify``` the payload --- the request methods will take care of it.
The response will be in text format, so this time we don't have to convert anything to JSON.

Let's look at the test to see how we can check every detail of the request.

```typescript
it('should be called with proper arguments', (done) => {
 backend.connections.subscribe((connection: MockConnection) => {
 expect(connection.request.url).toEqual('https://blacksonic.eu.auth0.com.auth0.com/usernamepassword/login');
 expect(connection.request.method).toEqual(RequestMethod.Post);
 expect(connection.request.headers.get('Content-Type')).toEqual('application/json');
 expect(connection.request.getBody()).toEqual(JSON.stringify(
 {
 username: 'blacksonic',
 password: 'secret',
 client_id: 'YOUR_CLIENT_ID'
 }, null, 2
 ));
 ...
 });

 subject.login('blacksonic', 'secret').subscribe((response) => {
 expect(response).toEqual('<form />');
 done();
 });
});
```

The headers are also available on the ```Request``` object and can be checked one by one.
The payload can be retrieved with the ```getBody``` method.
This method always returns the body converted to a string, which will we see in the network traffic.
When we send JSON it will contain the output of the ```JSON.stringify``` method: printed with spaces and an indentation of two.

### Refactoring

The previous setup works, but it has multiple problems.

- For every service we test, the provider configuration will be exactly the same.
- The subscription to the outgoing connection responds the same immediately, regardless of the url.
- The assertions are verbose and hard to read.

Those who have tested their HTTP services in Angularjs may remember how simple the setup was for those tests.
Angularjs provided convenient methods for setting expectations on requests.

Angular doesn't have those built-in functionalities,
but very similar ones are present in the [ngx-http-test](https://github.com/blacksonic/ngx-http-test) library.

It can solve the problems mentioned earlier.
Let's look at the test with the library for the Github profile fetch.

```typescript
...
import { FakeBackend } from 'ngx-http-test';

describe('GithubServiceRefactored', () => {
 ...

 beforeEach(() => {
 TestBed.configureTestingModule({
 providers: [
 GithubService,
 FakeBackend.getProviders()
 ]
 });
 });

 beforeEach(inject([GithubService, FakeBackend], (github, fakeBackend) => {
 subject = github;
 backend = fakeBackend;
 }));

 it('should get profile data of user', (done) => {
 backend
 .expectGet('https://api.github.com/users/blacksonic')
 .respond(profileInfo);

 subject.getProfile('blacksonic').subscribe((response) => {
 expect(response).toEqual(profileInfo);
 done();
 });
 });
});

```

The setup becomes a function call to ```FakeBackend.getProviders()```.
Setting the expectation hides the subscription and gives more readable methods like ```expectGET```.

The login test also becomes less verbose.

```typescript
it('should be called with proper arguments', (done) => {
 backend.expectPost(
 'https://blacksonic.eu.auth0.com.auth0.com/usernamepassword/login',
 {
 username: 'blacksonic',
 password: 'secret',
 client_id: 'YOUR_CLIENT_ID'
 },
 { 'Content-Type': 'application/json' }
 ).respond(responseForm);

 subject.login('blacksonic', 'secret').subscribe((response) => {
 expect(response).toEqual('</form>');
 done();
 });
});
```

## Aside: Securing Angular Applications with Auth0

Are you building a product with Angular? We at Auth0, can help you focus on what matters the most to you, the special features of your product. [Auth0](https://auth0.com/) can help you make your product secure with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication). [We offer a generous **free tier**](https://auth0.com/pricing) to get started with modern authentication.

We provide the simplest and easiest to use [User interface tools to help administrators manage user identities](https://auth0.com/user-management) including password resets, creating and provisioning, blocking and deleting users.

### Conclusion: What we've learned about Angular HTTP testing

In this tutorial, we managed to:

- setup tests and fake an HTTP backend
- write assertions for requests
- refactor the tests to be more readable

Angular has the tools to test HTTP requests, but still lacks the readable assertion methods that were present in Angularjs.
Until such methods are implemented, the [ngx-http-test](https://github.com/blacksonic/ngx-http-test) library can be used.

To see the tests in action check out
[this GitHub repository](https://github.com/blacksonic/angular-testing-ground "Angular testing ground").

Angular Testing In Depth: HTTP Services

Learn how to test services in Angular. We will start with setting up the environment and finish with using Dependency Injection.

<div class="alert alert-info alert-icon">
 
 Get the "Migrating an Angular 1 App to Angular 2 book" for Free. Spread the word and <a href="https://auth0.com/e-books/migrating-to-angular2">download it now!</a>
</div>

When I started developing and writing tests for Angularjs applications,
everything felt natural. The tools were mature and I easily got used to
developing applications in TDD ([Test-Driven Development](https://en.wikipedia.org/wiki/Test-driven_development)).
It gave me a high level of confidence, knowing that my application was working as I had imagined.
Just after Angular 2 came out and I learned the basics, I knew that the next step was to testing.

This article is the first part of a series in which
I share my experiences testing different building blocks of an Angular application.
We will start with simple use cases and then head for more complex ones.

- Services (this article)
- [Http Services](https://auth0.com/blog/angular-testing-in-depth-http-services/)
- [Components](https://auth0.com/blog/angular-testing-in-depth-components/)
- Pipes
- Routing

You may wonder why it is so important to write tests.


 <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/tdd_guilty.png" alt="Angular Testing Driven Development"/>


With tests, we can ensure the correctness of our application: that the code does what it was designed to do.
We can guard against someone breaking our code by refactoring or
adding new features. This might have happened to you when someone added a small feature
or equivalent code transformations and nothing worked afterwards.
Writing tests can clarify the intention of the code by giving usage examples.
It can also reveal design flaws. When a piece of code is hard to test,
there might be a problem with the underlying architecture.

If you are new to Test-Driven Development, I would recommend reading the Test-Driven Development book by Kent Beck.
It gives a nice overview about the concepts and best practices.

### Choosing the framework to test Angular


 <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/jasmine-mocha.png" alt="Angular Testing Framework"/>


The first thing we have to choose is the framework. The one suggested by Angular's core team is
[Jasmine](http://jasmine.github.io/edge/introduction.html).
For a long time it was the only supported testing framework, because test setups were hard wired into the framework.
Thanks to refactoring, now tests can also be written in [Mocha](https://mochajs.org/), or any other framework
that supports the ```beforeEach``` hook. This hook runs before every test run.
If your framework of choice doesn't support it, you have to add the following code snippet to your setup:

```typescript
import { resetFakeAsyncZone, TestBed } from '@angular/core/testing';

beforeEveryTestHook(() => {
 TestBed.resetTestingModule();
 resetFakeAsyncZone();
});
```

The first line within the hook resets the internal state of the Dependency Injection container.
It clears out any given provider or module.
If you are not familiar with Dependency Injection, I would recommend reading the
[official documentation](https://angular.io/docs/ts/latest/guide/dependency-injection.html) about it.

The second one clears out any remaining zone that fakes asynchronous operations like ```setTimeout```.
Detailed articles can be found on the Thoughtram blog about zones:
[Understanding zones](http://blog.thoughtram.io/angular/2016/01/22/understanding-zones.html) and
[Zones in Angular](http://blog.thoughtram.io/angular/2016/02/01/zones-in-angular-2.html).

For this series, we will be using Jasmine as the test framework.

### Writing the first Angular test

Let's look at our first service that will be tested.

```typescript
import { Injectable } from '@angular/core';

@Injectable()
export class Engine {
 getHorsepower() {
 return 150;
 }

 getName() {
 return 'Basic engine';
 }
}
```

It has two getter methods and the ```Injectable``` decorator.
The tests will check whether these getter methods work as intended.
The decorator is needed to utilize dependency injection.

In Jasmine, we can group our tests with the ```describe``` method.
Within this method, we can create test cases with the ```it``` function.
It is advised to place one class per file (the service) and group the tests around it (with ```describe```).
We can further group test cases around methods of the class
by placing ```describe``` statements inside the top ```describe``` block.
For now we will only group our tests around the class.

```typescript
import { Engine } from './engine.service';

describe('Engine', () => {
 it('should return it\'s horsepower', () => {
 let subject = new Engine();

 expect(subject.getHorsepower()).toEqual(150);
 });
});
```

In this setup, only plain instantiation is used; we will introduce dependency injection later.
For basic services, plain instantiation can be enough.

We call the ```getHorsepower``` method of the engine and check that it's equal to the expected value.

The first test is green and has been passed. Let's write another one for the ```getName``` method.

```typescript
it('should return it\'s horsepower', () => {
 let subject = new Engine();

 expect(subject.getName()).toEqual('Basic engine');
});
```

If you run the tests, a similar output will be on the terminal.

![Angular First Tests](https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/first_test_run.png)

Both tests have been passed; it is time to refactor.
There is duplication at the start of each Angular test. Instantiation is exactly the same,
we can move it out into a setup block.

```typescript
describe('Engine', () => {
 let subject: Engine;

 beforeEach(() => {
 subject = new Engine();
 });

 it('should return it\'s horsepower', () => {
 expect(subject.getHorsepower()).toEqual(150);
 });

 it('should return it\'s horsepower', () => {
 expect(subject.getName()).toEqual('Basic engine');
 });
});
```

The ```subject``` variable is declared at the start of the ```describe``` block, and the creation of the service
is moved to the ```beforeEach``` block. This way we don't have to do it manually every time.
It is common to move the creation of the test case subject to a separate method,
because it offloads the tests and makes them more readable.

### Using Dependency Injection

Creating services directly can be good if the subject under test has no or few, dependencies.
But if it has multiple dependencies, or a deeper dependency tree, setting up all the classes becomes tedious.
For these situations, we can use Angular's dependency injection management.

The ```Car``` class uses the ```Engine``` class in the constructor and its instance in the ```getName``` method.

```typescript
import { Injectable } from '@angular/core';
import { Engine } from './engine.service';

@Injectable()
export class Car {
 constructor(private engine: Engine) {}

 getName() {
 return `Car with ${this.engine.getName()}(${this.engine.getHorsepower()} HP)`;
 }
}
```

We check for the ```getName``` method's output in the test after we set up the dependency injection container.

```typescript
import { TestBed, inject } from '@angular/core/testing';
import { Engine } from './engine.service';
import { Car } from './car.service';

describe('Car', () => {
 let subject: Car;

 beforeEach(() => {
 TestBed.configureTestingModule({
 providers: [Engine, Car]
 });
 });

 beforeEach(inject([Car], (car: Car) => {
 subject = car;
 }));

 it('should display name with engine', () => {
 expect(subject.getName()).toEqual('Car with Basic engine(150 HP)');
 });
});
```

The difference here is that we configure the ```TestBed``` with the provided
services in the ```configureTestingModule``` method.
Only these classes can be instantiated with the ```inject``` method.
If we try to request something else, we get an error saying it is an unknown provider.

![Angular Testing Error](https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/test_failure_missing_dep.png)

We can request instances of the services in an array from the ```inject``` method.
In the callback, we get the instances in the same order as in the dependency array with the first parameter.
The type hint inside the callback is only for IDE completion; it also works without it.
In the example, it is placed inside the ```beforeEach``` function, but it can also be added to the ```it``` block.

```typescript
it('should display name with engine', inject([Car], (car: Car) => {
 expect(car.getName()).toEqual('Car with Basic engine(150 HP)');
}));
```

### Mocking

In unit tests for Angular, we want to execute the code in isolation.
This means it is not dependent on big, complex objects and is not calling methods that rely on external systems
(like [HTTP calls](https://auth0.com/blog/angular-2-series-part-3-using-http/) or database access).
In these cases, we want to simulate the original behavior while skipping the underlying implementation.

When achieved, it is called mocking.
We don't have to do it manually. Jasmine provides tools to make it work.
Let's assume that the method of the ```Engine``` class has a call through to the server
and we want to mock it.

```typescript
...
beforeEach(() => {
 TestBed.configureTestingModule({
 providers: [Engine, Car]
 });

 spyOn(Engine.prototype, 'getHorsepower').and.returnValue(400);
 spyOn(Engine.prototype, 'getName').and.returnValue('V8 engine');
});

...

it('should display name with engine', () => {
 expect(subject.getName()).toEqual('Car with V8 engine(400 HP)');
});
```

We mock the class methods by calling the ```spyOn``` method on the class's prototype.
We also alter the return value of the function. This way the original method never gets called.
When mocking the prototype, it affects every instance of the class.

### Using Dependency Injection for Mocking

The previous solution for mocking can be achieved also with Angular's dependency injection mechanism.
We pass the ```Engine``` class as the provider token, but create the instances with a fake class.

```typescript
@Injectable()
class V8Engine {
 getHorsepower() {
 return 400;
 }

 getName() {
 return 'V8 engine';
 }
}
```

Then we pass this fake class to the setup.

```typescript
beforeEach(() => {
 TestBed.configureTestingModule({
 providers: [
 { provide: Engine, useClass: V8Engine },
 Car
 ]
 });
});
```

With this setup, the ```inject``` call will return an instance of ```V8Engine``` when asked for ```Engine```.
We can also use ```useFactory``` with a callback, or ```useValue``` with an instance, to accomplish the same result.
The only drawback here is that every method of the class must be implemented and changed
whenever the original class changes.
The original class can be extended optionally in order to override only specific methods.

<include src="asides/Angular" />

## Conclusion: What we've learned about Angular Testing

In this tutorial, we managed to:

- create a basic service and write tests for it
- use dependency injection in tests
- fake dependencies with Jasmine
- fake dependencies with dependency injection

If you follow the steps introduced in this article and write tests for your Angular application, you can sleep safe and sound.
The code will work as intended and when someone accidentally breaks it,
the tests will warn him that those changes are unsafe and shouldn't be committed until the tests are green again.

Jasmine will help you along the way with its easy syntax and batteries included (assertion and mocking library).

I hope this has convinced you that writing tests in Angular is not an overly complicated thing.

To make the start even easier, the code is available in
[this GitHub repository](https://github.com/blacksonic/angular-testing-ground "Angular testing ground").

Angular Testing In Depth: Services

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

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

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

All National Association of REALTORS affiliated listing services are now required to adopt the Open ID Connect standard

<div class="alert alert-info alert-icon">
 
 Forrester Research conducted a comprehensive analysis of our identity platform and determined that using Auth0 can yield a 548% ROI and $9.9M in savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.
</div>

---

At the Real Estate Standards Organization's annual conference in Austin last October, the issue of identity authentication had top billing. The big announcement? Widespread and wholesale encouragement to adopt the Open ID identity management standard across the industry.

Today, it's more than a recommendation. All National Association of REALTORS affiliated listing services **[are now required](http://www.reso.org/new-reso-web-api-standard-3-reasons-implement/)** to adopt the Open ID Connect standard. This is huge, because the seamless management of identity has historically been a big problem for the increasingly digital real estate industry. 

While agents have been able to use their personal Google or Facebook accounts to access and share information across different apps, vendor lock-in and proprietary software have made it impossible to do the same at work. Single SSO integrations have taken weeks to complete.

And there's been no shortage of reasons to open up the information flow. Between contact management systems, listings management systems, marketing programs, market analysis systems, and document storage, real estate agents consume a ton of data. All that data used to be siloed off in databases that were totally disconnected from one another—until now.

## What Is Open ID Connect?

Before the RESO adopted Open ID Connect, they were on the Real Estate Transaction System, or RETS. A sixteen-year old system based in XML, this antiquated standard was difficult to learn and use, it was slow, and it was once used by every single real estate website out there.

Open ID Connect is a authentication layer that sits on top of the widely used OAuth 2.0 authorization standard.

OAuth gives websites the power to delegate access to secure areas. It's like a key—if you have yours, you can log in to your account. 

Unfortunately, it doesn't offer any way to tie that key to your identity. That means if someone else gets your key, they can also log into your account. 

Individual service providers like Facebook have built their own extra authentication layers in years past, ensuring that when *your* key is used it's actually you on the other end. Open ID Connect extends the same logic across the web, providing the same kind of security that Facebook and Google have been using for years as an open standard that any organization can adopt.

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

## Implementing Open ID Connect With Auth0

The coup de grâce of Open ID Connect is [how easy](https://auth0.com/docs/oauth-web-protocol) it can be to implement into your application. Cal Heldenbrand shared his experience with the OpenID Foundation

> The certification process was pretty easy as well. I was expecting it to be more intensive! Our environment is Ruby on Rails, and I used [Nov’s openid_connec](https://github.com/nov/openid_connect)t Ruby gem for constructing ID Tokens. Other than that, my Provider is written from scratch. It took me about 2 weeks to have a very simple provider running for demo purposes. Then another 2 weeks to have it fully compliant with the certification tools. This is also along side my usual day job tasks of web operations. I’d have to say this was a breeze compared to the old OpenID 2.0.

Of course, it can always be a bit faster and easier. Auth0 supports Open ID Connect and a long list of [identity providers](https://auth0.com/docs/identityproviders) and [development stacks](https://auth0.com/docs). 

![Auth0 Identity Providers](https://images.ctfassets.net/23aumh6u8s0i/MZw4ZJty6uqbarp5Sawxu/8214ba813366952e9e10bf66ed159c52/identity-providers)

You're covered no matter your IdP. There's no need to spend a month writing your own provider and getting it compliant, either—Auth0 is as close to plug-and-play as it gets.

You can set up Open ID Connect in four basic steps: 

1. Set up a callback URL from your Auth0 dashboard
2. Integrate Auth0 Lock on your site or trigger login manually
3. Send the `code` your app receives to the Auth0 with a `POST`
4. Use a `GET` to retrieve the user profile from the server's response

Then, when users visit your website, this is what they'll see (you can customize the look of the box, of course!):

![Auth0 Lock Widget](https://images.ctfassets.net/23aumh6u8s0i/5UdQftKG0ytbhU93otU4S3/a672e7d099743d3035ce87451452eeda/auth0-lock)

For the full breakdown, check out the documentation on implementing Auth0 into your web app [here](https://auth0.com/docs/oauth-web-protocol).

### Building Your Own Identity Provider Hurts

Building your own identity provider could be a good summertime project—no one knows that better than us!—but that month spent wrangling with Open ID Connect starts to look very different when it's the only thing keeping you from launching.

It can easily become a frustrating way to spend your valuable time early on while you should be worrying about finishing your product and finding customers. It can also become a serious roadblock on your feature map, and that sucks.

Plus, even once you finish building it, you have to deal with the tweaks and changes that will become necessary every time a change is made to one of the platforms your users use to log-in. Building an identity provider is not a one-time investment.

With an identity “clearinghouse” like Auth0, all the work of maintaining and keeping your different connections current is taken care of. 

## Why Open ID Connect 

We've been working with OAuth since we first started building out the core functionality of Auth0. OAuth was always simple, widely used, and highly cross-compatible. But it was never enough to provide secure federated identity management, which is how we found Open ID Connect. 

But Open ID Connect isn't just secure. That's the baseline. The true magic of it is something you've already experienced if you've ever used your Facebook account to find your friends' playlists on Spotify—the seamless interchange of information between apps.

Imagine having your listing info, market analysis, customer data and documents all accessible to one another. No more signing in and out of different overlapping systems for different markets and dealing with incompatible systems. One login and one password—that's what Open ID Connect promises. 

Auth0 can handle all the different connections and layers of authentication, but it can also help use this data to supercharge your company's marketing and promotional efforts.

### Put Your User Data To Work And Drive Growth

Auth0 “rules” are Javascript snippets run by Auth0 and executed when users are authenticated in your app. These are what allow Auth0 to provide simple, actionable analytics for you to use to grow your business.

![Auth0 Rules Engine](https://images.ctfassets.net/23aumh6u8s0i/9NMB5Cr08Ue9dCbzeug3B/3c8dc313d9bab5547b4ceb489ecc6eb7/rules-engine)

Conventional analytics run client-side often fail, or even return misleading results—rules are far more reliable because they're run from the back-end. That means clean data you can immediately start using to execute on personalized marketing and retention tactics: 

1. **Enrich lead profiles:** Pull publicly available information on your new sign-ups and use it to build detailed customer personas.
2. **Notify your team of new leads:** Loop your authentication into an application like Slack to let everyone know when you have a new prospect.
3. **Craft highly personal marketing emails:** Send the right emails to the right users—you don't want to send a listing announcement to a user who's been inactive for a year.
4. **Analyze user registration info:** Graph your new sign-ups and separate them by source so you can understand what promo campaigns are working and which aren't.

Open ID Connect is changing the world of real estate technology by making it easier than ever to develop and use business applications, but it's not just good for convenience's sake. 

Because it provides a way to securely share authentication and verification across platforms, Open ID Connect is opening up to real estate companies the same opportunities that tech companies have had for years—opportunities to treat customers better, learn faster, and [grow at unprecedented rates](https://auth0.com/blog/7-ways-to-2x-your-revenue-growth-by-putting-your-user-data-to-work/).

How Real Estate Companies Can Implement Open ID Connect With Auth0

71313b369e8f23b7ec7b4614acdf3031?s=200 avatar

71313b369e8f23b7ec7b4614acdf3031?s=200

Staff Security Engineer

Radek Karpowicz

Automation which helps you monitor the multi-factor authentication status of various services.

Imagine a situation where your company hires more and more people and uses a lot of external services. The number of available assets you need to track is always growing. It's hard to keep up with all the services that employees at your company use on a day-to-day basis. Are you sure that you have appropriate security checks in place?

## Proactive protection

Monitoring your assets can be a manual or an automated job. If you implement the right solution, it could give you almost an instant notification when there's a problem. It's often a missing feature on the service provider side to notify you when someone disables MFA protection for one of your organization's accounts.

If you go the manual route, that just creates more routine work. More routine at work (and sometimes in life) doesn't lead to good things. Also, with shifting priorities everyday, it's easy to skip a manual process or even forget about them. Automation is a better solution.

By being more proactive and productive, we mean automation and an appropriate solution to the problem. At Auth0, we want to automate as many things as we can and decrease the number of alerts we receive to get only the real threats and not noise. It gives us the best overview of our infrastructure's security status.

## The MFA Monitoring tool

The [MFA monitor](https://github.com/radekk/webtask-mfa-monitor) uses an API to fetch information about the MFA status for every user under your organization, checks the previous state of MFA, and alerts you when that status changed (enabled or disabled state).

![Slack MFA alert](https://images.ctfassets.net/23aumh6u8s0i/5OJnSCaBGuhks7eZ8ue5RV/3e2fa24f916f501cdce48819cd42b7ff/slack)

Possibilities for implementing additional monitors or notifiers which will receive your alerts are endless as long as there's an API on the provider side. For now, we have implemented checks for GitHub and Amazon Web Services (AWS), we added Slack as a notification provider. If you use Hipchat or Twitter for notifications, you can quickly add them as an additional module. Feel free to send pull requests!

### Implementation

The MFA Monitor was implemented in JavaScript with Node.JS as a target platform. The toolkit consists of two main parts - notification and monitor modules.

#### Monitors

The monitor module was implemented to provide the possibility to inspect the status of MFA settings of different services. You can quickly add new controls as far as the service you want to monitor allows you to fetch MFA status over an API or another channel. What monitor module requires is to receive the status of protection from the external service.

As an example, the GitHub monitor was implemented using publicly available API to fetch information about users assigned to your organization. Requirements could be different for every service as GitHub requires an API token with access to the list of members of your organization. Always remember to choose privileges for access tokens wisely.

The important part of the monitor module is the callback that returns information about all user logins with MFA disabled:

```javascript
 client.orgs.getMembers({
 org: ctx.secrets.ORGANIZATION,
 per_page: 100,
 filter: '2fa_disabled'
 }, (err, res) => {
 if (err) return cb(err);
 if (!res) return cb(new Error('Empty response received from Github API!'));

 cb(null, res.map(data => data.login));
 });
```

#### Notifier

Notifiers are modules that were created to notify users about the security event that occurred on the 3rd party service - it could be information about enabled or disabled MFA on the particular account.

The first module we implemented was Slack, but it doesn't mean you can only use chat applications. It's able to send notifications directly to a URL, Twitter, or even TCP socket; it depends on what you need and want to implement.

To implement notifier modules and secure required tokens you can use secrets that could be stored by the [Webtask](https://webtask.io) platform. After that you can call them using ``ctx.secrets`` prefix.

```javascript
 const slack = require('slack-notify')(ctx.secrets.SLACK_WEBHOOK_URL);
 const mfaStatus = !!ctx.body.mfaStatus;
 slack.onError = (err) => cb(err);

 ctx.body.data.forEach(service => {
 let accounts = service.accounts.map(account => `*${account}*`).join(', ');
 let message = getMessage(service.name, accounts, mfaStatus);

 slack.send({
 channel: ctx.secrets.SLACK_CHANNEL_NAME,
 username: 'MFA Agent',
 text: message
 });
 });
```

#### Storage

An early version of this tool was using MongoDB as a storage. It generated many additional steps to setup this database. As for the latest release, it's using built-in storage into the Webtask service. In short it means that you don't need to use any external database and worry about the security of your data, now it's safe, encrypted, and stored locally.

```javascript
db.init(ctx.storage);
```

Using the [Webtask storage](https://webtask.io/docs/storage) is easy, to write or read data you need to call methods on the ``ctx.storage`` object. Below is the implementation of the storage wrapper which helps to handle storing and receiving data using Promises.

```javascript
'use strict';

const Promise = require('bluebird').Promise;
let db;

module.exports = {
 init: (storage) =>
 db = storage,

 getStoredData: () =>
 new Promise((resolve, reject) =>
 db.get((err, data) => {
 if (err) return reject(err);
 resolve(data || []);
 })
 ),

 storeData: (data) =>
 new Promise((resolve, reject) =>
 db.set(data, {force: 1}, err => {
 if (err) return reject(err);
 resolve();
 })
 )
};
```

You can easily implement additional storage modules if needed. We wanted to keep it as simple as possible, that's why we decided to use built-in storage which is also the best way to work with the Webtask platform.

### Installation

Setting up the MFA monitoring in place requires creating the Webtask account for free ([https://webtask.io](https://webtask.io)). It's a server-less environment, and it means that you don't need any additional infrastructure to monitor your assets. Fewer assets means less work for you.

![MFA monitor configuration process](https://images.ctfassets.net/23aumh6u8s0i/5a6kFSy2amtxyZ94pFc4cR/7067346475056cac6d9cb16c5eea2aad/mfa)

After creating the Webtask account you need to clone the MFA monitor repository from GitHub, install required npm packages (``npm install``) and you're ready to go. The configuration process is rather straightforward, and it asks you for all necessary data like GitHub token, Slack token, etc.

By default, it installs GitHub monitoring and sends alerts to Slack. In case if you want to modify it, you need to write additional monitors or notifiers. You can find more details on the official repository [README](https://github.com/radekk/webtask-mfa-monitor/blob/master/README.md) file.

### Usage

Once installed MFA monitor shouldn't require any maintenance steps. It's working as a Webtask cron job which means that it runs periodically to pull out the data from your services and checks the status of MFA setting.

You can periodically check the log stream to verify that MFA monitor is working or verify if the status is monitored.

## Awareness

Keep in mind that monitoring the MFA status will not protect you against other malicious activities that could occur. The purpose of this particular tool is to alert you every time your users forget to enable MFA.

<include src="TweetQuote" quoteText="The MFA monitoring tool will alert you every time your users forget to enable MFA."/>


This tool works well for us; it fits into our methodology of being a proactive team. Setup your monitors and start protecting your accounts now.

The MFA monitoring tool

d5365965372e0c5843d836f660b51a84?size=200 avatar

d5365965372e0c5843d836f660b51a84?size=200

Jeff Smith

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

Adding Authentication to Your React Native App Using JSON Web Tokens

d48b998c2dce49ca309710eba498c562

Nathan Totten

Access Azure Storage APIs securely from browsers (i.e. using JavaScript) or native apps, without the need of a backend server.

**TL;DR**: you can access Azure Storage APIs securely from browsers (i.e. using JavaScript) or native apps, without the need of a backend server. Live demo @ <http://auth0.github.io/auth0-azure-blob-sample/>

---

Today’s modern cloud provides developers with a rich choice of building blocks for creating new and innovative applications faster than ever before. Utilizing Auth0, developers can build applications that are secure and scalable without the need for a traditional backend server. This significantly reduces your time to release as well as the cost of maintenance over the life of your application.

In this post you will see an example of how you can use Auth0 and the near infinite scale of Azure Blob Storage to build a rich and secure client application without a traditional backend. This example is built entirely in HTML/JavaScript and runs in the browser while still providing secure, authenticated access to resources in Azure Blob Storage.



Below you will find a simple diagram showing how this application will work. Notice that the browser app only communicates either with Auth0 or with blob storage directly. We don’t need backend server helping with security – Auth0 does this for us.

<div style="text-align: center"><img src="https://images.ctfassets.net/23aumh6u8s0i/7pUss8YHMqziXbR1kGgmH2/b2477c7d30bfcf8bafdea0305fe37234/cpLqCchdjHP_"/></div>

## Logging In

Authenticating with Auth0 is a breeze. To log the user in we will use the Auth0 Lock widget. After the user clicks through to login the callback will be returned and we can take the token and profile data and store them in the browser's local storage. After the data is stored, we redirect the user to the files.html page.

```js

var lock = new Auth0Lock(window.config.clientId, window.config.domain);

document.getElementById('btn-login').addEventListener('click', function() {
 lock.show({ popup: true }, function(err, profile, token) {
 if (err) {
 // Error callback
 alert('There was an error');
 } else {
 // Success calback

 // Save the JWT token.
 store.set('azure_sample_id_token', token);

 // Save the profile
 store.set('azure_sample_profile', JSON.stringify(profile));

 location.href = 'files.html';
 }
 });
});
```

## Retrieving the Azure Storage SAS Token
Auth0 integrates with a variety of identity providers as well as a number of additional services we call addons. We support a variety of addons such as [Firebase](https://auth0.com/docs/server-apis/firebase), [Salesforce](https://auth0.com/docs/server-apis/salesforce), [Azure Service Bus](https://auth0.com/docs/server-apis/azure-sb), and [Azure Storage](https://auth0.com/docs/server-apis/azure-blob-storage). You can use these addons to exchange your traditional user tokens for API specific tokens – in our example, we will use our JWT token issued by Auth0 for a Azure Blob SAS token in order for the browser client to securely read and write to storage.

```js
auth0.getDelegationToken({
 id_token: current_id_token,
 scope: "openid",
 api_type: "azure_blob",
 containerName: id_hash + "my-container-name"
}, function(err, delegationResult) {
 callback(delegationResult.azure_blob_sas);
});
```

## Rules
In addition to simply exchanging tokens we can use a feature in Auth0 called [Rules](https://auth0.com/docs/rules) to fully control user access to containers and blobs. Rules are Javascript functions that run on Auth0 in response to various authentication events. You can use rules to completely customize how authentication works inside your application.

In our example, I am simply limiting each user to a single blob that they own, but you could image that we could build a rich role-based access list for users to provide fine-grained control over storage resources. You can see the code for our rule below. Notice how we are using the Azure Storage SDK inside of the rule to check if containers exist and create new containers.

```js
function(user, context, callback) {

 var CLIENT_ID = "your_client_id_here";

 // Only run this rule for the correct app and for azure_blob delegations
 if (!(context.clientID === CLIENT_ID &&
 context.isDelegation &&
 context.request.body.api_type === 'azure_blob')) {
 return callback(null, user, context);
 }

 var blobName = context.request.body.blobName;
 var containerName = context.request.body.containerName;

 // Get user id hash
 var shasum = crypto.createHash('sha1');
 shasum.update(user.user_id);
 var hash = shasum.digest('hex');

 // Check to make sure the container belongs to the user
 if (containerName !== hash) {
 return callback(new UnauthorizedError('Not authorized.'));
 }

 // For blob requests, we are done
 if (blobName) {
 return callback(null, user, context);
 }

 var blobService = azure_storage.createBlobService(
 configuration.AZURE_STORAGE_ACCOUNT_NAME,
 configuration.AZURE_STORAGE_ACCOUNT_KEY);

 // For container list operations, ensure the container exists
 blobService.createContainerIfNotExists(containerName,
 function(error, result, response) {
 if (error) {
 return callback(error);
 }
 return callback(null, user, context);
 }); 
}
```

## List Blobs in Container
Once we have our container’s SAS token, our browser app can make a request directly to Azure Blob storage to list the contents of the blob.

```js
var url = 'https://blobshare.blob.core.windows.net/' + containerName +
 '?' + sasToken + '&restype=container&comp=list';
$.ajax({
 url: url,
 type: "GET",
 success: function(data, status) {
 var model = convertResponseToModel(data);
 callback(null, model);
 },
 error: function(xhr, desc, err) {
 callback(err);
 }
});
```


## Upload a Blob
Because we want to be able to handle large files we are going to upload our file as a block blob. This allows the browser to make multiple requests to upload small chunks of a large file. This way, if one request fails we simply have to retry a small request rather than retry the entire upload. This means our browser app can handle uploads of very large sizes efficiently.

Once again, we will call our Auth0 delegation endpoint to exchange our auth token for an azure blob sas token. This token will be for a particular blob rather than a container. Because the code for uploading a blob in blocks is quite long I won’t put a snippet here. You can find a great reference on how to do that on [Gaurav Mantri’s blog](http://gauravmantri.com/2013/02/16/uploading-large-files-in-windows-azure-blob-storage-using-shared-access-signature-html-and-javascript/).

## Resources
Now that we have walked through the steps of building a secure client-only application with Azure Storage and Auth0 you can try out the [running application](http://auth0.github.io/auth0-azure-blob-sample/) yourself. Additionally, you can find the [full source](https://github.com/auth0/auth0-azure-blob-sample) on Github and [additional documentation](https://auth0.com/docs/server-apis/azure-blob-storage) about using Auth0 and Blob storage.

<div class="try-banner try-code" style="margin: 0">
 <a href="https://github.com/auth0/auth0-azure-blob-sample" target="_new" class="btn btn-default btn-lg">Code</a>
 <a href="http://auth0.github.io/auth0-azure-blob-sample/" target="_new" class="btn btn-default btn-lg">Demo</a>
</div>

## Summary
I hope this post gave you an understanding of some of the awesome things you can do with Auth0 and the modern cloud. Be sure to sign up for your [free developer account](https://auth0.com/pricing) and check out our [quick start guides](https://auth0.com/docs). If you have any questions you can reach our entire team on [chat.auth0.com](http://chat.auth0.com/) or [@Auth0](http://twitter.com/auth0).

Using Azure Services without a Backend

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

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

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



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

Auth0 addresses these two issues:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

"services"