[Feature]: Enterprise authentication flow via Entra ID / MSAL NAA for organizational deployments

[Norris36]

Summary

Currently, office-agents uses static API keys (BYOK) or personal OAuth flows. This blocks enterprise/organizational deployment where:

• Users shouldn't be entering personal API keys
• The organization runs a self-hosted OpenAI-compatible backend with Entra ID SSO enabled
• IT needs to deploy the add-in centrally via admin manifest, not per-user sideloading

---

Background: Enterprise Backend Auth

Most self-hosted OpenAI-compatible backends support enterprise authentication via OpenID Connect (OIDC). The common authentication methods in this space are:

Method	Enterprise-relevant?	Notes
Local email/password	❌ Low	No org identity, self-managed
OAuth2 (Google, GitHub, Discord)	❌ Low	Personal social login
OIDC / OpenID Connect	✅ Yes	Entra ID, Keycloak, Okta, Authentik
LDAP	✅ Yes	On-prem directory
SAML	✅ Yes	Federated enterprise identity

Backends that support OIDC token validation (e.g. LibreChat) can already accept and validate tokens issued by Entra ID directly. The backend receiving end is therefore a solved problem for any OIDC-compliant service. The gap is on the add-in side.

---

Proposed Flow

User opens Excel
       │
       ▼
MSAL.js NAA acquires Entra ID token silently
(reuses existing M365 session — no prompt shown)
       │
       ▼
Token passed as Bearer header to configurable backend URL
(any OIDC-compliant, OpenAI-compatible endpoint)
       │
       ▼
Backend validates token via OIDC
User is authenticated — no API key required

Step-by-step

1. Add-in acquires token using MSAL.js Nested App Authentication (NAA) — Microsoft's current recommended approach for Office add-in SSO. It silently reuses the user's existing Microsoft 365 sign-in.
2. Token is forwarded as an Authorization: Bearer <token> header to a user-configurable backend URL in Settings.
3. Backend validates via OIDC. Any OIDC-compliant endpoint will work.

---

Why NAA Specifically

NAA is the current Microsoft-recommended path for Office add-in SSO, replacing the older OfficeRuntime.auth.getAccessToken() approach.

• Works in both desktop and web Office clients
• Silent by default — no login prompt if user is already signed into M365
• Falls back gracefully to interactive login if needed
• Scoped to the app registration — IT controls access via Entra ID

Reference implementation: OfficeDev/Office-Add-in-samples — NAA sample

---

What This Unlocks

Capability	Today	With this feature
Admin-deployable add-in	❌ Requires per-user API key setup	✅ Central deployment, zero user config
Org identity	❌ Personal API keys	✅ Entra ID / M365 identity
Access control	❌ Whoever has the key	✅ Entra ID app registration + group assignment
Audit trail	❌ API key-level	✅ Per-user, per-request via IdP
Works with self-hosted backend	✅ (custom endpoint)	✅ Same, but authenticated

---

Implementation Notes

Add-in side (packages/excel or shared auth package)

• Add @azure/msal-browser dependency
• Configure NAA in the Office manifest (<WebApplicationInfo> element with the Entra app registration client ID)
• Implement a getEntraToken() helper using PublicClientNext (the NAA-compatible MSAL client)
• Add a new provider option in Settings: "Organizational (Entra ID)" alongside existing BYOK options
• When this provider is selected, skip the API key field and use the acquired token for all requests

Backend side (user-configured)

No changes needed on the backend if it already supports OIDC token validation. The backend simply needs to accept Bearer tokens and validate them against the tenant's JWKS endpoint. This is standard behaviour for any OIDC-compliant service (e.g. LibreChat with OPENID_REUSE_TOKENS=true configured against Azure Entra ID).

Manifest addition required

<WebApplicationInfo>
  <Id>YOUR_ENTRA_APP_CLIENT_ID</Id>
  <Resource>api://localhost:3000/YOUR_ENTRA_APP_CLIENT_ID</Resource>
  <Scopes>
    <Scope>openid</Scope>
    <Scope>profile</Scope>
    <Scope>email</Scope>
  </Scopes>
</WebApplicationInfo>

---

References

• MSAL.js NAA documentation
• OfficeDev NAA sample (Excel)
• Example: LibreChat OIDC + Azure Entra ID configuration
• Example: LibreChat token reuse with Entra ID

[hewliyang]

Will leave this open for discussion but not planned for now.

I think in an enterprise setting you would want a client server architecture anyways to make data governance more ergonomic.