I am currently learning SCIM and one thing that I have come across is the SCIM endpoints need to be on the public DNS so IdPs can call out to them. I have used ngrok to expose my localhost over the internet for testing purposes but I was curious if there is any way I can accomplish this by not exposing my SCIM endpoints on the public DNS. I believe with Azure AD this is possible via the Azure AD Provisioning agent but I was wondering if there was an alternative like the Azure Provisioning agent or anything else for other IdPs such as Okta or PingOne.
Thank you
The SCIM protocol, at RFC-7644, doesn't specify anything about the implementation details of a provisioning agent. The protocol dictates the language that both the IdP and the target domain app will have to share. It doesn't even dictate the authentication layer.
But your point is valid: what if your SCIM REST API has to be network-gated?
A provisioning agent is purely an implementation-specific component that different identity providers opt to provide their admins as a means to allow SCIM provisioning in network-gated environments (e.g., the Azure AD Provisioning Agent and the Okta Provisioning Agent). If your SCIM REST API is gated behind network constraints that disallow the IdP's direct network access, you'll need an agent, but it's important to stress that the agent itself is not part of the SCIM protocol.
In other words, a provisioning agent is a courtesy given to you by your identity provider and not the SCIM 2.0 protocol.
Whether you seek to set up your development or production environment, how your IdP interacts with that environment's SCIM REST API is a decision to be made - agent or no agent. As for your local development environment, it's entirely up to you to decide whether you keep using a reverse tunnel like ngrok or decide to install your IdP's agent on your development stations.
A side-note on event-driven architecture:
I recently wrote a blog post on SCIM 2.0 provisioning on a high level. The idea is simple: instead of "scraping" the state of the identity provider's user pool, you're switching to an event-driven mindset, wherein the IdP informs your SCIM tenant (i.e., your SCIM REST API) of movements in your user pool. Switching to working with an agent kind of augments the idea behind that event-based architecture of SCIM 2.0, but it does work around the network constraint that a lot of organizations have.