Azure AD client credential flow - registering client applications for multiple client implementations

user_11607668 0
Viewed 303

I have an ASP.NET Core 6.0 web API which is currently deployed in an on-premise environment.

I am trying to protect the API with OAUTH 2.0 client credential flow using Azure AD as authentication server.

The clients that will be calling the API are external partners server (daemon) applications. There will be multiple clients, but each client will develop their own service to connect with my API. The requirement is to be able to set an authorization rule which would allow a specific partner to only send the data for its own resources. For instance - client A can only send documents for partners which are related to client A.

What I am struggling with is the right way to register client/clients in Azure AD. Should I:

  • register only one client app and add a credential (cert/secret) for each specific partner? In that case - what's the appropriate way to identify clients at API level - if only one ClientId is registered?
  • register multiple client apps - a new client app registration would be registered for each implementation. In that case - are there any availible resources that would help me to create a registration site which an external developer could use to self-register the client?

And another related question - what's the recommended way of getting authenticated ClientId of the caller in a client credential flow protected ASP.NET Core 6.0 web API controller? Right now i am checking the azp claim of access token. Is there a better way to identify the client that is calling the API?

msal microsoft-identity-platform azure-active-directory asp.net-core-webapi oauth-2.0
1 Answers

Interested to get an update on this as we have an almost identical scenario.

We have an API that our on-premise applications (tenants) will post some data to on a daily basis with the same authZ restrictions.

Current thinking is to issue a set of client credentials for each tenant but encode the identifier of the primary resource in to the clientId (e.g. TenantId_OurApplication_Client).

That way when the token is validated we can extract the client id and infer which resources they can access based on the encoded TennantId.

As for distribution of the client credentials, that's still a sticky wicket for us.Ideally we want it to be automated somehow.

I've taken a look at how secret distribution is achieved in commercial products like HashiCorp Vault. They issue short-lived ephemeral tokens that allow the tenants to download their own "permanent" client credentials.

Typically the short-lived tokens are injected in to the application at deploy time (if it's hosted by you!) then the application essentially bootstraps itself before the short-lived token expires.

This isn't possible for on-premise applications since it's installed/setup by the customer.

Current working proposal for this is to generate a TOTP (Time limited one time password) when a trusted user logs in to a portal or maybe an email when the top level resources are provisioned. They then enter the TOTP in to the application as a one time thing so the bootstrapping can occur. The TOTP is exchanged via an API endpoint for the client credentials.

Hope this helps!

user_7674280
Related