OAuth client credentials flow overview: benefits and use cases.

OAuth Client Credentials Flow

On this page

What is a Client Credentials Flow in OAuth 2.0?

The Client Credentials flow is a server to server flow. There is no user authentication involved in the process. In fact there is no user at all, the resulting access tokens will not contain a user, but will instead contain the Client ID as subject (if not configured otherwise).

When to Use the Client Credentials Flow

This flow is useful for systems that need to perform API operations when no user is present. It can be nightly operations, or other that involve contacting OAuth protected APIs.

Client Credentials Flow vs Authorization Code Flow

The main difference between the two is that the client credentials flow relies on application authorization rather than involving the user. Since there is no user authorization, the flow only interacts with the Token endpoint.

Steps in the Client Credentials Flow

Token Endpoint

Illustration with the steps in the client credentials flow
  1. The Client makes a POST request to the OAuth Server
  2. The OAuth Server issues the Access Token immediately and responds to the client

Benefit of Using the Client Credentials Flow

The benefit of using the OAuth 2.0 client credentials flow in contrast to merely basic authentication using API keys is two-fold. Firstly your API infrastructure can be made uniform, no matter if the request comes from an authenticated user or from a server with a system user, the authentication in the API can be reused. Secondly using client credentials you limit the parties that you send the credentials to. In OAuth the client calls the token endpoint to retrieve an access token and then use that token to call the API. Using basic authentication such as API keys only would mean that the client would send the credentials to any API it needs to communicate with, thus more parties share the secret.

Client Authentication

The client authenticates in the Token part of the flow. Client authentication can be done in many ways, the most common being client secret. The following authentication mechanisms are supported in Curity:

  • No authentication (public client)
  • Secret in post body
  • Secret using basic Authentication
  • Client Assertion JWT
  • Mutual TLS (mTLS) client certificate
  • Asymmetric Key
  • Symmetric Key
  • Credential Manager

The Access Token

The Access Token is returned by the token endpoint. It is the token that later can be used to call the API and gain access. It is a Bearer token, and must not be sent to untrusted parties. The access token usually have a lifetime of 5-30 minutes.

The Refresh Token

No refresh token is issued. The client can make the same call again to obtain a new access token.

The Token Endpoint

Request Parameters

  • Method: POST
  • Content-Type: application/x-www-form-urlencoded
  • Response Type: json
client_idThe Client IDyesThe ID of the requesting client
client_secretThe client secretyes*The secret of the client. *Mandatory if client authentication is of type secret, and the authentication is not done using basic authentication
grant_typeclient_credentialsyesTells the token endpoint to do perform the client credentials flow.
scopeSpace separated string of scopesnoList the scopes the client is requesting access to.


  • Response Type: application/json
access_tokenA newly issued access tokenyesThe resulting access token for the flow
expires_inExpiration in secondsyesThe time to live of the access token in seconds
scopeSpace separated stringnoIf not present the requested scopes where issued. If present the issued scopes may differ from the requested scopes.
token_typeBearer or other token typeyesDescribes how the token can be used. Most commonly Bearer token usage.

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial