Celigo Identity is the unified identity and access management system for end users in Celigo. It controls who can use Celigo capabilities through external clients, today, MCP servers from Claude, Cursor, and other AI clients, without giving those users access to integrator.io.
Celigo Identity sits alongside, but separate from, workspace-user authentication. Workspace users, the people who build integrations in integrator.io, authenticate through your account's SSO or Celigo credentials. End users, the people who consume MCP tools, authenticate through Celigo Identity instead, with their own auth methods, group model, and lifecycle. Celigo Identity requires a multi-environment account. Legacy sandbox-only accounts don't have end users, groups, or capability sets available.
What Celigo identity manages
| Concept | What it does | Where to configure |
|---|---|---|
| End users | A lightweight user type for people who consume MCP tools. End users have no integrator.io access. | Account → Users → End users → Users |
| End-user authentication | How end users sign in. Celigo credentials (email/password) by default, with optional MFA and optional external OIDC IdPs (Okta, Entra ID, and others). | Account → Security → End users → Authentication |
| End-user groups | Bundles of end users that share access to MCP servers and capabilities. Groups can be Celigo-managed or synced from an external IdP. | Account → Users → End users → Groups |
| Capability sets | Named collections of capabilities on a single MCP server, used to assign capability bundles to groups or individual end users. | MCP server → Access tab → Capability Sets. See Create and manage capability sets |
End users vs. workspace users
| Workspace users | End users | |
|---|---|---|
| Purpose | Build integrations, manage flows, monitor errors, administer accounts | Consume MCP tools via AI clients |
| integrator.io access | Yes | No, blocked from signing in |
| Auth model | Account SSO or Celigo credentials | Celigo credentials or external IdPs, configured separately from account SSO |
| Access model | AShare with access level (monitor, manage, administrator) | End user groups and direct MCP server assignments |
| Provisioning | Manual invitation; OIDC-based account SSO | Manual invitation; OIDC IdPs with JIT provisioning and group sync |
MFA isn't a separate sign-in method for either, it's an additional verification step layered on top of whichever method someone signs in with. For end users, an admin can require MFA on Celigo-credential sign-ins (off by default); end users on an external IdP get MFA from the IdP instead. The same person can be both a workspace user and an end user in the same account, an user who builds integrations and also uses MCP tools, for example. That's two records, but one email, one password, and one MFA enrollment: what differs is what each record's sign-in grants access to.
Authentication options
End users have two authentication paths in Celigo Identity:
Celigo credentials (default)
Email and password, set by the end user during invitation. Available by default on every account, with optional MFA. Best for small teams, dev/test, internal pilots, or any user whose email domain isn't claimed by an external IdP.
External OIDC identity providers
OIDC (Open ID Connect) based SSO through providers like Okta, Microsoft Entra ID, and others. Routed by email domain, or set as the catch-all for all end users. Supports JIT provisioning (auto-creating end users on first sign-in) and, for a limited set of providers, group sync (reading group memberships from OIDC tokens). Best for production rollouts where end users come from an enterprise IdP. See Configure end-user authentication for the full setup.
Identity model: per-account configuration, global user object
Celigo Identity is configured per account. Each Celigo account, which corresponds to a Celigo environment, has its own:
- IdP configurations
- JIT and group sync settings
- End-user groups and capability sets
- Authentication settings, including MFA
The end-user object itself is global. The OIDC sub is the durable link between an end-user record and the IdPs that authenticate them. When the same person authenticates to multiple Celigo accounts, they share a single end-user object, but their access in each account is independent, existing access in account A doesn't grant access in account B. They need to be invited or trigger JIT there too. A few things follow from this:
- A user's name and email are populated once, at first link, and preserved on later logins even if a different IdP authenticates them next. To update those fields, an admin edits the end-user record directly.
- IdP configurations don't carry over between accounts, setting up Okta in account A doesn't make it available in account B.
- The same group name in two different accounts is two separate Celigo groups, managed independently.
Authentication flow
When an end user connects to a Celigo MCP server from an MCP client:
- The MCP client starts the OAuth flow: Claude, Cursor, or another client opens a browser for sign-in.
- Celigo asks for the end user's email, to figure out which authentication path applies.
- Celigo checks routing: is there a configured IdP that claims the email's domain, or an "All end users" IdP? If so, the end user is redirected to the IdP. If not, they sign in with Celigo credentials.
- Authentication happens at the IdP, or at Celigo's sign-in page. MFA is enforced wherever it's configured: the IdP for IdP-routed users, Celigo for Celigo-credentials users.
- Celigo issues an access token and resolves groups — if the end user authenticated through an IdP with group sync enabled, Celigo reads the groups claim and updates memberships.
- The MCP client receives the token, and the end user can now use whatever their group memberships and direct assignments grant. IdP-initiated SSO isn't supported. Authentication always has to start from the MCP client — that's an MCP architectural constraint, not a Celigo limitation. The MCP client has to initiate the OAuth flow to receive the access token.
How Celigo Identity relates to MCP server OAuth
Celigo's MCP servers are OIDC providers. Celigo Identity manages the end user side of that OAuth flow: who the end user is, how they authenticate, and what capabilities they're authorized to use. The MCP server itself is the OAuth resource server. When an MCP client requests a token, Celigo Identity:
- Identifies the end user, through Celigo credentials or an external IdP.
- Resolves their effective access for groups and direct assignments, down to MCP servers and capabilities.
- Embeds the resolved capability list in the access token issued to the MCP client.
If the access token came from an external IdP that grants read-only or read-write access, Celigo Identity only grants the capabilities whose own read/write level the token allows, a read-only token gets read capabilities, a read-write token gets both. Read vs. write is a property of each capability, not of the capability set.