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.

Hello everyone, I'm currently in the process of implementing platform SSO (Single Sign-On) in macOS and could use some guidance. I find myself a bit confused during the device registration phase, particularly because my Identity Provider (IdP) needs to support it. I'm wondering if Platform SSO will handle this automatically or if there are specific steps I need to take. Additionally, I'm unsure whether I need to share the device signing and encryption key in my identity. Could someone please clarify this for me? Finally, I would greatly appreciate it if someone could provide me with some sample code or starting pointers to help me get started on the right track. More into apart from OpenID, SAML protocol what else the Idp needs to change to support Platform SSO. Thank you in advance for your assistance!

In https://developer.apple.com/forums/thread/128705?answerId=405119022#405119022, it is said that But if it’s holding up connections that match the on demand rules, that’s the correct behaviour. So if there was an on demand rule to connect for all domains (Connect rule without any matching criteria), all traffic would be held up while in the connecting state. The problem is that a customer can have SSO configured so that auth happens outside of the vpn app. So sequence would be Connect for all domains on demand rule triggers vpn connection VPN, in order to connect, tries auth through a broker app. VPN is in connecting state and blocks broker app traffic and so auth cannot complete and it cannot connect. I tried adding an on demand rule for EvaluateConnection and never connect for the auth domains. However, that caused the vpn to never be triggered to connect. Is it possible to support the scenario of an on demand rule to connect for all domains while having a vpn connection dependent on auth done in a separate app? Do you have any recommendations?

Hi, my iOS app using plugin.Firebase for google SSO. But the SSO show me a list of account which login previously, I can login with those account without inputting password. Anyway I can clean up the list or force to enter password? Thank you.

Hi, We are developing an Enterprise SSO extension for use by our customers. It is working well for username/password. We would like to use external security tokens such as Yubikey, via NFC. This works well inside the container app. However, it looks like NFC might not be available to the SSO extension? The container app is signed with an NFC entitlement, and has the relevant key in the plist for a prompt to show the user. We use a 3rd party package called Yubikit to communicate with the Yubikey in the container app... all good. In the trial I did, I had the SSO appex configured as a Credential extension. I have a demo/sample host app that uses this service, that mirrors what our customer's apps will do. Currently, due to limitations in the server we are connecting to, instead of relying on a 401 authentication challenge, I am "manually" activating the enterprise SSO credential appex using ASAuthorizationSingleSignOnProvider, then our customer's host app will use the token the SSO appex returns for authenticating its API calls. This is working perfectly for the username/password scenario. However some of our customers are very security conscious and require hardware tokens. When I drive the same code in the contained SSO Enterprise app extension, and attempt to activate the NFC reader the same way, it seems like it doesn't have access to NFC? I attempted to add the entitlement to the appex as well but it wasn't even available on the list of entitlements! This leads me to suspect that iOS doesn't allow the SSO appex process to have access to the NFC reader, and there's no way to do what I'm attempting? Note: it is easy for us to move to using a Redirect extension instead if this is the answer, but it doesn't seem that it's likely to help? What is the recommended approach here? Regards, Carl

I'm trying to create an "Extensible Enterprise SSO" extension as described in the Introducing Extensible Enterprise SSO tech talk. My SSO extension works fine, but I want to be able to access the camera (via AVFoundation) from within the SSO extension. According to this thread (which I can't seem to be able to reply to) - it should be possible to access the camera from within an SSO extension, however this doesn't work for me. When I try to access the camera, I get the permission dialog, but after accepting, the camera preview is empty and no camera frames are produced. I don't get any errors/warnings in the logs, but it immediately fires AVCaptureSession.wasInterruptedNotification notification with AVCaptureSessionInterruptionReasonKey = 1 which corresponds to videoDeviceNotAvailableInBackground. However, the SSO extension view controller is clearly not in the background, so is this a bug - or are there special rules for requesting camera permission in an SSO extension? The same camera access works fine in the host app, just not inside the extension. Interestingly, accessing the camera in a WKWebView using various webcam test pages, doesn't work either. All of these tests have been on iPadOS 18.

Hi all. So, I built the platform SSO extension on a demo server I created and everything ran smoothly. I get the tokens at the end of the process. Now, I want to use the tokens when I trigger my SSO extension in my domain from Safari. I trigger my domain, get into the beginAuthorization method, get the request.loginManager?.ssoTokens and then want to return them to Safari by calling the request.complete method. But, no matter what complete method I call (complete(httpResponse: HTTPURLResponse, httpBody: Data?) or complete(httpAuthorizationHeaders: [String : String]) where I insert the Bearer token into the Authorization header, it will not drill down to Safari or my server. The headers I try to send back are not moving from the extension to Safari. Some knows why its happening? Thank you for any help or suggestion.

Hi, I'm currently in the middle of debugging between my macOS and server for implementing Platform SSO. As part of the debug process, I sometimes want to restart the whole process, which means to get into the beginDeviceRegisteration method again. I noticed that even if I push the Repair button in the user (under settings) it will go again and again into the beginUserRegistration, but it will not go again to the device registration. Is there an option to reset the Platform SSO device registration? (already tried Repair, remove MDM profile of the PSSO etc.)