Passkey Intelligence, Login Identifiers & Verification

At Corbado, we've been enhancing our passkey features over the past weeks to offer developers more control and customization options. Our latest updates include multiple verification options, custom authentication flows, and enhanced passkey settings, all designed to simplify and secure user authentication.

In our blog post, “Why Passkey Implementation is 100x Harder Than You Think – Misconceptions, Pitfalls and Unknown Unknowns” which went viral on Hacker News, we have already summarized why passkeys require an intelligence layer. Simply installing a WebAuthn server or providing some backend APIs is just not enough. That’s what we have learned the hard way over the past years.

Passkey intelligence ensures that your users have a smooth user experience, and you only start passkey authentication ceremonies if you are really sure that users can use a passkey on this device – all this by applying a “Don’t’ make your users think” mantra. As there are many non-obvious things (“unknown unknowns”) to take care of, we like to compare passkey intelligence with an iceberg where only the visible parts stand for a fraction of the features and logic you need, while beneath the surface lies a complex system ensuring the stability of your passkey implementation.

The following passkey intelligence features have recently been added to our product.

One of the most crucial aspects of any passkey implementation is the ability to detect and assume if a user / device has a passkey available. Due to privacy reasons, there’s no API call that a relying party can make out-of-the-box. That’s why an own intelligence that makes use of several properties needs to be implemented to assure that passkeys are used in the right manner. We have built a system that intelligently detects devices and users and adapts to the passkey being used. What does this mean:

• We make use of LocalStorage to store information if a passkey was used on a certain device locally

• We check if used passkeys are synced in cloud accounts or third-party password managers and proactively offer these passkeys for login if we see a new device that has access to these synced passkeys is trying to log in.

• We store if a passkey is a hybrid passkey (meaning it can be used for CDA) and proactively offer hybrid passkeys to use on devices where no local passkeys are available

As the feature to login via QR code and Bluetooth has gained strong momentum in passkey implementations, we doubled down on this way of logging in and provided more intelligence here. One of our core goals was to avoid any user confusion that might be caused by non-available passkeys and unexpected QR code screens.

Besides that, we understood that different applications require a different push of CDA. Therefore, we allowed to choose between three CDA strategies that you can define in the developer panel:

• Minimize: The Minimize strategy implies that CDA is prevented. During sign-up, CDA is not offered and is also not available for logins.

• Standard: The Standard strategy is the default. This means the user can use CDA as an equally valuable login way. During sign-up, CDA is not offered but it can be used in logins.

• Maximize: The Maximize strategy tries to push CDA where possible. CDA authenticator devices (mostly smartphones) are preferred, even though local passkeys, e.g. on a Windows desktop might be available. During sign-up, CDA is the only shown option and it can be used in logins.

To be more specific, please have a look at the following table to understand the differences between the three CDA strategies:

In our initial implementation via web components, we only allowed for an email address to be used as the central user / login identifier. However, we soon realized that this is not enough, as many developers want to use usernames (the main reason is to enhance privacy – sometimes even a UUID or hash was requested) or phone numbers (which are pretty popular on mobile-first or native apps).

That’s why we came up with an entirely new concept for login identifiers.

The most user-friendly and adoption-boosting method to use passkeys is via an identifier-first approach. Identifier-first passkeys mean that the user provides the login identifier at first and submits via button-click. The login identifier is fed into the passkey intelligence and the best possible login method and applicability of passkeys is determined. This leads to highest adoption and login rates with passkeys (in contrast to a separate “Sign in with passkey” button which holds very little passkey intelligence).

The login identifier is a critical component of our user authentication system. It can be an email address, phone number, or username that uniquely identifies a user. In general, the user account is a separate entity from the login identifiers. Moreover, you can add multiple login identifiers to one user account (e.g., a phone number and email address or two phone numbers). You can define in the developer panel which of the login identifiers can be used to identify the user during the login process.

Configure your login identifiers through our developer panel, choosing from email addresses, phone numbers, or usernames based on your project’s needs.

Remember if you start with a username as the only login identifier, the account verification is an issue, as no email magic link / OTP or SMS OTP can be sent. Therefore, we recommend to only use the username in conjunction with an email address or phone number if you want to reduce the manual recovery processes that might follow if users have no self-recovery option via email address or phone number.

Before, we only used email magic links for account verification. The account verification was done on the first login, as we let users pass initially after they created account in order to increase the conversion rate.

Many developers approached us and came up with their own ideas for the account verification – be it for the process (verification strategy) or for the method (verification method). That’s why we extended our support for account verification strategies and account verification methods by allowing developers to configure that according to their needs.

We have introduced three different verification strategies that you can select in the developer panel:

• None: The account does not need to be verified. We recommend using this strategy only if you know the impacts. One thing to consider is that basically anyone can claim an account and that typos in the initial provisioning of a login identifier cannot be changed later.

• At sign-up: This is the safest strategy as the account must be verified when it is created. This means that only verified accounts are authenticated and forwarded to the logged-in part of an app / website.

• Before first login: This strategy lets users create an account and directly forwards them to the logged-in part of an app or website. For subsequent logins, however, the account needs to be verified. The big benefit is that the conversion rate is initially higher than with the “At sign-up” verification strategy. On the other hand, accounts with typos in the login identifier can initially proceed to the logged-in part of an app / website.

Before the introduction of the UI components, we only supported email magic links as account verification option. As these have their drawbacks (see below) and phone numbers became increasingly requested, we started to offer also OTPs via email or SMS to be used:

• Email Verification: Use either email magic links or one-time passcodes (OTPs) for verifying email addresses.

• Phone Number Verification: Send OTPs via SMS to verify phone numbers.

Regarding email magic links, there are several issues involved when you work solely with email magic links, such as:

• Users have multiple devices: We live in a world where users have multiple devices and may request an email magic link on their smartphone but only have their mailbox set up on their desktop. What do you do now? Do you log in the tab where the email magic link was requested or only the tab where the user is being forwarded to after the magic link was clicked or both? Depending on your preference, this can lead to user confusion and potential security issues.

• Security issues: Imagine you’re using email magic links for account verification. In a scenario where the tab that triggered the email magic link flow is also logged in after the user has clicked on the link in the email, this could lead to the following scenario: a potential attacker could trigger an email magic link multiple times and try to convince (e.g. via social engineering) the user to click on the email magic link (or the user does so by accident). As the originating tab will also be logged in, this would give the attacker access to the account (if it is not protected via IP pinning or equivalent measures).

That’s why we recommend using OTPs instead of email magic links (OTPs also being the default for new projects).

We understand that not every user base is like the other. That also applies to the preference of opting in and using passkeys. Therefore, we provide more granular ways to ask users if they want to upgrade to passkeys or create local passkeys after cross-device authentication (configurable in the developer panel):

Customize how often users are prompted to use their passkey for authentication after a login with an alternative method, balancing security and user convenience.

Enable users to create passkeys automatically without an additional passkey benefit explainer screen. Our data analysis has shown that this can lead to higher conversion rates and higher passkey adoption rates. However, some users might be confused without the additional explainer screen what is happening (this behavior can initially also be desired, e.g. Amazon also automatically starts the passkey creation on passkey-ready devices if the user has successfully authenticated with another login method).

At Corbado, we are committed to providing developers and product managers with the tools they need to implement secure, user-friendly authentication methods. Our latest features – ranging from enhanced passkey settings to multiple verification options – ensure that you can offer your users a seamless and secure login experience. Start optimizing your passkey flow with our low-code solutions today.