Subjects and lessons to explore.

Law

Cybersecurity · Foundations

Authorization

9 min read 5 practice questions
8 key termsSourcesReport an error
Want it in plain words first? Jump to Eli explains — the same idea, no jargon.
On this page 9 sections
  1. In 30 seconds
  2. Why this matters
  3. The college version
  4. Eli explains
  5. Worked example
  6. Key takeaway
  7. Quick check
  8. Study tools
  9. Sources & references

In 30 seconds

is the decision about what an authenticated person is allowed to do. After a system verifies who you are, it separately decides whether your account may open a file, run a feature, or call an API. That second decision is authorization. Permissions can hang off roles or off attributes, and they apply within a . The guiding rule is to grant the minimum access needed, a principle explored fully in its own lesson.

Why this matters

opens the door; authorization decides which rooms you may enter. Most people have signed in successfully and still been denied, a folder they cannot open, a report they cannot see. That is the system working as designed. When authorization is missing or too generous, anyone whose identity is accepted, including an attacker holding stolen credentials, can reach far more than they should. Understanding who decides, and on what basis, turns a denial from a mystery into a check you can reason about, and it explains why organizations watch permissions as carefully as passwords.

The college version

What authorization is

Authorization is the process of deciding whether a requested action is approved for a specific person. OWASP's developer guidance, quoting NIST, defines authorization as the process of verifying that a requested action or service is approved for a specific entity. The word approved carries the weight. When you click a link or open a file, the system checks not just who you are but whether your account has been granted that specific action. That check is separate from proving identity. OWASP makes the point explicitly: a user who has been authenticated is often not authorized to access every resource and perform every action the system can perform. Authorization is the layer that turns identity into controlled access, the difference between knowing you are you and letting you do things under your own name.

Authentication versus authorization

The two concepts blur because a single login performs both. Authentication answers who are you: it verifies that the person presenting credentials is the account's owner, using something you know, something you have, or something you are. The details belong to the authentication lesson; here the distinction is the point. Authorization answers what may you do: it decides whether that verified identity is allowed to perform a specific action. Consider logging in to an employee portal. The password check is authentication: the system accepts that you are you. The same session then asks whether your account may open the payroll module. That is authorization, and it can deny you even after a perfect login. OWASP's cheat sheet stresses the distinction: authorization verifies that a requested action is approved, and it is distinct from authentication, which verifies identity. The two decisions fail independently, and both must pass before anything sensitive happens.

Permissions and scopes

Permissions describe the actions an account may take: read a document, edit a spreadsheet, delete a record, call an application programming interface. In practice a attaches to a resource and an operation on that resource, which is why you meet them on files, folders, application features, and APIs. A permission is usually paired with a scope, the set of resources it applies to. Microsoft's role-based access control documentation is explicit: a role definition is a collection of permissions, typically actions such as read, write, and delete, and the scope is the set of resources the access applies to. The same read permission can be granted narrowly, for one document, or broadly, for every document in the company. Getting the pairing right, the right action on the right resource for the right person, is the whole craft of access control.

Access control models: RBAC and ABAC

Organizations rarely write a permission for every person on every file; they use models that scale. assigns permissions to roles and people to roles. NIST describes RBAC as employing predefined roles that carry a specific set of privileges, with subjects assigned to those roles: a role like Manager carries different access than a role like Analyst. When someone changes jobs, the role changes and access follows. decides each request by evaluating attributes, characteristics of the person, the resource, the requested operation, and the environment, against policies. NIST's ABAC standard defines the method exactly that way: authorization determined by evaluating attributes of the subject, object, requested operations, and in some cases environment conditions against policy. A hospital might admit a nurse to a patient record only when the patient is on the nurse's ward and the request arrives during a shift. RBAC is common because roles mirror how organizations are structured; ABAC is more flexible and more complex. Both serve the same end: granting exactly the access that is justified.

When authorization fails, and why it matters

Authorization failures are common and costly. OWASP ranked broken access control as the most concerning web security vulnerability in its 2021 Top 10. One frequent shape of failure is the over-permissioned account: a person holding far more access than the job requires, often because permissions accumulated over years or were copied from a colleague's profile. OWASP warns that failing to enforce — granting users only the minimum privileges their job requires — can jeopardize the confidentiality of sensitive resources. Least privilege has its own lesson; here the point is that generous permissions are never harmless. Every extra permission is a door an attacker can use if the account is compromised. That is why identity alone is not enough: proving you are you should never, by itself, grant access to anything. The permission check is the guard between a verified identity and the damage it could do, it must , and it must run on every request.

Eli, the EliExplains learning guide

Eli explains

The same idea, in plain words

Explain it like I’m 10

Logging in proves who you are. Authorization decides what you may do next. After the computer checks your password, it checks a separate list: can this account open this file, press this button, call this service? Two common systems build that list differently. Role-based access control gives everyone with the same job the same list: all designers get designer access. Attribute-based access control checks facts about you and the request, your team, your location, the time of day, against rules before saying yes. And a safe system says no unless a rule says yes: deny by default.

Picture it like this

Think of a hotel. The front desk checks your ID and confirms your reservation: that is authentication. The keycard they hand you is authorization. Your card opens your room and the gym but not the manager's office or the supply closet, because the hotel decided which doors your card may open, not which doors exist. A staff card that opens every room is the over-permissioned account: convenient to carry, dangerous if lost.

Where the picture stops working

A hotel keycard is issued once and its doors stay fixed until checkout, while computer permissions can change with every request, every role change, and every policy update. And a lost card is a physical object someone must find and use, while a compromised account can be used remotely, in seconds, from anywhere, so the limits on digital access matter more than the limits on a card.

Worked example

Marisol joins a shipping company as a billing clerk. Her manager sets up her account with the role Billing Clerk, which carries read and edit permissions on invoices but nothing on employee salaries. When Marisol opens the invoices folder, the system finds the read permission and lets her in. When she clicks the salary report, the same system checks again, finds no matching permission, and shows a denial. She also receives a link to a customer API; the permission on that API covers only her region, so calls for other regions are refused. Every request is checked, and the default answer is no.

Key takeaway

Authorization is the decision of what an authenticated person may do. Identity alone is never enough: every action needs a permission check, permissions should be scoped and minimal, and the safe default is to deny.

Quick check

3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.

Question 1 of 3foundational

What does authorization decide?

Choose an answer, then check it.
Question 2 of 3intermediate

Which statement best captures the relationship between authentication and authorization?

Choose an answer, then check it.
Question 3 of 3intermediate

A design studio gives every account a role: Designer or Project Manager. A designer account tries to delete a shared client folder and is refused. Under role-based access control, what most directly explains the refusal?

Choose an answer, then check it.
Practice all 5

Keep learning

Ready to build on this? Continue to the next lesson.

Practice this lesson
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related

You’ll learn to

  • Define authorization as the decision of what an authenticated person is allowed to do.
  • Distinguish authentication from authorization, using an example in which identity is proven but an action is still denied.
  • Name two access control models, role-based (RBAC) and attribute-based (ABAC), and state the basic idea of each.
  • Explain what permissions attach to, files, folders, features, and APIs, within a scope.
  • Explain why over-permissioned accounts are dangerous and why identity alone is not enough to grant access.

Common mistakes

  • Thinking authentication and authorization are the same check.

    A login performs both, but they are separate decisions made at different moments. You can be verified and still denied.

  • Assuming a successful login means you should be able to do everything.

    An authenticated account is authorized only for what its permissions allow; OWASP stresses that authenticated users are often not authorized for every action.

  • Treating an over-permissioned account as harmless just in case.

    Every extra permission enlarges what an attacker can reach if the account is compromised; OWASP ranked broken access control as the most concerning web vulnerability in its 2021 Top 10.

  • Confusing the two access control models.

    RBAC grants access through roles people join; ABAC evaluates attributes against policies on each request. Both exist to grant justified access.

Easily confused

Authentication vs. Authorization

Authentication verifies who you are; authorization decides what you may do. You can pass the first and fail the second.

RBAC vs. ABAC

Roles carry permissions and people join roles; ABAC evaluates attributes of the person, resource, operation, and environment against policies on each request. Roles are simpler; attributes are more flexible.

Permission vs. Scope

A permission names an action; the scope names the resources that action applies to. Read access means different things at different scopes.

Key vocabulary

authorization
The process of deciding whether a requested action is approved for a specific person or account.
authentication
The process of verifying that someone is who they claim to be; the identity check that runs before permission checks.
permission
An approved action an account may take, such as reading a file or calling an API.
scope
The set of resources that a permission applies to.
role-based access control (RBAC)
An access control model that assigns permissions to job roles and assigns people to those roles.
attribute-based access control (ABAC)
An access control model that grants or denies each request by evaluating attributes of the person, resource, operation, and environment against policies.
least privilege
The principle of giving an account only the minimum access needed to do its job.
deny by default
The rule that a request is denied unless a permission explicitly allows it.

Sources & references

  1. Authorization Cheat Sheet — OWASP Cheat Sheet Series
  2. NIST Special Publication 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations — National Institute of Standards and Technology
  3. What is Azure role-based access control (Azure RBAC)? — Microsoft Learn
  4. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations — National Institute of Standards and Technology

EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.

Researched 2026-08-21

Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.