Portal session cookies
Defender and Purview rely on the portal's sccauth cookie and an authenticated browser session.
Portals: Defender, Purview
Portal session + same-origin XHR
Exchange uses the authenticated Exchange admin center browser session with .AspNetCore.Cookies and same-origin x-requested-with: XMLHttpRequest requests.
Portals: Exchange
Portal session + same-origin context
Purview Portal uses the same sccauth browser session, but its same-origin /api/ calls also depend on portal bootstrap state and are where Purview mints downstream bearer tokens.
Portals: Purview Portal
Portal session + custom headers
M365 Admin requires AjaxSessionKey plus portal routing and hosting headers extracted from the admin shell.
Portals: M365 Admin
Portal session + SharePoint digest
SharePoint uses the tenant's -admin.sharepoint.com browser session together with same-origin SharePoint headers such as x-requestdigest, SdkVersion, and odata-version on POST requests.
Portals: SharePoint
Portal bearer tokens + regional discovery
Teams admin center uses browser-acquired bearer tokens across multiple Teams and Office service hosts, plus same-origin portal context for /api/log and resolver calls that map the tenant to regional backends.
Portals: Teams
MSAL PKCE bearer token + same-origin GraphQL
Viva Engage admin uses a browser-acquired bearer token from the Engage MSAL PKCE flow with the Yammer user_impersonation scope, then calls same-origin persisted GraphQL on engage.cloud.microsoft, a bearer-backed token helper on api.engage.cloud.microsoft, and a transient *.rt.yammer.com Bayeux relay chain whose auth material is carried in the handshake body rather than in Authorization or cookie headers. No cookie header was observed on the authenticated admin API requests captured for this pass.
Portals: Viva Engage
Portal bearer tokens + diagnostic headers
M365 Apps uses browser-obtained bearer tokens together with diagnostic headers such as x-api-name, x-correlationid, x-manageoffice-client-sid, and x-requested-with.
Portals: M365 Apps Config, M365 Apps Services, M365 Apps Inventory
Portal bearer tokens + service-specific audiences
Power Platform reuses browser-obtained bearer tokens from the admin center, but different backends expect different audiences plus portal context headers such as correlation IDs, session IDs, tenant IDs, and app identifiers.
Portals: Power Platform
Portal bearer tokens
Intune Portal and Intune Autopatch use browser-obtained bearer tokens plus same-origin cookies or portal headers from the authenticated Intune session.
Portals: Intune Portal, Intune Autopatch
Delegated OAuth2
Entra IAM uses the ADIbizaUX resource with delegated user auth only and typically needs X-Ms-Client-Request-Id.
Portals: Entra IAM
Azure AD bearer tokens
Entra PIM, IGA, IDGov, and B2C use Azure AD bearer tokens, with tenant- or feature-specific constraints on top.
Portals: Entra PIM, Entra IGA, Entra IDGov, Entra B2C