How to Integrate Wazuh with Authentik

As security teams deploy more infrastructure and give more users access to security platforms, managing separate credentials for every application quickly becomes inefficient and difficult to secure. Single Sign-On (SSO) addresses this problem by allowing users to authenticate through a centralized identity provider and then access supported applications without maintaining separate login credentials. This is where a Wazuh Authentik integration can be useful.

Wazuh is an open-source security platform that provides capabilities including endpoint monitoring, threat detection, log analysis, vulnerability detection, and security configuration assessment.

Authentik is an open-source identity provider that can centralize authentication and provide protocols such as OpenID Connect (OIDC) and SAML for applications.

When integrated, Authentik can act as the identity provider for the Wazuh environment, allowing users to authenticate through a centralized authentication system rather than relying solely on locally managed credentials.

Depending on the configuration, this can also support centralized user lifecycle management, group-based access decisions, multi-factor authentication, and consistent authentication policies across multiple applications.

What Wazuh and Authentik Are

Wazuh is an open-source cybersecurity platform commonly used for security monitoring and detection.

A typical Wazuh deployment includes components such as the Wazuh server, Wazuh indexer, and Wazuh Dashboard.

The Dashboard provides the web interface through which authorized users can investigate alerts, review security events, manage agents, and interact with other parts of the platform.

Authentik is an identity provider and access-management platform designed to centralize authentication for applications and services.

It can provide an authentication layer between users and applications while supporting identity protocols such as OIDC and SAML.

In a Wazuh Authentik deployment, these systems have distinct responsibilities:

• Authentik verifies the identity of the user.
• Wazuh receives the authenticated identity and determines what that user is allowed to access.
• The Wazuh Dashboard provides the application entry point and participates in the authentication flow.

This separation is important because authentication and authorization are related but different security functions.

Successfully proving who a user is does not automatically determine what that user should be permitted to do inside Wazuh.

The distinction between authentication and access permissions is covered in the Mastering Wazuh Security: The Complete Access Control Guide.

What Wazuh Authentik Integration Provides

Integrating Wazuh with Authentik can provide a centralized authentication workflow for Wazuh users.

Instead of creating and maintaining separate credentials for every user directly within the Wazuh environment, administrators can use Authentik as part of the login process.

Depending on the architecture and identity configuration, the integration can provide:

• Centralized user authentication
• Single Sign-On for Wazuh users
• Multi-factor authentication policies enforced by Authentik
• Centralized user lifecycle management
• Integration with existing identity sources
• Group or attribute information that can support access-control decisions
• A more consistent authentication experience across multiple internal applications

For example, a security analyst could navigate to the Wazuh Dashboard and be redirected to Authentik for authentication.

After Authentik verifies the user’s identity, the user is returned to the Wazuh environment with the identity information required to complete the login process.

The exact permissions available after login depend on the Wazuh authorization and role configuration.

For a broader overview of configuring SSO in the platform, see The Complete Wazuh Single Sign-On (SSO) Guide.

Why Use Authentik as an Identity Provider for Wazuh

Authentik can be particularly attractive for organizations that want an open-source and self-hosted identity provider.

It allows administrators to centralize authentication policies rather than managing authentication independently across every application.

Using Authentik as the identity provider for Wazuh can also simplify operational management.

User onboarding and offboarding can be handled centrally, authentication policies can be standardized, and additional security controls such as multi-factor authentication can be enforced at the identity-provider layer.

From a security architecture perspective, centralizing identity management can also reduce the number of separate credential stores administrators must manage.

However, centralization also makes the identity provider an important part of the security boundary, so Authentik availability, certificate management, administrative access, and recovery procedures should be considered carefully.

The integration is especially useful when Authentik already serves as the identity provider for other self-hosted services.

Wazuh can then become part of an existing SSO ecosystem rather than introducing another isolated authentication system.

Overview of the Integration Process

At a high level, integrating Wazuh with Authentik involves configuring both sides of the authentication relationship.

The process generally includes the following stages:

1. Confirm that the Wazuh environment is accessible through a stable URL.
2. Ensure that Authentik is deployed and accessible through its own URL.
3. Configure HTTPS and the certificates required to establish trusted communication.
4. Create an OIDC application or provider configuration in Authentik.
5. Configure the Wazuh authentication layer with the Authentik identity-provider details.
6. Configure redirect or callback URLs.
7. Define the identity claims and group information that should be provided during authentication.
8. Map authenticated users or groups to the appropriate Wazuh permissions where required.
9. Test the complete login flow with a non-administrative account before enforcing the configuration for all users.

The OIDC configuration typically involves exchanging several pieces of information between the two systems, including a client identifier, client secret, issuer or discovery information, redirect URI, and requested scopes.

For a more protocol-focused walkthrough, see How to Configure Wazuh OIDC.

Wazuh Authentik SSO Architecture

A simplified Wazuh Authentik architecture looks like this:

User → Wazuh Dashboard → Authentik → Wazuh authentication and authorization

The actual sequence generally works as follows:

1. A user attempts to access the Wazuh Dashboard.
2. The authentication workflow redirects the user to Authentik.
3. Authentik authenticates the user according to its configured policies.
4. Authentik may require additional verification, such as multi-factor authentication.
5. After successful authentication, Authentik returns identity information through the configured OIDC flow.
6. The Wazuh environment validates the authentication response.
7. Wazuh applies the appropriate authorization and role-based access controls.
8. The user receives access to the resources permitted by their assigned permissions.

This architecture separates the responsibility for identity verification from the responsibility for access control.

Authentik determines whether the user has successfully authenticated, while the Wazuh security configuration determines what that authenticated identity can do.

Documentation:

• Wazuh documentation
• Authentik documentation

For more information about assigning permissions after authentication, see How to Configure Wazuh RBAC.

For a full guide on Wazuh SSO and authentication, see The Complete Wazuh Single Sign-On (SSO) Guide.

What Is Wazuh Authentik Integration?

Wazuh Authentik integration is the process of connecting the Wazuh authentication workflow with Authentik as an external identity provider.

The goal is to allow users to authenticate through Authentik using a standardized identity protocol, such as OpenID Connect, while continuing to use Wazuh for security monitoring and access control.

Rather than treating the integration as a simple login replacement, it is more accurate to view it as an identity federation architecture.

Authentik becomes responsible for authenticating users, while Wazuh consumes the resulting identity information and applies its own authorization controls.

How Wazuh Authentication Works

Wazuh deployments can use different authentication approaches depending on the deployment architecture and version.

Local authentication can involve users and credentials managed within the security stack, while federated authentication allows an external identity provider to participate in the login process.

When external authentication is configured, a user does not necessarily authenticate directly against a Wazuh-managed password database.

Instead, the authentication flow can redirect the user to the configured identity provider.

The external identity provider verifies the user’s identity and returns the information required by the relying application to establish an authenticated session.

This approach provides a clearer separation of responsibilities:

• Identity provider: Authenticates the user.
• Application or relying party: Consumes the authentication result.
• Wazuh authorization layer: Determines the user’s access permissions.

See How to Configure Wazuh SSO for a broader explanation of the available Wazuh single sign-on architecture.

What Authentik Provides

Authentik provides the identity and authentication services required to connect users with applications.

Administrators can create applications, configure identity providers, define authentication flows, manage users and groups, and control how identity information is delivered to relying applications.

For a Wazuh integration, Authentik can provide information such as:

• User identity
• Username
• Email address
• Group membership
• Authentication status
• Additional claims or attributes, depending on configuration

Authentik can also act as an identity hub by connecting to other identity sources.

This can allow an organization to centralize its authentication architecture while still maintaining users in an upstream directory or identity system.

The important configuration task is ensuring that the identity information Authentik sends matches what the Wazuh authentication and authorization configuration expects.

Wazuh Dashboard and Authentik Authentication Flow

The Wazuh Dashboard is typically the user’s entry point into the platform.

When external authentication is configured, the login workflow can involve a redirect between the Dashboard environment and Authentik.

A simplified flow is:

1. User accesses the Wazuh Dashboard

The user navigates to the configured Wazuh Dashboard URL.

2. The authentication process begins

Instead of completing authentication only with local credentials, the user is directed to the external identity provider.

3. Authentik authenticates the user

Authentik applies its configured authentication flow. This might include a username and password, multi-factor authentication, or another configured authentication mechanism.

4. Authentik returns the user to the application

After successful authentication, Authentik redirects the user back to the configured callback or redirect URI.

5. The authentication response is validated

The Wazuh-side configuration validates the information returned through the OIDC flow.

6. Wazuh applies authorization controls

The authenticated user’s identity and associated attributes can then be used within the access-control architecture to determine which resources and actions are available.

This process means that a successful Authentik login is only one part of the overall access decision.

A user may be successfully authenticated but still receive limited access if their Wazuh roles or permissions are restricted.

OIDC-Based Authentication

The Wazuh Authentik integration can use OpenID Connect (OIDC) as the identity protocol.

OIDC is an identity layer built on OAuth 2.0 that enables an application to obtain information about an authenticated user from an identity provider.

In this architecture, Authentik acts as the OpenID Provider, while the Wazuh side of the integration acts as the relying party or client.

An OIDC configuration commonly includes:

• Issuer URL: Identifies the identity provider.
• Client ID: Identifies the Wazuh application to Authentik.
• Client secret: Authenticates the configured application where required.
• Redirect URI: Defines where Authentik sends the user after authentication.
• Scopes: Define the categories of identity information being requested.
• Claims: Carry identity attributes about the authenticated user.
• Discovery endpoint: Provides metadata describing the OIDC provider and its supported endpoints.

The exact URLs and configuration values must match on both sides.

Even a small mismatch in a redirect URI, issuer URL, certificate chain, or client secret can prevent the authentication flow from completing.

For a dedicated protocol-level guide, see How to Configure Wazuh OIDC.

Authentication vs Authorization

One of the most important concepts in a Wazuh Authentik integration is the difference between authentication and authorization.

Authentication answers:

Who is this user?

Authentik is primarily responsible for answering this question. It verifies the user’s identity according to the configured authentication flow.

Authorization answers:

What is this authenticated user allowed to do?

Wazuh access controls, roles, permissions, and related security configuration are responsible for this decision.

For example, two users might successfully authenticate through Authentik:

• A security analyst may be allowed to investigate alerts and view relevant security data.
• A platform administrator may have additional permissions to manage configuration or users.

Both users are authenticated, but they are not necessarily authorized to perform the same actions.

This distinction becomes particularly important when configuring groups and role mappings.

Authentication should establish a reliable identity, while authorization rules should follow the principle of least privilege.

See How to Configure Wazuh SSO Role Mapping for configuring the relationship between external identity information and Wazuh access roles.

Prerequisites for Wazuh Authentik Integration

Before configuring the Wazuh Authentik integration, verify that both platforms are operational and that the required network, DNS, HTTPS, certificate, and identity information is available.

Most integration failures are caused by configuration mismatches rather than the authentication protocol itself.

Incorrect URLs, untrusted certificates, mismatched redirect URIs, unavailable discovery endpoints, or inconsistent group information can all prevent a successful login.

Wazuh Installation Requirements

Start with a working Wazuh deployment.

Before configuring Authentik, confirm that:

• The Wazuh Dashboard is operational.
• The Wazuh environment is accessible to intended users.
• The relevant Wazuh security and authentication components are running correctly.
• You have administrative access to the configuration files and services that participate in the authentication flow.
• You understand how to roll back the authentication configuration if an error prevents administrative login.

It is strongly recommended to test the integration in a staging environment before applying it to a production Wazuh deployment.

You should also maintain an emergency administrative access procedure.

A broken SSO configuration can potentially prevent users from logging in, so administrators should understand how to restore a working authentication configuration without depending on the failing SSO workflow.

If you are deploying the environment for the first time, see The Complete Wazuh Cluster Architecture Guide and How to Build a Wazuh Indexer Cluster.

Authentik Installation and Administrator Access

You need a working Authentik deployment and administrative access to configure the application and identity provider settings.

Before continuing, confirm that you can:

• Sign in to the Authentik administrative interface.
• Create or manage applications.
• Create an OIDC provider configuration.
• Configure redirect URIs.
• Access client credentials.
• Create or manage users and groups.
• Configure authentication policies and flows.

It is also useful to create a dedicated test user and test group before integrating production users.

This makes it easier to verify identity claims and role mappings without affecting existing users.

Wazuh Dashboard URL

The Wazuh Dashboard must have a stable URL that users and Authentik can reach.

For example:

https://wazuh.example.com

This URL is important because it can be involved in the redirect and callback configuration.

Avoid using temporary IP addresses, inconsistent hostnames, or URLs that may change after the integration is configured.

The externally visible URL should also match the deployment architecture.

If the Dashboard is behind a reverse proxy or load balancer, ensure that the public-facing URL, forwarding configuration, and HTTPS settings are consistent.

A mismatch between the URL configured in Authentik and the URL used by the Wazuh environment is a common cause of failed authentication redirects.

Authentik URL

Authentik also requires a stable, reachable URL.

For example:

https://auth.example.com

The Wazuh environment must be able to reach the Authentik endpoints required for the OIDC workflow.

Before beginning the configuration, verify:

• DNS resolution works correctly.
• The Authentik URL is reachable from the Wazuh environment.
• The HTTPS certificate is valid.
• Intermediate certificates are available where required.
• Reverse proxies are forwarding the necessary requests correctly.
• The issuer URL is consistent with the URL configured in the OIDC provider.

Avoid changing the Authentik hostname after configuring the integration unless you are prepared to update the OIDC configuration accordingly.

DNS and HTTPS Requirements

Both Wazuh and Authentik should use stable DNS names and HTTPS.

A production configuration should avoid relying on raw IP addresses for identity-provider URLs whenever possible.

DNS-based URLs provide a more manageable foundation for certificates, redirects, and identity-provider metadata.

Verify that:

• The Wazuh Dashboard hostname resolves correctly.
• The Authentik hostname resolves correctly.
• Required systems can communicate with each other.
• Firewalls and security groups allow the required HTTPS traffic.
• Reverse proxies preserve the expected host and protocol information.
• Redirect URLs use the exact scheme, hostname, and path expected by the OIDC configuration.

HTTPS is particularly important because authentication flows involve sensitive information such as authorization codes, tokens, cookies, and identity assertions.

Required Certificates

The systems participating in the integration must trust the certificates used for HTTPS communication.

Depending on the deployment, this may include:

• Publicly trusted TLS certificates.
• Certificates issued by an internal certificate authority.
• Intermediate CA certificates.
• CA bundles required by the Wazuh or Authentik host.
• Certificates used by reverse proxies or load balancers.

If Authentik uses a certificate that the Wazuh environment does not trust, OIDC discovery or other HTTPS requests can fail.

Similarly, certificate expiration, hostname mismatches, or incomplete certificate chains can interrupt an otherwise correct authentication configuration.

For related troubleshooting guidance, see How to Fix Wazuh Certificate Errors.

Required User and Group Information

Before configuring role mappings, determine how users and groups will be represented in Authentik.

At a minimum, identify:

• The user attribute that will uniquely identify each user.
• The username or preferred username claim.
• Email information, if required by the configuration.
• The groups that should receive access to Wazuh.
• The Wazuh roles associated with those groups.
• Which users should have administrative access.
• Which users should have read-only or analyst-level access.

A useful approach is to document the mapping before configuring it.

For example:

The actual role names and mappings should reflect the organization’s access-control model and should follow least-privilege principles.

For more detailed guidance on this stage, see How to Configure Wazuh RBAC and How to Configure Wazuh SSO Role Mapping.

With these prerequisites in place, the next step is to configure Authentik as an OIDC identity provider and connect its application settings to the Wazuh authentication workflow.

How Wazuh Authentik SSO Works

A Wazuh Authentik integration uses Authentik as the external identity provider and Wazuh as the application that consumes the resulting identity information.

In an OIDC-based deployment, Authentik handles the user’s authentication while Wazuh validates the OIDC response and uses the resulting identity attributes for authorization.

The important point is that Wazuh does not simply receive a username and trust it.

The OIDC flow provides cryptographically verifiable information that allows the application to establish the identity of the authenticated user.

The high-level process is:

1. The user opens the Wazuh Dashboard.
2. Wazuh initiates the external authentication workflow.
3. The user is redirected to Authentik.
4. Authentik authenticates the user.
5. Authentik returns an authorization code to the configured Wazuh callback URL.
6. Wazuh exchanges the authorization code for tokens.
7. Wazuh validates the returned identity information.
8. Wazuh maps the authenticated identity to its configured user and authorization model.
9. The user receives access to the Wazuh Dashboard according to their permissions.

Wazuh Dashboard Authentication Flow

When a user attempts to access a Wazuh Dashboard configured for OIDC authentication, the Dashboard starts an authentication request rather than requiring the user to authenticate directly against Wazuh.

The browser is redirected to Authentik with parameters describing the requested authentication transaction.

These parameters typically include the client ID, redirect URI, requested scopes, response type, and a state value.

A simplified request looks conceptually like this:

User
  |
  v
Wazuh Dashboard
  |
  | OIDC authorization request
  v
Authentik

Authentik then presents the appropriate authentication flow to the user.

After successful authentication, the browser is redirected back to Wazuh using the redirect URI configured for the OIDC application.

The redirect URI is therefore one of the most important configuration values in the entire integration.

The URI registered in Authentik must correspond exactly to the callback endpoint expected by the Wazuh authentication configuration.

Authentik Authorization Flow

Authentik is responsible for establishing that the user is who they claim to be.

When the browser reaches Authentik, the configured authentication flow determines what the user must do before authentication succeeds.

Depending on the Authentik configuration, this could include:

• Username and password authentication
• Multi-factor authentication
• Group membership checks
• Policy evaluation
• Other configured authentication stages

Once the authentication flow succeeds, Authentik authorizes the OIDC client to receive the requested identity information.

It is useful to distinguish this authorization step from Wazuh authorization.

Authentik decides whether the OIDC client and user are permitted to complete the authentication transaction.

Wazuh subsequently decides what the authenticated user can do inside the Wazuh environment.

OIDC Authorization Code Flow

The Wazuh Authentik integration should use the OIDC Authorization Code flow rather than exposing authentication credentials directly to the application.

The basic sequence is:

1. User → Wazuh Dashboard
2. Wazuh → Authentik authorization endpoint
3. Authentik → User authentication
4. Authentik → Wazuh callback with authorization code
5. Wazuh → Authentik token endpoint
6. Authentik → Wazuh tokens
7. Wazuh → Validate identity
8. Wazuh → Establish authenticated session

The authorization code is temporary and is exchanged for tokens through the token endpoint.

This is preferable to sending the user’s password to the Wazuh application.

For a confidential OIDC client, the client secret is used when authenticating the client to the token endpoint.

This makes protecting the client secret particularly important.

The state parameter also plays an important role in protecting the authorization flow against request-forgery attacks.

OIDC implementations should validate the state associated with the authentication transaction.

ID Tokens and Claims

An ID token is a JWT that communicates authentication information about the user to the OIDC client.

The token can contain claims such as:

• iss — the issuer
• sub — the subject identifier
• aud — the intended audience
• exp — expiration time
• iat — issued-at time
• nonce — authentication-request binding value, when used
• email — user’s email address, if configured
• name — user’s display name, if configured
• groups — group membership, if configured

The exact claims returned by Authentik depend on the provider and scope configuration.

The sub claim is particularly important because it provides the stable subject identifier assigned by the OpenID Provider.

Administrators should understand which claim Wazuh uses to identify users and avoid casually changing identity claims after users have already been provisioned.

A successful authentication therefore does not necessarily mean that every desired user attribute is available.

If Wazuh needs a username, email address, or group membership, those claims must be configured and included appropriately.

Access Tokens

The access token is different from the ID token.

An ID token communicates authentication information to the OIDC client. An access token is intended to authorize access to protected resources.

In a typical OIDC authorization-code transaction, Authentik returns the appropriate tokens from its token endpoint after the authorization code is exchanged.

Administrators should not assume that an access token and an ID token are interchangeable.

They serve different purposes, and applications should validate and consume each according to the protocol requirements.

The exact token contents and lifetime are controlled by the identity-provider configuration and should be kept as restrictive as practical for the deployment.

User Identity Mapping

After Wazuh receives the OIDC authentication response, it needs to associate the authenticated identity with a Wazuh user.

This requires consistency between the identity attributes issued by Authentik and the attributes expected by Wazuh.

For example, an organization might use an Authentik claim containing a user’s username as the application identity:

Authentik user
    |
    +-- username: analyst01
    +-- email: analyst01@example.com
    +-- groups: wazuh-analysts
             |
             v
       Wazuh identity
             |
             v
       Wazuh permissions

Before going into production, test exactly which claims Authentik is returning.

A configuration that works for authentication but returns an unexpected username or missing group claim can still produce an authorization problem.

Group and Role Mapping

Groups provide a convenient way to connect centralized identity management with Wazuh authorization.

For example, an organization could maintain groups such as:

wazuh-admins
wazuh-analysts
wazuh-readonly

Authentik can provide the user’s group membership through an appropriate OIDC claim.

Wazuh can then use the available identity information as part of its role-mapping configuration.

The important distinction is:

Authentik group membership → identity information → Wazuh role/permission

Do not assume that creating an Authentik group automatically creates a Wazuh role.

The mapping between external identity information and Wazuh authorization must be configured deliberately.

See How to Configure Wazuh SSO Role Mapping for a detailed explanation of external groups and Wazuh roles.

See How to Configure Wazuh RBAC for the underlying Wazuh role-based access-control model.

Prepare Authentik for Wazuh

Before changing the Wazuh configuration, prepare Authentik to act as the OIDC provider.

The Authentik side of the integration needs an application, an OAuth2/OIDC provider, a client identifier, a client secret where applicable, redirect URI information, and the claims that Wazuh will consume.

The exact labels in the Authentik interface can vary between releases, so focus on the underlying OIDC concepts rather than relying exclusively on a particular UI layout.

Create an Authentik Application

Start by creating an application in Authentik for Wazuh.

The application represents the Wazuh Dashboard as a relying application within Authentik.

Use a descriptive name, such as:

Wazuh Dashboard

If Authentik asks for a launch URL, use the appropriate Wazuh Dashboard URL.

Keep the Wazuh application separate from other OIDC applications whenever possible.

A dedicated application makes it easier to manage client credentials, redirect URIs, access policies, and troubleshooting.

Create an OAuth2/OIDC Provider

Next, create an OAuth2/OIDC provider for the Wazuh application.

Select the provider type intended for an OIDC application. Authentik’s OAuth2 provider configuration is responsible for exposing the OIDC authorization, token, user-information, and discovery functionality required by the client.

Associate the provider with the Wazuh application you created in the previous step.

At this stage, you are establishing the relationship:

Authentik Application
        |
        v
Authentik OIDC Provider
        |
        v
Wazuh Dashboard

Configure the Provider

Configure the provider using values appropriate for your Wazuh deployment.

Pay particular attention to:

• Client ID
• Client type/authentication method
• Redirect URIs
• Scopes
• Signing configuration
• Subject and identity claims
• Group claims
• Access policies

Do not copy values from another OIDC application unless you have verified that they are appropriate for Wazuh.

Configure the Redirect URI

The redirect URI tells Authentik where it is allowed to send the browser after authentication.

The URI must match the callback URL expected by the Wazuh OIDC configuration.

For example, a deployment might use a callback endpoint under:

https://wazuh.example.com/<oidc-callback-path>

The exact path must come from the Wazuh version and authentication configuration you are deploying.

Do not invent a callback path or substitute the Dashboard home page unless Wazuh explicitly requires that URL.

When troubleshooting redirect errors, compare the complete values character by character:

• Scheme: http vs https
• Hostname
• Port
• Path
• Trailing slash

A mismatch in any of these can cause Authentik to reject the request.

Configure Client Authentication

OIDC clients can use different methods to authenticate to the token endpoint.

For a server-side Wazuh deployment, configure the client authentication method supported by the Wazuh version and deployment architecture.

A confidential client normally uses a client ID together with a client secret when communicating with the token endpoint.

Avoid treating a Wazuh Dashboard OIDC client like a browser-only public client unless the Wazuh documentation for your specific release explicitly calls for that configuration.

Generate and Securely Store the Client Secret

If the OIDC provider uses client-secret authentication, generate a dedicated secret for the Wazuh application.

Treat the client secret as a credential.

Do not:

• Commit it to Git.
• Put it in a public configuration repository.
• Paste it into screenshots.
• Include it in support tickets.
• Share it through unsecured chat.
• Reuse it for unrelated applications.

Store it in the appropriate protected Wazuh configuration location with permissions restricted to the services that require it.

If the secret is exposed, rotate it in Authentik and update the Wazuh configuration.

For related credential-management considerations, see Wazuh API Token: Authentication and Setup Guide.

Configure Scopes

OIDC scopes determine what categories of identity information the client requests.

Common OIDC scopes include:

openid
profile
email

The openid scope is fundamental to an OIDC authentication request. Additional scopes such as profile and email can request additional user attributes.

Only request the scopes that are necessary for the Wazuh integration.

If group membership is required for role mapping, configure the appropriate group claim and ensure that the Authentik provider exposes the information needed by Wazuh.

Configure Claims

Claims are attributes returned by the identity provider about the authenticated user.

For Wazuh, determine which identity information needs to be returned and ensure that the Authentik configuration supplies it consistently.

Potential claims include:

sub
preferred_username
email
name
groups

Do not blindly add every available user attribute to the token. Claims should be limited to what the application actually needs.

The most important requirement is consistency.

If the Wazuh configuration expects one claim for the username while Authentik sends the identity under a different claim, authentication or user mapping may fail.

Configure Groups and User Attributes

Create or identify the Authentik groups that should have access to Wazuh.

For example:

wazuh-admins
wazuh-analysts
wazuh-readonly

Then determine which users belong to each group.

If group-based authorization is being used, make sure the group information is actually included in the OIDC claims returned to Wazuh.

A useful test matrix is:

This allows you to test both authentication and authorization rather than simply confirming that the login page works.

Configure the Authentik OIDC Provider

Once the application and provider have been created, review the OIDC provider configuration carefully before connecting it to Wazuh.

The provider is the component that exposes Authentik’s OIDC functionality to the Wazuh client.

Select the Correct Provider Type

When creating the provider, select the OAuth2/OIDC provider appropriate for the Wazuh integration.

Do not confuse an OAuth2/OIDC provider with a SAML provider.

Both can be used for federated authentication, but they use different protocols, endpoints, tokens, and configuration models.

For this integration, the configuration described in this article is based on OpenID Connect.

If you need to compare the protocol options, see How to Configure Wazuh SAML Authentication and How to Configure Wazuh OIDC.

Configure the Client ID

Assign a dedicated client ID to the Wazuh application.

For example:

wazuh-dashboard

The client ID identifies the OIDC client to Authentik.

It is not a password and does not need to be treated as secret, but it should remain unique and descriptive.

The same client ID must be supplied in the corresponding Wazuh OIDC configuration.

Configure the Client Secret

If the Wazuh OIDC client is configured as confidential, generate a strong random client secret.

The secret must match between Authentik and Wazuh.

If authentication fails immediately after changing the secret, verify that:

1. The secret was updated in Authentik.
2. The corresponding Wazuh configuration contains the new value.
3. The Wazuh service has loaded the updated configuration.
4. No hidden whitespace or quotation errors were introduced.

Do not expose the secret in logs or diagnostic output.

Configure Redirect URIs

Add the exact Wazuh OIDC redirect URI to the Authentik provider.

For example:

https://wazuh.example.com/<configured-callback-path>

Use the callback path specified by your Wazuh version and authentication configuration.

If your Wazuh Dashboard is accessed through a reverse proxy, make sure the URI represents the externally accessible address rather than an internal backend address.

Common redirect problems include:

• Incorrect hostname
• Incorrect HTTPS scheme
• Wrong callback path
• Missing port
• Unexpected trailing slash
• Reverse-proxy URL mismatch
• Multiple URLs being used for the same Dashboard

The redirect URI should be treated as an exact value rather than an approximate location.

Configure Signing and Encryption Settings

OIDC relies on cryptographic signing to establish the integrity and authenticity of identity information.

Review the signing configuration exposed by the Authentik provider and ensure it is compatible with what the Wazuh OIDC implementation supports.

Where applicable, verify:

• Signing algorithm
• Signing key
• Key rotation behavior
• JWT validation requirements
• Encryption settings, if encryption is enabled

Do not enable optional encryption or change algorithms simply because the options are available.

The provider and Wazuh client must support the selected configuration.

Configure Authorization Settings

Configure which users are allowed to use the Wazuh OIDC application.

If the Wazuh application should be restricted to a specific population, use Authentik policies or group-based restrictions rather than allowing every Authentik account to authenticate to Wazuh.

For example, access might be restricted to:

wazuh-admins
wazuh-analysts
wazuh-readonly

This creates an initial authorization boundary before Wazuh applies its own role-based permissions.

The two layers should complement each other:

Authentik
  └── Can this identity use Wazuh?

Wazuh
  └── What can this authenticated identity do?

This layered approach reduces the risk of accidentally granting Wazuh access to every user in the identity provider.

Configure Allowed Users and Groups

If Authentik supports restricting the application or provider to specific users and groups, configure those restrictions deliberately.

For example:

wazuh-admins
wazuh-analysts
wazuh-readonly

can be allowed to access the application while unrelated groups remain excluded.

Then test at least three scenarios:

1. Authorized user: Authentication succeeds and the expected Wazuh permissions are applied.
2. Authorized user with different group: Authentication succeeds but receives the appropriate lower-privilege role.
3. Unauthorized user: Authentik prevents access to the Wazuh application.

This testing verifies that authentication and authorization boundaries are behaving independently.

Verify the OIDC Discovery Endpoint

Before configuring Wazuh, verify that Authentik is exposing valid OIDC discovery metadata.

The discovery document is normally available under an OIDC well-known endpoint associated with the configured provider.

A typical OIDC discovery document contains information such as:

{
  "issuer": "...",
  "authorization_endpoint": "...",
  "token_endpoint": "...",
  "userinfo_endpoint": "...",
  "jwks_uri": "...",
  "response_types_supported": ["code"]
}

The exact URL depends on the Authentik provider configuration and version.

The discovery document should be reachable over HTTPS from the Wazuh environment and should return valid JSON.

Check that:

• The issuer is the expected Authentik issuer.
• The authorization endpoint is present.
• The token endpoint is present.
• The JWKS URI is present when required.
• HTTPS certificates are trusted.
• DNS resolves correctly.
• The returned endpoints are reachable.
• The configured Wazuh client can communicate with the provider.

You can perform a basic connectivity test from the Wazuh host with a command such as:

curl -I https://auth.example.com/

For the discovery document itself, use the exact discovery URL generated by your Authentik provider rather than assuming a generic path.

Once discovery, certificates, client credentials, redirect URIs, and claims have been validated, the Authentik side is ready for the Wazuh configuration.

For additional Wazuh authentication troubleshooting, see How to Fix Wazuh SSO Login Error.

Configure Wazuh for Authentik OIDC

Once the Authentik OIDC application and provider are configured, the next step is connecting them to the Wazuh Dashboard.

The Wazuh Dashboard is the web interface used to visualize and manage the Wazuh environment, and its configuration includes the settings required for authentication and communication with the Wazuh components.

Important: Wazuh’s OIDC and SSO configuration can vary between releases. Always compare the configuration parameters and callback paths against the documentation for the exact Wazuh version you are running.

Locate the Wazuh Dashboard Security Configuration

On a self-managed Wazuh installation, the primary Dashboard configuration is located at:

/etc/wazuh-dashboard/opensearch_dashboards.yml

Wazuh’s installation documentation identifies this file as the main configuration file for the Dashboard.

Before modifying it, create a backup:

sudo cp /etc/wazuh-dashboard/opensearch_dashboards.yml \
  /etc/wazuh-dashboard/opensearch_dashboards.yml.bak

Keep the backup available until you have successfully tested the Authentik login flow.

It is also important to distinguish this file from:

/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml

The latter contains Wazuh Dashboard application configuration, including its connection to the Wazuh server API.

Wazuh documents run_as in this file as important when configuring role mappings because it allows the Dashboard to create role mappings based on identity-provider information.

Configure the OIDC Identity Provider

The Wazuh OIDC configuration needs to know where Authentik is located and how to communicate with its OIDC endpoints.

At a conceptual level, the configuration connects these components:

Wazuh Dashboard
       |
       | OIDC
       v
    Authentik
       |
       +-- Authorization endpoint
       +-- Token endpoint
       +-- UserInfo endpoint
       +-- JWKS endpoint
       +-- Discovery metadata

The exact configuration syntax depends on the Wazuh release and the authentication implementation being used.

Do not copy an OIDC configuration from an older Wazuh release without checking whether the available settings and authentication backend are still applicable.

Set the Authentik Issuer URL

The issuer identifies the Authentik instance that issued the OIDC identity information.

For example:

https://auth.example.com/

The value configured in Wazuh must correspond to the issuer advertised by Authentik’s discovery metadata.

This is important because the issuer is not simply a convenient hostname.

It is an identity value that the OIDC client uses when validating the provider.

If the configured issuer differs from the issuer returned by Authentik, authentication can fail even when the Authentik login page itself works correctly.

Configure the Authorization Endpoint

The authorization endpoint is where the user’s browser is redirected when Wazuh initiates authentication.

Conceptually:

Wazuh Dashboard
       |
       | Authorization request
       v
Authentik authorization endpoint
       |
       v
User authentication

You should normally obtain this endpoint from Authentik’s OIDC discovery metadata rather than manually guessing the URL.

The endpoint must be reachable by users through their browsers, and the request must contain the client and redirect information expected by the Authentik provider.

Configure the Token Endpoint

After the user successfully authenticates, Wazuh receives an authorization code and exchanges it with Authentik for tokens.

The token endpoint performs this exchange:

Authorization code
        |
        v
Authentik token endpoint
        |
        v
ID token + access token

The token endpoint is normally obtained from the Authentik discovery document.

For a confidential client, Wazuh must also authenticate the client using the configured client credentials.

If this step fails, users may successfully authenticate in Authentik only to be returned to Wazuh with an error.

Configure the UserInfo Endpoint

The OIDC UserInfo endpoint can provide additional information about the authenticated user.

Depending on the Wazuh OIDC implementation and configuration, the application may obtain user attributes from the ID token, UserInfo endpoint, or both.

Potential attributes include:

• Username
• Subject identifier
• Email
• Display name
• Group information
• Other configured claims

Make sure the claims expected by Wazuh are actually available from the Authentik provider.

A successful authentication does not guarantee that every desired attribute has been returned.

Configure Client ID and Client Secret

The client ID identifies Wazuh to Authentik.

For example:

Client ID: wazuh-dashboard

The client secret authenticates the confidential OIDC client.

The values must correspond exactly between Authentik and Wazuh.

Treat the secret as sensitive information and restrict access to the Wazuh configuration containing it.

If it is exposed, rotate it through Authentik and update Wazuh.

Do not place the secret in public documentation, source-control repositories, screenshots, or troubleshooting output.

Configure Requested Scopes

The OIDC request should include the scopes required by the Wazuh authentication configuration.

The fundamental OIDC scope is:

openid

Additional scopes may include:

profile
email

If group information is required, configure Authentik to return the appropriate group claim and ensure the Wazuh configuration consumes it correctly.

Only request information required by the application.

This keeps the identity exchange more predictable and avoids unnecessarily exposing user attributes.

Configure Claim Mappings

Claims provide the attributes Wazuh uses to identify and authorize the user.

A typical mapping might conceptually look like:

Authentik claim          Wazuh purpose
------------------------------------------------
sub                      Stable user identifier
preferred_username       Username
email                    Email address
groups                   Backend roles / groups

The exact Wazuh configuration syntax and supported claim names depend on the Wazuh release.

Group claims deserve particular attention.

Wazuh’s Authentik documentation demonstrates role mapping using a backend role supplied by the identity provider and then mapping that value to a Wazuh role.

Apply the Configuration

After entering the OIDC settings, validate the configuration before restarting the Dashboard.

At minimum, verify:

• Issuer URL is correct.
• Authorization endpoint is correct.
• Token endpoint is correct.
• UserInfo endpoint is correct where required.
• Client ID matches Authentik.
• Client secret matches Authentik.
• Redirect URI matches exactly.
• Requested scopes are supported.
• Required claims are being returned.
• Authentik’s TLS certificate is trusted.
• The Wazuh host can reach Authentik.

A configuration backup is especially useful at this stage because an authentication mistake can prevent normal Dashboard login.

Restart or Reload the Required Wazuh Services

After making changes to the Dashboard authentication configuration, restart the Wazuh Dashboard service when required by the configuration.

For a systemd-based installation:

sudo systemctl restart wazuh-dashboard

Then verify the service:

sudo systemctl status wazuh-dashboard

Wazuh’s official installation documentation uses systemctl restart wazuh-dashboard to apply Dashboard configuration changes.

If the service fails to start, inspect the Dashboard logs before repeatedly changing configuration values.

Do not immediately remove working authentication settings.

Compare the new configuration against the backup and isolate the invalid parameter.

For troubleshooting authentication failures, see How to Fix Wazuh SSO Login Error.

Configure Wazuh User and Role Mapping

Authentication establishes the user’s identity, but Wazuh still needs to determine what that user can access.

Wazuh provides role-based access controls and role mappings that allow administrators to associate users or identity-provider attributes with permissions.

The Dashboard’s Security area includes users, roles, policies, and role mappings.

This is where the distinction between authentication and authorization becomes operational.

How Wazuh Maps Authenticated Users

The general flow is:

Authentik user
      |
      v
OIDC claims
      |
      v
Wazuh authenticated identity
      |
      v
Backend role / group information
      |
      v
Wazuh role mapping
      |
      v
Wazuh permissions

For example, Authentik might authenticate:

alex@example.com

and return:

preferred_username = alex
groups = wazuh-analysts

Wazuh can then use the returned identity information when determining the user’s roles.

The exact mechanics depend on the Wazuh SSO implementation and release, so verify the expected claim names before creating mappings.

Map Authentik Usernames

Choose a consistent username claim.

For example:

preferred_username

could contain:

alex

The important requirement is that the value is stable and unique enough for the identity model you are implementing.

Avoid changing the username claim after deployment without considering its effect on existing mappings and user identity records.

Map Email Claims

Email can be included as an additional user attribute:

email = alex@example.com

Email addresses are useful for identification and administration, but they should not automatically be treated as the authorization mechanism.

For example, avoid rules equivalent to:

email contains "@example.com"
    → administrator

unless that behavior is explicitly intended and appropriately controlled.

Group-based authorization is generally easier to manage because membership can be changed without changing the user’s identity.

Map Groups to Wazuh Roles

Group-to-role mapping is one of the most useful parts of a Wazuh Authentik deployment.

For example:

Authentik group       Wazuh role
-----------------------------------------
wazuh-admins          administrator
wazuh-analysts        analyst role
wazuh-readonly        readonly

Wazuh’s Authentik documentation provides an example where an Authentik-provided backend role such as wazuh-admins is used in a Wazuh role mapping and associated with the administrator role.

The same approach can be used for lower-privilege groups.

See How to Configure Wazuh SSO Role Mapping for a dedicated guide to external group and role mappings.

Configure Administrator Access

Create a dedicated Authentik group for Wazuh administrators:

wazuh-admins

Only users who genuinely require administrative privileges should be members.

Then map the corresponding backend role or group value to the appropriate Wazuh administrative role.

Test administrator access using a dedicated test account before assigning production administrators.

Administrator access should be treated as a high-impact permission because it can expose configuration, security data, user-management functions, and other sensitive capabilities.

Configure Analyst Access

Create a separate group for security analysts:

wazuh-analysts

Map this group to an analyst-oriented Wazuh role with only the permissions required for investigation and monitoring.

An analyst does not necessarily need permission to modify platform-wide configuration or manage users.

Separating analyst and administrator roles makes the access model easier to audit and reduces unnecessary privileges.

Configure Read-Only Access

For users who only need to view security information, create a dedicated group:

wazuh-readonly

Map it to the appropriate Wazuh read-only role.

This is useful for stakeholders who need visibility into security information but should not modify Wazuh configuration.

Wazuh’s documentation also demonstrates mapping an identity-provider backend role to the readonly Wazuh role.

Apply Least-Privilege Permissions

The principle of least privilege should govern both sides of the integration.

At the Authentik layer, only appropriate users should be allowed to access the Wazuh application.

At the Wazuh layer, those authenticated users should receive only the permissions required for their responsibilities.

A good model is:

Authentik access
       ↓
Can the user access Wazuh?

Wazuh role mapping
       ↓
What Wazuh role does the user receive?

Wazuh policies
       ↓
What can that role actually do?

This layered approach is more robust than assigning broad permissions to every authenticated user.

See Mastering Wazuh Security: The Complete Access Control Guide for a broader discussion of Wazuh access control and RBAC.

Handle Users Without Matching Roles

Decide explicitly what happens when a user authenticates successfully but does not belong to a mapped Wazuh group.

Do not assume that successful authentication should automatically result in broad Wazuh access.

A safer model is:

Authenticated
      |
      +-- Matching Wazuh group → mapped role → access
      |
      └-- No matching group → no appropriate Wazuh role

Test this scenario with a user who has access to the Authentik application but is not a member of any Wazuh authorization group.

This test can reveal accidental default permissions before the integration is deployed to production.

Configure Authentik Groups for Wazuh Access

Using dedicated Authentik groups makes the Wazuh access model easier to understand and maintain.

Rather than mapping individual users whenever possible, manage membership centrally through groups and allow Wazuh to consume the resulting group information.

Create Wazuh-Specific Groups

Create groups specifically for Wazuh access.

A simple structure might be:

wazuh-admins
wazuh-analysts
wazuh-readonly

Avoid using a generic group such as:

employees

for administrator access to Wazuh.

Dedicated groups make access reviews substantially easier because their purpose is immediately apparent.

Assign Users to Groups

Assign users according to their job responsibilities.

For example:

Alice → wazuh-admins
Bob   → wazuh-analysts
Carol → wazuh-readonly

Avoid putting users into multiple groups unless there is a clear reason to do so.

If a user belongs to multiple groups that map to different Wazuh roles, test the resulting authorization behavior carefully.

Return Groups Through OIDC Claims

Creating groups in Authentik is not sufficient by itself.

The user’s group membership must be exposed to the OIDC client through an appropriate claim.

Conceptually:

Authentik
   |
   | groups claim
   v
Wazuh
   |
   | backend role
   v
Wazuh role mapping

For example, the OIDC response could contain a group-related claim representing:

wazuh-admins

Wazuh can then use that value when evaluating its role mappings.

The exact property mapping and claim configuration should follow the Authentik and Wazuh versions in use.

Map Groups to Wazuh Roles

After Authentik is returning group information, configure the corresponding Wazuh role mappings.

For example:

Wazuh’s current Authentik integration documentation specifically demonstrates using a backend role value supplied by the identity provider in a Dashboard role mapping.

This is preferable to manually creating every external user inside Wazuh when the goal is centralized identity management.

Test Group Membership Changes

Do not stop testing after the first successful login.

Change the test user’s Authentik group membership and verify the resulting Wazuh authorization.

For example:

1. Test 1 — Analyst

User → wazuh-analysts
Expected → analyst permissions

2. Test 2 — Read-only

User → wazuh-readonly
Expected → read-only permissions

3. Test 3 — Administrator

User → wazuh-admins
Expected → administrator permissions

4. Test 4 — Removed from Wazuh groups

User → no Wazuh group
Expected → Wazuh access denied or no applicable role

Also test what happens to an existing session after group membership changes.

Depending on token and session lifetimes, a user may need to sign in again before the updated claims are reflected.

Manage User Lifecycle Through Authentik

One of the major advantages of integrating Wazuh with an external identity provider is centralized lifecycle management.

When an employee joins the security team, administrators can add the user to the appropriate Authentik group.

 Administrators can move them to a different group when their responsibilities change.

When they leave the organization, administrators can disable their Authentik account or remove their access to the Wazuh application.

The resulting model is:

Join organization
      ↓
Create/enable Authentik account
      ↓
Assign Wazuh group
      ↓
Wazuh role automatically applies

Role change
      ↓
Change Authentik group
      ↓
Wazuh authorization changes

Offboarding
      ↓
Disable Authentik account
      ↓
Wazuh authentication is no longer available

This centralizes identity lifecycle management while leaving Wazuh responsible for its own application authorization.

However, administrators should still periodically review Wazuh role mappings, Authentik groups, active sessions, and privileged accounts. Centralized identity does not eliminate the need for access reviews.

For broader guidance on Wazuh SSO administration and ongoing maintenance, see The Complete Wazuh Single Sign-On (SSO) Guide.

How to Test Wazuh Authentik SSO

After configuring the Wazuh Authentik integration, test the complete authentication and authorization workflow before allowing production users to depend on it.

A successful test should verify more than whether the Authentik login page appears.

You should confirm that the authentication transaction completes, Wazuh identifies the correct user, the expected role is applied, group membership is handled correctly, and logout behaves as expected.

Use a dedicated test account rather than an administrator’s primary account during initial testing.

Open the Wazuh Dashboard

Open the Wazuh Dashboard using the same HTTPS URL that production users will use.

For example:

https://wazuh.example.com

Before testing SSO, verify that:

• The Dashboard loads normally.
• HTTPS is working.
• The hostname resolves correctly.
• The browser does not report certificate errors.
• The Wazuh Dashboard service is running.
• Authentik is reachable from the client.

If the Dashboard itself does not load, resolve that problem before troubleshooting OIDC.

See Wazuh Dashboard Not Loading? Complete Troubleshooting Guide if the Dashboard is unavailable before authentication begins.

Start the SSO Login Process

Select the configured SSO or external authentication option on the Wazuh login interface.

The browser should be redirected from Wazuh to the Authentik authorization endpoint.

A successful transition should look approximately like:

Wazuh Dashboard
       |
       v
Authentik

If the browser never leaves Wazuh, investigate the Wazuh authentication configuration.

If it reaches Authentik but Authentik rejects the request, inspect the client ID, redirect URI, provider configuration, and authorization policies.

Authenticate Through Authentik

Authenticate using the dedicated Authentik test account.

Complete any authentication requirements configured for the provider, including MFA if enabled.

At this stage, verify that Authentik recognizes the user as an authorized user of the Wazuh application.

If Authentik reports that the user is not permitted to access the application, review the application’s allowed users, groups, and policies.

If authentication succeeds but Wazuh subsequently rejects the user, the problem is more likely related to the OIDC response, claims, role mapping, or Wazuh authorization.

Verify the Redirect Back to Wazuh

After successful authentication, Authentik should redirect the browser back to the Wazuh callback URL.

The expected sequence is:

Wazuh
  ↓
Authentik login
  ↓
Successful authentication
  ↓
Wazuh callback
  ↓
Authenticated Wazuh session

If the browser remains on Authentik or returns an error, verify the registered redirect URI.

Pay particular attention to:

• Protocol
• Hostname
• Port
• Path
• Trailing slash
• Reverse-proxy configuration

The URI registered in Authentik must match the callback URL expected by the Wazuh OIDC configuration.

Confirm the Authenticated Username

After the login completes, confirm that Wazuh identifies the expected user.

For example, if the Authentik account is:

alex@example.com

verify that Wazuh does not unexpectedly identify the user as another account or with an incorrect username.

This test is important because authentication can succeed while identity mapping is incorrectly configured.

Check the claim used to establish the Wazuh username and confirm that Authentik is returning the expected value.

Verify Assigned Permissions

Once the user is logged in, verify the permissions assigned to that account.

Do not test only whether the user can see the Dashboard.

Test representative actions for the expected role.

For example, an administrator might be expected to manage configuration, while an analyst might only need to investigate alerts.

Confirm that:

• The intended pages are accessible.
• Restricted pages remain inaccessible.
• The user cannot perform administrative actions that their role should not permit.
• Data access matches the assigned permissions.

See Mastering Wazuh Security: The Complete Access Control Guide for the broader Wazuh authorization model.

Test Different Authentik Groups

Repeat the test with users in different Authentik groups.

For example:

This verifies that the group claim is being returned correctly and that Wazuh’s role mappings are working as intended.

Also test moving a user from one group to another.

For example:

wazuh-readonly
      ↓
wazuh-analysts

Then authenticate again and verify that the user’s effective permissions change as expected.

Verify Logout Behavior

Test both the Wazuh logout operation and the Authentik session.

After logging out of Wazuh, determine whether returning to the Dashboard immediately authenticates the user again because an active Authentik session still exists.

This distinction is important:

Wazuh session logout
        ≠
Authentik identity-provider session logout

Depending on the configured SSO behavior, logging out of Wazuh may not terminate the user’s entire Authentik session.

Test the behavior that your organization expects and document it for users.

Troubleshooting Wazuh Authentik Integration

OIDC integrations can fail at several different points.

The most effective troubleshooting strategy is to identify exactly where the authentication transaction stops rather than changing multiple settings simultaneously.

A useful diagnostic sequence is:

Wazuh
  ↓
Authorization request
  ↓
Authentik
  ↓
User authentication
  ↓
Authorization code
  ↓
Token exchange
  ↓
Identity claims
  ↓
Wazuh role mapping
  ↓
Authorized session

The location of the failure usually narrows the possible causes significantly.

For broader Wazuh SSO troubleshooting, see How to Fix Wazuh SSO Login Error.

Wazuh Redirects Back to the Login Page

A repeated redirect to the login page often indicates that the authentication transaction is not producing a valid Wazuh session.

Possible causes include:

• Incorrect redirect URI
• Invalid issuer
• Invalid client configuration
• Failed token exchange
• Invalid or missing claims
• Cookie or session problems
• Reverse-proxy configuration errors
• Incorrect Dashboard authentication configuration

Start by determining whether the user successfully authenticates in Authentik.

If Authentik reports successful authentication but Wazuh immediately returns to the login page, focus on the callback, token validation, session, and claim-processing stages.

See How to Fix Wazuh SSO Login Error for additional login-loop troubleshooting.

Check Redirect URI Configuration

Compare the redirect URI configured in Authentik with the callback URI expected by Wazuh.

Check the complete URL rather than only the hostname.

For example:

https://wazuh.example.com/callback

is different from:

https://wazuh.example.com/callback/

Likewise:

http://wazuh.example.com/callback

is different from:

https://wazuh.example.com/callback

Do not make assumptions about the callback path.

Use the path specified by the Wazuh configuration for your release.

Verify Issuer and Endpoint URLs

Confirm that the issuer configured in Wazuh exactly corresponds to the issuer advertised by Authentik.

Then verify the authorization, token, and UserInfo endpoints.

If Authentik’s discovery document provides these values, use the discovery metadata as the authoritative source rather than manually reconstructing URLs.

Check Browser Cookies and Sessions

A stale browser session can make OIDC troubleshooting confusing.

Try:

• A private/incognito browser window.
• Clearing cookies for the Wazuh and Authentik domains.
• Signing out of Authentik.
• Starting a completely new authentication transaction.

If the integration works in a private window but not in a normal browser session, investigate cookies, stale sessions, browser policies, and cached authentication state.

Invalid Client Error

An invalid_client response generally indicates that Authentik cannot authenticate or identify the OIDC client correctly.

Verify the Client ID

Confirm that the client ID configured in Wazuh is identical to the client ID configured in Authentik.

Check for:

• Typographical errors
• Extra spaces
• Wrong provider
• Wrong Authentik application
• Incorrect capitalization where relevant

Verify the Client Secret

If the provider uses a client secret, verify that the secret in Wazuh matches the current Authentik secret.

If there is any possibility that the secret was exposed or copied incorrectly, generate a new secret and update both systems.

Avoid repeatedly testing an uncertain secret without first confirming which value is currently active.

Check Authentik Provider Configuration

Make sure the Wazuh client is associated with the correct Authentik provider.

An Authentik deployment may contain multiple OIDC providers.

Accidentally using the client ID from one provider while pointing Wazuh at another can produce an apparently inexplicable invalid_client error.

OIDC Discovery Error

Discovery errors occur when Wazuh cannot retrieve or validate the OIDC provider metadata.

Verify the Issuer URL

Confirm that the issuer configured in Wazuh is the correct Authentik issuer.

Avoid adding or removing trailing slashes without confirming what Authentik actually publishes.

The issuer in the discovery metadata should correspond to the issuer expected by the OIDC client.

Check the Discovery Endpoint

Request the discovery document directly from a system that can reach Authentik.

For example:

curl -fsS https://auth.example.com/<oidc-discovery-path>

Use the exact discovery path exposed by your Authentik provider.

The response should be valid JSON containing the relevant OIDC metadata.

Verify HTTPS and DNS Resolution

From the Wazuh host, verify that the Authentik hostname resolves:

getent hosts auth.example.com

Then verify HTTPS connectivity:

curl -I https://auth.example.com/

If DNS works but HTTPS fails, investigate certificates, firewalls, proxies, or TLS configuration.

Invalid Redirect URI

An invalid redirect URI is one of the most common OIDC configuration mistakes.

Compare Wazuh and Authentik Redirect URIs

Copy the expected callback URI from the Wazuh configuration and compare it directly against the URI registered in Authentik.

Do not compare only the domain.

Compare the entire string.

Check HTTP vs HTTPS

A production Wazuh deployment should normally use HTTPS.

These are different redirect URIs:

http://wazuh.example.com/callback
https://wazuh.example.com/callback

If the user accesses Wazuh through HTTPS but Authentik has an HTTP callback registered, the OIDC provider can reject the request.

Check Trailing Slashes and URL Paths

These may also be different:

https://wazuh.example.com/oidc/callback
https://wazuh.example.com/oidc/callback/

Likewise, an internal Dashboard path may not be the same as the public URL exposed through a reverse proxy.

Check the externally visible URL and the reverse-proxy configuration together.

User Authenticates but Cannot Access Wazuh

This situation is particularly useful diagnostically because it indicates that authentication may already be working.

The likely problem is authorization.

Check Role Mappings

Verify that the authenticated user’s external group or backend role is mapped to an appropriate Wazuh role.

For example:

wazuh-analysts
      ↓
Wazuh analyst role

If the group value returned by Authentik does not exactly match the value used in the Wazuh role mapping, the mapping may not apply.

Check Group Claims

Verify that the OIDC response actually contains the expected group information.

Creating a group in Authentik does not automatically mean that the group appears in the OIDC token.

The provider must be configured to return the claim.

Verify Wazuh Permissions

A role can exist and still lack the permissions necessary for the user’s intended task.

Verify the role’s associated policies and permissions rather than assuming that a successful role mapping means unrestricted access.

See How to Configure Wazuh RBAC for role and policy configuration.

Check Backend Security Configuration

If the Wazuh authentication process succeeds but the Dashboard cannot establish the expected security context, inspect the Wazuh security configuration and Dashboard logs.

Pay particular attention to configuration values associated with external authentication, backend roles, and role mappings.

Groups Are Not Being Mapped

If users authenticate successfully but every user receives the same permissions, the group claim is one of the first areas to investigate.

Verify Authentik Group Claims

Confirm that the OIDC response contains the user’s Authentik groups.

The value might conceptually look like:

groups:
  - wazuh-analysts

If no group claim is returned, Wazuh cannot use it for group-based role mapping.

Check Requested Scopes

Confirm that Wazuh requests the scopes necessary to obtain the configured identity attributes.

At minimum, OIDC requires the openid scope.

Additional scopes may be necessary for profile or email information.

Group membership may require additional provider-side claim configuration rather than simply adding a standard OIDC scope.

Verify Claim Names

Make sure Wazuh is reading the same claim that Authentik is returning.

For example:

Authentik returns:
groups

Wazuh expects:
backend_roles

Those values do not automatically become equivalent.

The identity-provider configuration must expose the information in a form compatible with the Wazuh role-mapping configuration.

Check Wazuh Role-Mapping Configuration

Finally, verify that the external group value is associated with the intended Wazuh role.

For example:

External group:
wazuh-analysts

↓
Wazuh role mapping

↓
Analyst role

Check spelling and capitalization carefully.

See How to Configure Wazuh SSO Role Mapping for more detailed role-mapping troubleshooting.

Certificate or TLS Errors

TLS failures can prevent the OIDC workflow from even reaching the authentication stage.

Verify Certificate Chains

Check that Authentik presents a complete certificate chain.

A certificate may appear valid in a browser while still failing validation from the Wazuh host if an intermediate certificate is missing or the host uses a different trust store.

Check Trusted CA Certificates

If Authentik uses an internal CA, ensure that the Wazuh environment trusts the appropriate CA certificate.

Do not disable TLS certificate verification merely to make the integration work.

That removes an important security control and can expose authentication traffic to man-in-the-middle attacks.

Validate Hostname Matching

The certificate must be valid for the hostname Wazuh uses to communicate with Authentik.

For example, if Wazuh connects to:

https://auth.example.com

the certificate must cover auth.example.com.

Check System Time Synchronization

OIDC tokens contain time-sensitive claims such as expiration and issuance timestamps.

If the Wazuh host, Authentik server, or related systems have significantly incorrect clocks, otherwise valid tokens can be rejected.

Check the system time and synchronization status:

timedatectl

If necessary, correct the system’s NTP configuration before continuing with OIDC troubleshooting.

Wazuh Authentik Security Best Practices

A successful SSO implementation should not only be convenient; it should strengthen the overall authentication architecture.

Because Authentik becomes part of the security boundary for Wazuh, protect both platforms and minimize the privileges granted through the integration.

Use HTTPS for Wazuh and Authentik

Use HTTPS for both the Wazuh Dashboard and Authentik.

This protects authentication transactions and helps prevent attackers from intercepting sensitive information exchanged during the OIDC workflow.

Avoid HTTP for production authentication endpoints.

Use valid certificates and maintain the complete trust chain required by the systems communicating with each other.

See How to Fix Wazuh Certificate Errors when troubleshooting certificate validation problems.

Protect the OIDC Client Secret

Treat the OIDC client secret as a credential.

Store it securely, restrict permissions on configuration files, and avoid exposing it through:

• Source control
• Public documentation
• Screenshots
• Shell history
• Logs
• Monitoring output
• Support tickets

If the secret is compromised, rotate it immediately.

Use Least-Privilege Wazuh Roles

Do not map every authenticated Authentik user to the Wazuh administrator role.

Instead, create separate roles for different responsibilities.

For example:

wazuh-admins
      ↓
Administrator

wazuh-analysts
      ↓
Analyst permissions

wazuh-readonly
      ↓
Read-only permissions

This limits the impact of compromised accounts and reduces accidental administrative changes.

Restrict Application Access to Approved Authentik Groups

Use Authentik policies and groups to control who can authenticate to the Wazuh application.

A user having an Authentik account should not automatically mean that the user should have Wazuh access.

Restrict the Wazuh application to the groups that actually require it.

Avoid Unnecessary OIDC Scopes

Request only the scopes and identity attributes Wazuh needs.

The openid scope is required for OIDC authentication. Other scopes should be enabled when there is a legitimate requirement for the associated information.

Minimizing claims also makes the integration easier to troubleshoot because the identity payload contains fewer unnecessary attributes.

Use Strong Authentication in Authentik

The security of Wazuh SSO is strongly influenced by the authentication policy enforced by Authentik.

Use strong authentication requirements appropriate for the sensitivity of the Wazuh environment.

For privileged users, consider requiring stronger authentication than ordinary internal applications.

Enable MFA Where Appropriate

Multi-factor authentication can provide an additional layer of protection if an attacker obtains a user’s password.

Authentik can enforce MFA through its authentication flows and policies.

Consider requiring MFA for:

• Wazuh administrators
• Security analysts
• Remote users
• Privileged identity-provider accounts

MFA should complement, not replace, least-privilege authorization.

Monitor Authentication Failures

Monitor both Wazuh and Authentik for authentication failures.

Look for patterns such as:

• Repeated failed logins
• Invalid client attempts
• Unexpected redirect failures
• Repeated token-validation errors
• Suspicious login locations
• Unexpected administrative access

Centralized logging can make it easier to correlate identity-provider events with Wazuh activity.

See How to Configure Wazuh Audit Logs for related Wazuh auditing capabilities.

Review Role Mappings Regularly

Role mappings should be reviewed periodically.

Verify that:

• Administrative groups contain only appropriate users.
• Obsolete groups are removed.
• External group names still match Wazuh mappings.
• No overly broad mapping exists.
• Read-only users have not accumulated unnecessary permissions.

Identity-provider changes can unintentionally alter application access, so role mappings should be treated as security-sensitive configuration.

Remove Inactive Users Promptly

Disable or remove inactive accounts from Authentik and remove users from Wazuh-specific groups when access is no longer required.

Centralized identity management makes this easier because disabling an Authentik account can prevent subsequent authentication to Wazuh.

However, also consider existing sessions and token lifetimes.

Disabling an account does not necessarily mean that an already-issued session disappears instantaneously.

Rotate Client Secrets When Necessary

Rotate the OIDC client secret when:

• The secret may have been exposed.
• An administrator with access to the secret leaves the organization.
• Security policy requires periodic rotation.
• You suspect unauthorized use.
• The provider or application requires replacement.

After generating the replacement secret in Authentik, update Wazuh and verify the complete authentication flow.

Plan secret rotation carefully so that the change does not unexpectedly lock administrators out of the Dashboard.

Keep Wazuh and Authentik Updated

Keep both Wazuh and Authentik on supported releases and apply security updates promptly.

Identity-provider software and security-monitoring platforms both occupy sensitive positions in the infrastructure, so vulnerabilities in either component can have significant consequences.

Before upgrading either platform, review release notes and test the SSO integration in a controlled environment where practical.

After an upgrade, test:

• OIDC discovery
• Authentication
• Redirect behavior
• Token exchange
• User identity mapping
• Group claims
• Wazuh role mappings
• Logout
• Administrative access

For broader Wazuh SSO administration and maintenance, see The Complete Wazuh Single Sign-On (SSO) Guide.

Wazuh Authentik vs LDAP, SAML, and Other SSO Methods

Wazuh supports several approaches for centralized authentication, including LDAP, SAML, and OIDC.

Authentik can participate in several of these architectures because it supports OIDC/OAuth2, SAML, LDAP, and other provider types.

The right choice depends on the identity infrastructure already deployed, the protocol supported by the application, and the authentication and authorization requirements of the organization.

For a new Wazuh Authentik deployment, OIDC is often an attractive choice when the Wazuh version and deployment architecture support it because Authentik provides a dedicated OAuth2/OpenID Connect provider with standard discovery, authorization, token, UserInfo, and JWKS endpoints.

Wazuh Authentik OIDC vs LDAP

LDAP and OIDC solve related identity problems but operate differently.

With LDAP, Wazuh connects to an LDAP directory or Active Directory server and uses directory credentials and attributes for authentication and authorization.

Wazuh’s LDAP integration uses separate authentication and authorization configuration to authenticate users and retrieve backend roles.

With OIDC:

Wazuh
   |
   | OIDC
   v
Authentik
   |
   v
User authentication

With LDAP:

Wazuh
   |
   | LDAP/LDAPS
   v
LDAP / Active Directory

OIDC is generally preferable when:

• Authentik is already your centralized identity provider.
• You want browser-based SSO.
• You want Authentik to enforce MFA and authentication policies.
• You want to integrate Wazuh into a broader SSO ecosystem.
• You want standardized OIDC discovery and token-based authentication.

LDAP may be preferable when:

• Your organization already relies heavily on LDAP or Active Directory.
• Applications are primarily designed around directory authentication.
• You need direct access to LDAP directory attributes.
• Introducing OIDC would add unnecessary architectural complexity.

Wazuh’s LDAP implementation also supports Active Directory, making LDAP particularly relevant in environments where the existing directory is already the authoritative identity source.

See How to Configure Wazuh LDAP Authentication for a dedicated LDAP implementation guide.

Wazuh Authentik OIDC vs SAML

OIDC and SAML are both established federation protocols, but OIDC uses JSON and JWT-based mechanisms built around OAuth 2.0, while SAML uses XML-based assertions.

For a modern web application, OIDC can be easier to integrate and troubleshoot because the authentication flow exposes standardized HTTP endpoints and JSON-based metadata.

Authentik supports both OIDC and SAML providers.

Choose OIDC when:

• Wazuh supports the required OIDC configuration.
• Authentik is already deployed.
• You want modern token-based federation.
• You want OIDC discovery.
• You want straightforward integration with modern identity-aware applications.

Choose SAML when:

• An existing enterprise identity architecture is based on SAML.
• Other applications already use SAML and you want consistency.
• Your Wazuh deployment specifically requires SAML.
• Your identity provider has established SAML policies and tooling.

SAML remains a valid enterprise federation protocol, but there is generally little reason to introduce it solely for Wazuh when a well-supported OIDC architecture already meets the requirements.

See How to Configure Wazuh SAML Authentication for the SAML approach.

Authentik vs Keycloak for Wazuh

Both Authentik and Keycloak can serve as centralized identity platforms for Wazuh.

The choice should therefore be based on the organization’s identity requirements rather than assuming one product is universally better.

Authentik provides OAuth2/OIDC, SAML, LDAP, and other provider types and can act as an OpenID Provider for applications.

Keycloak is another mature open-source identity and access-management platform with extensive federation, identity-provider, client, realm, and role-management capabilities.

For a Wazuh deployment, Authentik may be attractive when:

• You already operate Authentik.
• You want a relatively straightforward self-hosted SSO platform.
• You want OIDC and SAML support in the same identity layer.
• You want Authentik’s application and policy model.

Keycloak may be attractive when:

• Your organization already standardizes on Keycloak.
• You require Keycloak’s realm and federation architecture.
• Existing applications and teams already have Keycloak expertise.
• You want to reuse an established Keycloak identity infrastructure.

The best choice is usually the platform that already fits your identity architecture and operational model.

See How to Integrate Keycloak with Wazuh for a Keycloak-specific implementation.

When OIDC Is the Better Choice

OIDC is generally a strong choice when Wazuh and the identity provider can use a standard authorization-code workflow.

It is particularly useful when you want:

• Browser-based SSO.
• Centralized authentication.
• MFA enforced by the identity provider.
• Standardized claims.
• Group-based role mapping.
• OIDC discovery.
• Modern token-based authentication.

Authentik’s OAuth2 provider supports OIDC and authorization-code flows, and its discovery document exposes the endpoints required by an OIDC client.

For a new Wazuh Authentik deployment, OIDC therefore provides a clean way to connect Wazuh to Authentik without requiring Wazuh to become the primary identity store.

When LDAP May Be Preferable

LDAP may be the better choice when the organization already has an established LDAP or Active Directory environment and does not need an additional OIDC layer.

LDAP can be especially practical when:

• Active Directory is already authoritative.
• Existing applications authenticate directly against LDAP.
• Directory groups already define application access.
• Administrators are experienced with LDAP.
• The organization does not want to introduce another identity-provider dependency.

The trade-off is that LDAP-based authentication is more directly tied to directory infrastructure, whereas OIDC allows Wazuh to consume identity information through a modern federation protocol.

How to Maintain Wazuh Authentik Integration

An SSO integration should be treated as production security infrastructure rather than a one-time configuration task.

Changes to certificates, client credentials, Authentik providers, Wazuh releases, user groups, and role mappings can all affect authentication.

Establish a maintenance schedule and document the configuration before deploying it to production.

Client-Secret Rotation

The OIDC client secret should be rotated whenever there is a reasonable possibility that it has been exposed or when organizational security policy requires periodic rotation.

A controlled rotation process is:

1. Generate a replacement secret in Authentik.
2. Record the new secret securely.
3. Update the corresponding Wazuh configuration.
4. Apply the Wazuh configuration.
5. Test authentication.
6. Revoke or retire the previous credential when appropriate.

Avoid rotating credentials during an unplanned outage unless necessary.

Maintain a documented rollback procedure in case the new secret is entered incorrectly.

Certificate Renewal

Monitor the certificates used by both Wazuh and Authentik.

Certificate renewal should cover:

• Authentik’s HTTPS certificate.
• Wazuh Dashboard’s HTTPS certificate.
• Intermediate certificates.
• Internal CA certificates where applicable.
• Certificates used for signing OIDC tokens, if applicable.

An expired certificate can make a previously working OIDC integration fail without any changes to the Wazuh configuration.

After renewal, verify the complete authentication flow rather than checking only whether the web page loads.

See How to Fix Wazuh Certificate Errors for certificate-related troubleshooting.

Authentik Provider Changes

Treat changes to the Authentik provider as potentially breaking changes.

Before changing:

• Provider slug
• Issuer mode
• Client ID
• Client secret
• Redirect URIs
• Signing keys
• Scopes
• Claims
• User or group policies

document the current configuration.

This is particularly important because Authentik’s default per-provider issuer mode derives the issuer from the application/provider slug.

Changing provider-related identifiers can therefore affect issuer and discovery URLs.

After any provider change, test authentication using a dedicated account.

Wazuh Configuration Updates

Wazuh upgrades can change configuration syntax, authentication behavior, supported parameters, or the location of relevant configuration settings.

Before upgrading:

1. Back up the current Wazuh configuration.
2. Record the Authentik provider configuration.
3. Document the redirect URI.
4. Record the client ID and provider details.
5. Document role mappings.
6. Review the Wazuh release notes and documentation.
7. Test the integration after upgrading.

Do not assume that an authentication configuration from an older Wazuh release should be copied unchanged into a newer installation.

See The Complete Wazuh Single Sign-On (SSO) Guide for broader SSO administration guidance.

User and Group Management

Manage Wazuh access primarily through the identity-provider groups rather than creating unnecessary individual exceptions.

For example:

wazuh-admins
wazuh-analysts
wazuh-readonly

can provide a clear access model.

When a user’s responsibilities change, update their Authentik group membership and then verify the resulting Wazuh permissions.

When a user leaves the organization, disable their Authentik account or remove their access to the Wazuh application promptly.

Role-Mapping Reviews

Review role mappings regularly.

Look specifically for:

• Unused external groups.
• Broad administrator mappings.
• Duplicate mappings.
• Groups that no longer exist.
• Unexpected role assignments.
• Users receiving higher privileges than intended.

A simple access review should answer:

Which Authentik groups can access Wazuh, and which Wazuh roles can those groups receive?

If that answer cannot be determined quickly from the configuration, the authorization architecture probably needs simplification.

See How to Configure Wazuh SSO Role Mapping.

Monitoring Authentication Logs

Monitor authentication-related events in both Wazuh and Authentik.

Investigate:

• Repeated authentication failures.
• Invalid-client errors.
• Unexpected login locations.
• Repeated token-validation failures.
• Changes to privileged groups.
• Unexpected administrator logins.
• Certificate or TLS failures.

Authentication logs are particularly valuable when troubleshooting intermittent SSO problems because they allow you to determine whether the failure occurred before or after Authentik authenticated the user.

Backup and Disaster Recovery

Include the Wazuh Authentik integration in your disaster-recovery plan.

Back up or document:

• Wazuh authentication configuration.
• Wazuh role mappings.
• Authentik application configuration.
• Authentik provider configuration.
• Required certificates.
• Identity-provider group structure.
• Client identifiers.
• Recovery procedures.

Do not store client secrets or private keys in an unencrypted backup.

Also maintain an emergency administrative access procedure.

If Authentik becomes unavailable, administrators need a documented method for restoring access to Wazuh without depending on the failed SSO path.

Frequently Asked Questions

Question: What Is Wazuh Authentik?

Wazuh Authentik refers to integrating Wazuh with Authentik so that Authentik can participate as the external identity provider for Wazuh authentication.

With an OIDC implementation, Authentik authenticates the user and provides identity information to Wazuh, while Wazuh applies its own authorization and role configuration.

Question: Does Wazuh Support Authentik?

Yes. Wazuh currently provides an official documentation page specifically describing how to integrate Authentik with Wazuh for Single Sign-On and how to map Authentik roles to Wazuh roles.

Question: Can Wazuh Integrate With Authentik Using OIDC?

Yes. Authentik provides an OAuth2/OpenID Connect provider that can act as the OpenID Provider for an application.

Its OIDC implementation includes standard authorization-code functionality, discovery metadata, token endpoints, UserInfo, and JWKS functionality.

Wazuh’s current Authentik integration documentation also documents Authentik as an identity provider for Wazuh SSO.

Question: Does Authentik Provide SSO for Wazuh?

Yes. Authentik can provide the centralized authentication layer for Wazuh.

The resulting architecture allows users to authenticate through Authentik and then access Wazuh according to the permissions assigned through the Wazuh authorization configuration.

Question: How Do I Configure Authentik as a Wazuh Identity Provider?

The general process is:

1. Create an Authentik application.
2. Create an OAuth2/OIDC provider.
3. Configure the client ID and secret.
4. Configure the Wazuh redirect URI.
5. Configure scopes and claims.
6. Configure Authentik users and groups.
7. Configure Wazuh’s OIDC authentication settings.
8. Configure Wazuh role mappings.
9. Test authentication and authorization.

The exact configuration values depend on your Wazuh and Authentik versions.

Question: What Redirect URI Does Wazuh Use With Authentik?

The redirect URI is the Wazuh OIDC callback endpoint configured for your Wazuh version and authentication architecture.

Do not use a generic Authentik callback URL or guess the path.

The URI registered in Authentik must exactly match the callback expected by Wazuh, including:

• Scheme
• Host
• Port
• Path
• Trailing slash

Authentik explicitly validates redirect URIs supplied by the OIDC client.

Question: How Do I Map Authentik Groups to Wazuh Roles?

First, configure Authentik to return the user’s group information through the appropriate OIDC claim.

Then configure Wazuh role mappings to associate the returned external group or backend role with the desired Wazuh role.

For example:

wazuh-admins
      ↓
administrator

wazuh-readonly
      ↓
readonly

Wazuh’s official Authentik integration documentation demonstrates this general role-mapping approach.

Related Guide: See How to Configure Wazuh SSO Role Mapping.

Question: Can I Use MFA With Wazuh Authentik SSO?

Yes. MFA can be enforced through Authentik’s authentication flows and policies.

This means Authentik can require additional authentication factors before completing the Wazuh OIDC authentication transaction.

For privileged Wazuh accounts, MFA is particularly valuable because compromising the user’s password alone should not necessarily be sufficient to authenticate.

Question: Why Is Wazuh Authentik Login Not Working?

Start by identifying where the authentication flow fails.

Check:

1. Wazuh Dashboard availability.
2. Authentik availability.
3. DNS resolution.
4. HTTPS certificates.
5. OIDC discovery.
6. Client ID.
7. Client secret.
8. Redirect URI.
9. Issuer.
10. OIDC scopes and claims.
11. Wazuh role mappings.

If the user can authenticate successfully in Authentik but cannot access Wazuh afterward, focus on claims, backend roles, role mappings, and Wazuh authorization rather than the initial login credentials.

Related Guide: See How to Fix Wazuh SSO Login Error.

Question: Why Does Wazuh Redirect Back to the Login Page?

A login loop can occur when Wazuh cannot establish or maintain the authenticated session after the Authentik authentication succeeds.

Check:

• Redirect URI.
• Issuer.
• Token validation.
• Client credentials.
• Claims.
• Browser cookies.
• Reverse-proxy configuration.
• Wazuh Dashboard authentication settings.

Testing in a private browser window can help determine whether stale cookies or an existing session are contributing to the problem.

Question: Why Are Authentik Groups Not Appearing in Wazuh?

The most common causes are:

• Groups are not included in the OIDC response.
• The required Authentik scope is not requested.
• The claim name is incorrect.
• The group membership is not being returned by the provider.
• Wazuh is reading a different claim.
• The Wazuh role mapping does not match the returned group value.

Remember that creating an Authentik group does not automatically create a Wazuh role.

The identity information must be returned through OIDC and then mapped to the appropriate Wazuh authorization configuration.

Question: How Do I Troubleshoot Wazuh OIDC Authentication?

Troubleshoot from the outside inward:

DNS
 ↓
HTTPS/TLS
 ↓
OIDC discovery
 ↓
Authorization endpoint
 ↓
Authentik authentication
 ↓
Redirect URI
 ↓
Token exchange
 ↓
Claims
 ↓
Wazuh role mapping
 ↓
Authorization

Testing each stage independently is much more effective than changing multiple OIDC settings at once.

See How to Configure Wazuh OIDC and How to Fix Wazuh SSO Login Error.

Question: Is Authentik Better Than Keycloak for Wazuh?

Neither is universally better.

Authentik can be an excellent choice if you already use it or want its application, policy, and provider architecture.

Keycloak may be preferable when your organization already has a Keycloak-based identity architecture, existing realms and federation, or established operational expertise.

For Wazuh specifically, choose the identity provider that best fits your existing authentication architecture, operational requirements, security controls, and maintenance capabilities.

See How to Integrate Keycloak with Wazuh.

Question: Can Authentik Manage Wazuh User Access?

Yes, but it is important to distinguish application access from Wazuh permissions.

Authentik can control which users and groups are permitted to authenticate to the Wazuh application.

Wazuh then uses its own roles, policies, and role mappings to determine what authenticated users can do inside the platform.

A well-designed architecture therefore looks like:

Authentik
    ↓
Who can authenticate?

Wazuh
    ↓
What can they access and modify?

This separation allows identity lifecycle and application authorization to be managed centrally without eliminating Wazuh’s own access-control model.

Conclusion

A Wazuh Authentik integration provides a practical way to connect Wazuh to a centralized identity and access-management architecture.

With OIDC, Authentik can handle user authentication while Wazuh consumes the resulting identity information and applies its own authorization policies.

The integration is more than simply connecting two login pages.

A production deployment requires coordination between the Authentik application and provider configuration, Wazuh OIDC settings, redirect URIs, claims, groups, role mappings, certificates, and security policies.

Recap of the Wazuh Authentik Integration

The core workflow is:

User
 ↓
Wazuh Dashboard
 ↓
Authentik
 ↓
OIDC authentication
 ↓
Authorization code
 ↓
Token exchange
 ↓
Identity claims
 ↓
Wazuh role mapping
 ↓
Wazuh permissions

Each stage has a specific responsibility.

Authentik verifies the user’s identity and controls access to the application. OIDC transports the authentication and identity information.

Wazuh maps the resulting identity to its authorization model.

Benefits of Centralized Authentication

Centralizing authentication through Authentik can provide:

• Single Sign-On
• Centralized authentication policies
• MFA integration
• Centralized user lifecycle management
• Group-based access management
• Reduced dependence on application-specific passwords
• Consistent identity management across applications

Authentik’s OIDC provider supports standard OAuth2/OIDC functionality and exposes the discovery and protocol endpoints needed for standards-based integrations.

Importance of Role and Group Mapping

Successful authentication does not automatically mean appropriate Wazuh access.

The most important authorization relationship is:

Authentik group
      ↓
OIDC group/backend-role claim
      ↓
Wazuh role mapping
      ↓
Wazuh permissions

Use dedicated groups such as wazuh-admins, wazuh-analysts, and wazuh-readonly to make the access model easier to understand and audit.

Avoid granting administrator privileges simply because a user successfully authenticated through Authentik.

See Mastering Wazuh Security: The Complete Access Control Guide for a comprehensive overview of Wazuh authorization.

Security and Maintenance Recommendations

Finally, treat the integration as part of your security infrastructure.

Use HTTPS, protect client secrets, enforce strong authentication and MFA where appropriate, restrict application access to approved groups, minimize OIDC scopes, monitor authentication activity, review role mappings, maintain certificates, and keep both Wazuh and Authentik updated.

Back up the relevant configuration and maintain an emergency access procedure so that an Authentik outage or configuration error does not permanently prevent administrative access to Wazuh.

With these controls in place, Authentik can provide a centralized identity layer for Wazuh while Wazuh retains control over the permissions and security data that users can access.