> For the complete documentation index, see [llms.txt](/docs/llms.txt)

# Applications | FusionAuth Docs

An overview of FusionAuth Applications.

# Applications

A FusionAuth Application holds configuration for how an application (e.g. a website, mobile app, or both) interacts with FusionAuth. Multiple web and mobile applications can share a single FusionAuth Application.

Here's a brief video covering some aspects of applications:

[Play](https://youtube.com/watch?v=DaZbwrA7M90)

## Ids[#](#ids)

FusionAuth Applications have both an **applicationId** and a **client\_id**, but both use the same `Id` value. You'll provide these values for Login API requests or authorization grants to specify the application that the user would like to access.

## Core Concepts Relationships[#](#core-concepts-relationships)

Below is a visual reminder of the relationships between FusionAuth's primary core concepts.

![Diagram showing Applications used within FusionAuth](/img/docs/get-started/core-concepts/core-concepts-relationships-applications.png)

## Admin UI[#](#admin-ui)

This page describes the admin UI for creating and configuring an Application.

### Add an Application[#](#add-an-application)

Before you start your integration with FusionAuth you need to set up at least one Application. Click on Applications from the left navigation to begin.

1.  Click the Applications menu option on the left side of the page.
    
    ![Dashboard to Applications](/img/docs/extend/examples/5-minute-intro/dashboard-applications.png)
    
2.  Click the **Add** button at the top of the page:
    
    ![Application Listing](/img/docs/extend/examples/5-minute-intro/application-listing.png)
    
3.  On the Add Application form, provide a name for your Application (this is only used for display purposes).
    
4.  Select a Tenant for your Application.
    
5.  In the **OAuth** tab, configure a login method. Generally, you should at least configure **Authorized redirect URLs** and a **Logout URL** with the values provided by your IdP.
    
6.  Click the **Save** button at the top of the page.
    

#### Form Fields[#](#form-fields)

`Id`optional

An optional UUID. When this value is omitted a unique Id will be generated automatically. This will also be used as the **Client Id** in the OAuth configuration, so if you require a specific value for that, set it here. Application Ids are unique across all tenants.

`Name`required

The name of the Application. This value is for display purposes only and can be changed at any time.

`Universal`required

When enabled, the created application will be a [universal application](#universal-applications). A regular application is assigned to a single tenant, while a universal application exists in all tenants.

This setting cannot be changed after the application has been created.

`Tenant`required

The tenant in which to create this Application.

`Theme`optionalAvailable since 1.27.0

When a theme is selected, it will be used for this application instead of the tenant theme.

**Note:** To use application themes, you'll need a paid plan.

### Roles[#](#roles)

The Roles tab will only be available on the Add Application form. To manage roles after the Application has been created you will use the Manage Roles action.

#### Table Columns[#](#table-columns)

`Name`required

The name of the role. This value should be short and descriptive. Roles can only be created and deleted, only the role description may be modified.

`Default`optional

One or more roles may be marked as default. A default role will be automatically added to new user registrations when no roles are explicitly provided on the API request.

`Super Role`optional

A role may be optionally marked as a super user role. This indicator is just a marker to indicate to you that this role encompasses all other roles. It has no effect on the usage of the role.

`Description`optional

An optional description to better describe the intended use of this role.

To manage Application Roles after you have added an Application, click the Manage Roles button on the index page. To edit an Application click the edit icon. The following sections will walk you through each panel for the edit action.

![Applications](/img/docs/get-started/core-concepts/applications.png)

### OAuth[#](#oauth)

The OAuth tab allows you to configure the OAuth2 and OpenID Connect settings specific to this Application.

![Application OAuth configuration](/img/docs/get-started/core-concepts/application-oauth.png)

#### Form Fields[#](#form-fields-1)

`Client Id`Read only

The unique client identifier as defined by [RFC 6749 Section 2.2](https://tools.ietf.org/html/rfc6749#section-2.2). This value is read only and is equal to the unique Id of the Application.

`Client secret`Read only

The client secret as defined by [RFC 6749 Section 2.3.1](https://tools.ietf.org/html/rfc6749#section-2.3.1). When **Client Authentication** is `Required`, this client secret will be required to obtain an access token from the Token endpoint.

This value may be regenerated if you think it has been compromised by clicking the regenerate button. If this Application is configured to require client authentication, regenerating the client secret will cause all clients to fail, and they will not be able to complete the OAuth login process. If this Application is not configured to require client authentication, regenerating this secret will not have any effect.

`Client Authentication`optionalAvailable since 1.28.0

This selector allows you to set a rule for accessing the [Token endpoint](/docs/apis/oauth/token).

The possible values are:

*   `Required` - The `client_secret` parameter must be used. This is the default setting. In most cases you will not want to change this setting.
*   `Not required` - Use of the `client_secret` parameter is optional.
*   `Not required when using PKCE` - Requires the use of the `client_secret` parameter unless a valid PKCE [code_verifier](https://datatracker.ietf.org/doc/html/rfc7636#section-4.1) parameter is used. This is useful for scenarios where you have a requirement to make a request to the Token endpoint where you cannot safely secure a client secret such as native mobile applications and single page applications (SPAs) running in a browser. In these scenarios it is recommended you use PKCE.

See the [Token endpoint](/docs/apis/oauth/token) for more information.

`PKCE`optionalAvailable since 1.28.0

This selector allows you to set a rule for [Proof Key for Code Exchange](https://datatracker.ietf.org/doc/html/rfc7636) (or PKCE) requirements when using the authorization code grant.

The possible values are:

*   `Required` - The `code_verifier` parameter must be used. If you want to require PKCE for this application, set **PKCE** to this value.
*   `Not required` - Use of the `code_verifier` parameter is optional. This is the default setting.
*   `Not required when using client authentication` - Requires the use of the `code_verifier` parameter unless a valid `client_secret` parameter is used.

`Generate refresh tokens`Available since 1.3.0

When enabled, FusionAuth will return a refresh token when the `offline_access` scope has been requested. When this setting is disabled refresh tokens will not be generated even if the `offline_access` scope is requested.

In order to use the Refresh Token with the Refresh Grant to refresh a token, you must ensure that the `Refresh Token` grant is enabled. See the **Enabled grants** field.

`Enable debug logging`optionalAvailable since 1.25.0

Enable debug to create an event log to assist you in debugging integration errors.

`URL validation`optionalAvailable since 1.43.0

Controls the validation policy for **Authorized redirect URLs** and **Authorized request origin URLs**.

The possible values are:

*   `Exact match` - Only the configured values that do not contain wildcards are considered for validation. Values during OAuth 2.0 workflows must match a configured value exactly.
*   `Allow wildcards` - Configured values with and without wildcards are considered for validation. Values during OAuth 2.0 workflows can be matched against wildcard patterns or exactly match a configured value.

`Authorized redirect URLs`optional

When OAuth grants, such as the authorization code grant, require a browser redirect to a URL found in the `redirect_uri` parameter, the destination URLs must be added to this list. URLs that are not authorized may not be utilized in the `redirect_uri` parameter or the `post_logout_redirect_uri` parameter.

You can add as many URLs as you'd like to this list. Prior to version `1.43.0` only exact string matches with the provided `redirect_uri` will be allowed. No partial or wildcard matches will be accepted.

Configured URLs containing wildcards are considered during validation when **Authorized redirect URLs** is set to `Allow wildcards`. Wildcards are allowed in the following positions:

*   The left-most subdomain - A full or partial wildcard is allowed in the left-most subdomain. The replacement value cannot contain a `.`.
*   The port number - A wildcard is allowed in place of the port number. Partial wildcards are not allowed in this position.
*   A path segment - A full or partial wildcard is allowed in any path segment. The replacement value cannot contain a `/`.
*   A query string value - A wildcard is allowed in place of a query string value. Partial wildcards are not allowed in this position. Wildcards are not allowed in query string names.

See the OAuth 2.0 [URL Validation](/docs/lifecycle/authenticate-users/oauth/url-validation) page for more detail.

`Authorized request origin URLs`optional

This optional configuration allows you to restrict the origin of an OAuth2 / OpenID Connect grant request. If no origins are registered for this Application, all origins are allowed.

By default FusionAuth will add the `X-Frame-Options: DENY` HTTP response header to the login pages to keep these pages from being rendered in an iframe. If the request comes from an authorized origin, however, FusionAuth will not add this header to the response. To load FusionAuth hosted login pages in an iframe, you will need to add the request origin to this configuration.

Configured URLs containing wildcards are considered during validation when **Authorized request origin URLs** is set to `Allow wildcards`. Wildcards are allowed in the following positions:

*   The left-most subdomain - A full or partial wildcard is allowed in the left-most subdomain. The replacement value cannot contain a `.`.
*   The port number - A wildcard is allowed in place of the port number. Partial wildcards are not allowed in this position.
*   A path segment - A full or partial wildcard is allowed in any path segment. The replacement value cannot contain a `/`.
*   A query string value - A wildcard is allowed in place of a query string value. Partial wildcards are not allowed in this position. Wildcards are not allowed in query string names.

See the OAuth 2.0 [URL Validation](/docs/lifecycle/authenticate-users/oauth/url-validation) page for more detail.

`Authorized resource URIs`optionalAvailable since 1.67.0

An optional list of allowed resource server URIs for this Application, per [RFC 8707 (Resource Indicators for OAuth 2.0)](https://www.rfc-editor.org/rfc/rfc8707.html). Defaults to an empty list.

Each URI must be an absolute URI and may not contain a fragment (`#`). When this list is non-empty, clients may pass a `resource` parameter during the OAuth authorize and token flows to request access tokens scoped to a specific resource server. These flows only accept URIs present in this list; all other values return an `invalid_target` error.

When this list is empty (the default), FusionAuth silently ignores any `resource` parameter sent by the client; existing application behavior is unchanged.

Examples of valid resource URIs:

*   `https://api.example.com`
*   `https://mcp.example.com/v2/api`

`Logout URL`optional

The optional logout URL for this Application. When provided this logout URL should handle the logout of a user in your application.

If you need to end an HTTP session or delete cookies to logout a user from your application, these operations should be handled by this URL. When the `/oauth2/logout` endpoint is retrieved, each Logout URL registered for Applications in this tenant will be called within an iframe to complete the SSO logout.

If the OAuth2 logout endpoint is used with this Client Id, this configured Logout URL will be also utilized as the redirect URL. This behavior only occurs when the `post_logout_redirect_uri` parameter is not provided.

If this Application has not defined a Logout URL, the value configured at the Tenant level will be used. If no Logout URL has been configured, a redirect to `/` will occur. A specific redirect URL may also be provided by using the `post_logout_redirect_uri` request parameter.

See the [Logout endpoint](/docs/apis/oauth/logout) or the [Logout And Session Management guide](/docs/lifecycle/authenticate-users/logout-session-management) for more information.

`Logout behavior`optionalAvailable since 1.11.0

This selector allows you to modify the behavior when using the [Logout endpoint](/docs/apis/oauth/logout) with this Client Id.

The possible values are:

*   `All applications` - This is the default behavior. Upon Logout of the FusionAuth SSO, call each registered Logout URLs for the entire tenant and then redirect to the Logout URL registered for this application.
*   `Redirect only` - Do not call each registered Logout URL in the tenant, instead logout out of the FusionAuth SSO and then only redirect to the Logout URL registered for this application.

See the [Logout endpoint](/docs/apis/oauth/logout) for more information.

`Enabled grants`optionalAvailable since 1.5.0

The enabled OAuth2 grants. If a grant is not enabled and a client requests this grant during authentication an error will be returned to the caller indicating the grant is not enabled.

*   Authorization Code
*   Device
*   Implicit
*   Password
*   Refresh Token

When creating a new Application, the `Authorization Code` and `Refresh Token` grants will be enabled by default. See The [OAuth 2.0 & OpenID Connect Overview](/docs/lifecycle/authenticate-users/oauth/) for additional information on each of these grants.

`Device Verification URL`optionalAvailable since 1.11.0

The URL to be returned during the Device Authorization request to be displayed to the end user. This URL will be where the end user navigates in order to complete the device authentication workflow.

This field is required if `Device` is enabled in the OAuth **Enabled grants** for this Application and hidden when not.

`Require registration to complete OAuth authorization`optionalAvailable since 1.28.0

When enabled the user will be required to be registered, or complete registration before redirecting to the configured callback in the authorization code grant or the implicit grant. This configuration does not affect any other grant, and does not affect the API usage.

`UserInfo populate lambda`optionalAvailable since 1.50.0

The lambda to be invoked during the generation of the UserInfo response when provided a token associated with this Application. See [UserInfo populate lambda](/docs/extend/code/lambdas/userinfo-populate).

### Scopes[#](#scopes)

Available since 1.50.0

The Scopes tab allows you to configure OAuth scope settings specific to this Application. To manage custom OAuth Scopes, click the Manage Scopes button in the action dropdown a the top of the page or click the link to `Manage custom scopes` from the Scopes tab. See [Scopes](/docs/get-started/core-concepts/scopes) for more detail.

![Application Scopes configuration](/img/docs/get-started/core-concepts/application-scopes.png)

#### Form Fields[#](#form-fields-2)

`Relationship`

The application's relationship to the authorization server, otherwise known as the OAuth server.

The possible values are:

*   `First-party` - The application has the same owner as the authorization server. Consent to requested OAuth scopes is granted implicitly. This was the default behavior for all versions of FusionAuth before version 1.50.0.
*   `Third-party` - The application is external to the authorization server. Users will be prompted to consent to requested OAuth scopes based on **Consent mode**.

**Note:** To use third-party applications, you'll need an Essentials or Enterprise plan.

`Consent mode`

Controls the policy for prompting a user to consent to requested OAuth scopes. This field is only visible when the application's **Relationship** is `Third-party`.

The possible values are:

*   `Always prompt` - Always prompt the user for consent.
*   `Remember decision` - Remember previous consents; only prompt if the choice expires or if the requested or required scopes have changed. The duration of this persisted choice is controlled by the tenant's **Remember OAuth scope consent choice** configuration.
*   `Never prompt` - The user will be never be prompted to consent to requested OAuth scopes. Permission will be granted implicitly as if this were a `First-party` application. This configuration is meant for testing purposes only and should not be used in production.

`Unknown scope policy`

Controls the policy for handling unknown scopes on an OAuth request.

The possible values are:

*   `Allow` - Unknown scopes will be allowed on the request, passed through the OAuth workflow, and written to the resulting tokens without consent. This is the behavior for all versions of FusionAuth before version 1.50.0.
*   `Remove` - Unknown scopes will be removed from the OAuth workflow, but the workflow will proceed without them.
*   `Reject` - Unknown scopes will be rejected and cause the OAuth workflow to fail with an error. This is the default behavior for new applications.

`Scope handling policy`

Controls the policy for handling of OAuth scopes when populating JWTs and the UserInfo response.

The possible values are:

*   `Compatibility` - OAuth workflows will populate JWT and UserInfo claims in a manner compatible with versions of FusionAuth before version 1.50.0.
*   `Strict` - OAuth workflows will populate token and UserInfo claims according to the OpenID Connect 1.0 specification based on requested and consented scopes.

`Provided scopes`

Configuration for standard scopes provided by FusionAuth. Each provided scope is reserved by FusionAuth and can be individually Enabled and **Required**. A disabled scope will be treated as unknown by FusionAuth and handled in accordance with the **Unknown scope policy**. A user must consent to all **Required** scopes present in an OAuth workflow, but may choose whether or not to consent to Enabled fields that are not **Required**.

### CleanSpeak[#](#cleanspeak)

The CleanSpeak configuration panel allows you to optionally configure username filtering through the use of a CleanSpeak integration. See [CleanSpeak Integration](/docs/lifecycle/manage-users/cleanspeak) for additional configuration details.

The use of this feature requires a licensed instance of CleanSpeak. See [https://cleanspeak.com](https://cleanspeak.com) for additional information.

![No Application Webhooks](/img/docs/get-started/core-concepts/application-cleanspeak.png)

### Identities[#](#identities)

The identities configuration allows you to optionally select customized email or message templates for this Application. When configured, an application specific template will be used instead of the corresponding tenant configured template.

![Application Identities](/img/docs/get-started/core-concepts/application-identities.png)

#### Form Fields[#](#form-fields-3)

`Base URL`optionalAvailable since 1.68.0

The base URL used when rendering links in templates for this Application. When defined, this value overrides the Tenant base URL.

`Admin two-factor method removal`optionalAvailable since 1.68.0

The email or message template to use when notifying a user that an administrator removed one of their two-factor methods.

`Forgot password`optional

The email or message template to use for the forgot password workflow.

`Identity update`optionalAvailable since 1.30.0

The email or message template to use when notifying a user that their identity has been updated.

**Note:** To use this feature, you'll need an Enterprise plan.

`Login Id duplicate on create`optionalAvailable since 1.30.0

The email or message template to use when notifying a user that another user has attempted to register an account with the same email address, phone number, or username as they have. If user Richard has an email `richard@piedpiper.com` and a new user tries to register with the email address `richard@piedpiper.com`, then user Richard will be notified.

**Note:** To use this feature, you'll need an Enterprise plan.

`Login Id duplicate on update`optionalAvailable since 1.30.0

The email or message template to use when notifying a user that another user has attempted to change their own email, phone number, or username to a value in-use by the user.

**Note:** To use Login Id duplicate on update, you'll need an Enterprise plan.

`Login with new device`optionalAvailable since 1.30.0

The email or message template to use when notifying a user that a new device was used to login.

**Note:** To use Login with new device, you'll need an Enterprise plan.

`Suspicious login`optionalAvailable since 1.30.0

The email or message template to use when notifying a user that a login occurred and it was determined to be of interest or suspect due to the location, IP address or other factors.

**Note:** To use Suspicious login, you'll need an Enterprise plan.

`Password reset success`optionalAvailable since 1.30.0

The email or message template to use when notifying a user that their password has been successfully updated using the reset workflow.

**Note:** To use Password reset success, you'll need an Enterprise plan.

`Password update`optionalAvailable since 1.30.0

The email or message template to use when notifying a user that their password has been successfully updated. This is different from **Password reset success** in that this event occurs outside of the reset workflow.

**Note:** To use Password update, you'll need an Enterprise plan.

`Passwordless login`optional

The email or message template to use to send the link or one-time code for passwordless login requests.

`Set up password`optional

The email or message template to use when accounts are created and the user needs to set up their password.

`Two-factor method added`optionalAvailable since 1.30.0

The email or message template to use when notifying a user that a new two-factor method has been successfully added.

**Note:** To use Two-factor method added, you'll need an Enterprise plan.

`Two-factor method removed`optionalAvailable since 1.30.0

The email or message template to use when notifying a user that a previously configured two-factor method has been successfully removed.

**Note:** To use Two-factor method removed, you'll need an Enterprise plan.

`Verification complete template`optionalAvailable since 1.30.0

The email or message template to use when notifying a user that their identity has been verified.

**Note:** To use this feature, you'll need an Enterprise plan.

`Verification template`optionalAvailable since 1.27.0

The email or message template to use when accounts are created to verify the User's identity.

### JWT[#](#jwt)

The JWT configuration allows you to provide Application-specific JWT configuration. When this panel is left in the default state as shown in this screenshot without the enable toggle turned on, the JWT configuration provided by the Tenant will be utilized.

![Application JWT disabled](/img/docs/get-started/core-concepts/application-jwt-disabled.png)

`Enable application-level JWT override`optional

When enabled you may configure Application specific JWT configuration including signing keys, durations, etc.

#### Lambda Settings[#](#lambda-settings)

The application specific lambda settings are available even if you choose not to enable additional application specific JWT configuration by leaving the **Enable** field off.

`Access token populate lambda`optional

The lambda to be invoked during the generation of an Access Token (JWT) when a user authenticates against this Application.

`Id token populate lambda`optional

The lambda to be invoked during the generation of an Id Token (JWT) when a user authenticates against this Application.

Once you have enabled JWT configuration for this Application you will be provided with additional configuration options.

![Application JWT enabled](/img/docs/get-started/core-concepts/application-jwt-enabled-configuration.png)

#### JWT Settings[#](#jwt-settings)

`Issuer`Read only

The issuer used in the `iss` claim when building the Access Token and Id Token. This is a read-only value in this configuration. It can be modified in the Tenant configuration.

`JWT duration`required

The duration in seconds for which a JWT will be valid after creation. After this time has passed the JWT will expire and can no longer be used.

`Access token signing key`optional

The signing key used to sign the Access Token (which is a JWT) when a user authentic The signing key used to sign the Access Token (which is a JWT) when a user authenticates against this Application. When this value is not selected, FusionAuth will generate a new key pair and assign it to this configuration.

`Id token signing key`optional

The signing key used to sign the Id Token (which is a JWT) when a user authenticates against this Application. When this value is not selected, FusionAuth will generate a new key pair and assign it to this configuration.

![Application Refresh Token configuration](/img/docs/get-started/core-concepts/application-jwt-enabled-refresh-token.png)

#### Refresh Token Settings[#](#refresh-token-settings)

`Refresh token duration`requiredDefaults to 43,200

The length of time the refresh token is valid. Refresh tokens are typically long lived.

`Refresh token expiration`optionalDefaults to Fixed

The **Refresh token expiration** may be one of the following:

*   **fixed window** (`Fixed`): expires a configurable time-to-live after *initial issuing*
*   **sliding window** (`SlidingWindow`): expires a configurable time-to-live after *the last time the refresh token was used*
*   **sliding window with a maximum lifetime** (`SlidingWindowWithMaximumLifetime`): combines the previous two options like an `OR` operator: expires a configurable time-to-live after *the last time the refresh token was used*, as long as it does not exceed a maximum lifetime after *initial issuing*

To configure the time-to-live, use `refreshTokenTimeToLiveInMinutes`; to configure the maximum lifetime, use `maximumTimeToLiveInMinutes`.

Consider a scenario where a refresh token is issued at 1:00, has an time-to-live of 60 minutes, and a maximum lifetime of 6 hours:

*   If the expiration is **fixed**, the token will expire at 2:00.
*   If the expiration is a **sliding window**, then if the refresh token is used at 1:55, it would then expire at 2:55. If it were then used at 2:50, it would expire at 3:50. This can continue *forever*, as long as the client always refreshes the token before 60 minutes have elapsed (good luck with daylight savings!).
*   If the expiration is a **sliding window with a maximum lifetime**, then if the refresh token is used at 1:55, it would then expire at 2:55. If it were then used at 2:50, it would expire at 3:50. This can continue until 7:00, when the refresh token passes the *maximum lifetime* and expires.

`Refresh token usage`optionalDefaults to Reusable

The **Refresh token usage** may be reusable or one time use. By default, a token is reusable and the token does not change after it was issued. With a one time use token, the token value will be changed each time the token is used to refresh a JWT. This means the client must store the new value after each use.

`One-time use grace period`optionalDefaults to 0

When **Refresh token usage** is set to `One-time use`, you may optionally set the grace period to something greater than `0` seconds.

The grace period is the length of time specified in seconds that a one time use token can be reused.

This value must be greater than `0` and less than `86400` which is equal to 24 hours. Setting this value to `0` effectively disables the grace period which means a one-time token may not be reused. For security reasons, you should keep this value as small as possible, and only increase past `0` to improve reliability for an asynchronous or clustered integration that may require a brief grace period.

Note that one-time use tokens refreshed within a grace period are not considered for revocation when the Tenant Refresh Token Revocation Policy is configured to revoke a one-time use refresh token on reuse. When a token is reused within the grace period the current token will be returned on the API response and the token will not be rotated.

### Multi-Factor[#](#multi-factor)

This feature is only available in paid plans. To learn more, see [our pricing page](/pricing).

The multi-factor configuration allows you to provide Application specific multi-factor settings.

![Multi-Factor Authentication configuration](/img/docs/get-started/core-concepts/application-mfa.png)

#### Form Fields[#](#form-fields-4)

`On login policy`optional

If a policy requires a two-factor challenge on login and the user has not already configured a two-factor method, then they will be required to configure one.

Risk-based policies use FusionAuth's **Intelligent MFA**, which combines multiple signals to decide when to issue an MFA challenge.

Supported values include:

*   No application policy selected. Multi-factor authentication is managed by the tenant.
*   Disabled: Never challenge during login
*   Enabled: Only challenge if user has configured an eligible MFA method
*   Challenge On Medium Risk: Only challenge on medium or high login risk   Available since 1.68.0
*   Challenge On High Risk: Only challenge on high login risk   Available since 1.68.0
*   Required: Always challenge during login   Available since 1.42.0

**Note:** To use an Intelligent MFA Policy, you'll need a paid plan.

`Trust policy`optional

When **On login policy** is set to `Enabled` or `Required`, the following field will be displayed. This value will control how the two-factor trust value is utilized.

Supported values include:

*   Any. Trust obtained from any application is sufficient to bypass the challenge during login.
*   This Application. Only trust obtained from this application is sufficient to bypass to challenge during login.
*   None. The user will always be prompted to complete a challenge during login.

`Email template`optional

When a template is selected, it will be used to send a multi-factor authentication code when the email MFA method is used and a user is signing in to this application.

`SMS template`optional

When a template is selected, it will be used to send a multi-factor authentication code when the phone MFA method is used and a user is signing in to this application.

`Voice template`optionalAvailable since 1.65.0

When a template is selected, it will be used to send a multi-factor authentication code when voice delivery is used for the phone MFA method and a user is signing in to this application.

`MFA requirement lambda`optionalAvailable since 1.62.0

The MFA requirement lambda that will be invoked during logins, password changes, and MFA Status API calls. FusionAuth uses this lambda to determine whether to challenge the user with MFA. The lambda assigned to the application will override the lambda assigned to the application's tenant.

You can customize this logic to:

*   Change FusionAuth's MFA decision for a user.
*   Trigger a suspicious login event based on your criteria.   Available since 1.62.0

This feature is only available in the Enterprise plan. To learn more, see [our pricing page](/pricing).

### WebAuthn[#](#webauthn)

This feature is only available in Essentials or Enterprise plans. To learn more, see [our pricing page](/pricing).

The WebAuthn configuration allows you to configure which WebAuthn workflows are enabled for the Application, overriding the Tenant configuration.

![WebAuthn configuration](/img/docs/get-started/core-concepts/application-webauthn.png)

#### Form Fields[#](#form-fields-5)

`Enable application-level WebAuthn override`optional

When disabled, the tenant configuration for enabled WebAuthn workflows will be used. When enabled, the options on this page will be used to override which WebAuthn workflows are enabled for this application.

#### Bootstrap settings[#](#bootstrap-settings)

The bootstrap workflow is used when the user must "bootstrap" the authentication process by identifying themselves prior to the WebAuthn ceremony and can be used to authenticate from a new device using WebAuthn.

#### Form Fields[#](#form-fields-6)

`Enable passkey authentication`optional

When enabled, users will be able to use the WebAuthn bootstrap workflow to sign in, including on new devices.

#### Re-authentication settings[#](#re-authentication-settings)

The re-authentication workflow is used to streamline the login process for repeat logins on a device.

#### Form Fields[#](#form-fields-7)

`Enable re-authentication workflow`optional

When enabled, users will be able to use the WebAuthn re-authentication workflow for repeat logins on their device.

### Registration[#](#registration)

The registration configuration allows you to provide Application specific registration configuration.

![Application Registration](/img/docs/get-started/core-concepts/application-registration-verify.png)

#### Form Fields[#](#form-fields-8)

`Verify registrations`optional

When enabled a registration can be verified using an email workflow. This is similar to the email verification process, which occurs when a user is first created. Verifying a registration allows you to send an email to an end user and allows them to confirm they registered for this specific application.

`Verification template`required

The email template to be used when sending the Registration Verification email to the end user.

Required when **Verify registrations** field toggle has been enabled.

`Enable auto-deletion of unverified registrations`optional

When enabled, the system will delete registrations for users who have not verified their registration for this application after a configurable duration since the registration occurred.

`Delete after`required

The duration in days for which a user's registration to this application must exist and remain unverified before being deleted.

Required when **Enable auto-deletion of unverified registrations** field toggle has been enabled.

#### Self-Service Registration[#](#self-service-registration)

Self-service registration controls how end users can create or complete registrations for this application.

Use Registration mode to select registration behavior, then choose Basic or Advanced to define the registration form experience.

![Self Service Registration](/img/docs/get-started/core-concepts/application-registration-self-service-enabled.png)

#### Form Fields[#](#form-fields-9)

`Registration mode`optionalAvailable since 1.65.0

Select the self-service registration behavior for this application.

Supported values include:

*   **Disabled**: Users cannot self-register for this application.
*   **Complete registration**: Users cannot self-register, but can complete missing profile information from an existing registration.
*   **Create registration**: Users can self-register for this application using a link on the login page.

`Type`optional

Select Basic or Advanced self-service registration forms.

A paid plan of FusionAuth is required to use the Advanced self-service registration forms.

Use Basic to configure standard registration fields directly in the application settings.

![Basic Self Service Registration](/img/docs/get-started/core-concepts/application-complete-registration-self-service-basic.png)

#### Basic Self Service Registration[#](#basic-self-service-registration)

`Confirm password`optional

Toggle this field if you want FusionAuth to require a password confirmation during registration.

`Login type`optional

This field indicates if the email address or username should be the user's unique identifier.

`Registration fields`optional

The optional fields to be displayed on the registration form.

`Field`Read only

The user attribute that can be shown on the registration form. Each field can be Enabled and/or Required .

`Enabled`optional

This field will be shown on the registration form.

`Required`optional

This field will be required and the user will be unable to complete registration unless the field is provided. If this field is not also Enabled then it will not be required.

Use Advanced to configure a custom registration form with multi-step and custom field support.

![Advanced Self Service Registration](/img/docs/get-started/core-concepts/application-complete-registration-self-service-advanced.png)

#### Advanced Self Service Registration[#](#advanced-self-service-registration)

This feature is only available in paid plans. To learn more, see [our pricing page](/pricing).

Advanced self-service registration allows you to create a custom registration form, including validation, custom form fields, and multiple steps. [Learn more in the guide](/feature/user-registration).

`Form`required

The selected form will be used to provide self-service registration for this application.

`Self-service registration validation`optionalAvailable since 1.43.0

The lambda that will be used to perform additional validation on registration form steps. See [Self-Service Registration Validation lambda](/docs/extend/code/lambdas/self-service-registration)

![Custom Registration Form](/img/docs/get-started/core-concepts/application-registration-form.png)

#### Form Settings[#](#form-settings)

This feature is only available in paid plans. To learn more, see [our pricing page](/pricing).

`Admin Registration`optionalAvailable since 1.20.0

The form that will be used in the FusionAuth UI for adding and editing user registrations.

`User self-service`optionalAvailable since 1.26.0

The form that will be used with the hosted login pages for user self-service account management.

`Require current password`optionalAvailable since 1.45.0

When enabled a user will be required to provide their current password when changing their password on a self-service account form.

### SAML[#](#saml)

The SAML configuration allows you to reveal FusionAuth as a SAML v2 Identity Provider (IdP).

![Application SAML](/img/docs/get-started/core-concepts/application-saml-disabled.png)

`Enable SAML v2`optional

When enabled you may configure FusionAuth to reveal this application as a SAML v2 Identity Provider (IdP).

Once you have enabled SAML for this Application you will be provided with additional configuration options.

![Application SAML enabled](/img/docs/get-started/core-concepts/application-saml-enabled.png)

#### Form Fields[#](#form-fields-10)

`Issuer`required

The issuer used by service providers (i.e. Google, Zendesk, etc.) to identify themselves to FusionAuth's SAML identity provider. Often you cannot set this in the service provider and need to read their documentation or test the integration and use the error messages to determine the correct value.

`Audience`optional

Some service providers require a different audience (such as Zendesk). You can leave this blank if the audience is the same as the issuer.

`Authorized redirect URLs`required

One or more allowed URLs that FusionAuth may redirect to after the user has logged in via SAML v2, also known as the Assertion Consumer Service URL (ACS).

`Logout URL`optional

The URL that the user is redirected to after they are logged out. Usually this is the starting location of the application.

`Enable debug logging`optional

Creates event log entries to help debug integration errors. Check System -> Event Log .

![Application SAML authentication request settings](/img/docs/get-started/core-concepts/application-saml-authentication-request.png)

#### Authentication Request[#](#authentication-request)

`Require signed authentication requests`optional

When enabled, all unsigned requests will be rejected.

`Default verification key`optionalAvailable since 1.20.0

The verification key used to verify a signature when the SAML v2 Service Provider is using HTTP Redirect Bindings.

When HTTP POST Bindings are used, this is the default verification key used if a `KeyInfo` element is not found in the SAML AuthNRequest. If a `KeyInfo` element is found, Key Master will be used to resolve the key and this configuration will not be used to verify the request signature.

This field is required when **Require signed authentication requests** is enabled.

`Enable login hint`Available since 1.47.0

When enabled, FusionAuth will accept a username or email address as a login hint on a custom HTTP request parameter.

`Login hint parameter name`optionalDefaults to login\_hintAvailable since 1.47.0

The name of the login hint parameter provided by the service provider on an AuthnRequest. If this parameter is present, its value will be used to pre-populate the username field on the FusionAuth login form.

For example, suppose **Enable login hint** is enabled and **Login hint parameter name** has the value `login_name`. When FusionAuth is set up as an IdP, the SP can send a request which includes the parameter `login_name=richard@example.com`, and FusionAuth will pre-populate [richard@example.com](mailto:richard@example.com) into the login form the end user sees.

Note that this setting names an HTTP query parameter, not an element in the SAML AuthnRequest XML.

![Application SAML authentication response settings](/img/docs/get-started/core-concepts/application-saml-authentication-response.png)

#### Authentication Response[#](#authentication-response)

`Signing key`optional

The signing key used to sign the SAML request. When this value is not selected the default selection will cause FusionAuth to generate a new key pair and assign it to this configuration.

`Signature canonicalization method`optional

The XML signature canonicalization method. If you are unsure which method to select, leave the default and begin testing, or contact your service provider for configuration assistance.

`Signature location`optionalDefaults to AssertionAvailable since 1.21.0

The location of the XML signature in the SAML response.

`Populate lambda`optional

The lambda used to add additional values from the user and registration to the SAML response.

`Enable IdP-initiated login`optionalDefaults to falseAvailable since 1.41.0

When enabled, FusionAuth will be able to initiate a login request to a SAML v2 Service Provider.

Once enabled, open the View dialog or this application to view the integration URI. You will find this value in the view dialog in the SAML v2 Integration details, and the value will be named **Initiate login URL**:.

`NameID format`optionalDefaults to PersistentAvailable since 1.41.0

The NameId format to send in the AuthN response to the SAML v2 Service Provider. There are two valid values:

*   Persistent - The `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent` NameID format will be used.
*   Email - The `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` NameID format will be used.

![Application SAML logout request settings](/img/docs/get-started/core-concepts/application-saml-logout-request.png)

#### Logout Request[#](#logout-request)

`Require signed logout requests`optionalAvailable since 1.25.0

When enabled the SAML service provider (SP) will be required to sign the Logout request. All unsigned Logout requests will be rejected.

`Default verification key`optionalAvailable since 1.25.0

The unique Id of the Key used to verify the signature if the public key cannot be determined by the KeyInfo element when using POST bindings, or the key used to verify the signature when using HTTP Redirect bindings.

This field is required when **Require signed logout requests** is enabled.

`Logout behavior`optionalAvailable since 1.25.0

This selector allows you to modify the behavior when logout occurs. There are two valid values:

*   All session participants - This is the default behavior. Each session participant that has enabled single logout will be sent a Logout Request.
*   Only logout request originator - no other session participants will be notified when a logout request is sent for this application.

`Enable single logout`optionalAvailable since 1.25.0

Enable this to receive a LogoutRequest as a session participant when any other SAML enabled application within the same tenant receives a LogoutRequest.

`Logout URL`optionalAvailable since 1.25.0

The URL where you want to receive the LogoutRequest from FusionAuth.

This field is required when **Enable single logout** is enabled.

You can learn more about this behavior in the [Logout And Session Management guide](/docs/lifecycle/authenticate-users/logout-session-management).

`Signing key`optionalAvailable since 1.25.0

The Key used to sign the SAML Single Logout response.

`Signature canonicalization method`optionalAvailable since 1.25.0

The XML signature canonicalization method. If you are unsure which method to select, leave the default and begin testing, or contact your service provider for configuration assistance.

![Application SAML logout response settings](/img/docs/get-started/core-concepts/application-saml-logout-response.png)

#### Logout Response[#](#logout-response)

`Signing key`optionalDefaults to AssertionAvailable since 1.25.0

The signing key used to sign the SAML logout request. When this value is not selected the Authentication Response **Signing key** will be used.

`Signature canonicalization method`optionalAvailable since 1.25.0

The XML signature canonicalization method. If you are unsure which method to select, leave the default and begin testing, or contact your service provider for configuration assistance.

![Application SAML assertion encryption settings](/img/docs/get-started/core-concepts/application-saml-assertion-encryption.png)

#### Assertion Encryption[#](#assertion-encryption)

`Enable assertion encryption`optionalDefaults to falseAvailable since 1.47.0

When enabled, assertions in SAML responses will be encrypted.

`Encryption algorithm`optionalAvailable since 1.47.0

The symmetric key encryption algorithm used to encrypt the SAML assertion.

`Key location`optionalDefaults to ChildAvailable since 1.47.0

The location that the encrypted symmetric key information will be placed in the SAML response in relation to the `EncryptedData` element containing the encrypted assertion value.

`Key transport algorithm`optionalAvailable since 1.47.0

The encryption algorithm used to encrypt the symmetric key for transport in the SAML response.

`Digest algorithm`optionalAvailable since 1.47.0

The message digest algorithm to use when encrypting the symmetric key for transport.

`Mask generation function`optionalAvailable since 1.47.0

The mask generation function and hash function to use for the Optimal Asymmetric Encryption Padding when encrypting a symmetric key for transport. This configuration is only available when **Key transport algorithm** is set to `RSA OAEP with MGF1`.

`Key transport encryption certificate`optionalAvailable since 1.47.0

The RSA certificate from Key Master that will be used to encrypt the SAML assertion encryption symmetric key for transport.

This field is required when SAML assertion encryption is enabled.

### Security[#](#security)

The Security tab contains some additional security configuration for this application.

![Application Security](/img/docs/get-started/core-concepts/application-security.png)

#### Login API Settings[#](#login-api-settings)

`Require an API key`optional

When enabled the Login API will require an API key. This is functionally equivalent to requiring client authentication during OAuth2.

`Generate Refresh Tokens`optional

When enabled the Login API will return refresh tokens. This is functionally equivalent to requesting the offline\_scope during an OAuth2 grant.

`Enable JWT refresh`optional

When enabled a JWT may be refreshed using the JWT Refresh API. This is functionally equivalent to enabling the OAuth2 Refresh Grant.

##### Access control lists settings[#](#access-control-lists-settings)

This feature is only available in paid plans. To learn more, see [our pricing page](/pricing).

`Access control list`optionalAvailable since 1.30.0

The IP access control list that will be used to restrict or allow access to hosted login pages in FusionAuth. Using this, you can allow access to or block specific IP addresses from an application's authentication pages (login, forgot password, etc).

When configured, this value will override the IP access control list configuration on the tenant.

#### Passwordless Login[#](#passwordless-login)

`Enable passwordless login`optional

When enabled, allow users to request login using a link sent via an email (or code sent via an SMS message). Enable this feature to display a button on the FusionAuth login form and allow usage of the Passwordless Login API.

`Email login strategy`Available since 1.64.0

The default login strategy by which the user will complete the passwordless login via email. The possible values are:

*   `ClickableLink` - send the user a clickable link that they can open in a web browser to authenticate
*   `FormField` - send the user a short code that they can enter into a form field to authenticate

`Phone login strategy`Available since 1.64.0

The default login strategy by which the user will complete the passwordless login via phone. The possible values are:

*   `ClickableLink` - send the user a clickable link that they can open in a web browser to authenticate
*   `FormField` - send the user a short code that they can enter into a form field to authenticate

#### Authentication Tokens[#](#authentication-tokens)

`Enable authentication tokens`optional

When enabled, allow users to optionally authenticate using an Application specific token in place of their password. This should only be used when the security requirements are low and the user's normal password is not a good option for authentication.

For example, if a password needs to be stored in an external configuration and the exposure risk is low, a token can be used in place of the user's password. This token may only be used for authorization for this application.

### Webhooks[#](#webhooks)

This feature is removed as of version 1.37.0.

The Webhooks tab allows you to select one or more webhooks to be used for this Application. In this example screenshot either no webhooks have been configured, or no application specific webhooks are configured.

![No Application Webhooks](/img/docs/get-started/core-concepts/application-webhooks-none.png)

In most cases you will not need to configure this panel. Only a few specific events are considered application specific, and when a webhook is configured to be application specific, only those events will be sent to the webhook.

This example screenshot shows one Application specific webhook selected. This option will be visible if at least one webhook is configured as application specific.

![Application Webhooks Selected](/img/docs/get-started/core-concepts/application-webhooks-selected.png)

## Universal Applications[#](#universal-applications)

A universal application is an application that exists for all tenants, rather than belonging to a single tenant. Universal applications are useful when you need to make the same application available to users across many or all tenants.

A universal application uses the same application configuration across all tenants, including its client Id, client credentials, and more. This makes configuration management simpler, allowing you to share configuration across all uses of the application.

### Universal Application Registrations[#](#universal-application-registrations)

Users from any tenant can have a registration to a universal application, and registrations work as they would for normal applications.

### Universal Applications and Tenants[#](#universal-applications-and-tenants)

Because a universal application does not belong to a single tenant, you will generally have to supply a tenant Id when interacting with a universal application. This is true during authentication and other user-specific workflows. The supplied tenant Id tells FusionAuth a number of things, such as which tenant the user that is logging in belongs to, which theme to use, and more.

The tenant Id is typically provided on a `tenantId` query parameter, unless otherwise specified.

A universal application "inherits" settings from the tenant it is being associated with at runtime. This means that you can customize the behavior of a universal application per tenant by using different tenant configuration.

Note that for tenant configuration settings that can be overridden at the application level, if you supply an application-level override, that setting will be used for all tenants. If this is not what you want, do not set a value in the universal application's configuration and let the application fall back to what is defined in the tenant.

### Universal Applications and Tenant-scoped API Keys[#](#universal-applications-and-tenant-scoped-api-keys)

A tenant-scoped API key cannot make changes that could be seen or otherwise affect other tenants than the one it is scoped to. Because universal applications span all tenants, you cannot use a tenant-scoped API key with a universal application via the [Application API](/docs/apis/applications). You can, however, use a tenant-scoped API key to interact with things like registrations and refresh tokens, as these are confined to a user within a tenant.

### Configure an Application as Universal[#](#configure-an-application-as-universal)

You can only set an application as universal when it is created. Do this by setting **application.universalConfiguration.universal** to `true` when using the API, or select the Universal toggle on the Add Application view in the admin app.

### Universal Applications and the Self-serve Account application[#](#universal-applications-and-the-self-serve-account-application)

When using the [self-serve account](/docs/lifecycle/manage-users/account-management) application, users supply an application Id to edit their profile within the context of that application. To use this application with a universal application, the user will also need to specify a tenant Id in the following way:

```
/account?client_id=APPLICATION_ID&tenantId=TENANT_ID
```