macOS FIDO2/Webauthn support for web authentication

Hello.

Does WKWebView on Mac support FIDO2(webauthn)? We need to implement this in our app and ASWebAuthenticationSession API comes up in searches all the time as the only solution. Is this still the case? From my experiments ASWebAuthenticationSession on Mac doesn't provide best user experience - too much fiddling and odd behavior for an end user. F.e. user needs to click Open button from the browser window to pass token to the very same app which initiated the window and this is not very logical considering all the efforts to setup applink.

Would appreciate an advice.

Up vote post of tandre Down vote post of tandre
1.3k views
Posted by
tandre
Reply
Add a Comment

Accepted Reply

Yes, WKWebView supports WebAuthn as long as your app is using Associated Domains (specifically the webcredentials association) with the RPID that you're using. If you need to authenticate to third party services, ASWebAuthenticationSession is the correct solution.

For the Open button behavior you're describing, it sounds like you may be either using a Universal Link for your callback rather than a custom URL scheme or your custom URL scheme isn't matching. Using a custom URL scheme is the preferred callback method for ASWebAuthenticationSession and will provide the best user experience (e.g. no Open button). For other platforms, custom URL schemes are generally discouraged because other apps may try to claim the same URL scheme and intercept the response. However, ASWebAuthenticationSession was specifically built to solve that problem and guarantees only the calling app will receive the response (documented here).

Posted by
garrett-davidson
Up vote reply of garrett-davidson Down vote reply of garrett-davidson
Post marked as solved
Add a Comment

Replies

Yes, WKWebView supports WebAuthn as long as your app is using Associated Domains (specifically the webcredentials association) with the RPID that you're using. If you need to authenticate to third party services, ASWebAuthenticationSession is the correct solution.

For the Open button behavior you're describing, it sounds like you may be either using a Universal Link for your callback rather than a custom URL scheme or your custom URL scheme isn't matching. Using a custom URL scheme is the preferred callback method for ASWebAuthenticationSession and will provide the best user experience (e.g. no Open button). For other platforms, custom URL schemes are generally discouraged because other apps may try to claim the same URL scheme and intercept the response. However, ASWebAuthenticationSession was specifically built to solve that problem and guarantees only the calling app will receive the response (documented here).

Posted by
garrett-davidson
Up vote reply of garrett-davidson Down vote reply of garrett-davidson
Post marked as solved
Add a Comment

I also noticed that custom URL scheme and ASWebAuthenticationSession combo doesn't have this Open button issue, but was worried that this is some kind of omission/bug and it may get fixed later. After your explanation it looks like expected behavior and this helps a lot. Essentially applinks purpose is for direct app/browser integration and not meant to work with ASWebAuthenticationSession API. Thank you!

Posted by
tandre
Up vote reply of tandre Down vote reply of tandre
Add a Comment