Anthony Dombrowski
Developer Advocate

---

Choosing which OAuth 2.0 grant type to use depends on factors such as the level of security needed and the type of user experience you want to provide. In this blog space, we’ve already taken a look at two of the four grant types: the authorization code flow and the implicit grant flow. Each grant type lends itself to specific use cases, and figuring out the best way to obtain an access token often starts with the question “To whom are we giving access?”

If the answer is “a machine,” the client credentials grant type may be the preferred option.

What are Client Credentials?

Client credentials are much what they sound like. At their core, they’re essentially a username and password (credentials) for a computer (client) that can be used to authenticate with an authorization server. 

When a client registers with an authorization server, it’s typically given two things:

1. A client ID. This is usually a randomly generated string of characters created by the authorization server. It acts as an identifier, and you can think of it like you would a  username.
2. A client secret. A randomly generated string of characters created by a sufficiently secure random generator, this acts as the client’s password. Just as you wouldn’t want a user’s password to be guessable, you wouldn’t want the client secret to be guessable, either. It’s also created by the authorization server, typically at time of client registration.

The similarities to a user’s username and password are obvious, but there is one key difference: The client secret is generated by the site or authorization server rather than being generated by the client. (While it would be possible for the client to create the client secret, the authorization server would need to do a few checks, and it’s easier to have the authorization server create the client secret since it would have to use the same logic to create the checks anyway. The authorization server creating the client secret simply streamlines the process.)

Client Credentials Use Cases

When should you use the client credentials grant type? I alluded to this earlier when I talked about situations where a machine is gaining access, so let’s look at that a little more deeply

The IETF defines an authorization grant as “a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token.” Client credentials can serve as a form of authorization grant, and this happens typically in one of the following two use cases:

• Protected resources are under the control of the client, i.e., the client is acting on its own behalf
• A previous arrangement was made with the authorization server for the client to access the protected resources

For example, if the party requiring access to the resource is a machine and the resource owner is also a machine, such as when an app needs to access an API’s data to perform its work rather than access end-user-owned data, the client credentials grant type can be the most appropriate. The key benefit here is the ease with which this can be done. You have a secure computer with a secure connection, so it makes sense to take advantage of that and use credentials that couldn’t be used in a less secure situation.

In PingOne for Customers, the two-step flow looks something like this:

A few notes:

• You can use a client secret with HTTP basic authentication scheme to authenticate with the authorization server, so you can use this with GET or POST.
• If the confidential client is a single page app that runs in a browser, the credentials are in the browser and can't be guaranteed to be kept secret. But if the confidential client is a computer the company owns that can be guaranteed to be secure, and it communicates over a secure line, you can ensure the safety of those credentials.
  
• Public clients can’t be trusted to identify themselves using client authentication, so that would not be a good case for client credentials.
  

Worker Apps and PingOne for Customers

PingOne for Customers, our cloud-delivered customer identity and access management (IAM) solution for developers, includes a number of apps that don’t have any end user interaction, also called “worker apps.” In these cases, the worker apps have some type of management (typically configuration) to take care of, such as creating client connections, creating identities or gathering information on populations. These worker apps use the client credentials grant type to authenticate and get access tokens.

Worker apps are unique in our product through the use of roles, because the roles limit and allow the apps to do certain tasks. You can use client credentials for any of the other OAuth app connections, but the worker apps were really made specifically for this kind of thing.

In future posts, I’ll take a look at the remaining OAuth 2.0 grant type: resource owner password credentials. Until then, I invite you to test out PingOne for Customers with a free trial!