How to Integrate Wazuh with Google Workspace

Managing user authentication separately for every security platform quickly becomes difficult as organizations grow. Security teams need a secure, centralized authentication system that reduces administrative overhead while strengthening access controls. Integrating Wazuh with Google Workspace allows organizations to authenticate users using their existing corporate Google accounts through OpenID Connect (OIDC), eliminating the need to maintain separate Wazuh credentials.

Google Workspace serves as a cloud-based identity provider (IdP) that supports modern authentication standards, including OAuth 2.0 and OpenID Connect.

When integrated with Wazuh Dashboard, Google Workspace handles user authentication while Wazuh continues managing security monitoring, alerting, and log analysis.

This architecture centralizes identity management, simplifies user administration, and improves the overall security posture of a Security Operations Center (SOC).

Google recommends using OpenID Connect for web application authentication because it builds on OAuth 2.0 while providing standardized identity verification through ID tokens.

This enables applications like Wazuh Dashboard to verify user identities without storing passwords locally.

How it Works

The authentication process is straightforward:

A user attempts to log in to the Wazuh Dashboard.
Wazuh redirects the user to Google’s authentication service.
Google verifies the user’s credentials and any configured Multi-Factor Authentication (MFA).
Google issues an ID token containing the authenticated user’s identity.
Wazuh validates the token and grants access according to its configured role mappings.

This authentication model greatly reduces password-related risks because Wazuh never stores or validates user passwords directly.

Instead, Google Workspace becomes the trusted authentication authority while Wazuh focuses on authorization and security monitoring.

Google Workspace integration is supported in modern Wazuh deployments that use the OpenSearch-based Dashboard with OpenID Connect authentication.

Administrators should verify that both their Wazuh version and bundled OpenSearch components support OIDC before beginning the configuration process.

For organizations evaluating multiple authentication methods, you may also find these guides helpful:

According to Google’s Zero Trust guidance, centralized identity, strong authentication, and continuous verification are foundational components of securing enterprise applications.

Benefits of Integrating Wazuh with Google Workspace

Integrating Wazuh with Google Workspace provides far more than a convenient login experience.

It centralizes authentication, strengthens security controls, and simplifies administration across the entire security infrastructure.

Centralized Identity Management

Google Workspace becomes the single source of truth for user identities.

Administrators no longer need to create, update, or remove separate user accounts within Wazuh for every security analyst.

Centralized identity management offers several advantages:

Consistent user identities across multiple security tools
Reduced administrative overhead
Easier enforcement of organizational security policies
Simplified access reviews and compliance audits

Organizations using Google Workspace alongside other enterprise applications benefit from managing identities in one location rather than maintaining duplicate accounts across multiple systems.

Single Sign-On (SSO)

Single Sign-On allows analysts to access Wazuh using their existing Google Workspace credentials without remembering another username and password.

Benefits include:

Faster login experience
Improved productivity
Fewer password reset requests
Better user adoption
Consistent authentication across enterprise applications

Instead of authenticating independently to every security platform, analysts authenticate once with Google and gain seamless access to authorized services.

Strong Authentication with Multi-Factor Authentication (MFA)

Because authentication is delegated to Google Workspace, Wazuh automatically benefits from Google’s mature authentication platform.

Organizations can enforce:

Google Authenticator
Passkeys
Security Keys (FIDO2)
Push notifications
Hardware security tokens
Risk-based authentication

Even if an attacker obtains a user’s password, MFA significantly reduces the likelihood of unauthorized access.

Google reports that phishing-resistant MFA methods such as security keys provide substantially stronger protection against account compromise than passwords alone.

Simplified User Provisioning

Adding a new SOC analyst becomes much simpler.

Instead of creating accounts separately inside Wazuh:

Create the employee in Google Workspace.
Assign them to the appropriate organizational units or groups.
Configure Wazuh role mappings.
The user can immediately authenticate using their corporate account.

This reduces manual configuration and minimizes administrative errors.

Reduced Password Management

Local application passwords introduce several operational challenges:

Weak passwords
Password reuse
Forgotten credentials
Frequent reset requests
Password storage risks

Using Google Workspace eliminates the need for Wazuh-specific passwords because authentication occurs entirely through Google’s identity platform.

This also reduces help desk workload related to password management.

Improved Security Auditing

Authentication events become easier to monitor because Google Workspace generates detailed login logs.

Administrators can review:

Successful logins
Failed authentication attempts
MFA challenges
Suspicious sign-in activity
Device information
Geographic login locations

These logs complement Wazuh’s own monitoring capabilities, providing additional visibility into authentication activity.

You can further enhance monitoring by collecting Google authentication logs into Wazuh after completing the integration.

Easier Employee Onboarding and Offboarding

Identity lifecycle management becomes significantly more efficient.

When an employee joins:

Create a Google Workspace account.
Assign appropriate groups.
Access becomes immediately available.

When an employee leaves:

Disable or delete the Google Workspace account.
Access to Wazuh is automatically revoked.

This reduces the risk of orphaned accounts remaining active after employee departures.

Scalability for Growing Organizations

As organizations grow from dozens to thousands of employees, manually managing application-specific accounts becomes increasingly difficult.

Google Workspace is designed to support organizations of all sizes, allowing Wazuh authentication to scale without major architectural changes.

Benefits include:

Consistent authentication across multiple Wazuh Dashboard instances
Centralized policy enforcement
Simplified administration
Reduced operational overhead
Enterprise-ready identity management

For larger deployments, consider combining this integration with a clustered Wazuh environment.

Related Guides:

Prerequisites

Before configuring Google Workspace as the authentication provider for Wazuh, ensure that the following requirements are met.

Wazuh Server and Dashboard Installed

You should have a fully functional Wazuh deployment that includes:

Wazuh Manager
Wazuh Indexer
Wazuh Dashboard

The Dashboard must already be accessible over HTTPS before configuring external authentication.

If you have not yet deployed a production environment, first complete your Wazuh installation.

Administrative Access to Google Workspace

You need a Google Workspace administrator account with permissions to:

Access the Google Admin Console
Create OAuth applications
Configure authentication settings
Manage users and groups

Without administrator privileges, you cannot configure the required OpenID Connect integration.

Google Cloud Project

OIDC applications are configured within a Google Cloud project.

You’ll need to:

Create or select an existing Google Cloud project
Configure OAuth consent
Create OAuth credentials
Generate a Client ID
Generate a Client Secret

These credentials allow Wazuh Dashboard to communicate securely with Google’s identity platform.

OpenID Connect (OIDC) Configuration Enabled

Your Wazuh version must support OpenID Connect authentication through the underlying OpenSearch Security plugin.

You’ll configure:

Client ID
Client Secret
Discovery endpoint
Redirect URI
Requested scopes
Claim mappings

This establishes the trust relationship between Google Workspace and Wazuh Dashboard.

For a deeper explanation of OIDC concepts, see: How to Configure Wazuh OIDC

Public HTTPS Endpoint for Wazuh Dashboard

Google redirects authenticated users back to the Wazuh Dashboard after successful login.

Therefore, the Dashboard should be reachable using a publicly accessible HTTPS URL such as:

https://wazuh.example.com

The redirect URI configured in Google Cloud must exactly match the URL configured in Wazuh.

TLS Certificates

Secure communication between users, Google, and Wazuh requires valid TLS certificates.

Use certificates issued by a trusted Certificate Authority whenever possible.

TLS provides:

Encryption
Server authentication
Data integrity
Protection against man-in-the-middle attacks

Self-signed certificates may cause browser trust warnings and authentication issues.

DNS Configuration

Ensure your DNS records correctly resolve the public hostname used by the Wazuh Dashboard.

Verify:

Forward DNS resolution
Public accessibility
Correct hostname
Consistent URLs between Google Cloud and Wazuh configuration

Any mismatch between configured URLs and DNS records can cause OIDC authentication failures.

Time Synchronization (NTP)

OIDC tokens contain expiration timestamps and are time-sensitive.

If the clocks on your Wazuh server and Google’s authentication service differ significantly, authentication may fail due to invalid token validation.

Configure Network Time Protocol (NTP) on all Wazuh servers to maintain accurate system time.

Accurate time synchronization also improves log correlation, event ordering, and forensic investigations across your security infrastructure.

For production deployments, maintaining synchronized system clocks is considered a security best practice by organizations including the Internet Engineering Task Force (IETF) and is essential for reliable authentication token validation.

Understanding the Authentication Architecture

Before configuring the integration, it’s important to understand how Google Workspace, Google Cloud, and Wazuh work together during the authentication process.

Although users experience a simple login screen, several components exchange secure tokens behind the scenes to authenticate users without exposing passwords to Wazuh.

Google Workspace uses OpenID Connect (OIDC), an identity layer built on top of OAuth 2.0, to verify user identities.

Rather than authenticating users directly, Wazuh delegates authentication to Google and trusts the identity information returned after a successful login.

Understanding this authentication architecture makes troubleshooting significantly easier if authentication errors occur later during configuration.

Google Workspace Identity Platform

Google Workspace acts as the organization’s Identity Provider (IdP).

Its responsibilities include:

Authenticating users
Verifying passwords
Enforcing Multi-Factor Authentication (MFA)
Managing user accounts
Managing Google Groups
Applying Conditional Access policies
Issuing authentication tokens

Wazuh never receives or stores user passwords. Instead, it trusts the identity assertions generated by Google after successful authentication.

Google’s Identity Platform is designed to support millions of users and follows widely adopted identity standards including OAuth 2.0 and OpenID Connect.

OpenID Connect Authentication Flow

OpenID Connect extends OAuth 2.0 by providing standardized identity information.

A typical authentication sequence looks like this:

A user opens the Wazuh Dashboard.
Wazuh redirects the user to Google’s login page.
The user authenticates with Google Workspace.
Google verifies credentials and any required MFA.
Google redirects the browser back to Wazuh with an authorization code.
Wazuh exchanges the authorization code for tokens.
Wazuh validates the ID token.
The user is granted access according to their mapped permissions.

This process occurs over encrypted HTTPS connections, protecting credentials and tokens from interception.

Authorization Code Flow

Google recommends using the Authorization Code Flow for server-side web applications such as Wazuh Dashboard because it keeps sensitive credentials off the user’s browser.

The flow works as follows:

User requests access.
Browser is redirected to Google.
User authenticates.
Google returns an authorization code.
Wazuh exchanges the code for tokens using its Client Secret.
Google verifies the request.
Tokens are securely issued.

Unlike the Implicit Flow, the Authorization Code Flow never exposes access tokens directly through browser URLs, making it significantly more secure.

Google considers this the recommended OAuth flow for confidential web applications.

ID Tokens

The ID token is the primary identity document used by Wazuh.

It is a signed JSON Web Token (JWT) that contains information about the authenticated user, including claims such as:

User ID
Email address
Name
Subject identifier
Issuer
Audience
Token expiration
Authentication time

After receiving the ID token, Wazuh validates:

Google’s digital signature
Issuer information
Audience (Client ID)
Expiration timestamp
Token integrity

Only after successful validation is the user considered authenticated.

Access Tokens

An access token authorizes applications to call Google APIs on behalf of the authenticated user.

For basic Wazuh authentication, the access token is generally not used extensively because Wazuh primarily needs to verify user identity rather than access Google services.

However, access tokens may become useful if future integrations require access to:

Google Directory API
Google Admin SDK
Additional Google Workspace services

Access tokens are intentionally short-lived to reduce security risks if they are ever compromised.

Refresh Tokens

Refresh tokens allow Wazuh to obtain new access tokens without requiring the user to log in again.

Instead of forcing users to authenticate every time an access token expires, Google can issue a new token when presented with a valid refresh token.

Benefits include:

Longer authenticated sessions
Reduced login prompts
Better user experience
Improved productivity

Refresh tokens are long-lived credentials and should always be protected with the same level of security as passwords.

Session Lifecycle

A user session begins after successful authentication and ends when one of several conditions occurs.

Typical session lifecycle events include:

Initial login
Token validation
Session creation
Session renewal
Session expiration
User logout
Administrator revokes access

Administrators should configure reasonable session timeout values that balance usability with security requirements.

Shorter sessions reduce the window of opportunity if an authenticated session is compromised, while longer sessions improve analyst productivity.

If you’re configuring enterprise authentication across multiple identity providers, you may also find these guides useful:

Create a Google Cloud Project

Before Wazuh can authenticate users with Google Workspace, you’ll need a Google Cloud project to host the OAuth application.

This project contains the OAuth consent screen, client credentials, branding information, and security settings that Google uses during the authentication process.

If your organization already uses Google Cloud, you can create a dedicated project for Wazuh or reuse an existing one, depending on your administrative policies.

Create a New Project

Begin by signing in to the Google Cloud Console using a Google Workspace administrator account.

To create a project:

Open the Google Cloud Console.
Select the project dropdown in the top navigation bar.
Click New Project.
Enter a descriptive project name, such as Wazuh Authentication.
Select your organization and billing account (if applicable).
Click Create.

Using a dedicated project simplifies administration, auditing, and future maintenance.

Enable Required APIs

Most OpenID Connect authentication works without enabling numerous APIs, but organizations commonly enable identity-related services to support administration and future integrations.

Depending on your deployment, you may enable services such as:

Identity Toolkit API
Admin SDK
Cloud Resource Manager API

Review your organization’s requirements before enabling additional APIs to follow the principle of least privilege.

Configure the OAuth Consent Screen

The OAuth consent screen displays information about your application whenever users authenticate through Google.

You’ll configure:

Application name
Support email
Developer contact email
Authorized scopes
User type

Most internal enterprise deployments select the Internal user type so that only users within the Google Workspace organization can authenticate.

The consent screen also informs users which application is requesting access to their identity information.

Configure Application Branding

Branding helps users recognize that they are signing in to an approved corporate application rather than a phishing site.

Configure branding elements such as:

Application name
Organization logo
Support email
Privacy policy (if applicable)
Terms of service (optional)

Consistent branding improves user confidence and reduces confusion during authentication.

Add Authorized Domains

Google requires administrators to verify the domains associated with OAuth applications.

Add every domain that will be used during authentication, including the domain hosting the Wazuh Dashboard.

For example:

example.com
security.example.com
wazuh.example.com

Only verified domains can be used for redirect URIs and application links.

If your organization manages multiple domains, ensure each required domain is verified before proceeding.

Configure Publishing Status

Google allows OAuth applications to remain in Testing mode or be promoted to Production.

For internal Google Workspace deployments, Production status is typically recommended once testing has been completed successfully.

Using Production status:

Removes testing limitations
Supports long-term deployments
Provides a consistent authentication experience for users

Before publishing, verify that all redirect URIs, branding information, and OAuth settings have been thoroughly tested.

Create OAuth Credentials

After configuring your Google Cloud project, the next step is creating OAuth credentials.

These credentials establish the trust relationship between Google Workspace and the Wazuh Dashboard and allow secure authentication using OpenID Connect.

The generated Client ID and Client Secret uniquely identify your Wazuh deployment when communicating with Google’s identity platform.

Create an OAuth 2.0 Client ID

Within the Google Cloud Console:

Navigate to APIs & Services → Credentials.
Select Create Credentials.
Choose OAuth Client ID.
Select Web application as the application type.
Enter a descriptive name such as Wazuh Dashboard.

Google will prepare the OAuth client configuration used by Wazuh during authentication.

Configure Authorized Redirect URIs

Redirect URIs specify where Google sends users after successful authentication.

A typical redirect URI resembles:

https://wazuh.example.com/auth/openid/login

The exact URI depends on your Wazuh Dashboard and OpenSearch Security configuration.

Important considerations:

Use HTTPS.
Match the configured Wazuh URL exactly.
Avoid trailing slash mismatches.
Ensure DNS resolves correctly.
Use publicly accessible URLs.

Even minor differences between the configured URI and the actual callback URL can result in authentication failures.

Configure JavaScript Origins

Authorized JavaScript origins define which browser origins may initiate OAuth authentication requests.

For example:

https://wazuh.example.com

Origins should:

Use HTTPS
Match the Dashboard hostname
Exclude additional paths
Be limited to trusted domains only

Avoid using wildcard origins, as they increase the attack surface and are not recommended for production deployments.

Generate the Client ID and Client Secret

Once all OAuth settings have been configured, Google generates two important credentials:

Client ID
Client Secret

The Client ID identifies your Wazuh application, while the Client Secret authenticates Wazuh when exchanging authorization codes for tokens.

These values will be required later when configuring OpenID Connect within the Wazuh Dashboard.

Securely Store Credentials

Treat the Client Secret as a highly sensitive credential.

Recommended security practices include:

Store secrets in a secure secrets manager.
Restrict administrative access.
Never commit credentials to source control.
Rotate secrets periodically.
Monitor for unauthorized access.
Replace compromised credentials immediately.

Google’s security documentation recommends protecting OAuth client secrets with the same care as other privileged credentials because unauthorized access could allow attackers to impersonate trusted applications.

Configure Google Workspace Authentication

With the Google Cloud project and OAuth credentials in place, the next step is configuring Google Workspace to control who can access the Wazuh Dashboard.

This includes selecting authorized users, enforcing security policies, enabling Multi-Factor Authentication (MFA), and reviewing the permissions granted to the OAuth application.

Proper configuration ensures that only approved users can authenticate while maintaining compliance with your organization’s identity and access management policies.

Configure Users and Groups

Rather than allowing every Google Workspace user to access Wazuh, it’s recommended to restrict access to dedicated security groups.

For example, you might create groups such as:

Security Analysts
SOC Engineers
Incident Responders
Security Administrators

Using groups provides several advantages:

Simplifies permission management
Reduces administrative overhead
Supports role-based access control (RBAC)
Makes onboarding and offboarding easier

As employees join or leave the security team, administrators simply update group membership rather than modifying Wazuh directly.

Restrict Application Access

Google Workspace allows administrators to limit which users or organizational units can access specific OAuth applications.

Best practices include:

Restrict access to authorized security personnel.
Deny access to unnecessary departments.
Limit administrative accounts to security administrators.
Regularly review assigned users and groups.

Following the principle of least privilege minimizes the risk of unauthorized access to sensitive security data.

Google recommends limiting OAuth application access whenever possible to reduce the organization’s attack surface.

Enable Multi-Factor Authentication

Multi-Factor Authentication (MFA) is one of the most effective ways to protect administrative and security-related accounts.

Google Workspace supports several MFA methods, including:

Google Authenticator
Google Prompt
Security Keys (FIDO2)
Passkeys
Backup codes

Administrators should require MFA for every user who can access the Wazuh Dashboard.

Google has consistently emphasized that phishing-resistant authentication methods, such as security keys and passkeys, provide significantly stronger protection against credential theft than passwords alone.

Configure Organizational Policies

Google Workspace administrators can further strengthen authentication by configuring organization-wide security policies.

Examples include:

Require MFA for privileged accounts
Restrict logins from unmanaged devices
Block legacy authentication protocols
Configure session timeout policies
Require verified devices
Restrict access by geographic location (where appropriate)

These policies add multiple layers of defense before users can even reach the Wazuh login process.

Review OAuth Scopes

OAuth scopes determine which information the Wazuh Dashboard can request from Google during authentication.

Typical OpenID Connect scopes include:

openid
email
profile

Avoid requesting unnecessary scopes unless they are required for your deployment.

Following the principle of least privilege helps:

Reduce security risks
Improve user trust
Simplify consent management
Minimize exposure of user information

Carefully review all requested scopes before deploying the integration into production.

Configure Wazuh for Google Workspace Authentication

Once Google Workspace has been configured as the identity provider, you must configure the Wazuh Dashboard to trust Google’s OpenID Connect service.

This involves supplying the OAuth client credentials, issuer information, redirect URIs, and authentication scopes.

The exact configuration file and syntax may vary slightly depending on your Wazuh version and the bundled OpenSearch Security plugin, but the overall process remains the same.

For a broader overview of OpenID Connect in Wazuh, see:

How to Configure Wazuh OIDC

Locate the Authentication Configuration

Begin by locating the authentication configuration used by the Wazuh Dashboard.

Depending on your deployment, this may include:

OpenSearch Security configuration
Dashboard authentication settings
OIDC provider configuration
Authentication backend settings

Before making changes:

Back up the existing configuration.
Verify file permissions.
Document the current authentication settings.

Creating a backup makes it easier to roll back if authentication problems occur after deployment.

Configure OpenID Connect Settings

Enable OpenID Connect as an authentication provider and specify Google Workspace as the external identity provider.

Typical OIDC configuration includes:

Identity provider name
Authentication type
Discovery endpoint
Client credentials
Redirect URI
Requested scopes

These settings establish the trust relationship between Wazuh and Google’s identity platform.

Configure Issuer URL

The issuer URL identifies the trusted authentication provider that issues identity tokens.

Wazuh validates this value during token verification to ensure tokens originate from Google’s identity service.

An incorrect issuer URL will typically result in authentication failures because token validation will fail.

Always use the issuer URL provided in Google’s OpenID Connect discovery document rather than manually entering a custom value.

Configure Client ID

Copy the OAuth Client ID generated in Google Cloud Console into the Wazuh authentication configuration.

The Client ID uniquely identifies the Wazuh Dashboard when communicating with Google’s authorization servers.

Ensure:

No characters are omitted.
No additional spaces are introduced.
The Client ID matches the Google Cloud project being used.

Configure Client Secret

Next, configure the Client Secret that was generated alongside the Client ID.

The Client Secret authenticates the Wazuh Dashboard when exchanging authorization codes for tokens.

To protect this sensitive credential:

Restrict file permissions.
Avoid storing it in version control.
Rotate secrets periodically.
Replace compromised credentials immediately.

Treat the Client Secret with the same level of protection as other privileged application secrets.

Configure Redirect URI

The redirect URI configured within Wazuh must exactly match the URI configured in Google Cloud.

Verify:

HTTPS is used.
Hostname matches.
Port numbers are correct.
Paths match exactly.
No unexpected trailing slashes exist.

Even small mismatches commonly produce OAuth redirect errors.

Configure Scopes

Specify the OAuth scopes requested during authentication.

Most deployments require only:

openid
email
profile

Avoid requesting additional scopes unless there is a specific operational requirement.

Requesting fewer permissions follows Google’s security recommendations and reduces unnecessary access to user information.

Configure Logout Behavior

Single Sign-Out behavior should also be considered during deployment.

When users log out of the Wazuh Dashboard, administrators may choose to:

End only the local Wazuh session.
Redirect users to Google’s logout endpoint.
Require fresh authentication on the next login.
Clear local session cookies.

Select the logout behavior that best aligns with your organization’s security policies.

Save Configuration Changes

After verifying every configuration value:

Save the authentication configuration.
Validate the configuration syntax.
Check file ownership and permissions.
Confirm there are no formatting errors.

Avoid restarting services until the configuration has been reviewed, as syntax errors may prevent the Dashboard from starting correctly.

Restart Wazuh Services

After updating the authentication configuration, restart the necessary Wazuh services so the new OpenID Connect settings are loaded into memory.

Restarting services also provides an opportunity to verify that no configuration or syntax errors were introduced during deployment.

Restart Wazuh Dashboard

Restart the Wazuh Dashboard service using the appropriate service management utility for your operating system.

After restarting:

Wait for the service to finish initializing.
Allow authentication plugins to load completely.
Verify that the Dashboard is accepting connections before testing authentication.

Verify Service Status

Confirm that the Dashboard service is running normally after the restart.

Check for:

Running service status
No restart loops
No failed dependencies
Successful initialization

If the service fails to start, review configuration changes before attempting additional troubleshooting.

For Dashboard startup issues, see:

Review Startup Logs

Startup logs are often the fastest way to identify configuration problems.

Look for messages related to:

OpenID Connect initialization
OAuth provider loading
Token validation
Client authentication
Certificate validation
Configuration parsing

Warnings and errors during startup frequently identify missing configuration values or incorrect OAuth settings.

Confirm Authentication Configuration Loads Successfully

Once the Dashboard is running, confirm that:

OpenID Connect initializes successfully.
Google is recognized as the configured identity provider.
No authentication errors appear in the logs.
The Dashboard loads without configuration warnings.

Resolving startup issues before testing user logins reduces troubleshooting complexity later.

Test the Integration

The final step is validating that authentication works correctly from an end-user perspective.

Testing should cover the entire authentication lifecycle, including login, authorization, MFA, logout, and session management.

Whenever possible, perform testing with both standard user accounts and administrator accounts to verify role mappings and permissions.

Verify SSO Login

Open the Wazuh Dashboard and initiate the Single Sign-On process.

Confirm that:

Users are redirected to Google’s sign-in page.
The correct Google Workspace tenant is displayed.
Authentication completes successfully.
Users are redirected back to the Dashboard.

Successful authentication indicates that the OAuth client, redirect URI, and OpenID Connect configuration are functioning correctly.

Test User Authentication

Verify that:

Authorized users can authenticate successfully.
Unauthorized users are denied access.
User identity information is displayed correctly.
Authentication occurs without unexpected prompts or errors.

Testing multiple user accounts helps validate access policies before production deployment.

Verify Group Assignments

If your deployment maps Google Workspace groups to Wazuh roles, verify that group membership results in the expected permissions.

Confirm that:

Security analysts receive analyst privileges.
Administrators receive administrative access.
Unauthorized groups cannot access the Dashboard.
Role mappings are applied consistently.

Proper group-based authorization simplifies long-term user administration.

Test Logout

After logging in successfully:

Log out of the Dashboard.
Verify that the session ends correctly.
Confirm protected pages are no longer accessible.
Ensure users are prompted to authenticate again when required.

Proper logout behavior helps prevent unauthorized access from shared or unattended workstations.

Test Session Expiration

Allow an authenticated session to remain idle until it expires.

Verify that:

The session terminates at the expected time.
Users are redirected to authenticate again.
Expired sessions cannot continue accessing protected resources.
No authentication errors occur after reauthentication.

Session timeout testing confirms that configured security policies function as expected.

Validate Token Renewal

If refresh tokens are enabled, verify that tokens are renewed automatically without unnecessarily interrupting the user.

Monitor for:

Successful token refresh operations
No unexpected login prompts
Proper handling of expired tokens
Graceful recovery when refresh tokens become invalid

Testing token renewal helps ensure a smooth user experience while maintaining secure authentication.

Confirm MFA Enforcement

Finally, verify that Google Workspace enforces Multi-Factor Authentication according to your organizational policies.

Test scenarios should include:

Standard user login
Administrative account login
New device authentication
Authentication from different networks
Login attempts without completing MFA

Successful MFA enforcement confirms that Wazuh is relying on Google’s authentication controls rather than local password validation.

For organizations implementing enterprise authentication across multiple identity providers, you may also find these guides helpful:

Configure Role-Based Access Control (RBAC)

Authentication verifies a user’s identity, but Role-Based Access Control (RBAC) determines what that user is allowed to do after signing in.

After integrating Google Workspace with Wazuh, configure RBAC to ensure users receive only the permissions required for their job responsibilities.

A well-designed RBAC strategy improves security, simplifies administration, and helps organizations meet compliance requirements by enforcing the principle of least privilege.

For a detailed overview of Wazuh permissions, see: Troubleshooting Wazuh RBAC

Map Google Workspace Users to Wazuh Roles

Once users successfully authenticate through Google Workspace, Wazuh must associate them with the appropriate internal role.

Role mappings are commonly based on:

User email address
User groups
Organizational units (where applicable)
Identity claims contained within the ID token

Rather than assigning permissions individually, most organizations map Google Workspace groups to Wazuh roles, making ongoing administration significantly easier.

Configure Administrator Access

Administrative accounts should be limited to users responsible for managing the Wazuh deployment.

Typical administrator permissions include:

Managing Wazuh configuration
Creating detection rules
Managing integrations
Configuring agents
Viewing all alerts
Managing RBAC policies

Avoid assigning administrator privileges to users who only require monitoring or investigative capabilities.

Administrative accounts should also be protected with strong Multi-Factor Authentication and monitored for unusual login activity.

Configure Analyst Access

Security analysts generally require broad visibility into security events without the ability to modify critical system settings.

Typical analyst permissions include:

View alerts
Search security events
Investigate incidents
Create dashboards
Execute approved searches
Review agent status

Restricting configuration changes reduces the likelihood of accidental or unauthorized modifications to the monitoring environment.

Configure Read-Only Users

Many organizations have users who need visibility into security data but should not be able to modify the environment.

Examples include:

Compliance auditors
IT managers
Executive leadership
External auditors
Risk management teams

Read-only access typically allows users to:

View dashboards
Search alerts
Export reports
Review security events

Configuration changes, rule creation, and administrative functions should remain unavailable.

Use Groups for Permission Management

Managing permissions through Google Workspace groups is considerably more scalable than assigning permissions to individual users.

For example:

Google Workspace Group	Suggested Wazuh Role
Security Administrators	Administrator
SOC Analysts	Analyst
Compliance Auditors	Read-Only
IT Operations	Limited Access

Benefits of group-based administration include:

Simplified onboarding
Faster offboarding
Consistent permissions
Reduced administrative effort
Easier auditing

When an employee changes roles, administrators only need to update group membership rather than modify multiple Wazuh configurations.

Apply Least Privilege Principles

The principle of least privilege states that users should receive only the minimum permissions necessary to perform their responsibilities.

Best practices include:

Avoid granting administrator access by default.
Separate administrative and analyst accounts.
Regularly review assigned roles.
Remove unused accounts promptly.
Audit permission assignments periodically.
Restrict sensitive administrative functions.

The National Institute of Standards and Technology (NIST) recommends least privilege as a foundational component of modern identity and access management because it limits the impact of compromised accounts and insider threats.

Security Best Practices

Integrating Google Workspace with Wazuh significantly improves authentication security, but additional security controls are essential for protecting your deployment against credential theft, misconfiguration, and unauthorized access.

The following best practices help build a secure and resilient authentication environment.

Enforce Multi-Factor Authentication

Every account with access to the Wazuh Dashboard should require Multi-Factor Authentication.

Preferred authentication methods include:

Passkeys
FIDO2 Security Keys
Google Prompt
Authenticator applications

SMS-based authentication should generally be used only when stronger methods are unavailable.

Google recommends phishing-resistant authentication methods wherever possible because they provide stronger protection against credential phishing attacks.

Use HTTPS Exclusively

All authentication traffic should be encrypted using HTTPS.

Never expose the Wazuh Dashboard over unencrypted HTTP.

HTTPS protects:

User credentials
Authentication tokens
Session cookies
OAuth authorization codes
Identity information

Always use certificates issued by a trusted Certificate Authority in production environments.

Protect OAuth Client Secrets

The OAuth Client Secret is one of the most sensitive credentials in the integration.

Recommended practices include:

Store secrets in a dedicated secrets manager.
Restrict access to authorized administrators.
Avoid storing secrets in source control.
Encrypt backups containing secrets.
Monitor secret access.

If the Client Secret is ever suspected of being compromised, generate a new one immediately and update the Wazuh configuration.

Rotate Credentials Regularly

Regular credential rotation reduces the potential impact of credential exposure.

Consider rotating:

OAuth Client Secrets
TLS certificates
Administrative passwords
API credentials

Document rotation procedures to minimize downtime during maintenance.

Restrict OAuth Scopes

Only request the minimum scopes required for authentication.

For most deployments, the following scopes are sufficient:

openid
email
profile

Avoid requesting unnecessary access to Google services unless additional functionality specifically requires it.

Restricting scopes limits the information shared with Wazuh and reduces the potential impact of compromised credentials.

Monitor Authentication Logs

Authentication logs provide valuable visibility into account activity and potential security incidents.

Regularly review:

Failed login attempts
Successful logins
MFA failures
Token validation errors
Suspicious sign-in activity
Administrative account usage

Forwarding Google Workspace audit logs into Wazuh provides centralized monitoring and correlation with other security events.

Limit Administrative Accounts

Administrative accounts represent high-value targets for attackers.

Limit administrator accounts by:

Granting administrator access only when necessary.
Using dedicated administrative accounts.
Removing inactive administrators.
Performing periodic access reviews.
Monitoring privileged account activity.

Reducing the number of privileged accounts lowers the overall attack surface.

Configure Session Timeout Policies

Long-lived sessions increase the risk of unauthorized access if a workstation is left unattended.

Configure reasonable timeout values based on organizational requirements.

Consider:

Automatic idle session expiration
Forced reauthentication
Session invalidation after logout
Token expiration policies

Balancing usability with security helps maintain analyst productivity while protecting sensitive systems.

Enable Conditional Access Where Applicable

Organizations with advanced identity policies can further strengthen authentication using conditional access controls.

Examples include:

Restrict authentication by geographic location
Require managed devices
Block risky sign-in attempts
Restrict access from unknown networks
Apply risk-based authentication policies

Layering conditional access with MFA provides additional protection against compromised credentials.

Common Integration Issues and Troubleshooting

Even when the integration is configured correctly, authentication problems can occur because of configuration mismatches, expired credentials, or network issues.

Understanding the most common problems can significantly reduce troubleshooting time.

Redirect URI Mismatch

A redirect URI mismatch is one of the most common OAuth configuration errors.

Symptoms include:

Google displays an OAuth error.
Authentication never completes.
Users are not returned to the Wazuh Dashboard.

Verify that:

The redirect URI matches exactly.
HTTPS is used.
Hostnames are identical.
No trailing slash differences exist.
Ports are correct.

Even a minor mismatch will cause Google to reject the authentication request.

Invalid Client ID or Client Secret

Incorrect OAuth credentials prevent Wazuh from exchanging authorization codes for tokens.

Possible causes include:

Typographical errors
Expired credentials
Deleted OAuth application
Incorrect Google Cloud project
Rotated Client Secret not updated in Wazuh

If necessary, regenerate the credentials in Google Cloud and update the Wazuh configuration.

Invalid Issuer URL

The issuer URL must exactly match Google’s OpenID Connect issuer.

If the configured issuer differs from the value contained in the ID token, authentication will fail during token validation.

Verify that the issuer URL comes directly from Google’s OpenID Connect discovery document rather than being entered manually.

Login Loop After Authentication

Users may authenticate successfully but be redirected back to the login page repeatedly.

Possible causes include:

Session cookie issues
Incorrect redirect URI
Reverse proxy configuration errors
Invalid session configuration
Browser cookie restrictions

If you’re experiencing this specific issue, see: How to Stop the Infinite Wazuh Login Loop After a Version Upgrade

Users Cannot Access Wazuh

If authentication succeeds but users cannot access the Dashboard, verify:

RBAC role mappings
Authorized groups
Assigned permissions
Google Workspace access policies
Dashboard authorization settings

Authentication and authorization are separate processes; successful login does not automatically guarantee access.

Group Mappings Not Working

If users receive incorrect permissions, review the group mapping configuration.

Check:

Group names
Identity claims
Mapping rules
Group membership
Synchronization status

Testing with multiple user accounts can help isolate mapping issues.

Token Validation Failures

Invalid or expired tokens typically generate authentication errors during login.

Possible causes include:

Expired tokens
Incorrect issuer
Incorrect audience
Invalid signature
Clock drift
Corrupted configuration

Review Dashboard logs for detailed token validation errors.

SSL Certificate Errors

TLS problems can interrupt communication between Wazuh and Google.

Common issues include:

Expired certificates
Untrusted Certificate Authority
Incorrect certificate chain
Hostname mismatch
Missing intermediate certificates

Verify certificates using standard TLS validation tools before investigating OAuth settings.

If certificate-related problems occur, see: How to Fix Wazuh Certificate Errors

Clock Synchronization Issues

OAuth and OpenID Connect rely on accurate timestamps.

If system clocks differ significantly, token validation may fail because tokens appear to be expired or not yet valid.

Verify that:

NTP is enabled.
All Wazuh nodes use reliable time sources.
Reverse proxies maintain accurate system time.
Virtual machines synchronize correctly with their hosts.

Maintaining synchronized clocks is particularly important in clustered deployments.

Session Expiration Problems

Unexpected logouts or sessions that never expire often indicate configuration issues.

Review:

Session timeout values
Token lifetime settings
Refresh token configuration
Browser cookie settings
Reverse proxy session handling

Testing authentication over extended periods can help identify session lifecycle issues that are not immediately apparent after deployment.

Performance and High Availability Considerations

Integrating Wazuh with Google Workspace introduces an external authentication dependency, which means authentication availability depends on both the Wazuh environment and Google’s identity infrastructure.

Proper planning ensures that users can continue accessing the Wazuh Dashboard reliably while maintaining strong security controls.

For enterprise deployments, authentication performance, token management, credential lifecycle management, and identity service availability should all be considered during architecture planning.

Google Workspace Service Availability

Google Workspace authentication services are designed for high availability and global scalability.

Since Wazuh delegates authentication to Google, users depend on Google’s identity platform being available when signing in.

Organizations should consider:

Google Workspace service availability
Planned maintenance windows
Google service health notifications
Authentication dependency risks

Administrators should monitor Google’s service health dashboard and establish procedures for handling temporary authentication disruptions.

For critical Security Operations Centers (SOCs), authentication availability should be treated as part of the overall security infrastructure because analysts need reliable access during active incidents.

Google Identity Redundancy

Google Workspace uses a globally distributed identity infrastructure designed to provide resilience against regional failures.

Organizations benefit from:

Distributed authentication services
Automatic service failover
Global availability
Redundant authentication infrastructure

However, organizations should still maintain contingency plans, especially for emergency access scenarios.

Recommended practices include:

Maintaining emergency administrative accounts.
Documenting recovery procedures.
Testing authentication failure scenarios.
Ensuring administrators understand fallback access methods.

Authentication Latency

Authentication latency affects how quickly users can access the Wazuh Dashboard after selecting the Google login option.

Factors that influence authentication speed include:

User network location
Internet connectivity
DNS resolution
TLS negotiation
Google authentication response time
Wazuh Dashboard performance
Reverse proxy configuration

In most environments, OIDC authentication adds only minimal overhead because token exchanges occur quickly between Wazuh and Google’s authentication servers.

To optimize authentication performance:

Use reliable DNS infrastructure.
Deploy Wazuh close to users when possible.
Avoid unnecessary proxy layers.
Maintain healthy Dashboard resources.

Token Validation Performance

During authentication, Wazuh validates Google’s ID tokens before creating a user session.

Token validation includes checking:

Digital signatures
Token issuer
Audience
Expiration time
Identity claims

Performance considerations include:

Network connectivity to Google’s identity endpoints
Certificate validation speed
System resource availability
Token verification workload

For large environments, efficient token validation helps ensure that multiple analysts can authenticate simultaneously during high-pressure security events.

Session Caching

Session caching reduces repeated authentication requests by allowing authenticated users to continue accessing Wazuh without repeatedly contacting Google.

Benefits include:

Faster Dashboard access
Reduced authentication traffic
Improved user experience
Lower dependency on external authentication requests

Session caching should be balanced with security requirements.

Excessively long sessions may increase risk if user sessions are compromised.

Session Timeout Configuration

Session timeout values should align with organizational security requirements.

Shorter timeouts provide:

Reduced exposure from unattended sessions
Stronger protection for privileged accounts
Faster access revocation

Longer timeouts provide:

Better analyst productivity
Fewer authentication interruptions
Improved workflow during investigations

Security teams should define timeout policies based on user roles.

For example, administrator sessions may require shorter expiration periods than read-only audit accounts.

Refresh Token Management

Refresh tokens allow applications to obtain new access tokens without requiring users to authenticate repeatedly.

When using refresh tokens:

Protect them like passwords.
Limit who can access them.
Monitor unusual token activity.
Revoke compromised tokens immediately.

Organizations should periodically review OAuth application access and remove unused credentials.

Scaling Large Enterprise Deployments

Large organizations may have hundreds or thousands of security users accessing Wazuh.

Scaling considerations include:

Authentication concurrency
Dashboard capacity
Network bandwidth
User session volume
RBAC complexity
Identity group management

Google Workspace handles identity scaling, but the Wazuh Dashboard infrastructure must still be sized appropriately to support user activity.

For large environments, consider:

Multiple Wazuh Dashboard instances
Load balancing
Dedicated authentication monitoring
Clustered Wazuh deployments

Related guides:

Multiple Wazuh Dashboard Instances

Organizations running multiple Wazuh Dashboards can use the same Google Workspace OAuth application or create separate applications depending on their security requirements.

Multiple instances may be used for:

Geographic separation
Department isolation
High availability
Disaster recovery

Ensure every Dashboard instance has:

Correct redirect URIs
Consistent OIDC configuration
Matching role mappings
Valid TLS certificates

Load Balancing Authentication Requests

Large deployments may place Wazuh Dashboard instances behind a load balancer.

When load balancing authentication traffic:

Maintain session persistence where required.
Ensure all nodes share compatible authentication settings.
Configure health checks.
Use consistent HTTPS termination.

Incorrect load balancer configuration can cause:

Login loops
Failed redirects
Lost sessions
Authentication inconsistencies

OAuth Client Secret Rotation

OAuth client secrets should be rotated periodically as part of normal credential lifecycle management.

A secure rotation process includes:

Generate a new OAuth client secret.
Update Wazuh configuration.
Test authentication.
Remove the old secret after verification.
Document the rotation.

Avoid deleting old credentials before confirming that the new configuration works successfully.

Monitoring Credential Expiration

OAuth credentials and certificates should be monitored before expiration.

Track:

OAuth client secret expiration
TLS certificate expiration
Domain verification status
Authentication configuration changes

Automated monitoring prevents unexpected authentication outages caused by expired credentials.

Monitoring Authentication Services

Authentication monitoring should include both Google Workspace and Wazuh components.

Monitor:

Failed login attempts
Authentication errors
Token validation failures
OAuth configuration changes
Suspicious login activity
Dashboard authentication logs

Centralizing these events in Wazuh provides better visibility into identity-related security events.

Organizations can also integrate additional authentication sources using:

Real-World Example

A multinational enterprise operates a Security Operations Center (SOC) responsible for monitoring thousands of endpoints, cloud workloads, and network devices using Wazuh.

The organization wants to simplify authentication management while improving security controls for security analysts, incident responders, compliance teams, and administrators.

Previously, the SOC maintained separate Wazuh user accounts, creating administrative overhead and increasing the risk of outdated permissions after employees changed roles or left the company.

To solve this challenge, the organization integrates Wazuh with Google Workspace using OpenID Connect.

Creating a Dedicated Google OAuth Application

The security team creates a dedicated Google Cloud project specifically for Wazuh authentication.

The team:

Creates a new OAuth application.
Configures the application as an internal enterprise application.
Adds the Wazuh Dashboard domain as an authorized domain.
Creates OAuth Client ID and Client Secret credentials.
Configures HTTPS redirect URIs.

The dedicated OAuth application provides centralized control over authentication settings and simplifies future auditing.

Configuring OpenID Connect Authentication

The organization configures Wazuh Dashboard to use Google Workspace as its OpenID Connect identity provider.

The configuration includes:

Google issuer URL
OAuth Client ID
OAuth Client Secret
Redirect URI
Required OIDC scopes

After configuration, users no longer authenticate directly against Wazuh.

Instead, Google verifies their identity and returns signed authentication tokens to Wazuh.

Mapping Google Workspace Groups to Wazuh RBAC Roles

The SOC creates Google Workspace groups based on job responsibilities.

Example structure:

Google Workspace Group	Wazuh Role
SOC Administrators	Full Administrator Access
Incident Responders	Investigation and Response Permissions
Security Analysts	Alert Monitoring Permissions
Compliance Team	Read-Only Access

This approach allows the organization to manage permissions entirely through Google Workspace.

When an employee joins the SOC, administrators add them to the correct Google group.

When an employee leaves, removing their Google Workspace access immediately prevents Wazuh authentication.

Enforcing Multi-Factor Authentication

Because authentication is handled by Google Workspace, the SOC enforces MFA policies centrally.

Security requirements include:

MFA for all Wazuh users
Strong authentication for administrators
Security key support for privileged accounts
Conditional access policies for sensitive systems

This ensures that compromised passwords alone cannot provide access to the organization’s security monitoring platform.

Improving Onboarding, Offboarding, and Auditability

The integration significantly improves identity lifecycle management.

For onboarding:

Create Google Workspace account.
Assign security group membership.
User automatically receives Wazuh access.

For offboarding:

Disable Google account.
Remove group membership.
Access is immediately revoked.

The SOC also benefits from improved auditing because authentication activity can be correlated with Wazuh security events.

The final architecture provides:

Centralized identity management
Strong authentication controls
Simplified access administration
Better compliance visibility
Reduced credential management overhead

Frequently Asked Questions

Question: Does Wazuh support Google Workspace authentication?

Yes. Wazuh can integrate with Google Workspace authentication by using OpenID Connect (OIDC). Google Workspace acts as the identity provider while Wazuh Dashboard validates authentication tokens issued by Google.

Question: Does Google Workspace use SAML or OpenID Connect with Wazuh?

The recommended approach for this integration is OpenID Connect (OIDC).

Google Workspace supports both SAML and OIDC authentication technologies, but OIDC is commonly used for modern web applications because it provides standardized identity tokens and works well with OAuth 2.0.

Question: Can I enable Single Sign-On (SSO) for Wazuh using Google Workspace?

Yes. Google Workspace can provide Single Sign-On functionality for Wazuh by authenticating users through OpenID Connect.

Users can sign in using their existing corporate Google accounts without creating separate Wazuh passwords.

Question: Can I enforce Multi-Factor Authentication for Wazuh logins?

Yes. MFA enforcement occurs through Google Workspace rather than Wazuh.

Any MFA policies configured in Google Workspace apply automatically when users authenticate to Wazuh.

Question: How do I map Google Workspace users to Wazuh roles?

Users are mapped using Wazuh RBAC configuration.

The recommended approach is:

Create Google Workspace security groups.
Add users to appropriate groups.
Map groups to Wazuh roles.
Apply least privilege permissions.

Question: Can multiple Google Workspace domains authenticate with Wazuh?

Yes, but the configuration depends on your Google Workspace structure and OAuth application settings.

Organizations with multiple domains should verify domain ownership and configure authentication policies appropriately.

Question: What OAuth scopes are required?

Most Wazuh Google Workspace integrations require:

openid
email
profile

Additional scopes should only be requested if required for specific functionality.

Question: Why am I getting a redirect URI mismatch error?

A redirect URI mismatch occurs when the URI configured in Google Cloud does not exactly match the URI requested by Wazuh.

Check:

Protocol (https)
Hostname
Port
Path
Trailing slashes

Question: How do I rotate the OAuth client secret?

To rotate the OAuth Client Secret:

Generate a new secret in Google Cloud.
Update the Wazuh authentication configuration.
Restart required services.
Test authentication.
Remove the old credential.

Question: What logs should I check if authentication fails?

Review:

Wazuh Dashboard logs
OpenSearch Security logs
Google Workspace authentication logs
Browser developer console errors
Reverse proxy logs

Common causes include incorrect credentials, invalid redirect URIs, certificate issues, and token validation failures.

Conclusion

Integrating Wazuh with Google Workspace provides organizations with a secure and scalable authentication architecture based on OpenID Connect.

The integration process involves:

Creating a Google Cloud OAuth application
Configuring Google Workspace authentication policies
Enabling OpenID Connect in Wazuh
Mapping Google groups to Wazuh RBAC roles
Testing authentication workflows
Monitoring authentication reliability

By centralizing authentication through Google Workspace, organizations reduce password management overhead, simplify user administration, and strengthen security through MFA and centralized identity controls.

A secure deployment requires ongoing maintenance, including:

Monitoring authentication logs
Rotating OAuth credentials
Reviewing user permissions
Maintaining TLS certificates
Testing authentication availability

For additional Wazuh identity and authentication guides, see: