Single Sign On (SSO)

Single Sign-On (SSO) lets users access Zitcha using their organisation’s existing corporate credentials instead of a separate Zitcha password.

Overview

Single Sign-On (SSO) allows users to log into Zitcha using their organisation's existing identity provider (IdP), such as Okta, Microsoft Entra ID (Azure AD), or Google Workspace.

Instead of maintaining a separate Zitcha password, users authenticate using the same credentials they already use for internal corporate systems.

SSO is configured per organisation and managed through Auth0, Zitcha’s authentication platform. It is suited to retailers and advertisers who require:

  • Centralised access control
  • Simplified onboarding
  • Alignment with internal security and compliance policies

How SSO Works

When SSO is enabled, the login process follows this flow:

  1. The user visits the Zitcha login page and enters their email address.
  2. Auth0 recognises the email domain (for example, @yourcompany.com) and routes the user to the correct identity provider. This process is known as Home Realm Discovery.
  3. The user authenticates using their corporate credentials, including any required MFA.
  4. The identity provider sends a secure assertion back to Zitcha via Auth0.
  5. Zitcha matches the authenticated identity to an existing user account based on email address.
  6. The user is logged in to Zitcha.

Users do not need to manually select their identity provider, and they do not need to create or remember a separate Zitcha password.

Important:
SSO does not automatically create user accounts. A user must already exist in Zitcha and be invited by an administrator before they can log in via SSO.

Supported Protocols

Zitcha supports enterprise SSO connections through Auth0 using the following industry-standard protocols:

ProtocolDescription
SAML 2.0Security Assertion Markup Language, widely supported by enterprise identity providers
OIDCOpenID Connect, a modern authentication layer built on OAuth 2.0

Protocol configuration is managed at the Auth0 level. Your Zitcha account representative can advise on the most suitable option for your identity provider.

Compatible Identity Providers

Any identity provider supporting SAML 2.0 or OIDC can be connected via Auth0. Common examples include:

  • Microsoft Entra ID (Azure Active Directory)
  • Okta
  • Google Workspace
  • OneLogin
  • JumpCloud
  • Ping Identity

Requesting SSO Setup

SSO is configured by the Zitcha team.

To request SSO setup, contact your Zitcha Customer Success Manager.

What Zitcha Provides During Setup

Once configuration begins, Zitcha supplies your IT administrator with the required connection details to register Zitcha as a trusted application in your identity provider.

These typically include:

  • Callback URLs
  • Entity identifiers
  • Protocol-specific configuration values

Your IT administrator must register these values within your identity provider.

User Experience with SSO

Prerequisites

Before logging in via SSO, a user must:

  • Be invited to Zitcha by an administrator
  • Have at least one role and one team assigned
  • Be assigned to the Zitcha application within your identity provider

First-Time Login

On first login:

  1. The user authenticates through their identity provider.
  2. Zitcha matches the email address to the existing account.
  3. The user is logged in with their assigned roles and teams.

Note:
The email address in Zitcha must exactly match the email address in the identity provider. If they differ, authentication will fail. Ensure email addresses are consistent across both systems.

Ongoing Login

For returning users:

  1. Navigate to the Zitcha login page.
  2. Authenticate via your corporate identity provider.
  3. You are logged into your last active organisation.

Managing SSO Users

SSO changes how users authenticate, but user administration inside Zitcha remains largely the same.

What Stays the Same

  • User invitations
    Users must be invited before accessing Zitcha.

  • Team and role assignment
    Roles and teams are assigned during invitation and are not provisioned automatically by SSO.

  • Deactivation
    Deactivating a user in Zitcha prevents platform access. It is recommended to also remove them from the Zitcha application in your identity provider.

  • Editing user details
    Administrators can update user details under:
    Settings > Organisation > Users

What Changes

  • No Zitcha password
    SSO users authenticate exclusively through their identity provider. The “Forgot password” flow does not apply.

  • Offboarding
    Offboarding should include:

    1. Deactivating the user in Zitcha
    2. Removing the user from the Zitcha application in your identity provider
  • MFA management
    Multi-factor authentication is controlled by your identity provider, not by Zitcha.

Frequently Asked Questions

A user cannot log in via SSO

Check the following:

  • The email address in Zitcha exactly matches the identity provider email
  • The user has been invited and their account exists
  • The user has not been deactivated
  • The user is assigned to the Zitcha application in your identity provider

A new user does not appear in Zitcha after SSO login

SSO does not create accounts automatically.
An administrator must invite the user before they can authenticate. Settings > Organisation > Users (see Creating a User). Once invited, the user can authenticate via SSO.

Can SSO and password-based login coexist?

This depends on your organisation’s configuration. Contact the Zitcha team to discuss requirements.

Who manages credentials for SSO users?

Your organisation’s IT team manages credentials through your identity provider. Zitcha does not store passwords for SSO users.

Does SSO affect API access?

No.

SSO applies only to interactive user login. API integrations use separate machine-to-machine credentials and are not impacted by SSO configuration.