Security architecture

Dockli is a Windows desktop app that surfaces your Microsoft 365 file estate inside File Explorer. Everything below the surface is designed around a single principle: the part of the app you can see never holds anything worth stealing. No access token lives in the UI, no file content is copied out of your tenant, and the only network surface Dockli exposes is bound to loopback on your own machine.

This page is the map. Each layer is summarized here and covered in depth in its own article, linked inline.

The four moving parts

Dockli is composed of four cooperating pieces on the user’s machine, plus Microsoft’s cloud on the far side:

1. The File Explorer shell extension (DockliShellExt.dll, native C++). A per-user Windows namespace extension that adds the Dockli entry to the Explorer navigation pane and hosts a WebView2 control to render Dockli’s interface inside Explorer.
2. The WebView2 UI (a React single-page app). It is served from a local virtual host, https://app.dockli.local, mapped to the bundled front-end assets. This is the only surface the user interacts with — and it holds no Microsoft access token.
3. The local service (a headless ASP.NET Core / Kestrel process). It binds to loopback only — http://localhost:5050 — owns authentication and the token cache, and brokers every Microsoft Graph call on the user’s behalf.
4. Microsoft Graph and Microsoft 365. Where your files, sites, mail, and calendar actually live. Dockli reads and displays them live; it does not copy them elsewhere.

File Explorer (shell extension, C++)
   └─ WebView2  →  UI at https://app.dockli.local   ← holds NO token
                        │  (loopback HTTP, CORS-restricted)
                        ▼
             Local service on http://localhost:5050  ← owns the token
                        │  (delegated Graph token, server-side only)
                        ▼
             Microsoft Graph / Microsoft 365

Why the UI holds no token

The WebView2 UI talks only to the local service on http://localhost:5050. When the UI needs data — a folder listing, a file’s version history, a search result — it calls that loopback API, and the service attaches the Microsoft Graph access token server-side before forwarding the request to Microsoft. The token is minted and refreshed by the Microsoft Authentication Library (MSAL) inside the service and never crosses back into the browser context.

The practical consequence: there is no bearer token in front-end memory, in localStorage, in a cookie, or on the wire between the UI and the service that an attacker could lift. The trust boundary is the loopback interface, exactly like every other request path in the app.

See Authentication and tokens for how sign-in and token handling work end to end.

The network posture is loopback-only

The local Kestrel host binds exclusively to http://localhost:5050. Nothing Dockli runs is exposed to your LAN, reachable from another device, or bound to a routable interface. The API surface exists only for the local UI.

Cross-origin access to that loopback API is fail-closed. The service trusts a fixed, hardcoded allowlist of origins and nothing else:

• https://app.dockli.local — the shipped WebView2 virtual host
• http://localhost:5050 — loopback tooling on the API port
• http://localhost:5173 — the developer Vite dev server (used only during development)

The CORS policy is uncredentialed by design — cross-origin requests carry no cookies, because the Graph token lives server-side in the encrypted MSAL cache, not in the browser. A bad or empty configuration cannot widen this: the shipped origin is compiled in so the app can never lock itself out, but nothing else is added unless it is an explicit, trusted loopback origin.

Encryption at rest

The MSAL token cache is written to %LocalAppData%\Dockli\Data\msal_cache.bin and is encrypted with the Windows Data Protection API (DPAPI) scoped to the current user (DataProtectionScope.CurrentUser). The cache is readable only by that Windows user on that machine; copied to another machine or opened by another user, it fails to decrypt and Dockli simply starts fresh. Details in Authentication and tokens.

Least-privilege, delegated access

Every permission Dockli requests from Microsoft Graph is delegated — Dockli acts as the signed-in user, never as itself, and can never see or touch anything the user couldn’t already reach in Microsoft 365. Access rides on the user’s existing permissions and never widens them.

The base scope set is deliberately minimal, and higher-risk capabilities (sending mail, Teams messaging, people lookup, SharePoint recycle bin) are requested incrementally — only the first time a user actually uses that feature. See Permissions and scopes for the full list and Tenant-wide admin consent for how an administrator approves them once for the whole tenant.

Where your data lives

File content stays in Microsoft 365. Dockli reads and displays it live through Graph and does not copy files to any Dockli or third-party server. The only things persisted on the local machine are a small set of state files — the encrypted token cache, an accounts list, settings, and per-account preferences — all under %LocalAppData%\Dockli. See Data handling and residency.

Guarantees, by architecture

These properties are not policy promises — they fall out of how the app is built:

What Dockli deliberately does not do

• It does not run a cloud service that holds your Graph token or your files.
• It does not embed the access token in the browser, a cookie, or client-side storage.
• It does not open any network-reachable port — the API is loopback-only.
• It does not request application (app-only) Graph permissions; every scope is delegated.
• It does not ship third-party analytics SDKs (no Application Insights, no Sentry) in the backend.

Where to go next

• Sign-in and token lifecycle → Authentication and tokens
• The exact Graph scopes and why → Permissions and scopes
• What is stored where → Data handling and residency
• The AI trust model → AI security
• Publisher verification and compliance → Compliance