We have a custom SecurityAgentPlugin that is triggered by multiple authorizationdb entries. Some customers report that the SecurityAgent process takes window focus even though no UI or windows are displayed.
Our plugin explicitly ignores the _securityAgent user and does not show any UI for that user. However, in macOS 26.1, it appears that the plugin still causes the SecurityAgent to take focus as soon as it is triggered.
Is this a change in macOS 26.1 or a bug? Can we do anything to prevent "focus stealing"?
Security Interface
RSS for tagThe Security Interface framework is a set of Objective-C classes that provide user interface elements for programs that implement security features.
Posts under Security Interface tag
33 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I'm looking to implement USB monitoring for FIDO2 authentication through a custom Authorization Plugin, specifically for the below ones.
This plugin applies to the following macOS authorization mechanisms:
system.login.console — login window authentication
system.login.screensaver — screensaver unlock authentication
The goal is to build a GUI AuthPlugin, an authorization plugin that presents a custom window prompting the user to "Insert your FIDO key”. Additionally, the plugin should detect when the FIDO2 device is removed and respond accordingly.
Additional Info:
We have already developed a custom authorization plugin which is a primary authentication using OTP at login and Lock Screen. We are now extending to include FIDO2 support as a primary.
Our custom authorization plugin is designed to replace the default loginwindow:login mechanism with a custom implementation.
Question: Is there a reliable approach to achieve the USB monitoring functionality through a custom authorization plugin? Any guidance or pointers on this would be greatly appreciated.
I've been spending days trying to solve the memory leak in a small menu bar application I've wrote (SC Menu). I've used Instruments which shows the leaks and memory graph which shows unreleased allocations. This occurs when someone views a certificate on the smartcard.
Basically it opens a new window and displays the certificate, the same way Keychain Access displays a certificate. Whenever I create an SFCertificateView instance and set setDetailsDisclosed(true) - a memory leak happens. Instruments highlights that line.
import Cocoa
import SecurityInterface
class ViewCertsViewController: NSViewController {
var selectedCert: SecIdentity? = nil
override func viewDidLoad() {
super.viewDidLoad()
self.view = NSView(frame: NSRect(x: 0, y: 0, width: 500, height: 500))
self.view.wantsLayer = true
var secRef: SecCertificate? = nil
guard let selectedCert else { return }
let certRefErr = SecIdentityCopyCertificate(selectedCert, &secRef)
if certRefErr != errSecSuccess {
os_log("Error getting certificate from identity: %{public}@", log: OSLog.default, type: .error, String(describing: certRefErr))
return
}
let scrollView = NSScrollView()
scrollView.translatesAutoresizingMaskIntoConstraints = false
scrollView.borderType = .lineBorder
scrollView.hasHorizontalScroller = true
scrollView.hasVerticalScroller = true
let certView = SFCertificateView()
guard let secRef = secRef else { return }
certView.setCertificate(secRef)
certView.setDetailsDisclosed(true)
certView.setDisplayTrust(true)
certView.setEditableTrust(true)
certView.setDisplayDetails(true)
certView.setPolicies(SecPolicyCreateBasicX509())
certView.translatesAutoresizingMaskIntoConstraints = false
scrollView.documentView = certView
view.addSubview(scrollView)
// Layout constraints
NSLayoutConstraint.activate([
scrollView.leadingAnchor.constraint(equalTo: view.leadingAnchor),
scrollView.trailingAnchor.constraint(equalTo: view.trailingAnchor),
scrollView.topAnchor.constraint(equalTo: view.topAnchor),
scrollView.bottomAnchor.constraint(equalTo: view.bottomAnchor),
// Provide certificate view a width and height constraint
certView.widthAnchor.constraint(equalTo: scrollView.widthAnchor),
certView.heightAnchor.constraint(greaterThanOrEqualToConstant: 500)
])
}
}
https://github.com/boberito/sc_menu/blob/dev_2.0/smartcard_menu/ViewCertsViewController.swift
Fairly simple.
Hi,
I have a certificate, how can I display the certificate content in my Mac app just like Keychain Access app does. Can I popup the certificate content dialog just like Keychain Access app?
Hi Team,
We are trying to understand deep sleep behaviour, can you please help us clarifying on the below questions:
When will we configure Hibernate 25, is it valid for M series MacBooks?
Is Hibernate 25 called deep sleep mode?
What are the settings I need to do on Mac, to make my Mac go in to deep sleep?
When awakening from deep sleep , what would be macOS system behaviour?
If we have custom SFAuthorization plug in at system.login.screensaver, what would be the behaviour with deep sleep?
Hi,
I have a set of plugins which are registered for login.
One of them is a custom ui view for the login screen.
The scenario:
1.DisableFDEAutoLogin is false.
2.The User logs in to the file vault login screen.
3.The security plugins are activated, and working.
4.We get any kind of an error from the plugins, and therefore the login fails.
5.We get a native login screen, after the denial of authorization.
6.In case that DisableFDEAutoLogin is true, I do get the custom login screen, after the file vault login.
My question:
Why dont I see the custom login screen, after the auto login fails?
Cheers
Sivan
Hi,
A user logs in to the file vault, and DisableFDEAutoLogin is false. The file vault login succeeds, but the login to the selected user fails. The user gets the login screen again. If the user puts an invalid password to try and login again, the loginwindow:FDESupport plugin will change the user's password to the invalid one.
Testing my security agent plugin on Tahoe and find that when unlocking the screen, I now get an extra window that pops up over the SFAuthorizationPluginView that says "macOS You must enter a password to unlock the screen" with a Cancel (enabled) and OK button (disabled). See the attached photo. This is new with Tahoe.
When unlocking the screen, I see the standard username and password entry view and I enter my password and click OK. That is when this new view appears. I can only click cancel so there is no way to complete authenticating.
Has anybody else experienced something similar? This is on the login screen.
I call update() and it doesn't call me back with view()
2025-08-21 17:04:38.669 Db SecurityAgentHelper-arm64[1134:2df1] [***:LoginView] calling update()
Then silence...
When we enable 3rd party authentication plugin using SFAuthorization window, then when user performs Lock Screen and then unlock the MAC. Now after unlock, if user tries to open Keychain Access, it is not getting opened.
When trying to open Keychain Access, we are prompted for credentials but after providing the credentials Keychians are not getting opened.
This is working on Sonoma 14.6.1 , but seeing this issue from macOS Sequoia onwards.
Are there any suggested settings/actions to resolve this issue?
I'm having trouble dealing with concurrency with the SFAuthorizationPluginView. Does anybody know how this can be solved?
https://developer.apple.com/documentation/securityinterface/sfauthorizationpluginview
The crux of it is:
If I inherit an object as part of an API, and the API is preconcurrency, and thus is nonisolated (but in reality is @MainActor), how do I return a @MainActor GUI element?
https://developer.apple.com/documentation/securityinterface/sfauthorizationpluginview/firstresponder()
The longer story:
I made my view class inherit SFAuthorizationPluginView.
The API is preconcurrency (but not marked as preconcurrency)
I started using concurrency in my plugin to retrieve data over XPC. (https://developer.apple.com/documentation/xpc/xpcsession + https://developer.apple.com/documentation/swift/withcheckedthrowingcontinuation(isolation:function:_:))
Once I retrieve the data over XPC, I need to post it on GUI, hence I've set my view class as @MainActor in order to do the thread switch.
Swift compiler keeps complaining:
override func firstResponder() -> NSResponder? {
return usernameField
}
"Main actor-isolated property 'usernameField' can not be referenced from a nonisolated context; this is an error in the Swift 6 language mode"
override func firstResponder() -> NSResponder? {
MainActor.assumeIsolated {
return usernameField
}
}
"Sending 'self' risks causing data races; this is an error in the Swift 6 language mode"
I think fundamentally, the API is forcing me to give away a @MainActor variable through a nonisolated function, and there is no way to shut up the compiler.
I've tried @preconcurrency and it has no effect as far as I can tell. I've also tried marking the function explicitly as nonisolated.
The rest of the API are less problematic, but returning a GUI variable is exceptionally difficult.
What Has Been Implemented
Replaced the default loginwindow:login with a custom authorization plugin.
The plugin:
Performs primary OTP authentication.
Displays a custom password prompt.
Validates the password using Open Directory (OD) APIs.
Next Scenario was handling password change
Password change is simulated via: sudo pwpolicy -u robo -setpolicy "newPasswordRequired=1"
On next login:
Plugin retrieves the old password.
OD API returns kODErrorCredentialsPasswordChangeRequired.
Triggers a custom change password window to collect and set new password.
Issue Observed : After changing password:
The user’s login keychain resets.
Custom entries under the login keychain are removed.
We have tried few solutions
Using API, SecKeychainChangePassword(...)
Using CLI, security set-keychain-password -o oldpwd -p newpwd ~/Library/Keychains/login.keychain-db
These approaches appear to successfully change the keychain password, but:
On launching Keychain Access, two password prompts appear, after authentication, Keychain Access window doesn't appear (no app visibility).
Question:
Is there a reliable way (API or CLI) to reset or update the user’s login keychain password from within the custom authorization plugin, so:
The keychain is not reset or lost.
Keychain Access works normally post-login.
The password update experience is seamless.
Thank you for your help and I appreciate your time and consideration
Topic:
Privacy & Security
SubTopic:
General
Tags:
Open Directory
Security
Privacy
Security Interface
Hi! We are developing an authentication plugin for macOS that integrates with the system's authentication flow. The plugin is designed to prompt the user for approval via a push notification in our app before allowing access. The plugin is added as the first mechanism in the authenticate rule, followed by the default builtin:authenticate as a fallback.
When the system requests authentication (e.g., during screen unlock), our plugin successfully displays the custom UI and sends a push notification to the user's device. However, I've encountered the following issue:
If the user does not approve the push notification within ~30 seconds, the system resets the screen lock (expected behavior).
If the user approves the push notification within approximately 30 seconds but doesn’t start entering their password before the timeout expires, the system still resets the screen lock before they can enter their password, effectively canceling the session.
What I've Tried:
Attempted to imitate mouse movement after the push button was clicked to keep the session active.
Created a display sleep prevention assertion using IOKit to prevent the screen from turning off.
Used the caffeinate command to keep the display and system awake.
Tried setting the result as allow for the authorization request and passing an empty password to prevent the display from turning off.
I also checked the system logs when this issue occurred and found the following messages:
___loginwindow: -[LWScreenLock (Private) askForPasswordSecAgent] | localUser = >timeout
loginwindow: -[LWScreenLock handleUnlockResult:] _block_invoke | ERROR: Unexpected _lockRequestedBy of:7 sleeping screen
loginwindow: SleepDisplay | enter
powerd: Process (loginwindow) is requesting display idle___
These messages suggest that the loginwindow process encounters a timeout condition, followed by the display entering sleep mode. Despite my attempts to prevent this behavior, the screen lock still resets prematurely.
Questions:
Is there a documented (or undocumented) system timeout for the entire authentication flow during screen unlock that I cannot override?
Are there any strategies for pausing or extending the authentication timeout to allow for complex authentication flows like push notifications?
Any guidance or insights would be greatly appreciated. Thank you!
Step1. Update system.login.screensaver authorizationdb rule to use “authenticate-session-owner-or-admin”( to get old SFAutorizationPluginView at Lock Screen ). Here I will use my custom authorization plugin.
Step 2. Once the rule is in place, logout and login, now click on Apple icon and select “Lock Screen”.
Is there a way programmatically to update the Lock Icon and the test getting displayed on the first Unlock screen? When I write a custom authorisation plug-in, I am getting control of the text fields and any consecutive screen I add from there on. But all I want is to update the lock icon and text fields on 1st unlock display itself. Can you please suggest how I can achieve this? Here is the screenshot with marked areas I am looking control for.
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
Regarding the issue of login controls remaining on screen for a few seconds when using a subclass of SFAuthorizationPluginView, I wanted to inquire whether any progress has been made on resolving it.
To recap, per notes I found in the QAuthPlugins sample code:
Due to a bug (FB12074874), the use of an SFAuthorizationPluginView subclass can cause the login controls to remain onscreen for a significant amount of time (roughly 5 seconds) after login is complete, resulting in them being onscreen at the same time as the Finder’s menu bar and the Dock. The exact circumstances under which this happens are not well understood, but one factor seems to be running on a laptop where the main display is mirrored to an external display.
Specifically, I would like to know:
If there any other information about how the issue is reproduced? For my part I can say that it reproduces with out the use of a mirrored display. So far it reproduces for all of our developers and testers, all of the time.
Are there any known workarounds?
Is there any expectation that this issue will be addressed?
Thank you so much!
I modified the system.login.screensaver rule in the authorization database to use "authenticate" instead of "use-login-window-ui" to display a custom authentication plugin view when the screensaver starts or the screen locks.
However, I noticed an issue when the "Require Password after Display is Turned Off" setting is set to 5 minutes in lock screen settings:
If I close my Mac’s lid and reopen it within 5 minutes, my authentication plugin view is displayed as expected.
However, the screen is not in a locked state—the desktop remains accessible, and the black background that typically appears behind the lock screen is missing.
This behavior differs from the default lock screen behavior, where the screen remains fully locked, and the desktop is hidden.
Has anyone encountered this issue before? Is there a way to ensure the screen properly locks when using authenticate in the screensaver rule?
Hi,
I am creating a custom login window, so I am using SFAuthorizationpluginView, here I want to hide Submit Arrow botton which gets displayed beside username and password text feild
, is there a way to hide this, please suggest.
I am developing an Authorisation Plugin which talks to Launch daemons over XPC.
Above is working neat, now I have to decide on how to get it installed on a machine.
Installation requires.
Plugin Installation
Launch Daemon Installation
Both require
Moving binary and text (.plist) file into privileged system managed directory.
Firing install/load commands as root (sudo).
I have referred this post BSD Privilege Escalation on macOS, but I am still not clear how to approach this.
Q: My requirement is:
I can use .pkg builder and install via script, however I have some initialisation task that needs to be performed. User will enter some details talk to a remote server and get some keys, all goes well restarts the system and my authorisation plugin will welcome him and get him started.
If I cannot perform initialisation I will have to do it post restart on login screen which I want to avoid if possible.
I tried unconventional way of using AppleScript from a SwiftUI application to run privileged commands, I am fine if it prompts for admin credentials, but it did not work.
I don't want that I do something and when approving it from Apple it gets rejected.
Basically, how can I provide some GUI to do initialisation during installation or may be an app which helps in this.
Q: Please also guide if I am doing elevated actions, how will it affect app distribution mechanism. In Read Me for EvenBetterAuthorizationSample I read it does.
Thanks.
I am developing a sample authorization plugin to sync the user’s local password to the network password. During the process, I prompt the user to enter both their old and new passwords in custom plugin. After the user enters the information, I use the following code to sync the passwords:
try record.changePassword(oldPssword, toPassword: newPassword)
However, I have noticed that this is clearing all saved keychain information, such as web passwords and certificates. Is it expected behavior for record.changePassword to clear previously stored keychain data?
If so, how can I overcome this issue and ensure the keychain information is preserved while syncing the password?
Thank you for your help!