authentik Documentation

Endpoint Devices Device Compliance Connectors Index (`website/docs/endpoint-devices/device-compliance/connectors/index.mdx`) Copy Section

title: Connectors sidebar_label: Connectors tags: [device compliance, compliance, connectors, authentik Agent, fleet, fleetdm] authentik_version: "2025.12.0" Copy Chapter

Connectors allow device information to be reported to authentik. Connectors for third-party services like Fleet can be used standalone or alongside the authentik Agent connector.

Available connectors Copy Chapter

The following connectors are currently available:

• authentik Agent connector: Integrates with the authentik Agent
• Fleet connector: Integrates with Fleet device management

Connectors are in development for Entra, Intune, Cloudflare WARP and other services.

Manage connectors Copy Chapter

Use the following instructions to manage your connectors:

Add a connector Copy Section

For more specific instructions on adding a connector refer to the authentik Agent connector or Fleet connector documentation.

1. Log in to authentik as an administrator and open the authentik Admin interface.
2. Navigate to Endpoint Devices > Connectors and click Create.
3. Select the connector type, click Next, and configure the following required settings:
   • Connector name: Provide a descriptive name for the connector.
   • Refresh interval: Select how often the agent updates its configuration.
   • Enabled: Enable or disable the connector.
4. Click Finish.

Edit a connector Copy Section

1. Log in to authentik as an administrator and open the authentik Admin interface.
2. Navigate to Endpoint Devices > Connectors.
3. Click on the connector that you wish to edit.
4. Update any settings that you want to change.
5. Click Update.

Delete a connector Copy Section

1. Log in to authentik as an administrator and open the authentik Admin interface.
2. Navigate to Endpoint Devices > Connectors.
3. Select the connector that you wish to delete.
4. Click Delete.

Sys Mgmt Ops Autoscaling Index (`website/docs/sys-mgmt/ops/autoscaling/index.mdx`) Copy Section

title: Autoscaling on Kubernetes slug: /sys-mgmt/ops/autoscaling sidebar_label: Overview sidebar_position: 1 Copy Chapter

On Kubernetes, you can automatically adjust the number of authentik server and worker replicas independently:

• Scale servers on CPU usage with the Helm chart's Horizontal Pod Autoscaler (HPA). This requires Kubernetes resource metrics, but does not require KEDA or Prometheus.
• Scale workers on queued tasks with KEDA. Queue length can reveal a backlog even when workers use little CPU, such as when they wait for external services. The metric includes delayed tasks and excludes tasks already running.

Keep at least one worker running to handle scheduled tasks and file changes. For the number of tasks each replica can run concurrently, see Worker scaling.

Sys Mgmt Ops Storage S3 Index (`website/docs/sys-mgmt/ops/storage-s3/index.mdx`) Copy Section

title: S3-compatible storage sidebar_label: Overview sidebar_position: 1 Copy Chapter

authentik can store uploaded files in Amazon S3 or an S3-compatible object storage service instead of storing them on the local filesystem in /data.

This guide covers the settings, permissions, and migration steps that are common to S3 storage. For service-specific endpoints and authentication details, see S3-compatible storage providers.

For the full list of storage configuration options, see the configuration reference.

Prepare storage Copy Chapter

Before you configure authentik, create or identify the following values:

• An S3 bucket for authentik files, for example ``.
• S3 access credentials, unless you use AWS SDK authentication such as an instance role or profile.
• The S3 endpoint URL for your storage service, unless you use Amazon S3.
• The public origin that users use to access authentik, for example https://authentik.company.

The examples on this page use the AWS CLI. For S3-compatible services, add the service endpoint with --endpoint-url=<s3_endpoint>.

Configure bucket permissions Copy Chapter

authentik needs permission to list bucket contents and to read, write, and delete objects in the bucket. For Amazon S3, the following IAM policy grants those permissions:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListBucket",
            "Effect": "Allow",
            "Action": ["s3:ListBucket"],
            "Resource": "arn:aws:s3:::<bucket_name>"
        },
        {
            "Sid": "ManageObjects",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": "arn:aws:s3:::<bucket_name>/*"
        }
    ]
}

For other S3-compatible services, create an equivalent policy in the service's access-control system.

Configure CORS Copy Chapter

Apply a cross-origin resource sharing (CORS) policy to the bucket so that the authentik web interface can load files directly from generated S3 URLs.

Save the following policy as cors.json. Replace https://authentik.company with your authentik origin, including the scheme and port if you use a non-standard port.

{
    "CORSRules": [
        {
            "AllowedOrigins": ["https://authentik.company"],
            "AllowedHeaders": ["Authorization"],
            "AllowedMethods": ["GET"],
            "MaxAgeSeconds": 3000
        }
    ]
}

If users access authentik from more than one domain, include each origin in AllowedOrigins.

Apply the policy:

AWS_ACCESS_KEY_ID=<access_key> AWS_SECRET_ACCESS_KEY=<secret_key> aws s3api \
  --endpoint-url=<s3_endpoint> \
  put-bucket-cors \
  --bucket=<bucket_name> \
  --cors-configuration=file://cors.json

For Amazon S3, omit --endpoint-url.

Configure authentik Copy Chapter

Add the following settings to your .env file:

AUTHENTIK_STORAGE__BACKEND=s3
AUTHENTIK_STORAGE__S3__ACCESS_KEY=<access_key>
AUTHENTIK_STORAGE__S3__SECRET_KEY=<secret_key>
AUTHENTIK_STORAGE__S3__BUCKET_NAME=<bucket_name>

If you use AWS SDK authentication, such as an instance role or profile, omit AUTHENTIK_STORAGE__S3__ACCESS_KEY and AUTHENTIK_STORAGE__S3__SECRET_KEY. See AUTHENTIK_STORAGE__S3__SESSION_PROFILE and related options in the configuration reference.

For other S3-compatible services, also configure the service endpoint:

AUTHENTIK_STORAGE__S3__ENDPOINT=<s3_endpoint>

The provider reference lists service-specific endpoint and region values.

Configure a public S3 hostname Copy Section

Set AUTHENTIK_STORAGE__S3__CUSTOM_DOMAIN only when the hostname that authentik uses to reach S3 is different from the hostname that browsers use to retrieve files.

AUTHENTIK_STORAGE__S3__CUSTOM_DOMAIN=<public_s3_domain>/<bucket_name>

The custom domain must include the bucket name and must not include a scheme. For example, if users retrieve objects from https://s3.company/authentik-data/, set:

AUTHENTIK_STORAGE__S3__CUSTOM_DOMAIN=s3.company/authentik-data

AUTHENTIK_STORAGE__S3__SECURE_URLS controls whether generated file URLs use HTTPS and defaults to true.

Configure compatibility options Copy Section

If your storage service requires path-style bucket addressing, set:

AUTHENTIK_STORAGE__S3__ADDRESSING_STYLE=path

If your storage service supports only legacy S3 signatures, set:

AUTHENTIK_STORAGE__S3__SIGNATURE_VERSION=s3

The default signature version is s3v4.

For local HTTP testing, set AUTHENTIK_STORAGE__S3__SECURE_URLS=false. Use HTTPS for production deployments.

Check file content types Copy Chapter

Browsers rely on the HTTP Content-Type header to decide whether to render a file as an image, HTML, or another format. authentik sets the content type when it uploads files. If you upload files to the bucket with another tool, ensure that the tool also writes the correct Content-Type metadata.

The following command updates the Content-Type metadata for PNG files in a bucket:

aws s3 cp \
  s3://<bucket_name>/ s3://<bucket_name>/ \
  --exclude "*" --include "*.png" \
  --no-guess-mime-type \
  --content-type "image/png" \
  --metadata-directive "REPLACE" \
  --recursive

:::info
Terraform uploads to S3 do not set the Content-Type header unless you configure the metadata explicitly.
:::

Migrate between storage backends Copy Chapter

The following examples assume that the local storage path is /data and the bucket is ``. Ensure that your AWS CLI configuration can reach your storage service. For services other than Amazon S3, include --endpoint-url=<s3_endpoint>.

Migrate from file storage to S3 Copy Section

Follow the setup steps above, then sync files from the local directory to the bucket root:

aws s3 sync /data s3://<bucket_name>/

For services other than Amazon S3:

aws --endpoint-url=<s3_endpoint> s3 sync /data s3://<bucket_name>/

Migrate from S3 to file storage Copy Section

aws s3 sync s3://<bucket_name>/ /data

For services other than Amazon S3:

aws --endpoint-url=<s3_endpoint> s3 sync s3://<bucket_name>/ /data

Users Sources Sources Property Mappings Index (`website/docs/users-sources/sources/property-mappings/index.mdx`) Copy Section

title: Source property mappings Copy Chapter

Source property mappings allow you to modify or gather extra information from sources.

This page is an overview of how property mappings work. For information about a specific protocol, refer to the protocol page:

• Kerberos
• LDAP
• OAuth
• SAML
• SCIM

Create a custom source property mapping Copy Chapter

If the default source mappings are not enough, or if you need to get additional data from the source, you can create your own custom source property mappings.

Here are the steps:

1. In authentik, open the Admin interface, and then navigate to Customization > Property Mappings.
2. Click Create, select the property mapping type for your source, and then click Next.
3. Type a unique and meaningful Name, such as ldap-displayName-mapping:name.
4. In the Expression field, enter Python expressions to retrieve the value from the source. See Expression semantics below for details.
5. In the source configuration, select the newly created property mapping as a User property mapping if it applies to users, or Group property mapping if it applies to groups.

How it works Copy Chapter

Expression semantics Copy Section

Each source provides the Python expression with additional data. You can import parts of that data into authentik users and groups. Assuming the source provides us with a data Python dictionary, you can write the following:

return {
    "name": data.get("displayName"),
}

You can see that the expression returns a Python dictionary. The dictionary keys must match User properties or Group properties. Note that group_attributes cannot be set for users. A user property mapping can return groups, which feeds group synchronization rather than setting a property on the user.

See each source documentation for a reference of the available data. See the authentik expressions documentation for available data and functions.

Note that the list_flatten method is applied for all top-level properties, but not for attributes:

return {
    "username": data.get("username"), # list_flatten is automatically applied to top-level attributes
    "attributes": {
        "phone": list_flatten(data.get("phoneNumber")), # but not for attributes!
    },
}

Object construction process Copy Section

A user or group object is constructed as follows:

1. The source provides initial properties based on commonly used data.
2. Each property mapping associated with the source is run and results are merged into the previous properties.
   • If a property mapping throws an error, the process is aborted. If that happens inside a synchronization process, the object is skipped. If it happens during an enrollment or authentication flow, the flow is canceled.
   • If a property mapping sets one attribute to None, that attribute is then discarded.
3. If the username field is not set for user objects, or the name field is not set for group objects, the process is aborted.
4. The object is created or updated. The attributes property is merged with existing data if the object already exists.

Group synchronization Copy Section

LDAP and SCIM sources have built-in mechanisms to get groups. This section does not apply to them.

You can write a custom property mapping to set the user's groups:

return {
    "groups": data.get("groups", []),
}

The groups attribute is a special attribute that must contain group identifiers. By default, those identifiers are also used as the group name. Each identifier is then given to group property mappings as the group_id variable, if extra processing needs to happen.

An identifier has to be a simple value such as a string. Entries that are not, such as the objects some identity providers return in an OpenID Connect groups claim, are skipped, and a Configuration error event records how many were dropped.

Disabling group synchronization

The source collects its groups before any property mapping runs, and mapping results are merged into them as described in Object construction process. To prevent the collected groups from being imported, return None for the groups attribute:

return {"groups": None}

This stops groups from being imported. However, authentik reconciles source-linked memberships on every login, so users are still removed from groups that were created by or linked through the source.

Object-shaped OpenID Connect group claims

OpenID Connect does not define a groups claim, so providers are free to put anything in one. Some return group objects instead of plain identifiers.

The best fix is on the provider side. Configure it to return an array of stable, unique identifiers:

{
    "groups": ["g1", "g2"]
}

Prefer an immutable group ID from the provider. Only use a display name if it is unique and never changes.

If the provider cannot do that, create an OAuth source property mapping and attach it to the source's User property mappings. These mappings receive the provider's response in the info variable.

The mapping below handles a groups claim holding identifiers, objects, or a mix of both:

groups = []

for group in info.get("groups", []):
    if isinstance(group, dict):
        # Adjust these keys for your provider. Some use "id",
        # SCIM group resources use "value".
        group_id = group.get("value") or group.get("id")
    else:
        group_id = group

    if isinstance(group_id, (str, int)):
        groups.append(group_id)

return {"groups": groups}

Pick a stable, unique identifier from each object, because authentik uses it to recognize the group on later logins.

The identifiers the mapping returns are merged into the groups the source already collected, not substituted for them, so the original objects are still in the list. authentik skips those and records a Configuration error event counting how many it dropped. The identifiers you extracted still synchronize.

To get rid of the event, the groups claim itself has to contain only identifiers. Either change what the provider sends, or have it emit a separate identifier-only claim and map that claim to groups.

To use the provider's group name instead of the identifier, add a second OAuth source property mapping under the source's Group property mappings. It receives group_id along with the original info data:

for group in info.get("groups", []):
    if not isinstance(group, dict):
        continue

    # Use the same identifier keys as the user property mapping.
    if (group.get("value") or group.get("id")) != group_id:
        continue

    # Adjust these keys for your provider.
    group_name = group.get("display") or group.get("name")
    if group_name:
        return {"name": group_name}

    break

return {"name": str(group_id)}

Skip this second mapping if the identifier already makes a reasonable group name.

Users Sources Sources Social Logins Index (`website/docs/users-sources/sources/social-logins/index.mdx`) Copy Section

title: Federated identity providers sidebar_label: Identity providers tags: [saml, oauth] Copy Chapter

Configuring authentik with a federated identity provider allows users to authenticate with their existing credentials, such as social logins or enterprise identity providers.

Typically, identity providers use protocols such as OAuth 2.0 or Security Assertion Markup Language (SAML). These protocols allow authentik to act as a service provider (SP), delegating the authentication process to the identity provider (IdP). The choice of protocol depends on the provider and the level of integration desired.

IdP-initiated single sign-on Copy Chapter

In this scenario, a user is logged in to the IdP and attempts to access a resource on a remote SP server. In this example, the IdP is Google, Facebook, or another social login provider. The SP is authentik, acting as a service provider.

sequenceDiagram
    autonumber
    participant User
    participant IdP as Identity Provider
    participant SP as authentik
    participant Browser

    User->>IdP: Log in
    User->>SP: Access resource
    SP->>IdP: Request SAML assertion
    IdP->>IdP: Authenticate user
    IdP->>SP: Return SAML assertion
    SP->>Browser: Redirect to resource

In short, the user logs in to the IdP, requests access to a resource on the SP, and is redirected to the SP with a SAML assertion. The SP validates the assertion and establishes a session for the user.

SP-initiated single sign-on Copy Chapter

In this scenario, a user attempts to access a protected resource directly on an SP website without being logged in. The user does not have an account on the SP site, but does have a federated account managed by a third-party IdP. The SP sends an authentication request to the IdP. Both the request and the returned SAML assertion are sent through the user's browser via HTTP POST.

sequenceDiagram
    autonumber
    participant User
    participant IdP as Identity Provider
    participant SP as authentik
    participant Browser

    User->>SP: Access resource
    SP->>IdP: Request SAML assertion
    IdP->>IdP: Authenticate user
    IdP->>SP: Return SAML assertion
    SP->>Browser: Redirect to resource

In short, the user requests access to a resource on the SP, the SP requests a SAML assertion from the IdP, the IdP authenticates the user and returns a SAML assertion, and the SP establishes a session for the user.

Configure authentik Copy Chapter

While we provide detailed guides for popular services such as Google, GitHub, and Microsoft Entra ID, you can configure any standards-compliant provider using the same basic process.

authentik supports most identity providers that implement standard OAuth 2.0 or SAML 2.0 protocols. While each provider may have its own administrative interface, the core information needed is consistent, typically OAuth client credentials or SAML metadata.

Our provider-specific guides walk you through any unique steps needed for each service.

See also Copy Chapter

• Google identity providers
• Application Providers

External references Copy Chapter

• Federated Identity
• Social Login
• OAuth
• SAML

Users Sources User Account Types Index (`website/docs/users-sources/user/account-types/index.mdx`) Copy Section

title: Account types sidebar_position: 2 Copy Chapter

authentik supports several account types that represent people and machine identities. The account type determines how an account is created, how it authenticates, and how it is used.

The available account types are:

• Internal users: human users whose accounts are created and managed in authentik.
• External users: human users who typically authenticate to a single application and cannot access the authentik application dashboard.
• Service accounts: non-human identities created by an administrator for integrations and automation.
• Internal service accounts: non-human identities created and managed by authentik for internal components. They can not be created by administrators.
• Agent accounts: non-human identities that act on behalf of a parent user.

Choose an account type Copy Chapter

Use the following table to choose an account type:

Add Secure Apps Flows Stages Flow Context Index (`website/docs/add-secure-apps/flows-stages/flow/context/index.mdx`) Copy Section

title: Flow Context toc_max_heading_level: 5 Copy Chapter

Each flow execution has an independent context. This context holds all of the arbitrary data about that specific flow, data which can then be used and transformed by stages and policies.

Manage data in a flow context Copy Chapter

You create and manage the data for a context by configuring policies, stages, and bindings. As you plan your flow, and set up the required stages, etc. you are creating the context data for that flow.

For example, in the Identification Stage (part of the default login flow), you can define whether users will be prompted to enter an email address, a username, or both. All such information about the flow's configuration makes up the context.

Any data can be stored in the flow context, however there are some reserved keys in the context dictionary that are used by authentik stages.

To manage flow context on a more granular level, see Setting flow context keys.

Context dictionary and reserved keys Copy Chapter

This section describes the data (the context) that are used in authentik, and provides a list of keys, what they are used for and when they are set.

:::warning
Keys prefixed with goauthentik.io are used internally by authentik and are subject to change without notice, and should not be modified in policies in most cases.
:::

{/* To update this file, search for PLAN_CONTEXT_\w+\s= in the workspace to find all definitions. */}

Common keys Copy Section

`pending_user` ([User object](../../../../users-sources/user/user_ref.mdx#object-properties))

pending_user is used by multiple stages. In the context of most flow executions, it represents the data of the user that is executing the flow. This value is not set automatically, it is set via the Identification stage.

Stages that require a user, such as the Password stage, the Authenticator validation stage, and others will use this value if it is set, and fall back to the request's user when possible.

`prompt_data` (Dictionary)

prompt_data is primarily used by the Prompt stage. The value of any field within a prompt stage is written to the prompt_data dictionary. For example, given a field with the Field key email that was submitted with the value [email protected] will result in the following context:

{
    "prompt_data": {
        "email": "[email protected]"
    }
}

Policies can change this data. Stages such as User Write can then store values from prompt_data on pending_user.

For more information, see Collect custom user attributes during enrollment.

`redirect` (string)

Stores the final redirect URL that the user's browser will be sent to after the flow is finished executing successfully. This is set when an un-authenticated user attempts to access a secured application, and when a user authenticates/enrolls with an external source.

`pending_user_identifier` (string)

If Show matched user is disabled, this key will hold the user identifier entered by the user in the identification stage.

`application` (Application object)

When an unauthenticated user attempts to access a secured resource, they are redirected to an authentication flow. The application they attempted to access will be stored in the key attached to this object. For example: application.github, with application being the key and github the value.

`source` (Source object)

When a user authenticates/enrolls via an external source, this will be set to the source they are using.

`outpost` (dictionary)

When a flow is executed by an Outpost (for example the LDAP or RADIUS), this will be set to a dictionary containing the Outpost instance under the key "instance".

Scenario-specific keys Copy Section

`is_sso` (boolean)

This key is set to True when the flow is executed from an "SSO" context. For example, this is set when a flow is used during the authentication or enrollment via an external source, and if a flow is executed to authorize access to an application.

`is_restored` (Token object)

This key is set when a flow execution is continued from a token. This happens for example when an Email stage is used and the user clicks on the link within the email. The token object contains the key that was used to restore the flow execution. This field is also used by the Source stage when returning back to the initial flow the Source stage was run on.

`is_redirected` (Flow object)

This key is set when the current flow was reached through a Redirect stage in Flow mode.

Stage-specific keys Copy Section

Autosubmit stage

The autosubmit stage is an internal stage type that is not configurable via the API/Web interface. It is used in certain situations, where a POST request is sent from the browser, such as with SAML POST bindings. This works by using an HTML form that is submitted automatically.

`title` (string)

Optional title of the form shown to the user. Automatically set when this stage is used by the backend.

`url` (string)

URL that the form will be submitted to.

`attrs` (dictionary)

Key-value pairs of the data that is included in the form and will be submitted to url.

Captcha stage:ak-version

`captcha` (dictionary)

When Error on invalid score is set to false on a captcha stage, after the execution of the captcha stage, this object will be set in the flow context.

It contains two keys, response which is the raw response from the specified captcha verification URL, and stage, which is a reference to the captcha stage that executed the test.

`goauthentik.io/stages/captcha/site_key` (string):ak-version[2025.12]

`goauthentik.io/stages/captcha/private_key` (string):ak-version[2025.12]

Optionally set captcha site and private keys dynamically through a policy, for example when using E2E testing with a captcha stage bound.

Consent stage

`consent_header` (string)

The title of the consent prompt shown. Set automatically when the consent stage is used with an OAuth2, Proxy or SAML provider.

`consent_permissions` (List of PermissionDict)

An optional list of all permissions that will be given to the application by granting consent. Not supported with SAML. When used with an OAuth2 or Proxy provider, this will be set based on the configured scopes.

Deny stage

`deny_message` (string)

Optionally overwrite the deny message shown, has a higher priority than the message configured in the stage.

User write stage

`groups` (List of [Group objects](../../../../users-sources/groups/index.mdx))

See Group. If set in the flow context, the pending_user will be added to all the groups in this list.

If set, this must be a list of group objects and not group names.

`user_path` (string)

Path the pending_user will be written to. If not set in the flow, falls back to the value set in the user_write stage, and otherwise to the users path.

`user_type` (string)

Type the pending_user will be created as. Must be one of internal, external or service_account.

Password stage

`user_backend` (string)

Set by the Password stage after successfully authenticating the user. Contains a dot-notation to the authentication backend that was used to successfully authenticate the user.

`auth_method` (string)

Set by the Password stage, the Authenticator validation stage, the OAuth2 Provider, and the API authentication depending on which method was used to authenticate.

Possible options:

• password (Authenticated via the password in authentik's database)
• token (Authenticated via API token)
• ldap (Authenticated via LDAP bind from an LDAP source)
• auth_mfa (Authentication via MFA device without password)
• auth_webauthn_pwl (Passwordless authentication via WebAuthn with Passkeys)
• jwt (M2M authentication via an existing JWT)
• mtls (Authentication via Certificate, see Mutual TLS Stage)

`auth_method_args` (dictionary)

Additional arguments used during the authentication. Value varies depending on auth_method.

Example:

{
    // List of the MFA device objects used during authentication
    // applies for `auth_method` `auth_mfa`
    "mfa_devices": [],
    // MFA device used for passwordless authentication, applies to
    // `auth_method` `auth_webauthn_pwl`
    "device": null,
    // the token identifier when `auth_method` `token` was used
    "identifier": "",
    // JWT information when `auth_method` `jwt` was used
    "jwt": {},
    "source": null,
    "provider": null,
    // Certificate used for authentication
    // applies for `auth_method` `mtls`
    "certificate": {}
}

Email stage

`email_sent` (boolean)

Boolean set to true after the email from the email stage has been sent.

`email` (string)

Optionally override the email address that the email will be sent to. If not set, defaults to the email of pending_user.

Identification stage

`pending_user_identifier` (string)

If Show matched user is disabled, this key will be set to the user identifier entered by the user in the identification stage.

Invitation stage

`invitation` (Invitation object)

The invitation used with the invitation stage. When Continue flow without invitation is enabled, this may be unset.

If the invitation was single-use, this object may hold a reference to an invitation that no longer exists in the database.

`invitation_in_effect` (boolean)

A boolean value that is True when an invitation has been used.

`token` (string)

This value can be set either via Prompt data or via policy to interactively/programmatically choose an invitation.

Redirect stage

`redirect_stage_target` (string)

Set this key in an Expression Policy to override Redirect stage to force it to redirect to a certain URL or flow. This is useful when a flow requires that the redirection target be decided dynamically.

Use the format ak-flow://{slug} to use the Redirect stage in Flow mode. Any other format will result in the Redirect stage running in Static mode.

Mutual TLS Stage

`certificate` (dictionary):ak-version[2025.6]

This key is set by the Mutual TLS Stage during authentication and enrollment and contains data about the certificate supplied by the browser.

Starting with authentik 2026.11, the san key contains the certificate's Subject Alternative Names, grouped by type (for example DNSName, RFC822Name, IPAddress, or UniformResourceIdentifier). Only types present in the certificate are included.

Example:

{
    "serial_number": "1234",
    "subject": "CN=client",
    "issuer": "CN=authentik Test CA, O=authentik, OU=Self-signed",
    "fingerprint_sha256": "08:D4:A4:79:25:CA:C3:51:28:88:BB:30:C2:96:C3:44:5A:EB:18:07:84:CA:B4:75:27:74:61:19:8A:6A:AF:FC",
    "fingerprint_sha1": "5D:14:0D:5F:A2:7E:14:B0:F1:1D:6F:CD:E3:4B:81:68:71:24:1A:70",
    "san": {
        "DNSName": ["client.example.com"],
        "RFC822Name": ["[email protected]"]
    }
}

For example, to read the first email address from the certificate in an expression policy:

emails = context["flow_plan"].context["certificate"]["san"].get("RFC822Name", [])
return emails[0] if emails else None

Add Secure Apps Flows Stages Stages Account Lockdown Index (`website/docs/add-secure-apps/flows-stages/stages/account_lockdown/index.mdx`) Copy Section

title: Account Lockdown stage authentik_version: "2026.5.0" authentik_enterprise: true Copy Chapter

:::danger
This stage performs destructive actions on a user account. Ensure the flow includes appropriate warnings and confirmation steps before this stage executes.
:::

The Account Lockdown stage executes security lockdown actions on a target user account. For the feature overview and usage instructions, see Account Lockdown.

Stage behavior Copy Chapter

1. Resolves the target account from the flow query parameters (see Target user resolution)
2. Applies the configured actions to that account
3. Creates an event for the locked account
4. For self-service: if sessions are deleted, redirects to the completion flow

Stage settings Copy Chapter

:::warning
Disabling Delete sessions is not recommended as it would allow an attacker with an active session to continue using the account.
:::

Target user resolution Copy Chapter

The account lockdown API pre-plans the flow with the selected user as the flow's pending_user. The stage uses that pending_user as the account to lock.

The resolved target must be:

• a real user account
• not the anonymous user
• not an internal service account

If no valid target user can be resolved, the stage returns an invalid response.

Reason input Copy Chapter

The stage reads the lockdown reason from:

1. prompt_data.lockdown_reason
2. lockdown_reason in the flow plan context
3. an empty string if neither is set

Self-service behavior Copy Chapter

When the resolved target user is the same user who is currently authenticated and Delete sessions is enabled, the user's session is deleted during lockdown. The stage cannot continue to the next stage, so it redirects to the Completion flow.

If Delete sessions is disabled, the flow continues normally and can show its own completion stages.

The completion flow must have Authentication set to No authentication required.

Events Copy Chapter

Creates a User Write event with an account-lockdown action ID. Use Notification Rules to send alerts. To match account-lockdown events, use action user_write and query context.action_id = "account_lockdown".

{
    "action": "user_write",
    "context": {
        "action_id": "account_lockdown",
        "reason": "User-provided reason",
        "affected_user": "username"
    }
}

Usage examples Copy Chapter

Policy to show a completion stage only for administrator-triggered lockdowns Copy Section

target_user = request.context.get("pending_user")
current_user = request.http_request.user

return bool(target_user and current_user and target_user.pk != current_user.pk)

Dynamic warning message Copy Section

Prompt field with Initial value expression enabled:

target = user
current_user = http_request.user
is_self_service = bool(target and current_user and target.pk == current_user.pk)
from django.utils.html import escape

if is_self_service:
    return """<p><strong>This will immediately:</strong></p>
    <ul>
        <li>Invalidate your local authentik password</li>
        <li>Deactivate your account</li>
        <li>Terminate all sessions</li>
        <li>Revoke all tokens</li>
    </ul>"""
else:
    if target:
        return f"<p><strong>Locking down:</strong></p><p><code>{escape(target.username)}</code></p>"
    return "<p><strong>Locking down the selected account.</strong></p>"

Error handling Copy Chapter

Add Secure Apps Flows Stages Stages Authenticator Duo Index (`website/docs/add-secure-apps/flows-stages/stages/authenticator_duo/index.mdx`) Copy Section

title: Duo authenticator setup stage Copy Chapter

The Duo Authenticator Setup stage enrolls a Duo authenticator for the current user.

About the Duo authenticator setup stage Copy Chapter

This stage connects authentik to Duo and stores a Duo-backed authenticator for the user. Duo can then be used with the Authenticator Validation stage.

Configuration options Copy Chapter

• API Hostname: the Duo API hostname for your tenant.

Under Duo Auth API:

• Integration key: Duo Auth API integration key.
• Secret key: Duo Auth API secret.

Under Duo Admin API (optional):

• Integration key: optional Duo Admin API integration key, used for importing existing Duo users and authenticators.
• Secret key: optional Duo Admin API secret, used together with the Admin API integration key.
• Authenticator type name: optional friendly name shown to the user in self-service settings.
• Configuration flow: optional authenticated flow that lets users enroll this authenticator from user settings.

Flow integration Copy Chapter

Use this stage in an enrollment or user-settings flow where the user should enroll Duo.

To require Duo during authentication, add an Authenticator Validation stage to the login flow and allow the Duo device class.

Notes Copy Chapter

• Duo authenticators created through this stage are tied to the stage because authentik needs that stage's API credentials during authentication.
• Because of that link, the stage cannot be deleted while authenticators created through it still exist. Delete those authenticators first, then delete the stage.

Import existing Duo authenticators Copy Section

:::info
Due to the way the Duo API works, authentik can only automatically import existing Duo users when a Duo MFA or higher license is active.
:::

The Duo Auth API enrollment flow creates a new Duo user. If a Duo user already exists with the same username, Duo rejects the enrollment request. To use that existing Duo user in authentik, configure the optional Duo Admin API credentials on the stage and import the authenticator instead of using the enrollment flow. If the Admin API is not available, delete or rename the existing Duo user before enrolling the authenticator.

If you already have Duo users, you can import their authenticators into authentik from the Admin interface. The Duo username can be found in the Duo Admin dashboard under Users. If needed, you can also use the Duo user ID shown in the Duo Admin URL for that user.

For direct API use, the import endpoint accepts:

• duo_user_id: the Duo user's ID from the Duo admin portal
• username: the authentik username to assign the imported authenticator to

The stage_uuid in the request must be the Duo stage whose API credentials should be used.

Add Secure Apps Flows Stages Stages Authenticator Email Index (`website/docs/add-secure-apps/flows-stages/stages/authenticator_email/index.mdx`) Copy Section

title: Email authenticator setup stage authentik_version: "2025.2" Copy Chapter

The Email Authenticator Setup stage registers an email-based authenticator for the current user, enabling one-time codes to be sent via email during subsequent authentications.

About the email authenticator setup stage Copy Chapter

During enrollment, the user supplies an email address if one is not already known, then confirms ownership by entering a one-time code.

The enrolled email address can later be used with the Authenticator Validation stage.

Configuration options Copy Chapter

• Use global connection settings: use authentik's global email configuration instead of stage-specific SMTP settings.
• SMTP Host: SMTP server hostname for stage-specific email delivery.
• SMTP Port: SMTP server port.
• SMTP Username: optional SMTP username.
• SMTP Password: optional SMTP password.
• Use TLS: enable STARTTLS for the SMTP connection.
• Use SSL: enable SMTPS for the SMTP connection.
• Timeout: SMTP connection timeout in seconds.
• From address: sender address used for enrollment emails.
• Token expiry: how long the one-time code stays valid.
• Subject: subject line for the enrollment email.
• Template: email template used for the one-time code email. See Custom templates below.
• Authenticator type name: optional friendly name shown to the user in self-service settings.
• Configuration flow: optional authenticated flow that lets users enroll this authenticator from user settings.

For SMTP requirements and global email delivery settings, see Email configuration.

Custom templates Copy Chapter

This stage supports custom email templates in the same way as the Email stage. Mount your custom templates into authentik's template directory, and they will appear in the stage's Template dropdown.

For the full mounting instructions (Docker Compose and Kubernetes), a list of available template variables, and an example template, see Custom templates in the Email stage documentation.

:::info
If a custom template does not appear in the Template selector, check the worker container logs. Templates are discovered when the stage configuration form loads.
:::

Flow integration Copy Chapter

Use this stage in an enrollment or user-settings flow where the user should add an email authenticator.

To use the enrolled address during login, add an Authenticator Validation stage to the authentication flow and allow the Email device class.

Notes Copy Chapter

• Email authenticators created through this stage are tied to it, so the stage cannot be deleted while any of those authenticators still exist. Delete the authenticators first, then delete the stage.
• If Use global connection settings is enabled, configure the global email settings first. See the installation docs for Docker Compose and Kubernetes.
• This stage is separate from the general-purpose Email stage, which is used for email verification and recovery.
• If the user already has an email address on their account, authentik can use that address during enrollment instead of prompting for a new address.

Add Secure Apps Flows Stages Stages Authenticator Endpoint Gdtc Index (`website/docs/add-secure-apps/flows-stages/stages/authenticator_endpoint_gdtc/index.mdx`) Copy Section

title: Google Chrome Device Trust authenticator stage authentik_enterprise: true support_level: deprecated Copy Chapter

:::warning Deprecated
This stage is deprecated in favor of the Google Chrome connector used with the Endpoint Devices feature set.
:::

The Google Chrome Device Trust Authenticator Stage verifies a Chrome browser by using the Chrome Verified Access API.

About the Google Chrome Device Trust authenticator stage Copy Chapter

This stage validates Chrome Enterprise Device Trust signals from the user's browser. Unlike other authenticator setup stages, it does not enroll a reusable MFA device for later validation through the Authenticator Validation stage.

It was designed to integrate Chrome browsers and ChromeOS devices with authentik as the identity provider so access decisions could take device posture into account.

Typical use cases included remote-work, contractor, and BYOD environments where access should depend on the state of the browser or device in addition to the user's identity.

Configuration options Copy Chapter

• Credentials: Google service-account JSON used to access the Chrome Verified Access API.
• Authenticator type name: optional friendly name shown to the user in self-service settings.
• Configuration flow: optional authenticated flow that exposes the stage in user settings.

Flow integration Copy Chapter

Bind this stage directly into a flow where Chrome browser verification should happen.

Compared to the newer Endpoint stage, this stage is Chrome-specific and relies on the legacy Device Trust integration path.

Notes Copy Chapter

Requirements Copy Section

• Google Chrome is required.
• A Google Cloud project with the Chrome Verified Access API enabled is required.
• A service account with exported JSON credentials is required.
• Chrome Enterprise Device Trust must be configured in the Google admin side to call back into authentik.

This integration was commonly paired with context-aware access policies, for example only allowing access from devices that meet patching or compliance requirements.

Google setup outline Copy Section

The original Chrome Device Trust setup has four main steps:

1. Create a Google Cloud project and enable the Chrome Verified Access API.
2. Create a service account.
3. Export a JSON key for that service account.
4. Configure Chrome Enterprise Device Trust to call authentik at /endpoint/gdtc/chrome/.

More concretely:

1. Open the Google Cloud Console and create a new project.
2. Enable the Chrome Verified Access API in that project.
3. In IAM > Service Accounts, create a service account.
4. Generate a JSON key from the service account's Keys tab.
5. In the Google admin side, configure a new provider under Chrome browser > Connectors and point it at your authentik URL, for example https://authentik.company/endpoint/gdtc/chrome/.
6. Paste the exported JSON key into the stage's Credentials field in authentik.

Why this stage is different Copy Section

This stage verifies the current Chrome browser directly and does not create a reusable MFA enrollment that is later selected by the Authenticator Validation stage. That difference is why the newer Endpoint stage is a better long-term replacement for most deployments.

Add Secure Apps Flows Stages Stages Authenticator Sms Index (`website/docs/add-secure-apps/flows-stages/stages/authenticator_sms/index.mdx`) Copy Section

title: SMS authenticator setup stage Copy Chapter

The SMS Authenticator Setup stage enrolls an SMS-based authenticator for the current user by using either Twilio or a generic HTTP endpoint.

About the SMS authenticator setup stage Copy Chapter

This stage stores a phone number, enabling one-time codes to be sent via SMS.

In normal mode, the enrolled phone number can later be used with the Authenticator Validation stage. In verify only mode, the stage only verifies ownership of a phone number during enrollment and stores a hash instead of the number itself.

Configuration options Copy Chapter

• Provider: choose either Twilio or Generic.
• From number: sender number or identifier used for outbound SMS.
• Account SID / External API URL: for Twilio this is the account SID; for the generic provider this is the target API URL.
• Auth / token: for Twilio this is the auth token; for the generic provider this is the bearer token or basic-auth username.
• Auth password: optional password for generic basic authentication.
• Auth type: choose Basic or Bearer authentication for the generic provider.
• Verify only: verify phone ownership during enrollment without storing the plain phone number for later MFA use.
• Mapping: optional webhook mapping used to customize the payload sent to custom providers.
• Authenticator type name: optional friendly name shown to the user in self-service settings.
• Configuration flow: optional authenticated flow that lets users enroll this authenticator from user settings.

Flow integration Copy Chapter

Use this stage in an enrollment or user-settings flow where the user should add an SMS authenticator.

To require SMS during login, add an Authenticator Validation stage to the authentication flow and allow the SMS device class.

If you enable Verify only, phone numbers enrolled through this stage cannot be used by the Authenticator Validation stage.

Notes Copy Chapter

SMS authenticators created through this stage are tied to it, so the stage cannot be deleted while any of those authenticators still exist. Delete the authenticators first, then delete the stage.

Twilio Copy Section

For the Twilio provider, create a messaging service and collect the Account SID, Auth token, and a usable sender number from the Twilio console.

A typical Twilio setup looks like this:

1. Log in to the Twilio console.
2. Go to Explore Products > Messaging > Services.
3. Create a new messaging service and choose a verification-oriented use case.
4. Add a sender from the service's sender pool.
5. Copy the Account SID and Auth token into the stage configuration.

Using a property mapping, you can customize the message sent via Twilio. The mapping should return a dictionary with a message key. For example:

return {
    "message": f"This is a custom message for {request.http_request.brand.branding_title} SMS authentication. The code is {token}."
}

Useful variables in that mapping include:

• device.phone_number
• stage.from_number
• request.http_request.brand

Generic provider Copy Section

For the generic provider, authentik sends an HTTP POST request to the configured API URL. The default payload contains:

{
    "From": "<value of the From number field>",
    "To": "<the phone number of the user's device>",
    "Body": "<the token that the user needs to authenticate>",
    "Message": "<the full SMS message>"
}

Any response with status 400 or higher is treated as a failed send and blocks the user from proceeding.

You can also customize the generic-provider payload with a webhook mapping. For example:

return {
    "from": stage.from_number,
    "to": device.phone_number,
    "body": f"foo bar baz {token}",
}

Limiting phone numbers Copy Section

To control which phone numbers are accepted, collect the number in a Prompt stage and validate it with an expression policy before this stage runs. If a prompt field uses the key phone, the SMS setup stage will read that value from prompt_data instead of prompting the user again.

Example expression policy:

phone_number = regex_replace(request.context["prompt_data"]["phone"], r"\s+", "")

if phone_number.startswith("+1234"):
    return True
ak_message("Invalid phone number or missing region code")
return False

A typical flow for this looks like:

1. Create a required text prompt field with the key phone.
2. Create a Prompt stage that contains that field.
3. Bind the validation policy to the Prompt stage.
4. Bind the Prompt stage before the SMS setup stage in the enrollment flow.

Add Secure Apps Flows Stages Stages Authenticator Static Index (`website/docs/add-secure-apps/flows-stages/stages/authenticator_static/index.mdx`) Copy Section

title: Static authenticator setup stage Copy Chapter

The Static Authenticator Setup stage creates one-time backup codes for a user. These codes are typically used as a fallback when the user's primary authenticator is unavailable.

About the static authenticator setup stage Copy Chapter

This stage enrolls static backup codes for the current user and generates a set of recovery codes. Each code can be used once.

Because static codes are a device class supported by the Authenticator Validation stage, they are usually added as a backup factor rather than the primary factor.

Configuration options Copy Chapter

• Token count: how many backup codes to generate for the user.
• Token length: how long each generated code should be.
• Authenticator type name: optional friendly name shown to the user in self-service settings.
• Configuration flow: optional authenticated flow that lets users enroll this authenticator from user settings.

Flow integration Copy Chapter

Use this stage in an enrollment or user-settings flow where the user is already authenticated or otherwise identified.

To use the generated backup codes during authentication, add an Authenticator Validation stage to the login flow and allow the Static device class.

Notes Copy Chapter

• Static codes are intended as emergency or backup credentials.
• Each code is consumed after a successful use.
• Codes are displayed in hyphenated groups of four characters (for example, abcd-efgh-ijkl) to make them easier to read and type. Hyphens and spaces are ignored when a code is entered, so users can enter a code with or without them. Codes are case-sensitive.

Add Secure Apps Flows Stages Stages Authenticator Totp Index (`website/docs/add-secure-apps/flows-stages/stages/authenticator_totp/index.mdx`) Copy Section

title: TOTP authenticator setup stage Copy Chapter

The TOTP Authenticator Setup stage enrolls a time-based one-time password authenticator for the user, such as Google Authenticator, Authy, 1Password, or similar authenticator apps.

About the TOTP authenticator setup stage Copy Chapter

This stage creates a TOTP authenticator for the current user and presents a standard OTP configuration URL that authenticator apps can scan or import.

The enrolled TOTP authenticator can then be used with the Authenticator Validation stage.

Configuration options Copy Chapter

• Digits: choose whether generated codes use 6 or 8 digits.
• Authenticator type name: optional friendly name shown to the user in self-service settings.
• Configuration flow: optional authenticated flow that lets users enroll this authenticator from user settings.

Flow integration Copy Chapter

Use this stage in an enrollment or user-settings flow where the user can add a TOTP authenticator.

To require that authenticator during login, add an Authenticator Validation stage to the authentication flow and allow the TOTP device class.

Notes Copy Chapter

• Six-digit TOTP codes are the most widely compatible option.
• During enrollment, authentik uses the active brand's title as the issuer shown in the TOTP app. If you operate multiple authentik instances with the same usernames, distinct brand titles help avoid confusion in authenticator apps.

Add Secure Apps Flows Stages Stages Authenticator Validate Index (`website/docs/add-secure-apps/flows-stages/stages/authenticator_validate/index.mdx`) Copy Section

title: Authenticator validation stage Copy Chapter

The Authenticator Validation stage validates an already enrolled authenticator.

About the authenticator validation stage Copy Chapter

This stage is used during authentication after a user has already enrolled one or more authenticators with a setup stage, such as:

• Duo Authenticator Setup stage
• Email Authenticator Setup stage
• SMS Authenticator Setup stage
• Static Authenticator Setup stage
• TOTP Authenticator Setup stage
• WebAuthn / FIDO2 / Passkeys Authenticator setup stage

Configuration options Copy Chapter

• Not configured action: control what happens when the user has no compatible authenticator.
  • Skip: continue the flow without MFA.
  • Deny: deny access and end the flow.
  • Configure: inject one of the configured enrollment stages and continue after that stage succeeds.
• Configuration stages: stages that can be injected when Not configured action is set to Configure.
• Device Classes: which enrolled authenticator types can be used at this step.
• Last validation threshold: skip validation if the user has successfully used a compatible device within the configured time window.
• WebAuthn User verification: user-verification requirement for WebAuthn authentication.
• WebAuthn Hints: browser hints that influence which WebAuthn authenticator is preferred.
• WebAuthn Device type restrictions: optionally limit which WebAuthn device types are allowed.
• Email OTP throttling factor: exponential back-off factor for Email devices after failed verification attempts.
• SMS OTP throttling factor: exponential back-off factor for SMS devices after failed verification attempts.
• TOTP throttling factor: exponential back-off factor for TOTP devices after failed verification attempts.
• Static OTP throttling factor: exponential back-off factor for static recovery codes after failed verification attempts.

Flow integration Copy Chapter

This stage normally appears in authentication flows after Identification and Password, and before User Login.

If Not configured action is set to Configure, the stage can bootstrap enrollment by injecting one or more authenticator setup stages into the running flow.

Notes Copy Chapter

Require more than one MFA method Copy Section

To require users to enroll more than one MFA method and validate with each method on every login, add multiple Authenticator Validation stages to the same authentication flow.

Configure each validation stage with a different set of allowed Device Classes, and set Not configured action to Configure.

For example, to require both TOTP and WebAuthn:

1. Create a TOTP setup stage and a WebAuthn setup stage if you do not already have them.
2. Create an Authenticator Validation stage for TOTP:
   • Set Device Classes to totp.
   • Set Not configured action to Configure.
   • Set Configuration stages to your TOTP setup stage.
3. Create a second Authenticator Validation stage for WebAuthn:
   • Set Device Classes to webauthn.
   • Set Not configured action to Configure.
   • Set Configuration stages to your WebAuthn setup stage.
4. Bind both validation stages to your authentication flow in the order that users should enroll and validate them.

On first sign-in, users who do not yet have one of the required methods are prompted to configure it before the flow continues. On later sign-ins, each validation stage checks only the device classes configured on that stage.

Require at least two enrolled MFA methods of any type Copy Section

If you want to require users to enroll at least two different MFA methods, regardless of which types they choose, use an Expression Policy to count the enrolled device classes for the user.

from authentik.stages.authenticator import devices_for_user

pending_user = request.context.get("pending_user")
if not pending_user or not pending_user.pk:
    return False

device_types = {
    device.__class__.__name__.lower().replace("device", "")
    for device in devices_for_user(pending_user, confirmed=True)
}

return len(device_types) >= 2

Bind the policy to the flow or stage binding that controls whether the user can continue without enrolling another authenticator.

If you select multiple Configuration stages on a single validation stage, users can choose which authenticator to enroll for that requirement.

Less-frequent validation Copy Section

Set Last validation threshold to a non-zero value to avoid prompting on every login. Any compatible authenticator within the allowed classes can satisfy that threshold.

For code-based authenticators such as TOTP, Static, and SMS, values below seconds=30 are not useful because those authenticators do not store exact validation timestamps at sub-window precision.

Passwordless authentication Copy Section

:::caution
Firefox has known issues with some Touch ID and platform-authenticator flows. See Mozilla bug 1536482 for one longstanding example.
:::

Passwordless authentication in this stage currently relies on WebAuthn authenticators.

To build a dedicated passwordless flow:

1. Create an Authentication flow.
2. Add an Authenticator Validation stage that allows the WebAuthn device class.
3. Add any extra verification stages you still require.
4. End the flow with a User Login stage.

If you want users to choose a passkey directly from the browser's autofill UI on the identification screen, configure Passkey autofill in the Identification stage. This requires a discoverable credential, also known as a resident key.

Users can either access the passwordless flow directly or reach it through an Identification stage's Passwordless flow link.

WebAuthn hints Copy Section

:::info
Hints are advisory and browsers can ignore them based on available authenticators or platform capabilities.
:::

Optional hints can guide the browser toward a preferred authenticator type during WebAuthn authentication:

• Security key: prefer a portable FIDO2 device such as a YubiKey.
• Client device: prefer a built-in platform authenticator such as Touch ID or Windows Hello.
• Hybrid: prefer a platform authenticator on a nearby mobile device, typically through a QR code.

The order of selected hints matters. For example, selecting Security key before Hybrid asks the browser to prefer security keys before hybrid authentication.

Automatic authenticator selection Copy Section

If the user has multiple compatible authenticators, authentik lets them choose one. After a successful validation, the last-used authenticator is automatically preferred the next time this stage runs.

WebAuthn authenticator type restrictions Copy Section

WebAuthn Device type restrictions are an allowlist for already-enrolled WebAuthn authenticators. When no device types are selected, any enrolled WebAuthn authenticator that matches the stage's Device Classes can be used. When one or more device types are selected, authentik only allows WebAuthn authentication from enrolled devices whose recorded device type matches one of the selected entries.

The available device-type entries are populated from the FIDO Alliance Metadata Service data and additional AAGUID metadata bundled with the authentik release. This is useful when you need to limit authentication to specific hardware families or compliance profiles.

These restrictions only apply to WebAuthn devices that have a stored device type. Devices enrolled in authentik 2024.4 or later store this information when the authenticator returns a known AAGUID. Older WebAuthn enrollments or devices without a stored type cannot be matched by this filter. To enforce a device-type policy for enrollment and later authentication, configure the same allowlist on the WebAuthn / FIDO2 / Passkeys Authenticator setup stage and have users re-enroll devices that predate stored device types.

Throttling Copy Section

To slow down brute-force attacks against code-based authentication methods, the stage applies an exponential back-off to each device after a failed verification attempt. The delay required between verification attempts grows with each successive failure:

delay_seconds = factor * 2^(n - 1)

In this formula, factor is the per-device-class throttling factor configured on the stage and n is the number of successive failures on that device.

For example, with the default factor of 1, the required delay between attempts is 1, 2, 4, 8, 16, ... seconds. With a factor of 0.5, it is 0.5, 1, 2, 4, ... seconds. A successful verification resets the counter.

A factor of 0 disables throttling for that device class.

WebAuthn and Duo devices are not throttled.

Authentication logging Copy Section

When passwordless authentication succeeds through this stage, authentik records the method as auth_webauthn_pwl in flow context and related events.

Example event context:

{
    "auth_method": "auth_webauthn_pwl",
    "auth_method_args": {
        "device": {
            "pk": 1,
            "app": "authentik_stages_authenticator_webauthn",
            "name": "test device",
            "model_name": "webauthndevice"
        }
    }
}

Add Secure Apps Flows Stages Stages Authenticator Webauthn Index (`website/docs/add-secure-apps/flows-stages/stages/authenticator_webauthn/index.mdx`) Copy Section

title: WebAuthn / FIDO2 / Passkeys authenticator setup stage Copy Chapter

The WebAuthn / FIDO2 / Passkeys Authenticator setup stage enrolls a WebAuthn authenticator for the current user.

About the WebAuthn authenticator setup stage Copy Chapter

This stage supports common WebAuthn authenticator types, including:

• security keys such as YubiKey or Google Titan
• platform authenticators such as Windows Hello, Touch ID, or Face ID
• passkeys stored by operating systems or password managers

Enrolled authenticators can later be used with the Authenticator Validation stage.

Configuration options Copy Chapter

• User verification: require, prefer, or discourage built-in user verification during registration.
• Resident key requirement: control whether the authenticator should create a discoverable credential.
• Authenticator Attachment: restrict enrollment to platform authenticators, cross-platform authenticators, or leave it unrestricted.
• Hints: browser hints that influence which authenticator is preferred during enrollment.
• Device type restrictions: limit enrollment to specific WebAuthn device types.
• Maximum registration attempts: maximum number of failed registration attempts before the stage denies access. A value of 0 disables the limit.
• Authenticator type name: optional friendly name shown to the user in self-service settings.
• Configuration flow: optional authenticated flow that lets users enroll this authenticator from user settings.

Flow integration Copy Chapter

Use this stage in an enrollment or user-settings flow where the user should register a passkey or hardware key.

To require those devices during login, add an Authenticator Validation stage to the authentication flow and allow the WebAuthn device class.

If you want passkey autofill on the login form itself, configure the Identification stage to reference a WebAuthn-capable Authenticator Validation stage.

Notes Copy Chapter

User verification Copy Section

User verification controls whether authentik requires, prefers, or discourages user verification on the authenticator itself. On platform authenticators such as Windows Hello, that can determine whether a PIN or biometric check is required.

Resident key requirement Copy Section

For passkey-based passwordless login, set Resident key requirement to Preferred or Required so the created credential is discoverable.

Authenticator attachment Copy Section

Use Authenticator Attachment when the flow should prefer either removable authenticators such as YubiKeys or built-in authenticators such as Touch ID, Windows Hello, or password-manager passkeys.

Signature algorithms Copy Section

Registration accepts EdDSA, ES256, and RS256 credentials, and the post-quantum ML-DSA-44, ML-DSA-65, and ML-DSA-87 algorithms (FIPS 204). Authenticators pick the first algorithm they support, so ML-DSA is only used by devices that offer nothing else. No shipping authenticator supports ML-DSA yet.

This controls the authenticatorAttachment parameter sent to the browser during WebAuthn registration:

• No preference is sent: the browser can offer any available authenticator.
• Platform: prefer a non-removable authenticator built into the device, such as Touch ID, Face ID, or Windows Hello.
• Cross-platform: prefer a roaming authenticator, such as a YubiKey or Google Titan.

If WebAuthn hints are configured and this option is left unset, authentik infers an attachment value from the selected hints for backward compatibility with older browsers.

WebAuthn hints Copy Section

:::info
Hints are advisory and browsers can ignore them based on available authenticators or platform capabilities.
:::

Optional hints can guide the browser toward a preferred authenticator type during registration:

• Security key: prefer registering a credential with a portable FIDO2 device such as a YubiKey.
• Client device: prefer registering a credential with a built-in platform authenticator such as Touch ID or Windows Hello.
• Hybrid: prefer registering a credential using a platform authenticator on a nearby mobile device, typically through a QR code.

The order of selected hints matters. For example, selecting Security key before Hybrid asks the browser to prefer security keys before hybrid registration.

For backward compatibility with older browsers that do not support hints, authentik automatically infers the authenticatorAttachment parameter from the selected hints when Authenticator Attachment is not explicitly set:

• Only Security key and/or Hybrid hints: cross-platform
• Only Client device hints: platform
• If both client-device and cross-platform hints are selected, no value is inferred

Duplicate devices Copy Section

The Prevent duplicate devices option was removed in 2026.8. It compared attestation certificates, which manufacturers share across entire production batches, so it rejected legitimate enrollments of a second security key. No configuration replaces it, and no action is needed when upgrading.

Device type restrictions Copy Section

Device type restrictions are an allowlist for WebAuthn registration. When no device types are selected, authentik allows any WebAuthn authenticator that the browser and authenticator can register. When one or more device types are selected, authentik only allows registration when the authenticator returns an AAGUID that matches one of the selected entries.

The available device-type entries are populated from the FIDO Alliance Metadata Service data and additional AAGUID metadata bundled with the authentik release. This lets you restrict enrollment to specific hardware families or passkey providers listed in that metadata.

If you select specific device types, newly added metadata entries are not allowed automatically. Review this allowlist after authentik upgrades if your compliance policy should include newly recognized authenticators.

authentik also includes the special device-type authentik: Unknown devices. Select it only when you want to allow authenticators that return an AAGUID that is not present in authentik's device-type metadata. Authenticators that do not return an AAGUID cannot satisfy a device-type restriction.

Add Secure Apps Flows Stages Stages Captcha Index (`website/docs/add-secure-apps/flows-stages/stages/captcha/index.mdx`) Copy Section

title: Captcha stage Copy Chapter

The Captcha stage adds CAPTCHA verification to a flow by using Google reCAPTCHA or compatible alternatives like hCaptcha, Cloudflare Turnstile, and Cap.

About the Captcha stage Copy Chapter

This stage verifies that the current interaction appears human before the flow continues.

It can either be bound to a flow or embedded inside the Identification stage by setting the Identification stage's Captcha stage option.

Configuration options Copy Chapter

• Public Key: CAPTCHA site key.
• Private Key: CAPTCHA secret key.
• Interactive: enable an interactive CAPTCHA widget instead of score-based verification.
• Score Minimum Threshold: minimum accepted score for score-based providers.
• Score Maximum Threshold: maximum accepted score for score-based providers.
• Error on Invalid Score: show an error immediately when the score is outside the configured threshold. If disabled, the flow continues and policies can inspect the result from context.
• JavaScript URL: JavaScript loader URL for the provider.
• API Verification URL: verification endpoint URL for the provider.
• Request Content Type: content type used when authentik verifies the CAPTCHA token with the provider.

Flow integration Copy Chapter

Use this stage anywhere a flow should require a CAPTCHA check, especially in enrollment, recovery, or other public-facing flows.

If you embed it in an Identification stage, configure the CAPTCHA provider for invisible or background use.

:::note CAPTCHA and passkey authentication
The CAPTCHA stage does not run when the user completes an Identification stage with a passkey, because authentik completes identification immediately after a successful WebAuthn check. For more information about this behavior and its security rationale, see CAPTCHA and passkey authentication.
:::

Notes Copy Chapter

Google reCAPTCHA Copy Section

:::note Supported versions
Google reCAPTCHA Enterprise, reCAPTCHA v2, and reCAPTCHA v3 are all supported.
:::

Use the keys from https://www.google.com/recaptcha/admin.

Recommended defaults for reCAPTCHA:

• Interactive: disabled for score-based reCAPTCHA
• Score Minimum Threshold: 0.5
• Score Maximum Threshold: 1.0
• JavaScript URL: https://www.recaptcha.net/recaptcha/api.js
• API Verification URL: https://www.recaptcha.net/recaptcha/api/siteverify

hCaptcha Copy Section

See https://docs.hcaptcha.com/switch.

Recommended values:

• Interactive: enabled
• JavaScript URL: https://js.hcaptcha.com/1/api.js
• API Verification URL: https://api.hcaptcha.com/siteverify

Score thresholds only apply to hCaptcha Enterprise.

Cap Copy Section

Cap is a self-hostable CAPTCHA server that uses proof-of-work challenges.

See https://trycap.dev/guide/.

authentik supports Cap's default widget. The floating widget is not supported.

Recommended values:

• Public Key: public Cap endpoint for the site key path, for example https://cap.example.com/site-key/
• Private Key: Cap secret key
• Interactive: enabled
• JavaScript URL: self-hosted Cap widget asset, for example https://cap.example.com/assets/widget.js. If you use a CDN, pin a reviewed release such as https://cdn.jsdelivr.net/npm/cap-widget@<version> instead of the unversioned package URL. See Cap releases.
• API Verification URL: Cap verification endpoint, for example https://cap.example.com/site-key/siteverify
• Request Content Type: JSON

Cap does not use score thresholds.

Cloudflare Turnstile Copy Section

See https://developers.cloudflare.com/turnstile/get-started/migrating-from-recaptcha.

Recommended values:

• Public Key: Turnstile site key
• Private Key: Turnstile secret key
• Interactive: enable when using invisible or managed Turnstile modes
• JavaScript URL: https://challenges.cloudflare.com/turnstile/v0/api.js
• API Verification URL: https://challenges.cloudflare.com/turnstile/v0/siteverify

Turnstile does not use score thresholds.

Cloudflare Turnstile setup flow Copy Section

If you are configuring Turnstile from scratch:

1. Create the Turnstile widget in Cloudflare.
2. Copy the Site Key into Public Key.
3. Copy the Secret Key into Private Key.
4. Enable Interactive if the Turnstile widget is configured as Invisible or Managed.
5. Leave score thresholds at their defaults because Turnstile does not use them.

Add Secure Apps Flows Stages Stages Consent Index (`website/docs/add-secure-apps/flows-stages/stages/consent/index.mdx`) Copy Section

title: Consent stage Copy Chapter

The Consent stage asks the user to approve sharing data with an application or relying party.

About the consent stage Copy Chapter

This stage is commonly used in authorization flows, where a user should explicitly consent before authentik shares profile data or other claims with an application.

The default default-provider-authorization-explicit-consent flow already includes a Consent stage.

A typical use case is prompting the user to allow authentik to share profile data such as name, email address, or avatar with the application they are signing in to.

Configuration options Copy Chapter

• Mode: control how long a granted consent remains valid.
  • Always require consent: prompt every time.
  • Consent given lasts indefinitely: store consent without expiration.
  • Consent expires: store consent until the configured expiry time.
• Consent expires in: expiration offset used when the mode is set to expiring consent.

Flow integration Copy Chapter

Bind this stage into an authorization flow anywhere the user should see the consent prompt.

If you use the default explicit-consent authorization flow, the stage is already present and usually does not need to be added manually.

Notes Copy Chapter

Default flow Copy Section

If you are using the default default-provider-authorization-explicit-consent flow, you usually do not need to add a Consent stage manually because it is already present.

If you are building a custom authorization flow, the usual sequence is:

1. Create the Consent stage.
2. Bind it into the authorization flow.
3. Optionally bind an expression policy to the stage binding if the consent text should be customized.

If you are adding the stage from scratch in the Admin interface, the typical workflow is:

1. Go to Flows and Stages > Stages and create a Consent Stage.
2. Set the Mode and, if needed, the expiry duration.
3. Open the target authorization flow.
4. Add the Consent stage to that flow's stage bindings.

Custom consent text Copy Section

You can customize the text shown on the consent screen by setting the consent_header key in flow context before the stage runs, for example from an expression policy:

request.context["flow_plan"].context["consent_header"] = (
    "Are you OK with your IdP provider sharing your user identification data "
    "with the application?"
)
return True

Bind that policy to the Consent stage binding inside the authorization flow where you want the wording to change.

The binding workflow is:

1. Open the authorization flow that contains the Consent stage.
2. Go to Stage Bindings.
3. Expand the Consent stage binding that should use the custom text.
4. Bind the expression policy to that stage binding.

Stored consent Copy Section

When consent is stored, authentik keeps track of the user, the application, and the granted permissions so later requests can reuse or re-prompt according to the selected mode.

Users can check their past consent approvals via the User Settings menu.

Add Secure Apps Flows Stages Stages Deny Index (`website/docs/add-secure-apps/flows-stages/stages/deny/index.mdx`) Copy Section

title: Deny stage Copy Chapter

The Deny stage stops the current flow immediately.

About the deny stage Copy Chapter

Use this stage when the flow should end with access denied, including cases where the user is not signed in yet and group-based permissions are not available.

Configuration options Copy Chapter

This stage has no stage-specific configuration options.

Flow integration Copy Chapter

Bind this stage where a flow should stop after a policy or earlier stage determines that the user must not continue.

Notes Copy Chapter

:::caution
To use this stage effectively, make sure Evaluate when flow is planned is disabled on the stage binding. See Planning and stage policies.
:::

If the binding is evaluated during flow planning, the denial can happen earlier than intended and skip the checks that were meant to decide whether the user should be denied.

Example: block a known IP range Copy Section

One common use case is to bind a Deny stage to an expression policy that blocks requests from a specific IP range.

For example:

1. Create a Deny stage.
2. Create an Expression policy with logic such as:

from ipaddress import ip_network

return ak_client_ip in ip_network("203.0.113.0/24")

3. Bind that policy to the Deny stage in the flow.

When the policy passes, the Deny stage runs and the flow stops immediately.

Example: Block password recovery for inactive users Copy Section

Account deactivation prevents authentication, but it does not automatically prevent recovery stages from sending email or changing a password. To stop inactive users before those actions occur:

1. Add a Deny stage to the recovery flow after the Identification stage and before the Email stage.

2. Create an Expression policy with the following expression:

   python Copy

   pending_user = request.context.get("pending_user")
   
   return bool(
       pending_user
       and pending_user.pk
       and not pending_user.is_active
   )

3. Bind the policy to the Deny stage binding.

4. On the Deny stage binding, disable Evaluate when flow is planned and enable Evaluate when stage is run. The policy must run after the Identification stage adds pending_user to the flow context.

The Deny stage runs only when the identified user exists and is inactive. Active users and placeholder users that represent unknown identifiers skip the Deny stage.

:::danger Account state disclosure
The Deny stage produces a different response for an inactive account than the Email sent. challenge that the Email stage displays for unknown and active accounts. An attacker can use this difference to determine that an account exists or is inactive.

Use this configuration only if disclosing account state is acceptable. A Deny stage cannot both stop recovery and preserve the Email stage's indistinguishable response.
:::

Add Secure Apps Flows Stages Stages Email Index (`website/docs/add-secure-apps/flows-stages/stages/email/index.mdx`) Copy Section

title: Email stage Copy Chapter

The Email stage sends a verification or action email from within a flow.

About the email stage Copy Chapter

This stage is used for email verification, account recovery, invitations, and similar flow steps where authentik should send a tokenized link or message to a user.

The email is normally sent to the current pending_user, but the target address can be overridden from flow context.

When an email cannot be delivered immediately, authentik retries delivery through its background worker.

Configuration options Copy Chapter

• Use global connection settings: use authentik's global email configuration instead of stage-specific SMTP settings.
• SMTP Host: SMTP server hostname for stage-specific delivery.
• SMTP Port: SMTP server port.
• SMTP Username: optional SMTP username.
• SMTP Password: optional SMTP password.
• Use TLS: enable STARTTLS for the SMTP connection.
• Use SSL: enable SMTPS for the SMTP connection.
• Timeout: SMTP connection timeout in seconds.
• From address: sender address used for flow emails.
• Account Recovery Max Attempts: maximum number of recovery emails allowed in the configured time window.
• Account Recovery Cache Timeout: time window used for recovery-email rate limiting.
• Activate user on success: set the identified user's is_active state to True after they return with a valid email token. In a recovery flow, this setting allows an inactive user to reactivate their account through email verification. Disable this setting if reactivation must remain an administrative action. Disabling it does not prevent the user from receiving a recovery email or changing their password.
• Token expiry: how long the email token remains valid.
• Subject: subject line used for the email.
• Template: template used to render the email body.

Flow integration Copy Chapter

Use this stage in recovery, enrollment, verification, or invitation flows where an email should be sent before the flow continues.

By default, the message goes to the current pending_user. To override the destination, set email in the flow plan context before the stage runs:

request.context["flow_plan"].context["email"] = "[email protected]"
return True

You can also source the address from prompt data or another user attribute:

request.context["flow_plan"].context["email"] = request.context["prompt_data"]["email"]
return True

request.context["flow_plan"].context["email"] = request.context["pending_user"].attributes.get("otherEmail")
return True

Notes Copy Chapter

Rate limiting Copy Section

The recovery rate-limiting fields only affect recovery-style email sends. They limit how many recent attempts a user can trigger within the configured time window.

Recovery and account enumeration Copy Section

When an Identification stage does not find a user, it can create a placeholder user if Pretend user exists is enabled. In a recovery flow, the Email stage shows the same Email sent. challenge for this placeholder user without sending an email or creating a recovery token. This behavior prevents the recovery response from disclosing whether the identifier belongs to an account.

An existing inactive user is not a placeholder user. By default, the Email stage sends that user a recovery email and creates a recovery token. Deactivating an account prevents authentication, but it does not automatically prevent the user from recovering their account.

You can use a policy bound to a Deny stage to block inactive users before the Email stage. However, the denial response differs from the response for an unknown or active account and can disclose whether an account exists or is inactive. For configuration details and this security tradeoff, see Block password recovery for inactive users.

Custom templates Copy Section

You can provide custom email templates.

:::info
You can also add a matching .txt file next to the .html file to send multipart text and HTML emails.
:::

import TabItem from "@theme/TabItem";
import Tabs from "@theme/Tabs";

<Tabs
defaultValue="docker-compose"
values={[
{label: 'Docker Compose', value: 'docker-compose'},
{label: 'Kubernetes', value: 'kubernetes'},
]}>

Place custom templates in the custom-templates directory next to your Compose file. The template becomes selectable in the Email stage configuration.

apiVersion: v1
kind: ConfigMap
metadata:
    name: authentik-templates
    namespace: authentik
data:
    my-template.html: |
        <tr>...

volumes:
    - name: email-templates
      configMap:
          name: authentik-templates
volumeMounts:
    - name: email-templates
      mountPath: /templates

If a custom template does not appear in the selector, check the worker logs.

Template variables Copy Section

Templates are rendered with Django's templating engine. Common variables include:

• url: the full URL the user should open
• user: the pending user
• expires: when the token expires

These templates are rendered with Django's templating engine, so you can also use standard template inheritance and translation tags.

Example template Copy Section

Templates can extend the base email template and use standard Django template tags. For example:

:::info
Each Django {% ... %} tag must stay on one line; a tag wrapped across lines won't parse.
:::

/* Detailed source-code truncated for AI context efficiency. */

Add Secure Apps Flows Stages Stages Endpoint Index (`website/docs/add-secure-apps/flows-stages/stages/endpoint/index.mdx`) Copy Section

title: Endpoint stage Copy Chapter

The Endpoint stage checks whether the current browser or device is known to authentik's Endpoint Devices system and injects device facts into flow context.

About the endpoint stage Copy Chapter

This stage integrates with Endpoint Devices. It can associate the current session with a managed endpoint and make device facts available to policies and later stages.

Configuration options Copy Chapter

• Connector: which endpoint connector should be used to gather device information.
• Mode: whether endpoint verification is optional or required.

Flow integration Copy Chapter

Use this stage in authentication or authorization flows where device posture should influence access decisions.

The device facts gathered by this stage can then be consumed by policies or by later flow logic.

Notes Copy Chapter

• In required mode, the flow fails if the device cannot be verified.
• In optional mode, authentik attempts verification and can continue without attaching a device if verification does not complete in time.

Add Secure Apps Flows Stages Stages Identification Index (`website/docs/add-secure-apps/flows-stages/stages/identification/index.mdx`) Copy Section

title: Identification stage Copy Chapter

The Identification stage is the primary user-identification step in most authentik login flows.

About the identification stage Copy Chapter

This stage lets the user identify themselves by username, email address, UPN, or external source. You can also embed password entry, CAPTCHA verification, and passkey autofill directly into the identification step.

Configuration options Copy Chapter

• User Fields: which identifiers the user can enter.
  • Username
  • Email
  • UPN
• Password stage: optional Password stage to render inline instead of as a separate step.
• Captcha stage: optional Captcha stage to run as part of identification.
• WebAuthn Authenticator Validation Stage: optional Authenticator Validation stage used for passkey autofill.
• Case-insensitive matching: match identifiers regardless of case. If two users have usernames that differ only by case, only one of them is matched. To prevent such usernames, see Ensure unique usernames regardless of case.
• Show matched user: display the matched user's username and avatar after a valid identifier is entered.
• Pretend user exists: continue even when the entered identifier does not match a real user.
• Enable remember me on this device: allow the browser to remember the entered username and jump directly to password entry later.
• Enrollment flow: optional flow linked as a sign-up path.
• Recovery flow: optional flow linked as a recovery path.
• Passwordless flow: optional flow linked as a dedicated passwordless sign-in path.
• Sources: which OAuth or SAML sources should be shown.
• Show source labels: show labels in addition to source icons.

Flow integration Copy Chapter

This stage usually appears first in authentication and recovery flows.

• If Password stage is configured here, do not also bind that Password stage separately in the same flow.
• If Captcha stage is configured here, do not also bind that Captcha stage separately in the same flow.
• If no user fields are selected, the stage acts as a source-only entry point.

Notes Copy Chapter

User fields Copy Section

If no user fields are selected, only the configured sources are shown.

For UPN, authentik matches against the upn attribute on the user, which is commonly populated from an LDAP source.

Password and CAPTCHA embedding Copy Section

If you set a Password stage here, the password prompt appears on the same step as identification instead of as a later stage.

If you set a Captcha stage here, configure that CAPTCHA for invisible or background use so it renders correctly inside the identification form.

Pretend user exists Copy Section

When enabled, invalid identifiers still let the flow continue as long as the format is valid for the selected field type. Stages such as Password and Email are aware of this behavior and handle the synthetic pending user safely.

Source behavior Copy Section

Selected OAuth and SAML sources are shown below the local identification form. If no user fields are selected and exactly one source is configured, authentik can redirect to that source automatically as long as Passwordless flow is not configured.

By default, sources are shown by icon only. Enable Show source labels if the source name should be shown alongside the icon.

Sources can also be marked as Promoted in their source configuration. Promoted sources are shown as prominent full-width buttons on the login page instead of small icon buttons.

Linked flows Copy Section

The Enrollment flow and Recovery flow settings control the links shown below the identification form. The passwordless flow setting adds a direct link to a separate passwordless authentication flow.

When Enable remember me on this device is enabled, authentik can store the username locally and jump to the password field on later visits. Users can still select Not you? to enter a different username or disable the remembered value.

Passkey autofill (WebAuthn conditional UI):ak-version[2025.12] Copy Section

When configured, the Identification stage can offer passkey login directly from the browser's passkey or autofill UI without requiring the user to type a username first.

authentik automatically falls back to the normal identification flow when passkey autofill is not available.

CAPTCHA and passkey authentication Copy Section

When a user authenticates with a passkey through the Identification stage's WebAuthn configuration, authentik completes the stage immediately after the WebAuthn check. It does not run a CAPTCHA that is configured on the Identification stage, including an interactive CAPTCHA. This is intentional: CAPTCHA protects primarily against bots that guess, reuse, or vary credentials, while WebAuthn uses a cryptographic challenge and does not expose those attack paths. Skipping the CAPTCHA does not reduce protection against credential-guessing attacks and avoids an unnecessary challenge for passkey users.

If you need to reduce the impact of requests that consume resources during authentication, use rate limiting or similar controls in your reverse proxy configuration instead of relying on a CAPTCHA after a successful WebAuthn check.

Requirements

• HTTPS is required except on localhost.
• The browser must support WebAuthn conditional mediation.
• The user must have a compatible discoverable credential, also known as a resident key.
• The user must access authentik on the same hostname the passkey was created for.

Configuration

1. Create or edit an Authenticator Validation stage that allows the WebAuthn device class.
2. Set the Identification stage's WebAuthn Authenticator Validation Stage to that stage.
3. Make sure users have already enrolled a WebAuthn authenticator, for example with the WebAuthn / FIDO2 / Passkeys Authenticator setup stage.

If the user has multiple passkeys, the browser shows its own picker. In the default authentication flow, authentik skips the MFA validation stage after a passkey login with an expression policy; adjust that policy if you still want a second factor after passkey login.

Troubleshooting

• If no passkey prompt appears, check HTTPS, browser support, and that the validation stage is configured. The browser normally triggers the passkey suggestion when the user focuses the username field.
• If no passkey prompt appears, make sure the login page is not embedded in an iframe because some browsers block conditional UI outside top-level browsing contexts.
• If the prompt appears but falls back to username/password, check that the referenced validation stage allows WebAuthn and that the user has a valid enrolled authenticator.

Add Secure Apps Flows Stages Stages Invitation Index (`website/docs/add-secure-apps/flows-stages/stages/invitation/index.mdx`) Copy Section

title: Invitation stage Copy Chapter