Conversation
cscharf
left a comment
There was a problem hiding this comment.
YAY! Looks awesome and I'm stoked to get this in. Just some minor feedback, some style items and a few questions. Thanks Matt!
| { | ||
| Url = new Uri(url), | ||
| CallbackUrl = new Uri(callbackUri), | ||
| PrefersEphemeralWebBrowserSession = true |
NFC usage has long had a goldilocks zone in this space that varies between device pairs. This is a great description of the user experience issues observed in this use case. |
Support for FIDO2 WebAuthn in iOS & Android. Since iOS only supports FIDO2 via Safari, the decision was made to ditch the native API in Android and use a single code path for both platforms (using
WebAuthenticator; I'll push the native API work to a separate branch in case we ever want to revisit). This has the added benefit of not excluding our F-Droid users since the native API is part of Google Play Services, as well as being able to ship this ASAP without waiting for these changes to make it into production.Additional changes: Reworked the method of showing the progress dialog/spinner during use of
WebAuthenticatorbased on issues discovered while working on FIDO that I inadvertently avoided while working on SSO. Brought these changes to captcha as well to smooth out the flow.Also discovered the latest version of WebAuthenticator supports ephemeral webviews on iOS which has the additional side-effect of not prompting to open the view, so I applied this to both WebAuthn & captcha to smooth out the experience (left in place for SSO because of our use of cookies across sessions).
Tested with a YubiKey 5C NFC & 5Ci, which covers NFC, USB-C, and Lightning.
Notes on NFC: This process is clumsy on Android due to the speed of the handoff to the default scan handler after the FIDO2 scan is complete, combined with the way the system treats impromptu scans. If you don't physically distance the key soon enough after the FIDO2 scan the default handler scans it again and opens a web browser showing a Yubico page. You can time it with the device vibrations to get a perfect scan - a successful WebAuthn scan will result in 2 distinct vibrations. If you feel a 3rd one, you waited too long. And if you only feel 1, you pulled away too soon and the scan will fail with an error. (For the record this happens with the native FIDO2 API as well). Technically iOS does this as well but they trigger a notification instead of opening a browser, so the user doesn't have to worry about their reflexes during login.
Edit: Forgot to mention some UI work is still needed for the mobile webauthn-connector: