Protecting Azure App Services With Azure AD

This is going to be a nice short and sweet article, but one that I’ve felt the need to write for a while.

Many times when I’ve built small internal applications, hosted in Azure, there has been a need for some level of authentication. Pretty often, this is going to be against the clients Azure AD instance. I’ve seen people wrap themselves up in knots trying to use the “Microsoft Authentication Library (MSAL)” inside their code. Often this comes with many code changes, configuration, and banging your head along the way.

Sometimes that headache is unavoidable, but other times for your simple 5 page website, it’s just way overkill.

Did you know that you can set up Azure Authentication across a web application, from inside the Azure Portal, without any code changes what so ever? It’s really simple! Simply navigate to your Azure App Service and select “Authentication” under settings on the left hand menu

Next add an identity provider, as noted in the screenshot below, this can be Microsoft (Active Directory), Facebook, Google or Twitter.

The settings are fairly explanatory and work much like how you would set up app registrations within Active Directory normally (But this time it’s mostly done for you).

Once added, any access to your application will be forced to authenticate with your chosen identity provider.

Now you’re probably asking, what if I want to limit access to certain groups or users? Unfortunately Azure App Service only provides an “Authentication” service, it does not provide an “Authorization” service. So even though it can force users to login, it simply passes those claims through to your application to then validate if a user should or should not be able to access that page.

What this means in practice is that if you need complicated set up of roles and permissions.. Maybe the built in Authentication with Azure App Service isn’t right for you (Although it is definitely doable) as it somewhat disconnects the authentication and authorization pieces. However, what I’ve found is for small internal applications that we simply want to say “Anyone in an org can use, but not the public”, then this is a great little way of achieving that with zero code changes.

Leave a Reply

Your email address will not be published.