Last verified · 1 day ago
SCIM provisioning from Okta to an Atlassian organization is real, documented on both sides and does create, update and deactivate accounts. It is not a complete offboarding control on its own, it requires a paid Atlassian Guard Standard subscription plus Okta Lifecycle Management, and the failure modes cluster around domain verification and group naming.
Okta → Jira Cloud Partial
Two days
SCIM provisioning into the Atlassian organization, working.
Erick Ingleby, not a vendor figure
The question people actually ask is the offboarding one: if I deactivate someone in Okta on Friday afternoon, are they out of Jira by Friday evening. The honest answer is mostly, with an important exception. Provisioning is scoped to the Atlassian organization, not to Jira directly, so what you are really configuring is Okta to Atlassian organization over SCIM 2.0, with Jira and Confluence downstream of that. For a user on a verified domain it works the way you would hope. For an external user, meaning one whose email is not on a domain you have verified, deactivation removes them from SCIM-provisioned groups but leaves them with Atlassian site access until someone removes them from the site by hand. Verify your domains before you trust this as a control.
In my own words
The license is worth it. Provisioning specifically, not just sign on.
There is very little downside here. Authenticate your people through Okta, sync them properly, and your security posture goes up. This one is not complicated.
Erick Ingleby
Provisioning is available for all Atlassian accounts. Creating a user in Okta creates an Atlassian account if one does not already exist for that email, and links to it if one does. Deactivating in Okta deactivates the Atlassian account for users on your verified domain.
Display name, email address, organization, job title, timezone, department and preferred language all sync from the identity provider. Updating display name overwrites first and last name, which is worth knowing before you map both.
Groups pushed from Okta arrive as read-only groups in the organization directory and can be used to grant app access, admin privileges and application-specific settings. This is the mechanism by which joining a group in Okta hands someone a Jira license, and it is the part that actually saves work.
Atlassian publishes step-by-step instructions specifically for Okta, alongside OneLogin, Azure AD, Cisco Duo, Google Cloud, Google Workspace, PingFederate and JumpCloud. You add the Atlassian Cloud application in Okta and paste in the SCIM base URL and API key generated on the Atlassian side.
Atlassian documents a user provisioning API for building your own integration where the identity provider is unsupported, and for automating user account operations directly.
When you deactivate an external user, they are removed from SCIM-provisioned groups and may lose app access granted through those groups, but they still have Atlassian site access. Atlassian's own instruction is that to remove site access after deactivation you remove the user from the site. If you are relying on Okta deactivation as your offboarding control, that is a manual step your runbook probably does not have.
Deleting a user in the identity provider deactivates the Atlassian account rather than deleting it, for external users. Actual deletion for a verified domain user is done from the Atlassian directory, not from Okta.
User provisioning requires an Atlassian Guard Standard subscription on the Atlassian side and the user provisioning functionality on the Okta side, which is Lifecycle Management. Both are paid. There is no free tier of this integration, whatever the feature matrix implies.
Changing a user's email address to an unverified domain removes them from groups provisioned by SCIM and may cost them app access granted through those groups. Attributes are not synced for external users at all, so an update in Okta simply does not land. Domain verification is not paperwork here, it is the thing that makes the integration behave.
A group whose name matches an Atlassian built-in group will not sync. The reserved names are atlassian-addons, atlassian-addons-admin, site-admins, org-admins, administrators and system-administrators. A synced group can also arrive successfully but empty if it collides with a default or manually created group. Renaming a group after it has synced is not supported either: you create a new group, move the membership, and delete the old one.
Atlassian documents this one against Okta by name. Users who were already assigned to the Atlassian app before the provisioning integration was finished do not sync to the organization directory. The fix is to reassign them from the Assignments tab, or reassign the group containing them. Nothing is recorded in the troubleshooting log when this happens.
From early January 2025 Atlassian automatically sets SCIM API keys to expire in one year when you set up user provisioning or regenerate a key. Existing keys created before that were not affected. If nobody owns the renewal, provisioning stops roughly twelve months after the person who set it up has moved on.
Atlassian recommends staying below 1 million users, 290,000 users per group, 250,000 groups and 8 million total group memberships, and warns that syncing more than 500 groups will take a significant amount of time. These are large numbers, but the 500 group warning is not, and plenty of mid-sized organizations push more than that.
Account provisioning covers all Atlassian accounts, but group syncing is currently available for Jira app instances, Confluence and Trello and not yet for Bitbucket. If your access model assumes one identity provider group governs every Atlassian product, it does not.
Source of the SCIM 2.0 basis, the supported user and group operations, the external user deactivation and deletion behavior, the unverified domain effects, the reserved built-in group names, the Okta reassignment trap, the sync size recommendations and the 500 group warning, and the statement that group sync does not yet cover Bitbucket.
VENDOR DOC · Checked
Source of the Atlassian Guard Standard and Okta Lifecycle Management prerequisites, the domain verification requirement, the SCIM base URL and API key flow, and the January 2025 change making new SCIM API keys expire after a year.
VENDOR DOC · Checked