Despite its recent introduction and ongoing adoption by browsers, there's a noticeable gap in technical documentation and implementation advice for Conditional UI. This article aims to bridge that gap by explaining what Conditional UI is, how it works, and how to tackle common challenges during its implementation.
Conditional UI Benefits and Drawbacks Benefits Streamlined authentication: The process is more streamlined and efficient, removing the complexities often associated with multiple authentication methods.
Simple frontend integration: One of the standout features of Conditional UI is its ease of integration.
Drawbacks Learning curve for developers: Conditional UI introduces a new paradigm, which means there's a learning curve involved for developers unfamiliar with its intricacies.
No conditional passkey register: There's no support for using Conditional UI in the account/passkey creation process.
There's an ongoing discourse about the potential inclusion of Conditional UI for sign-ups as well.
As standards for Conditional UI are relatively new, we hope that things improve so that, e.g., not two autofill menus are overlaid or the desired one is not shown at all.
In general, the Conditional UI process flow can be partitioned into two phases.
During the page load phase, conditional UI logic happens in the background, while in the user operation phase, the user has to do something actively.
Conditional UI availability checks: The client calls the isConditionalMediationAvailable() function to detect if the current browser/device combination supports Conditional UI.Only if the response is true does the process continue; otherwise, the Conditional UI process is aborted.
Call the conditional UI endpoint: Next, the client calls the server Conditional UI endpoint in order to retrieve the PublicKeyCredentialRequestOptions.
Implement Conditional UI detection that ensures that Conditional UI is only employed when the current device/browser combination supports it.
If Conditional UI support is given, the Conditional UI login process can be started.
If there's no available passkey, or the user neglects the suggested passkeys and enters their email, the Conditional UI flow is stopped.
A critical point to emphasize here is the potential need to halt an ongoing Conditional UI request.
The WebAuthn standard suggests utilizing an AbortController to cancel a WebAuthn process, applicable to both regular and Conditional UI login processes (see WebAuthn's Docs for details).
The Conditional UI login process gets activated as soon as a user lands on the page.
Remember to set up a fresh AbortController each time you trigger Conditional UI. Using an already-aborted AbortController will lead to an instant cancellation of the passkey / WebAuthn function.
In the absence of Conditional UI support, direct users towards the regular passkey login process.
To illustrate how Conditional UI looks like for the end user, we added several screenshots of a Conditional UI autofill menu using https://passkeys.
This Cyber News was published on feeds.dzone.com. Publication date: Wed, 06 Dec 2023 14:13:05 +0000