Authenticated access to Logic Apps using Azure AD

While writing an earlier post I realized one can require access to Logic Apps be authenticated via Azure AD. It is not as extensive as with Azure Functions but should be fine as long as you only care about Azure AD. This doc has the deets so I am going to try it out.

By default you can run a Logic App using access keys. This is present in the URL that’s generated.

Simply calling the Url as is lets you run the Logic App. And without the keys it fails.

Problem with keys is about managing them and ensuring they are rotated regularly etc.

To protect via Azure AD one need to go to the Authorization section and create policies.

The only claim you need here is the Issuer. This has to start with either https://sts.windows.net/ or https://login.microsoftonline.com/ followed by the ID of the tenant. Any other Azure AD claims can be used in addition to this.

These are the default “standard” claims available in the drop down. The Audience claim can be used if I create an App Registration associated with this Logic App and then users have to get a token for that App Registration (this is how Azure AD authentication for Functions work as in my previous post).

I am not sure how to use the Subject claim. An example of all the claims and their values can be found in the doc itself. I’ve copy pasted it below for reference:

I’ll keep it simple in this case and only require the Issuer claim. This means anyone authenticated against my tenant Azure AD can access this Logic App.

Next thing is to add an ‘Authorization’ header in the request trigger of the Logic App. This basically means add and set the operationOptions property to IncludeAuthorizationHeadersInOutputs in the code view of the Logic App.

(Update: In some subsequent testing where I forgot to add the above I realized that authentication via Azure AD works fine even without this property. Adding this property, however, makes the token available to the Logic App so you can slice and dice it like I did in a previous post to extract the claims if needed).

So that’s it on the Logic App side. As a client, I now have to include a token in the header while making a request to the Logic App. This is the standard bearer token stuff (a header called Authorization with the value Bearer <token>).

How do I get a token though? Typically you get it for an App Registration but that’s not the case here… I don’t have an App Registration. So I need something from Azure itself I suppose. Even Azure REST API needs an App Registration.

That said, I had recently learnt it is possible to get an Access Token for Azure via the Get-AzAccessToken cmdlet. So maybe I’ll try with that?

First I do:

This signs me into Azure PowerShell. Then I do:

This gives me the token:

Let’s try authenticating with that:

Hmm.

Upon a whim I checked the access token in jwt.ms and found the issue:

The issuer starts with https://sts.windows.net. So I changed that in the Logic App policy and tried again. That too didn’t work intially until I realized the actual Issuer claim has a trailing slash – https://sts.windows.net/xxx/ – and I had missed that. So I added it and now I was able to connect.

My Logic App is set to respone with the Headers it received so that’s why the output above has the token in it.

Digression

What’s the difference between sts.windows.net and login.microsoftonline.com? I’ve seen both but not paid attention to the difference. It looks like the former is for v1.0 Azure AD endpoints while the latter is v2.0 (according to StackOverflow) – or rather, the kind of token the Application is configured to respond with (v1.0 is sts.windows.net)? Also found this answer in GitHub which says the same; as well as this answer that explains things a bit more (screenshot of the answer below).

This too gives the impression the endpoint doesn’t matter, but what matters is the kind of token the Application is configured to respond with. This is Microsoft’s page on the advantages of v2.0 over v1.0 (no mention of the endpoint there either). I also found this blog post introducing v2.0 but that gives the impression the issuer will always be sts.windows.net for Azure AD (irrespective of v1.0 or v2.0).

So I am not a 100% sure but I think it’s safe to say create two Authorization policies for your Logic Apps – one with sts.windows.net as Issuer, the other as login.microsoftonline.com. Both will have the tenant ID so this way you can restrict to connections from your tenant.

Advanced Stuff

If I want to restrict the Logic App to groups of users I imagine I’d have to use an App Registration and limit its Service Principal to specific groups. Or I could use the custom claims feature and add the claims I am interested in. This is not scalable as I can only have 5 policies, and each policy only have 10 claims… so better to use the App Registration I suppose.

Update: Once Azure AD authorization is enabled SAS keys stop working. You get the following error if you try those:

Update 2: I have a follow-up post.