WebAuthn Resident Key: Discoverable Credentials as Passkeys

1. Introduction

2. The WebAuthn Ecosystem

3. Dive into Passkeys

4. What are Resident Keys and Non-Resident Keys?

    4.1 Resident Keys (RKs)

    4.2 Non-Resident Keys (NRKs)

    4.3 Example

5. Conditional UI ("Passkey Autofill")

6. Client to Authenticator Protocol (CTAP)

    6.1 CTAP1 (U2F)

    6.2 CTAP2

    6.3 CTAP 2.1

7. WebAuthn Server Options

    7.1 WebAuthn Server Option Authenticator Attachment

    7.2 WebAuthn Server Option Resident Key

    7.3 WebAuthn Server Option User Verification

    7.4 Common Patterns of WebAuthn Server Options

      7.4.1 Passwordless Login with Passkeys via Face ID / Touch ID

      7.4.1 Passwordless Login with Security Keys (e.g. YubiKeys)

8. Potential Challenges and Solutions

    8.1 Challenge 1: Storage Limitations of Security Keys (e.g. YubiKeys)

    8.2 Challenge 2: Inconsistent Behavior Across Authenticators

    8.3 Challenge 3: User Experience Concerns

9. Best Practices for Developers and Product Managers

10. Recommendation

11. Conclusion

1. Introduction

Passkeys and the underlying WebAuthn protocol are revolutionizing the authentication landscape. However, setting up a WebAuthn server the proper way can be a tricky endeavor. Misconfigurations can not only introduce vulnerabilities but also break existing passkeys if you need to change them later. The following blog post should help you better understand the often complex WebAuthn specifications and give you the advice what settings are best for your use case.

2. The WebAuthn Ecosystem

WebAuthn operates with three primary entities:

• Relying Party (RP): This is your web service that wishes to authenticate a user. It sends challenges to the client, verifies responses and manages the public key of a passkey.
• Authenticators: These are devices that can prove possession of a credential. Examples include smartphones, laptops, or security keys (e.g. YubiKeys). Authenticators can be platform-specific (like Windows Hello or Apple's Touch ID / Face ID) or cross-platform (like security keys, e.g. YubiKeys).
• Clients: Typically, these are web browsers or native apps that act as the intermediary between the RP and the authenticator. They facilitate the communication, ensuring that the data flows correctly and securely.

Want to try passkeys yourself? Check our Passkeys Demo.

Try Passkeys

In the following, the high-level data flow during an authentication process (either login or sign-up) is described.

1. Client Initiation: The process begins on the client side, usually when a user attempts to log in or sign up. For instance, they might click a "Login with WebAuthn" button and the client sends a request for a challenge to the RP.
2. RP Request: The RP then sends a challenge back to the client. This challenge is a randomly generated value that ensures the authenticity of the subsequent response.
3. Client to Authenticator: During sign-up, the client requests the authenticator to create a new passkey by creating the corresponding public-private key pair. During login, the client requests the authenticator to sign the challenge. This is done using the private key on the authenticator, which corresponds to a previously registered public key stored on the RP.
4. Authenticator Response : During sign-up, the authenticator sends back the public key to the client. During login, the authenticator signs the challenge and sends this signed assertion back to the client.
5. Client to RP: The client forwards this new public key / the signed assertion to the RP.
6. RP Verification: The RP stores the public key / verifies the signed assertion using the stored public key. If it's valid, the authentication is successful.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

3. Dive into Passkeys

The above described high-level process flow describes WebAuthn sign-up and login processes. Passkeys are built on top of WebAuthn. Originally, the term passkeys was used as a more memorable and non-technical term than WebAuthn describing the same thing. Moreover, passkeys provide more features compared to standard WebAuthn, e.g. the possibility to sync passkeys via cloud accounts or password managers.

To better understand the following sections, we define some important terms in the WebAuthn protocol to have a common understanding.

• Credential ID: The Credential ID is a unique identifier assigned to a specific public key credential generated by an authenticator. It allows Relying Parties (RPs) to identify and select the correct PublicKeyCredential for authentication processes.
• PublicKeyCredential: This is the primary data structure returned from the browser's or native apps WebAuthn API. It encompasses both the Attestation data during sign-up and the Assertion data during login. Essentially, it contains the data that the RP needs to verify the process.
• Attestation: Attestation in the WebAuthn context serves as a proof of the authenticator's origin and its integrity. During sign-up, it's a way for the authenticator to say, "I've securely registered the user's credential, and here's a statement you can use to verify that". The Relying Party can then verify that the signature comes from a specific authenticator that is allowed (e.g. Yubikey). Not all passkey authenticators reply with such an attestation, some just dont send useful data back (see here the list of passkeys authenticators). Further AAGUIDs (Authenticator Attestation GUIDs) which identify more authenticators (mainly security keys, e.g. YubiKeys) can be found in the FIDO Alliance Metadata Service.
• Assertion: After the sign-up process, when a user tries to log in, the authenticator produces an assertion. The assertion is basically the PublicKeyCredential + the signed challenge. This assertion proves that the user possesses the private key linked to the registered public key without revealing the actual private key. It's the authenticator's way of saying, "This is the genuine user, and I can vouch for them."

Subscribe to our Passkeys Substack for the latest news, insights and strategies.

Subscribe

4. What are Resident Keys and Non- Resident Keys?

Resident keys (RKs) and non-resident keys (NRKs) are two types of cryptographic keys used in the WebAuthn protocol, and they differ primarily in their storage location and retrieval mechanism.

4.1 Resident Keys (RKs)

Definition:

Resident keys are stored directly on the authenticator itself. This could be a security key (e.g., YubiKey), a platform's secure enclave (e.g., iPhone's Secure Enclave), or a trusted platform module (TPM) on a laptop. Conditional UI (passkey autofill) only works for resident keys and the WebAuthn working group currently requires resident keys to be considered as a passkey.

In the following screenshot, you see a list of all resident keys (credential ID, rpID, username, display name) that are stored on a YubiKey. Non-resident keys are not in the list, as they are not stored on the authenticator:

Login flow:

Source: William Brown

During the login process, the Relying Party sends a request without specifying credentials to the client (browser) which starts to query the authenticator (here in the chart: security key). The authenticator discovers all resident keys for the corresponding Relying Party and the client (browser) selects the desired resident key. This resident key is used to sign the challenge. The signature is sent from the authenticator via the client to the Relying Party.

Advantages:

1. Streamlined User Experience: One of the most significant advantages of resident keys is that the authenticator stores the user handle (e.g. email, phone number, username) and thus can prefill the user handle (e.g. email, phone number, username) for login. Users do not need to remember or input user handles (e.g. email, phone number, username), streamlining the login process, especially on devices with biometric capabilities. This can happen also automatically with Conditional UI.
2. Device-Specific Authentication: Resident keys can provide an additional layer of security by tying authentication to a specific device. This can be particularly useful for services that want to ensure users are logging in from trusted devices.
3. Conditional UI (Passkey Autofill): Conditional UI only works with resident keys providing the most seamless login experience (see below for details).

Disadvantages:

1. Storage Limitation: Some authenticators have a finite storage capacity. Especially for security keys (e.g. YubiKeys), theres often a limit to the number of resident keys they can store (most have a limit ranging from 8 to ~100 resident keys). Once this limit is reached, older keys might need to be deleted to make space for new ones, or the user might need to use another authenticator.
2. Loss of Authenticator: If the authenticator, e.g., a security key (e.g. YubiKey) or smartphone, is lost or damaged, all resident keys on that device are lost. This could lock users out of multiple services until they re-register or recover their accounts. Syncing keys via a cloud account (e.g. iCloud Keychain, Google Password Manager) or a modern password manager (e.g. 1Password or Dashlane) prevents this loss.
3. Security Concerns: If an authenticator with resident keys is stolen, an attacker might attempt to extract the keys. While modern authenticators have robust security mechanisms to prevent extraction, e.g. the user protects the device with a strong PIN, passcode or gesture, the risk, albeit minimal, still exists.

Use Cases: Ideal for devices where the user frequently authenticates, like personal smartphones or laptops.

Want to find out how many people can use passkeys?

View Adoption Data

4.2 Non-Resident Keys (NRKs)

Definition:

Non-resident keys, in contrast, are not stored on the authenticator. Instead, the authenticator generates a new key pair (based on its internally protected master key) and sends the public key of this new key pair to the server (Relying Party) together with the credential ID (that contains a seed) during sign-up. The server then associates this public key with the users account. For subsequent authentications, the authenticator re-derives the private key by receiving the credential ID, extracting the seed and combining it with the master key. Because the key is only temporarily available in the protected memory of the authenticator It is sometimes called ephemeral key in cryptographic language.

Login flow:

Source: William Brown

During the login process, the Relying Party must first identify which user is requesting authentication (e.g. by asking for a user handle, e.g. email, phone number or username) and then sends the credential IDs that it is aware of for the requesting user to the client (browser). The client forwards them to the authenticator (here: security key). The authenticator uses the credential ID together with the authenticator's master key to derive the temporary private key, signs the challenge with the generated key and returns it to the client (here: browser), which forwards it to the Relying Party. Non-resident keys were originally used as second factor before the introduction of passkeys. Therefore, identifying the user first was part of the regular login process.

Advantages:

1. Scalability: Since non-resident keys dont reside on the authenticator, users can have an almost unlimited number of non-resident keys associated with various services. This is particularly beneficial for users who have accounts across numerous platforms.
2. Roaming Capability: Non-resident keys are ideal for roaming authenticators like security keys (e.g. YubiKey). A user can use the same security key (e.g. YubiKey) to authenticate across multiple devices and platforms, providing a consistent experience.
3. Reduced Dependency on Authenticator Storage: For suitable WebAuthn server settings, theres no need to worry about the storage limitations of the authenticator. This can be particularly advantageous for low-storage authenticators, like security keys (e.g. YubiKeys).

Disadvantages:

1. Less UX as User Handle is Required: The biggest downside of non-resident keys is that the user handle (e.g. email, phone number, username) needs to be provided by the user which makes a username prefill via Conditional UI impossible. This user handle needs to be tied to the credential ID which is needed to calculate the ephermal key-wrapped key.
2. Potential for Mismanagement: RPs need to manage and secure the associations between user accounts and public keys. Poor management or vulnerabilities could lead to security issues.

Use Cases: Ideal for roaming authenticators like security keys (e.g. YubiKeys) that are used across multiple services or platforms.

4.3 Example

Imagine you have a security key (e.g. YubiKey), and you register it with two online services: Service A and Service B. For Service A, you use a resident key. For Service B, a non-resident key. When you authenticate to Service A, you simply tap your security key (e.g. YubiKey), and youre in - no need to specify a username. For Service B, youd first provide your username in the browser / native app. The service then sends the associated credential ID to your security key (e.g. YubiKey), which then re-generates the ephemeral private key for authentication.

In essence, while both resident and non-resident keys enhance security by leveraging cryptographic authentication, their user experiences and storage mechanisms differ, catering to varied use cases.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

5. Conditional UI ("Passkey Autofill")

Conditional UI is a milestone feature of passkeys / WebAuthn. It takes even more burden from the user, as the user not only does not need to remember a password, but also does not need to remember the user handle (e.g. email, phone number, username) with which he signed-up to a Relying Party. Especially, in cases where Relying Parties' services are only occasionally used this is a huge step.

This works because as soon as the login page is opened, the Relying Party server sends a challenge in the background to the client (remember theres no credential ID required to be sent in this call). The client takes this challenge and checks which passkeys match the Relying Party ID on this authenticator and offers the selection via the autofill menu, where the user can select the appropriate passkey.

Moreover, it also saves the user from an extra click on the login button, because as soon as the passkey is selected from the autofill menu, the login process starts.

6. Client to Authenticator Protocol (CTAP)

CTAP is a foundational protocol in the FIDO2 standard, bridging the communication gap between clients (like browsers) and authenticators (like security keys, e.g. YubiKeys, or smartphones). To better understand CTAP, lets have a first brief view at the different protocol versions before analyzing the impact on resident and non-resident keys.

6.1 CTAP1 (U2F)

The earlier version, often referred to as Universal 2nd Factor (U2F), was primarily designed for second-factor authentication. In U2F, the server provides a challenge, and the authenticator provides a response, proving possession of the private key. However, U2F doesnt support resident keys, meaning it always requires a server-side lookup to identify which key to use for a user, as this was part of the process when asking for a second factor.

6.2 CTAP2

The successor to U2F, CTAP2 introduced support for resident keys, allowing for passwordless and username-less authentication. With resident keys, the authenticator stores the users username and credential ID (together with the Relying Party ID), eliminating the need for the Relying Party server to supply it during authentication. This is a significant leap towards a more seamless UX.

However, CTAP2 comes with challenges. One notable issue is the management of resident keys. For instance, deleting a specific resident key in a CTAP2.0 device often requires a complete device reset (so also your master key is reset, meaning all your non-resident keys will no longer work either), which is not user-friendly and can be problematic in scenarios where multiple resident keys are stored on a single device. This makes resident keys on a CTAP2.0 device a serious commitment. You really dont want to accidentally fill up that limited space you often have, especially on security keys (e.g. YubiKeys).

6.3 CTAP2.1

CTAP2.1 is a subsequent version of CTAP2, bringing additional features and improvements to the protocol. Some key points about CTAP 2.1 include:

• Better Resident Key Management: CTAP 2.1 allows to individually manage, update and delete specific resident keys from your device.
• Enterprise Attestation: This feature allows enterprises to have more control over the keys used by their employees. It provides a way for enterprises to verify that the keys being used are company-issued.
• Multiple User Recognitions: Some authenticators can recognize multiple users. CTAP 2.1 provides a way for these authenticators to indicate which user has been recognized.
• Backward Compatibility: CTAP 2.1 is designed to be backward compatible with CTAP2, ensuring that devices and platforms that support the older version can still work with the new one.

7. WebAuthn Server Options

After having had a look at resident keys, non-resident keys and the different CTAP versions, we now analyze the Relying Party side and thus the WebAuthn server side in more depth.

WebAuthns flexibility (but also its complexity) are largely attributed to its server settings, particularly within the authenticatorSelection object. This object guides the client in selecting the right authenticator for the job.

{
  "rp": {
    "name": "corbado.com",
    "id": "corbado.com"
  },
  "user": {
    "id": "dGVzdefEyMjE",
    "name": "test-username",
    "displayName": "test-username"
  },
  "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
  "pubKeyCredParams": [
    {
      "type": "public-key",
      "alg": -7
    },
    {
      "type": "public-key",
      "alg": -257
    }
  ],
  "timeout": 60000,
  "excludeCredentials": [],
  "authenticatorSelection": {
    "authenticatorAttachment": "platform",
    "residentKey": "preferred",
    "requireResidentKey": false,
    "userVerification": "preferred"
  },
  "attestation": "none",
  "extensions": {
    "credProps": true
  }
}

7.1 WebAuthn Server Option Authenticator Attachment

This server option specifies how the authenticator is attached to the client device. It provides insights into how the authenticator communicates with the client:

Possible Values

• Platform : This indicates that the authenticator is attached to the client's platform and is therefore not removable.
• Cross-platform: This indicates that the authenticator is not bound to the client's platform and can be used on multiple devices.

Use Cases & Examples

• Platform: Examples include a fingerprint scanner that's built into a laptop or a facial recognition system on a phone, e.g. Face ID, Touch ID or Windows Hello.
• Cross-platform: Examples include USB security keys (e.g. YubiKeys), Bluetooth devices, or NFC cards.

7.2 WebAuthn Server Option Resident Key

In the WebAuthn Level 1 specification, this server option was called requireResidentKey and could hold the Boolean values true (the authenticator must create a resident key) or false (the authenticator must create a non-resident key). WebAuthn Level 2 replaced this server option with the new server option residentKey:

Possible Values

• Required: The authenticator must create a resident key (if not possible the operation should fail).
• Preferred: The authenticator should try to create a resident key (if not possible it should create a non-resident key)
• Discouraged: The authenticator must create a non-resident key (if not possible the operation should fail).

Use Cases & Examples

• Required: Ideal for scenarios where username-less is wanted or where users should only authenticate from previously registered devices (by adding an extra security layer by binding the users credential to a specific device).
• Preferred: Suitable for scenarios where the web service wants to provide the best login UX if possible (via resident keys), but still wants to support non-resident keys if resident keys are not possible.
• Discouraged: A service wants to offer passkey authentication and also wants to ensure that users can use any authenticator, even those without storage capabilities, without binding the credential to a specific device.

7.3 WebAuthn Server Option User Verification

User verification refers to the process that ensures the person interacting with the authenticator is the legitimate owner, typically by requiring a specific authentication gesture like entering a PIN, providing a fingerprint, or using facial recognition.

Sometimes user presence (UP) is also mentioned or used similar to user verification but has some differences indeed. User presence only confirms that someone anyone is physically present and interacting with the device. It doesnt verify the identity of that person. A simple touch of a security key, without any further identity checks, can suffice for user presence. For passkeys / WebAuthn, the user always needs to be present.

Possible Values

• Required: The operation must have user verification.
• Preferred: The operation should have user verification if possible, but can proceed without it.
• Discouraged: The operation should not have user verification.

Use Cases & Examples

• Required: Ideal for high-security applications like banking or healthcare, where verifying the users identity (e.g., through a fingerprint or PIN) is crucial.
• Preferred: Useful for general applications where added security is a bonus but not strictly necessary.
• Discouraged: Suitable for low-risk operations or scenarios where user verification might be an inconvenience.

7.4 Commont Patterns of WebAuthn Server Options

7.4.1 Passwordless Login with Passkeys via Face ID / Touch ID

Pattern

• Authenticator attachment: platform
• Resident key: required
• User verification: required

Example: A corporate application wants employees to log in without passwords on their company-issued laptops using built-in fingerprint readers. The credential is stored on the device, and the user must verify with a fingerprint each time.

7.4.2 Passwordless Login with Security Keys (e.g. YubiKeys)

Pattern

• Authenticator attachment: cross-platform
• Resident key: required
• User verification: required

Example: A user registers a security key (e.g. YubiKey) for their online banking. They can use this key to authenticate on any device by providing the security key (e.g. YubiKey), without needing to enter a username.

8. Potential Challenges and Solutions

8.1 Challenge 1: Storage Limitations of Security Keys (e.g. YubiKeys)

Many hardware-based security keys (e.g. YubiKeys) have inherent storage constraints. This limitation is due to the physical memory available on the device and the design considerations of the manufacturer.

Example: A YubiKey might have the capacity to store only 20 resident keys. Once this limit is reached, no additional resident keys can be added without deleting existing ones.

Solution:

• Selective Use of Resident Keys: Instead of using resident keys for every user, consider them for specific roles or scenarios. For instance, prioritize resident keys for admin roles or high-privilege users who require enhanced security.
• User Education: Inform users about the limitations of their security keys (e.g. YubiKeys). Encourage them to switch to devices that can use unlimited resident keys, e.g. laptops or smartphones.

8.2 Challenge 2: Inconsistent Behavior Across Authenticators

Different authenticators might handle resident key requests differently. Some might default to creating a resident key even if its not explicitly requested, while others might require explicit instruction.

The inconsistent behavior for different WebAuthn server options on different platform is a major problem. For instance, iOS will always create a resident key regardless of the WebAuthn server options passed to, while Android requires an opt-in (e.g. with residentKey: preferred or residentKey: required).

Besides the behavior, its even worse that based on the server-side stored data, you cannot say with 100% certainty if a stored credential is a resident key or non-resident key. Instead, you can follow some checks and narrow it down (see below), but still need to hope that the credentials behavior is according to your belief.

The reason behind is that theres a WebAuthn suggestion to store information about the kind of credential (resident key or non-resident key) in the credential properties extension (clientExtensionResults.credProps.rk which is either true or false). However, providing this information to the RP is not guaranteed as all WebAuthn extensions are optional, e.g. iOS doesnt send it (so you dont know if its a resident key or non-resident key).

During our research, we tried to test the behavior on different platforms and authenticators (Windows 10, Windows 11, Android 7, Android 13, iOS17, macOS Ventura, YubiKey) with two WebAuthn demo pages that provide more details on the created credentials: https://webauthn.io and https://webauthntest.identitystandards.io/. The latter offers the possibility to work with the legacy requireResidentKey property (WebAuthn Level 1) and even combine it with residentKey property (WebAuthn Level 2). However, the results were not reliable (e.g. it stated non-resident key for iOS but clearly conditional UI worked).

The most trustworthy checking scheme we found is the following:

1. Check what your WebAuthn server settings for the attribute "residentKey" are
   1. If "residentKey: required" and a credential is successfully created -> it’s a resident key
   2. If "residentKey: preferred" or "residentKey: discouraged", then move on to next check
2. Is the extension credProps.rk supported and stored in the credential on the server?
   1. If credProps.rk = true, the credential is a resident key
   2. If credProps.rk = false, the credential is a non-resident key
   3. If credProps is empty, then the type of credential is unknown

As you can see, this helps to narrow it down, still the unknown option resides and you cannot determine the type of key with 100% certainty.

This is also in line with the findings of William Brown from SUSE in his great article outlining how security keys (e.g. YubiKeys) could be useless if resident keys are required by Relying Parties (we extended his table):

In the table, you see for different WebAuthn server resident key options if a resident key was created (true), if a non-resident key was created (false) or something else happened.

Solution:

• Thorough Testing: Before deploying, test your WebAuthn implementation across a range of popular authenticators to understand their behavior.
• Explicit Server Settings: When setting up your WebAuthn server, be explicit in your requirements. If you want to only have passkeys, then set the residentKey option to required (note: that this might lead to other challenges with authenticators with limited resident key capacity, see above).

8.3 Challenge 3: User Experience Concerns

If a user reaches the storage limit on their security key (e.g. YubiKey), they might face errors or be unable to register new credentials. This can lead to confusion and frustration.

Solution:

• Graceful Error Handling: Implement clear error messages that inform the user when their security key (e.g. YubiKey) is full and provide guidance on how to resolve the issue.
• Guided Workflows: Offer step-by-step guides or tutorials on how users can manage their resident keys, ensuring they can resolve issues independently.

9. Best Practices for Developers and Product Managers

As youve seen above, the WebAuthn server settings you choose can significantly impact the user experience and security of your authentication process. It's essential to understand the nuances of these settings to make informed decisions.

Resident vs. Non-resident Keys: If a majority of your users primarily access your service from personal devices like smartphones or laptops, resident keys are a suitable choice. Resident keys are stored on the device itself and offer a seamless authentication experience for users who frequently use the same device. However, for users who use security keys (e.g. YubiKeys), which are non-resident keys, might be more appropriate.

User Verification (UV) Settings: Depending on the level of security you want to achieve, you can decide how stringent the user verification process should be. If you're aiming for high security, requiring a PIN, fingerprint, or facial recognition (userVerification: preferred or userVerification: required) is advisable.

Attestation and Trustworthiness: Attestation allows you to verify the origin and integrity of the authenticator. Decide if you want to trust all authenticators or only those from specific manufacturers. This can be crucial if you're dealing with sensitive data and want to ensure that only high-quality, trusted authenticators are used.

Fallback Mechanisms: Always have a fallback mechanism in place. If a user loses their authenticator or if it malfunctions, they should have an alternative way to access their account. This could be through backup codes, SMS verification, email magic links or other multi-factor authentication methods.

Continuous Education: The landscape of passkeys and WebAuthn is continuously evolving. Stay updated with the latest developments, vulnerabilities, and patches. Encourage your development team to participate in workshops, webinars, and conferences related to passkeys and WebAuthn.

User Onboarding and Education: When introducing passkey authentication, ensure that your users understand its benefits and how it works. Offer clear instructions during the sign-up process and provide resources (like FAQs or video tutorials) to assist users in setting up and using passkeys.

By adhering to these best practices, developers and product managers can ensure that they implement passkey authentication effectively, balancing both security and user experience.

10. Recommendation

If you want to implement passkeys for mainstream adoption in your website or app and dont need to support security keys (e.g. YubiKeys), as most of your users will just use their smartphone or laptop, we recommend the following settings.

• authenticator: platform
• residentKey: required
• userVerification: required

Benefits:

• As all created keys are resident keys, the setup allows for Conditional UI making your login even more seamless for your users as they do not have to remember a username.
• All modern devices from Apple, Google and Microsoft are supported and use passkeys.

11. Conclusion

WebAuthn's server settings, while being complex, offer a robust and flexible framework for authentication. Mastering these settings is crucial, as it's not just about implementing a new standard; it's about fundamentally improving the security and efficiency of user authentication.

In essence, understanding WebAuthn's server settings is an investment in building more secure, efficient, and forward-looking applications. As the digital landscape evolves, being well-versed in such technologies will be indispensable. To stay updated, join our passkeys community or subscribe to our newsletter below.