How to Deploy Apple Extensible Enterprise SSO (App SSO) for macOS Native Authentication

In enterprise macOS deployments, identity fragmentation is a massive operational headache. Historically, IT administrators relied on Apple’s “Enterprise Connect” or third-party tools like Jamf Connect to bind local macOS accounts to cloud Identity Providers (IdPs) like Microsoft Entra ID or Okta. These tools relied on constantly polling APIs to keep the local Mac password synchronized with the cloud password. When synchronization inevitably failed, users were locked out of FileVault or bombarded with continuous keychain prompts.

Apple recognized this architectural flaw and introduced the Extensible Enterprise SSO framework (App SSO) natively into macOS and iOS.

App SSO is not a password synchronization tool. It is a fundamental shift in how Apple operating systems handle authentication. It acts as an OS-level interceptor. When a native application (like Apple Mail) or a web browser (Safari) attempts to access an enterprise resource, the OS intercepts the request and silently hands it off to an App SSO extension provided by your IdP (e.g., the Microsoft Company Portal app or Okta Verify). The extension acquires the cryptographic token (Kerberos or OAuth/SAML) and passes it back to the app, achieving true, silent Single Sign-On without ever touching the local macOS password.

This guide explains how to deploy the Extensible Enterprise SSO framework using Microsoft Entra ID (via the Microsoft Enterprise SSO plug-in) as the Identity Provider.

Understanding the App SSO Architecture

The Extensible SSO framework requires three components:

1. The Application: A native app or browser that supports Apple’s ASWebAuthenticationSession API or standard network intercepts.
2. The App SSO Extension: A lightweight binary installed on the Mac, provided by your IdP. For Microsoft Entra ID, this is bundled inside the Microsoft Company Portal application.
3. The MDM Configuration Profile: A Mobile Device Management (MDM) payload that tells macOS when to trigger the extension (e.g., “If an app tries to reach login.microsoftonline.com, intercept it and wake up the Microsoft SSO extension”).

Step 1: Deploying the SSO Extension Binary

Before you push the configuration profile, the actual extension binary must reside on the Mac.

For Microsoft Entra ID, you must deploy the Microsoft Company Portal app to your fleet via your MDM (e.g., Jamf Pro, Kandji, Intune). You do not actually need users to launch the Company Portal app or enroll in it; simply installing the .pkg silently drops the required SSO extension binary into the macOS system directories.

Step 2: Constructing the Extensible SSO MDM Payload

You must construct an Extensible Single Sign-On configuration profile in your MDM and push it to your Macs.

1. Create a new Configuration Profile in your MDM.
2. Select the Extensible SSO payload.
3. Extension Type: Select Redirect (for OAuth/SAML intercept). The other option is Credential (specifically for Kerberos).
4. Extension Identifier: You must enter the exact bundle ID of the IdP’s extension. For Microsoft, this is exactly: com.microsoft.CompanyPortalMac.ssoextension.
5. Team Identifier: Apple requires the cryptographic developer team ID of the vendor to ensure a malicious app cannot hijack the SSO flow. For Microsoft, this is: UBF8T346G9.

Step 3: Defining the Intercept Rules (URLs)

This is the most critical configuration. You must tell macOS exactly which URLs should trigger the silent SSO interception. If an app attempts a web view or network call to these domains, the OS wakes up the Microsoft extension.

Add the following URLs to the URLs array in the profile:

• https://login.microsoftonline.com
• https://login.microsoft.com
• https://sts.windows.net
• https://login.windows.net

(Note: If you use Okta, you would use Okta’s specific extension bundle ID, Team ID, and your Okta tenant URLs).

Step 4: Configuring the Custom Dictionary (Platform SSO Prep)

The MDM payload allows you to pass a custom plist dictionary directly into the Microsoft extension to control its behavior.

For example, to force the extension to share its cookies with the Safari browser (enabling silent SSO for web apps), you would add the following key/value pair to the custom configuration dictionary:

<key>browser_sso_interaction_enabled</key>
<integer>1</integer>

Deploy this profile to your fleet.

Step 5: The End-User Experience

Once the MDM profile lands on the Mac, the transformation is immediate.

When the user opens Microsoft Word for the first time, or navigates to portal.office.com in Safari, the macOS Extensible SSO framework intercepts the request. The Microsoft SSO extension wakes up and prompts the user to authenticate once. The extension acquires the Primary Refresh Token (PRT) from Entra ID and securely caches it in the Mac’s Secure Enclave.

For all subsequent authentication requests—whether the user opens Microsoft Teams, OneDrive, Excel, or internal web apps protected by Entra ID—the OS silently intercepts the request, grabs a token from the extension, and logs the user in instantly. The user sees zero prompts, zero credential boxes, and no keychain popups.

Conclusion

Apple Extensible Enterprise SSO natively resolves the identity friction that has plagued macOS in the enterprise for years. By embedding the interception framework deep within the operating system and delegating the cryptographic token handling to the cloud IdP’s extension, IT administrators can deliver a seamless, zero-prompt SSO experience across native apps and browsers without relying on brittle local password synchronization tools.