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.

I’ve developed an authorization plug-in with a mechanism that runs an SFAuthorizationPluginView subclass and I’m facing a couple issues: - Glitch after successful login After setting kAuthorizationResultAllow in the context the user is successfully logged in and brought to the desktop but the login controls remain onscreen for a few seconds after login is complete, resulting in them being visible at the same time as the dock, menu bar and desktop.
 I’ve also tried what’s mentioned here https://aninterestingwebsite.com/forums/thread/780212 but without any luck. It’s also worth mentioning that the deinit() in my SFAuthorizationPluginView subclass never gets called when the plugin it’s loaded at the login stage but it does get called the plugin is used to re-authenticate the user after they locked their screen. - update() doesn't trigger the plugin to call view(for:) I’m trying to update the UI elements out of my control (like buttons and user avatar images) in order to have them placed at the proper position on the screen after a resize of my inner NSView. To do that I call update() but it appears that does not trigger the plugin to call view(for:) and update system UI elements placement. Is this the expected behavior? - setButton not working as expected 
I’m trying to disable the login button by calling the setButton(_:enabled:) passing a SFButtonTypeLogin as inButtonType, as suggested here: https://aninterestingwebsite.com/forums/thread/777432. When the method is called at the login screen it has no effect on the button (the one with the forward-arrow icon) but when it’s called by the plugin loaded at the ‘unlock screen’ stage it successfully disable the ‘OK’ button. - Certificate issue When trying to run a network request from the plugin loaded in the ‘unlock screen’ scenario, I always get this type of error: The certificate for this server is invalid. You might be connecting to a server that is pretending to be <<server_url>> which could put your confidential information at risk Everything works as expected when the plugin is loaded either at login screen or for authorizing an operation that requires admin privileges while the user is logged in.

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.

Hello everyone, In my application, i have implemented authentication using ASWebauthenticationSession. However, when redirecting the user to a WKWebView, no cookies are shared, causing the session to be lost and requiring the user to log in again. Is there a way to share cookies between the two? If not, what would be the best approach to set up authentication that ensures SSO when switching to a WebView ? Thank you very much for your help !

After registe Passkey with webauthn library, i create a passkeyRegistration with follow, let passkeyRegistration = ASPasskeyRegistrationCredential(relyingParty: serviceIdentifier, clientDataHash: clientDataHashSign, credentialID: credentialId, attestationObject: attestationObject) and then completeRegistrationRequest like that, extensionContext.completeRegistrationRequest(using: passkeyRegistration) But a bad outcome occurred from user agent. NotAllowedError:The request is not allowed by the user agent or the platform in the current context. And the return data rawID & credentialPublicKey is empty,

I have a custom NSWindow that I want to exclude from screen capture by setting its sharing state to kCGWindowSharingStateSharingNone. The goal is to prevent this window from appearing in the content captured by ScreenCaptureKit. [window setSharingType:NSWindowSharingType::NSWindowSharingNone]; However, on macOS 15.4+ (Sequoia), the window is still captured by ScreenCaptureKit and appears in the shared content. Does anyone know if kCGWindowSharingStateSharingNone is still effective with ScreenCaptureKit on macOS 15.4 and later?

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.

I'm trying to develop a GUI app on macOS that takes control of the screen so that user must perform certain actions before regaining control of the desktop. I don't want the user to be able to kill the process (for example via an "assassin" shell script that looks for the process and terminates it with kill). Based on this post it is not possible to create an unkillable process on macOS. I'm wondering, however, if it's possible to run the GUI process in root (or with other escalated privileges) such that the logged in user cannot kill it. So it's killable, but you need privileges above what the logged in user has (assuming they are not root). I'm not worried about a root user being able to kill it. Such an app would run in a managed context. I've played around with Service Background Tasks, but so far haven't found what I'm looking for. I'm hoping someone (especially from Apple) might be able to tell me if this goal is even achievable with macOS Sequoia (and beyond).

Hi, I’m seeing a production issue on iOS 26+ that only affects some users. symptoms: It does NOT happen for all users. It happens for a subset of users on iOS 26+. If we write a value to Keychain and read it immediately in the same session, it succeeds. However, after terminating the app and relaunching, the value appears to be gone: SecItemCopyMatching returns errSecItemNotFound (-25300). Repro (as observed on affected devices): Launch app (iOS 26+). Save PIN data to Keychain using SecItemAdd (GenericPassword). Immediately read it using SecItemCopyMatching -> success. Terminate the app (swipe up / kill). Relaunch the app and read again using the same service -> returns -25300. Expected: The Keychain item should persist across app relaunch and remain readable (while the device is unlocked). Actual: After app relaunch, SecItemCopyMatching returns errSecItemNotFound (-25300) as if the item does not exist. Implementation details (ObjC): We store a “PIN” item like this (simplified): addItem: kSecClass: kSecClassGenericPassword kSecAttrService: <FIXED_STRING> kSecValueData: kSecAttrAccessControl: SecAccessControlCreateWithFlags(..., kSecAttrAccessibleWhenUnlockedThisDeviceOnly, 0, ...) readItem (SecItemCopyMatching): kSecClass: kSecClassGenericPassword kSecAttrService: <FIXED_STRING> kSecReturnData: YES (uses kSecUseOperationPrompt in our async method) Question: On iOS 26+, is there any known issue or new behavior where a successfully added GenericPassword item could later return errSecItemNotFound after app termination/relaunch for only some users/devices? What should we check to distinguish: OS behavior change/bug vs. entitlement/access-group differences (app vs extension, provisioning/team changes), device state/policies (MDM, passcode/biometrics changes), query attributes we should include to make the item stable across relaunch? Build / Dev Environment: macOS: 15.6.1 (24G90) Xcode: 26.2

[Q] When is the kTCCServiceEndpointSecurityClient set by macOS and in which conditions? From what I'm gathering, the kTCCServiceEndpointSecurityClient can not be set by a configuration profile and the end user can only grant full disk access. I searched for documentation on Apple's develop website (with the "kTCCServiceEndpointSecurityClient" search) and did not get any useful result. Using a more complete search engine, or the forum search engine, only points to the old annoying big bug in macOS Ventura. The problem I'm investigating is showing a process being listed as getting granted kTCCServiceEndpointSecurityClient permissions in the TCC database when: it's not an Endpoint Security client. it does not have the ES Client entitlement. the bundle of the process includes another process that is an ES Client and is spawn-ed by this process but I don't see why this should have an impact. This process is supposed to have been granted kTCCServiceSystemPolicyAllFiles via end user interaction or configuration profile. AFAIK, the kTCCServiceEndpointSecurityClient permission can only be set by macOS itself. So this looks like to be either a bug in macOS, an undocumented behavior or I'm missing something. Hence the initial question. macOS 15.7.3 / Apple Silicon

We are experiencing a significant issue with macOS security alerts that began on July 9th, at approximately 4:40 AM UTC. This alert is incorrectly identifying output files from our snippet tests as malware, causing these files to be blocked and moved to the Trash. This is completely disrupting our automated testing workflows. Issue Description: Alert: We are seeing the "Malware Blocked and Moved to Trash" popup window. Affected Files: The security alert triggers when attempting to execute .par files generated as outputs from our snippet tests. These .par files are unique to each individual test run; they are not a single, static tool. System-Wide Impact: This issue is impacting multiple macOS hosts across our testing infrastructure. Timeline: The issue began abruptly on July 9th, at approximately 4:40 AM UTC. Before that time, our tests were functioning correctly. macOS Versions: The problem is occurring on hosts running both macOS 14.x and 15.x. Experimental Host: Even after upgrading an experimental host to macOS 15.6 beta 2, the issue persisted. Local execution: The issue can be reproduced locally. Observations: The security system is consistently flagging these snippet test output files as malware. Since each test generates a new .par file, and this issue is impacting all generated files, the root cause doesn't appear to be specific to the code within the .par files themselves. This issue is impacting all the snippet tests, making us believe that the root cause is not related to our code. The sudden and widespread nature of the issue strongly suggests a change in a security database or rule, rather than a change in our testing code. Questions: Could a recent update to the XProtect database be the cause of this false positive? Are there any known issues or recent changes in macOS security mechanisms that could cause this kind of widespread and sudden impact? What is the recommended way to diagnose and resolve this kind of false positive? We appreciate any guidance or assistance you can provide. Thank you.

I have developed a sample app following the example found Updating your app package installer to use the new Service Management API and referring this discussion on XPC Security. The app is working fine, I have used Swift NSXPCConnection in favour of xpc_connection_create_mach_service used in the example. (I am running app directly from Xcode) I am trying to set up security requirements for the client connection using setCodeSigningRequirement on the connection instance. But it fails for even basic requirement connection.setCodeSigningRequirement("anchor apple"). Error is as follows. cannot open file at line 46986 of [554764a6e7] os_unix.c:46986: (0) open(/private/var/db/DetachedSignatures) - Undefined error: 0 xpc_support_check_token: anchor apple error: Error Domain=NSOSStatusErrorDomain Code=-67050 "(null)" status: -67050 I have used codesign -d --verbose=4 /path/to/executable to check the attributes I do get them in the terminal. Other way round, I have tried XPC service provider sending back process id (pid) with each request, and I am probing this id to get attributes using this code which gives all the details. func inspectCodeSignature(ofPIDString pidString: String) { guard let pid = pid_t(pidString) else { print("Invalid PID string: \(pidString)") return } let attributes = [kSecGuestAttributePid: pid] as CFDictionary var codeRef: SecCode? let status = SecCodeCopyGuestWithAttributes(nil, attributes, [], &codeRef) guard status == errSecSuccess, let code = codeRef else { print("Failed to get SecCode for PID \(pid) (status: \(status))") return } var staticCode: SecStaticCode? let staticStatus = SecCodeCopyStaticCode(code, [], &staticCode) guard staticStatus == errSecSuccess, let staticCodeRef = staticCode else { print("Failed to get SecStaticCode (status: \(staticStatus))") return } var infoDict: CFDictionary? if SecCodeCopySigningInformation(staticCodeRef, SecCSFlags(rawValue: kSecCSSigningInformation), &infoDict) == errSecSuccess, let info = infoDict as? [String: Any] { print("🔍 Code Signing Info for PID \(pid):") print("• Identifier: \(info["identifier"] ?? "N/A")") print("• Team ID: \(info["teamid"] ?? "N/A")") if let entitlements = info["entitlements-dict"] as? [String: Any] { print("• Entitlements:") for (key, value) in entitlements { print(" - \(key): \(value)") } } } else { print("Failed to retrieve signing information.") } var requirement: SecRequirement? if SecRequirementCreateWithString("anchor apple" as CFString, [], &requirement) == errSecSuccess, let req = requirement { let result = SecStaticCodeCheckValidity(staticCodeRef, [], req) if result == errSecSuccess { print("Signature is trusted (anchor apple)") } else { print("Signature is NOT trusted by Apple (failed anchor check)") } } var infoDict1: CFDictionary? let signingStatus = SecCodeCopySigningInformation(staticCodeRef, SecCSFlags(rawValue: kSecCSSigningInformation), &infoDict1) guard signingStatus == errSecSuccess, let info = infoDict1 as? [String: Any] else { print("Failed to retrieve signing information.") return } print("🔍 Signing Info for PID \(pid):") for (key, value) in info.sorted(by: { $0.key < $1.key }) { print("• \(key): \(value)") } } If connection.setCodeSigningRequirement does not works I plan to use above logic as backup. Q: Please advise is there some setting required to be enabled or I have to sign code with some flags enabled. Note: My app is not running in a Sandbox or Hardened Runtime, which I want.

We are using SecItemCopyMatching from LocalAuthentication to access the private key to sign a challenge in our native iOS app twice in a few seconds from user interactions. This was working as expected up until about a week ago where we started getting reports of it hanging on the biometrics screen (see screenshot below). From our investigation we've found the following: It impacts newer iPhones using iOS 26.1 and later. We have replicated on these devices: iPhone 17 Pro max iPhone 16 Pro iPhone 15 Pro max iPhone 15 Only reproducible if the app tries to access the private key twice in quick succession after granting access to face ID. Looks like a race condition between the biometrics permission prompt and Keychain private key access We were able to make it work by waiting 10 seconds between private key actions, but this is terrible UX. We tried adding adding retries over the span of 10 seconds which fixed it on some devices, but not all. We checked the release notes for iOS 26.1, but there is nothing related to this. Screenshot:

Hi, I’d like to confirm something regarding the hosting of the apple-app-site-association (AASA) file. We have a server that publicly hosts the AASA file and is accessible globally. However, this server sits behind an additional security layer (a security server/reverse proxy). My question is: Will this security layer affect Apple’s ability to access and validate the AASA file for Universal Links or App Clips? Are there specific requirements (e.g. headers, redirects, TLS versions, etc.) that we need to ensure the security server does not block or modify? Any guidance or best practices would be appreciated.

I’d like to confirm something regarding the hosting of the apple-app-site-association (AASA) file. We have a server that publicly hosts the AASA file and is accessible globally. However, this server sits behind an additional security layer (a security server/reverse proxy). My question is: Will this security layer affect Apple’s ability to access and validate the AASA file for Universal Links or App Clips? Are there specific requirements (e.g. headers, redirects, TLS versions, etc.) that we need to ensure the security server does not block or modify? Any guidance or best practices would be appreciated. Thanks!

Hi there, I'm trying to use SFAuthorizationPluginView in order to show some fields in the login screen, have the user click the arrow, then continue to show more fields as a second step of authentication. How can I accomplish this? Register multiple SecurityAgentPlugins each with their own mechanism and nib? Some how get MacOS to call my SFAuthorizationPluginView::view() and return a new view? Manually remove text boxes and put in new ones when button is pressed I don't believe 1 works, for the second mechanism ended up calling the first mechanism's view's view() Cheers, -Ken

I've contacted Apple support about this topic, and they've directed me to this forum. I regularly perform Pentests of iOS applications. To properly assess the security of iOS apps, I must bypass given security precaution taken by our customers, such as certificate pinning. According to a number of blog articles, this appears to only be viable on jailbroken devices. If a target application requires a modern version of iOS, the security assessment can't be properly performed. As it should be in Apple's best interest, to offer secure applications on the App Store, what's the recommended approach to allow intrusive pentesting of iOS apps?

Has anyone here encountered this? It's driving me crazy. It appears on launch. App Sandbox is enabled. The proper entitlement is selected (com.apple.security.files.user-selected.read-write) I believe this is causing an issue with app functionality for users on different machines. There is zero documentation across the internet on this problem. I am on macOS 26 beta. This error appears in both Xcode and Xcode-beta. Please help! Thank you, Logan

Hello, I have encountered several challenges related to System Integrity Protection (SIP) state detection and code signing requirements. I would like to seek clarification and guidance on the proper approach to programmatically determine the SIP state. Here are the issues I’ve encountered: XPC Code Signing Check APIs: APIs like setCodeSigningRequirement and setConnectionCodeSigningRequirement do not work when SIP disabled and that's ok given what SIP is. LaunchCodeRequirement API: When using Process.launchRequirement, the LaunchCodeRequirement API does not function anymore when SIP disabled. The IsSIPProtected requirement behaves in a way that is not clearly documented -- it appears to only apply to pre-installed Apple apps. Legacy APIs: Older APIs like SecCodeCheckValidity are likely to be non-functional, though I haven’t had the chance to validate this yet. Private API Concerns: So to mitigate those limitations I prefer my app to not even try to connect to untrusted XPC or launch untrusted Processes when SIP is disabled. The only way to determine SIP state I could find is a low-level C function csr_get_active_config. However, this function is not declared in any publicly available header file, indicating that it is a private API. Since private APIs cannot be used in App Store-distributed apps and are best avoided for Developer ID-signed apps, this does not seem like a viable solution. Given these limitations, what is the recommended and proper approach to programmatically determine the SIP state in a macOS application? Any insights or guidance would be greatly appreciated. Thank you!