# Passkeys

An overview of the passwordless capabilities of FusionAuth.

> For the index of this section of the site, see [llms.txt](https://fusionauth.io/docs/llms.txt)

Available since `1.41.0`

**Licensed Community+ plan** To use WebAuthn, you'll need [at least a Licensed Community plan](https://fusionauth.io/docs/get-started/core-concepts/plans-features.md#licensed-community-features).

Passkeys (part of a standard known as WebAuthn) provide the ability for users to authenticate in their browser using the same method they use to unlock their device, like a biometric scan or PIN. WebAuthn has some big security benefits over the traditional username and password. Read on to learn how to configure WebAuthn in your FusionAuth instance. If you'd like more detail on integrating WebAuthn with your FusionAuth instance, check out the [WebAuthn Developer Guide](https://fusionauth.io/docs/lifecycle/authenticate-users/passkeys/configure.md).

## What is WebAuthn

WebAuthn is a W3C [specification](https://www.w3.org/TR/webauthn-2/) that defines an API to create and use public-key credentials in web applications. Check out FusionAuth's [WebAuthn blog post](https://fusionauth.io/blog/what-is-webauthn-why-do-you-care.md) for more information on the basics of WebAuthn and its security benefits.

You can enable WebAuthn in your FusionAuth instance with a few configuration changes. This guide explains these configuration options and provides detail to help you choose the best options for your instance.

See the [Licensing](https://fusionauth.io/docs/get-started/core-concepts/licensing.md) guide for information about activating a license for your FusionAuth instance.

## Tenant Configuration

The bulk of WebAuthn configuration happens at the tenant level, including Relying Party settings, authenticator attachment, and user verification requirements. To configure these options, visit Tenant -> Edit -> WebAuthn .

![The tenant WebAuthn general configuration settings.](https://fusionauth.io/img/docs/screenshots/passkeys-tenant-webauthn-general.png)

The settings in this first section are applied to all applications in the tenant.

`Enabled`

This toggle must be enabled to use WebAuthn on this tenant.

`Relying party Id`

The Relying Party Id controls the scope of WebAuthn passkeys (i.e. which sites a WebAuthn passkey can be used to authenticate). More on this [below](#relying-party-id).

`Relying party name`

The Relying Party name is a human-readable name that may be displayed by the browser or operating system during a WebAuthn ceremony. The value should be something that your users will recognize such as the name of your company or service. If the field is left blank, FusionAuth will default the value to **Issuer** from the General tab during WebAuthn ceremonies.

`Enable debug logging`

Enable this toggle to create event logs with detailed information on WebAuthn failures. This can be useful for troubleshooting WebAuthn integration issues.

### Relying Party Id

The Relying Party Id controls which sites a given passkey can be used on. A passkey can only be used with the same Relying Party Id it was registered with. There are constraints on valid values based on the website where the WebAuthn ceremonies are performed. Leaving this field blank, which causes the [WebAuthn JavaScript API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API) to use the browser request origin's effective domain, should work for most use cases, but overriding the value can provide additional flexibility.

Next, we'll cover the constraints imposed on this value by the browser and then how and why you may want to override the value.

#### Constraints

As part of its security requirements, the WebAuthn specification requires that the Relying Party Id for a given ceremony is either:

*   The browser request origin's [effective domain](https://html.spec.whatwg.org/multipage/browsers.html#concept-origin-effective-domain)
*   A [registrable domain suffix](https://html.spec.whatwg.org/multipage/browsers.html#is-a-registrable-domain-suffix-of-or-is-equal-to) of the browser request origin's effective domain

It's easier to explain with an example. If your login page is at `https://auth.piedpiper.com/oauth2/authorize`, then the effective domain is `auth.piedpiper.com`. The following are valid Relying Party Ids:

*   `auth.piedpiper.com` - matches the effective domain
*   `piedpiper.com` - a registrable suffix of the effective domain

But the following values are *not* valid:

*   `m.auth.piedpiper.com` - a subdomain of the effective domain
*   `com` - this is a suffix of the effective domain but not registrable

Remember, if you are using a proxy or other means to serve up authentication pages for multiple domains, the domain the user sees in the browser is what matters, not the true hostname of the server.

#### Override

Continuing with the example from the previous section, let's say your login page is at `auth.piedpiper.com`. If **Relying party Id** is left blank, the [WebAuthn JavaScript API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API) will default to using `auth.piedpiper.com`, the browser request origin's effective domain, to scope passkeys. This means that passkeys will be registered with a Relying Party Id of `auth.piedpiper.com`, and those passkeys can only be used when the Relying Party Id is `auth.piedpiper.com` during the authentication ceremony.

The primary use case for overriding the Relying Party Id is to allow users access to their passkeys across multiple subdomains. Let's expand this scenario and assume you've got login pages on a few domains:

*   `auth.piedpiper.com` - the login domain for desktop/laptop users
*   `m.auth.piedpiper.com` - the login domain for mobile browser users
*   `login.piedpiper.com` - a legacy domain that is still in use for some portion of users

If you leave the **Relying party Id** blank, passkeys will be scoped to these exact domains. This means that a user who registers a passkey on their MacBook at `auth.piedpiper.com`, which is then synced to their other Apple devices via iCloud, would not be able to use that same passkey on their iPhone at `m.auth.piedpiper.com`. It also means that a user who registers a passkey on the legacy `login.piedpiper.com` would not be able to use that passkey on `auth.piedpiper.com` once they have been migrated to the new login domain.

There are a couple of options to override the Relying Party Id to improve the flexibility and usefulness of WebAuthn. Here are the override options available assuming all three login domains use the same FusionAuth instance and keeping in mind the constraints from the previous section:

*   `auth.piedpiper.com` - this value would allow users to share the same passkey between `auth.piedpiper.com` and `m.auth.piedpiper.com`, but it would prevent users from registering or using passkeys on the `login.piedpiper.com` legacy domain
*   `piedpiper.com` - this value functions the same as using `auth.piedpiper.com` with the added benefit that users would be allowed to register and use passkeys on `login.piedpiper.com` *and* continue using those same passkeys once they are migrated to the new `auth.piedpiper.com` domain

### Workflow settings

![The tenant WebAuthn workflow configuration settings.](https://fusionauth.io/img/docs/screenshots/passkeys-tenant-webauthn-workflow.png)

Each WebAuthn workflow has the same set of configuration options.

`Enabled`

Enabling this toggle will enable the associated workflow for all applications belonging to this tenant. The availability of a workflow can be overridden at the application level using the [Application Configuration](#application-configuration).

`Authenticator attachment`

This setting controls which authenticator attachments are allowed for registration ceremonies when using the associated workflow. See the section [below](#authenticator-attachment) for recommendations on configuring this option.

`User verification`

This setting controls whether user verification is required for registration and authentication ceremonies when using the associated workflow. See the section [below](#user-verification) for recommendations on configuring this option.

#### Authenticator attachment

There are two [authenticator attachment modalities](https://www.w3.org/TR/webauthn-2/#authenticator-attachment-modality) in WebAuthn.

*   `platform` - the authenticator is integrated with the client device
    
*   `cross-platform` - the authenticator is removable from the client device and can be used with other client devices
    
    **Enterprise plan** To use WebAuthn cross-platform authenticators, you'll need [an Enterprise plan](https://fusionauth.io/docs/get-started/core-concepts/plans-features.md#enterprise-features).
    

The workflow settings allow limiting the associated workflow to one attachment only or allowing either. The value is used to limit eligible authenticators to those that are best suited for the workflow. The authenticator attachment preference only impacts the WebAuthn registration ceremony. These are the recommended values for available WebAuthn workflows:

*   Bootstrap - `Any`. The bootstrap workflow can be used to authenticate on any supported device. The `Any` option allows signing in with WebAuthn across the broadest set of devices.
*   Re-authentication - `Platform only`. In order to ensure that the authenticator is available for repeated logins on the same device, it is best to limit authenticator selection to those integrated with the client device.

#### User verification

There are three options for the [user verification requirement](https://www.w3.org/TR/webauthn-2/#enum-userVerificationRequirement) defined by WebAuthn.

*   `Required` - user verification is required to successfully complete the WebAuthn ceremony
*   `Preferred` - user verification is preferred for the WebAuthn ceremony, but it will not fail if user verification is not provided
*   `Discouraged` - user verification should not be provided for the WebAuthn ceremony

The workflow settings allow selecting the preference for user verification. If the workflow allows a user to authenticate, it is *highly* recommended to require user verification. If user authentication is not required, anyone with access to the authenticator could use it to authenticate as the user that owns the passkey.

## Application Configuration

> **PLAN:** This feature requires [at least a Licensed Community plan](https://fusionauth.io/docs/get-started/core-concepts/plans-features.md#licensed-community-features) as of version `1.52.0`.

The application-level configuration options for WebAuthn serve as a way to override the availability of WebAuthn workflows that are configured at the tenant level.

![The application WebAuthn configuration settings.](https://fusionauth.io/img/docs/screenshots/passkeys-application-webauthn.png)

In order to override which workflows are enabled for the application, regardless of the tenant configuration, first enable the main toggle. Enabling the toggle in one of the subsections will enable that workflow for the application. Likewise, disabling the toggle in one of the subsections will disable that workflow for the application.
---

## Other pages in Authenticate Users

> For the full index of this section, see [Lifecycle](https://fusionauth.io/docs/llms-lifecycle.txt).

- [Application Authentication Tokens](https://fusionauth.io/docs/lifecycle/authenticate-users/application-authentication-tokens.md): Leverage Application specific authentication tokens to speed up certain authentication tasks.
- [Contextual Multi-Factor Authentication (MFA)](https://fusionauth.io/docs/lifecycle/authenticate-users/contextual-multi-factor.md): Learn about how FusionAuth decides to trigger multi-factor authentication (MFA) in the login flow.
- [Add a SAML v2 with ADFS IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/enterprise/adfs.md): Configure SAML v2 for Active Directory Federation Services (ADFS).
- [Add an OpenID Connect with Azure AD IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/enterprise/azure-ad-oidc.md): Set up user login using Azure AD/Microsoft Entra ID as an OpenID Connect Identity Provider.
- [Add a SAML v2 with Azure AD IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/enterprise/azure-ad-saml.md): Configure SAML v2 for Azure Active Directory (Azure AD)/Microsoft Entra ID.
- [Add a OpenID Connect with Cognito IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/enterprise/cognito.md): Set up user login using Cognito as an OpenID Connect Identity Provider.
- [Add a HYPR IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/enterprise/hypr.md): Set up user login with HYPR using the HYPR Identity Provider.
- [Add an OpenID Connect with Okta IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/enterprise/okta-oidc.md): Learn how to set up user login using Okta as an OpenID Connect Identity Provider.
- [Add a SAML v2 IdP-Initiated with Okta IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/enterprise/okta-samlv2-idp-initiated.md): Configure SAML v2 IdP-Initiated SSO With Okta.
- [Add a SAML v2 with Okta IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/enterprise/okta-samlv2.md): Configure SAML v2 for Okta.
- [Add a SAML v2 IdP-Initiated IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/enterprise/samlv2-idp-initiated.md): Set up user login using a SAML v2 IdP-Initiated Identity Provider.
- [External JWT IdP Example Usage](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/external-jwt/example.md): Learn how to federate identity using the External JWT Identity Provider.
- [Add an External JWT IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/external-jwt.md): Complete a FusionAuth login with an external JWT from a third party Identity Provider.
- [Add an OpenID Connect with Discord IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/gaming/discord.md): Learn how to set up user log in using Discord as an OpenID Connect Identity Provider.
- [Add an Epic Games IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/gaming/epic-games.md): Learn more about user login with Epic Games using the Epic Games Identity Provider.
- [Add a Nintendo IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/gaming/nintendo.md): Learn more about user login with Nintendo using the Nintendo Identity Provider.
- [Add a Sony PlayStation Network IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/gaming/sony.md): Learn more about user login with Sony PlayStation using the Sony PlayStation Identity Provider.
- [Add a Steam IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/gaming/steam.md): Learn more about user login with Steam using the Steam Identity Provider.
- [Add a Twitch IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/gaming/twitch.md): Learn more about user login with Twitch using the Twitch Identity Provider.
- [Add an Xbox IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/gaming/xbox.md): Learn more about user login with Xbox using the Xbox Identity Provider.
- [Add an Identity Provider (IdP)](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers.md): An overview of all FusionAuth Identity Providers, which allow authentication delegation.
- [Add an OpenID Connect IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/overview-oidc.md): Learn more about user login using an OpenID Connect Identity Provider.
- [Add an External SAML v2 IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/overview-samlv2.md): Learn how to set up user log in using the SAML v2 Identity Provider.
- [Add an Apple IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/social/apple.md): Learn how to add a login with Apple button to your application.
- [Add a Facebook IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/social/facebook.md): Learn how to add a login with Facebook button to your application.
- [Add a Github IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/social/github.md): Set up user login using Github as an OpenID Connect Identity Provider.
- [Add a Google IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/social/google.md): Learn how to add a login with Google button to your application.
- [Add a LinkedIn IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/social/linkedin.md): Learn how to add a login with LinkedIn button to your application.
- [Add a Twitter/X IdP](https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/social/twitter.md): Learn how to add a login with Twitter/X button to your application.
- [OIDC & CockroachDB](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/oidc/cockroachdb.md): Learn how to set up CockroachDB to allow users to log in using FusionAuth via OIDC.
- [OpenID Connect Integrations](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/oidc.md): Examples of OIDC integrations.
- [OIDC & Salesforce](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/oidc/salesforce.md): Learn how to set up Salesforce to allow users to log in using FusionAuth via OIDC.
- [OIDC & Tableau Cloud](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/oidc/tableau.md): Learn how to set up Tableau Cloud to allow users to log in using FusionAuth via OIDC.
- [SAML v2 & Aiven](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/saml/aiven.md): Setting up Aiven to allow users to log in using FusionAuth via SAML v2.
- [SAML v2 & Google](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/saml/google.md): Setting up Google to allow users to log in using FusionAuth via SAML v2.
- [SAML](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/saml.md): Examples of SAMLv2 integrations.
- [SAML v2 & PagerDuty](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/saml/pagerduty.md): Setting up PagerDuty to allow users to log in using FusionAuth via SAML v2.
- [SAML v2 & SendGrid](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/saml/sendgrid.md): Setting up SendGrid to allow users to log in using FusionAuth via SAML v2.
- [SAML v2 & Tableau Cloud](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/saml/tableau-cloud.md): Setting up Tableau Cloud to allow users to log in using FusionAuth via SAML v2.
- [SAML v2 & Zendesk](https://fusionauth.io/docs/lifecycle/authenticate-users/integrations/saml/zendesk.md): Setting up Zendesk to allow users to log in using FusionAuth via SAML v2.
- [Build a Login Page with the Login API](https://fusionauth.io/docs/lifecycle/authenticate-users/login-api.md): Learn about the Login API and when you would use it.
- [JSON Web Tokens](https://fusionauth.io/docs/lifecycle/authenticate-users/login-api/json-web-tokens.md): Learn how FusionAuth provides and manages JSON Web Tokens.
- [Logout And Session Management](https://fusionauth.io/docs/lifecycle/authenticate-users/logout-session-management.md): Learn about how FusionAuth handles logout and session management.
- [Multi-Factor Authentication (MFA)](https://fusionauth.io/docs/lifecycle/authenticate-users/multi-factor-authentication.md): Learn about how to use multi-factor authentication (MFA) in FusionAuth as a developer.
- [OAuth DPoP](https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/dpop.md): Learn how to enable sender-constrained OAuth tokens DPoP (Demonstration of Proof-of-Possession) with FusionAuth and validate DPoP proofs in your APIs.
- [OAuth](https://fusionauth.io/docs/lifecycle/authenticate-users/oauth.md): An overview of how FusionAuth provides an OAuth 2.0 and OpenID Connect SSO login system.
- [OAuth Issuer Validation](https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/issuer-validation.md): Learn how to validate the authorization response issuer parameter (RFC 9207) to prevent mix-up attacks.
- [Modes](https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/modes.md): An overview of OAuth modes and how OAuth is commonly used.
- [OIDC Prompt](https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/prompt.md): Learn about OpenID Connect prompt and example use cases.
- [OAuth Response Modes](https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/response-modes.md): Learn about OAuth 2.0 response modes (query, fragment, form_post) and when to use each one.
- [Access Control with OAuth Scopes](https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/scopes.md): Learn about OAuth scope policy configuration, managing custom scopes, and using scopes in an OAuth2 workflow.
- [Manage Software Tokens](https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/tokens.md): Learn about OAuth2 and OpenID Connect Tokens and how they are used.
- [URL Validation](https://fusionauth.io/docs/lifecycle/authenticate-users/oauth/url-validation.md): Learn about OAuth URL validation policies in FusionAuth.
- [Configure One-Time Passwords](https://fusionauth.io/docs/lifecycle/authenticate-users/one-time-passwords/configure.md): Set up a passwordless experience using magic links and codes.
- [Customize One-Time Passwords](https://fusionauth.io/docs/lifecycle/authenticate-users/one-time-passwords/customize.md): Customize the one-time password experience in your application.
- [One-Time Passwords](https://fusionauth.io/docs/lifecycle/authenticate-users/one-time-passwords.md): Create a passwordless experience using magic links and one-time passwords.
- [Configure Passkeys](https://fusionauth.io/docs/lifecycle/authenticate-users/passkeys/configure.md): Set up a passwordless experience using passkeys.
- [Customize Passkeys](https://fusionauth.io/docs/lifecycle/authenticate-users/passkeys/customize.md): Customize the passkey experience in your application.
- [Risk Signals](https://fusionauth.io/docs/lifecycle/authenticate-users/risk-signals.md): Learn about the risk signals that FusionAuth uses to identify suspicious activity and influence intelligent MFA decisionmaking.
- [Host a SAML v2 Identity Provider](https://fusionauth.io/docs/lifecycle/authenticate-users/saml.md): An overview of the SAML Identity Provider capabilities of FusionAuth.
- [Setting Up User Account Lockout](https://fusionauth.io/docs/lifecycle/authenticate-users/setting-up-user-account-lockout.md): Learn how to set up user account locking rules.
- [Implementing Single Sign-on](https://fusionauth.io/docs/lifecycle/authenticate-users/single-sign-on.md): Learn how to implement single sign-on between applications using FusionAuth.
