An Introduction to Authorization

Authorization is the process of granting access to resources. It is tightly coupled to authentication that verifies the subjects that are requesting access. While the focus for authentication and authorization often lies on human users, they are becoming equally important for machines, that is for applications, workloads, AI agents and devices.

This article describes concepts, related terms and patterns used in the context of authorization regardless of whether it targets users or machines. It serves as a universal introduction to the domain. Its content provides a basis for implementing authorization for all cases.

Before designing any authorization rules and applying related patterns, it is beneficial to get familiar with the common actors in authorization.

Actors of an Authorization Flow

Actors are anyone or anything that impacts a workflow such as an authorization flow. The following list of common authorization actors is partly inspired by the OAuth terminology.

• Resource Server
• Protected Resource
• Authority (Resource Owner)
• Subject

Resource Server

The resource server is the technical component like an API that makes resources available to applications and users. Consequently, the resource server is responsible for protecting access to resources.

Protected Resource

The protected resource is the data to which access is restricted. A protected resource can be anything such as documents behind paywalls, an organization's internal documents, sensitive data like intellectual property, or personal identifiable information (PII) from customers, partners, or employees. Access control rules differ depending on the information the protected resource contains.

Some type of information and data like personal information is highly regulated. Regulations impact how to implement and enforce authorization for affected resources. For example, they define the authority that needs to grant access.

Authority (Resource Owner)

The authority is the entity that controls the protected resource and that needs to grant access to it. The authority can be an organization or an individual depending on the nature of the data and the user case. Organizations may delegate authority to individuals, teams or partners.

In OAuth the authority is called the resource owner. It is also the subject on behalf of which an application accesses the protected resource. In modern OAuth use cases, however, the one granting access is not the same as the one requesting access. It means that the resource owner and subject are not always the same. Technically, there are often multiple subjects involved in an access request.

Subject

The subject is the entity whom the authority grants access to the protected resource. From an authorization viewpoint, use cases often include multiple subjects such as the following:

• Human Identity: A person, the end-user. Delegation use cases involve even multiple human identities.
• Machine Identity: An application such as a client application that the end-user operates, an intermediate, a backend service or an AI agent.

The subject or subjects and their relevance is defined by the use case, for example, whether you have to deal with delegation, partner access or applications acting on behalf of users. The use cases are then what defines your policies.

Policies

Authorization policies encompass the rules, requirements and prerequisites of when to grant subjects access to the protected resource. Policy authors can draw on access control models such as Role-based Access Control (RBAC) or Attribute-based Access Control (ABAC) for evaluating the permissions of a subject, human and machine alike.

For the policy to gain effect, you need patterns for how to evaluate the permissions of subjects to be able to grant them access.

Authorization Patterns

There are basically two approaches for how to grant access:

• Admin-time Authorization
• Runtime Authorization

Admin-time Authorization

Admin-time authorization grants access through configuration. Granting access through configuration means that the authority grants subjects access to protected resources upfront as part of a configuration task or phase. Examples for admin-time authorization are when administrators can grant access by registering trusted client applications or by assigning roles to users.

Using admin-time authorization, the policy gets enforced as part of authentication or right after it. For example, if a user attempts to login at an application and they lack the necessary roles, admin-time authorization can prevent the user from logging in and thus from accessing the application. As a consequence, the authority needs to assign a subject the appropriate permissions before the subject authenticates.

Admin-time authorization is static and tends to be long-lived. Therefore, it becomes important to keep data up-to-date and accurate. This is typically where in enterprise setups identity governance and administration (IGA) becomes essential.

Admin-time authorization is suitable for configuring trust relationships because trust is explicit and long-lived. It is not suitable for dynamic and continuous access control because it implies a coarse-grained, single point of control that cannot adapt decisions after authentication. Runtime authorization, on the other hand, provides fine-grained and continuous access control.

Runtime Authorization

Runtime authorization means that the policy evaluates the permissions of a subject and grants access at runtime. It takes effect after the subject has been authenticated and when they aim to access a protected resource. For example, if a user is logged in and clicks on a button in an application that eventually triggers an API request, runtime authorization ensures that the request is allowed in the given context.

When authorizing requests after authentication, the policy has access to an increased amount of information about the context of a request. Examples of information that the policy may have at that point include the user identity, requested action, date and time or even some history. Consequently, runtime authorization enables fine-grained, dynamic access control in realtime.

The decision of an access control policy represents the grant an authority gives the subject in question to access the protected resource in question. Runtime authorization differs from admin-time authorization because the grant is evaluated in realtime after the subject or subjects has authenticated and when the actual request happens, compared to it being set up and evaluated during authentication.

Runtime and admin-time authorization are not mutually exclusive but complement each other. In both cases, depending on the workflow, the authority can choose to allow, deny, or constrain permissions as part of an approval task before granting access.

Approvals

Approvals are part of both admin-time and runtime authorization. For example, when users request access to an application through a self-service portal (admin-time authorization), an authority such as an administrator typically needs to approve such requests. User consent screens, where users need to confirm a request attempt before an application gains access, are an example of approvals as part of runtime authorization.

Depending on who approves a request and in which form, you can distinguish between the following types of approvals:

• Admin Approval
• User Consent
• Out-of-band Approval

Admin Approval

Admin approval occurs when the authority that is not a subject needs to approve the permissions of subjects before access is granted. An example for admin approval, as mentioned above, is when an administrator needs to approve access requests from a self-service portal for a user to be granted access to an application.

Admin approval is a common requirement in admin-time authorization. You can also trigger admin approvals during runtime authorization, for example, when an autonomous application like an AI-driven program attempts to perform a sensitive action and you want to an administrator to explicitly grant (temporary) access.

Admin approvals always happen out of band because the authority is not the subject, and is not present when the approval gets triggered. In cases where the subject can approve and influence a grant, you can use user consent.

User Consent

User consent occurs when the list of subjects include a person, the user, and that user needs to approve a request before an application may continue with its attempt to access protected resource. It is a tool for giving users control over which application or machine may access what protected resources on their behalf.

Depending on the implementation, the user may be able to give consent for individual pieces of a request. For example, it may allow users to select a subset of scopes to approve, which provides fine-grained control. When a user consent flow is part of runtime authorization, an attempt to access protected resources triggers a user screen for the user to provide their consent.

In cases where it is not possible to collect user consent during runtime, out-of-band approvals provide an alternative.

Out-of-Band Approval

Instead of prompting users with a screen, users can give their consent out of band as well. For example, with the rise of autonomous applications, namely AI agents, the user may not be present when their AI agent triggers a request. There is no active channel nor user interface for the user to interact with. Instead, if approval is required, the flow must trigger a user interface, like a dedicated application, for the user to approve a request out of band.

Having to constantly approve requests as part of runtime authorization can be daunting for users. Therefore, put some planning in how to manage grants.

Managing Grants

Grants can be temporary. Temporary grants in runtime authorization effectively result in just-in-time access without standing privileges. While good from a security point of view, if just-in-time access requires constant user interaction, it leads to "cognitive fatigue" resulting in users not paying attention to the screens anymore. As a consequence, users consent to anything which undermines the purpose.

End-user experience becomes very important in runtime authorization for mitigating human mistakes and social engineering attacks. A strategy to improve user experience is to keep the number of user consents to a bare minimum. For example, instead of prompting every time, allow users to store their grant and then only prompt when stepping up authorization. You can then offer tools to manage grants. For example, the Curity Identity Server has a GraphQL API for that purpose.

Step-up authorization is required if the current grant is not sufficient for an action. Step-up authorization triggers a new flow in which you can prompt for consent. This grant can be temporary because the default grant should be good enough most of the time. Finding the balance between security, usability and manageability is one of the challenges of authorization.

Challenges

Authorization is complex because it needs to combine requirements from multiple stakeholders, like business, legal, security and engineering. There are often gaps between stakeholders and teams. As a consequence, it can be particularly hard to translate what the business owners knows about who should have access to what and when to an enforceable set of rules. This can lead to insufficient or inappropriate access control policies. Requirements can be conflicting as well making it even more difficult to write adequate policies and to balance security with other requirements like user experience.

These challenges can manifest itself in the following symptoms:

• Over-privileged accounts because of confusing requirements or lack of governance.
• Role explosion because of how permissions were designed to meet complex rules.
• Disparate access control because of the lack of a standardized framework for authorization.
• Incomplete auditing and accountability because of disparate access controls, as well as inconsistency in or lack of identity data management.

Authorization is not a one-time check but basically happens in all places where decisions are made. It means there are multiple points in an architecture, API, system or application that need to enforce access control policies, so-called policy enforcement points. Each component may come with their own limitations or requirements when implementing policies resulting in discrepancies and inconsistent rules as mentioned above. On top of this, organizations may struggle with:

• Integrating IAM into existing and legacy systems
• Enforcing dynamic authorization
• Scaling authorization

Best practices help overcome common challenges.

Best Practices

Authorization requires team effort. Therefore, include all relevant stakeholders when designing access control policies. This helps you to correctly identify the subjects, authorities, resources, available actions and related permissions.

The following are our recommendation with regard to policies and implementing authorization:

• Use attribute-based access control (ABAC).
• Externalize the authorization logic.
• Follow the principle of least privilege.

Use attribute-based access control (ABAC) to model the rules. Combine attributes from admin-time authorization with dynamic attributes that you evaluate during runtime authorization. In this way you can implement dynamic authorization where policy decisions change and can adapt to a context.

Attribute-based access control means you need to convey identity data for distributed policies to be able to retrieve the attributes for the correct subjects. Since attributes control permissions, attribute governance becomes important for attribute-based access control.

Externalize the authorization logic. This approach is also known as policy-based access control and closely related to policy-as-code. Externalizing authorization logic means writing and deploying policies next to applications instead of with them. It introduces a dedicated component that can evaluate policies and return decisions in a consistent manner to the distributed policy enforcement points.

In the long run external authorization management provides the following benefits which help overcome some of the challenges mentioned above:

• Standardized authorization framework — a standardized way to retrieve policy decision.
• Consistency by reusing policies.
• Quality assurance for policies through dedicated testing.
• Comprehensive audits via consistent logs.

Follow the principle of least privilege. Be restrictive in which permissions you assign to humans and machines both at admin time and runtime. Use step-up authorization and approvals to elevate privileges when needed and only for as long as needed (just-in-time access).

Curity provides a set of resources about best practices related to authorization. Check out the following links for additional guidance:

• Identity and Access Management Primer
• Privacy and GDPR Using OAuth
• API Security Best Practices

Last updated: 2025-12-02

Judith Kahrer

Product Marketing Engineer at Curity

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Email

Subscribe

I agree to Curity's Privacy Policy

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial