Skip to content
English
  • There are no suggestions because the search field is empty.

Single Sign-On (SSO) Authentication Options

Our administration portal supports SSO via Google and Okta, enabling secure login without requiring separate credentials for each system. Note: SSO applies only to the administration portal and is not used for the marketplace.

Supported Identity Providers

  • Google

  • Okta

  • Authentik

How It Works (Protocols)

SSO is implemented using OpenID Connect (OIDC), which is built on top of OAuth 2.0.
This protocol securely delegates authentication by redirecting users to their chosen identity provider (IdP). After successful authentication, the IdP returns an ID token that confirms the user’s identity — without exposing any credentials to our system.

Login Flow Overview

  1. The user selects “Sign in with Google,” “Sign in with Okta,” or “Sign in with Authentik.”

  2. auth.cossystems.com initiates the OIDC/OAuth2 flow and redirects the user to the IdP.

  3. After successful authentication, the IdP returns tokens to auth.cossystems.com, which validates the response and grants access to the administration portal.

Google SSO

Users can authenticate with their existing Google accounts. The login process is handled by auth.cossystems.com, which acts as an OIDC client to manage token exchange automatically and ensure a smooth user experience.

Okta SSO

Okta acts as an enterprise-grade identity provider, configured directly within the administration interface. The login flow uses OIDC/OAuth2 and provides a seamless authentication experience equivalent to Google’s.

Authentik SSO

Authentik provides a flexible, self-hosted identity and access management solution.
Through OIDC/OAuth2 integration, Authentik enables secure SSO with customizable user and group mappings, making it well-suited for organizations managing their own authentication infrastructure.

User Identification and Matching

When logging in via Google, Okta, or Authentik, the system retrieves the user’s email and a unique identifier (sub). Each user account contains an ExternalId field, which determines how authentication is handled:

  • If ExternalId is set, the system attempts to match the sub value with ExternalId. If they don’t match, login is denied.

  • If ExternalId is empty, the system falls back to matching users by email.