OAuth 2.0 Authentication for Office Add-ins

OAuth 2.0 is the auth standard behind almost every API an Office add-in might connect to: Microsoft Graph, Salesforce, Google, custom internal APIs, and any SaaS platform built in the last ten years. Implementing it correctly inside an Office add-in is harder than implementing it in a standard web app because the Office task pane is a sandboxed environment with restrictions on how popup windows work, where tokens can be stored, and what happens when the add-in is closed and reopened.

We implement OAuth 2.0 for two main scenarios. The first is Microsoft 365 authentication using the authorization code flow with PKCE via MSAL, the correct flow for add-ins that need to authenticate users against an Azure AD app registration without relying on the SSO getAccessToken approach. The second is third-party OAuth: connecting the add-in to a CRM, Google, HubSpot, or any other OAuth 2.0 provider using the authorization code flow and handling the callback, token storage, and refresh cycle within the Office add-in architecture.

Both scenarios require a server-side component for the token exchange. Storing OAuth tokens in localStorage inside the Office task pane is not secure and fails in some Office environments. We build the server-side token endpoint and caching layer so tokens are handled correctly and the add-in reconnects automatically after a session ends.

Every morning at nine, forty analysts at a market data firm re-authenticated their Excel task pane by hand. The add-in connected to a pricing vendor's OAuth-protected API, and whoever built it had stored tokens in the task pane itself, so each new Office session started logged out. Worse, the vendor's refresh tokens were being discarded. We moved the token exchange to a small server component, cached refresh tokens there keyed to each analyst's identity, and had the pane reconnect silently on open. Sign-in became a once-a-quarter event tied to the vendor's own token expiry policy. The same server layer later absorbed a second provider's custom API connection without touching the auth code again, which is the point of doing the plumbing properly the first time.

OAuth work is worth doing as its own engagement when tokens, refresh cycles, or popup handling are actively failing in an existing add-in, or when a build connects to several providers at once. If your add-in only ever authenticates against Microsoft 365, the standard silent sign-in path covers it and a separate OAuth project would be redundant. We check which situation you are in before quoting anything.