Enterprise
Security and SSO
Enterprise customers often need stronger identity and access controls than a single dashboard login can provide.
Enterprise customers often need stronger identity and access controls than a single dashboard login can provide.
Current enterprise security themes
| Theme | What it helps control |
|---|---|
| SSO | Centralized identity through the customer's identity provider |
| Session management | How long users stay signed in and when they must re-authenticate |
| IP allowlists | Network locations allowed to access administrative surfaces when enabled |
| Key restrictions | Which keys can be used for which teams, projects, or workloads |
| Audit-friendly boundaries | Clear ownership for member, key, billing, and policy changes |
SSO support in the current product plan
Supported protocols:
| Protocol | Notes |
|---|---|
| SAML 2.0 | supports major enterprise IdPs such as Azure AD, Okta, and OneLogin |
| OIDC | standard OpenID Connect-based SSO |
Typical configuration inputs
| Input | Notes |
|---|---|
| SSO status | Enable, disable, or roll out gradually |
| Protocol | Choose saml or oidc based on your identity provider |
| IdP URL | Identity provider login or metadata URL |
| Entity ID or Client ID | Depends on the selected protocol |
| X.509 certificate | Needed for SAML flows |
| Admin owner | Person responsible for testing and rollback |
Business rules
- SSO configuration is an admin-level control
- password login may remain available unless the organization enforces SSO-only access
- SSO rollout should include a test connection step before enforcement
- keep at least one clearly owned admin recovery path during rollout
Rollout sequence
- Confirm protocol and identity provider metadata.
- Configure SSO for a test group or controlled admin set.
- Test login, logout, session timeout, and failed-login behavior.
- Confirm the fallback login policy before enforcement.
- Communicate the enforcement date and support path to users.
- Enable stronger enforcement only after the test path succeeds.
Session controls
Enterprise environments commonly need:
- session timeout policies
- forced re-authentication
- optional single-session enforcement
Customer checklist
Before rollout, confirm the protocol, IdP metadata, administrator ownership, fallback login policy, and test plan.
Common mistakes
| Mistake | Risk |
|---|---|
| Enforcing SSO before testing admin login | Organization owners can lock themselves out |
| Forgetting a rollback or recovery owner | Support cannot quickly identify who can approve changes |
| Treating SSO as API key security | Dashboard login and API key custody are different controls |
| Leaving old keys after identity changes | Former users or systems may still have working credentials |