alisha-tingle

Alisha Tingle is a Senior Customer Advocate at Auth0 with 10 years of client-facing experience in the tech industry. In her role, she focuses on accelerating self-service customer growth, expanding self-service reach to developers, and generating enterprise growth. Outside of work, Alisha is passionate about teaching pilates and spending time with her family.

Senior Customer Advocate, DLG

Alisha Tingle

Discover how Auth0 is improving B2B plan flexibility with new Enterprise Connection options and M2M token add-ons based on developer feedback.

At Auth0, we do not just collect feedback; we act on it. Over the last few months, you have shared specific challenges regarding plan flexibility and the "price cliffs" that can occur when scaling. Our Customer Advocate team has taken those insights directly to our product teams to ensure our self-service B2B plans evolve alongside your actual needs.

*Note: If you want to dive into the full technical details and pricing of our B2B plan changes, you can [read the main announcement here](https://auth0.com/blog/auth0-b2b-plans-upgraded)*

Here are three major updates driven by your requests that are launching this month:

## 1. Proof of Concepts: Enterprise Connection on the Free Plan

**The Request:** You told us that testing an Enterprise Connection for a demo or POC felt like a significant barrier when you were not yet in production. You needed a way to validate your integration before committing to a paid tier.

* **The Change:** We have updated the **Free Plan** to include **one Enterprise Connection.**  
* **The Impact:** You can now build, test, and prove the value of your integration to stakeholders without any upfront cost.

## 2. Scaling Incrementally: Add-On Enterprise Connections for B2B Essentials

**The Request:** You highlighted that jumping from B2B Essentials to B2B Professional just to add a fourth or fifth connection felt like too large a leap for a growing business.

* **The Change:** We are introducing **Add-on Enterprise Connections** for the B2B Essentials Plan.  
* **The Impact:** You can now scale at your own pace. If you land a new client requiring SAML or OIDC, you can simply add that specific connection to your existing plan.

## 3. Machine-to-Machine (M2M) Token Add-Ons

**The Request:** Many of you needed to expand your backend service communication but didn't necessarily need the full suite of "Professional" features. You asked for the ability to buy only what you use.

* **The Change:** We are enabling **M2M Token Add-ons** for the B2B Essentials Plan.
* **The Impact:** This add-on provides the technical flexibility to increase service-to-service capacity without the overhead of a full plan upgrade.

## Help Us Build the Future of Auth0

These changes aren't just "new features" — they are the direct result of your input. Whether you are a nonprofit scaling your impact or a startup launching your MVP, your feedback is the most effective tool we have for making Auth0 better.

We are committed to keeping this dialogue open. If you see a way we can improve our plans or features to better support your build, we want to hear it.

**Continue to share your thoughts with us at:** [customeradvocate@auth0.com](mailto:customeradvocate@auth0.com).



You Talked, We Listened: How Your Feedback Shaped Our New B2B Plans


andrea-chiarelli

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

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

Principal Developer Advocate

Andrea Chiarelli

Dive into the world of Non-Human Identities (NHIs). Learn how they differ from traditional machine identities, their role in AI, the top security challenges, and the best practices for securing your machine-to-machine interactions.

You’ve just pushed the latest feature and your Continuous Integration (CI) pipeline begins its operations. A build server spins up, fetches dependencies, runs a battery of tests, packages your application into a container, and pushes it to a registry. Then, a deployment service picks it up, authenticates to your cloud provider, and rolls out the new version to a Kubernetes cluster.

In this whole sequence, how many humans were involved? Zero. It was a coordinated dance of machines, services, and APIs talking to each other—a world of machine-to-machine (M2M) communication. Each one of these actors—the CI server, the deployment tool, the services running in your cluster—needs an identity. They need to prove who they are and what they’re allowed to do.

Welcome to the world of **Non-Human Identities (NHIs)**. If you're a developer building anything that talks to an API (so, basically, everyone), you're already dealing with them, whether you call them that or not. They are the invisible workforce of your applications, and failing to manage them properly is like leaving the front door of your digital office wide open.

In this article, we'll dive deep into the world of NHIs. We’ll cover what they are, how they differ from the old-school "machine identities," why they are the next frontier in the age of AI, and most importantly, how to manage them following the best practices.

## Aren't These Just Machine Identities?

If you’ve been around for a while, you might be thinking, “Isn’t this just a fancy new name for machine identities, service accounts, or application identities?” And you’re not wrong—they are all part of the same family. But the term "Non-Human Identity" highlights a crucial evolution in *context* and *risk*.

In the not-so-distant past of on-premise data centers, the world was simpler. The network was the castle, and a big firewall was its moat. Most identities inside the castle walls belonged to humans. Machine-to-machine communication was often trusted implicitly because it was all happening "inside." A service account was often just a static, long-lived credential saved in a properties file.

Then came the cloud, microservices, and Infrastructure as Code (IaC). The castle walls dissolved. Your "network" is now a dynamic, multi-cloud, multi-region environment where services, serverless functions, and third-party APIs constantly interact. In this new world, **identity is the new perimeter**.

This shift is what makes NHIs different. It’s not just about a script needing a password anymore. We're talking about a massive and intricate ecosystem of identities, including:

* **Microservices** using [OAuth 2.0 client credentials](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) to call each other.  
* **IoT devices** on a factory floor authenticating with client certificates to stream telemetry data.  
* **Terraform scripts** using a cloud provider identity to provision infrastructure.  
* **GitHub Actions** needing a temporary identity to deploy code to a staging environment.

The sheer volume and ephemeral nature of these identities have exploded. We're moving from a world where we managed a handful of service accounts to one where we might manage hundreds of machine identities for a single application. This scale changes everything.

So, while the concept is rooted in machine identity, "Non-Human Identity" is the modern framing that acknowledges this new reality. It emphasizes a distinct and elevated risk profile that demands a dedicated and sophisticated management strategy.

## Non-Human Identities and the Rise of AI

Just as we’re starting to understand how to manage identities for microservices and CI/CD pipelines, a new player has entered the game: Artificial Intelligence. AI agents and models are rapidly becoming the most powerful and autonomous non-human actors in our systems. And every single one of them needs an identity.

Imagine an AI-powered customer support bot. To be useful, it needs to access customer data, check order statuses, and maybe even issue refunds. It can't do any of that without authenticating to various internal APIs. Or consider a developer-assisting AI tool that can write code, run tests, and fix bugs. To operate, it needs access to your source code repositories, your build environment, and your project management tools.

Giving AI agents identities is non-negotiable for three key reasons:

* **Security and Least Privilege**: An AI agent is just another piece of software. If it’s compromised, you need to contain the blast radius. Tying an AI agent to a specific, narrowly-scoped identity allows you to enforce the [Principle of Least Privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) (PoLP). The support bot should only be able to *read* order information, not delete the entire database. The coding assistant should only have access to the specific repositories it's assigned to work on. Without a distinct identity, you're forced to grant it overly broad permissions, which is a recipe for disaster.  
* **Auditability and Accountability**: When an AI tool takes an action, you *must* have a record of it. If an AI agent autonomously decides to scale down a production database cluster because of a perceived anomaly, you need to know which agent did it, why, and on whose authority it was acting. An NHI provides that clear, immutable audit trail. It’s the difference between saying "a system did something" and "AI-agent-734, acting on behalf of the 'cost-optimization' policy, performed this action at 3:15 AM."  
* **Contextual Operation**: AI agents often act on behalf of a human user. For example, an AI assistant scheduling meetings for you needs temporary, delegated access to your calendar. This is a perfect use case for the [OAuth 2.0 framework](https://auth0.com/docs/authenticate/protocols/oauth), where the AI agent (the client) is given a token to access a resource (your calendar) with a limited scope (reading and writing) on your behalf. Its own identity is used to request this access, and the resulting token is bound to both its identity and your permissions.

In essence, **AI agents are the ultimate NHIs**. They are autonomous, powerful, and will soon outnumber every other type of machine identity in your organization. Building a solid foundation for NHI management is now a prerequisite for safely adopting and scaling AI.

## Top Security Challenges with NHIs

Because NHIs are so pervasive and powerful, they are a prime target for attackers. They are the keys to the kingdom, and unfortunately, we often leave them lying around. The [OWASP Foundation](https://owasp.org/) has identified this growing threat and created the [Non-Human Identities Top 10 project](https://owasp.org/www-project-non-human-identities-top-10/), which outlines the most critical risks. Let's break down some of the biggest challenges you'll face as a developer.

### Secret leakage

This is the original sin of NHI security. A developer, in a hurry, hardcodes an API key, a password, or a private certificate directly into the source code or a configuration file:

```javascript
// src/config/db.js  - PLEASE, NEVER DO THIS!
const dbConfig = {
  host: 'prod.database.server.com',
  user: 'admin',
  password: 'Password123!', // <-- This is a leaked secret
  database: 'main_db'
};
```

The code gets committed to a Git repository. Maybe the repository is private today, but what about tomorrow? What if it's accidentally made public? Or what if a disgruntled employee clones it before they leave? There are tools that scan public GitHub repositories and find thousands of hardcoded secrets every single day. Once a secret is in your Git history, you must consider it compromised. Forever.

### Over-privileges

The Principle of Least Privilege is simple: an identity should only have the absolute minimum permissions required to do its job. Yet, it is violated constantly, and we are all guilty of it.

It’s late, you’re debugging a permission issue, and for a "temporary" fix, you give a service account *admin* or *root* access. You promise yourself you’ll fix it later, but later never comes.

Imagine a microservice whose only job is to resize user-uploaded profile pictures. It needs to read the original image from a storage bucket and write the resized version back. That's it. But in a rush, it’s given full read, write, and *delete* permissions to the *entire* storage system. Now, a vulnerability in that single, simple image-resizing service can be exploited to wipe out all of your company's data. This is how minor bugs become catastrophic breaches.

### Improper offboarding

Humans have a clear lifecycle. When an employee leaves, a well-defined offboarding process kicks in: their laptop is returned, their accounts are disabled, their access is revoked.

What about NHIs? A developer spins up a virtual machine for a temporary project. They create a service account for it with a set of credentials. The project ends, and the VM is deleted, but nobody remembers to revoke the credentials for the service account. That identity, and its permissions, now exist in perpetuity—an "undead" identity waiting to be discovered and abused. This is especially dangerous for long-lived credentials like static API keys, which can remain active and forgotten for years.

### Unmanaged NHIs and identity sprawl

The ease of creating identities in cloud environments is a double-edged sword. A developer needs to test an API, so they generate a new API key. A new microservice is deployed, so it gets its own service account. A data science team needs access to a database, so a new set of credentials is created.

Multiply this across hundreds of developers and thousands of services, and you get NHI sprawl. You end up with a vast, untracked landscape of identities. Nobody knows who owns them, what they’re used for, whether they're still needed, or how powerful they are. They are the digital equivalent of a drawer full of unlabeled keys. You don't know which ones open the front door until a burglar tries them all.

## Best Practices for Managing Non-Human Identities

We've outlined the dangers that can affect Non-Human Identities. Now for the good part: How do we fix it? Managing NHIs effectively isn't about finding one magic tool; it's about adopting a security-first mindset and a set of robust practices.

### Centralize and automate credential management

First and foremost: **get secrets out of your code**. Hardcoding credentials is a non-starter. All secrets—API keys, database passwords, TLS certificates—must be stored and managed in a dedicated, secure system. So apply these two basic principles:

* **Use a secret vault**: Tools like HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, or Azure Key Vault are designed for this. Your application should fetch its credentials from the vault at runtime. This way, the secret is never stored on disk or in your Git history.  
* **Embrace short-lived, dynamic secrets**: The best way to reduce the risk of a leaked credential is to make it useless as quickly as possible. Instead of static, long-lived passwords, use your vault to generate *dynamic* secrets. For example, when your application needs to connect to the database, it can request credentials from Vault that are unique, have the exact permissions needed, and automatically expire after, say, one hour. If the credential leaks, its window of utility for an attacker is tiny.

### Enforce the Principle of Least Privilege

This needs to be a core part of your development workflow, not an afterthought. An identity should only have the absolute minimum permissions required to do its job. The following practices help you apply the principle:

* **Prefer access tokens over static API keys**: A fundamental step in enforcing PoLP is to move away from traditional static API keys. These keys often act as a single, long-lived credential that grants all-or-nothing access, making granular control difficult. In contrast, [**OAuth 2.0 access tokens**](https://auth0.com/docs/secure/tokens/access-tokens) are far superior as they are designed to be **short-lived**, can be restricted to specific **audiences**, and can carry fine-grained permissions. This allows you to enforce PoLP on every single API request. Read [this article to learn more about access tokens vs. API keys](https://auth0.com/blog/why-migrate-from-api-keys-to-oauth2-access-tokens/) and [this one for specific risks in the AI context](https://auth0.com/blog/api-key-security-for-ai-agents/).  
* **Leverage OAuth 2.0 scopes**: When securing your APIs, don't just validate that a token is present. Define and enforce fine-grained scopes. A client requesting an access token should only ask for the [scopes](https://auth0.com/docs/get-started/apis/scopes) it absolutely needs. For example, a service that analyzes user data should request the `user:read` scope, not a generic `user` scope that implies write access. Your authorization server should enforce this, and your API should check the token's scope before executing an action. This article can help you understand [how to apply PoLP with OAuth 2.0 access tokens](https://auth0.com/blog/oauth2-access-tokens-and-principle-of-least-privilege/).  
* **Use IAM Roles and Policies**: In cloud environments, use Identity and Access Management (IAM) roles. Instead of assigning permissions directly to a resource (like a VM, a container, or a serverless function), you assign them a role. The resource can then assume this role to automatically receive temporary, short-lived credentials. This completely removes the need to manage and rotate long-lived secrets in your code.

### Implement strong, modern authentication mechanisms

Not all authentication methods are created equal. A static API key sent in a header is better than nothing, but it's essentially a bearer token that can be stolen and replayed. We can do much better:

* **Use Asymmetric Client Authentication**: Move away from shared secrets. Instead, use methods based on public-key cryptography.  
  * **Mutual TLS (mTLS)**: The client has its own TLS certificate and proves its identity by presenting it to the server during the TLS handshake. This provides strong, two-way authentication at the transport layer. Learn more [about mTLS here](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-mtls).  
  * **Private Key JWTs**: When authenticating to an OAuth 2.0 token endpoint, the client creates a JWT, signs it with its own private key, and sends that as its assertion. The authorization server verifies the signature using the client's public key, proving the client's identity without ever sending a secret over the wire. Learn [how to authenticate with Private Key JWTs in Auth0](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt).  
* **Bind Tokens to the Sender**: A standard bearer access token is like cash: whoever holds it can use it. **Sender-constrained tokens** fix this. They cryptographically bind the access token to the specific client that requested it. Technologies like [Demonstrating Proof-of-Possession (DPoP)](https://auth0.com/blog/protect-your-access-tokens-with-dpop/) require the client to prove it possesses the private key on every API call, making a stolen token useless to an attacker.

### Automate the entire identity lifecycle

To solve the "undead" identity problem and eliminate sprawl, you must tie the lifecycle of an NHI to the lifecycle of the resource it serves.

* **Manage Identity as Code**: Use Infrastructure as Code (IaC) tools like Terraform or **Pulumi** not just to define your servers and databases, but also to define their identities, roles, and permissions.  
* **Automated Provisioning and Deprovisioning**: When a new microservice is defined in your Terraform code, the script should also create its service account, grant it the necessary IAM role, and configure it to fetch secrets from your vault. Crucially, when you tear down the service, the script should also **revoke its permissions and delete its identity**. This ensures no orphaned identities are left behind.

### ​Keep a human in the loop for high-stakes operations

Full automation is great, but some actions are too critical to be left entirely to machines. Deploying to production, deleting a database, or approving a large financial transaction are events where you want explicit, real-time human approval. This is where ["human-in-the-loop" protocols](https://auth0.com/blog/secure-human-in-the-loop-interactions-for-ai-agents/) become essential.

[Client Initiated Backchannel Authentication](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba) (CIBA) is an OpenID Connect protocol that provides a secure and interoperable way for Non-Human Identities to request authorization from users.

Consider a CI/CD pipeline preparing for a production deployment. Instead of relying on a static, high-privilege secret, the pipeline initiates a CIBA flow. This action triggers a push notification to the on-call engineer's mobile device, prompting: "Approve deployment of v2.5.1 to production?" The engineer then verifies the request and authenticates using biometrics. Upon approval, the CIBA provider issues a short-lived, single-use token to the pipeline, enabling it to complete the deployment.

This approach significantly mitigates risk. The Non-Human Identity (the pipeline) never possesses a persistent high-privilege credential. Each critical action is gated by human approval, and a clear audit trail is established, linking the automated process directly to the approving individual. CIBA serves as a crucial safety net for your most critical automated workflows.

## The Future is Non-Human

The shift from human-centric to machine-centric interactions is one of the most significant transformations in modern technology. The number of non-human identities is already exploding, and with the rise of AI, this trend is only accelerating.

As developers, we are on the front lines. We are the ones creating these identities every day. Treating them as second-class citizens with static, overly-permissive, and forgotten credentials is no longer an option. It's a critical security failure waiting to happen.

By embracing practices like secrets management, least privilege, strong authentication, and lifecycle automation, we can tame this complexity. We can build systems that are not only powerful and efficient but also secure and resilient. The future of your applications depends on the invisible identities that run them. It’s time to bring them out of the shadows.

Here is a summary of the challenges posed by NHIs and best practices for managing them:

![A summary chart showing the top security challenges of non-human identities (secret leakage, over-privileges, improper offboarding, identity sprawl) and the best practices for managing them (centralized vaults, least privilege, strong authentication, and lifecycle automation).](https://images.ctfassets.net/23aumh6u8s0i/1i1S5VYiELX4m04i7r6eb1/6815e6bcb8cf849ea542c85bf8a54cd8/securing-non-human-identities.png)

Dealing With Non-Human Identities

Learn how to enable your customers to customize the login experience of your B2B SaaS application and integrate it into their systems by accessing your APIs.

Throughout this series, we've journeyed through [the foundational aspects of B2B identity](https://auth0.com/blog/b2b-saas-identity-challenges-the-foundations/), including multi-tenancy and onboarding, then delved into [granular access control with RBAC, ABAC, and ReBAC](https://auth0.com/blog/b2b-saas-identity-challenges-granular-access-control/), and most recently tackled [the critical demands of enterprise integration and advanced security](https://auth0.com/blog/b2b-saas-identity-challenges-enterprise-integration-and-security/). Your Business-to-Business (B2B) Software-as-a-Service (SaaS) application is now robust, secure, and ready for demanding clients.

However, the ultimate success of a B2B application often hinges on its adaptability and seamless integration into a customer's environment. This means more than just functionality; it means brand consistency and programmatic access.

In this concluding article, we will explore the essential aspects of customization and extensibility, focusing on how to tailor the user experience and secure your backend APIs for machine-to-machine communication, ensuring your application is truly integrated and personalized for every customer.

## Branding and User Experience Customization

Your B2B customers will often expect a seamless brand experience, even on the login page. They want their users to feel like they are interacting directly with their application, not an external provider. This is also reflected in your application’s login pages: **How can I customize the login pages to match my customers' corporate identities?**

To be honest, in my previous experience in building a B2B SaaS application, we had a couple requests of this type. At that time, we decided to implement an additional set of login and reset password pages. Basically, they were customized versions of our default login page. As a result, we had to maintain more code and keep in sync with any updates we were going to apply to the default pages. It worked with some additional maintenance, but only because we had very few such requests. As a developer, you know that the more code you have, the more trouble you may get.

[Auth0's Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is designed for extensive customization, allowing you to maintain a consistent brand experience across all your customer organizations. Customizing Auth0 Universal Login for individual Organizations is a powerful feature for B2B SaaS applications, allowing you to provide a truly branded experience for each of your customers. You can customize it at different levels: 

* With a **no-code approach**, which allows you to change the logo and colors of the login page.  
* With an **advanced approach** by customizing the Universal Login page template with Liquid.  
* With more powerful control by using the **Advanced Customizations** for Universal Login feature, which gives you control over every pixel of your Universal Login experience.

But that’s not all. Auth0 also allows you to customize the emails that users receive from the platform very easily.

> Read the following documents to learn more about customizing the login experience for your customers:
> 
> * [Customize Universal Login](https://auth0.com/docs/customize/login-pages/universal-login)  
> * [Advanced Customization for Universal Login](https://auth0.com/docs/customize/login-pages/advanced-customizations)  
> * [Customize Prompts and Email Templates for Organizations](https://auth0.com/docs/manage-users/organizations/create-first-organization#customize-prompts-and-email-templates)

## API Security for Your SaaS Backend

In the context of customization, it is likely that some customers will ask you to access your application's APIs to connect them with their systems, for example, to exchange data automatically. The challenge now becomes: **How can I protect my backend API so that my customer’s applications can only access their data securely?**

Auth0 enables you to implement this feature by providing Machine-to-Machine (M2M) Access for Organizations. To determine the Organization your API is scoped to, you will find an `org_id` claim in the access token sent by the customer’s application.

> Here is more information about securing your API in the context of Organizations:
> 
> * [Machine-to-Machine (M2M) Access for Organizations](https://auth0.com/docs/manage-users/organizations/organizations-for-m2m-applications)  
> * [Work with Tokens and Organizations](https://auth0.com/docs/manage-users/organizations/using-tokens)

## Real-time User Lifecycle Management with Event Streams

Beyond offering your customers direct API access and UI customization, your B2B SaaS application may need to react to changes in user identity in real time. Imagine needing to synchronize user data with your CRM, trigger welcome emails based on signup events, or update internal billing systems when a user's status changes. Relying on polling APIs or manual data exports is inefficient and can lead to inconsistencies.

The challenge here is: **How can I reliably and efficiently propagate user lifecycle events from Auth0 to my internal systems or third-party applications?**

[Auth0 Event Streams](https://auth0.com/docs/customize/events) provide a solution to this. Event Streams allow you to subscribe to a real-time feed of events generated by Auth0, such as:

* User creation  
* User updates (e.g., profile changes)  
* User deletions  
* Password changes  
* Login successes and failures

These events are delivered to a destination of your choice, such as Amazon EventBridge or an HTTP endpoint. This enables you to build event-driven architectures, ensuring that your other services are always up-to-date with the latest identity information without complex polling logic. By leveraging Event Streams, you can automate critical workflows and maintain data consistency across your B2B SaaS ecosystem.

> Learn more about Auth0 Event Streams:
> 
> * [Auth0 Event Streams](https://auth0.com/docs/customize/events)  
> * [Discover User Lifecycle Changes via Event Streams – Now in Early Access](https://auth0.com/blog/user-lifecycle-changes-via-event-streams-in-early-access/)

# Conclusion

Our journey through the identity landscape of B2B SaaS has traversed from the fundamental need for user authentication to the sophisticated demands of enterprise integration and bespoke logic. What might initially seem like a peripheral concern — simply letting users log in — quickly reveals itself as the bedrock upon which the security, scalability, and ultimate success of your B2B application are built.

We started by understanding that **B2B identity is fundamentally different** from Business-to-Customer (B2C), centered around organizations rather than just individual users. We then progressed through key developmental phases: from [laying the foundation with multi-tenancy support](https://auth0.com/blog/b2b-saas-identity-challenges-the-foundations/) to exploring [different approaches for granular access control](https://auth0.com/blog/b2b-saas-identity-challenges-granular-access-control/); from tackling the non-negotiable [integration needs for enterprise customers](https://auth0.com/blog/b2b-saas-identity-challenges-enterprise-integration-and-security/) to facing the customization and extensibility requirements.

By embracing a robust identity solution from the outset, you’re not just solving a technical problem; you're laying a strategic foundation for your B2B SaaS application to thrive in a competitive and security-conscious market. Your focus can remain on delivering exceptional business value, confident that your users and their data are in safe hands.

I hope this series has provided valuable insights and practical solutions for navigating the complex world of identity in B2B SaaS.

Ready to secure your B2B SaaS and accelerate your development with a trusted identity partner? Explore [Auth0's comprehensive offerings](https://auth0.com/b2b-saas) and see how they can transform your approach to identity and access management.



B2B SaaS Identity Challenges: Customization and Extensibility

eric wu

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

Staff Product Marketing Manager, Auth0

Eric Wu

Edgar Chirivella

I'm an engineer who focuses on creating high-performance solutions to address real-world problems.

When I'm not coding, you can find me playing musical instruments or dancing.

Software Engineer II

Machine-to-Machine Access for Organizations reaches General Availability (GA), unlocking SaaS APIs for developers

Within Auth0 by Okta, the [Organizations](https://auth0.com/docs/manage-users/organizations) feature allows business-to-business (B2B) software-as-a-service (SaaS) providers to manage their partners and customers and to customize the ways that end users access their applications.

Through a programmatic toolset of APIs and SDKs or directly on the Auth0 dashboard, B2B SaaS providers can use Organizations to:

* Represent their business customers and partners in Auth0 and manage their membership
* Configure branded, federated login flows for each business
* Build administration capabilities into their products, using Organizations APIs, so that those businesses can manage their own organizations

Until now, Organizations was limited to *user*-based authentication in browser-based flows — but with the General Availability (GA) of Machine-to-Machine Access for Organizations, B2B SaaS providers can now define the Organization(s) that a given app can access on its own behalf, via the Client Credentials Flow, for each API. This change allows B2B SaaS providers to open up their APIs, enabling machine-to-machine (M2M) use cases while allowing access to sensitive data and operations of each Organization to be restricted to authorized parties.

## Leading Use Cases

Let’s start with a quick look at what’s going on behind the scenes when a customer wants to interact with a B2B SaaS API via Client Credentials Flow. As depicted in the figure below:

1. First, the customer application gets an access token; with Machine-to-Machine Access for Organizations, the token request communicates new context through the `organization` parameter, and the token itself includes the corresponding `org_id `and `org_name`
2. Next, the customer application calls your API
3. Your API server validates that the target Organization for the requests matches the `org_id/name` included in the access token

![alt_text](https://images.ctfassets.net/23aumh6u8s0i/7miaBmd81uEVLmiy2jshWR/22cd99d26b516d7f9564438ffb4341f5/01_saas.png)

Straightforward and familiar, right?

Indeed, by design, these are exactly the claims used in existing user-based Organizations login flows, allowing B2B SaaS providers to implement the same authorization logic for their APIs across both user and machine-to-machine access.

Now, let’s look at the two primary use cases that this additional context enables, using our fictitious [Travel0 company](https://auth0.com/docs/manage-users/organizations/organizations-overview#sample-scenario).

### Open up APIs to third-party applications

Using Auth0 Organizations and the Management API, Travel0 offers a self-service portal where customers can create and manage their own organizations.

Travel0 wants to make it easy for customers to build bots to help end users find and purchase adventures. Accordingly, as part of this portal, Travel0 allows customers to register their applications (e.g., the bots) to consume the Travel0 API on their own behalf.

In this use case, cross-organization access must be correctly controlled so that applications belonging to a particular organization can only access that organization’s data.

Machine-to-machine access for Organizations allows Travel0’s self-service portal to configure Client Credentials access for customer applications by associating them with a specific organization for each API.

<img src="https://images.ctfassets.net/23aumh6u8s0i/55EYuibQQxOqdyZTyPa2iZ/a0c8fe244c7529b84557c9630ec6c39f/02_saas.png" alt="SaaStart"  width="500" >

As a result, the applications of Travel0’s customer *Org X* can only access the Travel0 API within the scope of *Org X*.

![alt_text](https://images.ctfassets.net/23aumh6u8s0i/52X8GLuhURskYrc7ffrYCr/5189f8c7556abea89d01f86d3aae6de9/03_saas.png)

To accommodate aggregators, Travel0 could also configure access from a single application to several organizations.

### Isolation of organizations for internal applications

Travel0 also has internal processes and CLI tools that need to access the Travel0 API using the Client Credentials Flow. To apply a unified access control strategy on the API, Travel0 wants requests from its own applications to be scoped to a specific organization so that only the right data is accessed in each case.

![alt_text](https://images.ctfassets.net/23aumh6u8s0i/5iwaR7wLph96ViCMEH3Tz1/bb2dc31d783483e9d7a99f10198fd14b/04_saas.png)

Travel0’s services aren’t bound to an individual customer, and Machine-to-Machine Access for Organizations enables Travel0 to configure an application to access any organization for each API using the Client Credentials Flow.

## How Does It Work?

### Extending Client Grants

You may have noticed that the use cases outlined above rely on knowing which Organizations an application is authorized to access.

To support this, we’ve built on the existing concept of [Client Grants](https://auth0.com/docs/api/management/v2/client-grants/get-client-grants), which represent the APIs an application is authorized to access via the Client Credentials Flow. You can now use the Client Grants (1) to specify whether an application can or cannot access an API in the context of an Organization and (2) to control which Organizations the Application can access, with two options:

1. Allow an application to access one (or several) specific organizations. This is especially relevant for the first use case.
2. Allow an application to access all organizations. This is especially relevant for the second use case.

Let’s take a look at the details!

### Configuring Machine-to-Machine Access for Organizations

To get started, you'll need to create one or multiple APIs and Organizations. After that, the process consists of three steps for each Application:

1. Create an Application and enable it to use the Client Credentials flow. To learn more, read [Create Applications](https://auth0.com/docs/get-started/auth0-overview/create-applications) and [Update Grant Types](https://auth0.com/docs/get-started/applications/update-grant-types).
2. Create and configure one or more Client Grants establishing the APIs that can be accessed by the Application.
3. Associate each Client Grant with one or more Organizations.

To create a Client Grant between the Application and an API, simply enable the toggle that can be found in the `APIs` tab under Application details:

![alt_text](https://images.ctfassets.net/23aumh6u8s0i/7AuaxeC6y2TSIn6kVkiOPi/8b0b71bf6a1b209a9c0715a1fb8afebf/05_saas.png)

The Client Grant will now have two extra properties:

* **Organization Support: **Configures whether the Client Credentials requests will `deny`, `allow`, or `require` the `organization` parameter. When configuring the Client Grant using Management API, this field will be called `organization_usage`.
* **Allow Machine-to-Machine access to any organization:** Configures whether the Client Credentials requests will allow any Organization within the tenant. By default, access will have to be granted organization by organization. When configuring the Client Grant using Management API, this field will be called `allow_any_organization`.

The Client Grant can also be created and configured for Organization support using Management API:

```
curl -X POST --location 'https://{auth0Domain}/api/v2/client-grants' \
--header 'Content-Type: application/json' \
--header 'Authorization: ••••••' \
--data '{
    "client_id": "0aFYaz2svVw7a5wGuNvvmaiW0pa2Fpga",
    "audience": "https://example-api",
    "scope": ["create:posts", "read:posts", "update:posts", "delete:posts"],
    "organization_usage": "require",
    "allow_any_organization": false
}'
```

If `allow_any_organization` has been set to `true`, you’re all set — jump to [Getting a machine-to-machine token in the context of an Organization](#Getting-a-machine-to-machine-token-in-the-context-of-an-Organization) to discover the next steps. On the other hand, if you only want to allow access to specific organizations, please continue reading.

### Granting access to concrete Organizations

Once the Client Grant has been configured, it’s time to authorize it to access a specific Organization. To do so, navigate to the organization you would like to grant access to and go to the new `Machine to Machine Access` tab. Click on the `Add Access` button and follow the steps to select the application and the API to which your Organization will have access. This will create an Organization Client Grant, which enables this permission.

![alt_text](https://images.ctfassets.net/23aumh6u8s0i/5obFwj3Qrm6G1PO3NppmIn/4b095179337103291548d1a275a00aa3/06_saas.png)

The Organization Client Grants can also be created using Management API. Three new scopes control the access to this new resource:

* create: `organization_client_grants`
* read: `organization_client_grants`
* delete: `organization_client_grants`

This is an example request that will grant access to the  `org_Kpu9Q89v57IaZJVK` Organization for the Application and API defined in the `cgr_kapBApAJV3jYdfQq` Client Grant.

```
curl -X POST --location 'https://{auth0Domain}/api/v2/organizations/org_Kpu9Q89v57IaZJVK/client-grants' \
--header 'Content-Type: application/json' \
--header 'Authorization: ••••••' \
--data '{
    "grant_id": "cgr_kapBApAJV3jYdfQq"
}'
```

### Getting a machine-to-machine token in the context of an Organization

Now that everything has been configured, we’re all set to use the feature. Let’s make a Client Credentials request, passing an `organization` parameter:

```
curl --location 'https://{auth0Domain}/oauth/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=0aFYaz2svVw7a5wGuNvvmaiW0pa2Fpga' \
--data-urlencode 'client_secret=••••••' \
--data-urlencode 'audience=https://example-api' \
--data-urlencode 'organization=org_Kpu9Q89v57IaZJVK'
```

The response received from Auth0 is as follows:

```
{
  "access_token": "eyJhbGciOi...XptRHPuRkw",
  "scope": "create:posts read:posts update:posts delete:posts",
  "expires_in": 86400,
  "token_type": "Bearer"
}
```

Let’s decode the `access_token` payload:

```
{
  "iss": "https://{auth0Domain}/",
  "sub": "0aFYaz2svVw7a5wGuNvvmaiW0pa2Fpga@clients",
  "aud": "https://example-api",
  "iat": 1730308095,
  "exp": 1730394495,
  "scope": "create:posts read:posts update:posts delete:posts",
  "org_id": "org_Kpu9Q89v57IaZJVK",
  "gty": "client-credentials",
  "azp": "0aFYaz2svVw7a5wGuNvvmaiW0pa2Fpga"
}
```

As you can see, the `access_token` now contains the Organization ID in the `org_id` claim.

### Default Organization

If you have any restrictions preventing you or your customers from sending an `organization` parameter in the Client Credentials request or want to use a standard OAuth library that does not support Auth0 Organizations, you can set a Default Organization in the corresponding Auth0 Application, which will be used in all the subsequent Client Credentials requests:

```
curl --location --request PATCH 'https://{auth0Domain}/api/v2/clients/0aFYaz2svVw7a5wGuNvvmaiW0pa2Fpga \
--header 'Content-Type: application/json' \
--header 'Authorization: ••••••' \
--data '{
  "default_organization": {
    "organization_id": "org_Kpu9Q89v57IaZJVK",
    "flows": ["client_credentials"]
  }
}'
```

## Additional Resources

Ready to use Machine-to-Machine Access for Organizations? Dive into our comprehensive [documentation](https://auth0.com/docs/manage-users/organizations/organizations-for-m2m-applications) for details.

Need a quick refresher on Auth0 Organizations? Watch our [demo video](https://www.okta.com/customer-identity/#organizations) and browse the [documentation](https://auth0.com/docs/manage-users/organizations).

Want a hands-on experience with essential Customer Identity functionalities in B2B SaaS apps? Check out our reference B2B SaaS app [SaaStart](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-saastart/).

Your B2B SaaS App Just Got Better

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

Staff Developer Advocate

Juan Cruz Martinez

Learn how to use the Auth0 Python SDK to query and store user data in this step-by-step tutorial.

The **Auth0 Dashboard** offers a wide range of tools for managing your application's authentication and authorization. You can create and delete users, assign roles, ban IPs, and much more. Although it's convenient to manage users directly from the dashboard, there may be scenarios where you need control from within your application.

Say, for example, that you want to store UI preferences such as dark/light mode settings or the user’s preferred theme directly on the user’s profile so that, independently from which device they connect to your application, they will have their favorite settings ready.

In scenarios like this, where your application directly processes and manages users' information, you can use the [Auth0 Management API](https://auth0.com/docs/api/management/v2), which allows you to work with users' data and programmatically access most features available in the Auth0 Dashboard.

In this article, we’ll explore how to use the Auth0 Management API from Python applications using the Auth0 Python SDK to read and store information about users, and at the end, we’ll build a lottery system to pull a random lucky user from the system.

## Accessing the Auth0 Management API

The Auth0 Management API allows you to programmatically create, access, update, and delete resources from your Auth0 tenant. It is an API built for back-end servers or trusted parties to perform administrative tasks such as user management or DevOps.

You can access the [Auth0 Management API](https://auth0.com/docs/api/management/v2) via HTTP requests directly or use one of the SDKs we provide for such a purpose. In any scenario, you’ll need a few things before starting the management API.

- **Auth0 account.** If you don’t have one already, you can <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account</a>.
- **A machine-to-machine application**
- **A short-lived token** for production access to the API

### Set up your Auth0 account

Once you have an <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Auth0 account</a> you can navigate the the [Auth0 Dashboard](https://manage.auth0.com/#/applications) and access your applications list.

![Auth0 application's dashboard](https://images.ctfassets.net/23aumh6u8s0i/3QEFGVXK0EW2UlGNfaU8jK/bebbcfa41f716523f000c45b6ba863a0/auth0-ma-create-app.png)

Once on the page, click on the “Create Application” button on the top right and enter the following information:

- **Name**: A descriptive name for your application, e.g., User Management App
- **Application Type:** Because we’ll be connecting to this Auth0 application from another system, e.g., your Python application, you need to select “Machine to Machine Applications.”

Then click on “Create”.

![Creating a machine to machine application](https://images.ctfassets.net/23aumh6u8s0i/6F51sEhfGP6lOGXmldL8s7/c274315a617ae8f42c5278e61e91aa41/auth0-ma-create-app-details.png)

In the following dialog, you’ll select which API you’ll authorize this application to access. In our case, you’ll choose the **Auth0 Management API** already available in your tenant. Before authorizing the API, Auth0 will list all the permissions associated with it. There are many available. For our use case, you'll authorize the following: `read:users`, `update:users`, `read:users_app_metadata`, and `update:users_app_metadata`. Finally, click on “Authorize”.

![Assigning permissions to an API](https://images.ctfassets.net/23aumh6u8s0i/6eWpQ9QUTcOT9gT2gb5Do0/b4605872f7de2186401c747f044cd21e/auth0-ma-authorize-api.png)

> You can update your application’s permissions at any point from the Auth0 dashboard.

### Get a Test Token from the Auth0 Dashboard

Now you are ready to test your Auth0 Management API. Visit the API entry on the [Auth0 Dashboard](https://manage.auth0.com/#/apis).

![Auth0 API dashboard](https://images.ctfassets.net/23aumh6u8s0i/4ap0GxPP1WrjfaueqzfovG/150363bf27096f8bda6997aa5f49ced2/auth0-ma-apis.png)

Once there, click on the Auth0 Management API and head on to the “Test” tab. After a few seconds, you’ll see a screen like the following:

![Getting API Access Token from the Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/5HJDsh75FgjFB5fbfFhSLN/38ed227a790b4be7632ecaaa32c0af9e/auth0-ma-api-test.png)

Before continuing, ensure you have the correct application selected on the drop-down; next, you can copy your `access_token` from the UI. Make sure to copy just the value without the quotes. You’ll need this token next.

You can test your API directly on the [API documentation page](https://auth0.com/docs/api/management/v2). You can explore and test all the API endpoints there, though we’ll focus on the list [user’s endpoint](https://auth0.com/docs/api/management/v2#!/Users/get_users) for now.

![Auth0 Management API docs](https://images.ctfassets.net/23aumh6u8s0i/6tZBiNtrWUf8fmGeji8FUS/112e38d8ae05bf8376b402b9ccc04699/auth0-ma-list-users.png)

On the “List or Search Users” section, you’ll find the different parameters you can use to query users. For now, we’ll leave them all to the default values, and if you look to the right of the screen, you’ll find a button, “Test Endpoint”, at the end of the section.

The button is currently disabled as the documentation page is not authorized to make calls to the management API yet. To test endpoints on the documentation page, you'll need to provide an API Token using the "Set API Token" on the top right of the screen.

![Set API Token to make API calls](https://images.ctfassets.net/23aumh6u8s0i/6UO3HenV2TLVG6xTjVVFsF/24eaa6acff4b6728849588e434f7a202/auth0-ma-set-api-token.png)

Next, paste your access token from the Auth0 dashboard into the modal window and click “Set Token”. If you copied the token value correctly and tried the endpoint again, you should now see your list of users.

![Example response for the list users API endpoint](https://images.ctfassets.net/23aumh6u8s0i/5fse9EYIe0xXci2oPtxDXU/2980f08b1cdca89640fc4a0e6f787fa1/auth0-ma-list-users-list.png)

## How to Consume the Auth0 Management API with Python

To make your life easier when working with the Auth0 Management API, Auth0 offers a set of tools in multiple programming languages. In the case of Python, we have the [Auth0 Python SDK](https://github.com/auth0/auth0-python) that allows for easy and convenient access to all the features in the management API.

To consume the Auth0 Management API with Python, we will use the Auth0 Python SDK. To install it, run the following command:

```bash
pip install auth0-python
```

After installing the library, you must get a short-lived access token and initialize it programmatically. You’ll need information about your Auth0 tenant domain and the machine-to-machine application you created before. You’ll need the “Client Id” and the “Client Secret”, which can be found on the [Auth0 Dashboard](https://manage.auth0.com/#/applications) under your application’s settings.

![Domain, Client Id, and Client Secret are available in the app settings](https://images.ctfassets.net/23aumh6u8s0i/72vTRKfXxiFPXNIxTAGZkb/9be57cda028c928c9091d00c638c2d00/auth0-ma-app-settings.png)

Once you can access these values, you set the Auth0 SDK with the following code:

```python
from auth0.authentication import GetToken
from auth0.management import Auth0

domain = 'mydomain.auth0.com'
client_id = 'myclientid'
client_secret = 'myclientsecret'

get_token = GetToken(domain, client_id, client_secret=client_secret)
token = get_token.client_credentials('https://{}/api/v2/'.format(domain))
mgmt_api_token = token['access_token']
auth0 = Auth0(domain, token['access_token'])

auth0 = Auth0(domain, mgmt_api_token)
```

And finally, if you, for example, want to list your users, you can run:

```python
users = auth0.users.list()
print(users)

# Example Output
{
    "start": 0,
    "limit": 25,
    "length": 25,
    "users": [
        {
            "created_at": "2023-07-14T11: 01: 09.493Z",
            "email": "###.#####@###.com",
            "email_verified": False,
            "identities": [
                {
                    "connection": "Username-Password-Authentication",
                    "provider": "auth0",
                    "user_id": "64b12af5c157759fdf791d4d",
                    "isSocial": False
                }
            ],
            "name": "###.#####@###.com",
            "nickname": "###.#####",
            "picture": "https: //s.gravatar.com/avatar/.........png",
            "updated_at": "2023-07-14T11:01:09.493Z",
            "user_id": "auth0|64b12af5c157759fdf791d4d",
            "last_login": "2023-07-14T11:01:09.491Z",
            "last_ip": "2a01:c23:c480:7900:6c:a31c:9c46:f435",
            "logins_count": 1
        },
        ...
    ],
    "total": 40
}
```

## Updating Users’ Profile Information

Auth0's user profiles store basic information about each user, including a unique identifier, name, contact details, and identifying information such as their profile picture. This information is helpful during the authentication process, but you may also require additional information as the user logs in, such as:

- User preferences, such as the application’s theme or color scheme, etc.
- Flags that the user opt-in in the application, such as notification preferences, getting started tutorial completion, etc.
- Others, such as the last read announcement, subscription status, and more.

Auth0's user profiles can store such information as metadata, which your app can access once the user logs in successfully. Although your app could store this information in its own storage system, utilizing Auth0's user profile metadata offers the advantage of immediate availability during and after the login process.

A significant benefit of using metadata is that it is associated with the user's account rather than tied to a specific device. This ensures that if a user switches between the mobile and web versions of your app, their settings and preferences based on metadata will remain consistent across both versions.

Auth0 supports two types of users’ metadata:

- **User metadata:** refers to information the user can see and update, such as user preferences and settings
- **App metadata:** refers to information about the user that is only accessible by the application, for example, feature flags, last read announcement, and more.

Let’s now write a Python script to update the user’s name and metadata to store their preferred theme and an application flag enabling extra features on the user’s account.

```python
# As we did before, we need to get an instance of the Auth0 client
from auth0.authentication import GetToken
from auth0.management import Auth0

domain = 'mydomain.auth0.com'
client_id = 'myclientid'
client_secret = 'myclientsecret'

get_token = GetToken(domain, client_id, client_secret=client_secret)
token = get_token.client_credentials('https://{}/api/v2/'.format(domain))
mgmt_api_token = token['access_token']
auth0 = Auth0(domain, token['access_token'])

auth0 = Auth0(domain, mgmt_api_token)

# Next, we can proceed to update the user's name using the user's id
user_id = '{YOUR_USER_ID}'
auth0.users.update(user_id, {
    'name': 'My name is...'
})

# We can also update the user's metadata
auth0.users.update(user_id, {
    'user_metadata': {
    'theme': 'light'
  },
  'app_metadata': {
    'experimental_features': True
  }
})

# Let's add some more information to see what the end result is
auth0.users.update(user_id, {
    'user_metadata': {
    'font_size': '16px'
  },
  'app_metadata': {
    'notifications': False
  }
})

# Query the user information
user_info = auth0.users.get(user_id)
print(user_info)

# Output
{
    "created_at": "2023-07-14T09:22:19.151Z",
    "email": "###.#####@###.com",
    "email_verified": False,
    "identities": [
        {
            "connection": "Username-Password-Authentication",
            "user_id": "64b113cb6a989b51063087ce",
            "provider": "auth0",
            "isSocial": False
        }
    ],
    "name": "My name is...",
    "nickname": "###.#####",
    "picture": "https://s.gravatar.com/avatar/...",
    "updated_at": "2023-07-14T11:29:53.139Z",
    "user_id": "auth0|64b113cb6a989b51063087ce",
    "user_metadata": {
        "theme": "light",
        "font_size": "16px"
    },
    "app_metadata": {
        "experimental_features": True,
        "notifications": False
    }
}
```

Note that when calling the `update` method, we don’t need to send all the information about the user, but only those fields we would like to change. This makes working with data really simple, as we don’t need to worry about overriding critical fields. Even on the `user_metadata` and `app_metadata` fields, we don’t need to send the full JSON we want to store but rather the individual key-value pairs, Auth0 will automatically merge the existing values with the new ones.

We can also access the user information from the [user’s entry in the Auth0 Dashboard](https://manage.auth0.com/#/users).

![Viewing user's profile and metadata information in the Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/12wH1mxn2Od5hcOQ7SwOTG/d8f45e0725c7eaeeab916bf94a6b9723/auth0-ma-list-user-data.png)

## Query Users

Whether you are building a user dashboard, gathering some statistics, or needing your users’ information to process in your application, the Auth0 Management API and the Auth0 Python SDK allow you to access the information you need and how you need it.

Previously we used the method `users.list` to retrieve a list of all users in the Auth0 database, which may be all that you need. However, that method offers advanced query functions worth knowing and exploring.

First, let’s start with paginating results. By default, paging is disabled. However, you can quickly specify the page and the number of items per page you want to retrieve with these two parameters:

- **page**: Page index of the results to return. The first page is 0.
- **per_page**: Number of results per page.

Here is an example querying the second page of users, up to ten users per page

```python
users = auth0.users.list(page=1, per_page=10)
```

Another common parameter in usage is sorting operations. For this purpose, the SDK exposes the `sort` parameter to specify the field and direction. For example:

```python
users = auth0.users.list(sort="name:1")
```

Use `field:order` where the order is `1` for ascending and `-1` for descending.

Lastly, one of the most powerful functions is the ability to perform complex queries, for example, getting all the users whose names start with `J` or even filtering by custom metadata, listing all the users that prefer the dark mode theme. Auth0 uses [Lucene query string syntax](http://www.lucenetutorial.com/lucene-query-syntax.html) for those complex queries, though there are some limitations, as some query types cannot be used on metadata fields, for details see [Searchable Fields](https://auth0.com/docs/users/search/v3/query-syntax#searchable-fields).

Example 1: List all users whose name starts with `J`

```python
users = auth0.users.list(search_engine='v3', q='name:j*')
```

Example 2: List all users that prefer dark mode

```python
users = auth0.users.list(search_engine='v3', q='user_metadata.theme:dark')
```

You can also mix multiple search criteria, for example:

```python
users = auth0.users.list(search_engine='v3', q='name=j* AND user_metadata.theme:dark')
```

To learn more about how to form queries, check the [Lucene query string syntax](http://www.lucenetutorial.com/lucene-query-syntax.html).

## Selecting a Random User

For the events we attended this year, we created a fun game using Python, Flask, and Auth0 to give some fabulous prizes away to lucky contestants. The game was pretty simple. It consisted of people signing up for our application at events like PyCon. During the day, users registered to the game using the Auth0 Universal Login page. Then, when it was time to give prizes away, we would use the same Flask application to withdraw a lucky winner. The winner would then get a special award from Auth0.

To select the lucky winner, we built a special page using the `users.list` method. There was a caveat: the same user couldn’t win twice. The way we solved it was by using `app_metadata` to store information about the users who had already won and then using Lucene syntax to filter them out when pulling for a new winner.

Though not critical for our situation, we wanted the script to be efficient and thus not pull the whole user’s database, as it could be quite extensive, so instead, we first pulled the API to know how many users were in total with a minimum query, and then we accessed a random user from the pull and extracted only that user’s information.

```python
import random

# List only 1 user just to retrieve the total number of users that match the given query
user_count = auth0.users.list(per_page=1, include_fields=False, search_engine='v3', q='NOT app_metadata.winner:true')["total"]

# Then, use the same trick of listing one user per page to get a random page between 0 and the total number of users
# That resulting user is our lucky winner
winner_user = auth0.users.list(page=random.randint(0, user_count - 1), per_page=1, include_fields=False, search_engine='v3', q='NOT app_metadata.winner:true')['users'][0]

# Before we do anything else with the results, update the user's metadata to reflect them as winner
auth0.users.update(winner_user.get('user_id'), {
    "app_metadata": {
        "winner": True
    }
})
```

## Summary

Today you learned about the Auth0 Management API and how to work with it from the documentation as well as from any Python application. You also learned how to work with user information, user, and app metadata, and how to query users from the Auth0 database using simple and more complex queries.

Thanks for reading!

Use the Auth0 Python SDK for Querying and Storing Users’ Data

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

How to set up non-interactive apps using the client credentials grant and Auth0 to perform IoT device, CLI tool, and more machine to machine API authorization.



Many times, a secure, authorized communication channel between different parts of an autonomous system is required. Think of two backend services from different companies communicating through the internet. For these cases, OAuth 2.0 provides the [client credentials grant](https://tools.ietf.org/html/rfc6749#section-4.4) flow. In this post, we will take a look at how the client credentials grant from [OAuth 2.0](https://tools.ietf.org/html/rfc6749) can be used with Auth0 for [machine to machine (M2M) communications](https://auth0.com/machine-to-machine).

<include src="TweetQuote" quoteText="Learn to use machine to machine authorization with Auth0!"/>

[Get the code](https://github.com/auth0-samples/auth0-api-auth-samples) for the sample in this post.

---

<AmpContent>
<amp-youtube
    data-videoid="9ivMf15wl1A"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div class='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/9ivMf15wl1A' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## Machine to Machine Communications
There are many parts of a system where machine to machine communications make sense: service to service, daemon to backend, CLI client to internal service, [IoT](https://auth0.com/blog/javascript-for-microcontrollers-and-iot-part-1/) tools. The key aspect of these communications lies on the fact that the element to establish trust in the system is the _client_. What does this mean? In contrast to usual systems where an authorization process attempts to establish trust by authorizing _a user_, in this case what must be authorized and trusted is the client. In other words, there is no need for a user to interact with the system to authenticate, rather the system must authenticate and authorize the _client_. To be clear, in this case, the client is simply an application, process or even an autonomous system. For these scenarios, typical authentication schemes like username + password, social logins, etc. don't make sense.

The [client credentials grant] from OAuth 2.0 attempts to fulfill the need for these scenarios. In the client credentials grant, the client holds two pieces of information: the client ID and the client secret. With this information, the client can request an access token for a protected resource.

![Client Credentials Grant](https://images.ctfassets.net/23aumh6u8s0i/3bJ99s5VK6bB85bS9eiBOf/26c0da9d6918894b66e44a87c9b5edf2/client-credentials-grant)

1. The client makes a request to the authorization server sending the `client ID`, the `client secret`, along with the `audience` and other claims claims.
2. The authorization server validates the request, and, if successful, sends a response with an access token.
3. The client can now use the access token to request the protected resource from the resource server.

Since the client must always hold the client secret, this grant is only meant to be used in _trusted_ clients. In other words, clients that hold the _client secret_ must always be used in places where there is no risk of that secret being misused. For example, while it may be a good idea to use the client credentials grant in an internal daemon that sends reports across the web to a different part of your system, it cannot be used for a public tool that any external user can download from GitHub.

## Client Credentials Grant
The client credentials grant is very simple to use. The following are the relevant HTTP requests:

```
POST https://<YOUR_AUTH0_DOMAIN>/oauth/token
Content-Type: application/json
{
  "audience": "<API_IDENTIFIER>",
  "grant_type": "client_credentials",
  "client_id": "<YOUR_CLIENT_ID>",
  "client_secret": "<YOUR_CLIENT_SECRET>"
}
```

A successful authorization request results in a response like the following:

```
HTTP/1.1 200 OK
Content-Type: application/json
{
  "access_token": "eyJz93a...k4laUWw",
  "token_type": "Bearer",
  "expires_in": 86400
}
```

In Auth0, to use the client credentials grant, you can [create a new "machine to machine" application from the dashboard:](https://auth0.com/docs/applications/machine-to-machine)

![Machine to Machine in the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/77BJOc4RrLIp07FLtdX5SV/491323d54c787864e5ce322c225bd6b8/2-create)

A machine to machine application requires the selection of at least one API. This is the API that gets selected through the `audience` claim in the HTTP request above.

![Select API in the Auth0 Dashboard](https://images.ctfassets.net/23aumh6u8s0i/4TEwKo6fti1umT59Ui5fHp/c4da3c10ee49b6c2784e731b9d25ea91/3-select-api)

You can create audiences for your APIs and protected resources in the [API](https://manage.auth0.com/#/apis) section of the Auth0 Dashboard. You can enable or disable these APIs in the `APIs` tab of your application.

### Granular Permissions in Auth0
Thanks to the use of [Hooks in Auth0](https://auth0.com/docs/hooks), it is very easy to have granular permissions for [machine to machine communications](https://auth0.com/machine-to-machine). Using Node.js code, you are able to customize the actions of Auth0 and extend the functionality of the Auth0 base platform.

<include src="TweetQuote" quoteText="With Auth0 Hooks, you can have powerful granular permissions even for machine to machine authorization!"/>

The Auth0 utility (auth0) is part of `wt-cli`. More information on `wt-cli` can be [found here](https://webtask.io/docs/wt-cli) and configuring the wt-cli for use can be [found here](https://manage.auth0.com/#/tenant/webtasks).

If you wanted to create a Hook, this is how the CLI process would go:

Scaffold the sample code from Auth0:

```bash
auth0 scaffold -t pre-user-registration > file.js
```

Then create the Hook:

```bash
auth0 create -t pre-user-registration --name my-extension-1 -p auth0-default file.js
```

Along with this process, the [Auth0 Management Dashboard](https://auth0.com/docs/hooks/dashboard) also provides an interface for managing your Hooks. This dashboard can do any of the CLI functions except for the "Identify and get log data from a Hook".

If you don't need the flexibility of Hooks, you can still achieve a level of granularity with scopes. These can be enabled on a per API and per application/client basis.

## Common Use Cases for M2M Communications
In this section, we will take a look at common scenarios where M2M communications might make sense.

### Backend-to-Backend (Services/Daemons)
This is one of the most common scenarios. Let's say you have different internal services that produce data in the form of logs. You are storing those logs locally in your own data warehouse. However, as part of your policies, you also want those logs to be stored offsite in a cold storage solution. You send those logs over the internet to the cold storage service in a different cloud provider. To authorize log storage from different services in your network, you use the client credentials grant, giving each client a client ID and a client secret.

![Machine to Machine Logging](https://images.ctfassets.net/23aumh6u8s0i/yAy6yj6lBIkpSajKLnNdM/3d9c1f1aeffc1c33e20a5a982dc43e7d/3-backend-to-backend)

What about other common services like job schedulers, daemons, continuous processes? These are also great scenarios where machine to machine authorization makes sense. Say you have a job scheduler that lives in your network but on a different cloud provider that offers a great deal for GPU processing. You only want your authorized clients to make use of the service. For this reason, you use the client credentials grant and only authorize those client IDs that you want to allow.

### Internet of Things Devices
The rise of [Internet of Things devices](https://auth0.com/blog/javascript-for-microcontrollers-and-iot-part-1/) makes a great case for machine to machine solutions. Many (if not most) of IoT devices are small, autonomous, specialized devices that collect and send data to a server. Let's say you have a fleet of small IoT devices that you use to collect data on the number of cars that are parked in your parking lot. You have many devices that are continuously reporting data to a central server. These devices communicate over WiFi. To avoid intrusions, and even though your WiFi network is password protected, you use the client credentials grant, giving each IoT device its own client ID and client secret. These devices are trusted: you set them up and no-one else can interact with them.

### CLI clients
When systems become big, automation starts to make more and more sense. Many tasks that are repetitive, but that still require an administrator to supervise them, start to become scripts. These scripts are run when administrators need to run them. Since these scripts interact with sensitive parts of a company's architecture, they usually have some sort of protection. In these cases, administrators may choose to create CLI apps that have the necessary rights to perform the actions, but that are only available in certain computers, like their own, or in mainframes. In these cases, the client credentials grant also makes sense. These CLI apps are trusted, but they also need access to sensitive parts of a system. Protecting access to sensitive parts of the system by requiring the client ID and client secret can be a solution.

## Code Example: Gift Deliveries App
If you are interested in seeing code that can apply to a real-world scenario, we have a sample app just for that purpose. The [Gift Deliveries app](https://github.com/auth0-samples/auth0-api-auth-samples/tree/master/machine-to-machine) shows how two backend services from the same company can interact securely with the use of the client credentials grant.

In this app, one service, the [World Mappers API](https://github.com/auth0-samples/auth0-api-auth-samples/tree/master/machine-to-machine/worldmappers-api-nodejs) exposes an API that can be used to find coordinates, addresses, and directions; while another service, the [Gift Deliveries Service](https://github.com/auth0-samples/auth0-api-auth-samples/tree/master/machine-to-machine/giftdeliveries-nodejs), uses the `World Mappers API` to get directions from one point to the destination address (to send a gift).

![Gift Deliveries App](https://images.ctfassets.net/23aumh6u8s0i/3cGGMA4TtCldPmX8vPe2j9/96f1aedf84c2eab44a86b783d5e74823/4-gift-deliveries-app)

Both of these services run in the internal network of an online shop, therefore, the `Gift Deliveries` client is a trusted client, which allows it to use the client credentials grant.

If you take a look at the `giftdeliveries-nodejs/index.js` file you will see the code that gets an access token using the client credentials grant:

```javascript
var getAccessToken = function(callback) {
  if (!env('AUTH0_DOMAIN')) {
    callback(new Error('The AUTH0_DOMAIN is required in order to get an access token (verify your configuration).'));
  }

  logger.debug('Fetching access token from https://' + env('AUTH0_DOMAIN') + '/oauth/token');

  var options = {
    method: 'POST',
    url: 'https://' + env('AUTH0_DOMAIN') + '/oauth/token',
    headers: {
      'cache-control': 'no-cache',
      'content-type': 'application/json'
    },
    body: {
      audience: env('RESOURCE_SERVER'),
      grant_type: 'client_credentials',
      client_id: env('AUTH0_CLIENT_ID'),
      client_secret: env('AUTH0_CLIENT_SECRET')
    },
    json: true
  };

  request(options, function(err, res, body) {
    if (err || res.statusCode < 200 || res.statusCode >= 300) {
      return callback(res && res.body || err);
    }

    callback(null, body.access_token);
  });
}
```

If you want to run this app, <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account</a>, clone the [repository](https://github.com/auth0-samples/auth0-api-auth-samples) and follow the [README](https://github.com/auth0-samples/auth0-api-auth-samples/blob/master/machine-to-machine/README.md).

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

## Conclusion

[Machine to machine communications](https://auth0.com/machine-to-machine) are part of almost any modern architecture. OAuth 2.0 and Auth0 provide the necessary building blocks to make its use in your architectures a breeze. From backend-to-backend, services, daemons, IoT devices, and even CLI tools, the client credentials grant remains a simple yet useful approach to the problem of authorization between autonomous and semi-autonomous system. This grant, augmented with the power of hooks, can cover all common use cases while remaining flexible for more granular security needs in the future. If you are using, or interested in using, machine to machine communications in your products, leave us a comment below. If you are unsure how any of this can apply to your architecture, [hit the "talk to sales" button in our homepage](https://auth0.com/), we can help you out!


Using Machine to Machine (M2M) Authorization

5e074956ee8ba1fea26e30d28c190495?s=300 avatar

5e074956ee8ba1fea26e30d28c190495?s=300

Full stack developer creating content at Auth0. I love taking a deep dive into hard-to-understand concepts and creating content that makes them easier to grasp. In my free time you can usually find me reading, hanging out with my dogs, or curling in the squat rack.

Former Developer Content Manager

Holly Guevara

Learn how to use the Auth0 Management API to build an admin dashboard with Express and Vue



<details>
<summary>Starting from this chapter?</summary>

Clone the application starter repo:

``` bash  
git clone git@github.com:auth0-blog/vue-express-auth.git
```

Follow the directions in the [project README](https://github.com/auth0-blog/vue-express-auth#set-up-the-express-server).

In the [Auth0 dashboard](https://manage.auth0.com/dashboard), click on "APIs" in the left menu and then select "Auth0 Management API". From there, select "Machine to Machine Applications" and find the "Vue Express API" you just created. Click the switch next to it so that it says "Authorized".

![Auth0 authorized API](https://images.ctfassets.net/23aumh6u8s0i/3bnn4TcXg4JJ6Ti42f4ymi/1545602b9f43d8c6dcfafda536730d27/auth0-management-api-authorized)

Next, add permissions to the application. Click on the down arrow V next to the authorized switch. Select `read:users`, `delete:users`, and `read:user_idp_tokens` and then click "Update".

</details>


## Calling the Management API with Express

The Express API is now registered in the dashboard, and the Auth0 Management API is set up and ready to issue an access token to the Express API. So what's next? Now, you have to do the [**client credentials**](https://auth0.com/docs/flows/concepts/client-credentials) dance to get an access token.

## Client Credentials Flow

The [OAuth 2.0 RFC 6794](https://tools.ietf.org/html/rfc6749#section-4.4) defines how trusted clients (your Express API) can use the client credentials to request an access token from a resource owner (the Auth0 Management API):

> ❗ The client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server (the method of which is beyond the scope of this specification).

Because the Management API access token is requested on behalf of the Express application, not a user, it doesn't make sense to ask for a username and password to verify who the requester is. Instead, you can use the Express application's client credentials (`client_id` and `client_secret`) to authenticate the application.

![Machine to machine client credentials grant](https://images.ctfassets.net/23aumh6u8s0i/3nVhN6jBKCjJxpO2BhcxOW/af8eaeabf5529b52e5e5ce865d045045/auth-sequence-client-credentials)
> This diagram depicts the client credentials grant flow described below

* The Express application authenticates with the Auth0 Authorization Server using its `client_id` and `client_secret`
* The Auth0 Authorization Server validates the  `client_id` and `client_secret`
* The Auth0 Authorization Server issues an access token and passes it back to your application
* The Express application passes this token when it makes a request to the Management API
* The Management API responds with the requested data

## Requesting an Access Token  

The Express application needs to request an access token for the Management API from the Auth0 server. There are **three ways** to do this.

1) Make a `POST` request to the token endpoint using your Express API client ID and client secret, as shown below:

<include src="AmpWarning" fullUrl="https://auth0.com/blog/build-an-admin-dashboard-with-express-and-vue-creating-the-backend"/>

``` js  
let request = require("request");

let options = {
    method: 'POST',
    url: 'https://YOUR-DOMAIN.auth0.com/oauth/token',
    headers: { 'content-type': 'application/json' },
    body: '{
        "client_id": "yourclientid",
        "client_secret": "yourclientsecret",
        "audience": "https://YOUR-DOMAIN.auth0.com/api/v2",
        "grant_type": "client_credentials"
    }'
};

request(options, function (error, response, body) {
  if (error) throw new Error(error);
});
```

This will return the **access token** (with a 24-hour expiration) and **token type**:

``` js  
{
  "access_token": "somelongstring",
  "token_type": "Bearer"
}
```

2) Use the [Auth0 Node Authentication API Client](https://www.npmjs.com/package/auth0#authentication-api-client)

``` js  
let AuthenticationClient = require('auth0').AuthenticationClient;
 
let auth0 = new AuthenticationClient({
  domain: '{YOUR_ACCOUNT}.auth0.com',
  clientId: '{CLIENT_ID}',
  clientSecret: '{CLIENT_SECRET}'
});
 
auth0.clientCredentialsGrant(
  {
    audience: 'https://{YOUR_ACCOUNT}.auth0.com/api/v2/',
    scope: '{MANAGEMENT_API_SCOPES}'
  },
  function(err, response) {
    if (err) {
      // Handle error.
    }
    console.log(response.access_token);
  }
);
```

This performs a Client Credentials Grant using the `clientId` and `clientSecret` of the client that was registered in the Auth0 dashboard, in this case, the Express API. This will return the **access token**, **scopes**, **expiration**, and **token type**. You'll then send this access token along with every request you make to the Management API.

3) Use the [Auth0 Node Management API Client](https://www.npmjs.com/package/auth0#management-api-client)

``` js  
let ManagementClient = require('auth0').ManagementClient;

let auth0 = new ManagementClient({
  domain: '{YOUR_ACCOUNT}.auth0.com',
  clientId: '{YOUR_CLIENT_ID}',
  clientSecret: '{YOUR_CLIENT_SECRET}',
  scope: 'read:users delete:users'
});
```

Finally, there also exists an option to **automatically receive an access token in the background** using the [Auth0 Node Management API Client](https://www.npmjs.com/package/auth0#management-api-client). This is similar to option 2. The Client Credentials Grant still takes place behind the scenes and will retrieve a Management API access token along with its expiration. It then automatically caches this access token for the time specified in the expiration.

For this tutorial, you'll be using the third option. This option allows you to use the [Management Client to easily make requests to the Management API](https://auth0.github.io/node-auth0/module-management.ManagementClient.html).

## Getting your Access Token in Express

Now that you know how the client credentials flow works and how you're going to implement it in your application, it's finally time to write some code!

Head back to your code editor and open `server/server.js` from the [Vue Express application you cloned earlier](https://github.com/auth0-blog/vue-express-auth).

📝 Here's an overview of what you're going to do:

- Install and import the Auth0 `ManagementClient`
- Create a `.env` file for your confidential values
- Add `clientId` and `clientSecret` to your `authConfig` object
- Create a new instance of the `ManagementClient` with your `domain`, `clientId`, and `clientSecret`

Make sure you're in the `server` directory in your terminal and install the [`node-auth0`](https://www.npmjs.com/package/auth0) package by running:

``` bash  
npm install auth0
```

Find the `require` functions at the top of your `server/server.js` file and add the following line to import `ManagementClient`.

``` js  
// ...
// import statements
const ManagementClient = require('auth0').ManagementClient;
// app.use 
```

Next, toward the top of the file, you should see an `authConfig` object directly underneath the `require` and `use` methods. This needs to be modified to include your client secret and client ID from the Express API.

Because these are sensitive values, you should not save them directly in the code. If you ever share this code or upload it to GitHub, you [risk leaking your client secret](https://auth0.com/blog/developers-guide-to-common-vulnerabilities-and-how-to-prevent-them/#Mishandling-Sensitive-Data). Instead, it's best to create a `.env` file and add this file to your `.gitignore`. To do this, navigate to the `server` directory and run the following command in your terminal: 

``` bash  
npm install dotenv
```

At the top of your `server/server.js` file add this line:

``` js  
require('dotenv').config();
```

Now create a file in the root of the `server` directory called `.env` and add the following to it:

``` js  
AUTH0_DOMAIN = your-domain.auth0.com
AUTH0_AUDIENCE = https://your-api-audience.com
CLIENT_ID = yourclientid
CLIENT_SECRET = yourclientsecret
```

The values for `CLIENT_ID` and `CLIENT_SECRET` can be found back in the [Auth0 dashboard](https://manage.auth0.com/dashboard) on the Auth0 Management API page that you set up earlier.

If you already closed this tab, just click on "**APIs**" > "**Auth0 Management API**" > "**Test**" and then select the Express API from the dropdown. Next, click on "**Node.JS**", and you can copy the `client_id` and `client_secret` from the resulting code below.

If you followed the setup instructions from the README, you should already have an object in `server.js` called `authConfig` that contains the audience and domain values. Grab those and paste them into their corresponding spots in `.env`.

If you don't have the domain and audience values, they can be found by clicking on "**APIs**" in the left-hand menu and then selecting the Vue Express API. Next, click on "**Quick Start**" and then select "**Node.js**". You'll see a value for `audience`, which you can paste directly into `AUTH0_AUDIENCE` and then another value for `issuer`. Copy this and paste it into `AUTH0_DOMAIN`.

> ⚠️ Important: For `AUTH0_DOMAIN`, omit the `https://` and the trailing `/`. It should be formatted exactly as shown above.

Next, modify the `authConfig` object in `server/server.js` to use those environment variables as follows:

``` js  
// Set up Auth0 configuration
const authConfig = {
  domain: process.env.AUTH0_DOMAIN,
  audience: process.env.AUTH0_AUDIENCE,
  clientId: process.env.CLIENT_ID,
  clientSecret: process.env.CLIENT_SECRET
};
```

And finally, you'll create a new instance of the `ManagementClient`, which takes an object that contains your Auth0 domain, client ID, and client secret.

Paste this just below the `authConfig` object in `server/server.js`:

``` js  
const managementAPI = new ManagementClient({
  domain: authConfig.domain,
  clientId: authConfig.clientId,
  clientSecret: authConfig.clientSecret
});
```

Now, when you use `managementAPI`, it will automatically perform the Client Credentials Grant in the background using the domain, client ID, and the client secret, which will result in an access token that can be used to make requests to the Management API.

Now it's time to test it out.

## Calling the Management API

Back in `server/server.js`, scroll down to where the `events` array is defined. Paste in the following code right below it:

``` js  
app.get('/users', (req, res) => {
  managementAPI
    .getUsers()
    .then(function(users) {
      res.send(users);
    })
    .catch(function(err) {
      console.log(err);
    });
});
```

This will create an API route in your Express application that calls the [Management API Node Client to get all users](https://auth0.github.io/node-auth0/module-management.ManagementClient.html#getUsers) whenever that route is accessed.

To verify that it's working, switch to your terminal and start your Express application if you haven't already by running:

``` bash  
npm start
```

Navigate to [`http://localhost:8000/users`](http://localhost:8000/users) in your browser, and you should see all of the users that have signed up for your application! 💃

If you're getting an error, **reach out in the comments below**, and I'll try to help troubleshoot.

You're also going to need a route to delete a user, so since you're here, just set that up now. Below the previous route, paste in:

``` js  
app.get('/users/:id/delete', (req, res) => {
  managementAPI
  .deleteUser({ id: req.params.id })
  .then(response => {
    res.send('User deleted!');
  })
  .catch(function(err) {
    res.send(err);
  });
});
```

This will grab the `id` of the user, which will be passed to the server from the Vue client. Then it will call the Management API to do the deletion.

Now that you're able to pull all of your users into the application and delete a user, it's time to switch to the frontend.

<include src="tutorial/NextButton" nextPart="build-an-admin-dashboard-with-express-and-vue-creating-the-frontend/" completedMessage="I've set up the Express backend"/>

<include src="tutorial/IssueButton" communityTopic="53302"/>


Build an Admin Dashboard with Express and Vue: Creating the Backend



The **Auth0 dashboard** has extensive tools that you can use to manage your application's authentication and authorization. You can create users, delete users, assign roles to users, ban IPs, and much more. While it's great to have the option to manage users straight from the dashboard, you might sometimes run into a scenario where you need to have that control straight from your own application.

Consider this use case. You're building a blogging platform for a client, and you're using Auth0 as an identity solution. The client has a few employees that will need full admin access to the blog. They'll have the ability to make updates to any users that sign up, ban users, view user data, and more.

Here's the caveat: the client doesn't want her employees to have to sign into another platform to do this. She wants you to build a dashboard on the blogging platform that will give administrators the capability to manage users straight from the blogging application. Lucky for you, you can do all of this using the [Auth0 Management API](https://auth0.com/docs/api/management/v2)! 

In this article, you'll learn how to **build a simple user management dashboard** using Vue.js, Node.js, and [Auth0](https://auth0.com). You'll be using the Auth0 Management API to pull all of your application's users into your Vue Express application. You'll also add a delete button so that you can delete users straight from your own dashboard. You can check out the final [User Management Dashboard code here](https://github.com/auth0-blog/express-vue-management-api).

![Auth0 user dashboard Management API](https://images.ctfassets.net/23aumh6u8s0i/6tjQ9rvSCgOcZ9MIrd9dCx/61d999a28e841ab4aac8a07c547226d0/auth0-user-management-api-dashboard)

## Getting Started

To keep this focused on user management, you're going to be building the dashboard from an existing application that was built in two previous tutorials: [Beginner Vue.js Login Tutorial](https://auth0.com/blog/beginner-vuejs-tutorial-with-user-login/) and [Making HTTP Requests with Vue and Express](https://auth0.com/blog/how-to-make-secure-http-requests-with-vue-and-express/).

You don't need to read those to follow along with this tutorial, but you should be familiar with Vue and Express. If not, those two tutorials will be a great starting point, even for a beginner!

To begin, clone the [Vue and Express Events app repository](https://github.com/auth0-blog/vue-express-auth) and follow the instructions in the README to get everything set up. You'll also need to <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account</a>. The [Auth0 configuration details](https://github.com/auth0-blog/vue-express-auth#configuring-auth0) are also in the README.

Without further ado, let's dive into the Management API!

## Using the Management API

This will be covered step by step, but here's a quick overview of what you'll need to do to get access to the Auth0 Management API:

* Create a Machine-to-Machine Application in the Auth0 dashboard
* Connect it to your Express API
* Get a short-lived access token for production

[In the Auth0 dashboard](https://manage.auth0.com/dashboard/), click on "APIs" in the left menu and then select "Auth0 Management API". This is a pre-configured Auth0 system API that you can use to connect to the Management API.

To use the Management API, you first need to get an access token called the *Auth0 Management API Token*. This token is used to **authorize your application to access the Management API**. As you'll see soon, whenever you make a request to the API, you'll send this token along with it, and the Auth0 server will check that it's valid.

You can get this token straight from the dashboard so that you can immediately experiment with the API. This method is for testing only. Let's play around with the API this way first, and then you'll generate an API access token on the fly from your own application afterward.

## Get a Token from the Dashboard

Make sure you're still on the Auth0 Management API page and click on "**API Explorer**" from there. Next, click the blue button that says "**CREATE & AUTHORIZE TEST APPLICATION**". A test access token will then be generated for you. Copy this token and head to the [Auth0 Management API Explorer](https://auth0.com/docs/api/management/v2). In the top left corner, you should see a button that says "**SET API TOKEN**." Click on this, paste your token in, and click "Set Token."

![Auth0 Management API explorer](https://images.ctfassets.net/23aumh6u8s0i/5DOSy4hJXfauYKGrRojrbv/31ba756ff4cdf854c3f9c7a848c755cc/auth0-api-explorer)

The API explorer provides a convenient way to test out any API calls that you might need to use once you start working on your application. You can scroll through the API Reference in the left menu to see everything you can do with the Management API.

Go ahead and test out one of the requests you'll be making in this tutorial. Scroll down to [List or search users](https://auth0.com/docs/api/management/v2#!/Users/get_users). You'll see some documentation and optional parameters that you can use to build your request. Just leave all of these blank for now and press the blue button that says "Try" (you'll have to scroll down a bit).

The response will be an array of objects, where each object contains information about an individual user such as name, email, number of logins, when their account was created, and more.

![Auth0 management API explorer - get all users](https://images.ctfassets.net/23aumh6u8s0i/2wnwGQAykgydsRq9lgi8WT/4c7f5a42fa1c3049ed5587ab1ee85620/auth0-management-api-explorer)

Feel free to experiment with the Management API here. You can always get a new token from the dashboard whenever yours expires.

## Setup to Get a Token Programmatically

Since the point of this tutorial is to streamline some of this user management process, you're going to want to be able to **automatically generate** a new Auth0 Management API Token straight from your application.

To do this, you need to connect your client application to the Auth0 Management API in the dashboard so that it knows who it's issuing an access token to. In this case, **the client application is your Express API**.

> Note: If you're scratching your head wondering how an Express application is the client, don't worry, you're not alone. It seems strange, but Express is the client in relation to the Auth0 Management API. Your Express application will be the one requesting access to a resource from the Management API.

Make sure you're still on the Auth0 Management API page [in the Auth0 dashboard](https://manage.auth0.com/dashboard/) and click on "**Machine to Machine Applications**". Click on the switch next to "**Vue Express API**" or whatever you named your Express API when you set it up in Auth0 from the [Vue and Express Events app repository README](https://github.com/auth0-blog/vue-express-auth). It should now be green and say "Authorized."

![Auth0 Management API authorized client](https://images.ctfassets.net/23aumh6u8s0i/3bnn4TcXg4JJ6Ti42f4ymi/1545602b9f43d8c6dcfafda536730d27/auth0-management-api-authorized)

You'll also need to add permissions to this application, so go ahead and handle that now. Click on the down arrow `V` next to the authorized switch. For the purpose of this application, select `read:users`, `delete:users`, and `read:user_idp_tokens` and then click "Update".

* `read:users` &mdash; Read your Auth0 application's users
* `delete:users` &mdash; Delete your Auth0 application's users
* `read:user_idp_tokens` &mdash; Read the [identity provider](https://auth0.com/docs/identityproviders) access token

If you scroll back up, you'll see a tab titled "**Test**" next to "**Machine to Machine Applications**". Click on "**Test**", and you should see your API in the dropdown right underneath "Asking Auth0 for tokens from my application". Select the "**Vue Express API**" and then click on "**Node.JS**" underneath it. This will give you the code for the API call that will allow the Express API to request a token from the Auth0 Management API.

Leave this page open, as you'll be using it in the next section.

<include src="tutorial/NextButton" nextPart="build-an-admin-dashboard-with-express-and-vue-creating-the-backend/" completedMessage="I've set up my application in the Auth0 dashboard"/>

<include src="tutorial/IssueButton" communityTopic="53302"/>


Build an Admin Dashboard with Express and Vue



<details>
<summary>Starting from this chapter?</summary>

**Setting up**

Clone the application starter repo and check out the `creating-the-backend` branch:

``` bash  
git clone git@github.com:auth0-blog/express-vue-management-api.git --branch creating-the-backend
```

Install the dependencies for both the client and server:

``` bash  
cd server
npm install
cd ../client
npm install
```

**Configure Auth0**

Follow the Auth0 Configuration directions in the [project README of the starter Vue and Express application](https://github.com/auth0-blog/vue-express-auth#configuring-auth0).

**Configure Management API**

In the [Auth0 dashboard](https://manage.auth0.com/dashboard), click on "APIs" in the left menu and then select "Auth0 Management API". From there, select "Machine to Machine Applications" and find the "Vue Express API" you just created. Click the switch next to it so that it says "Authorized".

![Auth0 authorized API](https://images.ctfassets.net/23aumh6u8s0i/3bnn4TcXg4JJ6Ti42f4ymi/1545602b9f43d8c6dcfafda536730d27/auth0-management-api-authorized)

Next, add permissions to the application. Click on the down arrow V next to the authorized switch. Select `read:users`, `delete:users`, and `read:user_idp_tokens` and then click "Update".

Create the `.env` file in the root of the `server` directory:

``` js  
AUTH0_DOMAIN = your-domain.auth0.com
AUTH0_AUDIENCE = https://your-api-audience.com
CLIENT_ID = yourclientid
CLIENT_SECRET = yourclientsecret
```

To find your values, go to the [Auth0 dashboard](https://manage.auth0.com/dashboard) and click:

"APIs" > "Auth0 Management API" > "Test"

Select the Express API from the dropdown then click "Node.JS". You'll find the values for `CLIENT_ID` AND `CLIENT_SECRET` in the resulting code.

`AUTH0_DOMAIN` and `AUTHO_AUDIENCE` can be found by clicking on "APIs" and then selecting the Vue Express API. Then click on "Quick Start" and select "Node.js". You'll see a value for audience, which you can paste directly into AUTH0_AUDIENCE and then another value for issuer. Copy this and paste it into AUTH0_DOMAIN, but leave off the `https://` and the trailing `/` at the end.

**Test it**

Start the Vue app:

``` bash  
cd client
npm run serve
```

Start the Express app:

``` bash  
cd server
npm start
```

Navigate to [http://localhost:8000/users](http://localhost:8000/users) to see an array all of your users from the Express `/users` endpoint.

View the dashboard at: [http://localhost:8080/dashboard](http://localhost:8080/dashboard)

</details>

## Creating the Dashboard with Vue

Here's what needs to be done on the Vue side:

* Create a dashboard route
* Create a new dashboard component
* Create the user service to connect to the Express API
* Make a `GET` request to the Express API's `/users` route
* Loop over and display the users
* Create a delete button and delete method
* Add the delete method to the user service that makes a request to the Express API's `/users/:id/delete` route
* Pass the user's access token along with their Express API requests
* Restrict the route so that unauthenticated users will be kicked to the login screen

I'll go over each step here, but if you'd like a more in-depth explanation about making HTTP requests in Vue, I'd recommend going back and reading through the original article that this application is based on, [Making HTTP Requests with Vue and Express](https://auth0.com/blog/how-to-make-secure-http-requests-with-vue-and-express/). 

If you haven't already, you can start the Vue application by navigating to the `client` directory in the terminal and running:

``` bash  
npm run serve
```

You can view it at [http://localhost:8080](http://localhost:8080)

## Add the Dashboard Route

First, go ahead and create the `/dashboard` route, which is where the user list will be displayed.

Open up `client/src/router/index.js` and paste the following in as the last element in the `routes` array:

``` js  
{
    path: '/dashboard',
    name: 'dashboard',
    component: () => import('../views/Dashboard.vue')
}
```

## Create the Dashboard Component

You'll notice that the `/dashboard` route is using the `Dashboard.vue` component. This doesn't exist yet, so go ahead and create it now.

Under `client/src/views`, create a new file called `Dashboard.vue` and paste in the following:

``` js  

<template>
<div class="container">
  <h2 class="title is-size-3 has-text-centered">Welcome to your dashboard</h2>
  <div class="columns" v-if="message">
    <div class="column is-one-quarter is-offset-8">
      <div class="notification is-success">
        {{ message }}
      </div>
    </div>
  </div>
  <div class="columns is-multiline has-text-centered">
    <div v-for="user in users" :user="user" :key="user.id" class="column is-one-quarter">
      <img :src="user.picture" :alt="user.name" style="width:200px;margin-left:auto;margin-right:auto;"/>
      <h3 class="is-size-6">Name: {{ user.name }}</h3>
      <h3 class="is-size-6">Email: {{ user.email }}</h3>
      <h3 class="is-size-6">Last login: {{ user.last_login }}</h3>
      <h3 class="is-size-6">Login count: {{ user.logins_count }}</h3>
      <button @click="deleteUser(user.user_id)" class="button is-medium is-danger">Delete me 😵</button>
    </div>
  </div>
</div>
</template>
<script>
import UserService from '@/services/UserService.js';
export default {
    name: "Dashboard",
    data() {
    return {
      users: [],
      message: ''
    };
  },
  created() {
    this.getUserData(); // call getEventData() when the instance is created
  },
  methods: {
    async getUserData() {
      // Pass the access token to the getUsers service
      UserService.getUsers()
      .then(
        (users => {
          this.$set(this, "users", users);
        }).bind(this)
      );
    },
    async deleteUser(deleteId) {
      // Pass specified id to the deleteUser service
      UserService.deleteUser(deleteId)
      .then(
        (response => {
          this.message = response; 
          this.getUserData(); // get refreshed users
        })
      );
    }
  }
}
</script>
<style lang="scss" scoped>
  .notification {
    position: fixed;
    top: 800px;
    right: 40px;
  }
  .button {
    margin-top: 15px;
  }
</style>

```

In the script section, you're first importing the `UserService`. This is what your Vue application will use to connect to the Express API defined in the `server` directory. The Express API is responsible for getting the data from the Management API.

> 🧠 Your Vue client cannot reach out to the Management API directly because it would need an access token to do that, and as you saw earlier, that would require the client (Vue) to pass the client secret on the frontend, which isn't secure.

So, instead, the **Express API handles the connection** with the Management API. The Vue application then makes a request to the Express API using the `UserService` and receives the user information that the Express API passes back to it.

Of course, you wouldn't want just *anybody* to be able to access this user information. This is why the **request to the Express API from the Vue client must be authorized**. With the current implementation, anyone will be able to access the Express API endpoints to obtain the list of users and delete a user. Sit tight for now, and you'll be addressing that in an upcoming section.

The next important thing to note here are the 2 methods: `getUserData()` and `deleteUser(deleteId)`. The first method is called when the Dashboard instance is created. It's going to call the `getUsers()` method on the `UserService` and then set the result to the `users` array (defined under `data`). The next method will be called when the user clicks on a "Delete me" button underneath a user. It will send the selected user's `user_id` through to the `UserService.deleteUser()` method as a parameter.

If you glance back up now at the template section, you'll see where that `users` array comes into play. You're looping over it to display each individual user's avatar, name, email, last login date, and login count.

Finally, there's a `message` variable that will let us know that a user has been deleted.

Now, the `UserService` doesn't exist, so none of this is going to work yet. Go ahead and create it now.

## Create the User Service

Create a new file called `UserService.js` under `client/src/services` and paste in the following:

``` js  

import axios from "axios"
export default {
  async getUsers() {
    let res = await axios.get("http://localhost:8000/users");
    console.log(res.data);
    return res.data;
  },
  async deleteUser(id) {
    let res = await axios.get(`http://localhost:8000/users/${id}/delete`);
    return res.data;
  }
}

```

This allows the Vue application to make a `GET` request to the Express API using [axios, a promise-based HTTP client](https://github.com/axios/axios).

You're calling the `/users` and `users/${id}/delete` routes that you built earlier in Express. The `/users` route is the one that returns the user information from the Management API.

So when the Vue application makes a `GET` request to the Express `/users` route, Express reaches out to the Management API and makes a request for the list of users. If the access token that the Express API presents is valid, then the Management API returns the users. Consequently, the Express API will then return that data to the requesting Vue application.

Again, it's important to verify that the Vue application is allowed to access this information. **Whether or not it's allowed to access it is between the Express API and the Vue application, not the Management API**. Currently, there's nothing in place to check that the Vue application is allowed to make this request to the Express API. You'll see how to implement this in the next section.

For now, make sure your Vue application and Express app are both still running in the terminal:

**Vue application:**

``` bash  
npm run serve
```

**Express application:**

``` bash  
npm start
```

Head to [`http://localhost:8080/dashboard`](http://localhost:8080/dashboard), and you should now see your shiny new dashboard with all of your user's avatars and information displayed.

> 🚨 Resist the urge to click the "Delete" button on the accounts you want to keep! I recommend creating test user accounts through the Auth0 dashboard when you want to try out the delete button.

![Vue Express Auth0 management API user dashboard](https://images.ctfassets.net/23aumh6u8s0i/6tjQ9rvSCgOcZ9MIrd9dCx/61d999a28e841ab4aac8a07c547226d0/auth0-user-management-api-dashboard)

<include src="tutorial/NextButton" nextPart="build-an-admin-dashboard-with-express-and-vue-adding-user-authorization/" completedMessage="I've created the Vue dashboard"/>

<include src="tutorial/IssueButton" communityTopic="53302"/>


Build an Admin Dashboard with Express and Vue: Creating the Frontend

956290?s=200

R&D Content Engineer

Luke Oliff

Streamline Travel API Authorization with Auth0



Travel is one of the world's fastest-growing sectors with demand reaching an all-time high, according to [Deloitte's 2018 Travel and Hospitality Industry Outlook](https://www2.deloitte.com/content/dam/Deloitte/us/Documents/consumer-business/us-cb-2018-travel-hospitality-industry-outlook.pdf). Directly or indirectly, economic contributions in [travel and tourism now account for 10.4% of global GDP](https://www.wttc.org/-/media/files/reports/economic-impact-research/regions-2018/world2018.pdf), reports the World Travel &amp; Tourism Council. Travel investment is set to reach $925B in 2018, and rise by an average of 4.3% over the next ten years to $1,408.3B by 2028.

According to a report by the [World Economic Forum](https://www.weforum.org/) from January 2017, there is widespread recognition among industry leaders that the role of technology is changing from being a driver of marginal efficiency to an enabler of fundamental innovation and disruption. The report states "Digitalization represents an exciting opportunity for the aviation, travel and tourism ecosystem, with the potential to unlock approximately $1 trillion of value for the industry and wider society over the next decade."

In this rapidly growing market, digital transformation is key to staying agile. Application Programming Interfaces (APIs) play a large role in digital transformation and are key tools that allow travel businesses to provide value to customers and, ultimately, compete better. From hotels and flights to cars and buses, [there is an API for virtually every area of travel](https://www.programmableweb.com/news/top-10-travel-apis-uber-tripadvisor-and-expedia/analysis/2015/04/24).

Even mega-giants like [Amadeus](https://amadeus.com/en), [Sabre](https://www.sabretravelnetwork.com/home/), and [Travelport](https://www.travelport.com/), who are the dominant players in the area of one-stop shop travel solutions, have their own [APIs for comprehensive booking and reservations services](https://www.altexsoft.com/blog/engineering/travel-and-booking-apis-for-online-travel-and-tourism-service-providers/). But they didn't start with APIs — they've been dominating this sector for much longer than APIs have been popular.

<include src="TweetQuote" quoteText="In the fiercely contested travel industry, digital transformation is key to staying agile. Auth0 streamlines API development."/>

## Digital Transformation in the Travel Industry Started in the 1950s

With the boom of general aviation in the 1950s, the travel industry was forced to scale quickly. Digital tools were developed to automate how airlines track and sell their inventory. This was the first digital transformation in travel, even before the beginning of the internet. From there, Sabre — or Semi Automated Business Research Environment — was born. The first global distribution system (GDS), Sabre was started in the 1960s with a collaborative effort by American Airlines and IBM. Travelport was developed by United Airlines in the 1970s and Amadeus soon followed, developed by a group of European airlines in the 1980s.

These [three major players still make up more than 90% of the global market](http://www.businesstravel-iq.com/article/2018/08/08/gds-market-share-second-quarter-2018) in airline bookings — and their dominance is down to digital transformation. This gave them the ability to streamline business processes and reach into more areas of the travel industry with relatively little friction.

![Graphic showing travel industry tech, applications, and advances](https://images.ctfassets.net/23aumh6u8s0i/68AtLA3SQx8RGsaWhbv1oE/96743115e80186204dd6203f2d7b3519/connected)

## The Plumbing of the B2B Travel Industry

Suppliers like hotel companies and airlines need to connect with distributors such as wholesalers and GDSs to reach as large an audience as possible for their products. In this scenario, without an API, the suppliers must upload their inventory to the GDS and similar companies that help connect partners and products to consumers, incurring a cost associated with the distribution. This increases ticket prices.

However, if a supplier has an API, it is easier for them to connect supply and demand directly, meaning less cost is passed on to the consumer. By building their own APIs, suppliers like the fictional "airline.com" are almost becoming direct-to-consumer distributors of their own products, offering their own sites or apps to book on, and possibly marketing through a metasearch engine.

Additionally, with APIs, "airline.com" can also sell ancillaries such as rental cars or even hotel rooms through the APIs offered by those ancillary services.

This means that suppliers have built APIs that help them sell more directly, market through metasearch, and integrate with a rental car or a hotel room providers' APIs as well to bolster their package or complementary travel offering.

As Sonja Woodman explained in [APIs – The Plumbing of the B2B Travel Industry](http://www.triometric.net/travel-analytics/apis-the-plumbing-of-the-b2b-travel-industry/), "The whole industry is underpinned by a complex layer of networks and APIs — the plumbing of the B2B travel industry — e.g. communication links and API connectors between merchandising platforms, central reservation systems, global distribution systems, industry transaction hubs and gateways, etc."

## Metasearch Simplifies the Consumer Search Process

Metasearch engines like [Skyscanner](https://www.skyscanner.com/) and [Trivago](https://www.trivago.com/) take data from airlines, travel agents, and global distribution systems and aggregate the results. By aggregating this data, they can provide a website and app that greatly improves customers' experience in finding the cheapest rates for flights (now including hotels and vehicles) and then linking the customer directly to the retailer to make their booking.

Metasearch engines ultimately aggregate prices and show the best options. Potentially, a simple search for flights could run through hundreds of sources of data all linked in a web of APIs, pulling data from different sources.

![Metasearch engine graphic showing flow of information to APIs connecting everything](https://images.ctfassets.net/23aumh6u8s0i/OFAooNM2xeb5nRRgBnnls/731d05d34f7a6a52f36505f53c301f77/meta-search-connects-to-everything)

## TripAdvisor Encourages Partners to Develop APIs

Online Travel Agents (OTAs) like [TripAdvisor](https://www.tripadvisor.com/), [Hotels.com](https://www.hotels.com/) and [Booking.com](https://www.booking.com/) offer hotel rooms, flight tickets, holiday packages, train tickets, and other tourism products directly to consumers by charging a commission.

The power of traditional OTAs usually comes from partners prepared to regularly upload their inventory. The partner bears the overhead of conforming with APIs and developing software to mass upload inventory. The effort of integrating with an API typically does not go the other way around. In other words, TripAdvisor would not spend time integrating with a retailer or hotel chain's APIs unless they were pretty big — think Hilton, Westin, or Four Seasons.

TripAdvisor's service, the TripAdvisor Self Implemented Partner program, is ready to integrate with any partner APIs, so long as those APIs have been built to TripAdvisor's specifications.

TripAdvisor and suppliers get the benefit of valuable live pricing by allowing TripAdvisor to pull prices on demand. This takes place in lieu of having to rely on daily uploads of inventory. With traditional inventory uploads, there is a risk that rooms can become unavailable between the upload and the customer trying to make a booking. In this new API-driven model, consumers gain access to great rates that don't disappear once they try to book them.

![Plane taking off - travel industry digital transformation](https://images.ctfassets.net/23aumh6u8s0i/4y8FIz8p0wWy9okW1CNHsF/1a0166b5aac8b4ee5fc82152560760e3/supercharge-api-development-with-auth0)

<include src="TweetQuote" quoteText="New APIs have the inevitable overhead of developing security, and dedicating resources to it has a cost. Secure your API with Auth0."/>

## Secure Your APIs with Auth0

Creating new APIs has the inevitable overhead of developing security. At a basic level, secure and authorized API integration is required for partners to communicate securely, to identify partner functionality and features, and to apply pricing and billing mechanisms. Dedicating engineering resources to areas such as authentication, identity, security, and compliance comes at a high opportunity cost but it can also represent a larger risk than relying on experts for the same.

In addition to supplying an identity and access management solution, Auth0 provides the necessary building blocks to secure your APIs much more quickly. We allow companies to focus on the core value-add capabilities of their product versus focusing time and effort on implementing capabilities that Auth0 provides out of the box.

Think of the tens, hundreds, or even thousands of API calls that could be triggered behind the scenes by a search for flights. Each one of those calls is made across the internet and secured each time by a layer of security and access management. Building this type of access management is time consuming, and can be substantially challenging to secure.

[APIs are helping to drive digital transformation right now](https://deloitte.wsj.com/cio/2016/06/27/apis-help-drive-digital-transformation/), with digitalization no longer a case of 'if' but 'when.' According to [MuleSoft's Connectivity Benchmark Report 2018](https://www.mulesoft.com/lp/reports/connectivity-benchmark), nearly three quarters of IT decision makers are currently carrying out digital transformation initiatives and nearly 60% claimed that APIs had increased productivity in business operations.

Add Auth0 to this API-centric shift in digital culture and benefit from faster development and more security than if you were to build it yourself. Auth0 provides a polished and reliable service, with tools that are easy to use and implement. In fact, enabling powerful features can be as easy as flipping a switch and hundreds of valuable development hours can go back to writing business logic. [Security is strengthened](https://auth0.com/security), with Auth0 shouldering the responsibility of adhering to security compliance policies and certifications. This means that lots of time dedicated to testing and security can be returned to core app work. Use Auth0 to secure your APIs to maintain your upward trajectory in the digitalization of the travel industry.

<include src="asides/AboutAuth0" />


"m2m"