We are evaluating whether Apple Platform SSO can be used by a native macOS application to silently authenticate against our backend through an identity provider's SSO extension. Our environment is as follows: Apple Platform SSO is configured and active. Device registration and user registration have completed successfully. Authentication is backed by Secure Enclave / Platform SSO. The identity provider is integrated through an SSO extension. Tokens are active and Not Expired We would like to understand the intended behavior and supported usage patterns of Platform SSO from the perspective of a third-party native macOS application. Specifically: Once Platform SSO is active, is there a supported way for a third-party macOS application to obtain IdP bearer/access tokens silently (without UI, password prompts, or web-based authentication) through the SSO extension? If silent token acquisition is supported, is it intended to work for any third-party application, or only for applications developed and distributed by the IdP/vendor that provides the SSO extension? In our testing, requests created via ASAuthorizationSingleSignOnRequest are rejected by the extension with doNotHandle. Does this generally indicate that: the request falls outside the extension's supported flow, a different request configuration is expected, or ASAuthorizationSingleSignOnRequest is not intended for this Platform SSO scenario? For native macOS applications that need silent authentication, should the recommended approach be: standard OAuth/OIDC flows, Platform SSO APIs, or a combination of both? If OAuth/OIDC is involved, which parts of those flows are expected to be handled transparently by Platform SSO and the SSO extension? If a combination of both is the recommended approach, many OAuth/OIDC flows rely on flow-specific security mechanisms such as client secrets, private keys, client certificates, or signed client assertions. In that case, the overall model becomes unclear Is there a standard protocol or capability that SSO extensions are expected to implement to support application authentication under Platform SSO, or is this entirely vendor-specific and dependent on the IdP's implementation and SDK? If there is an Apple-recommended pattern for enabling silent authentication from native third-party macOS applications when an IdP SSO extension is present, we would appreciate any guidance or references to relevant documentation. Thank you.

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

Throughout the years I've done a few integrations at my company with an iOS Application and an identity provider. I've implemented samples with UIWebView, WKWebview, Certificate based authentication through custom URLSession implementations and lastly through ASWebAuthentication. Also I gave the SSO Extension a try, but got stuck at some point (also Apple Forum didn't give me some solution -> https://developer.apple.com/forums/thread/117747) I'm having troubles digging through the Apple resources to find the best approach for big enterprises. We make use of a MDM solution, so I was hoping to find means to 'exploit it' and don't implement any custom authenticationframework anymore. Also, granting SSO between Apps and websites is what my ideal goal would be. Could you point me to some resources that can help me or give me some guidance on which of the frameworks/SDKs to use?

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.

Hi, I’m working with an SSO extension (ASAuthorizationProviderExtension) and am looking for clarification on how Apple determines whether the calling app is considered managed for ASAuthorizationProviderExtensionAuthorizationRequest.isCallerManaged. In my test, the authorization request is triggered from an app that is managed by our organization. We are using Jamf. However, in the SSO extension, I see the following caller metadata isCallerManaged=false I’d like to understand what conditions must be met for isCallerManaged to return true. Thanks.

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 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) ?

Hi, We developed a Platform SSO extension for our IdP, Keycloak. It would be great to get some feedback on it: https://francisaugusto.com/2025/Platform_single_sign_on_diy/

Hi, I developed a Platform Single Sign-On extension and a corresponding extension for my IdP, which is Keycloak based. The code for both projects are here: https://github.com/unioslo/keycloak-psso-extension and https://github.com/unioslo/weblogin-mac-sso-extension I realized that, when using the Secure Enclave as the AuthenticationMethod, and according to Apple's documentation, the Extension doesn’t obtain fresh ID Tokens when they expire if the refresh token is still valid. When using password as the Authentication Method, it fetches new ID tokens when they expire, without prompting the user for credentials, by using the refresh token. My suggestion is that the same behavior should be implemented for Secure Enclave keys. The thing here is that usually, on OIDC flows, the ID/Access tokens are short-lived. It would make sense for the extension to provide fresh ID tokens. It doesn’t seem to make sense for me that, when using passwords, the extension would fetch these tokens, and not when having the Secure Enclave key. By not doing this, Apple almost forces the developer of an extension to fetch new ID tokens themselves, which doens’t make sense when it clearly provides fresh tokens when using passwords. It almost forces the developers to either implement that logic themselves, or to issue longer tokens, which is not so nice. How so you deal with this? Do you simply use the refresh token as an authentication token, or do you do some sort of manual refresh on the extension?

I am developing an SSO Extension so that I can have SSO with Keycloak across applications. OIDC/OAuth2 works very well. But I am struggling with SAML. It works, but it seems that the form submission is always triggered twice. I use decisionHandler(.cancel) to stop the form submission and redirect it to the browser. I still get the form submitted both by the extension and by the browser. At some point I tried to allow the form submission in the Extension so that I get the redirect with the response to the browser. It still triggered another submission. Does anyone experience this issue?

We have a SAML-based SSO App Extension that uses WKWebView to load the SAML login request. This implementation has been working correctly on iOS versions prior to 26. However, starting with iOS 26, the extension consistently crashes when calling WKWebView.load(_:). The crash occurs inside WebKit, specifically in: /Library/Caches/com.apple.xbs/Sources/WebKit/Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp at WebKit::WebPageProxy::loadRequest(...) No app-level exception is thrown, and the extension terminates with: Thread 10: EXC_BREAKPOINT (code=1, subcode=0x1a31dbe00) It appears that WKWebView initialization or WebsiteDataStore creation is now restricted in extension contexts on iOS 26, but this change is not documented in the SDK release notes. Could you please confirm if this is an intentional sandbox restriction in iOS 26 or a regression in WebKit? Steps to reproduce: Implement an App Extension using ASAuthorizationProviderExtensionAuthorizationRequest. Create a WKWebView instance in the extension. Attempt to load a SAML login request (POST request with headers). Observe immediate crash on iOS 26 (works fine on earlier versions). Expected behavior: WKWebView should load the request or fail gracefully as in prior releases, without crashing the extension process. Request: Please clarify if WKWebView usage inside extensions is officially unsupported as of iOS 26, and if so, recommend an alternative approach for handling SSO flows.

Hello, I'm running into an issue with a complex macOS application (non-AppStore) structure involving an unsandboxed system daemon and a sandboxed SSO Extension attempting to communicate via XPC Mach service. The macOS app is composed of three main components: Main App: unsandboxed, standard macOS application. System Daemon: unsandboxed executable installed with a .plist to /Library/LaunchDaemons/ and loaded by launchd. It exposes an XPC Mach Service. SSO Extension: a sandboxed Authentication Services Extension (ASAuthorizationProviderExtension). Main App to System Daemon communication works perfectly. The unsandboxed main app can successfully create and use an XPC connection to the System Daemon's Mach service. But SSO Extension cannot establish an XPC connection to the System Daemon's Mach service, despite using the recommended temporary exception entitlement. I have added the following entitlement to the SSO Extension's entitlements file: <key>com.apple.security.temporary-exception.mach-lookup.global-name</key> <array> <string>my.xpc.service.system.daemon</string> </array> (The name my.xpc.service.system.daemon is the exact name registered by the System Daemon in its Launch Daemon plist's MachServices dictionary.) When the SSO Extension attempts to create the connection, the following log output is generated: default 08:11:58.531567-0700 SSOExtension [0x13f19b090] activating connection: mach=true listener=false peer=false name=my.xpc.service.system.daemon default 08:11:58.532150-0700 smd [0xb100d8140] activating connection: mach=false listener=false peer=true name=com.apple.xpc.smd.peer[1575].0xb100d8140 error 08:11:58.532613-0700 smd Item real path failed. Maybe the item has been deleted? error 08:11:58.532711-0700 SSOExtension Unable to find service status () error: 22 The error Unable to find service status () error: 22. Error code 22 typically translates to EINVAL (Invalid argument), but in this context, it seems related to the system's ability to find and activate the service for the sandboxed process. Questions: Is the com.apple.security.temporary-exception.mach-lookup.global-name entitlement sufficient for a sandboxed SSO Extension to look up a system-wide Launch Daemon Mach service, or are there additional restrictions or required entitlements for extensions? The smd log output Item real path failed. Maybe the item has been deleted? seems concerning. Since the unsandboxed main app can connect, this suggests the service is running and registered. Could this error indicate a sandbox permission issue preventing smd from verifying the path for the sandboxed process? Are there specific sandboxing requirements for Mach service names when communicating from an Extension versus a main application? Any guidance on how a sandboxed SSO Extension can reliably connect to an unsandboxed, non-app-group-related system daemon via XPC Mach service would be greatly appreciated!

Hi, We are using the MSAL library to authenticate users, with SSO authentication implemented through the Microsoft Authenticator app. The problem is that once or twice a day, a prompt for forced authentication appears, indicating that silent token acquisition is failing and resulting in a requirement for forced authentication. Below are some of the logs: ================================================= 2025-08-28 11:00:05.034 [Info] [AppDelegate.swift:121] application(:didFinishLaunchingWithOptions:) > MSAL message: TID=751353 MSAL 1.8.1 iOS 18.5 [2025-08-28 10:00:05 - EC9D1457-2D70-4878-926F-553391EBC9D3] [MSAL] Silent flow finished. Result (null), error: -51115 error domain: MSIDErrorDomain 2025-08-28 11:00:05.034 [Info] [AppDelegate.swift:121] application(:didFinishLaunchingWithOptions:) > MSAL message: TID=751353 MSAL 1.8.1 iOS 18.5 [2025-08-28 10:00:05 - EC9D1457-2D70-4878-926F-553391EBC9D3] [MSAL] acquireTokenSilent returning with error: (MSALErrorDomain, -50002) Masked(not-null) ==================================================== We initially raised this issue with Microsoft, but according to them: In the app's logs, the single one failure it contains, was when the SSO extension returned the error com.apple.AuthenticationServices.AuthorizationError, -6000 during a silent call. This error code is generated by the system framework (Apple), not by our code. It indicates that the framework encountered an unexpected internal issue before or after calling the SSO extension. MSAL returning interaction_required to the client app is the most effective way to recover from this error (as you mention, after the user selects the account the app continues working as expected). Additionally, as you also mention, the interactive call is made by switching to Authenticator (not displaying a "window" without leaving Eva Lite app), which means MSAL is not able to use the SSO extension and is using the fallback to legacy authentication. The recommended next step is for the customer to request support directly from Apple as this is an issue on their side. Additionally, the customer can also try to update to the latest iOS, in case Apple has already fixed this issue. ============================================= STEPS TO REPRODUCE There is no such steps its just that this is an enterprise application which is getting used on managed devices[iPhone 14]. The device are managed using some intune policy. Platform and Version: iOS Development Environment: Xcode 15, macOS 13.6.1 Run-time Configuration: iOS 18 Please let me know if there are any solutions to resolve this problem. Thank you.

Dear Team, We are working on retrieving email address of the user joined to Entra ID from Entra-joined macOS devices, specifically while running in a system context.The sudo dscl . -read /Users/$(whoami) RecordName command give the local user name whose password is synced with the entra ID. We would greatly appreciate guidance on how to retrieve the Entra ID joined user’s email address in a system context from Entra Joined mac devices, especially from those with prior experience in this area. Thank you for your support.

I tried with VSUserAccountManager.shared.requestAutoSignInAuthorization(). It did prompt a popup but with errors. I do have 'com.apple.smoot.subscriptionservice' configured in the entitlement. I don't know what's happened? Could you help me out.