CODEWITHSUNDEEP
asp.net-web-apimigrationazure-active-directory
Robert MacGrogan
Robert MacGrogan

Reputation: 357

Authenticating External System Connections to Web API with Azure AD

I'm trying to figure out how to migrate a system that is currently using ACS to Azure AD. I've read the migration docs provided by Azure and have looked through the Azure AD docs and the sample code but I'm still a bit lost as to what the best approach for my situation would be.

I've got a web API that has about 100 separate external systems that connect to it on a regular basis. We add a new connections approximately once a week. These external systems are not users--these are applications that are integrated with my application via my web API.

Currently each external system has an ACS service identity / password which they use to obtain a token which we then use to authenticate. Obviously this system is going away as of November 7.

All of the Azure AD documentation I've read so far indicates that, when I migrate, I should set up each of my existing clients as an "application registration" in Azure AD. The upshot of this is that each client, instead of connecting to me using a username and password, will have to connect using an application ID (which is always a GUID), an encrypted password, and a "resource" which seems to be the same as an audience URL from what I can see. This in itself is cumbersome but not that bad.

Then, implementing the authorization piece in my web API is deceptively simple. It looks like, fundamentally, all I need to do is include the properly configured [Authorize] attribute in my ApiController. But the trick is in getting it to be properly configured.

From what I can see in all the examples out there, I need to hard-code the unique Audience URL for every single client that might possibly connect to my API into my startup code somewhere, and that really does not seem reasonable to me so I can only assume that I must be missing something. Do I really need to recompile my code and do a new deployment every time a new external system wants to connect to my API?

Can anyone out there provide a bit of guidance?

Thanks.

Upvotes: 0

Views: 163

Answers (1)

juunas
juunas

Reputation: 58823

You have misunderstood how the audience URI works. It is not your client's URI, it is your API's URI.

When the clients request a token using Client Credentials flow (client id + secret), they all must use your API's App ID URI as the resource. That will then be the audience in the token. Your API only needs to check the token contains its App ID URI as the audience.

Though I want to also mention that if you want to do this a step better, you should define at least one application permission in your API's manifest. You can check my article on adding permissions. Then your API should also check that the access token contains something like:

"roles": [
  "your-permission-value"
]

It makes the security a bit better since any client app with an id + secret can get an access token for any API in that Azure AD tenant. But with application permissions, you can require that a permission must be explicitly assigned for a client to be able to call your API.

It would make the migration a tad more cumbersome of course, since you'd have to require this app permission + grant it to all of the clients. All of that can be automated with PowerShell though.

Upvotes: 1

Related Questions