Additional Claims in JWT Tokens via Claims Mapping Policy

Recently I was asked how to add additional claims for a user in the JWT token that Azure AD generates. The case was that the JWT Token should include the sAMAccountName from Active Directory. After spending too much time looking at the documentation for Optional Claims in Azure AD and trying to get that to work, I switched to the Claims Mapping Policy which is in preview. The reason for the switch was basically that Optional Claims is for adding extra attributes that you define on a per Azure AD Application level, not for including standard attributes that is synchronized via Azure AD Connect.

Claims Mapping Policy

A Claims Mapping Policy is an object that you create and apply on an Azure AD Application registration. The policy is a definition of extra claims you want to include in the JWT token that is generated when doing an OAuth authentication towards the App. In my test Azure AD tenant, I’ll illustrate this by adding the attribute JobTitle to the JWT token. Why JobTitle of all attributes? Well, I don’t have sAMAccountName available since my test tenant isn’t synced with an on-prem AD, so I had to pick something else.

The policy definition is a JSON document that looks like this. Source = user indicates that the attribute exists on the user object. Other sources, like application, company, transformation are explained in this article

If you where to include an extension attribute, synchronized via Azure AD Connect, it would look like this. The source is still user, but we use the ExtensionID instead and the value of the extension id is usually in the format extension_{guid}_<name>. The best way to get the value is via Graph Explorer and run the query<>

Applying the Claims Mapping Policy

Applying the policy requires powershell and the Azure AD cmdlets. As mentioned in the documentation (see link above), you need to install the preview release to make this to work Once you’ve installed that, you logon and import the preview module.

Creating the policy is just a few lines of powershell code. The code checks to see if you already have a policy and removes them first. Then the code creates the policy and applies it to the Application

Update the Application Manifest

Even though you have created the policy and applied it to the Application, the Manifest must be updated to tell that you are allowing mapped claims to be part of the token. The attribute “allowMappedClaims” attribute must be set to true.

The documentation also mentions that you need to upload a certificate as a signing key, but that is incorrect. That was required in the past and the preview have done away with that requirement.

You may get the error message “AADSTS50146: This application is required to be configured with an application-specific signing key.” but it has nothing to do with the certificate and it is not needed anymore. What the error message is telling you is that there is something wrong with the policy.

Testing that it works

I used this sample application from Office365 samples on Github

In the OAuthBasic.cs I changed the code to this to make it logging on to Azure AD and my Native Application

I also made some minor modifications to the source file AuthenticationCodeGrantFlow.cs in order to request access to the application as the resource and to have some error handling. The reason I call the AquireTokenWithResource with the AppID is so that I get the added claim in the access_token and not just the id_token.

Running the Windows Console application and logging on to my Azure AD account gives this output. As you can see the Claims Mapping Policy have kicked in and the attribute JobTitle is part of the claim.