Modern Security Operations Centers (SOCs) rely on dozens of security tools every day, from endpoint detection platforms and vulnerability scanners to SIEM and XDR solutions. As organizations grow, managing separate usernames, passwords, and user permissions for every application quickly becomes inefficient and introduces unnecessary security risks. This is where integrating Wazuh with Okta becomes valuable.

Centralized identity management allowing administrators to authenticate users through a trusted Identity Provider (IdP) while enforcing consistent access policies across the organization.

Instead of maintaining local Wazuh user accounts, administrators can delegate authentication to Okta, enabling security analysts, incident responders, and administrators to sign in using their existing corporate identities.

The result is a more secure, scalable, and manageable authentication architecture that supports enterprise security best practices.

A Wazuh Okta integration enables organizations to:

• Centralize authentication through a trusted Identity Provider
• Enable Single Sign-On (SSO) for faster and simpler access
• Enforce Multi-Factor Authentication (MFA)
• Apply conditional access policies based on user risk
• Automatically provision and deprovision users
• Synchronize user groups with Wazuh Role-Based Access Control (RBAC)
• Improve compliance with centralized audit logging
• Reduce password-related security incidents

Depending on your environment, Wazuh can integrate with Okta using either SAML 2.0 or OpenID Connect (OIDC), allowing organizations to select the authentication protocol that best aligns with their security architecture.

Throughout this guide, you’ll learn how each authentication method works, how to configure the integration, map Okta groups to Wazuh roles, troubleshoot common issues, and implement security best practices for production deployments.

What Is Okta?

Okta is a cloud-based Identity and Access Management (IAM) platform that helps organizations securely authenticate users and manage access to applications, cloud services, APIs, and on-premises resources.

It acts as a centralized Identity Provider (IdP), allowing users to authenticate once and securely access multiple applications without maintaining separate credentials for each one.

Rather than each application managing its own authentication database, Okta becomes the authoritative source for user identities.

Applications such as Wazuh trust Okta to verify user identities, issue authentication tokens, and enforce organization-wide security policies.

Today, Okta secures thousands of organizations worldwide and supports many of the authentication standards commonly used across enterprise environments, including:

• SAML 2.0
• OpenID Connect (OIDC)
• OAuth 2.0
• LDAP integration
• SCIM user provisioning
• MFA and passwordless authentication

Authentication, Authorization, and Identity Lifecycle Management

Although these terms are often used interchangeably, they perform different roles within an identity management system.

Authentication verifies who a user is.

Authorization determines what resources that authenticated user is allowed to access.

Identity lifecycle management automates user creation, modification, suspension, and deletion throughout the employee lifecycle.

When integrated with Wazuh, Okta authenticates users while Wazuh’s RBAC determines which dashboards, APIs, and administrative functions those users can access.

Single Sign-On (SSO)

Single Sign-On allows users to authenticate once with Okta and seamlessly access multiple enterprise applications without repeatedly entering passwords.

For SOC analysts who frequently switch between Wazuh, cloud consoles, ticketing systems, vulnerability scanners, and threat intelligence platforms, SSO dramatically improves productivity while reducing password reuse.

Organizations also benefit because authentication policies are enforced centrally instead of separately for every application.

Multi-Factor Authentication (MFA)

Okta supports multiple MFA methods including:

• Okta Verify
• FIDO2 security keys
• Passkeys
• Push notifications
• TOTP authenticator applications
• SMS (less preferred for high-security environments)
• Hardware tokens

According to guidance from the Cybersecurity and Infrastructure Security Agency, phishing-resistant MFA provides substantially stronger protection than password-only authentication and should be prioritized wherever possible.

Adaptive Authentication and Conditional Access

One of Okta’s strongest enterprise features is adaptive authentication.

Rather than treating every login equally, Okta evaluates contextual information such as:

• User location
• Device trust
• IP reputation
• Time of access
• User behavior
• Risk score
• Network location

Based on these signals, Okta can require additional authentication, deny access, or allow seamless login.

For example, a security analyst connecting from a managed corporate workstation may authenticate using SSO alone, while the same user attempting access from an unfamiliar country may be required to complete phishing-resistant MFA or be blocked entirely.

Universal Directory and Group Management

Okta Universal Directory provides a centralized identity store for users, groups, devices, and attributes.

Instead of maintaining user accounts separately inside every application, administrators manage identities once within Okta and synchronize group membership across connected services.

For Wazuh, this enables administrators to map Okta groups such as:

• SOC Analysts
• Incident Responders
• Threat Hunters
• Security Engineers
• Compliance Auditors
• Wazuh Administrators

to corresponding Wazuh RBAC roles, reducing manual permission management.

Why Organizations Use Okta for Enterprise Identity

Large organizations often manage thousands of employees, contractors, and service accounts spread across hundreds of applications.

Okta simplifies identity management by providing:

• Centralized authentication
• Enterprise-grade SSO
• MFA enforcement
• Automated onboarding and offboarding
• Centralized policy management
• Detailed authentication auditing
• Integration with cloud and on-premises applications
• Support for Zero Trust security architectures

For organizations already using Okta as their enterprise identity platform, integrating Wazuh allows security teams to extend these identity controls into their SIEM and XDR environment without maintaining another isolated authentication system.

Why Integrate Wazuh with Okta?

Organizations deploying Wazuh across enterprise environments often have dozens, or even hundreds, of analysts, administrators, auditors, and incident responders accessing the platform.

Managing local Wazuh accounts for every user quickly becomes difficult, particularly as teams grow or personnel change roles.

Integrating Wazuh with Okta centralizes identity management while improving security, simplifying administration, and ensuring consistent access controls across the entire security ecosystem.

Centralized Authentication

Instead of authenticating directly against locally managed Wazuh credentials, users authenticate through Okta.

This creates a single trusted identity source for:

• User authentication
• Password policies
• MFA enforcement
• Account status
• User attributes

Administrative overhead is significantly reduced because user management occurs in one location.

Single Sign-On for Security Teams

Security analysts commonly switch between multiple security platforms during investigations.

Single Sign-On allows them to authenticate once and access authorized applications, including Wazuh, without repeatedly entering credentials.

This streamlines analyst workflows while reducing password reuse and help desk requests for password resets.

Stronger Security Through MFA

Credential theft remains one of the most common initial access techniques observed in modern attacks.

Okta enables organizations to require MFA before granting access to Wazuh, significantly reducing the likelihood that compromised passwords alone can be used to access sensitive security monitoring systems.

Simplified User Provisioning

When employees join the organization, administrators simply assign them to the appropriate Okta groups.

Access to Wazuh can then be granted automatically based on predefined role mappings, eliminating repetitive manual account creation.

Centralized User Lifecycle Management

Identity lifecycle management becomes much simpler when users change departments or leave the organization.

Administrators can:

• Disable access immediately
• Remove group memberships
• Revoke sessions
• Apply new permissions automatically

This helps reduce orphaned accounts and excessive privileges.

Improved Compliance and Auditing

Many compliance frameworks require organizations to demonstrate:

• Centralized identity management
• Strong authentication
• Access logging
• User accountability
• Least privilege access

Because authentication events occur through Okta, administrators gain centralized audit trails that simplify investigations and compliance reporting.

The National Institute of Standards and Technology Digital Identity Guidelines recommend centralized identity assurance, strong authentication, and lifecycle management as foundational identity security practices.

Reduced Password Fatigue

Analysts no longer need separate passwords for Wazuh.

Instead, users authenticate using their existing enterprise identity, reducing password fatigue and lowering the likelihood of insecure password practices.

Consistent Access Policies Across Applications

Security policies can be applied consistently across the organization’s technology stack.

Examples include:

• Mandatory MFA
• Device trust requirements
• Conditional access
• Session timeout policies
• Password policies
• Geographic restrictions

Rather than configuring these individually inside every application, administrators manage them centrally within Okta.

Better Scalability for Enterprise Deployments

As organizations expand, manually maintaining authentication for every application becomes increasingly difficult.

Okta scales identity management across thousands of users while allowing Wazuh administrators to focus on security operations instead of account administration.

Related Guides:

• How to Configure Wazuh SSO
• How to Configure Wazuh SAML Authentication
• How to Configure Wazuh OIDC

Authentication Methods Supported by Wazuh

Wazuh supports modern federated authentication standards that integrate seamlessly with enterprise Identity Providers such as Okta.

The two primary authentication methods are SAML 2.0 and OpenID Connect (OIDC).

Selecting the appropriate protocol depends on your organization’s existing identity architecture, security requirements, and long-term cloud strategy.

SAML 2.0 Authentication

Security Assertion Markup Language (SAML) is an XML-based authentication standard that has been widely adopted across enterprise environments for many years.

With SAML:

1. A user requests access to Wazuh.
2. Wazuh redirects the user to Okta.
3. Okta authenticates the user.
4. Okta returns a signed SAML assertion.
5. Wazuh validates the assertion.
6. The user is granted access based on mapped roles.

Advantages include:

• Mature enterprise support
• Broad compatibility
• Strong security
• Extensive documentation
• Excellent integration with traditional enterprise applications

SAML remains an excellent choice for organizations already using SAML across their enterprise application portfolio.

OpenID Connect (OIDC)

OpenID Connect builds on OAuth 2.0 and uses JSON Web Tokens (JWTs) instead of XML assertions.

OIDC generally provides:

• Simpler implementation
• Modern REST-based architecture
• Lightweight token exchange
• Better support for cloud-native applications
• Improved developer experience
• Easier API integration

Because of its modern architecture, many organizations deploying new identity infrastructures now prefer OIDC for newly integrated applications.

Which Authentication Method Should You Choose?

For most organizations, either authentication protocol provides strong enterprise security when configured correctly.

Your choice usually depends on:

• Existing identity infrastructure
• Current enterprise standards
• Cloud adoption strategy
• Application compatibility
• Administrative experience
• Long-term modernization goals

Organizations already invested in SAML often continue using it successfully, while cloud-first environments increasingly standardize on OIDC for new deployments.

Comparison Table

Enterprise Recommendations

Most enterprise environments should follow these general recommendations:

• Use OIDC for new cloud-native deployments whenever supported.
• Continue using SAML if it is already standardized across your enterprise.
• Map Okta groups directly to Wazuh RBAC roles instead of assigning permissions individually.
• Require MFA for all privileged Wazuh users.
• Regularly review role assignments and inactive accounts.
• Test authentication changes in a staging environment before production rollout.

Related Guides:

• How to Configure Wazuh OIDC
• How to Configure Wazuh SAML Authentication

Security Considerations

Regardless of which protocol you choose, follow identity security best practices:

• Require phishing-resistant MFA where possible.
• Enforce least-privilege RBAC mappings.
• Use short-lived sessions with appropriate timeout values.
• Securely manage signing certificates and client secrets.
• Rotate credentials and certificates before expiration.
• Monitor authentication logs for suspicious activity.
• Restrict administrative access using conditional access policies.
• Periodically review group memberships and privileged accounts.

These practices align with Zero Trust guidance from CISA and NIST, helping ensure that your Wazuh authentication infrastructure remains resilient against credential-based attacks while maintaining operational efficiency.

Prerequisites

Before integrating Wazuh with Okta, verify that both environments are properly prepared.

Completing these prerequisites helps prevent common authentication errors such as invalid redirect URIs, certificate validation failures, clock skew issues, and failed user authentication.

Although the exact configuration differs depending on whether you use SAML 2.0 or OpenID Connect (OIDC), the following requirements apply to both authentication methods.

Supported Wazuh Versions

Use a supported and up-to-date version of Wazuh before configuring external authentication.

Newer Wazuh releases include:

• Improved authentication capabilities
• Enhanced security updates
• Better compatibility with modern Identity Providers
• Bug fixes for Dashboard authentication
• Updated OpenSearch security components

Running an outdated version may lead to unsupported authentication settings or compatibility issues with newer Okta features.

Before beginning the integration:

• Upgrade Wazuh if necessary.
• Verify release notes for authentication-related changes.
• Confirm compatibility with your OpenSearch Dashboard version.

Related Guide: How to Upgrade a Wazuh Agent (for agent upgrades if your deployment is also being updated)

Okta Administrator Privileges

You’ll need administrative permissions within your Okta tenant to create and configure an application integration.

Typical permissions include:

• Creating applications
• Configuring SAML or OIDC settings
• Managing certificates
• Creating client credentials
• Assigning users
• Assigning groups
• Viewing authentication logs

Without sufficient privileges, you may be unable to complete the application configuration or assign users to Wazuh.

Wazuh Dashboard Administrative Access

You should also have administrator access to the Wazuh Dashboard.

This is required to:

• Modify authentication settings
• Configure identity providers
• Update security configuration
• Test authentication
• Configure RBAC mappings
• Restart required services

Having console or SSH access to the Wazuh server is also recommended in case configuration files need to be edited manually.

HTTPS Configured on Wazuh Dashboard

Federated authentication requires HTTPS.

Okta expects secure endpoints for:

• Login requests
• Assertion Consumer Service (ACS) endpoints
• OIDC callback URLs
• Logout endpoints

Using HTTPS protects:

• Authentication tokens
• Session cookies
• SAML assertions
• JWT access tokens

Avoid configuring authentication over plain HTTP in production environments.

DNS and Certificates

Ensure DNS records correctly resolve your Wazuh Dashboard hostname.

For example:

https://wazuh.company.com

The SSL/TLS certificate should:

• Be issued by a trusted Certificate Authority (CA)
• Match the configured hostname
• Not be expired
• Include the full certificate chain

Certificate mismatches are among the most common causes of failed SAML and OIDC authentication.

Time Synchronization (NTP)

Accurate system time is essential for identity federation.

SAML assertions and OIDC tokens contain timestamps that define when they become valid and when they expire.

Even a few minutes of clock drift between Wazuh and Okta can cause authentication failures.

Use Network Time Protocol (NTP) to synchronize:

• Wazuh Manager
• Wazuh Dashboard
• OpenSearch nodes
• Reverse proxies
• Domain controllers (if applicable)

Keeping all systems synchronized minimizes token validation errors and improves overall authentication reliability.

Backup Existing Authentication Configuration

Before making authentication changes, back up your current configuration.

Depending on your deployment, this may include:

• Dashboard authentication settings
• OpenSearch security configuration
• Certificates
• Identity provider settings
• RBAC configuration
• Role mappings

If the integration does not work as expected, a backup allows you to quickly restore the previous authentication method and reduce downtime.

Related Guide: How to Backup Wazuh Manager Configuration

Test Environment Recommendations

Whenever possible, configure and validate the integration in a staging environment before deploying to production.

A test environment allows you to verify:

• Successful authentication
• Group-to-role mappings
• MFA enforcement
• Logout behavior
• Session timeouts
• Administrative access
• Failover and rollback procedures

Testing beforehand significantly reduces the risk of locking administrators out of the production Wazuh Dashboard.

How Wazuh Authentication Works with Okta

Understanding the authentication workflow makes troubleshooting much easier and helps administrators identify where authentication failures occur.

Although SAML and OIDC exchange different types of authentication data, both follow the same high-level process:

1. A user attempts to access Wazuh.
2. Wazuh redirects the user to Okta.
3. Okta authenticates the user.
4. Okta returns proof of authentication.
5. Wazuh validates the response.
6. Wazuh applies RBAC permissions.
7. The user gains access to authorized resources.

Authentication Flow Overview

The authentication sequence typically follows these steps:

1. User browses to the Wazuh Dashboard.
2. Wazuh detects that external authentication is enabled.
3. User is redirected to Okta.
4. Okta performs authentication.
5. MFA is requested if required.
6. Okta returns a signed authentication response.
7. Wazuh validates the response.
8. User identity is established.
9. Wazuh assigns RBAC permissions.
10. A secure session is created.

This entire process usually completes within a few seconds.

Identity Provider (Okta)

Within the integration, Okta acts as the Identity Provider (IdP).

Its responsibilities include:

• Authenticating users
• Enforcing password policies
• Performing MFA
• Evaluating conditional access policies
• Issuing SAML assertions or OIDC tokens
• Managing user lifecycle
• Maintaining user groups

Because Okta performs authentication, Wazuh no longer needs to store or validate user passwords directly.

Service Provider (Wazuh Dashboard)

The Wazuh Dashboard functions as the Service Provider (SP).

Its responsibilities include:

• Redirecting users to Okta
• Receiving authentication responses
• Validating signatures or tokens
• Establishing user sessions
• Applying RBAC authorization
• Managing application sessions

Rather than authenticating users itself, the Dashboard trusts Okta to verify identities.

Token/Assertion Exchange

The authentication response differs depending on the selected protocol.

SAML 2.0

• XML-based signed assertion
• Contains identity attributes
• Includes user group information (if configured)
• Digitally signed by Okta

OpenID Connect

• ID Token (JWT)
• Access Token
• Optional Refresh Token
• User claims
• JSON-based payload

Regardless of protocol, Wazuh validates the authenticity of the response before granting access.

Session Establishment

Once authentication succeeds, Wazuh establishes a secure authenticated session.

This session typically includes:

• Authenticated username
• Assigned roles
• Session expiration
• Security context
• User claims

Subsequent requests use this established session until it expires or the user signs out.

RBAC Authorization After Authentication

Authentication answers the question:

Who are you?

Authorization answers:

What are you allowed to do?

After Okta authenticates the user, Wazuh evaluates the user’s assigned roles.

These roles determine access to features such as:

• Dashboard views
• Agent management
• Rules management
• API access
• Index management
• Administrative settings
• Reporting capabilities

A common enterprise approach is to map Okta groups (for example, SOC Analysts, Tier 2 Responders, or Wazuh Administrators) to predefined Wazuh RBAC roles, ensuring permissions remain centrally managed.

Related Guide: How to Configure Wazuh LDAP Authentication (for additional identity and RBAC concepts)

Logout Flow

When a user signs out, the logout process should terminate both the Wazuh session and the associated identity session where appropriate.

A complete logout flow typically:

• Ends the Wazuh Dashboard session
• Invalidates authentication tokens (OIDC)
• Ends the SAML session (if configured)
• Redirects the user to Okta
• Prevents reuse of expired sessions

Proper logout configuration reduces the risk of session hijacking and unauthorized access on shared or unattended workstations.

Configure an Okta Application for Wazuh

The first configuration step within Okta is creating an application that represents the Wazuh Dashboard.

This application defines how authentication requests are exchanged, where users are redirected after signing in, and which users or groups are allowed to access Wazuh.

While some settings differ between SAML 2.0 and OpenID Connect, the overall setup process is similar.

Create a New Application

Sign in to the Okta Admin Console and navigate to the Applications section.

Create a new application integration and select the authentication protocol you intend to use:

• SAML 2.0 for SAML-based authentication
• OpenID Connect (OIDC) for modern token-based authentication

Provide a descriptive application name such as:

• Wazuh Dashboard
• Wazuh Production
• Enterprise Wazuh
• SOC Wazuh

If you manage separate environments, create distinct applications for development, staging, and production to keep authentication settings isolated.

Configure Redirect URLs

Redirect URLs tell Okta where authenticated users should be sent after a successful login.

For OIDC, you’ll configure one or more authorized callback (redirect) URIs that point to the Wazuh Dashboard.

These URLs must exactly match the values expected by Wazuh, including:

• Protocol (https)
• Hostname
• Port (if non-default)
• Path
• Trailing slashes, where applicable

Even minor differences, such as an incorrect port or missing trailing slash, can cause authentication to fail with redirect URI mismatch errors.

Configure Login URLs

Specify the URL that users should access when initiating authentication with Wazuh.

Typical login settings include:

• Application login URL
• Initiate login behavior
• Default landing page
• Post-authentication redirect

Ensure these URLs use the production hostname that users normally access, rather than temporary IP addresses or localhost values.

Configure Sign-On Settings

The sign-on configuration determines how Okta communicates with Wazuh during authentication.

Depending on the selected protocol, you’ll configure settings such as:

• Assertion Consumer Service (ACS) URL (SAML)
• Audience URI / Entity ID (SAML)
• Issuer URI
• Response type (OIDC)
• Requested scopes (OIDC)
• NameID or user identifier mapping
• Attribute or claim mappings
• Optional group claims for RBAC

Review each value carefully, as incorrect identifiers are a frequent source of authentication failures.

Configure Certificates (SAML)

For SAML integrations, Okta digitally signs authentication assertions using an X.509 certificate.

Wazuh uses the corresponding public certificate to verify that incoming assertions:

• Originate from your Okta tenant
• Have not been modified in transit
• Are still valid

Administrators should also establish a certificate rotation process before expiration to avoid unexpected authentication outages.

Configure Client ID and Client Secret (OIDC)

OIDC applications rely on client credentials rather than signing certificates.

When the application is created, Okta generates:

• Client ID
• Client Secret

These credentials uniquely identify the Wazuh application during authentication and token exchanges.

Treat the Client Secret as sensitive information:

• Store it securely.
• Limit access to administrators.
• Rotate it periodically.
• Replace it immediately if exposure is suspected.

Assign Users and Groups

The final step is assigning who can use the application.

Rather than assigning individual users, most organizations assign groups that correspond to operational roles, such as:

• SOC Analysts
• Incident Responders
• Security Engineers
• Threat Hunters
• Compliance Auditors
• Wazuh Administrators

Using groups simplifies onboarding and offboarding while ensuring users automatically receive the appropriate level of access when their organizational role changes.

Later in the Wazuh configuration, these Okta groups can be mapped directly to Wazuh RBAC roles, enabling centralized authorization management.

Related Guides:

• How to Configure Wazuh OIDC
• How to Configure Wazuh SAML Authentication
•  How to Set Up Wazuh Multi-Tenancy

Configure Wazuh for Okta Authentication

After creating and configuring your Okta application, the next step is configuring Wazuh to trust Okta as its Identity Provider (IdP).

The exact configuration depends on whether you choose SAML 2.0 or OpenID Connect (OIDC), but both methods involve exchanging trust information, defining authentication endpoints, and validating user identities before access is granted.

Before making any authentication changes, ensure you have console or SSH access to the Wazuh server so you can recover the system if a configuration error prevents Dashboard logins.

Configure SAML Authentication

SAML authentication establishes a trust relationship between Okta (Identity Provider) and the Wazuh Dashboard (Service Provider).

The overall process consists of:

1. Configuring Wazuh as a Service Provider.
2. Importing Okta metadata.
3. Defining trusted certificates.
4. Configuring Assertion Consumer Service (ACS) URLs.
5. Configuring Single Logout (SLO).
6. Testing authentication.

Related Guide: How to Configure Wazuh SAML Authentication

Required Configuration Files

Depending on your deployment architecture, you’ll update the authentication settings used by the Wazuh Dashboard and the underlying OpenSearch Security configuration.

Typical configuration includes:

• Identity Provider metadata
• Service Provider identifiers
• Signing certificates
• ACS endpoints
• Logout endpoints
• User attribute mappings

Always back up existing configuration files before making changes so you can quickly restore the previous authentication method if necessary.

Metadata Import

Okta publishes metadata describing the Identity Provider.

This metadata typically contains:

• Identity Provider Entity ID
• SSO endpoint
• Single Logout endpoint
• Signing certificates
• Supported bindings
• Security capabilities

Rather than manually entering these values, importing the metadata helps ensure consistency and reduces configuration errors.

Whenever Okta rotates signing certificates or updates federation settings, refresh the imported metadata to keep both systems synchronized.

Entity IDs

Entity IDs uniquely identify both participants in the federation.

You will typically configure:

• Identity Provider Entity ID — identifies your Okta tenant.
• Service Provider Entity ID — identifies the Wazuh Dashboard.

These identifiers must match exactly on both sides. Any mismatch will usually result in authentication failures before the user reaches the Wazuh Dashboard.

Certificates

SAML authentication relies on X.509 certificates to verify that authentication assertions originate from a trusted Identity Provider.

Wazuh validates:

• Assertion signatures
• Certificate validity
• Trust chain
• Certificate expiration

Administrators should:

• Monitor certificate expiration dates.
• Rotate certificates before they expire.
• Remove unused certificates.
• Verify certificate fingerprints after updates.

Expired or mismatched certificates are among the most common causes of failed SAML logins.

Assertion Consumer Service (ACS)

The Assertion Consumer Service (ACS) endpoint receives the SAML assertion after the user successfully authenticates with Okta.

The ACS URL must exactly match the value configured in the Okta application, including:

• HTTPS protocol
• Hostname
• Port (if applicable)
• Path
• Trailing slash (where required)

Even small differences can prevent successful authentication.

Single Logout Configuration

Single Logout (SLO) allows users to terminate their authenticated session across both Wazuh and Okta.

A properly configured logout process should:

• End the Wazuh session
• Notify Okta of the logout request
• Invalidate authentication tokens or assertions
• Redirect users appropriately
• Prevent session reuse

Although optional, SLO improves security in environments where users share workstations or frequently switch between applications.

Configure OIDC Authentication

OpenID Connect (OIDC) provides a modern authentication workflow based on OAuth 2.0 and JSON Web Tokens (JWTs).

Compared to SAML, OIDC generally requires fewer configuration parameters and integrates well with cloud-native environments.

Configuring OIDC involves establishing trust between Wazuh and Okta using endpoint URLs, client credentials, and token validation settings.

Related Guide: How to Configure Wazuh OIDC

Discovery Endpoint

Most OIDC providers, including Okta, publish a discovery document that automatically exposes the provider’s configuration.

The discovery endpoint includes information such as:

• Authorization endpoint
• Token endpoint
• UserInfo endpoint
• Supported scopes
• Supported claims
• Public signing keys (JWKS)
• Issuer information

Using the discovery endpoint reduces manual configuration and ensures Wazuh uses the correct authentication endpoints.

Client Credentials

Each OIDC application includes:

• Client ID
• Client Secret

These credentials identify Wazuh during the authentication process.

Protect the Client Secret by:

• Storing it securely
• Restricting administrative access
• Rotating it periodically
• Replacing it immediately if compromised

Authorization Endpoint

The authorization endpoint is where users authenticate.

When users attempt to access Wazuh:

1. They are redirected to Okta.
2. Okta authenticates the user.
3. MFA is performed if required.
4. Authorization is granted.
5. The user is redirected back to Wazuh.

Token Endpoint

After successful authentication, Wazuh exchanges the authorization code for tokens through the token endpoint.

Common tokens include:

• ID Token
• Access Token
• Refresh Token (optional)

Wazuh validates these tokens before establishing the user session.

UserInfo Endpoint

The UserInfo endpoint provides additional user attributes that may not be included in the ID Token.

These attributes can include:

• Username
• Email address
• Display name
• Department
• Group memberships
• Custom profile attributes

This information is often used for role mapping and auditing.

Redirect URI

The Redirect URI tells Okta where users should return after successful authentication.

This value must exactly match the URI configured in the Okta application.

Common mistakes include:

• Incorrect hostname
• Missing HTTPS
• Wrong port
• Typographical errors
• Missing trailing slash

Redirect URI mismatches typically result in immediate authentication failures.

Scopes

Scopes define which user information Wazuh requests during authentication.

Common scopes include:

• openid
• profile
• email
• groups (when group-based RBAC is required)

Only request the scopes necessary for authentication and authorization to align with the principle of least privilege.

Claims Mapping

Claims map user attributes from Okta to Wazuh.

Frequently mapped claims include:

• Username
• Email
• Full name
• User ID
• Group membership
• Department
• Employee ID (optional)

Carefully verify claim names and formats, as incorrect mappings can prevent RBAC from functioning correctly even when authentication succeeds.

Restart Wazuh Services

After updating the authentication configuration, restart the required Wazuh and Dashboard services so the changes take effect.

Once services restart:

• Verify all components are healthy.
• Review startup logs for authentication errors.
• Confirm certificates loaded successfully.
• Ensure the Dashboard is accessible before testing user logins.

Related Guide: Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Verify Authentication

Before deploying to production, perform comprehensive authentication testing.

Verify that:

• Users can successfully authenticate.
• MFA functions correctly.
• Group memberships are received.
• RBAC permissions are assigned properly.
• Sessions are created successfully.
• Logout functions correctly.
• Failed login attempts are properly logged.

Testing multiple user roles helps ensure authorization behaves as expected across the organization.

Configure Role-Based Access Control (RBAC)

Authentication determines who a user is, while Role-Based Access Control (RBAC) determines what that user can do after logging in.

A well-designed RBAC model helps enforce the principle of least privilege, ensuring users only have access to the features required for their responsibilities.

Integrating Okta groups with Wazuh RBAC also centralizes permission management, making onboarding, role changes, and offboarding significantly easier.

Create Wazuh Roles

Begin by creating roles that reflect your organization’s operational responsibilities.

Common enterprise roles include:

• SOC Analyst
• Tier 2 Analyst
• Incident Responder
• Threat Hunter
• Security Engineer
• Compliance Auditor
• Read-Only User
• Wazuh Administrator

Each role should include only the permissions necessary to perform its assigned tasks.

For example, a Compliance Auditor may require access to reports and dashboards but should not be able to modify detection rules or manage agents.

Configure Okta Groups

Next, create corresponding groups within Okta.

Examples include:

• Wazuh-SOC-Analysts
• Wazuh-Incident-Response
• Wazuh-Engineers
• Wazuh-Admins
• Wazuh-Auditors

Assign users to groups based on their job responsibilities rather than granting permissions individually.

This approach simplifies user administration and ensures consistent access control across the organization.

Map Okta Groups to Wazuh Roles

Once groups exist in both platforms, configure mappings so Wazuh assigns the correct RBAC role after successful authentication.

A typical mapping might look like:

With these mappings in place, users automatically receive the correct permissions based on their Okta group membership.

If a user’s responsibilities change, updating their Okta group assignment automatically updates their access during the next login.

Least Privilege Best Practices

Least privilege remains one of the most effective strategies for reducing the impact of compromised accounts.

Follow these recommendations:

• Grant only the permissions required for each role.
• Avoid assigning administrator privileges to everyday users.
• Separate administrative and analyst accounts.
• Use dedicated groups for privileged access.
• Regularly review role assignments.
• Remove inactive users promptly.
• Limit API access to authorized personnel.
• Audit privileged accounts on a regular schedule.

These practices align with guidance from the National Institute of Standards and Technology (NIST) on access control and identity management.

Testing Role Assignments

Before rolling out the integration to production, verify that every role behaves as expected.

Create test accounts representing each role and confirm that users can:

• Access authorized dashboards.
• View only permitted agents.
• Perform allowed administrative actions.
• Access APIs when appropriate.
• Be denied restricted functions.
• Receive updated permissions after group membership changes.

Testing both successful and denied actions helps ensure your RBAC configuration enforces the intended security boundaries.

Configure Multi-Factor Authentication (MFA)

One of the primary advantages of integrating Wazuh with Okta is the ability to enforce strong Multi-Factor Authentication (MFA) policies.

Even if an attacker obtains valid credentials, MFA provides an additional layer of protection before access to the Wazuh Dashboard is granted.

Security experts, including CISA and Microsoft, recommend phishing-resistant MFA, such as FIDO2 security keys or passkeys, over SMS-based verification whenever possible.

Enable Okta Verify

Okta Verify is the platform’s primary authenticator application.

It supports:

• Push notifications
• One-time passcodes (TOTP)
• Device trust
• Fast user verification

For most organizations, Okta Verify offers the best balance of usability and security for everyday access to Wazuh.

Configure WebAuthn (FIDO2)

WebAuthn provides phishing-resistant authentication using public-key cryptography.

Supported authenticators include:

• Platform authenticators (Windows Hello, Touch ID, Face ID)
• USB security keys
• NFC security keys
• Bluetooth authenticators

Unlike passwords or SMS codes, WebAuthn credentials cannot be reused on phishing sites, making them significantly more resistant to credential theft.

Configure Push Authentication

Push authentication sends an approval request to a trusted device after the user enters their credentials.

Administrators should configure:

• Push notification timeout
• Device enrollment requirements
• Retry limits
• Geographic restrictions
• Risk-based approval policies

While convenient, users should be trained to reject unexpected approval requests to reduce the risk of MFA fatigue attacks.

Configure Security Keys

Hardware security keys offer one of the strongest available authentication methods.

Benefits include:

• Phishing resistance
• Cryptographic authentication
• No shared secrets
• Fast login experience
• Strong protection for privileged accounts

Organizations should prioritize security keys for Wazuh administrators and other highly privileged users.

Configure Adaptive MFA Policies

Adaptive MFA evaluates contextual risk before determining whether additional authentication is required.

Typical policy conditions include:

• Device trust
• User location
• IP reputation
• Network zone
• User behavior
• Time of day
• Risk score

For example, a login from a managed corporate laptop on the internal network may require only a password and device trust, while a login from an unfamiliar country could trigger FIDO2 authentication or be blocked entirely.

Test MFA Login

Before enabling MFA organization-wide, validate the complete authentication workflow.

Confirm that users can:

• Successfully authenticate with MFA.
• Register approved authenticators.
• Complete push notifications.
• Use security keys.
• Recover access using approved recovery methods.
• Authenticate under adaptive policy conditions.
• Access Wazuh after successful verification.
• Be denied access when MFA requirements are not met.

Comprehensive testing ensures your Wazuh Okta integration delivers both a secure authentication experience and minimal disruption to security operations.

User Provisioning and Lifecycle Management

Integrating Wazuh with Okta simplifies much more than authentication.

It also centralizes user provisioning, role assignments, and account lifecycle management, reducing administrative effort while helping organizations maintain consistent security controls.

Instead of manually creating, updating, and removing Wazuh accounts, administrators can manage identities within Okta and automatically apply access changes across their security environment.

User Onboarding

When a new employee joins the security team, access to Wazuh should be granted through a standardized onboarding process.

A typical workflow includes:

1. Creating the user account in Okta.
2. Assigning the appropriate security groups.
3. Enforcing Multi-Factor Authentication (MFA).
4. Applying conditional access policies.
5. Granting access to the Wazuh application.
6. Verifying successful authentication and RBAC permissions.

Because authorization is based on group membership rather than individual permissions, onboarding becomes significantly faster and less error-prone.

Group Synchronization

Group-based authorization is one of the biggest advantages of integrating Wazuh with Okta.

Instead of managing individual permissions, administrators manage group membership.

For example:

Whenever a user changes departments or responsibilities, simply updating their Okta group membership automatically changes their permissions during their next login.

This centralized approach reduces permission drift and minimizes manual administration.

Automatic Deprovisioning

One of the most important identity security controls is removing access immediately when it is no longer required.

When an employee:

• Leaves the organization
• Changes roles
• Transfers departments
• Finishes a contract
• Loses authorization

their Okta account can be disabled or removed, preventing future authentication to Wazuh.

Automatic deprovisioning helps eliminate orphaned accounts, which are a common source of unauthorized access and compliance findings.

Access Reviews

Access permissions should not remain static indefinitely.

Organizations should periodically review:

• Administrative accounts
• Privileged users
• Group memberships
• Service accounts
• API clients
• Disabled accounts
• Inactive users

Quarterly or semiannual access reviews help verify that users still require the permissions they have been granted and support compliance with frameworks such as ISO 27001, SOC 2, and PCI DSS.

Temporary Administrative Access

Permanent administrator privileges increase organizational risk.

Instead, consider granting elevated access only when required for administrative tasks.

Examples include:

• Incident response
• System upgrades
• Authentication configuration
• Rule deployment
• Infrastructure maintenance

After the task is complete, administrative privileges should be automatically removed or manually revoked.

This just-in-time (JIT) access model reduces the attack surface while limiting the impact of compromised administrator accounts.

Security Best Practices

Successfully integrating Wazuh with Okta is only the first step.

Maintaining a secure authentication environment requires continuous monitoring, regular maintenance, and adherence to identity security best practices.

The following recommendations help protect both the authentication infrastructure and the Wazuh deployment.

Enforce HTTPS Everywhere

All authentication traffic should be encrypted using TLS.

HTTPS protects:

• Login credentials
• SAML assertions
• OIDC tokens
• Session cookies
• API communications

Avoid exposing authentication endpoints over HTTP, even within internal networks, as attackers with network access could intercept or manipulate authentication traffic.

Protect Client Secrets

For OIDC deployments, the Client Secret is equivalent to a highly privileged application password.

Protect it by:

• Storing it in a secure secrets manager
• Restricting administrator access
• Never embedding it in source code
• Rotating it regularly
• Replacing it immediately if compromised

Following secure secret management practices significantly reduces the risk of unauthorized token issuance.

Rotate Certificates Regularly

SAML deployments rely on trusted signing certificates to validate authentication assertions.

Develop a certificate lifecycle process that includes:

• Monitoring expiration dates
• Scheduling rotations before expiration
• Removing retired certificates
• Verifying fingerprints after updates
• Testing authentication after certificate replacement

Unexpected certificate expiration is a common cause of production authentication outages.

Limit Administrative Access

Administrator accounts should be limited to personnel who require elevated privileges.

Consider implementing:

• Separate administrator accounts
• Dedicated administrative groups
• Approval workflows
• MFA enforcement
• Privileged Access Management (PAM)
• Regular privilege reviews

Administrative accounts should never be used for routine monitoring or investigation tasks.

Enable Conditional Access Policies

Conditional access allows organizations to evaluate login context before granting access.

Policies may consider:

• Device compliance
• Geographic location
• Network trust
• User risk
• IP reputation
• Time of access
• Authentication strength

For example, privileged access to Wazuh could be limited to managed corporate devices connected through a VPN, while attempts from unknown locations require phishing-resistant MFA or are blocked entirely.

Monitor Authentication Logs

Authentication logs provide valuable visibility into both successful and unsuccessful login attempts.

Administrators should monitor for:

• Repeated login failures
• Impossible travel events
• MFA failures
• Unauthorized administrator access
• New device registrations
• Unexpected group changes
• Disabled account login attempts

According to the Verizon Data Breach Investigations Report (DBIR), stolen credentials continue to be one of the most common initial access vectors in real-world breaches, reinforcing the importance of monitoring identity-related events.

Restrict Access by Network Location

Where possible, limit access to Wazuh based on trusted network locations.

Examples include:

• Corporate offices
• VPN connections
• Secure remote access gateways
• Managed endpoint networks
• Private cloud environments

Combining network restrictions with MFA and device trust creates multiple layers of defense against unauthorized access.

Audit Login Activity

Regularly reviewing authentication activity helps detect misconfigurations, insider threats, and compromised accounts.

Audit items should include:

• Successful logins
• Failed logins
• MFA enrollment
• Administrator actions
• Group membership changes
• Privilege escalation
• Application assignments
• Authentication policy modifications

Organizations should also establish alerting for high-risk authentication events so security teams can investigate suspicious activity promptly.

Related Guides:

• How to Configure Wazuh Audit Logs
• How to Configure Wazuh Alerts

Troubleshooting Common Integration Issues

Even well-planned integrations can encounter authentication problems during deployment or after configuration changes.

Most issues stem from mismatched configuration values, certificate problems, clock drift, or incorrect role mappings.

The following troubleshooting steps address the most common problems encountered when integrating Wazuh with Okta.

Users Cannot Sign In

If users are unable to authenticate:

• Verify the user is assigned to the Okta application.
• Confirm the account is active.
• Ensure the user has completed MFA enrollment.
• Check Wazuh authentication logs.
• Review Okta system logs.
• Confirm network connectivity between the Dashboard and Okta.
• Verify DNS resolution.

Authentication logs on both platforms usually identify the stage at which the login failed.

Invalid SAML Response

An invalid SAML response typically indicates a trust or configuration issue.

Common causes include:

• Incorrect Entity ID
• Expired signing certificate
• Invalid ACS URL
• Signature verification failure
• Clock skew
• Incorrect NameID format

Verify that the Identity Provider metadata matches the configuration currently trusted by Wazuh.

OIDC Redirect URI Mismatch

One of the most common OIDC errors is a redirect URI mismatch.

Ensure the configured Redirect URI matches exactly on both sides, including:

• HTTPS
• Hostname
• Port
• Path
• Trailing slash

Even minor differences can cause Okta to reject the authentication request before the user is redirected back to Wazuh.

Invalid Client Credentials

If OIDC authentication fails during token exchange:

• Verify the Client ID.
• Confirm the Client Secret.
• Ensure the secret has not expired or been rotated.
• Check that the correct Okta application is being used.
• Validate the issuer URL and discovery endpoint.

Incorrect client credentials typically prevent Wazuh from obtaining authentication tokens.

Certificate Validation Errors

Certificate-related issues are especially common with SAML integrations.

Review:

• Certificate expiration
• Certificate chain
• Trusted CA
• Signature validation
• Metadata updates
• Certificate fingerprints

If Okta recently rotated its signing certificate, update the trusted certificate within the Wazuh configuration.

Group Mapping Not Working

Successful authentication does not necessarily mean authorization is functioning correctly.

If users authenticate but receive no permissions:

• Verify group claims are being sent.
• Check claim names.
• Confirm claim formatting.
• Review RBAC mappings.
• Ensure users belong to the expected Okta groups.

Inspecting the SAML assertion or OIDC ID token can help confirm whether group information is included.

Users Receive Incorrect Roles

If users receive unexpected permissions:

• Review Okta group memberships.
• Verify Wazuh role mappings.
• Remove duplicate mappings.
• Ensure groups have unique names.
• Test using a clean user account.
• Clear cached sessions before retesting.

Role mapping errors are often caused by overlapping group assignments or outdated RBAC configurations.

Clock Synchronization Issues

Authentication tokens and SAML assertions are time-sensitive.

If clocks differ between systems, users may receive errors indicating that assertions are expired or not yet valid.

Verify NTP synchronization across:

• Wazuh servers
• OpenSearch nodes
• Reverse proxies
• Domain controllers
• Okta-integrated infrastructure

Even a few minutes of clock drift can cause intermittent authentication failures.

Login Redirect Loop

A continuous login loop usually indicates that authentication succeeds but the session cannot be established.

Potential causes include:

• Incorrect cookie settings
• Invalid session configuration
• Reverse proxy misconfiguration
• SameSite cookie restrictions
• Redirect URL mismatches
• Session expiration settings

Review browser developer tools and Dashboard logs to determine where the redirect cycle begins.

Related Guides:

• How to Stop the Infinite Wazuh Login Loop After a Version Upgrade
• Fixing Wazuh API SameSite Cookie Errors

MFA Challenges Not Appearing

If users authenticate without receiving an MFA prompt:

• Verify the authentication policy requires MFA.
• Confirm the user is enrolled in an approved authenticator.
• Check adaptive policy conditions.
• Ensure device trust rules are functioning as intended.
• Review Okta authentication logs.
• Test using a different browser or device.

If MFA is being bypassed unexpectedly, carefully review policy precedence and any exceptions that may be allowing users to authenticate with only a password.