Passkeys in In-App Browsers: The API Is There, but It Won't Work

A recent addition of passkeys to a member login page revealed a tricky bug when using LINE's in-app browser. The passkey button appeared, but tapping it did nothing, with no error or system prompt. This post explains why passkeys may not work and three key points to consider when implementing them:

1. Checking the API's existence isn't enough: In an in-app browser like LINE, the WebAuthn API exists, but a ceremony cannot run if the app doesn't allow it. To determine if passkeys will work, use the PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() API to check if the device has a platform authenticator (like Face ID or fingerprint reader) that can verify the user.

This method is widely supported. Alternatively, PublicKeyCredential.getClientCapabilities() (newer from WebAuthn Level 3) returns a set of capabilities, including userVerifyingPlatformAuthenticator, which can be checked for validity. Implement a function like canUsePasskey() that probes the API and returns true if passkeys can be used.

2. NotAllowedError doesn't mean the user cancelled: When a NotAllowedError occurs, it doesn't necessarily mean the user canceled the passkey prompt. Other reasons for the error include system prompt rejection, timeout, or lack of a usable credential. Instead of assuming the user canceled, time the call and treat any prompt rejected within a few milliseconds as passkeys don't work here. This approach helps avoid incorrect assumptions about user interaction with the passkey system.

3. The failure handling mechanism: Restricted WebViews, like LINE's, may return a promise that never resolves or rejects, causing login pages to hang during the check. To mitigate this, implement a timeout mechanism, such as the withTimeout() function provided, to prevent the page from hanging. Additionally, cache the function's result to avoid redundant checks, as login, enrollment, and passkey management all depend on a single answer.