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.
(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.