SSO (single sign-on)

How it works

Two protocols carry almost all of it. SAML 2.0, an OASIS standard since 2005, exchanges signed XML assertions and still runs a large share of enterprise web apps. OpenID Connect, built on OAuth 2.0 and published in 2014, exchanges JSON web tokens and is what mobile apps use, because it was designed for native clients and redirect flows rather than browser form posts. New integrations should be OIDC unless the vendor gives you no choice.

Mobile adds a wrinkle. Each app runs in its own sandbox, so a token obtained by one app isn't automatically visible to the next. Apple solved this with the Extensible Single Sign-On payload, introduced in iOS 13 and macOS 10.15 in 2019: an MDM installs an extension, declares the hosts it covers, and the extension answers authentication challenges for every app and for Safari. Platform SSO went further on macOS 13 Ventura by tying the local account login to the IdP, and the rewrite in macOS 15 Sequoia in 2024 added Secure Enclave backed keys and password sync, which is why most Mac fleets only adopted it recently.

Android has no equivalent OS-level SSO layer. Credential sharing happens through a broker app instead: Microsoft Authenticator or Intune Company Portal brokers tokens for apps built against MSAL, and inside an Android Enterprise work profile the broker and the apps that use it must live in the same profile. Apps outside that pattern do their own browser-based OIDC flow and ask the user again.

What the MDM contributes is plumbing the user never sees: the Extensible SSO payload and its app bundle IDs, the broker app installed and pre-configured before first launch, the Kerberos realm settings where an on-premises domain is still in play, and the client certificates an extension or a VPN needs.

Why it matters for a fleet

Fewer passwords means fewer reused passwords, faster onboarding, and an offboarding that actually works: disable the account and access ends everywhere, instead of hunting for the eleventh SaaS tool nobody documented.

The trade-off is blast radius. One compromised session token can now reach everything the user could reach, and token theft through malware or a convincing proxy page has become the dominant attack pattern rather than password guessing. Shorten session lifetimes on sensitive apps, require a phishing-resistant factor at sign-in, and condition the session on a device you recognize. SSO without device conditions just makes a stolen identity more efficient.

How Appaloosa handles it

Appaloosa delivers the device-side pieces of an SSO deployment: the Apple Extensible SSO payload and its configuration, broker and authenticator apps distributed to the right groups from the enterprise app store, managed app configuration carrying tenant IDs and sign-in hints so the first launch already points at the right directory, and client certificates installed at enrollment. Compliance state from the same console can gate the session. The payload and certificate mechanics sit in the MDM configuration profiles applied to each enrolled device.