Microsoft Graph Api tenant Wide permission facade
Date Published

There's a pattern I reach for whenever a service needs Microsoft Graph but I don't fully trust it with the keys.
It's called the API Façade — but mostly I just call it "putting a function in front of it."
The Function App holds the broad Graph permission (say, GroupMember.Read.All — tenant-wide). The calling service holds exactly one permission: the right to invoke that function. Inside the function, my code decides what the caller gets to see.
The point is permission containment. The dangerous permission still has to exist somewhere — the call has to happen — but it lives inside one trust boundary I control, instead of being scattered across every service that touches Graph.
Three things this gets you:
→ Contained blast radius. If the caller's secret leaks, the attacker hits a narrow API. They can't enumerate the directory.
→ Business rules at the gate. Graph itself can't say "only this group, only these fields." My function can.
→ Reversibility. Pulling a client's access is one role unassignment — the function's Graph permission keeps working for everyone else.
It's not new architecture. It's not glamorous. But it's the difference between leaking a secret and leaking the tenant.
Designing a privilege access for tier 0 access. Principals ,ideas, and how to think through the process