Disclaimer 
I am not an Azure expert. I just did a considerable number of Azure Functions with API Management, and troubleshooted all kinds of errors. Together it amounted to quite a compendium of testing/verification/troubleshooting steps. I wanted to share these with you and the future me :)




Design


Which app calls what? One of the first things to consider is the design you want to follow. The authentication flow you choose will decide what is authorised to what. Consider these two scenarios:


Diagram showing OAuth communication where audience is the backend.Diagram showing OAuth communication where audience is the API Management gateway.
Image source:  https://learn.microsoft.com/en-us/azure/api-management/authentication-authorization-overview


The first one is the most common scenario. Azure API Management is a "transparent" proxy between the caller and backend API. This is what most tutorials, guides and troubleshooters refer to. You can still configure policies in APIM to validate the token, and check other claims of interest extracted from the token, but the calling application requests access to the API directly. The scope of the access token is between the calling application and backend API
In the second scenario, the API Management service acts on behalf of the API, and the scope of the access token is between the calling application and API Management. The second scenario will be usually used when calling the backend API is not possible. For example, when the backend API does not support OAuth.



Authorization Flow


Make sure you understand authorization flow

Diagram that shows the process flow for creating runtime.
The client app needs to call API Management. If you can call your Azure Function directly, using only function code - it's not secured with OAuth.

RICHTIG - NICHT RICHTIG BILDER



API Management Policies



<inbound>
    <base />
    <set-backend-service id="apim-generated-policy" backend-id="provisionierungacco" />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Invalid token.">
        <issuers>
        </issuers>
        <required-claims>
            <claim name="aud" match="any">
                <value>7e5ff242-8d3a-46a9-8890-45722c2f3d27</value>
            </claim>
        </required-claims>
    </validate-jwt>
</inbound>

As per RFC definition  https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3 refers to the recipient of the access token:

The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case- sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL. 

In our case the recipient, or the audience, will be Azure Function


Tooling

Postman
Application Insights
Trace




See Also



Authentication and authorization in Azure API Management