Implement macOS passkey and security key support#44
Conversation
|
Thanks for the pr. After my first look at it this looks great. I still need to find some time to look deeper into it (probably tomorrow) and get a friend of mine to test it. |
|
Could you please take a look at my comments and check if that is possible? Just some things i noticed on my first look. Would it be possible to make the example working on macos to make it easier to test or do you need to do everything that is described in the README.md also for dev builds? |
Use ASAuthorizationPlatformPublicKeyCredentialProvider and ASAuthorizationSecurityKeyPublicKeyCredentialProvider for native passkey and hardware security key registration and authentication on macOS. Communicates between Rust and Swift via C FFI with async callback pattern through swift-rs.
Sadly, Apple's process for signing and entitlements requires all of that stuff to get this working (unless some level 100 mac/ios dev has some greater insight here). Also requires the web domain hosting the AASA file, passkey ceremony, etc. to have HTTPS set up correctly and thusly it will not work with local dev. The only potential addition we could add is a template |
|
|
||
| unsafe { | ||
| webauthn_register( | ||
| std::ptr::null_mut(), |
There was a problem hiding this comment.
Why are you passing a null pointer instead of just removing the argument and the usage of NSWindow in the Swift code when it is always null?
There was a problem hiding this comment.
Good catch. This just got leftover from the earliest implementation.
|
The code looks good to me. I just found one more thing you need to take a look at. I hope that I can get someone to test this next week so this can be merged. |
- Remove unused window_ptr parameter - Replace tokio+futures with std::sync::mpsc+recv_timeout
Addressed that last comment. I also went ahead and ran a swift linter across the code and did some minor formatting fixes. Also pulled out the use of |
I'm not a level 100 mac dev but I do have this mostly addressed over here: https://github.com/dkackman/tauri-plugin-secure-element with this script. To run dev on macos one needs to build and sign the package if it needs to use security APIs. It will not work from iOS uses xcode to build which properly handles dev signing and such. For both ios and macos, you have to jump through apple developer hoops. I'll attempt to document the entire process, which is kind of involved. I have a branch of your PR @fendent with both ios working and the script above wired in for macos. Should be PR ready in a bit. |
|
Do you need a paid apple developer account for testing or can you do local testing without it? |
for ios you can get away with a free account. macos, at least the only way I could figure out with ample help from claude, you need a paid account in order to provision access to restricted entitlements. And you need those entitlements to sign the code. I don't think tauri supports xcode for macos the way it does for ios which is a real bummer. |
Thank you! I was under the impression that iOS, even signed, would still ultimately fail if the associated domain(s) serving the AASA file were not communicating with HTTPS/TLS. Great news if that's not the case. |
Oh. I was speaking to just getting the app packages actually running, not the https part. The relying party requires a domain (no IP address binding) AND https. Since I've got a domain that I control, I setup a free tier cloudflare worker. So no additional cost there if you have a domain. So many moving part with this, especially on apple dev. |
3 participants
Uses ASAuthorizationPlatformPublicKeyCredentialProvider and ASAuthorizationSecurityKeyPublicKeyCredentialProvider for native passkey/hardware security key registration and authentication on macOS.
Communicates between Rust and Swift via C FFI with async callback pattern through swift-rs.