We need to create an API in Azure API Management and allow only known, registered applications to call it. We can require authentication, which restricts access to only people in our AAD, but how can we ensure that only certain applications can call the API? I know (a little) about clientIds and secrets, but those are submitted from the client, which means they can be grabbed and used, for example, by someone knowledgeable and using Fiddler. We need all AAD users to be able to use the applications, so we can't restrict by user, and we need these accessible both on and off the corporate network so can't restrict by IP address. What can guarantee that our API is only accessed by the applications we designate?
Asked
Active
Viewed 348 times
2
-
Welcome to the long, long, long line of questions asking (in essence) how to implement DRM. In short, you can make it harder, but you cannot make it impossible. You don't even need to be knowledgeable or need special tools to do this either - you can grab requests straight out of your browser's network tab and replay them however/wherever you want. – Conor Mancone Feb 11 '21 at 00:51
-
Note that you should never assume that one of your authorized client applications is the one making the call - your API should validate that the caller (that is, the AAD user) is authorized to call whatever operation and access whatever relevant data. At that point, whether or not it's an authorized application is quite possibly irrelevant, since it doesn't enable anything new. The authorized applications are then just for convenience. – Clockwork-Muse Feb 11 '21 at 06:00
-
Thanks, but we can't restrict based on userID or IP address (see above). All authenticated users could perform the operation *if* they're doing so from the known app. Unfortunately, I don't get to write the business rules...I'm just the lucky soul who gets to implement them... – TimTheEnchanter Feb 11 '21 at 11:30
1 Answers
1
Short answer: you cannot.
As soon as you ship a secret to the client, the secret is not secret anymore. No matter how many layers of obfuscation you employ, if the application somehow have access to the secret, the attacker have access too.
The only way to protect the API is to only run it server-side, and offer the service for your clients from the server.
![](../../users/profiles/54284.webp)
ThoriumBR
- 50,648
- 13
- 127
- 142
-
We've discussed adding a web app in between the client and the API, but I don't see how that helps. If the client can connect to the web app and ask it to use the API on its behalf, can't an attacker do the same thing? How would the code running on the server differentiate a legitimate request from a valid app, from a request from some other, invalid app, or submitted via Fiddler? – TimTheEnchanter Feb 11 '21 at 01:02
-
@TimTheEnchanter - Because, assuming you control **all** the endpoints connecting to the API, you can make it so that only your designated endpoints can connect in the first place. In this sort of situation, the API is on a virtual network containing it and the relevant applications, and isn't exposed to anything else. – Clockwork-Muse Feb 11 '21 at 05:49
-
The app is a React app running in an Azure web app. It has to be publicly available (i.e not on the corporate network) but it does require authentication. If I understand things correctly, this means that we don't control all of the endpoints - correct? – TimTheEnchanter Feb 11 '21 at 11:34