[SOLVED] Migrating from validate-jwt to validate-azure-ad-token policy

Migrating from validate-jwt to validate-azure-ad-token policy

I've previously been using the validate-jwt policy successfully in a lot of projects. I would like to try out the new validate-azure-ad-token policy instead.

I changed one of my policies from:

<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
    <openid-config url="https://login.microsoftonline.com/{{tenant-id}}/v2.0/.well-known/openid-configuration" />
    <required-claims>
        <claim name="azp" match="all">
            <value>{{portal-clientId}}</value>
        </claim>
    </required-claims>
</validate-jwt>

To:

<validate-azure-ad-token header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid." tenant-id="{{tenant-id}}">
    <client-application-ids>
        <application-id>{{portal-clientId}}</application-id>
    </client-application-ids>
</validate-azure-ad-token>

The former works without any issues, but I just can't get the latter to work. The named value portal-clientId in both policy snippets above correspond to the applicationId of both the app registration and the enterprise app.

As you can see from the former, the value is in the azp claim. From jwt.ms, it sounds like this should be the correct claim for the new policy as well:

The application ID of the client using the token. The application can act as itself or on behalf of a user. The application ID typically represents an application object, but it can also represent a service principal object in Azure AD.

I've read both the Azure documentation and the article introducing the new feature, but I just can't figure out what I'm doing wrong. When tracing, the newer policy has the following to say:

validate-azure-ad-token (3.470 ms)
{
    "message": "Azure AD JWT Validation Failed: ValidationFailed."
}

Are there some hidden expectations in the new policy? My issuer in the token is https://login.microsoftonline.com/{{tenant-id}}/v2.0.

Viewing logs in application insights connected to this API yields no more useful information than the trace, even when activating verbose logging.

Any help would be greatly appreciated.

Solution

(Source: I am on the Azure API Management team and responsible for the APIM policy implementations).

Short version: Revert back to using validate-jwt (for now).

There are two issues here.

Your two statements are not equivalent. The client application ID is exposed in JWT as an audience. You are correct on the validate-azure-ad-token version and wrong on the validate-jwt version.
There is a current bug (that we are working on and will be fixed "soon") whereby the underlying library we are using for Azure Active Directory is not validating v2.0 tokens.