Allowing Client Credential Flow only with Certificate Credentials

I decided write in short blog post about a simple way to increase the security of JWT Validation Policy in Azure API management.

When dealing with OAuth2 Client Credentials flow in Azure AD; You have typically two options for Authentication: 1. Using Client Secret (a string),

or

2. using Client Certificate (Signing the specific Jwt token with private key to receive access token from azure ad) – This blog will outline a way to ensure in API management that the second option was used to gain the token used in calling the API

Background

I have written previously about the benefits using Client Certificate, so this post will focus only implementation side.

• You can read the previous post for context here and below for recommendations outlined by Microsoft documentation sources regarding the use Certificate Credentials in Microsoft Identity Platform best practices.

Recommendations on using Certificate Credentials

• Security Checklist of Microsoft identity platform best practices and recommendations

”There are two types of authentication available for service principals: password-based authentication (application secret) and certificate-based authentication. We recommend using a certificate, but you can also create an application secret.”

• Azure AD Integration assistant

API Management

I’ve seen often scenarios where API management validates credentials used by system, not in user context; in these examples OAuth2 Client Credentials flow is typically used.

Implementation

Since we can’t control the creation of weak client secrets in the first place (We surely can audit them though) it’s best to validate the use of Certificate Credential in the API management side; This can be achieved by validating that the signed JWT token includes ’appidacr’ (v 1.0 tokens) or ’azpacr’ (v2.0 tokens) claim, which Azure AD issues only when Access Token is requested successfully with Certificate Credential

Example

Azure API Management Policy

• Claim value of ’appidacr’ is checked in API management policy for the JWT Token
• It’s of paramount importance to check the appid claim for many reasons not written here, but most specifically to limit the amount of clients that will be authorized by the policy.

<validate-jwt header-name="Authorization" failed-validation-httpcode="401"
failed-validation-error-message="Unauthorized - Failed policy requirements, or token is invalid or missing.">
    <openid-config
        url="https://login.microsoftonline.com/3d6e366f-9587-413b-ab6b-0a851b1b91ba/.well-known/openid-configuration" />
    <audiences>
        <audience>https://myapi.dewi.red</audience>
    </audiences>
    <required-claims>
        <claim name="appid" match="any">
            <value>1105ae9f-6be2-42a2-9439-7a17934226ac</value>
        </claim>
        <claim name="appidacr" match="any">
            <value>2</value>
        </claim>
    </required-claims>
</validate-jwt>

Successful policy validation

• Client Uses Certificate Credential to fetch Access token via Client Credentials Flow and calls API management then
• Token includes the expected claim ’appidacr’, API managements ECHO API responds with 200, and echoes the payload.

Unsuccessful policy validation

• Client Uses Password Credential to fetch Access token via Client Credentials Flow and calls API management then
• Token includes the expected claim ’appidacr’, API managements ECHO API responds with 200, and echoes the payload.

Ending thoughts

If there is single most important actions for first stage policy for Azure API management, then better have JWT validation quite near that list.

Br Joosua!