Provisioning: JIT vs SCIM
A trade-off comparison between two different provisioning strategies.
This is the process of managing user accounts throughout their life cycles within an application, especially in the case of an SSO integration. Creating, updating and deleting users from your application as per an identity provider (IdP) that serves as the source of truth.
This is not to be understood as authentication itself, as authentication answers whether someone is who they claim to be. Provisioning makes sure that the identity’s attributes are properly defined on the application: email, roles, groups, etc.
There are two ways provisioning can be done:
- Reactively: with Just in Time (JIT) Provisioning, done right when a user logs in;
- Proactively: with System for Cross-domain Identity Management (SCIM), continuously updated by an identity provider regardless of whether the user ever logs in to the application.
The application creates the user’s account on demand, right at login time, based on the SSO information provided by an identity provider. There is no separate, previously required step for setting up any user account nor any administration needed. For existing users, provisioning also may update any already existing information based on what the IdP provides (each application decides what to do).
This is a simple and effective solution, though it is limited by the fact that information is only ever updated whenever a user signs in to the application.
JIT is unable to handle any other aspect of a user’s life cycle: accounts cannot exist prior to a login, people therefore cannot be referenced in an application, and deprovisioning is not possible, since the IdP is not able to notify the application that any given user should be deleted or deactivated. This limitation is solved by SIM. If our application implements JIT only, these steps would have to be performed manually within the application when possible.
In a SCIM integration, the IdP is the source of truth that feeds our application with user-related data. We must implement a set of HTTP endpoints, such as /Users with the GET, DELETE, PATCH, POST and PUT verbs (see more in Section 3.2 of RFC 7644).
This allows users to exist in our application before they ever log in, which can be a nice-to-have, but the greatest benefit of SCIM is the ability of offboarding users based on signals provided by the IdP.
When a user is deactivated or removed on the IdP, it tells our application that we should do the same, and based on this information we may choose to end the user’s session and revoke its access, or even completely delete his account.
The two of them should not be seen as competitors, but rather as complementary to each other and we must decide whether to choose either one or both of them in our design.
The key difference is that JIT by itself cannot revoke access and SCIM can. With JIT only, we may block an account on the next login, but we may do nothing regarding its data, permissions or, even more importantly, any active session that may already exist on our application. With SCIM, the IdP may signal to the application that access should be revoked and the account deleted in its entirety with real time updates.
One other important note is that SCIM can set up an account before the first login ever happens; this user can be assigned to groups, mentioned or be invited to conversation threads before it is even onboarded on a new team.
JIT is easy to implement once SSO is already implemented. SCIM is broader and more complex and requires adaptive behaviour based on different IdPs. This maintenance cost must also be taken into account.