This is the third post in a series where I write about OAuth 2.0 & OpenID Connect. In this article we are going to have a look at the
client credentials flow.
This type of flow was introduced with RFC 6749 and is sometimes referred to as
two-legged OAuth flow.
It is commonly used for server-to-server interactions that must run in the background, without immediate interaction of a user, where the client is typically a daemon service or a website. It's a much simpler flow then the others we have encountered so far.
client credentials flow permits a
confidential client to use its own credentials, instead of impersonating a user, to authenticate when calling another web service.
As an example think of a website (client) that likes to enrich it's content with a weather forecast provided by a protected weather service API (resource server). There is no human involved, when the website pulls that data.
Let's have a look at the sequence diagram.
This is what the flow looks like. It's pretty basic compared to the
authorization code flow, isn't it? 😎
Step 1 - Authentication
The client initiates the flow by authenticating with the authorization servers
It does so by sending a POST request of which the body is protected with TLS in transit. The
client_secret attributes are getting send in the header as a base64 encoded string (HTTP Basic Authentication, RFC 2617).
Authorization Servers like Microsofts Identity Platform can also accept certificates instead of a shared secret.
This is what an authentication request would look like:
POST /oauth2/token HTTP/1.1
Authorization: Basic eW91clfaWQ6eW91cl9jbGllbnRfc2VjcmV09jbGllbnR
It further passes two parameters along with it, which are
scope where the latter is optional.
|Must be set to
client_credentials to indicate the grant type
|The level of access to get an access token for
Step 2 - Credential Validation
The authorization server validates the
client_id and the
client_secret, which implies that the client needs to be registered with the authorization server beforehand.
Step 3 - Access Token Response
If the credentials are valid the authorization server immediatly returns an
access token. Please note that the access token response does not include a
As an example this is what an access token response could look like.
HTTP/1.1 200 OK
Step 4 - Requesting Data
The client requests the protected resource by presenting the access token in the authorization header.
Authorization: Bearer eyJraWQiOiJ[...]
Step 5 - Validating & Response
After the resource server successfully validated the access token via the authorization servers introspection endpoint (or a cached public key) it will reply with the requested data.
client credentials flowis used for server-to-server interaction
- The flow doesn't involve any user interaction (besides the one-time registration process done by an admin).
- Since client authentication is used as the authorization grant, no additional authorization request is needed.
- The authorization server will immediately return an access token upon successful authentication.