Authenticated access to Azure Functions using Azure AD (Client Credentials Grant) – an update

An update to an earlier post. I hadn’t done one of these in a while and looks like things have slightly changed.

When setting up Entra ID authentication for an Azure Function app there are some additional options:

No additional info on what these settings are in the docs either. I think it ties in to the authorization policy (which I came across in this doc).

Apparently you can only set these up via the API or ARM templates, but I guess the doc is outdated and you can now do this via the portal too.

Here’s what I understand these settings to do. (I haven’t tested all this, so take this with a pinch of salt. As with all things in this blog, the posts are mainly as a reference for my future self ☺️).

First this one:

When you enable Entra ID authentication for a Function App it creates an App Registration in Entra ID. Users can login to that application and use the token they get from there to authentication against the Function App. I go into how I do this in an older blog post.

By default the “Client application requirement” setting is set to “Allow requests only from this application itself”. And that basically allows the authentication flow above.

What you can’t do with this is the kind of authentication flows I talk in another blog post wherein I have other App Registrations (or applications) authenticating against the App Registration the Function App. If you want to allow such authentication flows the second and third options are what you need.

“Allow requests from any application (Not recommended)” basically says any App that is allowed to authentication against the Function App’s App Registration is allowed to access this Function App. Nothing wrong with that, coz you can control what Apps can authenticate against the Function App’s App Registration on Entra ID. You create App Roles basically:

And then on each App Registration that needs access to this App Registration you have to consent to it.

So, technically, even though the setting says “Allow requests from any application (Not recommended)” not any application can access your Function App – an Entra ID admin has to consent to them. But.. you are now depending on a different team to manage access to your Function App. What happens if the Entra ID admin creates a new App Registration and consents to it without your knowledge – that app now has access to your Function! By being able to control things on the Function App side, you now have some control on this. Apart from an Entra ID admin consenting to an App Registration, you too can whitelist it on the Function App. (That’s my take on this setting at least).

And that’s what the second setting says. “Allow requests from specific client applications”. Select that, and you are able to give the client Ids of the App Registrations that are allowed access.

Neat, huh!

When looking at the claims sent to the Function App, this id is in the azp or appid claim.

On to the next setting:

From what I understand this is the service principal. An App Regisration has a corresponding Enterprise Application – it’s Service Principal. So this setting defines what Service Principals can access the Function App. I am not a 100% sure why one would use this. One use case I can think of is Managed Identities. Maybe it’s also for a use case when a user signs into an App Registration and that has access to the Function App’s App Registration, and you want to limit it to certain users? I don’t know…

In the JWT claims, this is the oid claim.

You can mix both requirements too. If both client application and identity requirements are specified, then both must be satisfied. (I will update post in the future if I learn more on this).

As in my older post, after enabling the Entra ID authentication for a Function App, one must go to the settings and remove this “v2.0” bit.

Else you get an “You do not have permission to view this directory or page.” error when trying to get a token from the Function App middleware. This is because the issuer claim in the JWT token does not have “v2.0” in it.

Update (11th August 2024): Whoa, this blog post made it to the Entra ID News #57.