Client credentials flow

In the client credentials flow, the Authorization Server provides an access token directly to the client app after verifying the client app’s client ID and client secret. It is recommended for internal client apps highly trusted by the resource server (for example, when the client app and the resource server are part of the same organization).

The resources that the client app requests do not belong to any external end user. Because of this, identity providers and resource owners in the traditional sense do not take part in the client credentials flow. The client app acts on its own behalf and assumes the role of the resource owner.

Use case

Imagine a bookstore API whose resources are books. An internal client app is configured to regularly retrieve details of newly added books from the API and display their covers in an advertisement. The client credentials flow applies to this scenario because all parties trust each other and no external resources are involved.

Response

In the client credentials flow, where only an access token is present, a sample Authorization Server JSON response may look like this:

{
  "access_token": <token>
  "token_type": "Bearer",
  "expires_in": 1799,
  "scope": "http://bookstore.api.akamai.com/books.write"
}

Process

Here’s a detailed overview of the full OAuth 2.0 process in the client credentials flow case:

  1. The client app contacts the Authorization Server for an access token.
  2. The Authorization Server verifies the client app’s client ID and client secret and provides an access token.
  3. With a valid access token, the client app requests data from the resource server.
  4. The resource server validates the access token and provides the requested data to the client app.

The client app can make subsequent requests to the resource server until the access token received from the Authorization Server expires, in which case the process repeats.