peterfernandez_360

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

Principal Developer Advocate

Peter Fernandez

Why a Multi-Tenant approach is fundamental to B2B SaaS, and how using Auth0 and the Auth0 Organizations feature can help implement it.

Demystifying Multi-Tenancy in a B2B SaaS Application

matt-raible

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

Developer Advocate

Matt Raible

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

Java Microservices with Spring Boot and Spring Cloud

jimena-garbarino

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

Spring Cloud Developer

Jimena Garbarino

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

Identity in Spring Boot with Kubernetes, Keycloak, and Auth0

pawan bhardwaj

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

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

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

Principal Product Manager

Pawan Bhardwaj

jc tierney

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

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

Director, Engineering

JC Tierney

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

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

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

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

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

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

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

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

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

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

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

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

## Why Converged Architecture?

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

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

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

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

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

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

## Deployment Characteristics of Multi-Subscriber Services 

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

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

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

## Public Cloud Platform Infrastructure Architecture

### Tiers - Central, PoPs, and Spaces

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

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

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

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

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

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

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

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

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

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

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

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

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

### Reliability

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

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

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

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

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

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

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

## What Next?

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


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

Multi-Subscriber (Public Cloud) Deployment on Converged Architecture

david-telehowski

David Telehowski is Director of Security Engineering at Auth0 and his team is responsible for securing the Auth0 Identity Platform. He has over 20 years of experience designing and building innovative cybersecurity products and services. Prior to joining Auth0 David led global engineering teams at SonicWall and Dell, and he has been awarded several patents in the areas of remote access and network security. David holds bachelor's and master's degrees in computer engineering from the University of Michigan.

Director, Security Engineering

David Telehowski

How we expanded customer choice while building a security-first architecture.

Choice is good. We like it when our supermarket shelves are stocked with hundreds of varieties of breakfast cereal. We pick the smartphones we use and the cars we drive. The same should be true for businesses and the technologies they use.

Today, we brought the Auth0 Identity Platform to Microsoft Azure, giving our private cloud customers the ability to pick the right infrastructure provider for their needs.

This means a greater selection of regions. Microsoft currently operates in over 60 regions around the world, making it easier to comply with data residency and sovereignty requirements.

And if you’re already running your app on Azure’s cloud servers, you’ll benefit from a converged infrastructure, with every component running on the same underlying cloud platform.

![Azure](https://images.ctfassets.net/23aumh6u8s0i/3LjSNS6Motv1nFGNKkIQn/3f9353b41dd9653536e2e9b9f664689a/72798-Auth0_AzureMap-D2-02-01.jpg)

## Shifting Security Left on Microsoft Azure

We’re equally excited to tell you about the development process. Auth0 has always prioritized security. Last year, we took this a step further with the adoption of “Shift-Left” principles. This puts security-related tasks at the start of the Software Development Life Cycle (SDLC), making it easier to build a stronger, more resilient product.

We remained true to these principles when building the Auth0 Identity Platform for Microsoft Azure, and are thrilled with the end result. The final product is one that reflects our **Secure by Design** philosophy and faithfully adheres to industry best practices.

Let’s talk about what “Shift-Left” means. This is an established term in the software development sphere, and refers to a variety of domains, both security-related and otherwise. In short, you take something that would typically happen at the end of the development lifecycle and tackle it at the beginning. Test-driven development (TDD) is a notable example.

As Auth0’s CISO Jameeka Aaron said: “Nobody wants their CISO to show up at the last minute with 800 vulnerabilities to be fixed before release.” Our security engineering team looks for vulnerabilities during the design and development phases, and remediates issues early on to prevent a last-minute crunch, or worse, having to rework the design.

At Auth0, our Shift-Left process tackles both the human and technical elements of secure software development. All code must meet strict security requirements and is constantly tested against sophisticated static analysis benchmarks.

We also provide all developers with secure coding training, with some designated as “security champions.” These employees act as liaisons between the engineering and our dedicated platform security teams. They also receive additional training to act as security advocates within their teams.

## Security First Architecture

As we developed the Auth0 Identity Platform for Microsoft Azure, we emphasized “shift-left” principles and focused on building a strong security architecture at the start of the development cycle.

We established a dedicated Azure AD tenant and automated governance controls to support resource and identity isolation, required MFA and Azure PIM for privileged access, and enforced security standards with Azure Policy. Prioritizing security in the early stages of the development process is part of our Secure by Design strategy to mitigate risk and keep customers safe from cyberthreats.

The Security Engineering team is also responsible for Azure customer account provisioning and management. In Azure, these are called subscriptions. These are used to isolate private cloud environments and all the associated provisioned resources, like VMs, data storage, and more.

We built a new service for managing Azure subscriptions, and it is integrated directly into our platform infrastructure workflows. This helped to automate how we manage our Azure Private Cloud environments and dramatically improved environment creation time. This was another part of our Azure governance to keep customer environments isolated and secure.

## Cloudflare on the Edge

To help protect against network-based attacks, the Auth0 Identity Platform uses Cloudflare — a popular reverse proxy and content delivery network (CDN) product.

Cloudflare acts as a gateway between the application and the outside world. The service proactively analyzes all inbound traffic, and blocks things that could harm the smooth functioning of the Azure instance, including malicious bots and DDoS attacks. Further protection comes from its customizable rate limiting and firewall rules.

This means a better, more reliable service for your users. It also comes with some significant performance advantages, too. With Cloudflare's CDN, static assets (like images and scripts) are hosted close to the user, thereby reducing load times. Traffic is routed through Cloudflare's Anycast network, which consists of over 250 locations in 100 countries, and provides greater resiliency and latencies below 50ms.

## Detection & Response

In the hands of an IT engineer, security professional, or developer, logs are a powerful tool. They're the first place you look when remediating a fiendishly tricky problem, or trying to identify an attempted intrusion.

When building the Auth0 Identity Platform for Microsoft Azure, we wanted to make it easy to audit and monitor. Logging is enabled by default on all Azure instances, as well as with the back-end databases. By default, we retain logs for 13 months.

Each Azure environment is covered by Auth0's host monitoring agents. This monitors the security, performance, configuration and state of each host. We also enabled Azure Security Center & Defender by default, further bolstering our security monitoring capabilities.

## Disaster Recovery

Identity is fundamental to business. Your CIAM system is the gateway between your application and its users. You can’t afford significant downtime. With this in mind, we spent a lot of time thinking about resilience when designing the Auth0 Identity Platform for Microsoft Azure.

All services are provisioned across three Availability Zones (AZ). In the case of an AZ failure, service are designed to automatically resume in one of the other healthy AZs. Backups are captured every six hours and securely retained in the same region as the deployment, and we can restore an instance from the last snapshot in four hours.

## Azure’s Solid Foundations

Let’s wrap up by talking about Microsoft Azure itself. After all, what’s the point in building a secure platform if the underlying infrastructure isn’t up to standard?

Fortunately, there’s no such concerns here. We have come to appreciate the security features and tools within the underlying Azure platform and ecosystem. Microsoft also has the right mindset. The Azure access control best practices urge users to regard identity as the primary security perimeter. This reflects the changes in enterprise IT, particularly the rise of BYOD and cloud computing, which make it harder to build watertight network defenses.

Identity is the best way to protect your most important data. Well-defined permissions can limit the impact of a security breach, while using MFA and SSO can help prevent an account being compromised in the first place. To find out how the Auth0 Identity Platform on Microsoft Azure can benefit your organization, [click here](https://auth0.com/contact-us).

Why Auth0 “Shifted Left” with Azure

akhil-chawla

I am an enthusiastic software professional with 6+ years of experience in translating business requirements into innovative technological solutions. Have extensive experience as a full-stack developer in building end-to-end scalable applications using Java, Spring Boot/ Spring Cloud, CI/CD, Azure, AWS, Docker, Kubernetes, Jenkins, and others. I am always interested in learning algorithms, data structures, architecture design, and other new technical skills. Adding to my engineering background, I have recently completed my Executive MBA from MDI Gurgaon to enhance my managerial and team-leading skills. I am currently working with Optum (a UnitedHealth Group Company), Gurgaon.

Software Engineer

Akhil Chawla

Learn what are the different deployment strategies available in Kubernetes and how to use them.

Deployment Strategies In Kubernetes

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

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

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Auth0 Assemble is Auth0's first annual Identity Conference for Application Builders.



<div class="alert alert-success alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>An Important Message from Auth0</strong><br>
  <p>The health and well being of the application builder community &mdash; and all humans &mdash; is the most important thing to Auth0. Due to the COVID-19 pandemic, we don’t feel we can offer the high-level experience you deserve. Therefore, we have made the <strong>difficult decision to cancel Auth0 Assemble 2020</strong>.</p>
</div>

We're excited to announce that we're hosting our very first conference: **Auth0® Assemble &mdash; The Identity Conference for Application Builders™**! The conference will be held on August 26-27, 2020, in San Francisco, CA.

## What is Auth0 Assemble?

[Auth0 Assemble](https://assemble.auth0.com/?utm_source=ASM_Blog&utm_medium=sc&utm_campaign=ASM_WebTraffic), Auth0's annual developer and customer conference, is the only identity conference for application builders. For those who are architecting the future. The ones who understand that applications are built today by assembling the best of breed APIs and tools. Those who care about the intersection between end-user experience, privacy, and security.

During this two day conference you will hear about:

**The future of application building**

Thirty years ago, the focus was on  databases; fifteen years ago, the cloud; ten years ago, infrastructure services for developers. Today, the focus is on serverless and no-code. It's an exciting time to be a developer with so many building blocks and tools available to free up resources to focus on what matters: **building what differentiates your business**. This future is being built by developers, product managers, architects, designers, security, and ops teams. Learn about the latest trends in application development and what it means to *assemble* applications.
 
**Identity: convenience, security, and privacy**

A powerful identity infrastructure is an enabler of business. If users can access applications without friction, the result is more active users. If care is shown about user security, they will entrust more of their business. If priority is placed around user privacy, they will become more loyal. The challenge faced by application builders today is how to balance user experience with privacy and security. Join industry experts as they share their journeys, strategies, and best practices based on real-world experience.

## Who is Auth0 Assemble for?

The *builders* of an application include more than just the software developers. So what makes someone an application builder? Simply put, an application builder is someone who takes part in the application development process. This includes product managers, software architects, security professionals, developers, and more.

The keynotes and sessions at Auth0 Assemble will cater to **all application builders**.

## Why Should You Attend?

### Architect the future

Auth0 Assemble will explore a future where applications are assembled, not built. We have created a select lineup of developers, visionaries, and practitioners who are as passionate as you about building secure, scalable applications.

### Build the community

One of the best parts about attending a conference is the ability to branch out and meet other professionals in the industry. Auth0 Assemble will bring together over 500 like-minded application builders for two days of education and networking.

### Celebrate dev culture

One of our guiding principles has always been our "developer-first" approach, so at Auth0 Assemble, we want to celebrate *you*! We'll be hosting a Celebration Night, creating interactive experiences to highlight your time at Auth0 Assemble, providing opportunities to win Auth0 merchandise, and much more.

### Develop your Auth0 skills 

Curious about what's next for Auth0? We'll be sharing an insider sneak peek at our 2020 roadmap, so you'll be among the first to see our new product features. Our 1:1 expert meetings can get your team up to speed with Auth0 features, special use cases, and deep-dive product sessions.

## Event Information

### When and where

Auth0 Assemble will be held on August 26-27, 2020, at the [Hyatt Regency](https://www.hyatt.com/en-US/hotel/california/hyatt-regency-san-francisco/sfors) in San Francisco, CA.

### How to get tickets

You can purchase your tickets now at [https://assemble.auth0.com](https://assemble.auth0.com/page/1492043/get-your-ticket)! To lock in the **Early Adopter** rate of $895, make sure you book your ticket by **April 1, 2020**. The conference is expected to sell out, so purchase now if you'd like to attend! You can also sign up to receive Auth0 Assemble conference email updates at [https://assemble.auth0.com](https://assemble.auth0.com/?utm_source=ASM_Blog&utm_medium=sc&utm_campaign=ASM_WebTraffic).

More information and updates can be found on our [brand new conference website](https://assemble.auth0.com/?utm_source=ASM_Blog&utm_medium=sc&utm_campaign=ASM_WebTraffic) or by [following us on Twitter](https://twitter.com/Auth0Assemble). We look forward to seeing you there!

<include src="asides/AboutAuth0" />


Introducing Our First Conference: Auth0 Assemble

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

Experimental modeling tool answers unmet need for holistic view of identity management design



**BELLEVUE, Wash. – December 9, 2019 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today unveiled [Auth0 Explorer](https://auth0.com/blog/charting-new-territory-with-auth0-explorer/), an experimental research tool for application developers to map, visualize, and navigate the design of identity authentication architecture, a crucial element in the creation of secure applications. Vittorio Bertocci, principal architect, will showcase Auth0 Explorer publicly at Gartner Identity & Access Management Summit, December 10-12, 2019. It can also be accessed at [https://explorer.auth0.com](https://explorer.auth0.com). 

Auth0 Explorer is born from the company’s ongoing and never-ending quest to make the very complex world of identity simple(r) for application builders. Knowing how many components are involved when building identity, Bertocci and team wanted to research and roll out an experimental tool that would help customers visualize their Auth0 tenant’s overall structure through an innovative user interface, providing them with a holistic live overview that most customers had previously drawn out on a whiteboard. Laid out very clearly, Auth0 Explorer arranges all major artifacts (connections, apps, APIs) representing relationships as a graph and allows customers to delve into every detail, path, and custom logic required for each specific architecture. 

Here’s how it works: Auth0 customers can log in to their Auth0 account at the [Auth0 Explorer landing page](https://explorer.auth0.com/), where they can select settings that allow them to customize their unique identity management architecture, with every possible component as an option. The experimental tool even has a “traffic layer” feature, which enables customers to connect an app to an identity provider and visually show (by line thickness) the volume of traffic that particular IdP generates for the application, as recorded in Auth0 logs. 

“Seeing the big picture of an identity management solution can be very difficult when you are a developer that is mired in the nitty-gritty details of building a complex identity architecture,” said Bertocci. “After consistently hearing from developers that drawing a picture is standard protocol in the planning process, we wanted to ease the developer burden by providing a much more seamless and customizable approach to navigating and planning an identity solution. The early feedback we have received from customers has been very positive, and we look forward to continuing to improve upon Auth0 Explorer to provide even more value to the application builders using it.”

Auth0 Explorer is an experiment – not a formal product offering – and is available now and accessible for customers and in demo mode at [https://explorer.auth0.com](https://explorer.auth0.com). Bertocci will be demoing Auth0 Explorer on Tuesday, Dec. 10 at 1:50 PM at the [Gartner IAM Summit](https://info.auth0.com/gartneriam2019.html). For show attendees who want to learn more about Auth0, please visit booth #517.

<include src="asides/AboutAuth0" />

### Media Contacts

Kaycie East<br>
Auth0 Communications<br>
[press@auth0.com](mailto:press@auth0.com)
 
Alexandria Plew <br>
Matter for Auth0<br>
[auth0@matternow.com](mailto:auth0@matternow.com)


Auth0 Explorer Gives Developers Greater Control, Deeper Insight into Authentication Architecture

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

Cut through the complexities of identity with custom-branded end-user flows.



**TL:DR:** In this article, we'll walk you through setting up an Auth0 Flow so you and your end users can easily see the Auth0's impact. (Typical set up time: < 5 mins)

Are you looking to kick the proverbial Auth0 tires? Do you want to quickly understand our solution before taking the [_IDaaS_](https://auth0.com/blog/identity-as-a-service-in-2018/) plunge? Maybe you need your boss and/or colleagues to use Auth0 in your next project and want an easy way to present our features. Or perhaps you want to explain identity to your customer or client. Whatever the reason might be, [_Auth0 Flows_](https://flows.auth0.com/) is a great tool to help cut through the complexities of identity with branded visualizations of the end-users' journey.


<include src="QuoteCard" picture="https://cdn.auth0.com/blog/auziros/kris-babbish.jpg" name="Jeffrey Bruns" title="Director of Product Engineering" company="The Chronicle of Higher Education" body="The Auth0 flows tool helped our UX and design folks gain an understanding of how best to implement the login and sign up experience during our design phase. The biggest challenge with any new project is overcoming the ‘you don't know what you don't know’ challenge. Being able to visualize an end-to-end workflow and present something for business stakeholders to preview has been very helpful in overcoming the knowledge gap make the right decisions around our login and registration flows."/>

![Auth0 Flows presentation by Vittorio Bertocci](https://images.ctfassets.net/23aumh6u8s0i/31SdN18jHX3CLfYyWMp8en/f6c58944ccd906c17a16dd3969d53df0/auth0-flows-presentation-by-vittorio-bertocci)

[_*Vittorio Bertocci*_](https://auth0.com/blog/authors/vittorio-bertocci/)_ using Auth0 Flows in a presentation at Identiverse_

## Getting Started

1. Navigate to [_flows.auth0.com_](https://flows.auth0.com/).

2. Run through the quick guide and then enter your organization's name to customize the login experience.

3. If your company is already populated, select it from the drop-down list. Otherwise, select “Add [Your Org's Name]” at the bottom of the list. Confirm your organization's name, enter the URL to your company's logo, and provide a primary color in hexadecimal value. Finally, select “EXPLORE FLOWS.”

![Selecting your organization in Auth0 Flows](https://images.ctfassets.net/23aumh6u8s0i/4vAjGAVBnhet0aMDThurVw/42dafd928d52f95e98609130dd9c8597/selecting-your-organization-in-auth0-flows)

_Select your organization_

![Creating a custom-brand organization in Auth0 Flows](https://images.ctfassets.net/23aumh6u8s0i/5UuEkWIoJ4gCifoChqSkF0/b9994f696e2274837345b032b680df09/creating-a-custom-brand-organization-in-auth0-flows)

_Custom-brand your organization_

## Auth0 Flows Interface

The Explore page is organized into two panes. In the left pane, you'll find a list of features organized by the authentication type. Simply, click on each feature to see the branded end-user experience in the right pane. You can pan in any direction and zoom in/out to adjust the view to your liking. You'll find a set of controls to further help you adjust the view on the bottom-right side of your screen. You can also switch from the "Flows" view, which shows the entire path of the feature, to a "Screens" view, which zooms into a particular screen. Select the left and right arrows in the control box to navigate through the various screens.

![Auth0 Flows UI](https://images.ctfassets.net/23aumh6u8s0i/5r534fHBK4gH7e9S3gvM2p/eb6ade1e6b1a170503b67302610a318b/auth0-flows-ui)

_Auth0 Flows UI_

## Share Your Custom Flows

It's simple to share your custom-branded flows with colleagues and managers. Select "SHARE" from the top-right of your screen to display a public-facing URL. **Hint:** You can also copy/paste the URL from your browser's navigation bar.

<include src="TweetQuote" quoteText="Use Auth0 Flows to visualize what the authentication workflow looks like for your business from end to end."/>

<include src="asides/AboutAuth0" />


Visualize the Power of Auth0 in Minutes

andrea-chiarelli

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

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

Andrea Chiarelli

Learn how to build client-server systems by applying the REST architecture principles.

REST Architecture - Part 2: Building the Client

REST Architecture - Part 1: Building The API

Vittorio

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

Principal Architect

Vittorio Bertocci

4 hours of video classes on identity, architecture, and standards.


**TL;DR**: Every new technical hire at Auth0 goes through two days of technical onboarding. Today we are making the lecture portion of that training available to everyone, for free.

<include src="TweetQuote" quoteText="Take a guided deep dive into the complexity of identity with Auth0 Principal Architect @vibronet. 4 hours of our technical onboarding lectures — for free!"/>

## Understanding Identity: The Journey of New Auziros

Identity is complex. When you identify the job to be done, the particular task you want to accomplish, providers such as Auth0 can make it possible for you to add authentication and other identity-related functionality at the flip of a switch: you no longer experience the complexity, but the complexity never disappears. It has now transferred to the provider, who must thoroughly analyze the task you want to accomplish and make sound decisions about what's the most appropriate protocol flow to use, what reasonable defaults should be selected, what values should be hidden from view and what controls should be surfaced as configurable, what security measures are warranted... and many, many other design, planning and implementation aspects. Our customers don't need to sweat the details, but we do... and as a general rule, [the easier the experience you enjoy](https://auth0.com/blog/the-developer-first-identity-platform-auth0-story-and-future/), the more work has been poured into it behind the scenes.

One inescapable implication of the aforementioned situation is that the Auth0 personnel must have identity competence (what I often call the "identity IQ") that goes wide and deep: on fundamentals, traditional aspects (to know how to integrate with existing systems) and modern approaches. That's a kind of competence that isn't common on the market, especially if you compound it with the robust orientation toward developers of our offering and culture.

And yet, grow we must... Auth0 has been growing at a significant pace, [continuing to double in growth and revenue year-over-year](https://auth0.com/blog/auth0-closes-103m-in-funding-passes-1b-valuation/), and to sustain that growth we need to acquire talent that, while meeting our high bar (did I mention we are hiring? Take a look [here](https://auth0.com/careers)), doesn't always bring as dowry the deep identity IQ we need to develop and operate our service. Faced with this conundrum, we didn't have much choice but to devise ways to teach identity to our new hires.

## Why We Are Making Our Technical Onboarding Available

If you've been working in this space for a while, you know that this can be real tricky. Identity IQ isn't just learning by rote the name of the protocol artifacts and what knobs to turn in dashboards and SDKs to achieve a certain effect. True competence is mostly demonstrated when making decisions. Every day, Auth0 employees must make sound decisions on how to model specific scenarios, how to represent real world entities in the protocol artifacts with the most fitting characteristics, what attack surface will come with a particular architecture, and so on. Those decisions must withstand the test of time, must gel with prior art, must gracefully scale when necessary, and all the other good properties one expects from solid engineering practices. 

With all of that in mind, we examined the available literature on identity and development. **Although there is a lot of good content out there, most of it was either too protocol centric** (describing the protocol as a thing in itself, rather than a tool for solving real life problems), too scenario specific (not explicitly connecting the dots between development practices and protocol choices) or quite outdated. Given the strategic importance of keeping our identity IQ high, we decided to bite the bullet and... develop the content ourselves.

Every new Auziro (our nickname for Auth0 employees) begins his or her journey with few days of in-person training in our Bellevue headquarters. We started running classes once a month, experimenting with different formats and content &mdash; and eventually converged in the current course: a two days full-immersion class of heavily interactive lectures, punctuated by hands on labs designed to give attendees first hand experience of the theory learned up to that point.

![A photo of the Auth0 Technical Employee Onboarding ran by Vittorio Berttoci](https://images.ctfassets.net/23aumh6u8s0i/7AX2WwJamW3XgdceZ6rXAB/cd8830b5d3475a209c9f6c9d1040f966/technical-onboarding-auth0-vittorio-bertocci-2)

The feedback has been consistently positive, and the course proved to be very effective in equipping people not just with essential knowledge, but with the right command of the terminology and fundamentals necessary to understand the literature out there and contextualize new knowledge. This is now established practice and a staple of starting one's journey with Auth0. And for the cases where logistic doesn't work and a trip to Bellevue isn't feasible, we pre-recorded all lectures in professional videos for a self paced experience. Hold this thought, as I will come back to it shortly.

After few months of successes, someone had the idea to experimenting with delivering the class to customers and partners. I have to admit that at first I was skeptical &mdash; isn't Auth0 job to take on the burden of complexity, why should I bother the customer with the reasons behind the use of Nonce or why PKCE is necessary when using the system browser? Would they even care?

As it turns out, I was dead wrong &mdash; they cared A LOT. We delivered classes in London and Bellevue, Copenhagen and Oslo. In all cases, we filled the room with CTOs, architects, star developers and in general people whose responsibilities include making medium and long term strategy decisions for their company. They all gave glowing feedback, with some of them admitting that the class finally helped them to fully understand some aspects of the protocols and practices that they never managed to crack before. Some other shared that they've been looking for similar content for a long time, but they weren't able to get quite what they needed- until now.

"Some of the information I received today contradicts with our assumptions within the team about OAuth standards. Most of the information received will help me and the team make better decisions about auth flows." &ndash; Architecture Lead, Global Travel Aggregator

"Very useful. I work with a lot of businesses where identity is always a key part and not only has it given me more confidence and knowledge of Auth0 but in identity as a topic as well." &ndash; Partner, Cloud Architecture consultancy

"We had a great discussion. It's not every day that I get to talk so geekily in-depth with an acknowledged thought-leader in identity." &ndash; Distinguished Architect, B2B software multinational

Which brings us to today. Given the positive feedback we received, we decided to open up access to our classes to anyone. If you navigate to [https://auth0.com/docs/videos/learn-identity/](https://auth0.com/docs/videos/learn-identity/), you'll find the complete collection of identity lectures we recorded for our technical onboarding &mdash; available to you **for free**.

## The Identity Course

The lectures you find at <https://auth0.com/docs/videos/learn-identity/> are meant to help the viewer gain deep understanding of OAuth2 and OpenID Connect, down to the use specific parameters in particular messages of a given grant. Unlike a lot of the protocol content you might have consumed in the past, however, the course refers to scenarios and problems to be solved as highest order bit. Instead of hitting you with the laundry list of all the artifacts described in the specifications, the course introduces the concepts required to solve a specific problem only when the scenario requires it. This helps with understanding the whys behind each choice, and positions each artifact in the right context &mdash; providing obvious explanations for otherwise baffling things that neophytes are usually forced to swallow as articles of faith, such as why one goes to authenticate to the authorization endpoint, or why a web site is called a client even when it's clearly the resource we are gating access to.

The other side of the coin is that every explanation builds on the concepts already covered, hence to get the most from the class the content should be consumed sequentially and without skipping any part.

![An image of Auth0 Docs Learn Identity homepage](https://images.ctfassets.net/23aumh6u8s0i/PdtPHtKHxiudV6PLeXyic/e40723969ec9b0bd62d1ab0a8cfb4a61/learn-identity-homepage)

The content is really designed to be interactive, for classes under 20 people &mdash; where it's not uncommon to have 15 mins detours to dig in some specific scenario that happens to be of interest for a particular cohort; that is also the reason for which the slides supporting the narration are all designed to be rearranged on the fly, by dragging clipart around and scribbling on screen whatever impromptu explanation the discussion requires.

We clearly cannot offer the same dynamic in pre-recorded videos; however we compensate for that by providing very granular bookmarks. Each concept and subtopic has been indexed and surfaced in form of link below the video, allowing you to form an idea at a glance of the specific points being discussed, and to jump directly to the right time in the narration. We observed this to be particularly useful when reviewing the material and looking for a quick refresher. In fact, we made sure to make every bookmark available as an absolute URL &mdash; we envision using those as references during discussions, posts on forums, tweets and any context requiring a bite size explanation of specific identity concepts.

![An image of a Learn identity video's table of contents](https://images.ctfassets.net/23aumh6u8s0i/WyeKuRsWLvONjIXkk0YCm/c884377cb1ad30d17c7c179a91ee33b6/auth0-learn-identity-video-and-bookmarks)

As of today, we cover the following topics:

-   [An intro to the history of protocols &mdash; how the modern protocols came to be, what problems they were meant to originally solve, and how they emerged in response of the main challenges of each era](https://auth0.com/docs/videos/learn-identity/01-introduction-to-identity)

-   [A 20,000 ft meta-view of OAuth2 and OpenID Connect](https://auth0.com/docs/videos/learn-identity/02-oidc-and-oauth)

-   [Using OpenID Connect for implementing web sign on in a traditional web app](https://auth0.com/docs/videos/learn-identity/03-web-sign-in)

-   [Using OAuth2 for gaining delegated access to an API from a traditional web app](https://auth0.com/docs/videos/learn-identity/04-calling-an-api)

-   [Using OAuth2 and OpenID Connect to invoke API from native clients (mobile, desktop, etc)](https://auth0.com/docs/videos/learn-identity/05-desktop-and-mobile-apps)

-   [Using OAuth2 and OpenID Connect to invoke API from SPAs (including a discussion of the implicit vs code+PKCE)](https://auth0.com/docs/videos/learn-identity/06-single-page-apps)

The discussion starts extremely high level, but quickly dives deep - grants are picked for their ability to solve an abstract scenario, but are examined down to the network traces level. No concept is ever presented in isolation, but always annotated with the whys behind it and the implications of choosing one approach vs another. The highest order bit remains equipping the viewer to make good decisions.

<include src="TweetQuote" quoteText="Free access to Auth0 technical onboarding lectures with Principal Architect @vibronet!"/>


## What's Next

Where to go from here? 

The next step is to upload the hands on labs, so that you can taste the complete onboarding experience. We don't have an ETA to offer at this point, but it's something we'd like to do very soon.

Another likely evolution is that we might publish the course on its own web site. Today it's embedded in our documentation, a solution that allowed us to make the videos available to you quickly, however depending on your feedback we might repackage them (or updated versions) in their own space. Leave your feedback in the comments!

Finally. The fact that we published the video doesn't mean that we will not do more in-person workshops. There is a lot of value in discussing those topics in person and dig in specific areas as needed by each specific group of participants, so we'll still occasionally do pop up in-person classes around the world. If you are interested in one of those events, let us know by reaching out to an [Auth0 Resource](mailto: sales@auth0.com).

In the meanwhile, please enjoy the videos. We hope they'll help you to catch the identity bug and get passionate about identity as much as we all are here at Auth0!

[Learn Identity](https://auth0.com/docs/videos/learn-identity/)


Introducing Learn Identity!

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

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 build a mature service architecture for high availability by creating its topology progressively.

Progressive Service Architecture At Auth0

Jose-Romaniello

I started working at Auth0 before the first line of code for our authentication platform existed. I’ve been able to go through the journey of seeing our ideas go from prototype to living production code that impacts millions of people. It’s satisfying to know that my actions here are having a positive impact in solving problems for developers like me.

Head of Engineering

Jose Romaniello

Learn how to apply the Scout code to software development to get code to a better state continuously.



When I was a kid, I practiced [_Scouting_](https://en.wikipedia.org/wiki/Scouting) for eight years I picked up a lot of excellent values and my scouting experiences helped to shape my character and make me a better programmer. Let me show you why.

As a Scout, you get to experience nature by camping outdoors which teaches you one of the core values — **respect life**. Scout rules help support core Scout values. One of the first rules I learned was:

> Always leave the campground cleaner than you found it.

This rule comes from a quote by [_Robert Baden-Powell_](https://en.wikipedia.org/wiki/Robert_Baden-Powell,_1st_Baron_Baden-Powell), founder and first [_Chief Scout_](<https://en.wikipedia.org/wiki/Chief_Scout_(The_Scout_Association)>) of [_The Scouts Association_](https://en.wikipedia.org/wiki/The_Scout_Association), and founder of the [_Girl Guides_](https://en.wikipedia.org/wiki/Girlguiding):

> Leave this world a little better than you found it.

What this rule represents is that you should not only pick up your trash, clean the area where you started a wood fire and the soil where you built your tent, but also you need to take a look at the campsite and do something to leave it better than it was before.

It is an explicit instruction. It helps you accept the notion that something can always be better. There’s always room for improvement. You had the opportunity to enjoy the area and its resources but you also have the opportunity to pay back by leaving the area in better shape for others.

I believe that when kids are taught this kind of values through games, repetition, and rewards, it becomes a habit. This is nominally known as [_positive reinforcement_](https://en.wikipedia.org/wiki/Reinforcement#Positive_reinforcement). Positive reinforcement takes place when a reward is presented as the result of certain behavior and the behavior increases. This trait has been embedded in my mind so that I don’t need to apply it consciously. It has become a behavioral reflex that integrates naturally in my day-to-day activities.

## The Codebase Is the Developer's Campsite

Even if I don't go camping often nowadays, I follow this rule in a lot of different situations in my life. One of them is in my daily work — programming!

Working on a new feature or a bug feels excellent. Working on a codebase change feels like camping as a Scout. It is an opportunity to:

- Experience the environment.
- Understand the problem.
- Put what I know in practice.
- Use my skills to create solutions.

The codebase will host me for hours or days. Even if I don't enjoy the codebase too much, I still have to respect it because other people have worked hard on it. It gives me an opportunity to learn new things and to possibly use tools I have never been exposed to before.

<include src="TweetQuote" quoteText="Even if we don't enjoy a codebase too much, we still have to respect it because other people have worked hard on it. We can work on taking little steps to improve it."/>

Once again, I have to assume that other people will get to "camp" in the project after me. People I haven't met yet and probably will never meet. They may be developers, project managers, even end-users. As thought leader and software craftsman [_Uncle Bob Martin_](https://twitter.com/unclebobmartin) says in his [_Scout Rule_](https://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484):

> “Indeed, the act of leaving a mess in the code should be as socially unacceptable as littering. It should be something that just isn't done.”

Therefore, not only my work in the codebase needs to be clean, but it should leave the code at least a little better than I found it.

These are some examples in which I have applied this improvement of the status quo within a project:

- It took me 30 minutes to understand what this function does. Can I rename it to something more declarative or expressive so that others can understand it quicker than I did?
- I wasn't able to run this project with the provided instructions. Can I write the instructions that I followed but are not documented in a README file?
- This code is more convoluted than it should be. Can I make it easier and clearer?
- This function doesn’t have enough tests. Can I add some tests?

These small improvements will help my teammates and myself later. The code is not going to end up perfect, but it will be better than it was before. By following this practice, the code grows in a better direction with every action that you take on it.

<include src="TweetQuote" quoteText="Small but powerful actions for teams that improve a codebase gradually: Vague naming? Make it explicit. Confusing code? Make it clearer. No documentation? Add steps to the README. Missing tests? Write one."/>

I have been doing software development for years and being a Scout had already prepared me to transfer the mindset and values exposed by Uncle Bob from the campsite to the codebase. But this approach is not an excuse for not allocating exclusive time and developers to fix issues in a codebase; it is just one way to continuously get things to a better state.

![Binary tree - example of clean code growing organically and gradually following the Scout development approach.](https://images.ctfassets.net/23aumh6u8s0i/5KLuJlW0dEoHg3Wf03i7t9/a11e8be6f2480802675a8d4daaf6c3c2/Binary-Tree)

<include src="asides/AboutAuth0" />


A Scout Approach to Software Development

Stretching OAuth2 scopes beyond intended usage leads to trouble in complex architectures.



**TL;DR:** Scopes only come into play in delegation scenarios, and always limit what an app can do on behalf of a user: a scope cannot allow an application to do more than what the user can do.

Although stretching scopes beyond that usage is possible, it isn’t trivial or natural – contrary to what common naïve narratives would want you to believe.

<include src="TweetQuote" quoteText=".@vibronet on why using OAuth2 scopes in every authorization scenario is not a good idea."/>

## The Problem

OAuth2 scopes are misunderstood. Developers are victim of the “man with a hammer” syndrome here — **scopes are the only primitive defined in OAuth2 that has something to do with authorization, and as a result people use them in every authorization scenario** — even the ones for which they weren’t conceived. Just like Newtonian laws are enough to tackle simple problems, the same can be said for those naïve uses of scopes — but as soon as architectures get more complicated, people discover (often painfully) that they need to rethink things in quantum terms to get out of trouble.

It certainly doesn’t help that protocol specs aren’t too prescriptive on this point — a common ailment in OAuth2 — but a deeper read usually helps to clarify things. Circumstantial evidence/spec intent and context on one side, “laws of physics” on the other leave little room for interpretation.

Let me stress: most misunderstandings I discuss here come from legitimate authorization requirements; scopes just happen to be the wrong artifact to carry them. If anything, this points to the need for more prescriptive guidance on the matter (for a primer, see [Jared Hanson’s session at Identiverse](https://www.youtube.com/watch?v=eEI4ShHPh-8)).

Here’s an extra note to clarify further what I am trying to do here, given that I expect some people will push back hard when their beliefs are challenged.

Like everything that doesn’t really exist in ground reality, **the semantic of scopes is entirely in our head**: a consensual hallucination where we all agree on the meaning of the term — hence formally you are free to refuse the entire premise of this post and use “scope” to mean whatever you like. The main selection criteria I am using here is, what’s the choice of meaning that will be best conducive of us “thinking good thoughts,” as in taking decisions that will make our solutions work reliably? That’s a terribly relative, very arbitrary thing to establish — one that doesn’t scale linearly. Heuristic for prime numbers is super handy and we could embrace it, but if we need to work beyond a certain number it will stop working: our intended range determines whether the heuristic takes care of our needs, or it’s a dangerous oversimplification that will force us to backtrack and rip out a lot of logic in the process. Same with scopes: we can hold on to simplified views and revel in their apparent neatness, and feel the burn when we go beyond trivial cases and start having to architect serious shit.

## Scopes Inception

To all intents and purposes, scopes didn’t really exist before OAuth. The quintessential use case OAuth was devised for is a simple scenario, which has been presented ad nauseam already. LinkedIn asks for your Gmail password so it can use it to log in as you in Gmail, programmatically harvest your contacts (via API/scraping/etc) and spread itself; but knowledge of your Gmail password allows LinkedIn to do far more than that (e.g. sending mails on your behalf, read your messages, etc) and put the secrecy of your credentials at risk.

OAuth shows up, devises a mechanism for LinkedIn to ask Gmail just for the action it requires (access contacts) and nothing else — and makes all this possible without ever sharing with LinkedIn your gmail credentials. Done. Scopes happen to be the primitive that OAuth2 introduced for allowing LinkedIn to request delegated access to your Gmail’s contacts, to the exclusion of everything else. Intent clear and mission accomplished, right?

To me, that would be enough to demonstrate my thesis (scopes only come into play in delegation scenarios, and always limit what an app can do on behalf of a user; they are not meant to grant the application permissions outside of the privileges the delegated user already possesses). However, I know that this scenario alone won’t be enough to convince everyone: a classic objection is “fine, that might have been the original intent, but that doesn’t mean that they can’t be successfully used for more scenarios!.” Fair. Let’s dig deeper and explore more ramifications.

<include src="TweetQuote" quoteText="Scopes only come into play in delegation scenarios, and always limit what an app can do on behalf of a user."/>

## Scopes as Claims

What I described so far is all about using scopes for asking for permissions. **OAuth2 says nothing about scopes being claims in access tokens**, given that access tokens (ATs from now on) don’t need to carry claims at all (ATs are shapeless, per OAuth — and per OpenId Connect as well: only id_tokens are defined as JWTs). Nonetheless, the belief that scopes can be used to express authorization beyond delegated scenarios is deeply entrenched in the assumption that scopes do travel in the access token in form of claims. More precisely, the essence of the problem lies the conviction that **the presence of a scope claim in an access token invests the bearer with its corresponding permission, and that a resource (API, etc) being invoked with such a token can/should grant the corresponding access level without any further check**. It is pretty easy to show that in the general case, that logic wouldn’t work.

To set up our counterfactual, let’s entertain the notion that we are indeed using ATs in a specific format (JWT) carrying scope claims. Here there’s a corollary of the thesis: in the general case, scopes alone in an access token are not enough to carry on authorization decisions. Stealing my own thunder, I’ll tell you the two reasons why that’s the case: 1) the resource visible at the OAuth level isn’t usually the real resource requiring authorization, and 2) the authorization server isn’t omniscient. Let me unpack this through examples: I’ll use Azure AD because the Microsoft Graph is a really good example of this phenomenon.

## The OAuth2 Resource Isn’t The Real Resource

Say that I want my web app to call an API to list all the email messages of the currently signed in user. I request an AT for invoking the Microsoft Graph, and I request the scope **Mail.Read**. Once I get it, I make my web app call **me/messages**, and get a nice list of emails. All is good.
Now, let me make a small change to the call syntax. Instead of me/messages, I’ll call **users/guid/messages**. Still works, awesome! No surprise there.

Here’s the twist. Let me repeat that call, this time asking for the messages for another user. I don’t think anyone would be surprised to see the request result in a 400. And yet, my AT carried the **Mail.Read** scope! The point here is that **the scope is only saying to the authorization server (AS) what the app can do on the user A’s behalf**, which means that the app can list messages just like user A would, but cannot list messages for user B regardless of the presence **Mail.Read** scope. In other words, **Mail** in **Mail.Read** is a resource type, a family of resources — not a specific instance of inbox. But at access time, the specific inbox being requested does matter. Intuitive, right? If the API behavior would be any different we would be in serious trouble. Figure 1 provides a visual summary of the scenario.

![OAuth2 Scopes Mail API exmaple](https://images.ctfassets.net/23aumh6u8s0i/1fcJ0pv60sB1eWrQm9w7KX/8d076bb0f3982735272e00616af27388/oauth2-scopes-mail-api)

_Figure 1: A token carrying the scope Mail.Read indicates that the app can gain delegated access to the user’s mailbox. That scope doesn’t grant to the app privileges that the user doesn’t have: attempts to access another user’s mailbox will fail._

This is an example of 1). The resource we are asking a token for is an API offering a façade for multiple, more granular resources — with their own lifecycle, permissions, privileges and authorization rules. The scope in this scenario is not expressing one of those finer-grained, “ground reality” resources. The true resources in this example are really the inboxes of each user, and that was carried by the REST call rather than the token used to secure it… and the authorization decision emerged from combining the scope **Mail.Read** (without which we wouldn’t have bothered doing anything else), the identifier of the user (carried through a different claim in the token) and the entity requested (in the URL of the entity, hence in the actual call).

But the solution is simple, then! Let’s just describe those sub-level resources at the OAuth2 level, let’s surface the true resource in the protocol — so that scopes can finally express actual privileges. That is sometimes possible, if the resources you are exposing are ultra-simple, which usually means they don’t exist outside of your API. In term of “thinking good thoughts,” I am still somewhat against that. The fact that you might concoct cases where scopes express authorization directives context-free doesn’t make the aforementioned context-dependent scope uses disappear: if your access control logic now assumes scopes to be of the context-free kind (and more importantly, if you/your developers now understand scopes in those terms), your access checks will be too permissive when you do receive classic delegated scopes as you’ll take the permissions in the incoming scopes as directives, without making the further contextual checks they require (“Sure, he got mail.read — but does he own this inbox?”).

However, that’s not the biggest problem with using scopes to represent granted permissions (as opposed to delegated ones). The biggest challenge derives from the fact that permissions are always resource specific, and that transfers a lot of complexity to the AS and the tokens it issues. Resources can be very numerous, leading to A LOT more token requests than in the general case; they can have heavily decentralized life cycles, which makes it hard for the AS to know enough about assigned permissions (or learn about it in timely fashion) to be able to express that as claims; and permissions on an individual resource can be numerous and/or verbose, leading to unmanageably large tokens.

To make things more concrete, think of the case in which the resources being accessed are documents in some repository. According to the naïve view I sketched earlier, we can turn scopes from a delegated hint (which requires the resource to intersect the delegated permission in the scope, with the actual user privileges on lower-level resource being requested to obtain the effective permissions reflected in the access control logic) to an actual assigned privilege (the sheer presence of the scope is all the resource need to grant access, without checking anything elsewhere) just by directly expressing the document itself in our token request, rather than a generic API for accessing documents in the repository. The scenario is on display in Figure 2.

![OAuth2 Scopes assigned privilege example](https://images.ctfassets.net/23aumh6u8s0i/iZG02a9fyVSgvSZF08yFc/fcbcbd01ab22dd2402556d45c43d64fd/oauth2-scopes-doc-api)

_Figure 2: it is possible to surface at the protocol level the actual resources being accessed; it is also possible to relieve the web API from the need to keep track of access policies, relying entirely on the claims included with the incoming token. However the price to pay is an omniscient AS and more tokens than the approach shown in Figure 1 required._

Note: The mechanism we use for expressing that in the request to the AS doesn’t matter for the purpose of this discussion. for example, we can add a prefix to the scope string to point to the exact document we want, followed by the action we request (e.g. <documentID>:read), although in a real system it would make a big difference in term of usability.

The approach hinges on the assumption that the AS knows every resource, and knows all the policies governing who has access to what — and in what terms. This is represented by the access policies store in Figure 2. Armed with that knowledge, the AS can immediately evaluate whether the requestor has indeed the privileges corresponding to the permissions being requested and A) refuse to issue a token if the requirement aren’t met or B) issue a token containing a statement that access policies have been evaluated and the user should be allowed to perform the requested operation. In the case of B), any resource trusting the AS (and any resources whom delegated its full access management policies to the AS, a function NOT enshrined in either OIDC or OAuth) would simply follow the authorization directive contained in the token.

Now, let’s ignore for a moment that there’s no reason for such a statement to travel in a scope claim — one can pick ANY claim type without the need to overload an entity meant for a different scenario and make scopes consuming logic more complicated. Regardless of what claim is used, requesting a different token for each different document would create a very large increase in traffic. It’s not uncommon to see repositories with millions of documents, even in mid-sized businesses. Imagine the traffic generated by a simple thumbnail generator for a folder, multiplied for all the concurrent users across all the apps portfolio of the company, and all the ripples downstream to that (e.g. increase in size for token caches for offline use, increased lookup time to use those caches, etc., etc.).

Then there’s the matter of how many privileges you’d want to transmit in a token. Although having a client request different tokens for read and write operations is possible, that would exacerbate the tokens explosion challenge; but batching all the privileges a user has for a given document would be problematic as well, as the token itself could become very large. Expressing claims by reference is always possible, but having to make an API call for evaluating a claim would somewhat defeat the purpose of having scopes as a simple, immediately consumable source of truth for all things authorization.

## The Authorization Server Isn’t (Usually) Omniscient

But finally, the biggest problem of all is that having to keep the AS in the loop whenever documents are created, destroyed or assigned in different capacity to users is a daunting task — one that isn’t done even in much simpler settings than cloud and distributed systems based on public networks.

Think of how access to files is regulated in Unix or Windows: the domain controller doesn’t keep track of every file’s ACL — every file has a local policy, which is evaluated at access time rather than at ticket generation time. If OSes have to rely on resource side policies, despite all the simplifying conditions they enjoy (homogeneous resource types; constant line of sight with the domain controller; reliable network operations; etc), how could we expect this to be mainstream in the far more challenging public cloud scenario?

Now, technically all of this can be done. But it requires A LOT of work, very precise assumptions about the resources types and lifecycle, a very flexible AS, and so on — far from the naïve assumption that given that the ‘A’ in “AS” stands for “authorization”, all authorization logic can be centralized in the AS and all authorization decisions can be expressed as scopes values.

## In Summary

In the general case, scopes are used to express what an application can do on behalf of a given user — and that is always a subset of what the user can do in the first place. In other words, scopes are used for handling delegation scenarios. Resources are responsible to combine the incoming scopes and the actual user privileges to calculate the call’s effective permissions and make access control decisions accordingly.

Again in the general case, overloading scopes to represent actual privileges assigned to the app (as opposed to the delegated permissions mentioned above) is problematic — as it requires the AS to have specialized authorization knowledge at a granularity that is often not practical to achieve and maintain; even in the case in which that’s viable, the increase in traffic and token size might still render the approach unfeasible.

That is not to say that the AS should not make authorization decisions; if the AS happens to have access to data and logic that make it possible to take authorization evaluations at token issuance time, those can certainly be reflected in the decision of withholding issuance, or in the content of the issued token — but there’s no reason for the latter to be expressed in scopes claims, and doing so can in fact contribute to keep alive the urban legend that made me spend about half of a long flight writing this also long post.


On The Nature of OAuth2’s Scopes

Learn how to use web workers in JavaScript to create parallel programming and perform multiple operations simultaneously rather than interleaving them.

Speedy Introduction to Web Workers

In this Redis tutorial, learn how to install and setup Redis as well as commands to write, read, update, and delete data from the store using its core data structures.

Introduction to Redis: Installation, CLI Commands, and Data Types

1097492785caf9ffeebffeb624202d8f?s=200 avatar

1097492785caf9ffeebffeb624202d8f?s=200

Prosper is a great speaker, community leader, open source hacker, technical consultant, and a fervent Developer Advocate. He is a full-stack software engineer who has worked on biometric, health and developer tools. Prosper recently co-founded a startup called Eden that’s focused on improving the quality of lives in Nigeria and currently leads the engineering team. He also co-founded forloop, the largest developer community in Africa.

Former Auth0 Employee

Prosper Otemuyiwa

Learn how to develop applications in AngularJS  using a component-based architecture.

New Features for Developing AngularJS Applications - Part 2: Build An App

Learn how to develop applications in AngularJS using a component-based architecture.



**TL;DR:** AngularJS 1.5+ has undergone major updates. In this article, you'll learn how to develop AngularJS applications using a component-based architecture and leverage the API changes that will help you write your AngularJS applications in an Angular(v2+) style.

The Component-based Architecture is prevalent in frontend development today. JavaScript Client-side frameworks such as React, Preact, Ember, Vue.js all advocate building applications in components. _Angular_ also popularly known as _Angular(v2+)_ which is a major rewrite of AngularJS is completely component-based.

<include src="TweetQuote" quoteText="The Component-based Architecture is prevalent in frontend development today."/>

A typical example of an application built applying the component architecture involves developing several features of the application as modules with reusable components.

For example, let's use a Music Player application. A required feature for this product could be a Music Player widget. A developer designing their app in a component-based architecture style can model this feature as a *Module*.

Let's call it the _Music Player Widget_ Module. Inside the module, we can have the following components:

- _Music Search_ Component, `<music-search>`.
- _Music Playlist_ Component, `<music-playlist>`.
- _Currently Playing Song_ Component, `<music-currently-playing>`.

In a Component-based Architecture, we usually have _Parent_ and _Child_ components. The three individual components mentioned above can be referred to as _Child_ components wrapped up into a big component that will be known as the _Parent Component_ or _Root_ component.

## The AngularJS .component() method

The Angular team introduced the `.component()` method in AngularJS 1.5. This method allows developers to write their applications using the component-based architecture. How do we use the `.component()` ?

Before Angular 1.5, we only had directives, Angular directives such as `ngHide`, `ngHref`, `ngRepeat`, and custom directives.

Directives are a unique and powerful feature that allows you create custom HTML-like tags, specific to your application. In this article, we'll examine a directive, and convert it to a component using the `.component()` method.

<include src="TweetQuote" quoteText="Directives are a unique and powerful feature that allows you create custom HTML-like tags, specific to your application"/>

```js
angular.module('tutorial', [])
  .directive('abacus', function abacus() {
    return {
      scope: {},
      bindToController: {
        count: '='
      },
      controller: function () {
        function increment() {
          this.count++;
        }
        function decrement() {
          this.count--;
        }
        this.increment = increment;
        this.decrement = decrement;
      },
      controllerAs: 'abacus',
      template: `
        <div>
          <input type="text" ng-model="$ctrl.count">
          <button type="button" ng-click="$ctrl.decrement();">-</button>
          <button type="button" ng-click="$ctrl.increment();">+</button>
        </div>
      `
    };
  });
```

The first step in converting the directive to a component is to change `.directive()` to `.component()`.

_directive_

```js
.directive('abacus', function abacus() {
  return {

  };
});
```

_component_

```js
.component('abacus', function abacus() {

});
```

Nice and simple. Essentially the return `{};` statement inside the `.directive()` becomes the Object definition inside `.component()`. Awesome!

## Bindings

In a `.directive()`, the scope property allows us to define whether we want to isolate the `$scope` or inherit it, this has now become a sensible default to always make our directives have isolated scope. So repeating ourselves each time just creates excess boilerplate.

With the introduction of `bindToController`, we can explicitly define which properties we want to pass into our isolate scope and bind directly to the Controller.

With the bindings property on `.component()` we can remove this boilerplate and simply define what we want to pass down to the component, under the assumption that the component will have an isolated scope.

```js
// before
.directive('abacus', function abacus() {
  return {
    scope: {},
    bindToController: {
      count: '='
    }
  };
});

// after
.component('abacus', {
  bindings: {
    count: '='
  }
});
```

## Refactoring Controller Function

Nothing has changed in the way we declare controller, however it’s now a little smarter and has a default `controllerAs` value of `$ctrl`.

If we’re using a controller local to the component, we’ll do this:

```js
  // 1.4
  {
    ...
    controller: function () {}
    ...
  }
```

If we’re using another controller defined elsewhere, we’ll do this:

```js
// 1.4
{
  ...
  controller: 'SomeCtrl'
  ...
}
```

If we want to define `controllerAs` at this stage, we’ll need to create a new property and define the instance alias:

```js
// 1.4
{
  ...
  controller: 'SomeCtrl',
  controllerAs: 'vm'
  ...
}
```

This then allows us to use something like `vm.title` inside our template to talk to the instance of the controller. In AngularJS 1.5, we can do the following inside `.component()`:

```js
// 1.5
{
  ...
  controller: 'SomeCtrl as vm'
  ...
}
```

This helps us minimize our code by preventing the use of `controllerAs` property. However, we can add the `controllerAs` property to maintain backwards compatibility or keep it if that’s within your style for writing directives or components.

There is another option that completely eliminates the need for `controllerAs`, and Angular automatically uses the property, `$ctrl`. For instance:

```js
.component('bet', {
  controller: function () {
    this.betNumber = 777;
  }
});
```

In the code above, there is no `controllerAs` property. In our template, controller defaults to `$ctrl`, so we can get the value of `777` in our template using `$ctrl.betNumber`.

Since there is no need for the `controllerAs` property, we can just have our directive refactored to a component like so:

```js
// before
.directive('abacus', function abacus() {
  return {
    scope: {},
    bindToController: {
      count: '='
    },
    controller: function () {
      function increment() {
        this.count++;
      }
      function decrement() {
        this.count--;
      }
      this.increment = increment;
      this.decrement = decrement;
    },
    controllerAs: 'abacus'
  };
});

// after
.component('abacus', {
  bindings: {
    count: '='
  },
  controller: function () {
    function increment() {
      this.count++;
    }

    function decrement() {
      this.count--;
    }

    this.increment = increment;
    this.decrement = decrement;
  }
});
```

## Templating Changes

Look at the code below, and how the template property is defined.

```js
.component('abacus', {
  bindings: {
    count: '='
  },
  controller: function () {
    function increment() {
      this.count++;
    }
    function decrement() {
      this.count--;
    }
    this.increment = increment;
    this.decrement = decrement;
  },
  template: `
    <div>
      <input type="text" ng-model="$ctrl.count">
      <button type="button" ng-click="$ctrl.decrement();">-</button>
      <button type="button" ng-click="$ctrl.increment();">+</button>
    </div>
  `
});
```

The template property can be defined as a function injected with `$element` and `$attrs` parameters. If the template property is a function then it needs to return a String representing the HTML to compile:

```js
{
  ...
  template: function ($element, $attrs) {
    // access to $element and $attrs
    return `
      <div>
        <input type="text" ng-model="$ctrl.count">
        <button type="button" ng-click="$ctrl.decrement();">-</button>
        <button type="button" ng-click="$ctrl.increment();">+</button>
      </div>
    `
  }
  ...
}
```

## One Way Data Binding

If you have been using AngularJS long enough, you will be accustomed to the two-data way binding it provides. However, in AngularJS 1.5+, there is a new one-way data binding that we can explore and also use to improve the performance of our AngularJS applications.

A new syntax expression for the one-way data binding is the use of `<` notation. For two-way data bindings, the `=` notation is used instead.

```js
{
  ...
  bindings: {
    firstObj: '<',
    secondObj: '='
  },
  ...
}
```

Check out a good example of one-way data binding below:

```js

var sample = {
  bindings: {
    firstObj: '<',
    secondObj: '<'
  },
  template: `
    <div class="section">
      <h4>
        One way Data binding Example
      </h4>
      <p>First Object: {{ $ctrl.firstObj }}</p>
      <p>Second Object: {{ $ctrl.secondObj }}</p>
      <a href="" ng-click="$ctrl.testDataBinding();">
        Change Values
      </a>
    </div>
  `,
  controller: function () {
    this.testDataBinding = function () {
      this.firstObj = 10;
      this.secondObj = {
        maxwell: {
          language: 'PHP',
          name: 'Jack Maxwell'
        }
      };
    };
  }
};

function ExampleController() {
  this.exfirstObj = 99;
  this.exSecondObj = {
    unicodeveloper: {
      language: 'JavaScript',
      name: 'Prosper Otemuyiwa'
    }
  };
  this.testDataBinding = function () {
    this.exfirstObj = 33;
    this.exSecondObj = {
      lesasote: {
        language: 'Scala',
        name: 'Shitta Kalesaso'
      }
    };
  };
}

angular
  .module('app', [])
  .component('sample', sample)
  .controller('ExampleController', ExampleController);

```

``` html  

<div ng-app="app">
  <div ng-controller="ExampleController as example">
    <h3>
      One way data-binding
    </h3>
    <div class="section">
      <h4>
        Parent
      </h4>
      <p>
        First Object: {{ example.exfirstObj }}
      </p>
      <p>
        Second Object: {{ example.exSecondObj }}
      </p>
      <a href="" ng-click="example.testDataBinding();">
        Change Parent Values
      </a>
    </div>
    <sample firstObj="example.exfirstObj" secondObj="example.exSecondObj"></sample>
  </div>
</div>

```

One-way data binding allows changes to propagate down and flow into the component to update it with new data.

## LifeCycle Hooks

Lifecycle hooks shipped alongside the `.component()` method in AngularJS 1.5. These hooks are functions that can be invoked at different stages of a component's life in AngularJS apps. These hooks are:

- **$onInit()**
- **$onChanges()**
- **$onDestroy()**
- **$postLink()**


### $onInit()

The `$onInit()` hook is invoked when controllers have been constructed. It is used for initialization work for controllers. A typical example is populating a table or some form of list once a controller has been loaded.

```js
function MyController() {
  this.$onInit = function () {
    this.players = [{
        "name": "Lionel Messi",
        "club": "Barcelona",
        "jerseyNumber": 10,
        "position": "Forward",
      },
      ...

    ];
  };
}
```

``` html  

  <div ng-repeat="player in players">
    <td>{{ player.name }}</td>
    <td>{{ player.club }}</td>
    <td>{{ player.jerseyNumber }}</td>
    <td>{{ player.position }}</td>
  </div>

```

### $onChanges()

Remember the old way of detecting changes with `$scope.$watch()`. In Angular 1.5, changes can be detected with the `$onChanges()` hook. When building components at one point you will have data coming into your component from an external source e.g parent component. With `$onChanges()`, we can react to this changes and update the child component data effectively.

Before we go ahead into examples it is important for us to understand, how, why and when this hook is called. `$onChanges` hook is called in two scenarios, one being during component initialization, it passes down the initial changes that can be used right away through `isFirstChange` method.

```js
$ctrl.onChanges = function (changes) {
    if (changes.commit) {
        $ctrl.issues = openIssues(changes.commit.currentValue);
        $ctrl.repo = createdRepos(changes.commit.currentValue);
    }
}
```

### $onDestroy()

This hook is called when its containing scope is destroyed. We can use this hook to release external resources, watches and event handlers. This is basically the same as `$scope.on($destroy, fn)` when used in controllers.

```js
function MyController($element) {

  var eventHandler = function () {
    /**
     * Write code here
     */
  };

  /**
   * [$onInit: Attach our eventHandler when the element is clicked]
   */
  this.$onPostLink = function () {
    // When the component DOM has been compiled attach you eventHandler.
  };

  /**
   * [$onDestroy: Destroy the eventHandler once the component is destroyed]
   */
  this.$onDestroy = function () {
    // Destroy all custom events or bindings when the component scope is destroyed.
  };
}
```

When our component is constructed, we attach a click event to the component element that does something to it when clicked, it can be wherever we want let's say show alert box saying I am clicked.

In the duration when this component is active we would be happy to have this event, but when this component is inactive, we don't need this event anymore it has to go. Since this is our custom event and it's not native to Angular, it will not be detached from our app along with the component, but it will be left snooping around for an element which does not exist.

We need to tell Angular through the `$onDestroy` hook that when this component is destroyed, the event should be detached too.

### $postLink()

This hook is called after the controller's element and its children have been linked. When the component elements have been compiled and ready to go, this hook will be fired.

```js
function MyController($element) {
  /**
   * When the element and its child nodes have been compiled
   */

  this.$postLink = function () {
    /**
     * Engineer something epic here
     */
  };

}
```

This hook can help us to implement some functionalities that depend on the component elements to be fully compiled. It is important to note that this is not a complete replacement for DOM manipulation, this functionality should be handled by decorator directives.


## Stateless components

There’s now the ability to create `stateless` components. This is essentially a component with no controller attribute.

```js

var Person = {
  bindings: {
    name: '<',
    age: '<',
    sex: '<'
  },
  template: `
    <div>
      <p>Name: {{ ::$ctrl.name }}</p>
      <p>Age: {{ ::$ctrl.age }}</p>
      <p>Age: {{ ::$ctrl.sex }}</p>
    </div>
  `
};

angular
  .module('app', [])
  .component('person', Person);

```

Use in a html file like so:

``` html  

  <person name="prosper" age="14" sex="male"></person>

```


## Stateful Components

Stateful components are components that perform stateful tasks such as handling form data, making HTTP requests and generally manipulating data. In a stateful component, you can have a controller that loads a list of car items to display from an external service (API).

```js
var CarItems = {
  template: './car.html',
  controller: function($http) {
    var ctrl = this;
    // Initialising the component
    ctrl.$onInit = function() {
      $http.get('/api/carlistings').then(function (data) {
        ctrl.items = data;
      });
    };
  }
};

angular
  .module('app', [])
  .component('carItems', CarItems);
});
```

## Multi-slot Transclusions

In AngularJS, **transclusion** simply allows you to include content from one place into another template. In basic computer science definition, **transclusion** refers to the inclusion of part or all of an electronic document into one or more other documents by reference.

Multi-slot transclusions was one of the features included in Angular 1.5. How does this work? AngularJS 1.5+ allows us define multiple slots. A good case study is trying to create a generic `card` component. Something like:

``` html  

  <card>
    <card-title>Great Title</card-title>
    <card-body>
      This is the body of the card component.
    </card-body>
  </card>

```

In the definition of the `<card>` component, the `<card-title>` and `<card-body>` elements are the transclusion slots that will be present in the component.

```js
app.component('card', {
  template: [
      '<div style="border: 1px solid black;">'
      '<div ng-transclude="title"></div>',
      '<div ng-transclude="body"></div>',
      '</div>'
  ].join(''),
  transclude: {
    title: 'cardTitle',
    body: '?cardBody'
  },
  controller: function() {
    // Render the component as a card
  }
});
```

**Note:** `?` signifies that the slot is optional.


## Conclusion

As we can see, AngularJS applications can be better with these features listed above. Much work has gone in to the project from the team to make it very similar to the way we write Angular apps using the component archictecture.

In the next and final part of this series, we'll build a sample application with AngularJS 1.5+ that harnesses somes of these features. Stay tuned!


New Features for Developing AngularJS Applications - Part 1: Component-Based Architecture

vincenzo-chianese

Vincenzo Chianese is an Italian Software Developer focused on Web APIs and User Interfaces. He has been working for the last years in API companies such as Apiary, Oracle, LunchBadger, Stoplight. Currently, he is working for Microsoft to help move Microsoft Graph forward and authored some open-source tools in the market (Prism, Express Gateway).

API Architect

Vincenzo Chianese

Express Gateway is an API gateway that sits at the heart of any microservices architecture, securing your microservices and exposing them through APIs.



**TL;DR:** In this tutorial, I'll show you how an API gateway can collect application specific metrics for you.
You can get [the code example in this GitHub repository](https://github.com/XVincentX/express-gateway-prometheus-metrics-example).

---

## Introduction

Unless you're building a proof of concept or an application that's not aiming to reach production, you definitely want to add **monitoring** and **metrics** to your system. In this installment, we're going to look how **Express Gateway** can help you to add application specific metrics and expose them through an HTTP endpoint that can be queried by an external service, such as [Prometheus][prometheus-homepage].

<include src="TweetQuote" quoteText="Monitoring and metrics are an important part of your system."/>

## Express Gateway to Rescue

Express Gateway is an API gateway that sits at the heart of any microservices architecture (regardless of what language or platform is being used), **securing** the different pieces and exposing them through **APIs**. All these magic works by using [Node.js](https://nodejs.org), [ExpressJS](https://expressjs.com/), and [Express middleware](https://expressjs.com/en/guide/writing-middleware.html).

![Express Gateway Diagram](https://images.ctfassets.net/23aumh6u8s0i/SsB12EeBdofDnsa69tJzv/26a9fd4972def879fd3181e203d91b11/express-gateway-diagram)

Express Gateway centralizes all the application configuration for the API use case into one YAML (or JSON) file. Within the YAML file there is an easy to understand description of what is configured and how.

Express Gateway entities, like _policies_, _pipelines_, _conditions_, and _actions_ wrap around Express middleware to make it **dynamic**. Any Express middleware can be plugged into Express Gateway to take advantage of its dynamic capabilities. It also features a hot-reload mechanism so you can change its configuration without having to restart the gateway at all.

## Writing a Plugin for Express Gateway

Express Gateway comes with a plugin framework used to extend the Express Gateway core.

The plugin framework enables anyone to take **Express middleware** and integrate them into Express Gateway as plugins. Express Gateway provides a declarative way to take advantage of Express middleware to be driven centrally and executed dynamically.

We're going to leverage such framework in order to build a plugin that'll hook in our HTTP responses and collect the information we need.

### Scaffold a Plugin

A plugin is nothing more than a JavaScript object that you export. It's shape is described in detail [in the documentation][plugin-shape]

```javascript
module.exports = {
  init: function (pluginContext) {

  },
}
```

In our case, we will create a plugin that:

1. Exposes a policy that will hook in the [response][express-response], collecting information in
[Prometheus format][prometheus-format].
2. Extend the [Admin API][admin-api] to expose an additional endpoint that will serve all the collected information.

#### What Metrics Are We Going to Collect?

There are a lot of ways to slice and dice metrics. They may vary according to your needs.

In this example, we will label all the responses that are on the way to the client according to:

* Success/Failed responses (discerned on the status code).
* The status code itself.
* The consumer id (if the request is authenticated).
* The [API Endpoint][apiendpoint] that triggered the Gateway.

#### What format do we expose the metrics?

To leverage the existing tooling around, we will expose the collected metrics in the [Prometheus Text Based Wire Format][prometheus-format]. In this way, we can **leverage the tools** that are already on the space to push and visualize the information, such as [Grafana][grafana].

```javascript
const metrics = require('prom-client');

const statusCodeCounter = new metrics.Counter({
  name: 'status_codes',
  help: 'status_code_counter',
  labelNames: ['type', 'status_code', 'consumer', 'apiendpoint']
});

module.exports = {
  version: '1.0.0',
  policies: ['metrics'],
  init: (pluginContext) => {
    pluginContext.registerAdminRoute((app) => {
      app.get(pluginContext.settings.endpointName, (req, res) => {
        if (req.accepts(metrics.register.contentType)) {
          res.contentType(metrics.register.contentType);
          return res.send(metrics.register.metrics());
        }

        return res.json(metrics.register.getMetricsAsJSON());
      });
    });

    pluginContext.registerPolicy({
      name: 'metrics',
      policy: ({ consumerIdHeaderName }) => (req, res, next) => {
        res.once('finish', () => {
          const apiEndpoint = req.egContext.apiEndpoint.apiEndpointName;
          const consumerHeader = req.header(consumerIdHeaderName) || 'anonymous';
          const statusCode = res.statusCode.toString();
          const responseType = res.statusCode >= 200 && res.statusCode < 300 ? 'SUCCESS' : 'FAILED';
          statusCodeCounter.labels(responseType, statusCode, consumerHeader, apiEndpoint).inc();
        });

        next();
      }
    });
  }
};

```

Let's go through the code and see the relevant parts:

```javascript
const statusCodeCounter = new metrics.Counter({
  name: 'status_codes',
  help: 'status_code_counter',
  labelNames: ['type', 'status_code', 'consumer', 'apiendpoint']
});
```

Here we're declaring a new Prometheus Counter called `status_code` that will track all the responses and categorize
them based on the declared labels (`['type', 'status_code', 'consumer', 'apiendpoint']`):

```javascript
pluginContext.registerAdminRoute((app) => {
  app.get(pluginContext.settings.endpointName, (req, res) => {
    if (req.accepts(metrics.register.contentType)) {
      res.contentType(metrics.register.contentType);
      return res.send(metrics.register.metrics());
    }

    return res.json(metrics.register.getMetricsAsJSON());
  });
});
```

This part of code is registering a new [route][admin-route-plugin] that will expose all the collected metrics. According to the `Accept` header, we're either returning the data in Prometheus format as JSON or in text format. The external tool collecting the data (such as InfluxDB or a Prometheus server) will query this endpoint **periodically** to grab the latest updates.

*Note:* Prometheus also supports [data pushing](https://prometheus.io/docs/instrumenting/pushing/) instead of polling it periodically. If you go in this way, you can **avoid to expose an endpoint** at all. Based on your requirements (such as security) you may opt for this other option.

```javascript
pluginContext.registerPolicy({
  name: 'metrics',
  policy: ({ consumerIdHeaderName }) => (req, res, next) => {
    res.once('finish', () => {
      const apiEndpoint = req.egContext.apiEndpoint.apiEndpointName;
      const consumerHeader = req.header(consumerIdHeaderName) || 'anonymous';
      const statusCode = res.statusCode.toString();
      const responseType = res.statusCode >= 200 && res.statusCode < 300 ? 'SUCCESS' : 'FAILED';
      statusCodeCounter.labels(responseType, statusCode, consumerHeader, apiEndpoint).inc();
    });

    next();
  }
});
```

Then, we export a new policy that will register an event handler once the response is terminated. Here we can now **inspect** all the response as well as request details that will populate our labels.

*Note:* [`egContext`][egcontext] is an Express Gateway specific object that contains additional information on the request that's being handled.

## Put it in production

We have our plugin ready to be used. Now we have to install it in our Gateway and enabled it.

Express Gateway plugins are nothing more than **NPM packages**, so we can simply publish our package to the registry and then install it using the command line.

For this tutorial, I've already published a plugin called `express-gateway-prometheus-metrics-example` with the exact same code we saw above. Hence, we can install the plugin directly by simply typing `eg plugins install express-gateway-prometheus-metrics-example`

*Note:* Express Gateway can also load [plugins inline][inline-load]. This is useful when you want to test them before publishing them. In this case, you could point the `package` property to our `index.js` file.

Now let's modify our [`gateway.config`][gateway-config] and configure a policy that will take advantage of such policy:

```yaml
http:
  port: 8080
admin:
  port: 9876
apiEndpoints:
  api:
    host: '*'
serviceEndpoints:
  httpbin:
    url: 'http://httpbin.org'
policies:
  - proxy
  - metrics
pipelines:
  - name: basic
    apiEndpoints:
      - api
    policies:
      - metrics:
      - proxy:
          - action:
              serviceEndpoint: httpbin
              changeOrigin: true
```

## See it live

Let's spin up the gateway and throw some requests to it:

```bash
$ ab -n 20 http://localhost:8080/
```

Once the command is terminated, we can now query our metrics endpoint to see what happened with such requests:

```bash
$ curl http://localhost:9876/metrics
# HELP status_codes status_code_counter
# TYPE status_codes counter
status_codes{type="FAILED",status_code="502",consumer="anonymous",apiendpoint="api"} 15
status_codes{type="SUCCESS",status_code="200",consumer="anonymous",apiendpoint="api"} 5
```

You can see we received back the Prometheus metrics with all the data we collected.

## Byproduct — Use JSON Schema to validate your parameters

Express Gateway relies on **JSON Schemas** to make sure all the configurations that goes in its funnel it's correct.

You can leverage the same mechanism to specify the **required** parameters, good defaults and **validation** rules for your plugin.

In our case, for instance, it's pretty clear that the Admin API path where the metrics will be exposed is **mandatory**; also we might want to configure the header where the consumer id information is stored.

With these two requirements in mind, we can write something like this:

```javascript
module.exports = {
  version: '1.0.0',
  policies: ['metrics'],
  schema: {
    $id: 'http://express-gateway.io/plugins/metrics.json',
    type: 'object',
    properties: {
      endpointName: {
        type: 'string',
        default: '/metrics'
      }
    }, required: ['endpointName']
  },
  init: function (pluginContext) {
    pluginContext.registerAdminRoute((app) => {
      // admin route code
    });

    pluginContext.registerPolicy({
      name: 'metrics',
      schema: {
        $id: 'http://express-gateway.io/policies/metrics.json',
        type: 'object',
        properties: {
          consumerIdHeaderName: {
            type: 'string',
            default: 'eg-consumer-id'
          }
        }, required: ['consumerIdHeaderName']
      },
      policy: ({ consumerIdHeaderName }) => (req, res, next) => {
        // policy code
      }
    });
  }
};

```

Thanks to this small addition, the gateway will **validate** the provided parameters against the schema and will
refuse to load the plugin if the validation does not pass.

<include src="asides/ExpressGateway" />

## Conclusions

Metrics are **hard**. In a Microservices context, it's even **harder**. In this installment we discovered how to leverage the shared **middleware** (our API gateway) to collect data **without** having to modify the services' code at all, and have a **centralized** way to push and display these.

<include src="TweetQuote" quoteText="Metrics are hard. In a Microservices context, it's even harder. See how Express Gateway and Auth0 can help you with that"/>

[plugin-shape]: https://www.express-gateway.io/docs/plugins/plugin-development/
[express-response]: http://expressjs.com/en/4x/api.html#res
[admin-api]: https://www.express-gateway.io/docs/admin/#markdown
[apiendpoint]: https://www.express-gateway.io/docs/configuration/gateway.config.yml/apiEndpoints/#markdown
[prometheus-format]: https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md
[grafana]: https://grafana.com/plugins?type=datasource
[admin-route-plugin]: https://www.express-gateway.io/docs/plugins/route-development/#exporting-admin-routes-to-plugin
[egcontext]: https://www.express-gateway.io/docs/policies/customization/eg-context/
[inline-load]: https://github.com/XVincentX/express-gateway-prometheus-metrics-example/blob/master/gateway/config/system.config.yml#L9
[gateway-config]: https://www.express-gateway.io/docs/configuration/gateway.config.yml/
[prometheus-homepage]: https://prometheus.io/


Application Specific Metrics with Express Gateway

Express Gateway is an API Gateway that sits at the heart of any microservices architecture, securing your microservices and exposing them through APIs.



**TL;DR:** In this tutorial, I'll show you how an API Gateway can be a great tool when you have multiple
microservices that need to share multiple tasks. You can get the code example [here](https://github.com/XVincentX/apigateway-playground).

---

## Introduction

[Microservices](https://auth0.com/blog/an-introduction-to-microservices-part-1/) is an architectural style with the basic idea of **decomposing** a system in a collection of services, each one implementing a particular capability/feature of the system itself based on business, technical, and other requirements.

[This has several benefits compared to a monolithic approach](https://auth0.com/blog/getting-a-competitive-edge-with-a-microservices-based-architecture/):

* It enables the **continuous delivery** of large, complex applications by deploying the singular pieces **independently**.
* It enables to select the framework and the programming language that you think it's the best for the job. You can use the latest technologies on a microservice while keep the other parts in legacy mode.
* It improves your teams agility, the ability to iterate on a small, focused piece of functionality quickly and to see results.
* It improves the resiliency of your system because a crash of a microservice **does not halt** your entire system (you can gracefully degrade the user experience).

The above points can be summarized with two keywords: **independence** and **isolation**.

This concept has been riding high during the last years with [blog posts](https://auth0.com/blog/tags/microservices/), articles, [websites](http://microservices.io), and even dedicated conferences although this is nothing really new—but rather a culmination of **best practices** in the modern web era, pushed by a tech giant that felt the need almost [ten years ago](http://www.zdnet.com/article/soa-done-right-the-amazon-strategy/).

Most of the time we don't necessarily have the same web scale, but we can benefit anyway from the paradigm of microservices.

## Challenges

The challenge though is that with microservices the knowledge is spread among multiple little pieces. However, on the other hand, the end game of your application is, most of the time, the exposure of what you're building through an **uniform API**.

So, we have two sides of the same coin: on one side, we want to break up our app into a set of services and [evergreen](https://blog.juriba.com/evergreen-it-concept-or-reality) them; on the other, we still want to offer an uniform experience.

Suppose you need to create a `Coffee` order system that will let people, registered as `Customers`, request for a coffee through an `Order`.

After a bunch of meetings, everybody in the company agrees that the `User` and registration part of your application will be written in JavaScript and run on [Node.js](https://nodejs.org/en/), while the `Order` system will be written in Go. Among the technical requirements, you want all the requests must be authenticated and, in order to prevent flooding, you want to put a [rate limiting policy](https://auth0.com/docs/connections/database/rate-limits).

Now, with such requirements, a couple of questions stand:

1. Writing **idiomatic** JavaScript is different than writing idiomatic Go. According to the programming language and the framework you're using the API you're exposing in Go might be **completely** different with regards to the other one exposed from the JavaScript microservice. How do you make sure that the final API—intended as the the whole surface exposed by your application—is _uniform_ and _consistent_?
2. _Rate limiting_, _authentication_, _authorization_, and a bunch of other stuff are things that should be shared across multiple microservices in your organisation. If you re-implement these things in each single microservice, you are **duplicating** the code at first, but more importantly you have two different pieces of software to maintain. This will mean that you will also need to make sure they behave in the same way (that's not trivial, since you could be potentially using two libraries for that).

## Solution

It turns out that, no matter the way you're doing microservices (whether you're dividing your system by business features, by domain, or coming up with a microservice architecture starting from your data), there are parts of them that are sharing functionalities.

[Microservices need a **superglue** and that glue is an **API Gateway**](https://auth0.com/blog/an-introduction-to-microservices-part-2-API-gateway/).

## API Gateway

An _API Gateway_ is a centralized middleware that encapsulates the internal system architecture and provides an API that can be shaped based on real client needs rather than simply returning what the particular microservice is sending you back. These gateways are effectively implementing the [**facade pattern**](https://en.wikipedia.org/wiki/Facade_pattern) in the microservices world.

API Gateway can have other responsibilities such as _authentication_, _monitoring_, _load balancing_, _caching_, _request shaping and management_, and _static response handling_.

## API Gateway in Practice

Let's move from theory to practice and see how to configure an API Gateway to serve our needs.

Let's suppose that we have `Customer` and `Order` microservices listening to `http://customers` and `http://orders` respectively. Using [Docker](https://docker.com) or [Kubernetes](https://kubernetes.io) achieving such scenario should be fairly easy.

We will configure an instance of an API Gateway that will sit on the edge of our system. This gateway will serve as a router for our microservices, but we'll also move some shared logic from the microservices to it. This will enable our applications to focus on the business logic.

This gateway will also throttle all the requests based on clients' IP addresses and make sure that all the
requests are authenticated based on a **JWT** that _Auth0_ is going to provide. [Auth0 will work as our **system of record** for our users](https://auth0.com/blog/360-view-of-customer-by-managing-identity/).

There are multiple API Gateways on the market. Some of them are offered by big software companies as a managed hosted solution and others are open source products. Of course, you can technically write your own solution too, but why reinvent the wheel? Instead, let's take advantage of [Express Gateway](https://express-gateway.io).

## Meet Express Gateway

Express Gateway is an API Gateway that sits at the heart of any microservices architecture (regardless of what language or platform you're using), **securing** the different pieces and exposing them through **APIs**. All these magic works by using [Node.js](https://nodejs.org), [ExpressJS](https://expressjs.com/), and [Express middleware](https://expressjs.com/en/guide/writing-middleware.html).

![Express Gateway Diagram](https://images.ctfassets.net/23aumh6u8s0i/SsB12EeBdofDnsa69tJzv/26a9fd4972def879fd3181e203d91b11/express-gateway-diagram)

Express Gateway centralizes all the application configuration for the API use case into one YAML (or JSON) file. Within the YAML file there is an easy to understand description of how and what is configured.

Express Gateway entities, like _policies_, _pipelines_, _conditions_, and _actions_, wrap around Express middleware to make it **dynamic**. Any Express middleware can be plugged into Express Gateway to take advantage of its dynamic capabilities. It also features an hot-reload mechanism so you can change its configuration without having to restart the gateway at all.

### Hands On

Installing [Express Gateway](https://express-gateway.io) is dead simple:

`~$ npm i -g express-gateway`

This will install the command line `eg` in your system, so you can now bootstrap a new gateway instance:

```shell
~$ eg gateway create
? What\'s the name of your Express Gateway? eg-example
? Where would you like to install your Express Gateway? eg-example
? What type of Express Gateway do you want to create? Getting Started with…
     created package.json
     created server.js
      ...  To start eg-example, run the following commands:
     cd eg-example && npm start
```

Next, change the working directory to `eg-example` (`cd eg-example`) and modify the [`gateway.config.yml`](https://www.express-gateway.io/docs/configuration/gateway.config.yml/) file. This is the file that controls your gateway’s behavior. For a complete configuration reference, you can see the [documentation](http://www.express-gateway.io/docs/).

```yml
http:
  port: 8080
apiEndpoints:
  customers:
    host: customers.company.com
  orders:
    host: orders.company.com
serviceEndpoints:
  customers:
    url: 'http://customers'
  orders:
    url: 'http://orders'
policies:
  - jwt
  - proxy
  - rate-limit
pipelines:
  customers:
    apiEndpoints:
      - customers
    policies:
      - rate-limit:
        - action:
            max: 1
            windowMs: 1000
      - jwt:
        - action:
            secretOrPublicKeyFile: ./key/pubKey.pem
            checkCredentialExistence: false
      - proxy:
          - action:
              serviceEndpoint: customers
              changeOrigin: true
  orders:
    apiEndpoints:
      - orders
    policies:
      - rate-limit:
        - action:
            max: 1
            windowMs: 1000
      - jwt:
        - action:
            secretOrPublicKeyFile: ./key/pubKey.pem
            checkCredentialExistence: false
      - proxy:
          - action:
              serviceEndpoint: orders
              changeOrigin: true
```

Let's go through the main part of the current configuration. The gateway will listen for HTTP requests on port `8080` (you might want to change it to `80` when going into production). Then, we have defined two **pipelines** (one per microservice) where we have enabled the [rate limit policy](https://www.express-gateway.io/docs/policies/rate-limiter) and the
[JWT](https://www.express-gateway.io/docs/policies/jwt) verification policy.

> **Note:** the configuration is shown in a extended form for clarity. However, it can be shortened by using [YAML references](http://blog.daemonl.com/2016/02/yaml.html).

> **Note:** if you want to test this locally, you'll need to make sure that `company.com` domain points to your local machine. This can be achieved by using [`dnsmasq`](http://www.thekelleys.org.uk/dnsmasq/doc.html) or by [modifying your hosts file](https://support.rackspace.com/how-to/modify-your-hosts-file/), putting both `customers.company.com` **and** `orders.company.com` to point to `localhost`. Another alternative would be to manually put the `HOST` header to the correct value while issuing requests.

### Configure the Client and the User in Auth0

Let's now configure Auth0 to work as our **system of record** for users and **issue JWTs** for them. If you don't already have an Auth0 account, <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free one now</a>.

From the [Auth0 management dashboard](https://manage.auth0.com/), click on the **APIs** menu item, and then on the **Create API** button. You will need to give your API a name and an identifier. The name can be anything you choose, so make it as descriptive as you want. The identifier will be used to identify your API, this field cannot be changed once set.

For our example, I'll name the API **billings** and identify it as `http://orders`. I'll also leave the signing algorithm as `RS256` and click on the **Create API** button.

![Creating billings API on Auth0](https://images.ctfassets.net/23aumh6u8s0i/2wgySpoX1QsiKHgITJWh11/646b7364760f17fdbb9800a280045c18/create-auth0-api)

Now point your browser to `https://yourAPI.auth0.com/pem` (where `yourAPI` is the Auth0 domain that you chose when creating your account) and download the **public key** file. This is the key that we will
use to verify that the JSON Web Tokens (JWTs) issued by Auth0 are valid. Save it as `pubKey.pem` and place it in the same directory specified in `secretOrPublicKeyFile` parameter of the `jwt` policy (that is, in a directory called `key` in the project root).

The API Gateway has now been configured correctly to handle the scenarios.

### Test Drive

Start the gateway using `npm start` in the project root. Once running, let's try to issue a couple of requests to it:

```shell
$ curl http://customers.company.com:8080 & curl http://customers.company.com:8080
$ [1] 4495
$ Unauthorized
$ [1]+  Done
$ Too many requests, please try again later.
```

You can see that the first request has been denied with `Unauthorized` status. That's because we didn't
provide any JWT with the request, so it didn't go through.

Moreover, the second request has been refused by the rate limiting policy, without event arriving to the
**authentication** phase. Policies are executed following the definition order in the configuration file.

Now grab any HTTP client and let's configure it to start an OAuth 2.0 authorization process against our API hosted in Auth0. We can grab all the necessary parameters going on _Applications_ -> _billings (Test Application)_ -> _Settings_ -> _Advanced Settings_ -> _Endpoints_

In my case, I am going to use `curl`, but you can use the one you prefer:

```bash
curl --request POST \
  --url https://bkrebs.auth0.com/oauth/token \
  --header 'content-type: application/json' \
  --data '{
    "client_id":"my-client-id-copied-from-auth0-application",
    "client_secret":"my-super-secret-copied-from-auth0-application",
    "audience":"http://orders",
    "grant_type":"client_credentials"
}'
```

Now, by simply copying the `access_token` attribute from the response, we will be able to communicate with the API through Express Gateway (you can verify the returned token by using [JWT.io](https://jwt.io/#debugger)). This is the token to be used in order to access the protected resource. So, just try to issue requests making sure that the token is now sent as a `Bearer` Authorization to the endpoint. The response should hopefully be `200`.

```bash
export JWT="ey...the-rest-of-the-token"
curl -H "Authorization: Bearer "$JWT http://customers.company.com:8080
```

## Conclusions

Thanks to [Express Gateway](https://express-gateway.io), we have moved two shared concerns (authentication and rate limiting) from the microservices to a centralized middleware that—no matter how many microservices we're going to have—it is going to behave in a consistent way.

We can now safely remove the code handling that from our microservices and assume that, if they're receiving a request, it's both **authenticated** and it passed the **rate-limit** checks. You now have **guarantees**.

However, this is just the tip of the iceberg.

The benefits of an API Gateway do not stop here. In this example, we've shown how it can make some checks on **inbound** requests, but it can also be used to modify the **outbound** responses.

In the initial part of the article, we were talking about the uniform API. An API Gateway could transform the response coming from a particular microservice so that the returned payload is consistent with the other microservices, even though the original data is shaped in a different way. Hopefully, we will explore this in a future article.

In the meantime, you can see some other interesting use cases on [Express Gateway website](http://www.express-gateway.io/resources/).


API Gateway: the Microservices Superglue

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

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

Ado Kukic

The need for application modernization is sweeping the software industry. It’s a challenge to know where to start, but we’ve got the quick wins that will get you on your way to modernization in no time.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Forrester Consulting analysis determines that using Auth0 can yield a 548% ROI and $3.7M in identity-related savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.</strong>
</div>

---

Traditionally, companies have built “monolithic” applications that addressed many business needs and intertwined business logic, user interfaces, and other components all in one. As the business grew, so did this application, adding more and more features, becoming harder and harder to maintain, deploy, test, and secure. These types of applications are commonplace today, however present numerous challenges to organizations looking to respond quickly, reliably, and efficiently to today’s changing business needs.

Monolithic applications slow organizations down. Long development cycles, high infrastructure and licensing costs, often single points of failure, and difficulty scaling are just some of the risks and challenges posed by these applications. Not to mention the difficulty of testing and fixing bugs, addressing vulnerabilities in such complex systems, and challenges integrating new technologies into the mix. In short, legacy architectures and monolithic applications are not compatible with today’s business demands.

Application modernization is the refactoring, repurposing or consolidation of legacy software to align it more closely with current business needs. Whether you call it application modernization, digital transformation, platform refactoring, or re-architecting the need to have software that meets the needs of your business is a priority. Nine out of ten decision makers claim that legacy software is keeping them from achieving their goals.

## Transitioning from Legacy Monoliths to Microservices

To remain competitive, organizations of all sizes are realizing that they need to be nimble, evolve fast, and maintain a healthy balance between customer expectations, business needs, and IT agility. Utilizing a microservices based architecture is a growing trend that helps achieve these goals. In this approach, applications are split into small sets of interconnected services based on business capability where each service has a well-defined boundary.

![Microservices](https://images.ctfassets.net/23aumh6u8s0i/18ttZOWoNAUgdI2sbKFdUP/4a46c78d26216ca770eae04087454988/microservices-example)

A good way to think about microservices is to think of them as individual lego pieces that come together to form something useful - like your ideal software. Each microservice can evolve independently based on the changing needs of the business. An easy way for organizations is to utilize SaaS vendors to fill in the feature and functionality gaps that are not core to the business, allowing the development teams to focus on building business value rather than re-inventing the wheel or so to speak.

The benefits of a microservices based architecture are clear. New features and functionality is much faster to develop, test, and deploy. Services can be deployed independent of each other and no single point of failure exists. Developer productivity and IT agility are increased, and the demands of business can be met head on. The challenge however is, knowing where to start.

## App Modernization Done Smart: Go For Quick Wins

Whether you are re-building your legacy application from scratch altogether or going about a phased restructuring of the legacy system, it’s ideal to offload critical parts of your application, which isn’t your core competency or expertise, externally to a cloud-based service. Using out-of-the box solutions will allow you to quickly implement key functionality. Some of the components that range from complex to almost impossible to build in-house but have various Software as a Service solutions are Payment Processing, Messaging, and Identity.

### Payment Processing
Payment systems have seen major disruptions in recent years and users are adapting fast. Whether it’s offering more payment methods such as cryptocurrency or direct debit payments, or ways to pay through contactless payments like Apple Pay or one-click buy, users are becoming accustomed to a seamless checkout experience. Payment processors like Stripe and Zuora are well known for providing payment platforms and APIs for enabling and managing all aspects of accepting payments via the Internet.

### Messaging

Given the number of communications channels available today, getting a consistent message to your users is harder than ever. Messaging is becoming more and more bi-directional and customers are increasingly engaging with organizations through social media, messaging bots, voice activated AI and more. Twilio is an example of a platform that provides messaging and communications services to handle SMS, voice, and other forms of communications to deliver consistent messaging across all channels.

![Identity](https://images.ctfassets.net/23aumh6u8s0i/4FP9tc3RggO7IwmtRgJlMn/9f722f14acd7c5eb5f2cc9783c58fe40/identity)

### Identity

Digital identity is at the core of any application - invisible yet crucial. An application of any nature requires digital identities, to [represent users and other entities interacting with it](https://auth0.com/user-management). With mobility, BYOD, IoT and smart entities becoming essential parts of the digital ecosystem, the “identity” piece of an application now has even more responsibilities and expectations than before.

Identity is complex. There’s username and password authentication, social connections, single sign on, and these are just ways to login. [Multifactor authentication](https://auth0.com/multifactor-authentication), [breached password detection](https://auth0.com/breached-passwords), anomaly detection, securing sensitive data like passwords, and many other topics comprise identity and having your engineers try to build, manage, and secure all these is like expecting an elephant to win a sprint race. You need to use their expertise at the right place.

Auth0 takes a completely new approach to providing a modularized, pluggable identity service by simplifying the most complex identity challenges with a powerful, secure, extensible, and easy to integrate platform. We will cover how Auth0 can solve your identity challenges in an upcoming article on modernizing your applications.

### Conclusion

Legacy monolithic applications are outdated and incompatible with today’s business needs and demands. Whether you are in the planning or re-architecting stage of your digital transformation, utilizing a microservices based approach alongside SaaS vendors is a sure-fire way to get quick wins and stay one step ahead of the competition.

Today’s blog post focused on introducing you to the quick and easy ways to get started on the  transformation from your legacy systems. In an upcoming post, we will dive deeper into how Auth0, as a Identity as a Service provider, can be a trusted partner in your modernization journey by solving your identity challenges and continuing to evolve as you do.


Getting a Competitive Edge with a Microservices Based Architecture

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

Protobuf, the binary format crafted by Google, surpasses JSON performance even on JavaScript environments like Node.js/V8 and web browsers.

Beating JSON performance with Protobuf

eHk3ciM

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

Group Manager, Developer Content

Kim Maida

Learn how to migrate real-world features of an AngularJS 1 application to a fresh Angular 2+ build (Part 1): setup, architecture, and components.

Migrating an AngularJS App to Angular - Part 1

b7e1e53144c06ecfdef91f0e4229a08a

Guest Author

Rafael Sacchi

How MVVM and VIPER can be good alternatives to the traditional MVC in iOS projects

Comparing MVVM and Viper architectures: When to use one or the other

Explore building an app in the functional front-end language Elm. Part 1 focuses on Elm history, architecture, syntax, and calling an API.

Creating Your First Elm App: From Authentication to Calling an API (Part 1)

001c9ddc5ceb9829b6aaf24f5d28502a

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

Senior Engineer

Sebastian Peyrott

Learn the basics of dependency management and data sharing for microservices architectures

Intro to Microservices, Part 4: Dependencies and Data Sharing

How the service registry works in a microservice-based architecture



In this post in the microservices series we will talk about *the service registry*. In [part 2](https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/) we discussed the *API gateway*, where we mentioned that services are **registered in a database**. The gateway dispatches requests according to the information contained in that database. Below we will explore how that database is populated and in which way services, clients and the gateway interact with it.

-----

## The service registry
The service registry is a database populated with information on how to dispatch requests to microservice instances. Interactions between the registry and other components can be divided into two groups, each with two subgroups:

1. Interactions between microservices and the registry (registration)
    1. Self-registration
    2. Third-party registration
2. Interactions between clients and the registry (discovery)
    1. Client-side discovery
    2. Server-side discovery

### Registration
Most microservice-based architectures are in constant evolution. Services go up and down as development teams split, improve, deprecate and do their work. Whenever a service endpoint changes, the **registry needs to know about the change**. This is what *registration* is all about: who publishes or updates the information on how to reach each service.

**Self-registration** forces microservices to interact with the registry by themselves. **When a service goes up, it notifies the registry**. The same thing happens when the service goes down. Whatever additional data is required by the registry must be provided by the **service itself**. If you have been following this series, you know that microservices are all about dealing with a *single concern*, so self-registration might seem like an anti-pattern. However, for simple architectures, self-registration might be the right choice.

![Self-registration](https://images.ctfassets.net/23aumh6u8s0i/793utSBFno7ZnfY2JPkHBW/fc270d61c5b71b09820ffb889cdbfc1d/self-registration-diagram)

**Third-party registration** is normally used in the industry. In this case, there is a **process or service that manages all other services**. This process polls or checks in some way which microservice instances are running and it automatically **updates the service registry**. Additional data might be provided in the form of per-service config files (or policy), which the registration process uses to update the database. Third-party registration is commonplace in architectures that use tools such as [Apache ZooKeeper](http://zookeeper.apache.org/) or [Netflix Eureka](https://github.com/Netflix/eureka) and other service managers.

![Third-party-registration](https://images.ctfassets.net/23aumh6u8s0i/1kXBlTgwxs0IHFqGTfwxXL/46d98df79b3262697685eb4c24bb55f8/third-party-registration-diagram)

Third-party registration also provides other benefits. For instance, what happens when a service goes down? A third-party registration service might be configured to provide safe fallbacks for services that fail. Other policies might be implemented for other cases. For instance, the service registry process might be notified of a high-load condition and automatically add a new endpoint by requesting the instantiation of a new microservice-process or VM. As you can imagine, these possibilities are critical for big architectures.

### Discovery
As you can imagine, discovery is the counterpart to registration from the point of view of clients. When a client wants to access a service, it must find out **where the service is located** (and other relevant information to perform the request).

**Client-side discovery** forces clients to **query a discovery service** before performing the actual requests. As happens with *self-registration*, this requires clients to deal with additional concerns other than their main objective. The discovery service may or may not be located behind the API gateway. If it is not located behind the gateway, balancing, authentication and other cross-cutting concerns may need to be re-implemented for the discovery service. Additionally, each client needs to know the fixed endpoint (or endpoints) to contact the discovery service. These are all disadvantages. The one big advantage is not having to code the necessary logic in the gateway system. Study this carefully when picking your discovery method.

![Client-side discovery](https://images.ctfassets.net/23aumh6u8s0i/2IzcnDuO6qsOYF96uP3ron/bdd6cdc6f18ec352928e19f53287f079/client-side-discovery-diagram)

**Server-side discovery** makes the **API gateway handle the discovery** of the right endpoint (or endpoints) for a request. This is normally used in bigger architectures. As all requests are directly sent to the gateway, all the benefits discussed in relation to it apply (see [part 2](https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/)). The gateway may also implement discovery caching, so that many requests may have lower latencies. The logic behind cache invalidation is specific to an implementation.

<include src="TweetQuote" quoteText="Server-side discovery makes the API gateway handle the discovery of the right endpoint for a request."/>

![Server-side discovery](https://images.ctfassets.net/23aumh6u8s0i/3FHSwwdLeOmBoLV5PvqNUM/07801774d85e25e330c74f01e5716a01/server-side-discovery-diagram)

## Example: A registry service
In [part 2](https://auth0.com/blog/2015/09/13/an-introduction-to-microservices-part-2-API-gateway/) we worked on a simple API gateway implementation. In that example we implemented dynamic dispatching of requests through queries to a service database. In other words, we implemented **server-side discovery**. For this example, we will extend our microservice architecture by working on the **registration** aspect. We will do so in two ways:

1. By providing a simple registration library that any development team can integrate into their microservice to perform **self-registration**.
2. By providing a sample [systemd unit](http://www.freedesktop.org/software/systemd/man/systemd.unit.html) that registers a service during startup or shutdown (**third-party registration** using systemd as a service manager).

> Why systemd? It has become the de-facto service manager in most Linux installations. There are other alternatives for managing your services but all require installation and configuration. For simplicity, we picked the one that comes preinstalled in most distros, and that is systemd.

### A registration library
Our microservice example from previous posts was developed for *node.js*, so our library will be for it as well. Here is the main logic of our library:

```javascript
module.exports.register = function(service, callback) {    
    if(!validateService(service)) {
        callback(new Error("Invalid service"));
    }

    findExisting(service.name, function(err, found) {
        if(found) {
            callback(new Error("Existing service"));
            return;
        }

        var dbService = new Service({
            name: service.name,
            url: service.url,
            endpoints: service.endpoints,
            authorizedRoles: service.authorizedRoles
        });

        dbService.save(function(err) {
            callback(err);
        });
    });
}

module.exports.unregister = function(name, callback) {
    findExisting(name, function(err, found) {
        if(!found) {
            callback(new Error("Service not found"));
            return;
        }

        found.remove(function(err) {
            callback(err);
        });
    });
}
```

Microservices that perform self-registration need to call these functions during startup or shutdown (including abnormal shutdowns). We have integrated this library into our existing microservice example in the following way (set the SELF_REGISTRY variable to any value to enable this function). Startup code:

```javascript
// Standalone server setup
var port = process.env.PORT || 3001;
http.createServer(app).listen(port, function (err) {
    if (err) {
        logger.error(err);
    } else {  
        logger.info('Listening on http://localhost:' + port);

        if(process.env.SELF_REGISTRY) {
            registry.register({
                name: serviceName,
                url: '/tickets',
                endpoints: [ {
                    type: 'http',
                    url: 'http://127.0.0.1:' + port + '/tickets'
                } ],
                authorizedRoles: ['tickets-query']
            }, function(err) {
                if(err) {
                    logger.error(err);
                    process.exit();
                }
            });
        }
    }
});
```

And shutdown code:

```javascript
function exitHandler() {
    if(process.env.SELF_REGISTRY) {
        registry.unregister(serviceName, function(err) {
            if(err) {
                logger.error(err);
            }
            process.exit();
        });
    } else {
        process.exit();
    }
}

process.on('exit', exitHandler);
process.on('SIGINT', exitHandler);
process.on('SIGTERM', exitHandler);
process.on('uncaughtException', exitHandler);
```

### Third-party registration using systemd
Our gateway example reads service information from a Mongo database. Mongo provides a command-line interface that we can use to register services during startup or shutdown. Here is a sample systemd unit (remember to disable the SELF_REGISTRY environment variable if you are using the sample microservice from this post):

```systemd
[Unit]
Description=Sample tickets query microservice

#Uncomment the following line when not running systemd in user mode
#After=network.target

[Service]
#Uncomment the following line to run the service as a specific user
#User=seba

Environment="MONGO_URL=mongodb://127.0.0.1:27018/test"

ExecStart=/usr/bin/node /home/seba/Projects/Ingadv/Auth0/blog-code/microservices/server.js
ExecStartPost=/usr/bin/mongo --eval 'db.services.insert({"name": "Tickets Query Service", "url": "/tickets", "endpoints": [{"type": "http", "url": "http://127.0.0.1:3001/tickets"}], "authorizedRoles": ["tickets-query"] });' 127.0.0.1:27017/test
ExecStopPost=/usr/bin/mongo --eval 'db.services.remove({"name": "Tickets Query Service"});' 127.0.0.1:27017/test

[Install]
WantedBy=default.target
```

Registration is handled by the *ExecStartPost* and *ExecStopPost* directives by calling the command-line Mongo client (included in all standard MongoDB installations).

Get the [code](https://github.com/auth0/blog-microservices-part3).

## Aside: use Auth0 for your microservices
Auth0 and microservices go hand-in-hand thanks to the magic of [JWT](http://jwt.io/). Check it out:

```javascript
var express = require('express');
var app = express();
var jwt = require('express-jwt');

var jwtCheck = jwt({
  secret: new Buffer('your-auth0-client-secret', 'base64'),
  audience: 'your-auth0-client-id'
});

app.use('/api/path-you-want-to-protect', jwtCheck);

// (...)
```

Your *client id* and *client secret* are available through the Auth0 dashboard. Create a new account and [start hacking](https://auth0.com/docs)!

## Conclusion
The service registry is an essential part of a microservice-based architecture. There are different ways of handling registration and discovery that fit different architectural complexities. Consider the pros and cons described above for each alternative before committing to one. In Part 4 we will study service dependencies in detail and how to manage them efficiently.


An Introduction to Microservices, Part 3: The Service Registry

Learn about API gateways and how they work in a microservice-based architecture



In this post in the microservices series we will talk about API gateways and how they can help us solve some important concerns in a microservice-based architecture. We described these and other issues in our [first post](https://auth0.com/blog/2015/09/04/an-introduction-to-microservices-part-1/) in the series.

-----

## What is an API gateway and why use it?

In all service-based architectures there are several concerns that are shared among all (or most) services. A microservice-based architecture is not an exception. As we said in the first post, microservices are developed almost in isolation. Cross-cutting concerns are dealt with by upper layers in the software stack. The API gateway is one of those layers. Here is a list of common concerns handled by API gateways:

- Authentication
- Transport security
- Load-balancing
- Request dispatching (including fault tolerance and service discovery)
- Dependency resolution
- Transport transformations

### Authentication
Most gateways perform some sort of authentication for **each request** (or series of requests). According to **rules** that are specific to each service, the gateway either routes the request to the requested microservice(s) or returns an error code (or less information). Most gateways add authentication information to the request when passing it to the microservice behind them. This allows microservices to implement **user specific logic** whenever required.

### Security
Many gateways function as a single entry point for a public API. In such cases, the **gateways handle transport security** and then dispatch the requests either by using a different secure channel or by removing security constraints that are not necessary inside the internal network. For instance, for a RESTful HTTP API, a gateway may perform **"SSL termination"**: a secure SSL connection is established between the clients and the gateway, and proxied requests are then sent over non-SSL connections to internal services.

<include src="TweetQuote" quoteText="Many gateways function as a single entry point for a public API."/>

### Load-balancing
Under high-load scenarios, gateways can **distribute requests among microservice-instances** according to custom logic. Each service may have specific scaling limitations. Gateways are designed to balance the load by taking these limitations into account. For instance, some services may scale by having multiple instances running under different internal endpoints. Gateways can dispatch requests to these endpoints (or even request the dynamic instantiation of more endpoints) to handle load.

### Request-dispatching
Even under normal-load scenarios, gateways can provide custom logic for dispatching requests. In big architectures, **internal endpoints are added and removed** as teams work or new microservice instances are spawned (due to topology changes, for instance). Gateways may work in tandem with service registration/discovery processes or databases that describe how to dispatch each request. This provides exceptional **flexibility** to development teams. Additionally, **faulty services** can be routed to backup or generic services that allow the request to complete rather than fail completely.

### Dependency resolution
As microservices deal with very specific concerns, some microservice-based architectures tend to become "chatty": to perform useful work, many requests need to be sent to many different services. For convenience and performance reasons, gateways may provide **facades** ("virtual" endpoints) that internally are **routed to many different microservices**.

### Transport transformations
As we learnt in the first post of this series, microservices are usually developed in isolation and development teams have great flexibility in choosing the development platform. This may result in microservices that return data and use transports that are **not convenient for clients** on the other side of the gateway. The gateway must perform the necessary **transformations** so that clients can still communicate with the microservices behind it.

## An API gateway example
Our example is a simple node.js gateway. It handles HTTP requests and forwards them to the appropriate internal endpoints (performing the necessary transformations in transit). It handles the following concerns:

### Authentication
Authentication using **JWT**. A single endpoint handles initial authentication: /login. User details are stored in a Mongo database and access to endpoints is restricted by roles.

```javascript
/*
 * Simple login: returns a JWT if login data is valid.
 */
function doLogin(req, res) {
    getData(req).then(function(data) {
        try {
            var loginData = JSON.parse(data);
            User.findOne({ username: loginData.username }, function(err, user) {
                if(err) {
                    logger.error(err);
                    send401(res);
                    return;
                }

                if(user.password === loginData.password) {
                    var token = jwt.sign({
                        jti: uuid.v4(),
                        roles: user.roles
                    }, secretKey, {
                        subject: user.username,
                        issuer: issuerStr
                    });

                    res.writeHeader(200, {
                        'Content-Length': token.length,
                        'Content-Type': "text/plain"
                    });
                    res.write(token);
                    res.end();                
                } else {
                    send401(res);
                }
            }, 'users');
        } catch(err) {
            logger.error(err);            
            send401(res);
        }
    }, function(err) {
        logger.error(err);            
        send401(res);
    });
}

/*
 * Authentication validation using JWT. Strategy: find existing user.
 */
function validateAuth(data, callback) {
    if(!data) {
        callback(null);
        return;
    }

    data = data.split(" ");
    if(data[0] !== "Bearer" || !data[1]) {
        callback(null);
        return;
    }

    var token = data[1];    
    try {
        var payload = jwt.verify(token, secretKey);
        //Your custom validation logic goes here.
        if(!payload.jti || revokedTokens[payload.jti]) {
            logger.debug('Revoked token, access denied: ' + payload.jti);
            callback(null);
        } else {        
            callback({jwt: payload});                
        }
    } catch(err) {
        logger.error(err);
        callback(null);
    }
}
```

> Disclaimer: the code shown in this post is not production ready. It is used just to show concepts. Don't copy paste it blindly :)

### Transport security
Transport security is handled through **TLS**: all public requests are received first by a reverse nginx proxy setup with sample certificates.

### Load balancing
Load-balancing is handled by **nginx**. See the sample [config](https://github.com/sebadoom/auth0/blob/master/microservices/gateway/nginx.conf).

### Dynamic dispatching, data aggregation and failures
Requests are **dynamically dispatched** according to a configuration stored in a database. Two types of requests are supported: HTTP and AMQP.

Requests also support the **aggregation strategy** for splitting requests among several microservices: a single public endpoint may aggregate data from many different internal endpoints (microservices). All returned data is in JSON format. See this excellent [post by Netflix](http://techblog.netflix.com/2013/01/optimizing-netflix-api.html) on how this strategy helped them achieve better performance. Also check our [post on Falcor](https://auth0.com/blog/2015/08/28/getting-started-with-falcor/) which allows for easy data fetching from many sources.

![Aggregation strategy](https://images.ctfassets.net/23aumh6u8s0i/5czB8vNeCDzOlE0SO9SYif/83a87ab75bd2bbe0a9a7d353ef33613d/aggregation)

**Failed internal requests** are handled by logging the error and returning less information than requested.

```javascript
/*
 * Parses the request and dispatches multiple concurrent requests to each
 * internal endpoint. Results are aggregated and returned.
 */
function serviceDispatch(req, res) {
    var parsedUrl = url.parse(req.url);

    Service.findOne({ url: parsedUrl.pathname }, function(err, service) {
        if(err) {
            logger.error(err);
            send500(res);
            return;
        }

        var authorized = roleCheck(req.context.authPayload.jwt, service);
        if(!authorized) {
            send401(res);
            return;
        }       

        // Fanout all requests to all related endpoints.
        // Results are aggregated (more complex strategies are possible).
        var promises = [];
        service.endpoints.forEach(function(endpoint) {   
            logger.debug(sprintf('Dispatching request from public endpoint ' +
                '%s to internal endpoint %s (%s)',
                req.url, endpoint.url, endpoint.type));

            switch(endpoint.type) {
                case 'http-get':
                case 'http-post':
                    promises.push(httpPromise(req, endpoint.url,
                        endpoint.type === 'http-get'));
                    break;
                case 'amqp':
                    promises.push(amqpPromise(req, endpoint.url));
                    break;
                default:
                    logger.error('Unknown endpoint type: ' + endpoint.type);
            }            
        });

        //Aggregation strategy for multiple endpoints.
        Q.allSettled(promises).then(function(results) {
            var responseData = {};

            results.forEach(function(result) {
                if(result.state === 'fulfilled') {
                    responseData = _.extend(responseData, result.value);
                } else {
                    logger.error(result.reason.message);
                }
            });

            res.setHeader('Content-Type', 'application/json');
            res.end(JSON.stringify(responseData));
        });
    }, 'services');
}
```

### Role checks
```javascript
var User = userDb.model('User', new mongoose.Schema ({
    username: String,
    password: String,
    roles: [ String ]
}));

var Service = servicesDb.model('Service', new mongoose.Schema ({
    name: String,
    url: String,
    endpoints: [ new mongoose.Schema({
        type: String,
        url: String
    }) ],
    authorizedRoles: [ String ]
}));

function roleCheck(jwt_, service) {
    var intersection = _.intersection(jwt_.roles, service.authorizedRoles);
    return intersection.length === service.authorizedRoles.length;
}
```

### Transport and data transformations
**Transport transformations** are performed to convert between HTTP and AMQP requests.

### Logging
**Logging** is centralized: all logs are published to the console and to an internal message-bus. Other services listening on the message-bus can take action according to these logs.

Get the full [code](https://github.com/sebadoom/auth0/tree/master/microservices/gateway).

## Aside: How webtask and Auth0 implement these patterns?

We told you about [webtasks](https://webtask.io) in our first post in the series. As webtasks *are* microservices they too run behind a gateway. The webtasks gateway handles authentication, dynamic-dispatching and centralized logging so that you don't have too.

* For authentication, [Auth0](https://auth0.com) is the issuer of tokens and webtask will verify those tokens. There is a trust relationship between them so that tokens can be verified.
* For real time logging webtask implemented a stateless resilient [ZeroMQ architecture](http://tomasz.janczuk.org/2015/09/from-kafka-to-zeromq-for-log-aggregation.html) which works across the cluster.
* For dynamic-dispatching, there is a custom-built Node.js proxy which uses [CoreOS etcd](https://github.com/coreos/etcd) as a pub-sub mechanism to route webtasks accordingly.

![Webtask](https://images.ctfassets.net/23aumh6u8s0i/26xA1D0RD9OZNmwuVPCCFw/6395ac83c869db331a701848bfa0e59f/webtask)

## Conclusion
API gateways are an essential part of any microservice-based architecture. Cross-cutting concerns such as authentication, load balancing, dependency resolution, data transformations and dynamic request dispatching can be handled in a convenient and generic way. Microservices can then focus on their specific tasks without code-duplication. This results in easier and faster development of each microservice.


"architecture"