Authorization & Scoped Permissions

Every secure system must answer two different questions. First: who or what is making this request? Second: what is that identity allowed to do right now? Authentication answers the first question. Authorization answers the second. Scoped permissions make authorization practical by replacing broad trust with precise limits: this user may read these records, this service may write to that queue, this agent may call this tool only for this task.

Authorization starts after identity

Authentication is the act of proving identity. A password, passkey, certificate, security key, or signed token can help a system decide that a person, workload, or device is who it claims to be. Authorization is the separate act of deciding what that authenticated identity may do.

This distinction matters because a correct identity is not the same as unlimited access. A finance analyst may be a valid employee, but that does not mean they can approve their own expenses. A background service may be a valid application, but that does not mean it can delete production data.

A typical request passes through a chain. The caller proves identity, receives or presents a token, asks for an action, and the receiving system checks policy before allowing or denying the action. The final decision should be made close to the resource, because only the resource usually knows the full context of the request.

📌

Identity is not permission. A user can be fully authenticated and still be correctly denied access.

Authorization runs after identity: a request is checked against policy before it acts.

What a permission really means

A permission is a statement of allowed behavior. It usually combines an actor, an action, and a target. For example: this application can read customer profiles, or this user can approve invoices under a certain amount.

The action should be expressed as a verb, such as read, create, update, delete, approve, export, or execute. The target should be a real boundary in the system, such as a database table, storage container, application programming interface (API), tenant, project, model, workspace, or business process.

Good permissions are not vague. A permission called admin is often a bundle of many powers, some harmless and some dangerous. A permission called read invoices is easier to review, test, explain, and remove.

Actor: the user, service, device, or workload asking to do something.
Action: the operation being requested, such as read, write, approve, or delete.
Target: the resource or business object the action applies to.
Condition: optional context, such as time, network, device health, data label, or transaction value.

Scopes shrink power to fit the job

A scope is a boundary around a permission. It answers the question: where and for what purpose does this permission apply? Without scopes, permissions tend to spread until a small mistake becomes a large incident.

Scoped permissions follow the principle of least privilege: grant only the access needed, for only the resources needed, for only as long as needed. The aim is not to make work difficult. The aim is to make the safe path the normal path.

Scopes can be based on resources, actions, data sensitivity, geography, environment, time, or task. A developer might have read access to production logs but write access only in a test environment. An automation account might rotate secrets in one application but not across the whole organization.

✅

Small grants age better. The narrower a permission is, the easier it is to approve, monitor, revoke, and explain later.

Common authorization models

Role-based access control (RBAC) assigns permissions to roles, then assigns identities to those roles. For example, a Help Desk Reader role might include permission to view support tickets but not close them. RBAC is popular because it maps well to job duties and is easy to explain.

Attribute-based access control (ABAC) uses attributes about the caller, resource, action, and environment. A policy might allow access only when the user is in the same region as the record, the device is compliant, and the data is not labeled confidential. ABAC is powerful, but policy design and testing must be disciplined.

Access control lists (ACLs) attach allowed identities or groups directly to a resource. ACLs are simple for a small number of resources, but they can become hard to audit at scale. Many real systems combine RBAC, ABAC, and ACLs, using each where it is strongest.

Tokens carry claims, not final truth

Modern applications often use tokens to carry identity and permission information between systems. An identity provider such as Microsoft Entra ID can issue a token after authentication and consent checks. The receiving API reads claims in the token, such as the subject, tenant, audience, roles, or scopes.

A claim is a statement inside a token. A scope claim might say that an application is allowed to call an API for a named purpose, such as read messages. A role claim might say that a user belongs to a particular application role. These claims help the API make a decision, but they should not replace local authorization logic.

The API must still check that the token was issued by a trusted authority, was meant for this API, has not expired, and contains the required permission for the requested operation. If the API also has resource-specific rules, such as project membership or data classification, it must check those too.

⚠️

Do not trust shape alone. A token that looks valid is not enough; the API must validate issuer, audience, expiry, signature, and required permission.

Token claims inform a decision, but the resource still validates every check locally.

Design choices leaders and practitioners must make

Authorization is not only an engineering detail. It expresses business risk. Leaders decide which actions are sensitive, which duties must be separated, which approvals are required, and how much friction is acceptable for high-risk operations. Practitioners translate those decisions into roles, scopes, policies, tests, and logs.

One important choice is where to use coarse-grained roles and where to use fine-grained scopes. Coarse roles are easier to manage but can grant too much. Fine-grained scopes reduce blast radius but can become complex if every exception becomes a new permission.

Another choice is how authorization works for automation and artificial intelligence agents. In Microsoft Foundry, an agent or application may need to call models, retrieve data, or use Foundry Tools. Each capability should be authorized as a separate, reviewable grant rather than hidden inside one broad application permission.

Which actions could cause financial, legal, safety, privacy, or operational harm?
Which permissions should require approval, expiry, or stronger authentication?
Which grants belong to a person, and which belong to a workload identity?
Which resources need fine-grained checks beyond a general role?
Which logs prove who requested access, who approved it, and how it was used?

Coarse roles are easy to manage; fine scopes shrink the blast radius.

Govern permissions across their life

Permissions are not finished when they are granted. People change jobs, applications change owners, data changes sensitivity, and emergency access is forgotten. Authorization needs a life cycle: request, approve, grant, use, monitor, review, and revoke.

Good systems make temporary access normal. Just-in-time access grants a permission for a limited period, often after approval or additional verification. Periodic access reviews ask resource owners to confirm that existing grants are still needed.

Logging closes the loop. Authorization logs should capture who or what requested access, what resource was targeted, which policy was evaluated, whether the decision was allow or deny, and enough context to investigate unusual behavior. Logs are most useful when they are designed before an incident, not after one.

⚠️

Stale access is active risk. A permission that is no longer needed can still be used by an attacker, a mistaken user, or a forgotten integration.

Key takeaways

Authentication proves identity; authorization decides what that identity may do.
A useful permission names an actor, an action, a target, and often a condition.
Scoped permissions reduce blast radius by limiting where, how, and how long access applies.
Roles, attributes, and access control lists solve different parts of the authorization problem.
Tokens carry claims that help decisions, but APIs must still validate tokens and enforce local policy.
Permission governance must include approval, monitoring, review, and revocation.

Grants are never finished: they are requested, used, reviewed, and revoked.

Glossary

Authentication: The process of proving that a person, workload, device, or service is who or what it claims to be.
Authorization: The process of deciding whether an authenticated identity is allowed to perform a requested action on a resource.
Scope: A boundary that limits a permission to a particular purpose, resource, action, time, or context.
Principle of least privilege: The practice of granting only the access needed to perform a task and no more.
Role-based access control (RBAC): An authorization model that assigns permissions to roles and then assigns identities to those roles.
Attribute-based access control (ABAC): An authorization model that uses attributes of the caller, resource, action, and environment to make access decisions.
Access control list (ACL): A list attached to a resource that names which identities or groups have specific permissions on that resource.
Claim: A statement inside a token about an identity, permission, tenant, role, scope, or other fact used during authorization.
Token: A signed data package presented by a caller to prove identity information or permission claims to a receiving system.