Microsoft explains how to issue custom SSO claims in Entra ID using directory extension attributes

Microsoft has outlined a step-by-step method for passing custom user data to apps during sign-in, using Entra ID’s directory extension attributes. The process can help organizations include unique identifiers, such as sponsorship details, in SSO tokens for specific user groups.

In a recent guide, Microsoft showed how admins can register, assign, and map these attributes so they appear as claims in SAML or OIDC tokens, and only for selected groups.

Here’s how Microsoft suggests you to complete the process:

Step 1: Register Directory Extension Attributes

Use Graph Explorer to register two custom attributes, for example sponsorid1 and sponsorid2, in the target application.

Send a POST request to:
POST https://graph.microsoft.com/v1.0/applications/{AppObjectId}/extensionProperties

Request body example:
{
  “name”: “sponsorid1”,
  “dataType”: “String”,
  “targetObjects”: [“User”]
}

Repeat the process for sponsorid2. After registration, the system will return the full attribute names in this format:

extension_<AppClientID>_sponsorid1
extension_<AppClientID>_sponsorid2

Note these exact names for future use.

Step 2: Assign Extension Attributes to Users

Use Graph Explorer again to PATCH user objects and assign values to these extension attributes.

Request URL:
PATCH https://graph.microsoft.com/v1.0/users/{UserObjectId}

Request body:
{
  “extension_<AppClientID>_sponsorid1”: “ABC123”
}

Repeat this for each user, assigning the corresponding attribute (sponsorid1 or sponsorid2).

Step 3: Create Claims in Enterprise Application

Navigate to Entra ID > Enterprise Applications > [App Name] > Single Sign-On > Attributes & Claims.

1. Click Add new claim
2. Provide a name (e.g., sponsorClaim1)
3. Under Claim conditions, select Member and choose the group that should receive the claim
4. In the source attribute, use the directory extension attribute name (e.g., extension_<AppClientID>_sponsorid1)

Repeat for the second group and attribute.

Step 4: Handle Claim Mapping Error

If you see the error “Application requires custom signing key to customize claims”

You can temporarily bypass this by updating the app registration manifest:

“acceptMappedClaims”: true

This allows claims customization without custom signing keys.

Step 5: Test the Configuration

Call the application using https://login.microsoftonline.com/(Tenant ID)/oauth2/v2.0/authorize?client_id=(Client ID) &response_type=id_token&redirect_uri=https://jwt.ms&scope=openid&state=12345&nonce=12345 and sign in with users who belong to the defined groups. You should see the expected custom claims (sponsorid1 or sponsorid2) issued in the SAML or OIDC token in https://jwt.ms. Users not in any of the groups will not receive any sponsor claim.

Microsoft says this setup ensures sensitive or specialized data only reaches the right audience during sign-in, without exposing it to others.