Overview
This guide details the distinctions and commonalities between Addigy Identity and Apple Platform SSO. While both can be used through Addigy MDM, this guide offers guidance on appropriate usage for each and suggests deployment strategies within Addigy-managed macOS environments. We will cover prerequisites, setup instructions, optimal practices, troubleshooting advice, and frequently asked questions, with references to pertinent Addigy and Apple resources.
Table of Contents
When to use Addigy Identity vs. Platform SSO
Solutions Overview
- Addigy Identity: Addigy’s login and authentication solution that replaces the macOS login window, authenticates against an IdP (Okta, Microsoft Entra ID, Google, etc.), performs just‑in‑time (JIT) local account creation, and syncs the local password to the IdP at login. It is configured per Addigy policy with theming and options.
- Platform SSO: Apple’s native framework that binds a macOS user to the organizational IdP using an SSO extension. It enables native login using IdP credentials, single sign-on to apps and browsers, optional passwordless methods, and group‑based authorization. Requires MDM, an Extensible SSO profile, and an IdP that supports Platform SSO (e.g., Entra ID, Okta).
Feature comparison
| Area | Addigy Identity | Platform SSO |
| Login method | IdP login via Addigy window; JIT local account creation | Native macOS login with IdP; JIT local account creation |
| Password model | Syncs local to IdP at login; prompts to resync on next auth after IdP change | Password sync mode, or passwordless Secure Enclave, or smart card |
| SSO to apps/browsers | Can be done separately with Extensible SSO; separate app sign‑ins | Automatic SSO via SSO extension after login |
| Biometrics | No native Touch ID/Watch | Touch ID/Apple Watch unlock after initial auth |
| FileVault unlock | Supported on macOS 15; may require network and yields two prompts on reboot | Supported on macOS 15; reduces double prompts |
| Group/role mapping | Policy‑level role default; limited per‑user granularity at creation | IdP group to admin/authorization mapping dynamically |
| IdP support | Okta, Entra ID, Google | Entra ID and Okta widely documented; others vary |
| OS requirements | Broader version coverage; Addigy managed | macOS 13+; some features on 15+; MDM + SSO profile + IdP vendor app dependent |
| Licensing | Included with Addigy | Included with IdP/MDM in some stacks; depends on IdP vendor |
When to use Addigy Identity vs. Platform SSO
Choose Addigy Identity if:
- Your IdP isn’t ready for Platform SSO (e.g., Google) or you want a turnkey Addigy‑managed login with JIT accounts across broader macOS versions.
- You need quick policy‑based deployment, branding, and password sync at login, and can accept a second prompt after FileVault unlock on reboot.
- You need user attributes to streamline automated workflows and tie users to device policy configurations.
Choose Platform SSO if:
- Your IdP supports Platform SSO and you want native login, SSO across apps, modern unlock (Touch ID/Watch), and options like passwordless or smart cards.
- You need dynamic admin mapping from IdP groups and deeper OS‑level integration, and you meet MDM and SSO payload prerequisites.
Prerequisites
Addigy Identity
- Addigy account with Identity enabled at Account > Integrations.
- Supported IdP tenant (Okta, Microsoft Entra ID, Google), with configured application and redirect settings.
- Addigy policy to deploy Identity settings and End-user Login branding.
Platform SSO
- macOS 13+ (recommend macOS 15+ for improved unlock behaviors), device enrolled in MDM.
- Extensible SSO payload configured for the IdP’s SSO extension identifier and payload.
- IdP‑specific agent or app and device registration (e.g., Microsoft Company Portal, Okta components) as guided by the vendor. Note: Microsoft Company Portal and Okta Fastpass can be deployed through Addigy Prebuilt Apps.
Best practices
Scope carefully during pilot:
- Start with one policy and a small device cohort; verify login flow, account creation, FileVault behavior, and app SSO before broader rollout.
Reduce prompts:
- With Addigy Identity and FileVault enabled, educate users on the two prompts after reboot; consider moving long‑running restarts to maintenance windows. Encourage users to lock their devices at the end of the day, so that the next day they put in their passwords once to avoid locking/unlocking FileVault
- With Platform SSO, ensure the SSO extension payload and registration complete before user testing to avoid fallback prompts.
Prepare for IdP password changes:
- Identity updates local passwords at next login; communicate expected prompts and test password rotation scenarios.
- Platform SSO password or passwordless methods should be tested for offline grace and recovery paths per IdP guidance.
Document offline and captive portal behavior:
- Plan for first login requiring network. For Platform SSO, validate cached credential behavior and grace settings with your IdP.
FAQs
Can both be used together?
- Environments commonly standardize on one login experience. Yet, there are workflows where using both is desired, such as creating the user (JIT) via Addigy Identity, and using Auto-Assignment policies to enforce Platform SSO logins instead. If testing both, ensure proper scoping via Auto-Assignment policies to avoid conflicting login window behaviors, and communicate expected prompts to users.
Does Addigy Identity support Google as an IdP?
- Yes. Addigy provides a dedicated configuration guide for Google. Platform SSO support depends on Google’s adoption of Apple’s Platform SSO framework.
Is MFA supported at the login window?
- Addigy Identity can show IdP MFA in its web‑based login flow per your IdP policy. Platform SSO generally does not place MFA at the OS login; enforce MFA at app/resource access layers via the IdP.
What about passwordless authentication options?
- Platform SSO supports passwordless via Secure Enclave keys and smart cards per IdP implementation. Addigy Identity relies on IdP credentials at login and password sync.
How are local admin rights assigned?
- Identity: per‑policy default during JIT account creation. Platform SSO: dynamic mapping from IdP groups.