# JIT user provisioning > Source-anchored research for JIT user provisioning. Run status: COMPLETED. Parent: [Atlas Federated Authentication](https://llms-explorer.com/tree/atlas-federated-authentication/) · 3 facets · 15 facts · page: https://llms-explorer.com/tree/jit-user-provisioning/ ## How it works - Stitchflow describes Atlas JIT user creation on first login alongside database-access lifecycle claims; MongoDB distinguishes Atlas users, who access the Atlas application, from database users, who access databases. Its “no group sync” statement is not inherently contradicted by its separate “Group Mapping” listing: MongoDB applies IdP-group role mappings at login, and this documented process does not establish continuous group synchronization. Okta’s 2026.09.1 release notes announce SCIM 2.0 provisioning for MongoDB Atlas through the Okta Integration Network; this evidence is specific to the Okta connector, so broad no-SCIM conclusions need connector-specific primary-source checking. (medium confidence) — [source](https://www.stitchflow.com/scim/mongodb) - When IdP group role mappings are configured, Atlas does not allow editing individual users' roles on the Access Manager page; authorization changes should be managed through the federation configuration and group membership. (low confidence) — [source](https://www.mongodb.com/docs/atlas/security/manage-role-mapping.md) ## Comparisons and alternatives - With federated SSO configured, Atlas can create a previously nonexistent user after successful authentication. JIT provisioning therefore occurs at sign-in rather than proactively when an administrator assigns an application. (high confidence) — [source](https://learn.microsoft.com/en-us/entra/identity/saas-apps/mongodb-cloud-tutorial) - JIT role updates depend on login rather than continuous group synchronization. MongoDB warns that an AI client holding a departed user's refresh token can continue acting on their behalf unless the organization deprovisions that user through the Atlas Administration API. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/manage-role-mapping.md) ## Facts and statements - Atlas authorization uses configured organization/project role mappings; assigning a user to the IdP application alone does not specify those Atlas roles. Administrators can map IdP groups to roles and configure a default organization role for new sign-ins. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/manage-role-mapping.md) - Atlas applies role mappings at login and combines all roles obtained from the user's mapped IdP groups. If no mappings are defined or mappings produce no roles, Atlas applies the configured default role. (low confidence) — [source](https://www.mongodb.com/docs/atlas/security/manage-role-mapping.md) - Removing a user from an IdP group can remove the corresponding Atlas organization and project roles at the next login. Role removal fails if it would remove the organization's last Organization Owner. (low confidence) — [source](https://www.mongodb.com/docs/atlas/security/manage-role-mapping.md) - JIT login-time synchronization does not supply immediate offboarding. MongoDB warns that an AI client holding a federated user’s refresh token can continue acting for that user unless the organization deprovisions the user through the Atlas Administration API; it also recommends limiting refresh-token lifetime. (high confidence) — [source](https://www.mongodb.com/docs/atlas/app-connections.md) - Okta’s 2026.09.1 release notes, whose deployment began September 28, announce MongoDB Atlas SCIM 2.0 provisioning. The Atlas integration overview also describes SCIM-based lifecycle management. Therefore, describing all Atlas provisioning as JIT-only is too broad. (high confidence) (verified as of 2026-09-28) — [source](https://help.okta.com/en-us/content/topics/releasenotes/archive/oce-relnotes-2026.htm) - Microsoft documents Atlas JIT provisioning as enabled by default: if the user does not already exist in Atlas, Atlas creates the user after authentication; no separate JIT activation step is required in this SSO tutorial. (low confidence) (verified as of 2026-06-15) — [source](https://learn.microsoft.com/en-us/entra/identity/saas-apps/mongodb-cloud-tutorial) - Federated sign-in and authorization require separate configuration: users assigned to the Okta application can authenticate through its login URL, while mapped organizations and configured roles determine their Atlas access. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-okta.md) - For group-based authorization, the SAML assertion must carry a memberOf attribute. Atlas compares those group values with organization role mappings; the Microsoft Entra tutorial sends Group ID and maps group Object IDs to Atlas organization/project roles. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/manage-role-mapping.md) - MongoDB recommends deprovisioning users through the Atlas Administration API as soon as they lose access and limiting maximum refresh-token lifetime to reduce retained delegated-access exposure. (low confidence) — [source](https://www.mongodb.com/docs/atlas/app-connections.md) - A practical JIT verification should test successful SSO and then inspect organization/project access separately: a new user can receive the configured default organization role, while memberOf-based mappings grant group-dependent permissions. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security/federated-auth-okta.md) - The Okta MongoDB Atlas catalog entry updated September 18, 2026 advertises SCIM-based automated user provisioning. This is an integration-vendor statement, not evidence that every Atlas federation configuration exposes native SCIM. (low confidence) (verified as of 2026-09-18) — [source](https://www.okta.com/integrations/mongodb-atlas/)