Client Credentials

Client Credentials

In this blog I would like to detail on "Client Credentials" OAuth2.0 grant type. This is more popular for authentication between applications hosted under same domain and usually one of them is Non-DMZ i.e. not exposed to internet.

It is typical to see this protocol applied by Financial Services Apps, wherein a Web UI Layer of application makes API calls basis "Client Credentials" protocol.

Let's try to understand with an example, we have an ABCD Bank which has a Web App for its customers. Web App as a layer of application has its Controls and event handling logic along with fair bit of Presentation and Orchestration logic in its piece of code this is technically hosted on a certain Web Server exposed to Internet. But it would seldom have data or core business logic hosted in the same server or developed under same code base.

You would certainly not want your KYC check logic coded inside a Javascript or a servlet (which is certainly more secure than Javascript), because
A] it makes it more vulnerable to attackers and
B] It is such a standard bit of process/algorithm you would want it to be centrally placed and be used by different Web channels/Apps of your Bank, without having to be rewritten in their own Servlets.

I hope I have built a case now to have a Business Logic Layer of Application which will contain the code for these standard algorithms and it would be exposed to the Web App through HTTP REST APIs. This would have its own Application Server.

Now to authenticate requests from Web App to API Layer we use Oauth2.0 "Client Credentials" code grant. So this is typically used when applications request an access token to access their own resources, not on behalf of a user.

The steps involved in this protocol as follows,

Request Parameters
grant_type (required)
The grant_type parameter must be set to client_credentials.

scope (optional)
Your service can support different scopes for the client credentials grant. In practice, not many services actually support this.

Client Authentication (required)
The client needs to authenticate themselves for this request. Typically the service will allow either additional request parameters client_id and client_secret, or accept the client ID and secret in the HTTP Basic auth header.

Example
The following is an example authorization code grant the service would receive.

POST /token HTTP/1.1
Host: abcdbank-server.com

grant_type=client_credentials
&client_id=ABCDID
&client_secret=X123tghk89

The use case above is for representational purpose only, this protocol can be applied between two different apps under same domain, or even across domains. But it is a general advise to use more secure and robust grant type while communication between two entirely different apps built and hosted on discrete domains, check this https://mytekstories.blogspot.com/2019/07/authorization-code-grant.html


Credits - https://developer.okta.com/ helped me understand these algorithms better
               https://tools.ietf.org/html/rfc6749 - Oauth standards