Showing Microsoft 365 data to visitors who have no Microsoft account

Can a public website display SharePoint, Outlook or directory data to anonymous visitors?

Yes, and the mechanism is that the server does the reading. The organisation's identity authorises the Microsoft Graph call server-side, the visitor never authenticates to Microsoft, and what reaches the browser is ordinary page data with no token attached.

12 August 2026 7 min read

Whose identity is used when a visitor loads the page?

The organisation's, not the visitor's. This is the distinction the whole design turns on, and conflating the two is why so many attempts at this end up either asking strangers to sign in to Microsoft or shipping a credential to the browser.

Identity of the application — used to authorise the Graph call. It is an application permission, exercised server-side, and it decides what data can be reached at all.
Identity of the visitor — used for nothing, in the ordinary case. A public page has anonymous readers, and the correct handling of an anonymous reader is to decide in advance what anonymous readers may see.

That "decide in advance" is the real security control. Publishing is a configuration decision — this library, this folder, these file types, this Graph filter, these fields — and everything outside it is unreachable by construction rather than by permission check.

A document library rendered from a live read: the folder, the files and their sizes come from SharePoint at the moment the visitor looks, and no copy is kept.

What must never reach the browser?

The client secret or certificate. Anything used to obtain a Graph token belongs on a server. There is no obfuscation that makes this safe.
The Graph access token itself. A token in page JavaScript is a token in the browser's network tab, in an extension's reach, and in any script the host page also loads.
Gateway credentials. In proxy mode the API key for your own gateway is exactly as sensitive as the Microsoft credential behind it.
Third-party keys with billing attached. A geocoding or maps key called from the browser is a key someone else can spend. Keys that must be browser-side have to be domain-restricted in that provider's own console.

The rule generalises: if a value would let someone reproduce your data access from their own machine, it belongs behind a request, not inside a page.

Is the data live, or is it a copy?

It should be live, and the reason is maintenance rather than purity. A copy is a second system that has to be kept in step, and keeping it in step is a job that quietly stops happening — which is how a staff page ends up listing someone who left eighteen months ago.

Reading at request time means the page is correct whenever the source is correct. Correcting a job title happens in the directory; correcting a document happens in SharePoint; the website follows without anyone editing it. That is worth more than the milliseconds a cache would save, and it is why a live read is the right default even when caching is available.

The exception is anything a visitor submits. A booking or a form response is not a read, and it needs a deliberate answer about where the permanent copy lives — a mailbox, a webhook, a calendar — rather than accumulating indefinitely in whatever system happened to receive it.

What stops someone copying the embed onto another site?

A domain allowlist, enforced server-side. The embed key that identifies a configured component is visible in the page markup — it has to be, it is in the HTML — so the control cannot be secrecy. It has to be that the server refuses to answer for an origin you did not list.

<script src="https://cdn.wpistatic.com/platform.js" async></script>
<wpi-documents embed-key="YOUR_EMBED_KEY"></wpi-documents>

Illustrative markup — the real snippet, carrying your own embed key, comes from the builder. The key resolves server-side to a configuration and a licence check; the host page carries no credential.

Two properties follow from that shape and are worth noticing. Everything about the component — which source it reads, how it is laid out, what colours it takes — resolves from the key at boot, so changing any of it later never means editing the page again. And because the resolution is a server request, licensing and the allowlist are checked on every one of them rather than trusted to the browser.

Does embedded third-party content hurt accessibility?

It can, and the failure lands on your domain rather than the vendor's. A widget with unreadable contrast, no visible focus ring, or a modal that cannot be dismissed from the keyboard becomes your accessibility defect the moment it is on your page, and an auditor will not care who wrote it.

Contrast — check the widget's own defaults against WCAG 2.1 AA, in both the light and dark presentation of your site, not just the one you designed in.
Keyboard — everything reachable by mouse should be reachable by tab, and focus should be visible at every stop.
Semantics — headings and landmarks inside the widget should still make sense when the page is read linearly by a screen reader.
Motion — prefers-reduced-motion should be honoured by the widget, not only by your own CSS.

Questions people ask about this

Do visitors need to sign in to Microsoft to see the content?

No. The Microsoft Graph request is authorised on the server with the organisation's own credentials, so the visitor receives ordinary page content and is never sent to a Microsoft sign-in page.

Is the embed key a secret?

No, and it must not be treated as one — it is visible in the page source to anyone who views it. What protects the configuration is the server-side domain allowlist and licence check, which refuse to answer for an origin you did not list.

Can we publish only part of a SharePoint library or directory?

Yes, and that is the intended way to use it. A folder path pins the root of a document browser, an extension allowlist hides everything else, and a Graph filter narrows a directory to one department — so the public view is a deliberate subset rather than everything the permission could reach.

Does the data get copied onto the vendor's servers?

It should not, and with WPIntegrate it is not — components read Microsoft 365 at the moment the visitor looks rather than synchronising. Form responses are passed to the destination you configure without a copy being kept, and a booking is written into your own Microsoft 365 as an appointment.

Still the wrong answer for your case? Then the case is worth hearing.

These articles describe the general shape. Tenants differ, policies differ, and the interesting questions are the ones where the general shape does not fit.

Ask us directly See the components