JWT Token - O Auth similar to Cognito

Hello Kumar, Dheeraj,

Hey Dheeraj, it sounds like you’re trying to spin up a “client-credentials” style Azure AD app + service principal, call the token endpoint, and get back a JWT that contains your own custom fields (sub, deep_product, application, aws_account, iat, etc.)—similar to what Cognito can mint. Here’s how you can do that and the caveats around truly arbitrary payloads in Microsoft Entra ID:

Create your App Registration + Service Principal • In the Azure portal go to Azure Active Directory → App registrations → New registration – Name: e.g. “my-jwt-issuer” – Supported account types: your choice – Redirect URI doesn’t matter for client-credentials • Once created copy the Application (client) ID and Directory (tenant) ID • Go to Certificates & secrets → New client secret → note the secret value

Expose an API / define a scope • In your app registration, open Expose an API • Set Application ID URI (e.g. api://) • Click Add a scope, give it a scope name (e.g. “.default” or “access_as_app”)

Grant your app permission to itself (client credentials) • Still under Expose an API, click Add a client application and enter your client ID • Grant admin consent

Acquire a JWT via client credentials Call the v2.0 token endpoint:

POST https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=<CLIENT_ID>
&client_secret=<CLIENT_SECRET>
&scope=api://<CLIENT_ID>/.default

If all is well you’ll get back an access_token (a JWT).

Adding custom claims By default Azure AD will only emit: – Standard claims (iss, aud, exp, iat, sub, etc.) – Optional claims you’ve configured (groups, roles, etc.) – Any registered “app roles” or “directory roles” assigned to the service principal

Microsoft Entra ID does not let you plop arbitrary fields (like deep_product, aws_account) into the token purely through the portal. To enrich the token you have two main paths: a) Optional Claims – in the App Registration go to Token configuration → Add optional claim, choose from supported lists (groups, upn, oid, etc.). b) Claims Mapping Policy – using the Microsoft Graph (or AzureAD PowerShell) you can create a claimsMappingPolicy that takes extension attributes (or built-in ones) and maps them into JWT claims. Example snippet via MS Graph:

POST https://graph.microsoft.com/v1.0/policies/claimsMappingPolicies
{
  "definition": [
    "{\"ClaimsMappingPolicy\":{\"Version\":1,\"IncludeBasicClaimSet\":true,\"ClaimsSchema\":[{\"Source\":\"user\",\"ID\":\"extension_deepproduct\",\"JwtClaimType\":\"deep_product\"},{\"Source\":\"user\",\"ID\":\"extension_awsaccount\",\"JwtClaimType\":\"aws_account\"}]}}"
  ],
  "displayName": "AddDeepProductAndAwsAccount",
  "isOrganizationDefault": false
}

Then assign that policy to your service principal:

POST https://graph.microsoft.com/v1.0/servicePrincipals/{sp-object-id}/policies/$ref
{ "@odata.id":"https://graph.microsoft.com/v1.0/policies/claimsMappingPolicies/{policy-id}" }

After that, tokens issued to that SP will include your mapped claims.

If you need completely free-form JWTs (with any fields you like) you’ll typically: – Keep Azure AD issuing you a minimal access token – Front it with your own microservice or API Gateway (LiteLLM, Azure Function, etc.) – Have that layer mint its own JWT with all your custom payload

Hope that helps you get started!

Can you contact me on Teams and so that we can test it together. i have tried multiple option with no successful results.