a good thing!
What Are OAuth 2.0 Grant Types? Part III: Client Credentials
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:
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:
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:
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!