Part 1 of this series, [[Entra-Extensibility-Is-Control-Plane]], made the case that every Microsoft Entra extension point hands a piece of the Entra trust boundary to a system Entra does not own. The Azure resources that host that code sit on the Control Plane (in the modern Microsoft Enterprise Access Model, what the legacy tiered model called Tier 0). The Azure RBAC inheritance chain makes them dangerously easy to compromise from far up the management-group tree, and they deserve a placement and a guardrail set normally reserved for domain controllers and Entra Connect.
This article gets concrete. Two real extension scenarios, end to end, and then the question that decides the security of both: what credential does the extension use when it calls out?
Example A: a custom claims provider backed by an Azure Function
The first scenario is the one most likely to land in a production tenant in the next six months. A team needs to inject custom claims into the access tokens issued to their applications. The supported path is a custom claims provider, implemented as a REST endpoint that Entra calls during the token issuance event. The reference implementation is an Azure Function.
The flow, in one paragraph. A user signs in to an application registered in Entra. Entra's token issuance pipeline reaches the configured custom claims provider extension. Entra calls the Function App's HTTPS endpoint with a server-to-server access token in the Authorization header, exactly as documented in the step that covers protecting your Azure Function. The Function validates the incoming token (issuer, audience, signature), inspects the request body, calls whatever upstream sources it needs to resolve the claims it cares about, and returns a JSON response describing which claims to add to the outgoing token. Entra builds the access token, including the returned claims, and hands it to the relying application. The application makes authorization decisions based on those claims.
