OWA Add-ins Cannot Restore Sessions Across outlook.office.com ↔ outlook.cloud.microsoft

[mikhalonok]

Provide required information needed to triage your issue

OWA add-ins can not restore user sessions when a shared mailbox is opened on a different Outlook endpoint (outlook.office.com vs outlook.cloud.microsoft) than the primary mailbox.

All client-side mechanisms for sharing session state fail due to browser storage partitioning and mailbox scoping.

This results in broken auto-login experiences for shared mailboxes in add-inn.

Scenario

A user is logged in to add-inn in their primary mailbox on outlook.office.com with a valid session.

They then open a shared mailbox's add-inn on outlook.cloud.microsoft in another tab. The add-in loads without a session and needs to auto-login as the primary user.

This is not possible because no session state can be shared between the two contexts.

Actual Behavior

The add-in in the shared mailbox cannot access any session or token from the primary mailbox and must treat the user as logged out.

Expected Behavior

The add-in should be able to restore the session of the primary user automatically, even when running in a shared mailbox on a different Outlook endpoint.

Provide additional details

Browser Storage Partitioning (CHIPS)

Browsers partition all storage by top-level site. Because outlook.office.com and outlook.cloud.microsoft are different domains, all storage mechanisms are isolated, including:

localStorage
IndexedDB
sessionStorage
BroadcastChannel

These cannot be used to share data across endpoints.

Mailbox-Scoped Roaming Settings

Office.context.roamingSettings is scoped per mailbox. Data written in the primary mailbox is not accessible in a shared mailbox, making it unusable for this scenario.

Attempted Approaches

We attempted all available client-side mechanisms (roaming settings, browser storage, BroadcastChannel), and all fail due to the isolation boundaries described above.