Enterprise
Single sign-on via SAML and OIDC
Bring Ciao under the identity controls you already run — SAML or OIDC, optional MFA, just-in-time provisioning and session policies enforced where they belong: at your IdP.
Ciao supports single sign-on via SAML and OIDC, with optional MFA and role-based access control. Unlike password-based tools that create a parallel identity silo, SSO puts Ciao behind your existing identity provider — so joiners get access through your directory, session and re-authentication policies follow your IdP's rules, and leavers lose access the moment your IdP deactivates them.
Published 2026-07-03 · Last updated 2026-07-03
Why SSO is usually the first enterprise requirement
Every tool that holds its own passwords is a tool your offboarding process can miss. For a platform where a signed-in user can prompt changes to production software, that risk is sharper than for a dashboard product: an orphaned account is not just a data-exposure question but a change-control question. Security reviews are right to put SSO near the top of the requirements list.
SSO moves authentication for Ciao behind the identity provider you already govern. Access reviews happen in one place, MFA policy is enforced consistently, and the joiner-mover-leaver process your auditors already accept extends to cover AI-assisted development without a parallel account store to reconcile.
There is a quieter benefit for the people doing the work: one less password, one less login ritual, and access that appears on day one because the directory — not a ticket queue — is the source of truth. Controls that make the secure path the convenient path are the controls people actually follow, and SSO is the clearest example in the identity stack.
What Ciao provides
The identity capabilities below are part of the enterprise platform, and each is verifiable during onboarding or evaluation:
- SAML and OIDC — SSO via both major protocols, so Ciao works with the IdP you run today rather than requiring a specific vendor.
- Optional MFA — MFA can be enforced through your IdP's policy, with optional MFA available on the Ciao side as part of the identity setup.
- Role-based access control — SSO pairs with RBAC, so authentication answers who you are and roles answer what you may do — across workspaces and projects.
- Just-in-time provisioning — Accounts can be created on first successful sign-in through your IdP, so onboarding does not depend on manual account creation.
- Audited admin actions — Identity and access changes are admin actions, and admin actions are recorded in the append-only audit trail.
How setup works
1. Choose the protocol
SAML or OIDC, based on what your IdP team prefers. Neither is the 'lesser' option — pick the one your identity tooling manages best.
2. Create the application in your IdP
Register Ciao in your identity provider the way you register any SSO application, and assign the users or groups who should have access.
3. Exchange configuration
Metadata, endpoints and certificates are exchanged between your IdP and Ciao during onboarding, with the enterprise team walking through it alongside your identity engineers.
4. Test with a pilot group
Verify sign-in, just-in-time account creation and role assignment with a small group before opening access more widely.
5. Roll out and review
Extend assignment to the full population, then confirm in the audit trail that access events and admin actions are recorded the way your review expects.
Just-in-time provisioning and what it does not solve
Just-in-time provisioning creates a Ciao account the first time a user signs in through your IdP. That removes the manual step at onboarding and prevents pre-created accounts from sitting unused. What JIT does not do is deprovision: a user who never signs in again still needs their access removed at the IdP, and lifecycle automation is better handled by SCIM. Most enterprise deployments run SSO with JIT for arrival and SCIM for the full lifecycle — the SCIM page covers that half.
During evaluation, test the JIT path explicitly: assign a test user in the IdP, sign in once, and confirm the account arrives with the role your mapping intended. The five-minute test tells you more than any architecture diagram.
Session policies and MFA
Session length, re-authentication frequency and step-up rules belong at the identity provider, where your security team already tunes them, and SSO means Ciao sessions follow the policy your IdP enforces at sign-in. MFA works the same way: enforce it in the IdP policy that governs Ciao access, with optional MFA available on the platform side. The practical result for reviewers is a single policy surface to audit instead of per-tool session settings that drift.
When your policy changes — shorter sessions, stricter step-up rules — you change it once, at the IdP, and access to Ciao follows without a parallel settings audit on the platform side.
Verification notes
Identity claims are cheap to verify: configure a test connection during evaluation and watch sign-in, JIT account creation and role mapping happen against your own IdP. The security pack, available on request via the contact page, documents the identity architecture in writing, and SOC 2 Type II reports under NDA cover the audited access-management controls behind it.
Capabilities at a glance
| Capability | Mechanism | Notes |
|---|---|---|
| Single sign-on | SAML or OIDC | Works with standards-compliant identity providers |
| Multi-factor authentication | IdP policy, plus optional MFA on Ciao | Enforce where your team already governs MFA |
| Account creation | Just-in-time on first sign-in | Pairs with SCIM for full lifecycle |
| Authorization | Role-based access control | Workspace and project scoping |
| Evidence | Append-only audit trail | Admin actions recorded for review |
Frequently asked questions
Which identity providers are supported?
Any identity provider that implements SAML or OIDC — the IdPs enterprises commonly run, such as Okta, Microsoft Entra ID and Google Workspace, all speak these protocols. Configuration is walked through with your identity team during onboarding.
Can we require that all users sign in through SSO only?
Enforcing SSO as the sole sign-in path is an identity-configuration question handled during onboarding — raise it with the enterprise team and your setup will be confirmed against the requirement rather than assumed.
What happens when an employee leaves?
Deactivate them at the IdP and they can no longer authenticate to Ciao. With SCIM provisioning in place, deactivation also propagates as a lifecycle event, and the surrounding admin actions are recorded in the append-only audit trail.
What is the difference between JIT and SCIM?
JIT creates an account when a user first signs in; it handles arrival only. SCIM pushes create, update and deactivate events from your IdP on an ongoing basis, covering the whole lifecycle. Most enterprise rollouts use both together.
Is SSO included, or an add-on?
SSO via SAML and OIDC is part of Ciao's enterprise capability set. Serious production programs start at USD 10,000 per year — confirm plan scope with sales so identity requirements are in the agreement from the start.