Out of four major grant type in the OAuth 2.0 specification, Client credential is the simplest one. This can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client. Basically when client owns the resources. It means that the client would be the resource owner itself. Here, registered trusted clients are allowed to obtain the access token by prodiving their client key and client secret to authorization server.
The flow illustrated in the above figure includes the following steps:
1. The Client application requests an access token from the authorization server, authenticating the request with its client key and client secret
2. If the client is successfully authenticated, an access token is returned.
Lets Try
You can easily try out this grant type with Open source WSO2 Identity Server which can be act as an OAuth 2.0 Authorization server.
Step 1. Login to Identity Server management console. And register OAuth application.
Callback url is not needed for client credential grant type. Therefore you can configure any value for that. Also you can select what grant types are allowed for given application.
Authorization server automatically generates client key and secret
Step 2. Use client tool to (such as curl) to send request to token end point. Following is the curl command for this. Here client key and secret is sent as Basic Auth headers.
curl --user fioXfS_HLZiKc6bKlruVFJJWLjAa:JIYG_OzuMcOj2KrRIamehEWJRMEa -k -d "grant_type=client_credentials" -H "Content-Type: application/x-www-form-urlencoded" https://localhost:9443/oauth2/token
You can see the returning access token in JSON format.
{"token_type":"bearer","expires_in":3600,"access_token":"8676e9c7292bde86315a717a9b76ac5"}
Use cases
This grant type can be used for following scenario.
Server to server communication
As an example, Internal server needs to communicate with several other internal servers. And where these servers need to be authenticated and authorized with each other to access services that are exposed by them. Rather than maintaining credentials or permissions in each server, OAuth can be used here. As there is no any end user involvement and the servers can be treated as both resource owner and the client; Client credentials would be the ideal way to grant access tokens.
Following diagram illustrates this.
Access APIs that do not want end user permission.
As an example, There is a web application. And users who login to web application can see the data that is retrieved through backend APIs. These APIs have been secured with OAuth 2.0. To retrieve these data, end user permission is not needed. Therefore, Web application can use its own access token (that has been granted through client credentials) . But once, user travels through any other web pages in the web application, end user permission would be needed to retrieve data. Then access token that is granted by end users is needed.
Access APIs by Application developer in Application development stage.
Say, Application developer starts to develop an application using APIs that have been secured with OAuth 2. Application developer would need to access APIs in the implementation stages where testing is needed to be carried out. Here, application developer can use an access token with limited access that is granted from client credentials. Following sample explains this scenario further.
Sample Scenario
Let assume there is some company (say “foo”) that exposes public APIs. These APIs can be used to build new applications. This “foo” has a SDK portal where users can download the SDK and build application top of it by using the APIs. Application developer can login to SDK portal and download the SDK. Then application developer is granted with an access token with limited access that can be used to implement the application (basically test the implementation). This access token can be obtained from client credentials as there is no end user involvement.
Following diagram illustrates more on this.
Here you can find the sample java project for the web application. Let try to identify what is happening in there. Also, WSO2 Identity Server is used as OAuth 2.0 Authorization server.
1. When user is click on download SDK, New client registration is happened with Authorization server (WSO2IS). Earlier we need to login to Identity Server management console and did the registration. This is also the same, But here, Web application calls WSO2 IS Web service API to do the client registration. Web application passes client key as the user name of the user that is login to the web application. (Actually this is not much good. Authorization server must define the client key. Just to build sample, I have used like this)
2. After registration, Web application calls to token end point to generate an access token for the developer using client credential grant type.
If you go through source you can easily identify what is happening.
You can try this web application with WSO2IS (Any configurations are not needed at WSO2IS). I have tested web application in Tomcat 7. Please note, there are some configuration parameters that you need to configure in web.xml file according to your environment.