This article summarizes how admins can use Apple Platform SSO and Apple User Authorization Policy to tightly control device passwords on managed macOS devices using Google SSO.
What this setup achieves
With the right policies and configuration, you can:
Use Google SSO as the primary login for macOS devices (via Platform SSO).
Prevent local password changes on the Mac, so employees can’t bypass central control.
Centralize all password changes in Google, and have those changes synchronize to the macOS login password.
The article confirms that this workflow is achievable today for Google SSO on macOS.
Prerequisites
To reproduce the behavior, make sure you have:
A managed macOS device enrolled in Swif MDM.
Swif policies:
Apple Platform SSO policy (for Google SSO login)
Apple User Authorization Policy (to block local password changes)
Recommended Policy Configuration
You should deploy both of the following policies to the target Mac:
Apple Platform SSO policy
Configure Platform SSO with Google as the identity provider.
Ensure login is via Google SSO.
Recommended: Do not merge with an existing local account; allow Platform SSO to manage the user account as a separate device account.
Apple User Authorization Policy
Configure this policy so that:
Users cannot change their local account password in macOS System Settings.
Password-related actions are restricted to the identity provider (Google).
Once these two policies are deployed to the Mac, the device will be governed by Google SSO and Swif’s authorization controls.
Tested Scenario and Results
The following behavior was verified for a Platform SSO policy with Google SSO + Apple User Authorization Policy setup.
1. Blocking Local Password Changes
What was done
The tester deployed the Apple User Authorization Policy to a Mac that was already using Google SSO.
Observed behavior
After the policy was applied, the tester could no longer change the password locally on the Mac.
Attempts to change the password via macOS System Settings were effectively blocked by the policy.
Outcome
Local password changes are prevented, which is aligned with the goal of tight admin control over device passwords.
2. Changing the Password in Google SSO and Syncing to macOS
What was done
Change password in Google SSO
The tester changed their Google account password in Google (the IdP).Re-login at the Google SSO screen
After changing the password in Google, they went to the SSO login screen on the Mac and tried to log in using the new Google password.Modal prompt for old password
Upon entering the new password, SSO displayed a modal asking for the old macOS password. This is required to synchronize the new Google password down to the local macOS account.
Enter old password
The tester entered the old local account password when prompted.Successful login and sync
After providing the old password, login succeeded using the new Google password.Reboot the device
The Mac was rebooted.Log in with new password again
After restart, the tester logged in using the new Google password and was able to access the macOS account successfully.
Observed behavior
The Google password change was recognized by Platform SSO.
The SSO modal allowed the new Google password to be synchronized into the local macOS account after the user confirmed the old password once.
After synchronization, the new Google password became the effective device password.
The new password persisted across a reboot.
Outcome
IdP-only password changes with propagation are supported in this flow:
The password has been changed at Google.
The new password is then synchronized to the macOS login via Platform SSO.
After sync, the new password is required for subsequent logins to the Mac.
How the User Experience Looks (Step-by-Step)
Here’s what an end user on a managed Mac will experience under this configuration:
Normal login
User logs into the Mac using the Platform SSO screen with their Google credentials.
Admin or policy requires password rotation
User changes their password in Google Workspace (e.g., due to a password rotation policy).
Next login to the Mac
At the SSO login screen, the user enters their new Google password.
A modal prompt appears:
It asks for the old password to securely update the local macOS account password.
User enters their old password once.
Password sync completed
Platform SSO updates the local macOS account to use the new Google password.
The user is logged into the Mac.
Subsequent logins
After a reboot or sign-out, the user logs in directly with the new Google password.
The old password is no longer valid on the device.
Combined with the Apple User Authorization Policy, the user cannot directly change the macOS password from System Settings; all effective changes flow from Google.
What This Means for Admins
✅ Device SSO via Google works as the primary login method on macOS (using Apple Platform SSO policy).
✅ Local password changes are blocked once the Apple User Authorization Policy is deployed.
✅ Password changes are centralized at Google, and those changes are synchronized to the macOS local account via Platform SSO when the user next logs in and confirms their old password once.
This combination provides a strong foundation for:
Shared or lab Macs where you don’t want users changing device passwords.
Environments where password rotation is enforced at the IdP level and must remain consistent across all devices.
Notes and Limitations
The article specifically validated Google SSO on macOS.
Other IdPs (Okta, Azure) and additional platforms are part of broader design goals, but were not covered in this specific test result.
The “old password” prompt during the first login after a Google password change is expected behavior, so Platform SSO can securely update the local macOS account.