 Sometimes, a secure authorized communication channel between two different parts of an autonomous system is required. For example, two back-end services from different companies communicating with each other through the internet. For these use cases, OAuth 2.0 provides the client credentials grant flow. Let's take a look at how the client credentials grant flow from OAuth 2.0 works with off-zero for machine-to-machine communications. First, let's talk about machine-to-machine communications. There are many parts of a system where machine-to-machine communications make sense. A service to a service, a daemon going to a back-end, a CLI client communicating with an internal service, or even some internet of things tools. The key aspect of these communications relies on the fact that the element used to establish trust within this system is the client. So what does this mean? In contrast to usual systems where there is an authorization process that attempts to establish trust by authorizing a user, in these situations, the thing that must be authorized and trusted is the client instead. What is the client in this case? The client is an application, a process, or even an autonomous system. And in these scenarios, the typical authentication method using an email address or username and password are things like social login really don't make sense. The client credentials grant from OAuth 2.0 attempts to fulfill the need that is required for these machine-to-machine scenarios. In the client credentials grant, the client holds two pieces of information, the client's ID and the client's secret. And with this information, the client can request an access token to a protected resource. So let's do a walkthrough of how this scenario works. The client makes a request to the authorization server, sending the client's ID, the client's secret along with the audience and other claims. Then the authorization server validates the request and, if successful, sends a response with an access token. The client can now use the access token to request the protected resource from the resource server. The client must always hold the client's secret. This grant is only meant to be used with trusted clients. In other words, clients that hold the client's secrets must always be used in places where there is no risk of that secret being misused. While it may be a good idea to use the client credentials grant in an internal daemon that sends reports across the web for a different part of your system, it may not be used for a public tool that any external user can download from GitHub. Let's show what a request using the client credentials grant looked like. So the client credentials grant is very simple to use. The following on the screen is a relevant HTTP request. A successful authorization request results in a response like the following. If you already don't have an API created in off-zero, you can create one by going to applications, APIs, click create API, want to do test API, and we'll identify we're going to use a domain name. It could be any domain name off-zero is not going to call this domain name. So I'm just going to put example.com and then going to keep the signing algorithm as RS 256 and then let's click create. So now that we have an API, we can go to application, applications, and then we're going to create application. And now we're going to name it test app API. And it's going to be a machine to machine application. So click that and click create. Then we have to select an API. And the API is going to be the one we just created, which is test API. And then click authorize. Now let's take a look at some common scenarios where machine to machine communications might make sense. First, we'll talk about back end to back end. This is one of the most common scenarios. Let's say you have two different internal services that produce data in the form of logs. You are storing these logs locally in your own warehouse. However, as part of your policies, you also want those logs to be stored off-site 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 within your network, you use the client credentials grant given each client a client ID and a client secret. What about other common services like job schedulers, daemons, continuous processes, crime jobs, things like that? These are also great scenarios where the machine machine authorization makes sense. Say you have a job schedule that lives on your network, but on a different cloud provider that offers a great deal for GPU processing. And you only want your authorized clients to make use of that service. For this reason, you want to use the client credentials grant and only authorize those client IDs that you want to allow. What about Internet of Things devices? The rise of IoT devices makes a great cause 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 parked in your parking lot. You have many devices that are continuously reporting data to a central server. These devices communicate over Wi-Fi. To avoid intrusions, and even though your Wi-Fi 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. Also, let's talk about one of my favorites, CLI clients. When systems becomes big, automation starts to make more and more sense. Many tasks are repetitive, but still require an administrator to supervise them. These processes usually become scripts. These scripts are run when the administrators need to run them. Since these scraps 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 are only available in certain computers like their own or in a mainframe. 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 these sensitive parts of a system by requiring the client ID and the client secret could be a solution. In conclusion, machine-to-machine communications are a part of almost any modern architecture. Oof 2.0 and Oof 0 provide the necessary building blocks to make use of these architecture's breeze from back-end to back-end services, daemons, IoT devices, and even CLI tools. The client credentials grant remains a simple but a useful approach to the problem of authorization between autonomous and semi-autonomous systems. This grant can cover lots of the common use cases, and Oof 0 makes it very, very easy for you to use. If you have any questions about securing machine-to-machine applications, leave us a comment down below.