Scim Protocol
The scim protocol is an open standard that syncs user accounts across cloud apps. You set it up by linking your main directory to a target app with a token. Teams use this setup to add new hires and remove former staff right away. Still, synced groups often give engineers broad roles that stay active all day. When an account holds wide permissions, one bad command can drop production data. How the scim protocol works in practice The scim protocol stands for System for Cross-domain Identity Ma
Model Context Protocol (MCP) Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The scim protocol is an open standard that syncs user accounts across cloud apps. You set it up by linking your main directory to a target app with a token. Teams use this setup to add new hires and remove former staff right away. Still, synced groups often give engineers broad roles that stay active all day. When an account holds wide permissions, one bad command can drop production data.
How the scim protocol works in practice
The scim protocol stands for System for Cross-domain Identity Management. It uses a standard web API to send user data in JSON format. In this setup, your main identity provider acts as the client. Your cloud app or database tool acts as the service provider.
First, the identity provider holds the master record for each person on your team. Every user record uses a fixed schema with basic fields like work email and status. Groups have their own schema to list members and map them to app roles. When HR hires an engineer, the admin adds that person to the main directory.
Next, the directory sends a web request to the target app over HTTPS. The target app reads the JSON payload and creates a local account right away. If the user changes teams, the directory sends an update request to change their group. When someone leaves the company, the directory sends a call to turn off the account. This central flow removes the need for admins to create accounts by hand.
Mapping directory groups to app roles
Most teams pair user sync with single sign-on to manage both accounts and logins. Single sign-on checks who the user is when they log in to an app. Meanwhile, the sync process makes sure the user profile and group links exist ahead of time. Admins map directory groups to local permissions inside each downstream tool or database.
For example, a backend group in the directory maps to a read and write role. Anyone added to that group gets those exact database rights right away. Teams build a few broad groups so they do not have to manage hundreds of roles. As a result, most engineers end up in groups with more power than they need daily. This makes setup fast for admins, but it creates a wide blast radius inside production systems.
Model Context Protocol (MCP) Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What directory sync solves and what it misses
Directory sync solves account sprawl across your cloud tools and internal systems. Admins do not have to log in to ten dashboards when someone quits. Turning off one central profile cuts off login rights across every linked app in minutes. It also gives security teams a single place to check who belongs to which group.
Still, user sync only manages the account lifecycle and static group membership. It decides who gets an account, not what that user does after they log in. Once a session starts, the sync protocol has no view into live queries or commands. An engineer in a broad group can run a delete query on a live table. A synced user can also run a query that returns raw emails, phone numbers, or card numbers. Static group roles cannot approve single commands or rewrite sensitive fields in query results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does the scim protocol handle user logins?
No, it only creates, updates, and turns off user accounts and group lists. You must pair it with a login standard like SAML or OIDC to check passwords.
What happens when you remove a user from a synced group?
The directory sends an update request to the target app right away. The app then removes the user from the mapped role and drops those permissions.
Can directory sync restrict which database queries a user runs?
No, directory sync only assigns coarse roles at the account level. It cannot inspect live SQL statements, block risky commands, or mask fields like national IDs.