Security Overview

Security Architecture

Omnium separates authentication (who you are) from authorization (what you can do). This separation keeps the security model flexible — you can change your identity provider without affecting your permission structure.

In this section

For API Developers

If you are building an integration against the Omnium API, start here:

• API Developer Guide — Authentication flow, token management, roles, and code examples
• API Security Best Practices — Credential lifecycle, permission design, error handling, and a go-live checklist
• Rate Limits — Concurrency and token bucket limits

For Administrators

If you manage users, roles, and identity providers in the Omnium UI:

• UI Authentication — Set up SSO with Entra ID, Auth0, or Azure AD B2C
• SCIM 2.0 Provisioning — Automatic user and role synchronization from your identity provider
• Access Rights and Invitations — Invite users and configure their access

How Roles Work

Omnium uses role-based access control (RBAC) for both the API and the admin UI. Roles are assigned to users and determine which resources and actions they can access.

API Roles

API users authenticate with a client ID and secret, and receive a JWT token containing their roles. There are three access levels, plus resource-specific roles:

Each resource domain (orders, products, customers, etc.) also has Read and Admin roles. See the full role reference for details.

UI Roles

UI users are organized into role groups that combine functional permissions with store and market access. Roles can contain other roles, allowing you to build a hierarchy that reflects your organization.

Role properties:

• Functional permissions — What the user can see and do (e.g., view orders, manage products)
• Store access — Which stores the user can work with (AllStores or specific stores)
• Market access — Which markets the user can work with (AllMarkets or specific markets)

For detailed role configuration, see Roles, access rights, and users.

Tenant Isolation

Omnium is a multi-tenant platform where each customer's data is completely separated at the infrastructure level:

• Data separation — Each tenant's data is stored in its own search index. There is no shared data layer and no need for row-level tenant filtering.
• Token scoping — Every JWT token contains a tenant claim. All API requests are automatically scoped to the tenant associated with the token.
• Cross-tenant protection — An API user belonging to one tenant cannot access another tenant's data, even if they somehow obtain a valid token from another tenant. The system validates that the user's tenant matches the token's tenant on every request.
• Cache isolation — Cached data is automatically keyed by tenant, so tenants never see each other's cached results.

Encryption and Data Protection

Webhook Security

When Omnium sends data to your systems via webhooks, you can secure the connection using any of these methods:

Webhook authentication is configured per connector in Configuration > Connectors. See the Connectors guide for setup details.

Security Checklist

Use this checklist when preparing an integration or environment for production.

API Integrations

• Each integration uses its own dedicated API user (never share credentials between systems)
• Each API user has only the roles it needs (principle of least privilege)
• API users are scoped to specific stores and markets where possible
• Client secrets are stored in a secrets manager or vault — not in source code or config files
• Your integration handles 401 Unauthorized by requesting a new token (not by retrying with the expired one)
• Your integration handles 429 Too Many Requests with exponential backoff
• Test and production environments use separate API users with separate credentials

User Management

• SSO is configured with your identity provider (Entra ID, Auth0, or Azure AD B2C)
• SCIM provisioning is enabled if you have more than a handful of users
• Forced sign-in frequency is enabled for sensitive areas (e.g., authorization settings)
• Departing employees are removed from the identity provider (SCIM handles the rest)
• Role groups follow least privilege — users should only access the stores and markets they work with

Webhooks and Connectors

• All webhook endpoints use HTTPS
• Webhook endpoints validate the authentication header before processing
• Webhook endpoints are idempotent (safe to receive the same event more than once)
• Connector credentials are reviewed periodically and rotated when team members change