The Apple Platform SSO Policy allows organizations to integrate macOS login with their identity provider (IdP) using Apple’s Platform Single Sign-On (SSO) framework.
This policy enables users to sign into their macOS devices using their Google, Microsoft Entra ID (Azure AD), or Okta credentials—improving security, reducing password fatigue, and centralizing authentication across the enterprise.
Swif.ai provides full support for Apple Platform SSO, allowing IT teams to deploy SSO at macOS login using standard OIDC configuration parameters.
⚠️ If FileVault is Enabled
Before configuring or deploying the Apple Platform SSO Policy, Platform SSO (including XCreds at the login window) depends on macOS Secure Token and FileVault integration. If FileVault is enabled:
Platform SSO will not function correctly
XCreds will not appear automatically at the login window
Authentication flows may fail or appear misconfigured
Required Setup If FileVault is Enabled
When assigning the Apple Platform SSO Policy:
Set Apple Login Window Policy -> “Disable automatic login if FileVault is enabled = true” and assign to the same group of devices,
This value must be set to TRUE if you are using the Platform SSO policy on the same device.
Since March 2026, when you create an Apple Platform SSO Policy, we automatically add “Disable automatic login if FileVault is enabled = TRUE” to the Apple Platform SSO Policy. But if you still have Apple Login Window Policy on the same device, remember to set “Disable automatic login if FileVault is enabled” to TRUE.
Device users will first enter their local user credentials to unlock FileVault the very first time, and then, as we advance, they will be able to view the Platform SSO login screen directly.
Failing to enable “Disable automatic login if FileVault is enabled” may result in Platform SSO not appearing or functioning properly at the login window.
Overview
With Apple Platform SSO, organizations can:
Enforce corporate identity login at macOS startup
Sync local macOS user accounts with IdP user attributes
Automatically create and manage local users
Enable password synchronization, token-based login, and SSO across apps
Improve compliance by removing local password handling
Swif.ai’s Platform SSO integration works with:
Google Workspace
Microsoft Entra ID (Azure AD)
Okta Workforce Identity Cloud
Full implementation guides are available here:
Requirements
macOS 12.0+
Device must be enrolled through Swif.ai MDM
Identity provider must support OIDC (OpenID Connect)
Configuration requires admin permissions in Swif.ai and your IdP
Configurable Settings
The policy allows administrators to map essential OIDC values that macOS requires to establish Platform SSO.
Below are all available configuration options.
Create Admin User
Determines whether the account created during Platform SSO onboarding is a local admin.
Setting | Description |
True | New users created via SSO are local admins |
False | New users are standard local users |
Minimum macOS version: 12.0+
Client ID
The public OIDC client identifier for the identity provider application.
This must match the Client ID configured in Google, Azure AD, or Okta.
Client Secret
The secret associated with the OIDC client.
Some identity providers (like Google) return a Client Secret; others may not require one depending on app type.
Discovery URL
The OIDC metadata URL provided by the IdP.
Examples:
Redirect URI
The redirect URL required for returning authorization responses.
Defaults to:
https://127.0.0.1
Scopes
OIDC scopes that define what user attributes are returned (claims).
These typically include:
Examples:
openid profile email offline_access
Note: Some IdPs require additional scopes such as groups or user.read.
Should Set Google Access Type To Offline
This setting is specific to Google Workspace environments.
True: Ensures refresh tokens are requested correctly
False: Normal OIDC behavior applies
Minimum requirement: macOS 12.0+
Attribute Mapping
These fields map IdP user attributes to local macOS user properties.
Field | Description | Typical Value |
Map First Name | OIDC claim for user’s given name |
|
Map Last Name | OIDC claim for user’s family name |
|
Map Full Name | Combined user name string |
|
Map Full Username | Full username used for account mapping |
|
Map Username | Local macOS account short name |
|
Tip: For Azure AD, mapping may require using preferred_username or email.
For Okta, mapping may require using login or email.
Best Practices
Use Platform SSO instead of local passwords for improved security and compliance.
Ensure attribute mappings match your IdP schema to prevent login issues.
Test with a single macOS device before organization-wide deployment.
Combine this policy with the Apple Login Window Policy for maximum control of login behavior.
You can combine it with Apple User Authorization Policy to prevent local user password changes. Learn more at Mac Platform SSO & Apple User Authorization Policy.
How to Configure (High-Level)
Create an OIDC app in Google, Azure AD, or Okta.
Add the Redirect URI (
https://127.0.0.1) in your IdP.Obtain the following from your IdP:
Client ID
Client Secret
Discovery URL
Map your OIDC attributes using the policy fields.
In Swif.ai, create a new Apple Platform SSO Policy and enter the required values.
Assign the policy to devices or device groups.
Restart the macOS device to begin SSO onboarding.
Compliance & Security Benefits
Eliminates local password storage
Ensures centralized identity enforcement
Reduces phishing risks
Enables SSO across macOS and cloud applications
Supports SOC 2, ISO 27001, and modern Zero Trust frameworks
Here is a section you can add to https://help.swif.ai/en/articles/12839068-apple-platform-sso-policy under a Troubleshooting / Collect Logs section.
Troubleshooting: Collecting Platform SSO (XCreds) Logs
If Apple Platform SSO or the login window authentication is not working as expected, Swif Support may ask you to collect XCreds debug logs.
Follow the steps below to enable debug logging and capture the issue.
Step 1: Enable XCreds Debug Logging
Open Terminal and run the following command:
sudo defaults write /Library/Preferences/com.twocanoes.xcreds showDebug -bool true
This enables detailed debug logging for XCreds.
Step 2: Reboot the Device
Restart the Mac so that the new debug logging setting is applied during the login process.
Step 3: Reproduce the Issue
After the reboot:
Attempt the login or authentication process where the issue occurs.
Trigger the problem (for example, login failure, missing XCreds login window, or authentication errors).
Step 4: Log in to the Device
Log in normally to the device so the logs can be saved.
Step 5: Collect the Log Files
After logging in, retrieve the following log files:
/tmp/xcreds/xcreds.log
~/Library/Logs/xcreds.log
These files contain detailed debug information about the Platform SSO authentication process.
Step 6: Send Logs to Swif Support
Provide the collected logs to Swif Support for analysis.
Include:
The two log files
The macOS version
The time when the issue occurred
A brief description of the issue
Disable Debug Logging (Optional)
After troubleshooting is complete, you can disable debug logging with:
sudo defaults write /Library/Preferences/com.twocanoes.xcreds showDebug -bool false
This helps prevent excessive logging once the issue has been resolved.