How to setup customer to obtain AADB2C token for an API exposed through APIM

Question

How to setup customer to obtain AADB2C token for an API exposed through APIM

curious7 281

I am setting up Azure APIM instance behind a Azure Application gateway. Developer portal will be exposed so external customers will be able to subscribe to products containing the APIs and obtain the subscription key that way. There will be approvals required for subscription.

I want to setup OIDC on top of the subscription key validation. For that I believe I have to setup a Validate JWT policy on the API in APIM, using this guide below and use scopes/roles:-
https://learn.microsoft.com/en-us/azure/api-management/validate-jwt-policy

And seems like I will have to setup client credentials flow for customers to be able to obtain token from AADB2C, using the below KB:-
https://learn.microsoft.com/en-us/azure/active-directory-b2c/client-credentials-grant-flow?pivots=b2c-custom-policy

Q1 - Firstly, is that the correct way of setting it up?

Secondly, with client credentials flow seems like customers will have to use the POST request (or PowerShell) like the one below to obtain the token:-

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy>/oauth2/v2.0/token

But this will mean that I will have to document my B2C token endpoint in Developer portal documentation to advise customers on how to obtain token. I have 2 questions related to that:-
Q2 - Is advising/advertising B2C token endpoint good practice from security point of view?

Q3 - With client credentials flow, setting up the calling app APP Registration in B2C and providing related APP secret will become a manual process. This will remove the benefit of having Product/API subscriptions process automated through APIM and bring in the complexity of securely communicating the secret to customers. Is there a better way of doing this?

0 comments

2 answers

Your answer

Answer 1

Q1. The approach is right. validate-jwt is the correct policy, since validate-azure-ad-token covers Microsoft Entra only, not B2C. Two corrections to the guide you linked.

You don't need custom policies. You've linked the custom policy pivot, which pulls in the Identity Experience Framework. The same page says:

"There are no specific actions to enable the client credentials for user flows or custom policies. Both Azure AD B2C user flows and custom policies support the client credentials flow."

Custom policies only matter at Step 4, if you want to inject extra claims into the token.

Second, the feature is still in public preview. Worth putting in front of whoever signs off the design.

Your instinct on scopes works cleanly. App roles defined with allowedMemberTypes: ["Application"] come back in the scp claim, so you can gate on them with required-claims.

Q2. No, because B2C already publishes it. Every user flow exposes an OpenID Connect metadata document at:

https://<tenant>.b2clogin.com/<tenant>.onmicrosoft.com/<policy>/v2.0/.well-known/openid-configuration

It's unauthenticated and already contains the token endpoint and your signing keys. Documenting it saves your customers a lookup. The credential is the client secret.

Q3. You're right that it's manual, and the reason sits in the flow itself:

"In the client credentials flow, permissions are granted directly to the application itself by an administrator."

Step 2.2 ends with Grant admin consent for your tenant, inside your B2C tenant, once per customer app. APIM subscription approval doesn't reach into B2C, and I can't find anything Microsoft ships that connects the two. If you want to keep self service, the only route I see is calling Microsoft Graph from your approval step to create the registration, assign the app role and grant consent.

A few details on the policy config

Roughly what the policy should look like:

xml

<validate-jwt header-name="Authorization" failed-validation-httpcode="401">
  <openid-config url="https://<tenant>.b2clogin.com/<tenant>.onmicrosoft.com/<policy>/v2.0/.well-known/openid-configuration"
                 validate-connectivity="false" />
  <audiences>
    <audience>{client ID of your API app registration}</audience>
  </audiences>
  <required-claims>
    <claim name="scp" match="any">
      <value>app.read</value>
    </claim>
  </required-claims>
</validate-jwt>

validate-connectivity="false" if your APIM is in a VNet. Given the Application Gateway in front, this probably applies to you. From the policy reference:

"If the API Management instance is injected or integrated in a virtual network and openid-config endpoint URLs are configured in the policy, set the validate-connectivity attribute to false to disable check of endpoint availability."

Leave it out and the policy fails a reachability check that has nothing to do with whether your tokens are valid.

Point openid-config at your b2clogin.com metadata document. The B2C example on that policy page still uses login.microsoftonline.com/tfp/..., which is the legacy host. Match the host you actually request tokens from.

The audience is the client ID of the API app registration, not the Application ID URI. The URI is what goes in the scope parameter of the token request. Two different values for what looks like the same thing.

Set accessTokenAcceptedVersion to 2 in the manifest if you reuse an existing app registration rather than creating a fresh one.

One last thing if this is a new tenant: B2C closed to new customers on 1 May 2025. Existing tenants carry on.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

curious7 281 Reputation points

2026-08-31T08:45:22.4566667+00:00

@SHOUMIK CHAKRAVARTY Thanks a lot for the information above. You mentioned that B2C client credentials flow is in public preview. But this video seems to have been created 3 years back and the creator explains the same process?:-
https://www.youtube.com/watch?v=gxPWRq9BteI

Does the video explain a different process? Or has this feature has remained in public preview for 3 years?

Also, for Question 2 do you mean that there is no harm in giving out the B2C token endpoint?
SHOUMIK CHAKRAVARTY 575 Reputation points

2026-09-01T04:36:10.37+00:00

I haven't watched it through, but going by what you describe, no, it isn't a different process. I checked the page again after your question. The preview banner is still there and the content date is October 2024, so it has genuinely stayed in preview the whole time.

Worth knowing alongside that: the B2C FAQ puts support at May 2030 at the earliest, with SLAs, security updates and compliance unchanged for existing customers. That covers B2C as a product, though. Preview features sit outside the SLA regardless, and Microsoft recommends against using them in production, so the caveat lands on this flow specifically rather than on B2C generally. It's a decision to document and get signed off rather than a blocker.

And yes, that's what I meant on Q2. Publishing the endpoint doesn't expose anything sensitive.

It's an address, not a credential. Someone who knows the URL and nothing else can't do anything with it. It's also already discoverable: the .well-known document is public, and any customer who has authenticated has called the token endpoint by definition, so they already have it. Putting it in your docs just saves them the lookup.

The client secrets are what needs to stay private, and those are per customer app anyway.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.
curious7 281 Reputation points

2026-09-06T12:16:24.2+00:00

@SHOUMIK CHAKRAVARTY @Andrew Taylor - COREZENN Thanks for the information above. The problem I see with client credentials is that, I will have to register a application registration per customer and give them the secret for this application registration. This will require secret renewal after expiry and manual steps. So, it becomes unmanageable for large customer base. Please correct me if I am misunderstanding something.

I was looking at this video, which shows different scenario's:- https://www.youtube.com/watch?v=JTKpunPpYi8. Scenario 3 in this one seems quite interesting which relies on user account but he has explained this process for the "Try me" function on developer portal, which has user interaction. But in my case it will be machine-to-machine. Is there anyway that can be used in machine-machine scenario?
SHOUMIK CHAKRAVARTY 575 Reputation points

2026-09-06T22:36:23.5866667+00:00

You're not misunderstanding. With client credentials in B2C, you really do end up with one app registration, one secret, and one renewal cycle per customer. B2C's token endpoint only supports client_secret_post and client_secret_basic, so certificates and client assertions aren't available. That's the limitation you're running into.

Going by how you've described Scenario 3, a user-account approach doesn't translate to machine-to-machine. The only user-based flow that works without interaction is ROPC, and that would require your customers' passwords and breaks as soon as MFA is enabled. A shared service account avoids the password problem but gives you the same "one secret per customer" issue under a different name. So that path doesn't solve it.

That leaves two workable options to evaluate.

1. Automate the client credentials flow

You keep the per-customer model but remove the manual work. Microsoft Graph can:

create the app registration

assign the app role

grant the consent

rotate the secret

Your customers still get a credential, but you're no longer doing the setup by hand.

2. Skip OAuth entirely

Your APIM subscription keys already give you:

per-customer identity

revocation

quotas

approval workflows

If the only thing client credentials add is scope-based authorization, you can enforce that in APIM policy instead and stay with a single credential per customer. For many B2C-backed APIs that ends up simpler and avoids the secret problem.

For reference, certificate credentials are supported on the Microsoft identity platform, just not in B2C.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

Answer 2

Hi @curious7

Thank you for reaching out to Microsoft Q&A. Great job sharing all the information; that is always a huge help.

Yes, for a server-to-server integration, using APIM subscription keys with OAuth 2.0 access-token validation is a reasonable defense-in-depth approach.

I would use the subscription key for product entitlement, metering, and the ability to suspend access at the APIM subscription level. I wouldn't treat it as the caller's primary identity: the APIM documentation notes that subscription keys are useful alongside another authentication or authorization mechanism, but are not strong authentication by themselves. Configure validate-jwt on the relevant API or product scope and validate the B2C token's issuer, audience, expiry, and required permission claim(s). The policy supports OpenID Connect metadata, audiences, issuers, and required claims.

See Authentication and authorization to APIs in Azure API Management and Validate JWT.

For Q2, documenting the token endpoint is expected for an OAuth client-credentials integration. The endpoint, tenant/policy, grant type, and scope=<API-application-ID-URI>/.default are integration parameters, not secrets. The B2C documentation shows this exact token endpoint pattern and request shape. What must remain confidential is the client credential. Do not put a client secret in the developer portal, browser-based test console, sample code, URLs, or support tickets. See Set up OAuth 2.0 client credentials flow in Azure AD B2C.

For Q3, there is no APIM setting that turns an approved product subscription into a B2C application registration and client secret. They are separate security objects with separate lifecycles. For each customer integration, I would normally:

Create a confidential client application registration.
Grant only the application's required API permissions/application roles and admin consent.
Require the corresponding scp claim at APIM; optionally validate azp against an allow-list of client IDs.
Deliver and rotate the client credential through a controlled onboarding process, independently of the APIM subscription key.

The B2C flow documentation requires a caller application, client secret, API application roles, and admin consent. If the onboarding must be automated, APIM supports delegating registration or product subscription to custom logic; in my view, that logic should initiate a separate audited identity-provisioning and secure credential-delivery process. It should not derive or reuse a B2C credential from an APIM subscription key. The APIM developer portal guidance describes this external API/SaaS pattern and delegation option: Secure access to the API Management developer portal.

One important planning point: B2C client credentials are documented as public preview. Also, Azure AD B2C is no longer available for purchase by new customers, although existing customers can continue using it. For a new long-lived implementation, I would assess Microsoft Entra External ID before committing to B2C. See the Azure AD B2C FAQ.

This assumes the customer application is a server-side confidential client. Client credentials are not suitable for an SPA or mobile application, where a client secret cannot be protected.

Please 'Upvote ' (thumbs-up) and 'Accept' as an answer if the response was helpful. This will benefit other community members who face the same issue.

Best regards, Andrew S Taylor