I noticed that the Keychain Access utility uses exactly what I am looking for if I delete something from the Keychain. Please see the attached screenshot. Any idea if this can be done using Local Authentication?

Thanks for the information. Filed an enhancement request FB16312095. Hope this helps. Best regards, Marc

Is there another way to authenticate a (non-admin) user with a smart card? I tried a few things using Authorization Services, but it only worked well with admin users. I know that Authorization Services is used to request authorization for something, but can I misuse it in some way to accomplish what I want?

@DTS Engineer If you want to see it that way, you're right, of course. I am currently just wondering which right I should request. I first thought of authenticate-session-owner, but that only works if the user is an admin. com.apple.trust-settings.user would generally work, but the text that is displayed during authentication is somewhat misleading. Is there something I can use or should I create a custom right for this? Many thanks in advance for your support. I really appreciate it.

Hi Quinn! This works pretty well. Just wondering if it would be possible to check if a smart card is available. Then I could switch to Local Authentication (Touch ID) otherwise. Thanks for helping me with this. Best regards, Marc

If a smart card is paired to the account, the AuthenticationAuthority contains an additional entry like tokenidentity;29A5F37DB3E09402BFD231B306D5AB4099EBFE4E.

During my testing it turned out that even if using Authorization Services, the Mac asks me for Touch ID. I always had in mind that this would only work using Local Authentication. So it seems that I don't have to use either one or the other but can build everything completely using Authorization Services. It asks me for Touch ID or PIN if a PIV token is connected, otherwise it asks me for Touch ID or Password.

Local Authorization's evaluatePolicy:localizedReason:reply: requires a partly localized reason, which is not ideal from a localization perspective. This is what the docs say: Application reason for authentication. This string must be provided in correct localization and should be short and clear. It will be eventually displayed in the authentication dialog as a part of the following string: "" is trying to . For example, if the app name is "TestApp" and localizedReason is passed "access the hidden records", then the authentication prompt will read: "TestApp" is trying to access the hidden records. What I found out now is, that the complete strings look as follows: Where the first placeholder contains the app name and the second placeholder contains the localized string the user provided. So I think I should be able to build the string I need. Best regards, Marc

BTW: I had to upload the above list as an image because otherwise my post supposedly contained sensitive language. Very strange...

Hi Quinn, opened feedback FB16445453. Best regards, Marc

@DTS Engineer I already tried this, but it only changes the icon of the alert, but the way the buttons are displayed is identical.

At least for macOS I can say that it still needs that substring. If you look at the APP_ASKING_AUTH keys in /System/Library/Frameworks/LocalAuthentication.framework/Support/coreautha.bundle/Contents/Resources/UIAgent.loctable you'll see exactly this and all my tests with the Local Authentication framework have also confirmed this. Best regards, Marc

Ok. But why do have some buttons a gray background and some a white one? Is this behavior is documented somewhere? That's the question I got from our accessibility folks…

@elementarteilchen The website is https://login.microsoftonline.com. It's a web form and WKWebView is configured to use persistent storage.

It turned out that the website uses Microsoft Enterprise SSO for authentication and my app's bundle identifier must be added to the AppAllowList in our Entra ID configuration. Microsoft describes this in the Enable SSO for specific apps section of their KB article Microsoft Enterprise SSO plug-in for Apple devices. After adding the app to that list, everything worked as expected.