CODEWITHSUNDEEP
authenticationoauth-2.0identityserver4identity
Dharmesh
Dharmesh

Reputation: 570

OAuth Client Credential Flow - Calling client details as claims

I have an Identity Server 4.0 implementation at my workplace. On top of Implicit and Auth Code flow, we are planning to use Client Credential flow for API to API call authentication.

There are few API that need to keep a log of who called it (the name of calling API). I have done a lot of digging but could not find a convincing (and secure) way of doing this.

In my understanding, in Client Cred flow, the client is going to IDS with just client secret. And obviously, this will make it practically impossible for IDS to know who is calling it. Am I right? Is there any way of knowing the client (so that some id claims can be added to the token)?

Any suggestions welcome.

EDIT: To elaborate my question and better explain my understanding of this particular OAuth flow:

Ok, so let me be clear. Let us say API X has to call API Y.

It follows the below order: (1) X goes to IDS with Client-Id and Client-Secret for Y. (2) IDS validates the Client-Id and Secret and issues an access-token to X (3) X calls Y with the given access token

In step (2) above, as per OAuth 2.0's client credential flow, there is nothing except Client-ID and Client-Secret that X is required to supply. Now, if API Z wants to talk to Y, it is going to go to IDS with the same Client-ID and the same Secret.

If IDS has no way of identifying if the authentication call is from X or Z, how can it add any additional claim in the issued token?

So the only other way for Y to know if the call is from X or Z is that X or Z telling themselves (in header or url or post data) who they are (which invalidates the entire purpose of authorizing through client-cred flow). Remember that my question doesn't talk about authentication.

Upvotes: 1

Views: 830

Answers (1)

user4864425
user4864425

Reputation:

There are two approaches: either use unique client credentials per instance (API X, API Z are seperate clients), or use the same clientid and / or leave it to the client to provide information.

With unique clientid's you can add information about the client as a claim in the ClientClaims table, e.g. Claim('ApiName', 'apiname').

This claim is added to the access token and is available in the receiving API.

In this scenario client credentials are used as id/password, allowing the client to 'login'.

The alternative is to use the same clientid for all API's. Now it's up to the client to provide information.

One scenario can be to issue apikey's that can be used to identify the client, e.g. a guid. You can send it along with each call.

In addition there is an alternative, add a custom endpoint. Don't use client credentials but implement your own endpoint.

With extension grants you can request the information you need and translate that to a valid access token.

Through the ExtensionGrantValidationContext object you have access to the incoming token request - both the well-known validated values, as well as any custom values (via the Raw collection)

Perhaps it's an idea to 'extend' the client credentials flow with an APIKEY.

Upvotes: 4

Related Questions