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.

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:

Google: https://accounts.google.com/.well-known/openid-configuration
Azure AD: https://login.microsoftonline.com/{tenantID}/v2.0/.well-known/openid-configuration
Okta: https://{company}.okta.com/.well-known/openid-configuration

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	`given_name`
Map Last Name	OIDC claim for user’s family name	`family_name`
Map Full Name	Combined user name string	`name`
Map Full Username	Full username used for account mapping	`name`
Map Username	Local macOS account short name	`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.

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