Securing Web APIs with Azure AD: A Case Study
Posts in this series:
- A Case Study
- Designing Authentication Schemes
- Authorizing Client Applications
- Building the Server
- Enabling Local Development
- Connecting External Clients
- Connecting Azure Clients
Recently, I was on a project where the company had a big push towards a "Zero Trust" security model. This concept was new to me, and I'd always been on clients where we had to secure APIs. What was quite a bit different with this approach was that previously, clients would typically not secure any kind of network-isolated APIs. If they had an app that was only accessible on a VPN or similar, it wasn't often the APIs themselves would have any kind of authentication/authorization.
Looking back, it seems pretty risky to do so (but I almost never get to make those sorts of decisions anyway). This particular client dealt with health data protected by HIPAA (and other) laws, so protecting this data was actually kiiind of important.
This client is also migrating from on-prem to Azure, as well as building new microservices in Azure as well (what my team was doing). With these changes, the security folks recommended a zero-trust security model using Azure AD for any internal . Great! But I hadn't implemented that model before, so we had to understand the ins and outs of Azure AD and how we would go about implementing this model.
Additionally, we had numerous scenarios to iron out, where we had several identity providers to worry about, existing systems, and an ongoing identity provider migration to a SSO solution with Auth0.
Azure AD has quite a lot of docs but we still needed to basically map its capabilities to our various use cases, enabling local development along the way. The end picture looked something like this:
The more modern customer facing applications were Angular applications using Identity Server to achieve some level of SSO between systems, migrating towards Auth0. The existing on-prem applications, some used cookie-based auth, s0me used SAML, but the end story is we didn't want to use any of those authentication methods for our APIs. We wanted to use Azure AD for any internal authentication/authorization needs so that our internal APIs did not get exposed to the messiness of applications at the edge.
We also looked at using either Identity Server or Auth0 for our internal authentication (using Client Credentials flows) but ultimately went with Azure AD because we had already built our security models for Azure resources around Azure AD using Managed Identities. Azure AD for other internal communication would simplify the security story in general. In this series, I'll walk through the design and implementation of Azure AD for these internal microservice APIs.