We develop an authorization plugin that replaces password entry at the login window and at screen unlock with a phone-based sign-in. The user scans a QR code with their phone, or the Mac reaches the phone over Bluetooth. Either way the plugin ends up with the user's password, which it hands to the authorization engine as if it had been typed. All networking runs in a LaunchDaemon that the plugin calls over XPC.
Setup
system.login.console:loginwindow:login→OurPlugin:loginsystem.login.screensaver: ruleuse-login-window-ui→authenticate-session-owner-or-admin, withscreenUnlockModeset to 2authenticate:builtin:authenticate→OurPlugin:authenticate- The UI is an
SFAuthorizationPluginViewsubclass. On success we setusernameandpasswordin the context (plushomeat login) and callSetResultwithkAuthorizationResultAllow.
What we see on macOS 27
Since moving to macOS 27 on a MacBook Pro (M3 Pro), we hit these more often:
- Touch ID unlocks the Mac but leaves our view on screen. Open the lid and unlock with Touch ID. The desktop becomes usable, but our plugin view stays on top, and shortly after the screen locks again. Same symptom as thread 819454, where it was filed as FB22289735.
- Saved passwords disappear from apps after an unlock through our plugin. They come back only after the user logs out and in again. This looks like FB13128730 (thread 796487).
- The lock screen stays on the desktop after sign-in. The clock, the user picture and our view, with its filled-in password field, stay on screen while the menu bar and Dock are drawn on top of them. Similar to FB12074874.
We also saw this once: the password field in our view would not take keyboard input at the lock screen. Every key press just played the system alert sound, and nothing was typed.
Questions
- Is there any workaround for these on macOS 27? Or a supported way to stop macOS offering Touch ID while our plugin handles unlock?
- Is an
SFAuthorizationPluginViewplugin still a supported way to replace the login and unlock UI? If not, what should we move to? - Is Platform SSO with the new web-based authentication in macOS 27 (login window, Lock Screen and FileVault unlock) the path you would recommend? If so, is there a supported option for offline sign-in, which we do over Bluetooth today?
I’ve written the following as a general response. So, pawanquantum, this applies to you, but it also applies to anyone else who has created, or is thinking about creating, an authorisation plug-in.
Authorisation plug-ins are in a very parlous state. Honestly, I consider them to be deprecated, and I’m hoping that we formally deprecate them at some point (r. 190103576).
Given that, my general advice is that you not implement one. If you’re an identity provider looking to integrated with macOS, Platform SSO is the obvious path forward. If that’s missing a feature you need, please do file an enhancement request against it.
If you’re planning to use an authorisation plug-in for some other task, try to find an alternative. If you can’t find an alternative, file an enhancement request that describes what you’re trying to do, how you’re implementing that with an authorisation plug-in, why none of the existing alternatives work for you, and roughly what you’d like to use instead.
And if you do file an ER, please reply on this thread with your bug number so that I can add it to my records.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"