CODEWITHSUNDEEP
openid-connectidentityserver3
Centrifugal
Centrifugal

Reputation: 46

WebAPI Mixing Implicit Flow and Client Credentials Flow

I have a WebAPI solution that secures it's controller methods via the [Authorize] attribute. It verifies that a given user has the appropriate roles, which are basically claims that come from an IdentityServer3.

There are several single page application clients that interact with this WebAPI, and the client users are authenticated/authorized using implicit flow.

So far pretty standard and simple, it all works fine...

Now I have a need for background process to make calls to this same WebAPI. This effectively becomes machine to machine communication. Based on all the documentation I have read this is a situation for Client Credentials flow. No users are involved.

The problem...

Given that no user is involved, this also means no subject, no claims and obviously no roles. If I am not mistaken a client does not have claims. Since my controller methods are secured by roles, how then can a client such as this be authorized to use the service/resource?

I read that a client should have only one flow, but what about a resource? The flow used by client shouldn't be important to the resource, except that the access token will have no claims depending on the client flow. So in that context the flow is also relevant to a resource when it is secured by claims. Am I confused?

Should I create a new service specifically for client credentials flow? Rig the identity server to support claims on clients?

I am looking for best practices here.

Edit

Please also refer to this Github discussion... Issue 76

If the subject is null - there is no human involved.

We are not planning to have claims for clients. The client identity and scopes should be enough.

leastprivilege

Also refer to... Issue 79

Well - in general a client should only have one flow since it can result in security problems if the wrong combination of flows is configured (e.g. code and implicit).

leastprivilege

Upvotes: 3

Views: 1865

Answers (1)

Karthik
Karthik

Reputation: 3155

You may not exactly match the user-role claim (fine-grained authorization) in Client Credentials flow but there are few workarounds:

  • Use the Scope claim issued to the Client for making authorization decision (refer to this Identity Server documentation - Specifically under Registering a Web API )
  • Based on the Audience ("aud") claim in the access token, you may waive the authorization decisions that you usually check for user tokens

Also have a look at the Token Introspection (and the associated video posted by Dominick) for further understanding. This also outlines the role of resource server.

Upvotes: 0

Related Questions