How to Generate Token for Azure APIM Endpoint
Azure AD → Token → APIM → Backend API
Simple, real-world explanation for OAuth 2.0 & JWT in Azure API Management
Overview (Simple Explanation)
Azure API Management (APIM) does NOT generate tokens. Tokens are always generated by Azure Active Directory (Azure AD).
APIM’s job is to:
- Ask for a token
- Validate the token (JWT)
- Allow or block the API request
This guide explains everything step-by-step in a non-technical way.
Step 1: Register Client Application (Who Requests the Token)
This app represents Postman, Web App, Mobile App, or any client that wants to call your APIM endpoint.
- Azure Portal → Azure AD → App registrations → New registration
- Name:
My-Client-App - Click Register
From Overview, copy:
- Tenant ID
- Client ID
Go to Certificates & secrets → Create Client Secret
Step 2: Register API App (What the Token Is For)
This app represents your APIM-protected API. Every token must say which API it is allowed to access.
- Azure AD → App registrations → New registration
- Name:
My-APIM-API - Click Register
Expose the API
Go to Expose an API → Set Application ID URI:
api://<API-CLIENT-ID>
Add Scope
- Scope name:
access_as_app - Who can consent: Admins only
This scope tells Azure AD: “This token can be used to access my API.”
Step 3: Connect Client App to API App
Now we tell Azure AD that the client app is allowed to call the API.
- Open My-Client-App
- API permissions → Add permission
- Select My-APIM-API
- Choose Application permission
- Select
access_as_app - Click Grant admin consent
Step 4: Generate Token from Azure AD
Token is generated by calling Azure AD’s token endpoint.
POST https://login.microsoftonline.com/<TENANT-ID>/oauth2/v2.0/token grant_type=client_credentials client_id=<CLIENT-ID> client_secret=<CLIENT-SECRET> scope=api://<API-CLIENT-ID>/.default
Azure AD responds with:
- Access Token (JWT)
- Expiry Time
Step 5: Configure APIM OAuth 2.0
APIM needs to know where tokens come from.
- APIM → OAuth 2.0 + OpenID Connect
- Token URL:
https://login.microsoftonline.com/<TENANT-ID>/oauth2/v2.0/token
Step 6: Add JWT Validation Policy
APIM checks if the token is real and valid.
<validate-jwt header-name="Authorization"> <openid-config url="https://login.microsoftonline.com/<TENANT-ID>/v2.0/.well-known/openid-configuration" /> <audiences> <audience>api://<API-CLIENT-ID></audience> </audiences> </validate-jwt>
Step 7: Call APIM Endpoint
Now call APIM with the token:
GET https://<apim-name>.azure-api.net/myapi/endpoint Authorization: Bearer <access_token>
Flow:
- Client sends request with token
- APIM validates JWT
- If valid → forwards request to backend
Final Understanding (One Line)
Azure AD generates the token → APIM validates the token → Backend API returns data.
💡 Clarifications & FAQ
1. What is <API-CLIENT-ID>?
<API-CLIENT-ID> is automatically generated by Azure AD when you register your API App. You do not generate it manually. You can find it in Azure Portal under the API App registration's Overview → Application (client) ID.
2. How do I use <API-CLIENT-ID> in Azure?
- Go to your API App registration → Expose an API
- Click Set Application ID URI → Azure suggests
api://<API-CLIENT-ID> - Click Save
3. How do I create a scope for the API?
- Inside Expose an API, click Add a scope
- Fill the fields like this:
- Scope name:
access_as_app - Who can consent: Admins only
- Admin consent display name & description: Optional but recommended
- Scope name:
- Click Add scope
4. How do I use the scope when requesting a token?
Use the default scope format in the token request:
scope = api://<API-CLIENT-ID>/.default
This ensures Azure AD issues a token valid for all application permissions granted to your API.
5. How does APIM use <API-CLIENT-ID>?
APIM validates the token against the audience in its JWT validation policy:
<audiences> <audience>api://<API-CLIENT-ID></audience> </audiences>
If the token matches, the request is allowed; otherwise, APIM returns 401 Unauthorized.
6. Why are two app registrations needed?
One app represents the client (Postman, web, mobile app) requesting the token, and the other represents the API the token is for. This separation helps Azure AD enforce proper scopes and permissions.




