Set Up SSO for Your Organization
Connect your identity provider to ops0 so team members sign in with company credentials and are automatically provisioned with the right roles.
Scenario
Your company uses Okta, Azure AD, or Google Workspace. You want everyone to log in via SSO instead of email and password, and you want new hires automatically added to ops0 with the right role when they log in for the first time — no manual invite required.
Prerequisites
✓ops0 Organization Owner access
✓Admin access to your identity provider (Okta, Azure AD, Google Workspace, etc.)
Step 1: Open the SSO Settings
1Go to Settings > SSO
2Click Add Provider
3Choose OIDC or SAML — for Okta and Azure AD, OIDC is simpler; for older enterprise IdPs, SAML is more compatible
OIDC Path
1In your IdP, create a new OIDC application and copy the Client ID, Client Secret, and Issuer URL
2Paste those values into ops0 — ops0 auto-discovers all endpoints from the Issuer URL
SAML Path
1Download the ops0 Service Provider metadata, or copy the ACS URL and Entity ID shown in ops0 Settings > SSO
2Configure those values in your IdP application
3Paste the IdP metadata URL back into ops0
Step 3: Set the Redirect URI
2Click Test Connection in ops0 — ops0 attempts a login flow and reports success or error
3Click Save
After connecting, map IdP groups to ops0 roles so users get the right permissions automatically.
| IdP Group | ops0 Role | Access Level |
|---|
engineering-leads | Admin | Full platform access |
developers | Editor | Create/deploy projects |
security-team | Viewer | Read-only across all features |
approvers | Editor | Deploy with approval rights |
The org-level role is set by group mapping. Project-level Approver rights are granted separately, per project, in the project's Collaborators tab.
Step 5: Enable Auto-Provisioning
1Toggle on Auto-Provisioning in Settings > SSO
2When a user authenticates via SSO for the first time, ops0 creates their account automatically using the mapped role
Without auto-provisioning enabled, an admin must invite each user manually before they can log in.
Step 6: Restrict to Specific Domains
1In Settings > SSO, find Allowed Email Domains
2Add your domain (e.g. company.com) to prevent users outside your org from logging in, even if they have IdP credentials
Step 7: Test the Login Flow
1Open a private browser window and go to the ops0 login page
2Click Continue with SSO and enter your work email address
3You should be redirected to your IdP login page and then back to the ops0 dashboard
Verification Checklist
✓User sees the ops0 dashboard after IdP login
✓User's org role matches the group mapping configured in Step 4
✓Audit Logs (Settings > Audit Logs) show the SSO login event
Troubleshooting
Invalid redirect URI
The ACS URL or redirect URI in your IdP does not match what ops0 expects. Copy it exactly from Settings > SSO — do not retype it manually.
User not provisioned
Auto-provisioning is off. Either enable it in Settings > SSO, or invite the user manually from Settings > IAM & Roles before they attempt to log in.
Attribute mapping failed
Your IdP is not sending the email claim. In your IdP application configuration, map the email attribute to the standard claim that ops0 expects.
Locked out after SSO misconfiguration
Contact support with your organization admin email. SSO can be disabled from the backend to restore email/password access.
Next Steps
