Introducing macOS Platform SSO in PingID Desktop 2.0

A technical overview of how macOS Platform SSO in PingID Desktop 2.0 connects the native Mac sign-on experience to PingFederate for seamless browser and native app SSO.

macOS Platform SSO in PingID Desktop 2.0 gives developers and identity architects a way to connect the native Mac sign-on experience to PingFederate and extend that trust into browser-based applications and native apps that rely on system web authentication. This isn’t just a desktop UI update. It’s an end-to-end flow built from an MDM-delivered Platform SSO profile, PingID Desktop 2.0, PingOne for Workforce (PingID), and PingFederate 13.1 or later.

In this first release, PingFederate is the supported identity provider (IdP), the Platform SSO extension is installed as part of PingID Desktop 2.0, and the supported authentication method is Secure Enclave-backed keys.

This post focuses on the implementation side of the release: prerequisites, architecture, PingFederate configuration, MDM profile requirements, and the main flow boundaries you should understand before rollout.

Prerequisites

Before you start, make sure the deployment baseline is in place.

Requirement Details
macOS macOS 15.4 or later
Hardware Apple Silicon Mac
Device management MDM is required, and unattended Automatic Device Enrollment (ADE) is supported
Desktop client PingID Desktop 2.0 or later
Ping service PingOne for Workforce (PingID) is required, and users must exist there before registration
Identity provider PingFederate 13.1 or later
PingFederate component Mac Platform SSO adapter

If you are already using PingID Desktop 1.0, the client-side change is straightforward: upgrade to PingID Desktop 2.0. No additional configuration is required in the installer or in the running application itself to enable macOS Platform SSO. The configuration is delivered through MDM and the PingFederate-side setup.

Why Platform SSO matters

Platform SSO is Apple’s framework for binding the local macOS sign-on experience to an enterprise identity provider. In Ping’s implementation, the model combines device identity, user identity, cryptographic trust, token issuance, and application single sign-on (SSO) in a single flow.

Platform SSO is also different from browser-session-based SSO. It doesn’t rely on an existing browser cookie to create the SSO experience. Because trust is established through the platform and the identity provider integration, even a newly installed supporting browser (based on Apple’s WebKit) can participate in SSO right away. The same model can also benefit native applications that use the same PingFederate login domain through supported system web authentication flows.

From a technical point of view, that matters because the trust does not begin in the browser. The device is registered first, the user is registered second, and only then does the system use that registered state to satisfy later authorization requests. That is what makes the experience feel native while still keeping PingFederate in control of policy and token issuance.

What we are releasing

This release adds macOS Platform SSO support to the new PingID Desktop application, starting with version 2.0. The Platform SSO extension is installed as part of PingID Desktop and works with PingFederate as the supported identity provider for this release.

At a high level, the solution has three major phases:

  • Device registration
  • User registration
  • Login and application authorization

Those phases matter because Platform SSO is not just a browser shortcut. The flow establishes trust in the device, binds a user credential to that device, and then uses that trust to support later sign-on requests.

How it works

The architecture includes four collaborating parts: the MDM profile that delivers the required configuration, the macOS Platform SSO engine, the PingID SSO extension, and PingFederate as the identity provider runtime layer.

The MDM profile is what turns the feature on for the device and tells macOS where to send matching authentication traffic. At the profile level, developers should expect a com.apple.extensiblesso payload with values such as the Ping extension identifier, the Ping team identifier, the list of URLs that should be handled by the extension, and ExtensionData that carries the Platform SSO configuration. Inside that configuration, the important values are the client identifier, base URL, audience, and PingFederate instance identifier that the extension uses when talking to PingFederate. For this first release, the Platform SSO authentication method is UserSecureEnclaveKey.

The macOS Platform SSO engine handles platform-native behavior, such as key generation, authentication, token refresh, and secure token storage. The PingID SSO extension handles device registration, user registration, token and login configuration, and the interception of supported SSO requests. PingFederate receives the Platform SSO-augmented requests, validates tokens, Secure Enclave signatures, nonce and replay protections, and device binding, then issues the client-specific result for the application or browser flow.

From an implementer’s point of view, the flow looks like this:

  1. The device is enrolled and receives the required Platform SSO profile through MDM.
  2. The device completes registration and establishes a cryptographic device identity.
  3. The user completes registration and binds a user credential to that device.
  4. When a supported authorization request arrives, macOS routes it to the Platform SSO extension.
  5. The extension adds the required Platform SSO material and forwards the request to PingFederate.
  6. PingFederate validates the request and continues the authentication policy.
  7. The application receives the result of the PingFederate flow without forcing the user to manually repeat sign-on.

What you need to configure

To roll out macOS Platform SSO, there are three technical control planes to configure: device management, PingOne for Workforce, and PingFederate. You can find full details in Configuring Platform SSO for macOS (Workforce only) in the PingOne documentation.

1. Device management and MDM profile

The device must be Apple Silicon, run macOS 15.4 or later, and be managed by MDM so it can receive the Platform SSO configuration profile. Unattended ADE is also supported, which is useful for zero-touch provisioning of managed Mac fleets.

The MDM profile is where you define the full Platform SSO behavior for the device, not just the redirect target. The exact values depend on your environment, but the key structure should look like this (keys can also change according to needs):

{
  "Type": "Redirect",
  "URLs": [
    "https://<pingfederate-host>"
  ],
  "PlatformSSO": {
    "Account": {
      "DisplayName": "My Org Name"
    },
    "UserCreation": {
      "EnableAtLogin": true,
      "TokenToUserMapping": {
        "FullName": "name",
        "AccountName": "preferred_username"
      },
      "EnableFirstUserDuringSetup": true,
      "EnableRegistrationDuringSetup": true
    },
    "RegistrationToken": "<registration-token taken from the PingFederate Adapter>",
    "UseSharedDeviceKeys": true,
    "AuthenticationMethod": "UserSecureEnclaveKey",
    "AllowDeviceIdentifiersInAttestation": true
  },
  "ExtensionData": {
    "AppPolicy": {
      "AppAllowList": [
        "<bundle-id-1>",
        "<bundle-id-2>"
      ],
      "AppBlockList": [
        "<blocked-bundle-id-1>",
        "<blocked-bundle-id-2>"
      ],
      "AllowManagedAppsOnly": false
    },
    "PSSOConfiguration": {
      "BaseURL": "https://<pingfederate-host>",
      "Audience": "https://<pingfederate-host>",
      "ClientID": "<oauth-client-id>",
      "InstanceID": "<pingfederate-instance-id>"
    }
  },
  "ExtensionComposedIdentifier": "com.pingidentity.pingid.desktop.pingssoe (6U3RF4C84N)"
}

The ExtensionComposedIdentifier (in Declarative Device Management as in the example above) or ExtensionIdentifier and TeamIdentifier (in a regular configuration profile) will always hold com.pingidentity.pingid.desktop.pingssoe and 6U3RF4C84N respectively.

Platform SSO deployments also need a separate associated domains payload. This payload authorizes Safari and system authentication services to route authentication traffic to the PingID Desktop SSO extension. Each entry should use the authsrv: prefix followed by the host name only. Do not include https://, a port, or a trailing slash. For example, if your PingFederate base URL is https://pf.example.com, the associated domain value should be authsrv:pf.example.com. Add one entry for each domain your deployment uses. ApplicationIdentifier will always be 6U3RF4C84N.com.pingidentity.pingid.desktop.

A placeholder associated domains payload can look like this:

{
  "PayloadType": "com.apple.developer.associated-domains",
  "Configuration": [
    {
      "ApplicationIdentifier": "6U3RF4C84N.com.pingidentity.pingid.desktop",
      "AssociatedDomains": [
        "authsrv:<your-pingfederate-host>"
      ]
    }
  ]
}

A few fields are especially important during implementation. The URLs list and the associated domains payload work together to determine which login traffic the extension can handle. The TokenToUserMapping section controls how claims from the identity response (OIDC ID Token) map to the local macOS account. The EnableFirstUserDuringSetup and EnableRegistrationDuringSetup flags are useful when you want registration to happen during Setup Assistant, especially in unattended ADE deployments. The PSSOConfiguration block must align with the PingFederate-side client, audience, base URL, and instance configuration.

Note about EnableFirstUserDuringSetup: If you enable this field as part of ADE, macOS shows a native username and password screen that prompts the user for IdP credentials. The system authenticates the user against the IdP using the Password grant type. macOS then carries the response into the next screen, where it creates the local account. In the local account creation screen, the account name and full name fields are pre-populated, and the user only needs to create the local account password. This prevents the possibility of users giving their own account and machine names.

2. PingOne for Workforce presence

PingOne for Workforce is part of the solution. Users participating in the flow must exist in PingOne for Workforce before registration starts. That presence is what enables device registration, user registration, and strong authentication during the Platform SSO journey.

The Platform SSO flow also supports PingOne for Workforce as the MFA layer, including methods such as push notifications to the PingID mobile application and passkeys.

Note about created users in PingOne for Workforce: To support the use of the MDM profile key TokenToUserMapping - Account Name, the admin must create a custom User Attribute named preferred-username in PingOne for Workforce that will map the username to the PingFederate field inserted into the preferred_username field in the ID Token. Each user must have this Custom Attribute.

Admins can check if the user is registered to the Platform SSO in the User -> Services -> Authentication section under Sessions & Devices.

3. PingFederate 13.1+ configuration

Customers should use PingFederate 13.1 or later, and in practice the latest supported PingFederate deployment is the best starting point.

The PingFederate configuration should include the following components and they should be aligned as one end-to-end Platform SSO flow:

  • Import the Apple Enterprise Attestation Root CA so PingFederate can validate the attestation chain presented during registration.
  • Add the urn:apple:platformsso scope.
  • Configure an OAuth client for the desktop app. The required grant types are Authorization Code, Refresh Token, and Assertion Grant.
  • Make sure the client can complete the OIDC flow and issue both an access token and an ID token.
  • Create an access token manager for the Platform SSO flow.
  • Create or update the OpenID Connect policy used to issue and validate the required claims.
  • Create a Mac Platform SSO adapter in PingFederate.
  • Create a Mac Platform SSO JWT Bearer Grant Processor.
  • Create the IdP connection used by that grant processor.
  • Add the Platform SSO adapter to the authentication policy.

Treat these as connected configuration objects rather than isolated tasks. The OAuth client, tokens, adapter, grant processor, IdP connection, and authentication policy all need to agree on the same Platform SSO flow so registration and sign-on behave consistently.

A few implementation details are especially important:

  • Platform SSO must be the first step in the PingFederate authentication policy. If another adapter appears before it, the flow is not supported.
  • Customers can use PingFederate HTML Adapters or a DaVinci flow later in the authentication experience. This way, admins can take the advantage of different MFA options (such as number matching push notifications to PingID mobile app or passkeys etc.), PingOne Verify, and so on.
  • The OAuth client, access token manager, adapter, and IdP connection should be configured consistently so the same client and token context are used across registration and SSO.

Troubleshooting

If registration or sign-on does not behave as expected, collect logs from all three layers of the flow: macOS, PingID Desktop, and PingFederate. Looking at only one layer usually gives you only part of the story.

1. Stream macOS unified logs

Use macOS unified logging when you want to watch the flow in real time while reproducing the issue.

log stream --predicate 'process == "AppSSOAgent"' --info --debug
log stream --predicate 'process == "pingssoe" AND subsystem BEGINSWITH "com.pingid.passwordless"' --info --debug

Or for the ADE flow, in addition to the above (Terminal can be opened by using ⌃+⌥+⌘+T):

log stream --predicate 'process == "Setup Assistant" AND subsystem == "com.apple.macbuddy"' --info --debug

In practice, the most useful predicates are the ones that narrow the stream to the PingID Desktop app, the SSO extension, or Apple AppSSO activity. If you already know the process name, subsystem, or category you want to follow, add it to the predicate and reproduce the registration or sign-on flow again.

2. Collect PingID Desktop logs

For PingID Desktop, the fastest way to gather diagnostics is the built-in CLI.

sudo pingiddesktop logs --time 30m

The output path is /tmp/pingid-desktop-logs.zip.

3. Review PingFederate server logs

On the server side, review the PingFederate logs while reproducing the same registration or sign-on attempt. This is especially important when you need to confirm adapter execution, token issuance, attestation validation, policy progression, or failures in the JWT Bearer Grant Processor or IdP connection.

For Platform SSO issues, it is a good practice to collect PingFederate logs in DEBUG during testing so you can correlate the server-side event with the device-side and desktop-side activity.

Current scope

This first release is intentionally focused.

Today, the supported authentication method is Secure Enclave-backed keys. In the current design, Phase 1 support is limited to the Secure Enclave approach, and the configuration examples use UserSecureEnclaveKey for the authentication method.

That limitation is important because the registration and assertion model depends on hardware-backed keys and attestation as part of the trust chain.

It is also important to understand what the extension does and does not intercept. The PingID SSO extension supports browser-based authentication flows and system web authentication sessions. It does not intercept direct API traffic such as cURL, Postman, background service calls, URLSession requests, or JavaScript fetch() calls, because those do not go through the OS-level browser authentication path.

Why this matters for developers and implementers

For engineering teams standardizing on managed Macs, this release creates a clean separation of responsibilities:

  • MDM delivers the Platform SSO profile.
  • PingID Desktop 2.0 hosts the extension.
  • PingOne for Workforce provides the user and MFA context.
  • PingFederate enforces policy and issues the final authentication result.

That split makes the system easier to reason about during rollout and troubleshooting. The device and user are enrolled once, and later authorization requests can be evaluated using signed proofs tied to that registered state instead of forcing the user through repeated sign-ons.

It also means troubleshooting gets easier when you keep the layers separate. If registration is failing, start with MDM profile delivery, the PingID Desktop logs, and the PingFederate debug logs. If sign-on works in the browser but not through Platform SSO, check whether the request is actually using a supported browser or system web authentication path and whether Platform SSO is the first step in the PingFederate policy.

Looking ahead

This is the beginning of the Platform SSO journey in PingID Desktop. The current release focuses on PingFederate as the supported identity provider and on Secure Enclave-backed authentication. Support for additional authentication types and broader coverage will follow in future releases.

If you are planning a rollout now, the best place to start is with PingID Desktop 2.0, the latest PingFederate deployment, the Mac Platform SSO adapter, PingOne for Workforce, and an MDM-managed device fleet. That gives you the baseline you need to validate registration, confirm policy behavior, and test browser and native application sign-on with the supported architecture.

macOS Platform SSO in PingID Desktop 2.0 is a practical step toward a more native and lower-friction sign-on experience on managed Macs. For developers and identity teams building passwordless and device-aware experiences around PingFederate, this is the right place to start.

Join the discussion on the Ping Identity developer community.

Tags

Access Management & AuthorizationDeveloper Resources#PingOne MFA#PingFederate#SSO#macOS