Modern organizations rely on centralized identity providers to manage authentication securely. Instead of creating and maintaining separate usernames and passwords for every application, users expect to access applications using their existing organizational accounts.
To provide a seamless and secure authentication experience, CH-OPS supports Single Sign-On (SSO) with multiple identity providers:
- Keycloak
- Okta
With SSO, CH-OPS delegates user authentication to trusted identity providers while maintaining control over which users are authorized to access the application.
What Is Single Sign-On (SSO)?
Single Sign-On (SSO) is an authentication mechanism that allows users to authenticate through an external identity provider and access an application without creating or managing a separate password for that application.
Instead of CH-OPS directly handling user credentials, authentication is delegated to an identity provider such as Google, Keycloak, or Okta.
Benefits
- Stronger security
- Reduced password fatigue
- Centralized identity management
- Faster login experience
- Easier onboarding and offboarding
- Support for enterprise security policies such as Multi-Factor Authentication (MFA)
- Integration with existing organizational identity infrastructure
SSO Providers Supported by CH-OPS
CH-OPS currently supports three identity providers through OpenID Connect (OIDC).
Google authentication allows users to authenticate using their Google or Google Workspace accounts.
Google SSO provides:
- Familiar login experience
- OAuth 2.0 and OpenID Connect support
- Secure identity verification
- Google Workspace integration
- Provider-managed authentication and security policies
It is particularly useful for organizations already using Google Workspace.
Keycloak
Keycloak is an open-source Identity and Access Management (IAM) platform commonly used in enterprise and self-hosted environments.
CH-OPS integrates with Keycloak to support organizations that already manage their users through their own identity infrastructure.
Keycloak provides capabilities such as:
- Centralized user management
- Role-based access control
- Multi-factor authentication
- LDAP and Active Directory integration
- Custom identity providers
- Enterprise authentication policies
Organizations using Keycloak can integrate CH-OPS without introducing another authentication system.
Okta
Okta is an enterprise identity platform that provides centralized authentication and identity management.
CH-OPS can use an organization's existing Okta environment to authenticate users.
Okta provides features such as:
- Enterprise-grade authentication
- Single Sign-On across applications
- Multi-factor authentication
- Centralized user administration
- Identity lifecycle management
- Enterprise security policies
This makes Okta a suitable choice for organizations that already use Okta as their identity provider.
How SSO Authentication Works in CH-OPS
The CH-OPS SSO implementation uses OpenID Connect (OIDC) to communicate with external identity providers.
An important part of the implementation is that authentication and authorization are treated as separate concerns.
The identity provider verifies who the user is, while CH-OPS verifies whether that user is allowed to access the application.
Authentication Flow
The complete authentication flow follows these steps:
- The user opens the CH-OPS login page.
- The user selects an SSO provider.
- CH-OPS initiates the authentication process.
- The user is redirected to Google, Keycloak, or Okta.
- The identity provider authenticates the user.
- The identity provider returns the authentication response to CH-OPS.
- CH-OPS validates the identity information.
- CH-OPS checks whether the user exists in its database.
- If the user is authorized, CH-OPS creates a session and redirects the user to the dashboard.
- If the user does not exist, access is denied.
Let's examine each step in detail.
1. User Selects an SSO Provider
The CH-OPS login page provides SSO options for the supported identity providers.
The user can choose:
- Continue with Google
- Continue with Keycloak
- Continue with Okta
The user selects the identity provider they want to use.
2. CH-OPS Initiates Authentication
When the user clicks an SSO button, CH-OPS initiates the authentication process for the selected provider.
The application determines which identity provider was selected and starts the corresponding OpenID Connect authentication flow.
Conceptually, CH-OPS uses a provider-specific login route:
/:provider/login
For example:
/google/login
/keycloak/login
/okta/login
This allows CH-OPS to maintain a common authentication process while supporting multiple identity providers.
3. Redirect to the Identity Provider
After receiving the login request, CH-OPS initiates the OpenID Connect authentication flow.
The user is redirected from CH-OPS to the selected identity provider through an authorization request.
The identity provider is responsible for authenticating the user.
CH-OPS does not ask the user for their identity-provider password. Instead, the user completes authentication using the provider's existing login mechanism.
If the organization has additional security policies, such as Multi-Factor Authentication (MFA), those policies can also be enforced by the identity provider.
4. Identity Provider Returns the User Information
After successful authentication, the identity provider sends the authorization response back to CH-OPS.
Using OpenID Connect, CH-OPS can obtain the authenticated user's identity information.
The identity information can contain details such as:
- Subject or user ID
- Email address
- Name
- Other identity claims
CH-OPS then validates the identity information received from the provider.
5. CH-OPS Checks the User in the Database
This is an important part of the CH-OPS architecture.
Authentication through the identity provider does not automatically mean that the user is authorized to use CH-OPS.
After receiving the user's identity, CH-OPS checks its application database using the user's email address.
The result determines whether the user is allowed to access CH-OPS.
User Exists
If the email address exists in the CH-OPS database, authentication continues and the user can access CH-OPS.
The flow is:
- The identity provider verifies the user's identity.
- CH-OPS receives and validates the identity information.
- CH-OPS searches its database for the user's email address.
- The user is found.
- Authentication continues.
User Does Not Exist
If the email address does not exist in the CH-OPS database, CH-OPS returns a User Not Found response.
The application does not automatically create a new user account.
This provides an additional authorization layer and prevents anyone with a valid Google, Keycloak, or Okta account from automatically gaining access to CH-OPS.
6. Session Creation and Callback
When the user is successfully found in the CH-OPS database, the authentication process continues.
CH-OPS establishes the authenticated session and redirects the user to the configured callback URL.
The final flow is:
- The SSO provider returns the OIDC response.
- CH-OPS validates the identity.
- CH-OPS checks the user's email address against its database.
- If the user is not found, access is denied.
- If the user is found, CH-OPS creates a session.
- The user is redirected to the callback URL.
- The CH-OPS dashboard becomes accessible.
The user can now access CH-OPS without having a separate CH-OPS password.
Authentication Flow Summary
The complete CH-OPS authentication process can be summarized as follows:
Successful authentication:
User → SSO Button → CH-OPS Authentication → Identity Provider → OpenID Connect → Identity Validation → Email Lookup → CH-OPS Database → Create Session → Callback URL → CH-OPS Dashboard
Unsuccessful authorization:
User → SSO Button → CH-OPS Authentication → Identity Provider → OpenID Connect → Identity Validation → Email Lookup → User Not Found → Access Denied
This design gives CH-OPS both external identity verification and application-level access control.
Authentication vs. Authorization
One of the important concepts in the CH-OPS SSO implementation is the separation between authentication and authorization.
Authentication
Authentication answers the question:
Who is this user?
Google, Keycloak, or Okta authenticates the user and provides the user's identity information through OpenID Connect.
Authorization
Authorization answers the question:
Is this user allowed to access CH-OPS?
CH-OPS checks the user's email address against its own database.
Therefore, having a valid Google, Keycloak, or Okta account does not automatically grant access to CH-OPS.
The user must also exist in the CH-OPS database.
Security Features
Security is a primary focus of the CH-OPS authentication architecture.
OpenID Connect
CH-OPS uses OpenID Connect (OIDC) for standardized identity authentication.
OIDC provides an identity layer on top of OAuth 2.0, allowing applications to verify users through supported identity providers.
OAuth 2.0
The authentication flow uses OAuth 2.0 authorization mechanisms, with OpenID Connect providing the authentication and identity layer.
Provider-Side Password Management
CH-OPS does not directly handle or store passwords for Google, Keycloak, or Okta users.
Instead, users authenticate through their chosen identity provider.
Token Validation
Identity information received from the provider is validated before the application continues authentication.
This helps ensure that the application relies on a valid authentication response.
HTTPS
Communication between CH-OPS and identity providers should use HTTPS to protect authentication data during transit.
Application-Level Authorization
Even after successful authentication, CH-OPS checks whether the user exists in its database before granting access.
This ensures that authentication by an external identity provider alone is not sufficient to access the application.
Multi-Factor Authentication
Organizations can use MFA configured at their identity provider, allowing CH-OPS to benefit from the provider's authentication security policies.
Why Support Multiple SSO Providers?
Different organizations use different identity platforms.
By supporting multiple providers, CH-OPS can integrate into existing authentication environments without forcing organizations to change their identity infrastructure.
| Organization Type | Recommended Provider |
|---|---|
| Google Workspace users | |
| Open-source or self-hosted infrastructure | Keycloak |
| Enterprise identity management | Okta |
This flexibility allows CH-OPS to support different organizational environments while maintaining a consistent application-level authentication flow.
The User Experience
From the user's perspective, the authentication process is simple.
The user opens the CH-OPS login page, selects their organization's preferred SSO provider, completes authentication with that provider, and is redirected back to CH-OPS.
If the user is already registered in CH-OPS, they can immediately access the application.
There is no need to create or remember another password.
Behind this simple experience, CH-OPS performs several security checks:
- Choose an identity provider.
- Authenticate with the provider.
- Validate the identity.
- Check the CH-OPS user database.
- Create an authenticated session.
- Access the application.
The result is a login experience that is both simple for users and controlled by the application.
Conclusion
Authentication should be secure, reliable, and effortless.
CH-OPS achieves this by integrating with Google, Keycloak, and Okta using OpenID Connect.
The architecture delegates user authentication to trusted identity providers while keeping application-level authorization under the control of CH-OPS.
The key principle is simple:
The identity provider verifies the user's identity; CH-OPS verifies whether that user is authorized to access the application.
When a user clicks an SSO button, CH-OPS initiates the authentication process, communicates with the selected identity provider through OpenID Connect, retrieves the user's identity, and checks the user's email address against the CH-OPS database.
If the user exists, CH-OPS establishes the session and redirects the user to the callback URL. If the user does not exist, access is denied with a User Not Found response.
This approach provides CH-OPS with a flexible, secure, and centralized authentication mechanism while allowing organizations to continue using the identity infrastructure they already trust.
References
- CH-Ops Installation Guide
- CH-Ops Official Repository
- CH-Ops Demo Video
Next in the CHOps Series
CH-Ops Pro Scheduled Archival: Move ClickHouse® Data to S3
Top comments (0)