How it works.
Okta connects to Atlas through two open standards. SAML 2.0 handles sign-on: Okta signs the user in and sends a signed assertion to the Atlas Assertion Consumer Service (ACS) URL. SCIM 2.0 handles provisioning: Okta creates, updates, and deactivates Atlas members by calling the Atlas SCIM endpoints with a bearer token you issue in Atlas. Both are on paid plans.
Atlas maps the groups in the SAML assertion to Atlas roles, so a person's access in Atlas follows their Okta groups. The same setup works for Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, and any other standards-based SAML 2.0 and SCIM 2.0 provider, with setup guides in Atlas security settings. Single sign-on and SCIM do not depend on the app connectors in Settings, then Integrations.
Setup steps.
In Atlas, open Settings, then Security, and copy the ACS URL, the metadata URL, and the SCIM base URL.
In your Okta admin console, add a SAML app for Atlas and paste in the ACS URL and metadata URL. Follow the Okta guide in Atlas security settings.
Paste the Okta IdP metadata XML into Atlas, or enter the entity ID, SSO URL, and x509 certificate by hand.
Create a SCIM token in Atlas and paste it into Okta. It is shown once. Map userName, name.givenName, name.familyName, externalId, and active.
Map the Okta groups sent in the assertion to Atlas roles, including any custom roles you have set up.
Run the SAML sample-response test, provision one pilot user, then deactivate them and confirm the SCIM activity panel shows each request. Keep one Atlas owner who can sign in without SSO.
What it syncs.
| Surface | Direction | Cadence | Notes |
|---|---|---|---|
| sign-in | Okta → Atlas | Each sign-in | SAML 2.0 assertion posted to the Atlas ACS URL. |
| members | Okta → Atlas | When Okta sends a SCIM request | Create and update users from userName, name, externalId, and active. |
| deactivation | Okta → Atlas | When Okta sends a SCIM request | Setting a user inactive in Okta disables their Atlas access. |
| role assignments | Derived | Each sign-in | Atlas roles set from the groups in the SAML assertion. |
Security model.
Atlas checks each SAML assertion against the x509 certificate you configured for Okta, and can require signed assertions. You can dry-run a sample SAML response before you turn SSO on for everyone.
The SCIM bearer token is shown once, when you create it. Atlas does not show it again, so if it may have been exposed, rotate it and paste the new token into Okta. Identity events are recorded in the Atlas audit log, which is on paid plans.
Common use cases.
- Single sign-on for the workspace.People sign in to Atlas with their Okta account. No separate Atlas password to manage.
- Onboarding and offboarding from one place.Assign Atlas to a person in Okta and SCIM creates their account. Deactivate them in Okta and their Atlas access is disabled.
- Roles that follow groups.Map Okta groups to Atlas roles once, and access in Atlas tracks group membership in Okta.
Troubleshooting.
- Sign-in fails after setup.The entity ID, SSO URL, certificate, or signing settings do not match between Okta and Atlas. Compare them in Settings, then Security, and run the sample-response test again.
- SCIM requests are rejected.The token was copied incorrectly, revoked, or issued for a different environment. Create a new token in Atlas and paste it into Okta.
- Users are created but not matched correctly.The Okta attribute mapping leaves out userName, externalId, or active. Add them and push the user again.
- SCIM health says it is waiting for the first sync.No request from Okta has reached Atlas yet. Run a provisioning test from Okta and check the activity panel.