Coarse Grained Authorization
Coarse grained authorization grants or denies entry to whole apps or databases using broad roles. Teams set it up by mapping identity groups to high-level system roles. Most engineering teams start with this model because it is fast to build. Admins create a few broad roles like reader, writer, or admin. Then they assign users to those groups inside their identity provider. When permissions are too broad, any user in a role can touch everything inside. A single mistake or bad query can affect al
Coarse-Grained Authorization: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Coarse grained authorization grants or denies entry to whole apps or databases using broad roles. Teams set it up by mapping identity groups to high-level system roles. Most engineering teams start with this model because it is fast to build. Admins create a few broad roles like reader, writer, or admin. Then they assign users to those groups inside their identity provider. When permissions are too broad, any user in a role can touch everything inside. A single mistake or bad query can affect all tables at once.
How coarse grained authorization works in practice
In a standard setup, the system checks user roles at the front door. A user logs in through an identity provider and gets a group tag. The database or server reads that tag and assigns a broad role. This role gives permission to read or write across an entire resource. It does not check which specific rows or fields the user needs.
For example, an engineer joins the support group to fix a bug. The system maps the support group to a database writer role. That engineer can now update any table in that database schema. The permission model treats every table and row as one big bucket. Admins do not have to write rules for each table or column. They manage a short list of roles across the whole team.
What coarse roles solve and where they fall short
Broad roles make onboarding fast and keep role lists small for admins. New hires get the right group tag on day one and start work. Security teams can see which groups can log in to which servers. For small apps with no private data, this simple setup works well.
Still, this model leaves a major gap during daily work. It only decides who can log in to the system at the start. It cannot check what individual queries, commands, or requests do in flight. Once a user logs in, every command they run has full role power. A user with read rights can pull emails, phone numbers, or card numbers. A user with write rights can drop a table or change prod rows. The native role check is already over before the first command runs.
Coarse-Grained Authorization: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Moving from broad roles to command-level checks
Teams often try to fix this gap by creating dozens of tiny roles. Soon, admins have hundreds of database roles and group rules to maintain. Every schema change breaks old roles and slows down the whole team. A better way is to keep role assignments simple at the identity level. Then, teams add checks and controls on the actual commands and results. Masking rules can rewrite emails, phone numbers, and national IDs in query results. Approval workflows can pause risky commands before they run against a live system.
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 is the main difference between coarse and fine-grained rules?
Coarse rules control entry to whole systems or databases using broad group roles. Fine-grained rules check specific actions, rows, fields, or context for each request.
When is a broad role model enough for a team?
It works well for test servers or tools that hold no private data. Once databases store customer records or card numbers, broad roles create high risk.
Why do broad database roles create audit headaches?
Many users share the same high-level role and run queries with full rights. Role maps alone cannot show which specific commands or data rows were touched.