Database security relies on two related but genuinely distinct concepts that are easy to conflate: authentication, the process of verifying that a user actually is who they claim to be, typically through a password or another credential; and authorization, a separate, subsequent question asking exactly which specific data and actions that now-verified user is actually permitted to access. Successfully authenticating simply confirms someone's identity — it doesn't by itself say anything about what that identified person should actually be allowed to see or do once they're in, which is precisely what authorization exists to control separately.
Two separate checks, not one combined gate
A well-designed database security system treats authentication and authorization as genuinely separate checks happening at different points, rather than folding them together into a single combined gate: a user first proves who they are through authentication, and only afterward does the system separately check, through authorization, exactly what that specific verified identity is actually permitted to do — read certain records but not others, modify some data but only view the rest, or nothing at all beyond what their specific access level explicitly allows. This separation matters because a system's overall security genuinely depends on getting both checks right independently — even a perfectly secure authentication system, one that reliably confirms a user's true identity every time, still leaves the database dangerously exposed if authorization is poorly defined and grants that correctly identified user access to far more data or capability than their actual role should ever require.
Overly broad authorization is a common, real source of breaches
A significant share of real-world data breaches don't actually stem from attackers successfully defeating authentication and impersonating someone else's identity; they instead stem from authorization being defined too broadly for a legitimately authenticated user — a genuine, correctly identified employee or account being granted access to considerably more data than their actual job or role genuinely requires, so that a compromised account, or simple human error or misconduct by that legitimately authenticated user, ends up exposing or misusing data well beyond what proper access controls should ever have permitted in the first place. This is a large part of why database security best practice generally emphasises the principle of least privilege — deliberately granting each user only the minimum specific access their actual role genuinely requires, rather than broad, convenient access that happens to cover far more than any given user actually needs.
What we're still unsure about
The basic conceptual distinction between authentication and authorization, and the principle of least privilege as a security best practice, are well-established, widely documented database security fundamentals. What's more genuinely an ongoing practical challenge, rather than a settled matter, is actually implementing and maintaining fine-grained, least-privilege authorization correctly at scale in a real, evolving organisation — as an organisation's roles, teams and data change over time, access permissions defined and granted at one point can easily drift out of alignment with what's actually appropriate later, and correctly auditing and periodically re-tightening authorization as an organisation evolves remains a genuine, ongoing operational challenge that security teams continue actively working to manage, not a problem solved once and then permanently finished.
This sits inside Database Security & Access Control, one of seven topics in Databases, one of seven domains in Computer Science, one of seventeen subjects the app can quiz you on.