401 Unauthorized on a linked function app HttpTrigger, authLevel=function

[Krolken]

Describe the bug

I have a linked function app to a SWA. This works great. I set the authLevel to anonymous and it works perfectly with the SWA.

But now I want to add some other triggers than just the SWA. For example responding to a Zapier webhook. So I create a new function with a HttpTrigger and sets the authLevel to function. But when testing (from Postman) I only get 401 unauthorized when I provide the auth key. Both function key and host key.

Expected behavior Be able to use function access keys on functions that are marked as access level function from outside of the SWA, when I have an identity provider set up.

Context Am I supposed to be able to access other functions in a function app when the app is linked to a SWA?

Here: https://docs.microsoft.com/en-us/azure/static-web-apps/functions-bring-your-own#security-constraints it says that if I have not set up a security provider the Static Web App has exclusive access to my API.

I set up an Azure AD provider but still could not use the functions with function keys.

I know that function keys is not the most secure way of auth, but for some integrations I have no choice.

Or is the intended way this is supposed to work is that I set up a stand alone function app and then create managed functions in the SWA to proxy the functions I need to call in the SWA.

[Krolken]

I might have been confused about the wording in the documentation / Azure UI.

If I use the settings "Allow unauthenticated requests" for the identity provider and have authLevel=Function I still need to provide an API key to access the function.

This seems like what I need. But I am unsure if I also then need to provied the API key when authenticated with AD

[ngoquoc]

I'm encountering the similar issue: all of my functions are decorated with HttpTrigger(AuthorizationLevel.Function... and SWA can not reach to any of functions because of 401 Unauthorized. I'm wondering if my configurations in the "Authentication" of function app are proper, although it's generated by "linking" the function to the SWA:

Changing all functions to AuthorizationLevel.Anonymous just does not sound right to me because functions could be accessed by other audiences, not only SWA.

[Krolken]

As I understand it now is that adding an identity provider is adding an extra authentication layer on top of the normal Function Auth.

To me this seems like something you don't want. I couldn't figure out how you would use this.

I ended up with setting up a separate Function App for all my functions. I did not link this to my SWA. Then I set up functions as managed functions in my SWA project that just proxy the request to my stand alone Function App.

Then I can use our internal Active Directory to authenticate users in the SWA but all functionality in our functions is not bound to the AD auth. The managed function use a token for authentication against the Function App. So I am now free to have any other triggers, like external webhooks, to start other workflows in the Function App.

I found this the most sane approach. Everything else required alot of work.

[ngoquoc]

Thanks for sharing your solution! Unfortunately in my situation I can not afford such latency caused by proxying managed function to the "actual" functions (this is just my assumption though, not sure how much latency it would be).

Just to share some of my findings: I have changed all of my functions to AuthorizationLevel.Anonymous, and it can work fine with the SWA now. The interesting part is it still requires authentication if I tried calling directly the functions via function URL (not SWA endpoint). Probably this is the "exclusive access" the documentation mentioned :) I see that I can add some other identity providers (OAuth2 or OIDC for example) to the Function app authentication, probably that's the proper way to allow other audiences (web hooks or other API consumers) to access the inner functions.

[Krolken]

Yeah it will add the authentication on top of Function Auth. You can set the functions to AuthorizationLevel.Function with AD auth. You just have to add the auth key also on every request.

I am running the Function App in a Premium plan an see no real latency compared to consumption plan when proxying.