Scim Payload
A scim payload is a JSON message that creates, updates, or deletes user accounts. Your identity tool sends this message to sync roles across your apps. Most teams set up this sync to avoid manual user creation. They map broad directory groups to app roles so people can log in. When those mapped roles are too broad, users gain excess permissions right away. A single group sync can grant wide database or server permissions to everyone. How a scim payload syncs user accounts The System for Cross
Payload: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A scim payload is a JSON message that creates, updates, or deletes user accounts. Your identity tool sends this message to sync roles across your apps. Most teams set up this sync to avoid manual user creation. They map broad directory groups to app roles so people can log in. When those mapped roles are too broad, users gain excess permissions right away. A single group sync can grant wide database or server permissions to everyone.
How a scim payload syncs user accounts
The System for Cross-domain Identity Management protocol uses standard web requests to manage users. When a new person joins your team, you add them to your directory. Your identity tool then builds a scim payload with their basic user details. This message includes their work email, display name, active status, and group memberships.
The identity tool sends this message to the target app over HTTPS. The target app reads the message and creates a matching local account. It also reads the group list inside the message to assign local roles. If someone leaves the company, the identity tool sends a new update message. That message flips the active status to false and cuts off their login.
Teams also use these messages to update user roles when people change jobs. When an engineer moves to a new team, you update their directory group. The identity tool sends a patch message to update their group membership. The target app sees the new group and grants the matching local role. This setup keeps account lists clean without manual work in ten different tools.
What directory sync solves and what it misses
Directory sync solves the problem of stale accounts and slow onboarding for teams. You do not have to create logins by hand in every single app. When you turn off a user in your main directory, their logins stop. This keeps former staff from logging into company apps after they leave.
Still, directory sync only controls who has an account and a static role. A scim payload finishes its job before a user ever runs a command. It decides who can log in, not what their queries do in flight. Once an engineer logs in with a synced role, those permissions stay wide open. If the synced role allows table drops, the user can drop tables anytime.
Directory groups are also coarse, so teams often map them to powerful roles. Nobody wants to build hundreds of tiny groups for every single database table. Instead, teams create one broad engineering group and give it full write permissions. Every person in that group can then read raw emails or card numbers. The sync tool has no way to inspect live queries or mask fields.
Payload: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Mapping roles for safer account sync
You can reduce risk by keeping your synced directory groups small and focused. Start by auditing the fields and groups your identity tool sends out today. Remove broad catch-all groups from your app sync rules right away. Create separate groups for read-only work and for admin tasks.
Next, check how the receiving app maps those incoming group names to roles. Make sure the default role for new synced users has zero write permissions. Only map specific sub-groups to roles that can change data or settings. Test your sync setup with a dummy account before you roll it out. Check that turning off the dummy user in your directory blocks active sessions.
Even with clean groups, static roles still leave live sessions unchecked. You still need a way to inspect individual commands and protect sensitive fields. Combining clean user sync with live session controls gives your team full coverage.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What data goes inside a standard user sync message?
The message carries a schema declaration, a unique user ID, and basic profile fields. Common fields include the work email, given name, family name, and active state. It can also carry a list of group names for role mapping.
How does a patch request differ from a put request in user sync?
A put request replaces the entire user record in the target app. A patch request only changes specific fields, like setting the active flag to false. Most tools use patch requests to add or remove one group membership.
Does user sync control what queries an engineer can run?
No, user sync only creates the account and assigns a static role. It does not watch or filter live database queries or terminal commands. You need runtime controls to check statements or rewrite emails and phone numbers.