eric wu

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

Product Marketing Manager - Customer Identity Cloud

Eric Wu

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

alisa-duncan

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

Senior Developer Advocate

Alisa Duncan

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

Why You Should Migrate to OAuth 2.0 From API Keys

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

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


"machine-to-machine"