Open connectors compared: C1 Baton, Veza OAA and Microsoft's ECMA connector host

Every identity tool has a list of supported applications. Every organization has applications that are not on it. The question is what happens next, and three of the vendors scored here document an answer that involves your own engineers.

C1: Baton and C1 Bridge

C1 lists C1 Connectors and open-source Baton connectors on its homepage, plus C1 Bridge for on-prem systems. Open source means you can read how an existing connector works, copy it, and write one for an application nobody else supports. C1 Bridge is the route for systems that cannot be reached from the internet.

Veza: the Open Authorization API

Veza states that custom systems connect through its Open Authorization API (OAA), and its lifecycle page lists OAA Write. The model is different from a provisioning connector: you send the application's identities and permissions into Veza's Access Graph in a defined format, and with OAA Write changes can flow back. The benefit is that custom applications appear in the same graph and reviews as everything else.

Microsoft: the ECMA connector host

Microsoft documents provisioning connectors for SCIM 2.0, LDAP, SQL, REST, SOAP and PowerShell, with the ECMA connector host running them on-premises so Entra can provision into on-prem applications without opening firewalls. For an application that keeps its users in a database or a directory, a generic connector may be enough without writing code.

How do they differ?

• Direction: ECMA connectors and Baton connectors are built to change accounts in the target application. OAA starts by bringing permission data into Veza's graph, with OAA Write for changes.
• Where it runs: C1 Bridge and the ECMA host run inside your network for on-prem systems.
• What you write: a Baton connector is code; an OAA integration is a data feed in Veza's format; an ECMA LDAP or SQL connector is mostly configuration.

What do they have in common?

They all assume someone knows the application exists and decides to integrate it. None of them finds the application for you. That is why this site scores discovery and no-API reach as separate criteria: a strong connector kit raises the second, not the first.

Who maintains it?

You do. A connector you write is a small software product. When the application changes its schema, API or admin screens, the connector needs an update, and the people who wrote it may have moved on. Before choosing a build-your-own route, list the applications it is for, name the owner of each connector, and decide how you will notice when one stops working.

Where does SCIM fit?

SCIM (RFC 7644) remains the cleanest route when an application supports it. Asking an application vendor to implement SCIM is often cheaper over five years than maintaining a custom connector for it.

Sources