Modern Authorization Trends: What’s Changing and Why It Matters

In July 2024, a NSW Police Force civilian employee was arrested for unauthorized access to and attempted alteration of restricted data. This incident highlights a growing issue: authorization.

While organizations often prioritize authentication, authorization tends to be overlooked. Just because you can access certain systems at work doesn’t mean you’re authorized to view sensitive data or perform critical actions. For example, you might manage infrastructure without having access to its data. How are modern authorization techniques addressing these challenges?

To clarify, authentication verifies your identity, while authorization defines what you can do within an app. For more on authentication, check out my blog, “A Guide to Picking the Best Authentication Method in 2024.”

When discussing authorization, we must also consider access control — the process of managing and enforcing who can access what. Authorization defines what you’re allowed to do, while access control enforces it.

In this blog, we’ll explore how authorization decisions are made, dynamically influenced, and enforced, along with recommendations for strengthening your strategy.

Authorization Decisions

The Policy Decision Point (PDP) is the entity responsible for making authorization decisions by evaluating a combination of predefined policies and dynamic, contextual attributes. Beyond static permissions, the PDP considers the context of the user’s login and other conditions, adjusting authorizations in real-time. These dynamic authorization influencers determine when and how access is granted or restricted, enabling more adaptive and situational control. Let’s look at some of them.

Attribute-based

Once you join a company, you may be automatically allocated certain authorizations across the corporate apps, which we call “birthright” access. This is based on the attributes registered on your HR database such as job title, location, department, org, etc. These attributes translate into certain authorizations given to you. For example:

• Based on your “officeAddress” attribute you may be authorized to use the printer on your office floor.
• Based on your employment “status: Active” you may be authorized to access internal company portals, corporate email, and so on.

These policies are often written in XACML (eXtensible Access Control Markup Language). XACML enables detailed Attribute-Based Access Control (ABAC) to allow/deny decisions.

<Sample employee entry in HR system>

EmployeeID: S123123
Suffix: Mr
FirstName: Ade
LastName: Azibo
JobTitle: Accountant
Org: Finance
CostCenter: 10001
City: Sydney
Status: Active
OfficeAddress: Level1, 10 Market St, Sydney 2000

<Sample XACML rule allowing access to a Printer>

<Rule RuleId="GrantAccessToPrinterFloor1" Effect="Permit">
    <Condition>
        <Apply FunctionId="...">
            <!-- User's OfficeAddress must match floor1 -->
            <AttributeValue DataType="...">Level1, 10 Market St, Sydney 2000</AttributeValue>
            <AttributeDesignator AttributeId="user:OfficeAddress" Category="..." MustBePresent="true"/>
        </Apply>
    </Condition>
</Rule>

Role-based 

Certain authorizations are awarded based on your project or work assignment for that duration. If the company has a modern-day Identity and Access Management (IAM) system, you would usually self-service request for these accesses and it would be set to be approved by certain approvers and you would get those authorizations. For example, a request for an IAM role “Universal Cloud Interface” on App1, would add an LDAP group cn=app1-universal-cloud-interface, ou=groups, dc=example, dc=com to your account and further give you access to certain sections in an application.

<Sample employee role membership in LDAP, which translates to
certain authorizations in an app>

dn: uid=S123123,ou=users,dc=example,dc=com
memberOf: cn=app1-universal-cloud-interface,ou=groups,dc=example,dc=com
memberOf: cn=app1-admin,ou=groups,dc=example,dc=com
memberOf: cn=app2-approver,ou=groups,dc=example,dc=com
memberOf: cn=app3-auditor,ou=groups,dc=example,dc=com

Segregation of Duties (SoD)

A Segregation of Duties (SoD) check ensures that no user has a conflicting combination of permissions, which could lead to fraud or abuse. A classic example is a user who can both submit and approve an expense, creating a conflict of interest. While SoD checks are typically performed during the provisioning of roles and permissions to users, it’s a good practice to also validate SoD during login as changes in the user’s login context or business processes may have altered their responsibilities, potentially creating new SoD conflicts or increasing the severity of existing ones.

User’s consent

This authorization is specifically given based on the user’s explicit consent received on the app. In a login scenario based on OAuth standards where there are two parties, the Relying Party (App) and the Identity Provider (like Facebook, Google, Workplace Identity, etc.), the user could then authorize the App’s access to specific user attributes like name, birthdate and so on.

These consents sometimes have an expiry and are generally given for one-time access.

In general, when evaluating authorization decisions, it’s more efficient to centralize all authorization decisions in one place, commonly referred to as a Policy Decision Point (PDP). This approach helps avoid duplication, prevents authorization conflicts, and simplifies policy management. Managing policies in isolated silos only adds complexity and makes them harder to maintain.

Login Context

In modern security systems, login context plays a key role in determining user access. Factors like device trust, location, and time of access are evaluated to adjust a user’s authorization in real time. For example, if a user logs in from a trusted device or a familiar location, they may receive full access. But if the login is from an untrusted network or outside office hours, their access could be restricted — such as being downgraded from read-write to read-only or limiting access to specific data. This context is usually assessed by a PDP, which has insight into the login environment and can influence authorization decisions accordingly. The PDP evaluates the context of the login and applies the relevant policies to determine the user’s access level.

Fine-grained Authorizations

In the OAuth context of login, as the standards have evolved and expanded, they have provided the ability to send “fine-grained authorizations” to an App as a part of the access token. These are referred to as Rich Authorization Requests or RAR. While RAR is request-based, it can also be combined with the login context to provide fine-grained permissions. RAR enables an application to request more specific authorizations for a given action, which can be informed by the PDP’s evaluation of the login context.

For instance, without RAR, an OAuth access token might include a broad scope like scope: "read write", granting general access to the application. However, with RAR, the access token can request more specific permissions, such as initiating a payment with a predefined limit or performing an action based on contextual attributes like device and location. Here’s how RAR can add detail to authorization based on a transaction:

"instructedAmount": { 
    "currency": "USD", 
    "amount": "100.00" 
}

This combination of RAR and login context helps ensure that authorizations are dynamically adapted to both the user’s request and the contextual risk at the time of login. The PDP provides an understanding of the login environment, while RAR allows fine-grained control at the request level.

Risk Engine Scores

A risk engine is a powerful tool for dynamically adjusting authorization by analyzing a range of factors, such as user login anomalies, and assigning a risk score that reflects the likelihood of suspicious activity, from low to high. Based on this score, the system can temporarily enhance or restrict the user’s authorization during the login process. Risk engines often leverage machine learning (ML) to identify patterns from historical data, refining the scoring process over time to improve accuracy and responsiveness to potential threats.

Ongoing Authorization Evaluation

When a user’s authorization changes during an active session, the typical approach is to wait until the session ends and recheck authorizations during re-authentication. However, a more effective method is to perform token introspection during the session itself. By using introspection with an Identity Provider (IdP) that embeds authorization details in access tokens, the application can dynamically verify whether the user’s permissions are still valid. During each token refresh, the IdP can provide updated authorization data, allowing the app to adjust the user’s access in real-time without waiting for re-authentication. This approach ensures that the app’s permissions reflect the user’s current authorization status throughout the session. 

This process applies specifically to apps configured using the OAuth protocol.

Authorization Lookups

This section is especially relevant for RBAC and how authorizations are stored for users. These authorizations are stored in one of a few ways:

• Central Directory (LDAP or Active Directory): It may reside as a group with your account as a member of the group.
• App database (Like SQL): It may reside as a table entry of roles and with relationships to your account as represented in the app
• Systems that further extract authorizations from a variation of LDAP or Database: Identity and Access Management (IAM) systems, Cloud service providers (like AWS, Azure, Google Cloud), SaaS, Security Tokens (like OAuth, JWT), API gateways.

Traditionally the auth lookup was done in the app, on completion of a successful authentication, the app is configured to do a lookup of authorization against the database or LDAP to decide what access to present to the user.

As with the adoption of modern IAM systems (such as Ping Identity, Okta, EntraID, and so on), the user information (usually a SAML assertion or ID token) shared with the app has the information about the authorization that the user has. The IAM system does the app-related authorization lookup for that user to the requesting app and can pass on that information to the app along with any relevant user attributes. Since the app has a digital trust established with the SSO, it trusts the authorization info.

Moving the auth lookup left in the authentication journey empowers the IAM system to then perform dynamic authorization.

A best practice is to provision access with an expiration date, even if it’s set for a year or more. This helps prevent the accumulation of unnecessary authorizations as employees remain with the company and potentially change roles or departments. By attaching role-based authorizations to an expiration, you ensure that access rights are periodically reviewed and re-evaluated. If access is still required, users can re-request it with proper justification. Maintaining a centralized database that logs all access requests and approvals provides a clear audit trail for future reviews and investigations.

Authorization Enforcement

Policy Enforcement Point (PEP) is the component responsible for enforcing authorizations by consulting the PDP for authorization decisions. PEP ensures that only authorized actions are allowed based on the policies in place. Authorization enforcement can be applied across multiple layers in the IT infrastructure, including the application layer, service layer, network layer, and operating system layer, ensuring comprehensive access control throughout the system.

App layer enforcement

App authorization enforcement is usually the responsibility of the application and part of its secure coding practices or on a PEP embedded within a web application/custom authorization module/middleware of the app. Typically, the PEP would control which user “role” or “group” can access which sections of the app and perform only certain actions. 

<A sample app enforcement of authorization>

if (user.groups.includes("app1-operator") {
  // allow access
  GenerateReport("ALLOWED", "edit");
} else {
  //deny access
  GenerateReport("DENIED", "edit");
}hhbAccess enforcements are also applied at certain reverse proxies that sit in front of the app (also referred to as web access management); these enforcements can look at user authorizations and then decide to allow or deny the app’s sub URLs to the users. 

<A sample web application enforcement of authorization>

location /app-admin-console {
    # Protect this location with LDAP-based authentication
    auth_ldap "Protected Application";
    auth_ldap_servers my_ldap_server;

    # Allow only users from the specified group
    if ($ldap_user_group = "CN=app1-operator,DC=example,DC=com") {
        allow all;
    }

    # Deny access to users not in the group
    if ($ldap_user_group != "CN=app1-operator,DC=example,DC=com") {
        deny all;
    }

    # Proxy requests to the upstream app server
    proxy_pass http://backend_application;
}

Service layer enforcement

A service layer PEP handles enforcement for services, API, and microservices. Service layer enforcement is achieved by the use of API gateways and microservice authorizations. It can validate tokens, check permissions, apply rate limits and evaluate identity claims before forwarding requests to appropriate microservices. Modern apps use multiple microservices to fulfill a user action on an app, for example, if a user “Ade” logs into a banking app and requests to view an account balance, the app may call an API to get the user’s balance. Access control policies can be applied to microservices such that the API at that time can only get “Ade’s” account balance and not get rogue account balances for other users. This policy is enforced by the API scope limited to customer-read and only user “Ade”

<A sample microservice request with a scope limited to user "Ade">

GET /balance
Host: microservice.example.com
Authorization: Bearer <access_token>

<access_token>

{
  "iss": "https://issuer.example.com",
  "sub": "S123123",
  "aud": "microservice_balance_view",
  "iat": 1694287176,
  "exp": 1694290776,
  "scope": "balance:view",
  "client_id": "app1",
  "jti": "unique-jwt-id",
  
  "authorization_details": [
    {
      "type": "view_balance",
      "user": "Ade",
      "time_period": {
        "start": "2024-08-30T00:00:00Z",
        "end": "2024-09-06T23:59:59Z"
      }
    }
  ]
}

While we won’t dive into the specifics of other types of authorization enforcement in the context of application authorizations, it’s important to note that a comprehensive authorization strategy is incomplete without enforcement at all layers including the network and OS layers. The network layer includes critical components such as firewalls, VPN access control, and Zero Trust networks, while the OS layer encompasses tools like SELinux for Linux systems and Windows Defender Application Control for Windows. Additionally, cross-layer enforcement tools like Data Loss Prevention (DLP) further enhance security by protecting access to data classified as sensitive across multiple Policy Enforcement Points (PEPs).

Conclusion

Why did the app user bring a ladder to the login page?

Because it needed to elevate its permissions!

Apologies for the cheeky line. To wrap up, we’ve touched on various factors involved in applying authorization for users accessing an app. Now, for modern application development, here are the recommended approaches where you should be thinking about:

1. Going dynamic — outsource the authorization decision to a centralized system that can dynamically evaluate what authorizations to apply. Where feasibly consider using RAR where the app can use fine-grained permissions. Several vendors on the market offer Rich Authorization Request (RAR) capabilities, so choose the one that fits your needs.
2. Gather all relevant signals to understand the user’s context — such as device, location, network, time of day, login history, login velocity (e.g., multiple login attempts in a short time), or impossible travel scenarios (e.g., logging in from Sydney and then China within minutes). The more signals you process, the more accurate your dynamic authorization decisions will be.
3. Perform role or group lookups from a central authentication system (like IAM or SSO) rather than from within the app itself. This shift empowers truly dynamic authorization that adapts in real-time. Remember to expire role authorizations after a certain time if they are related to an activity with a finite duration.
4. Take advantage of Service layer authorization enforcements by limiting user Cascade authorization scopes to downstream microservices APIs to prevent accidental data exposure or unauthorized lookups of other users’ information.
5. Leverage a risk engine to introduce additional factors for authorization, enabling more accurate detection of suspicious activity or hacking attempts.
6. Perform SoD checks during user login to prevent any toxic combination of accesses.
7. Perform ongoing authorization evaluation during an active App session using introspection where relevant.
8. Implement an authorization enforcement strategy across multiple layers of infrastructure, including the application, service, network, and operating system. A secure network follows the Zero Trust model, which assumes that no transaction is trusted by default and requires continuous validation of authorization and authentication.

While these recommendations offer a general framework, your specific authorization strategy will depend on the application, implementation costs, and available tools. The breach example in the introduction underscores the need for more sophisticated methods, as static, role-based controls are often inadequate in today’s evolving threat landscape. Dynamic authorization allows real-time adjustments based on contextual factors, which could have prevented the breach by continuously verifying access. As authorization evolves, adopting these modern techniques is crucial to protecting sensitive data in an increasingly digital world.