Managed or proxy: two ways to let a website read Microsoft 365

Why can a browser not just call Microsoft Graph?

Because the credential that makes the call would have to be in the browser, and anything in the browser is public. Reading a SharePoint library or an Outlook calendar on behalf of an organisation uses an application permission, and an application permission is exercised with the client credentials flow — an application id plus a client secret or certificate. Put that secret in page JavaScript and you have published it, to every visitor and every crawler, permanently.

Signing the visitor in instead does not rescue the design. A public website has visitors who have no account in your tenant, and the ones who do would be asked to authenticate to Microsoft before they could read a page — which is precisely the friction the page exists to remove.

The consequence is structural rather than a matter of care: the Graph call has to happen on a server. What is left to decide is whose server, and that decision is the whole of this article.

What is managed mode?

In managed mode the vendor owns the Entra application registration and holds its credential, and your Microsoft 365 administrator grants that application consent once. From then on the vendor requests an access token for your tenant, calls Microsoft Graph, and returns only the data the page needs.

• Who registers the application — the vendor. Nothing is created in your directory beyond the service principal that consent produces.
• What your administrator does — reviews the requested permissions and grants tenant-wide admin consent, once. There is no per-user prompt afterwards.
• What you can inspect — the consented application appears under Enterprise applications in the Microsoft Entra admin center, with its permission list, its sign-in activity, and a button that revokes it.
• What it costs you — a third party can, within the scopes you consented to, read that data without a further prompt. That is the trade, and it should be stated that plainly before anyone signs off on it.

Managed mode is the right default for most organisations, for an unglamorous reason: the alternative is infrastructure somebody has to run, monitor and patch, and an unmaintained gateway is a worse security position than a consented application you can revoke in one click.

What is proxy mode, and who actually needs it?

In proxy mode you stand up an HTTP gateway inside your own perimeter — an API Management instance, a function app, a reverse proxy, whatever your platform team already runs — and it is that gateway which holds the Graph credential. The vendor is configured with the gateway's base URL and an API key, and calls it instead of calling Microsoft. Graph traffic never leaves your network, and the audit trail is in your logs.

This matters to a specific kind of buyer rather than to everyone. If your security review has a line item that reads "no third party holds a token for our tenant", proxy mode is the only answer that satisfies it; managed mode does not, and no amount of encryption-at-rest language changes that. If your review has no such line, proxy mode is mostly extra machinery.

• Who registers the application — you do, in your own tenant, with whatever permissions your gateway needs and no more.
• Where the secret lives — in your gateway. The vendor holds an API key for the gateway, not a Microsoft credential, so revoking it revokes exactly one thing.
• What you inherit — availability. If the gateway is down, the widget on your website has nothing to render, and that is now your incident rather than the vendor's.
• What does not change — the embed on the page. The mode is an infrastructure decision, invisible in the markup and invisible to the visitor.

How do you choose between them?

One question settles it most of the time: would your security team sign off on a third-party application holding a token for your tenant? If yes, take managed mode and spend the effort on scoping the permissions tightly instead. If no, the answer was never going to be a better contract, and proxy mode is what the policy is asking for.

What does the access mode not change?

It does not change what the visitor sees, what the page contains, or what the component can reach. A component reads only the source it is configured against, and only within the permissions that were consented — narrowing the mode does not narrow the scopes, and widening the scopes is not made safe by proxying them.

It also does not change where the data ends up. In both modes the page is rendered from a live read rather than from a copy, so nothing accumulates a second store of your documents or your directory. Least privilege is a separate decision from access mode, and it is the one that actually bounds the blast radius.