MVP SCIM functionality

[Amrit]

Hello,

We are in the initial stages of building a custom SCIM 2.0 server to integrate with Okta as an Identity Provider.
Our goal is to understand if we can adopt an incremental, phased approach to building out our SCIM capabilities, or if the Okta SCIM client requires a fully functional server (supporting all core operations) from day one to work correctly.

For example, could we follow a development plan like this?

1. Phase 1 (Deprovisioning Focus): Initially, only implement GET /Users (for lookups) and PATCH /Users (specifically to support deactivation with active: false).
2. Phase 2 (Provisioning): Later, add support for POST /Users to handle user creation.
3. Phase 3 (Groups, etc.): Subsequently, add support for /Groups and other features.

Our Specific Questions Are:

1. Is an incremental approach viable? Or will the Okta provisioning service encounter critical, non-recoverable errors if, for instance, it attempts to create a user but the POST /Users endpoint is not yet implemented?
2. What is the minimum required set of endpoints for the Okta SCIM client to function without getting into a persistent error state? For example, must POST /Users be available before any users are assigned to the application?
3. What is the recommended best practice from Okta for developing a new SCIM integration? Is there a “minimum viable SCIM server” definition that we should aim for in our first release?

We want to ensure we can deliver value iteratively without causing downstream issues in our customers’ Okta tenants. Any guidance or insights from your experience would be greatly appreciated.

[ramgan]

@Amrit

incremental approach viable? Or will the Okta provisioning service encounter critical, non-recoverable errors if, for insta

GET /users is the only mandatory method you need, you could technically release a version accepting GET and PATCH requests and progressively perform upgrades to your app. You might have to support SCIM compliant filtering in your endpoint even in your first version as Okta tries to locate existing users for any operation.

During submission you would select something like this

Here are couple of blogs about building a SCIM server

How to Submit Your System for Cross-domain Identity Management (SCIM)...

How to Manage User Lifecycle with .NET and SCIM

[Amrit]

Hi Ram, thanks for your reply. We enabled SCIM only for deprovisioning and we are receiving PUT as well as POST request. We don’t see any PATCH request. Can you advise on how best to move ahead ?

[ramgan]

@Amrit

We don’t see any PATCH request. Can you advise on how best to move ahead ?

What kind of app are you using? An app created using AIW via Create App Integration button or using template app (refer this)

What are the steps you are doing to get the PUT/POST requests?

What does your provisioning settings look like?

I see a PATCH request during deactivation on my side similar to what is mentioned here.

You can create a support ticket if you want to share your org specific details for our engineers to take a closer look.