A CPaaS moves money and traffic, so access control has to answer in one pass, not after an incident scavenge. Devotel Orbit splits that answer cleanly: people authenticate through SAML 2.0 SSO, and code authenticates through individually-scoped API keys. Each endpoint gets only the role, scopes, and IP conditions it actually needs, and every assertion lands in the audit log.
SAML 2.0 for dashboard access
Human access lives on the SSO path, not on passwords anyone can guess or recycle. The organization admin pastes the IdP metadata URL in the dashboard, and Orbit publishes the three endpoints the IdP handshake needs:
GET /auth/saml/{orgSlug}/metadata— the service-provider metadata XML the IdP downloads during setup.GET /auth/saml/{orgSlug}/login— returns a 302 to the IdP's login page.POST /auth/saml/{orgSlug}/callback— validates the IdP response and issues the Clerk session ticket.
Any public metadata endpoint and login redirect are intentionally unauthenticated, because the IdP must be able to reach them before any session exists. A /settings/saml admin surface holds the same configuration for workspace owners, and a /settings/saml/test-connection probe checks the metadata URL before rollout. Connection problems get a categorical error message — the underlying failure (private IP, disallowed host, unresolvable DNS) stays in the server log, not in the response where it would teach an attacker about the internal network.
Scoped API keys for programmatic access
Machine access is controlled at the key level. An Orbit API key carries a role, a scope list, and an optional IP allowlist, and the effective role is the minimum of the minting user's role and whatever the scopes claim — a developer-minted key can never silently widen to admin. Keys come in live and test mode, rotate without downtime, and show their current scopes in the dashboard so revocation is a lookup, not a hunt.
Scope names are granular (messages:send, messages:read, billing:read, and so on), and the caller can combine them narrowly instead of granting the workspace role by default. That is what makes a leaked key a bounded event instead of a platform-wide event.
Proving it at audit time
SAML auth and scoped keys only help if the evidence is easy to produce. Orbit writes auth events to the audit log on the SAML handoff (auth.saml_login_initiated and friends), and the /audit-log surface lists role changes, key mints, key revocations, and SSO edits with timestamps. Access reviews become a filter on the log, not a Slack archaeology dig.
If you already run an IdP, wiring Orbit through SAML is one settings page and one metadata exchange. If you are just adopting scoped keys, the pattern to aim for is one key per workload with the smallest possible scope list, IP allowlisted wherever that is practical.
Frequently asked questions
Why does Orbit expose the SAML endpoints at all?
The IdP has to be able to fetch /auth/saml/{orgSlug}/metadata and redirect to /auth/saml/{orgSlug}/login before a session exists, so those routes are deliberately unauthenticated. Validation still happens — the org slug is checked and rate limited — but the handshake has to be reachable from the IdP side.
Can a scoped key ever exceed the role of the user who minted it?
No. The effective role is capped at the lesser of the minting user's role and whatever the key's scopes resolve to, so a developer-minted key with an admin scope still resolves to developer. Scopes can only narrow a role, never widen one.
What does a scoped-key audit actually look at?
The audit log records mints, rotations, revocations, and scope edits, so a reviewer can list every key that ever held a given scope, which role minted it, and when that happened — instead of diffing live key rows in the dashboard.