Hi Apple Community, Problem : Should be able to use my iDP password when I try to unlock my macOS local User Account.
 Password should sync across my macOS local User Account, when my User Account Password in iDP Changed
 Should have a provision to create a on-demand macOS local account with password of iDP Should be able to Create Primary Account in Automated Device Enrollment with password synced to iDP ( Simplified PSSO in Setup Assistant ) Solution : These can be solved if the Identity Provider implements Platform SSO , but not being implemented by all major Identity Providers Except major iDPs like Okta, Microsoft, Ping 
Since Platform SSO Offers the necessary framework and provision that satisfy the above needs I planned to make a open-source initiative to bridge in PSSO and Oauth ROPG to connect with Any OpenID Provider that supports Oauth ROPG 
I KNOW PSSO DOESN’T MEANT FOR THIS AND NEEDS TO BE IMPLEMENTED BY IDP, AND MEANINGFUL SSO TOKENS CAN BE ONLY ISSUED BY THEM TO HELP THE SSO EXTENSION 
But the native login Experience, FileVault Synchronization, Keychain Unlock everything being handled by OS in PSSO. I thought its best to go in this way The Attachment Includes the Components, Design Decisions of this Project , Questions in the PSSO Framework workflow. Including some Questions from new WWDC26 OpenID Authentication Method introduced in PlatformSSO Please help with the Questions in the Attachment and post if there is any suggestions on the workflow I described Filed Feedback with FB23065453

Hi Apple Community & Apple Team, 
Problem : Should be able to use my iDP password when I try to unlock my macOS local User Account.
 Password should sync across my macOS local User Account, when my User Account Password in iDP Changed
 Should have a provision to create a on-demand macOS local account with password of iDP Should be able to Create Primary Account in Automated Device Enrollment with password synced to iDP ( Simplified PSSO in Setup Assistant ) Solution : All the above Problems can be solved if the Identity Provider implements Platform SSO , but not being implemented by major Identity Providers Except Okta, Microsoft, Ping 
Since Platform SSO Offers the necessary framework and provision that satisfy the above needs I planned to make a open-source initiative to bridge in PSSO and Oauth ROPG to connect with Any OpenID Provider that supports Oauth ROPG ( Resource Owner Password Grant ) 
ITS RIGHT THAT PSSO DOESN’T MEANT FOR THIS AND NEEDS TO BE IMPLEMENTED BY IDENTITY PROVIDER, AND MEANINGFUL ID TOKENS CAN BE ONLY USED BY THEM TO HELP THE SSO EXTENSION 
But the native login Experience, FileVault Synchronization, Keychain Unlock everything being handled by OS in PSSO. I thought its best to go in this way The Attachment Includes the Components, Design Decisions of this Project , Questions in the PSSO Framework workflow. Including some Questions from new WWDC26 OpenID Authentication Method introduced in PlatformSSO Please help with the Questions in the Attachment and post if there is any suggestions on the workflow I described Filed a Feedback with ID FB23065453

We are deploying Platform SSO using the Secure Enclave authentication method. However, users are still being prompted for their username and password during registration. This undermines our goal of going passwordless and is causing deployment friction with customers. Once the Secure Enclave method is deployed and initialized, is there a way to suppress or skip this password dialog so users only authenticate via hardware/biometrics?

We would like to implement Platform SSO with the new web authentication. Where is the protocol documented? I have the documentation from prior versions of PSSO but would like to see the updated documentation.

During PSSO User Registration, we use ASWebAuthenticationSession for OIDC. If the user's default browser isn't Safari (e.g., Chrome), the browser window stays stuck on top of the PSSO UI after authentication. This confuses users because they can't see the final PSSO registration screen. Are there any native macOS window-management APIs we can call inside the session's completion handler to force the PSSO window back to the foreground?

I saw the "Authenticated Guest Mode on iPad" in macOS 27. Is this related to PSSO Authenticated Guest Mode on macOS? Does it require cloud binding for a machine account like on macOS? How is it related to Shared iPad? Shared iPad requires supervised mode. Is there a new profile and keys? Where is this documented? Can you share information about how it works and how it can be tested?

There wasn't any update on the tap to login. Has the spec on tap to login been finalized? Can wallet passes now be issued to authenticate to macOS using tap to login?

Are there current plans to implement Microsoft 365 groups with Platform SSO to control administrator access in macOS 27? If so, would you be able to provide a rough estimate of when we can expect changes to be implemented by identity providers?

We are implementing a Platform SSO extension on macOS and are seeing repeated registration notifications from AppSSOAgent for the same unresolved registration state. We are trying to understand whether this is expected Platform SSO behavior, or whether our extension should be returning a different registration result for a cancelled user-registration flow. Scenario 1: Setup Assistant / preboot cancellation Device registration succeeds during setup. User registration starts. The user closes/cancels the registration web auth UI. Setup completes and the user reaches the desktop. Two “registration required” notifications are posted a few seconds apart, before the user clicks anything. In AppSSOAgent logs, we see two separate cycles like: resetRegistrationWithCompletion handleUserRegistrationForUser:repair:newPasswordUser:newSmartCardUser:notified:profile: Sending registration notification Adding notification request ... then again roughly 10–12 seconds later, before any user action. In some runs, even if the user clicks the first notification and registration is already in progress, another notification still appears. If the first registration attempt does not complete successfully, registration does not finish and the user must click the second notification and repeat the registration flow. After acting on the second notification, registration may then succeed. Scenario 2: login / repair window already open In another run after logout/login, while the registration window is already open, AppSSOAgent posts another registration notification. Additional detail: In some runs, our extension logs show the web auth flow failing with: breaking calling recursion for caller with bundleIdentifier: ... no extension WebAuthenticationSession error 1 But the duplicate-notification behavior is specifically interesting when AppSSOAgent posts a second notification before any new desktop click/retry. We also see AppSSOAgent logs such as: Removing 1 delivered notifications with identifiers (...) Removing 1 pending notification requests with identifiers (...) which suggests the same Platform SSO registration notification can exist in both delivered and pending state before being reposted. Questions After a user cancels Platform SSO user registration UI during Setup Assistant, what is the expected ASAuthorizationProviderExtensionRegistrationResult the extension should return? (.failed, .userInterfaceRequired, something else?) Is it expected for AppSSOAgent to run multiple resetRegistrationWithCompletion / handleUserRegistrationForUser... cycles for the same incomplete registration state and post duplicate registration notifications before any user action? Is there any documented meaning for the retry timing gaps (for example ~3 seconds in some runs, ~11 seconds in others)? If the registration UI is cancelled by the user, is there a recommended way for the extension to prevent AppSSOAgent from re-posting multiple notifications for the same unresolved registration state? We want to understand whether the duplicate notifications are expected Apple-side Platform SSO behavior for incomplete registration, or whether the extension is expected to signal cancellation differently.

I am using ASAuthorizationProviderExtensionLoginManager.resetKeys() to generate new user-specific keys, specifically userDeviceSigningKey and userDeviceEncryptionKey. Based on the documentation, my understanding was that resetKeys() only resets keys associated with a particular user account: https://developer.apple.com/documentation/authenticationservices/asauthorizationproviderextensionloginmanager/resetkeys/ However, during testing, I observed that calling resetKeys() also resets sharedDeviceSigningKey. I had assumed that shared device keys would only be reset via resetDeviceKeys().

I’m testing a macOS Platform SSO extension deployed through Jamf, and I’m seeing an issue where device registration completes successfully during Setup Assistant, but user registration never gets triggered. Current Platform SSO profile settings: Authentication mode:Secure Enclave Enable registration during setup:Enabled Create first user during Setup:Enabled New user creation authentication method:Password Observed behavior: The Platform SSO extension is discovered and loaded. Device registration starts and completes successfully. My extension’s device registration completion path is reached. registrationDidCompleteis called. The device configuration appears to be updated. After that, I expect Platform SSO to call the user registration flow, but my extension’sbeginUserRegistration(...)is never invoked. The strange part is that this only seems blocked at the user-registration handoff. Device registration during Setup Assistant works reliably.

We’re investigating a Platform SSO registration issue on macOS and wanted to check whether others have seen similar behavior or know whether this is expected system behavior. Scenario: Our extension implements ASAuthorizationProviderExtensionRegistrationHandler for device and user registration. On failure we complete with ASAuthorizationProviderExtensionRegistrationResult.failed, and on success we complete with .success. What we’re seeing: If registration fails multiple times, macOS shows multiple system dialogs saying: Registration failed and will automatically retry in a few minutes. If we do not close those earlier failure dialogs and then start another registration that succeeds, the old failure dialogs remain visible and do not dismiss automatically. They have to be closed manually one by one. From our side, these appear to be system-owned Platform SSO dialogs, not app-owned windows. We only return the registration result via the handler completion. Any guidance on whether macOS is expected to reconcile/dismiss earlier failure dialogs after a later success would also be helpful.

We are implementing Platform SSO with Secure Enclave–based authentication. In a standard (post-enrollment) flow, everything behaves as expected: Authentication uses urn:ietf:params:oauth:grant-type:jwt-bearer The Secure Enclave–backed credential is used correctly However, when using Automated Device Enrollment (ADE) with Simplified Setup, we observe different behavior: After device registration, Platform SSO triggers a login request to our IdP That request uses grant_type=password Instead of the expected urn:ietf:params:oauth:grant-type:jwt-bearer This occurs even though: The configuration specifies Secure Enclave as the authentication method The same configuration works as expected outside ADE Questions: Is this password grant during ADE / Simplified Setup an expected bootstrap flow? Is there any official documentation describing this? This behavior is currently undocumented, and clarification would help ensure correct IdP implementation.

Can a macOS Platform SSO extension reliably identify the original app behind a Safari or ASWebAuthenticationSession-mediated request, or does ASAuthorizationProviderExtensionAuthorizationRequest only expose the immediate caller such as Safari ? We are seeing: callerBundleIdentifier = com.apple.Safari callerTeamIdentifier = Apple audit-token-based validation also resolves to Safari So the question is whether this is the expected trust model, and if so, what Apple-recommended mechanism should be used to restrict SSO participation to approved apps when the flow is browser-mediated.

Hi, We are implementing Platform SSO and using attestKey during registration via ASAuthorizationProviderExtensionLoginManager. Could you clarify whether the attestKey flow involves sending attestation data to an Apple server for verification (similar to App Attest in the DeviceCheck framework), or if the attestation certificate chain is generated and signed entirely on-device without any Apple server interaction? The App Attest flow is clearly documented as using Apple’s attestation service, but the Platform SSO process is less clearly described. Thank you.

I’m implementing a macOS Platform SSO extension using ASAuthorizationProviderExtensionAuthorizationRequest. In beginAuthorization, I intercept an OAuth authorize request and call: request.complete(httpAuthorizationHeaders: [ "x-psso-attestation": signedJWT ]) I also tested: request.complete(httpAuthorizationHeaders: [ "Authorization": "Bearer test-value" ]) From extension logs, I can confirm the request is intercepted correctly and the header dictionary passed into complete(httpAuthorizationHeaders:) contains the expected values. However: the header is not visible in browser devtools the header does not appear at the server / reverse proxy So the question is: Does complete(httpAuthorizationHeaders:) support arbitrary custom headers, or only a restricted set of authorization-related headers ? Is there something that I might be missing ? And if custom headers are not supported, is there any supported way for a Platform SSO extension to attach a normal HTTP header to the continued outbound request ?

I need to launch ASWebAuthenticationSession from single sign on extension, but its not launching it might issue with anchoring window, I have create custom windo and passing it in presentanchor(for session) function, custom window is launching but ASWebAuthenticationSession browser is not launching Note - flow is like this Apple PSSO register window lauched OIDC login will happen via ASWebAuthenticationSession to get accesstoken which will use in device registration but ASWebAuthenticationSession is not launching, I am using custom scheme as redirect URI iskeywindow for custom window is always false what is right approach to achieve the goal

I have a question regarding Platform SSO and the use of Secure Enclave–backed keys with biometric policies. If we configure userSecureEnclaveKeyBiometricPolicy with userSecureEnclaveKey, my understanding is that the Secure Enclave key is protected by biometric authentication (e.g., Face ID / Touch ID). In this setup, during a login request that also refreshes the id_token and refresh_token, the assertion is signed using the userSecureEnclaveKey. My question is: Will this signing operation trigger a biometric prompt every time the assertion is generated (i.e., during login/token refresh) ?

While working with Platform SSO on macOS, I’m trying to better understand how the system handles cases where a user’s local account password becomes unsynchronized with their Identity Provider (IdP) password—for example, when the device is offline during a password change. My assumption is that macOS may store some form of persistent token during the Platform SSO user registration process (such as a certificate or similar credential), and that this token could allow the system to unlock the user’s login keychain even if the local password no longer matches the IdP password. I’m hoping to get clarification on the following: Does macOS actually use a persistent token to unlock the login keychain when the local account password is out of sync with the IdP password? If so, how is that mechanism designed to work? If such a capability exists, is it something developers can leverage to enable a true passwordless authentication experience at the login window and lock screen (i.e., avoiding the need for a local password fallback)? I’m trying to confirm what macOS officially supports so I can understand whether passwordless login is achievable using the persistent-token approach. Thanks in advance for any clarification.