What I learned about Azure authentication

I’ve always been a sort of “meh” kind of guy. Heroku is “meh”. Digital Ocean is “meh”. AWS is “meh”. And so forth. Each of these providers allowed me to overcome some limitations from the previous one. But they also come with their own limitations, or rather, quirks

Now, a while ago, I had to move to Azure. Not forever, but for a specific project, for a specific client. The provider, while still being “meh”, offers a range of services rather similar to that of AWS. There’s a service to deploy a database, a service to run containerized applications, and a bunch of services around networking, so I managed to get stuff running there. And, let’s be fair, using Terraform to provision everything adds an extra layer of both documentation and confidence (someone actually reviewed what I was going to do).

What I was kinda eager to try out was the authentication wall that Azure offers for its Web App Service. Azure authentication, and the authentication for a lot of Microsoft services (as far as I know), relies on Active Directory. I used services using Lightweight Directory Access Protocol (LDAP) for authentication in the past, so while LDAP and Active Directory (AD) are different concepts, it was relatively easy for me to grasp the idea. Very simply, you create a user on AD, and then you can use that as a user database for your application. You can read more about it, but this is what matters for this post.

So, through setting up an Authentication Application, and connecting it to your Web App and your AD, you can make all users go through Microsoft’s (or Azure’s) authentication page — like the one when you go to outlook.com — before accessing your page. If the user exists in the Active Directory, great, otherwise he’s locked out. This allows me to not have to configure devise (is devise still the cool kid for authentication in Ruby on Rails apps?), and think of an authentication strategy — especially useful if the client already has a user base on AD because of other apps.

Microsoft AD authentication page

After the user authenticates, you receive a set of headers identifying the user, the AD account being used, and you can even configure the authentication application to add a token to use with Microsoft Graph (useful to fetch other information about the user, their groups, the tenant, and so on).

And again, the best part? It’s all configured through Terraform, so you can keep track of which apps are authenticating through this and what tokens are being added or not, without having to do anything manually through Azure Portal.

Code added to Terraform to allow for this flow

Adapting to Azure is still a work in progress, and even the flow above is subject to changes, but it’s certainly an easy way to add auth to your app on top of an already existing infrastructure — you can even use the groups and roles in AD to manage permissions in your app.