The technical complexities of decoupled authorization

Technical complexities when implementing decoupled authorization

Decoupled authorization has clear advantages over inflexible authorization logic that's written directly into application components. Decoupling authorization into its own service can increase overall complexity, though. You have to develop and maintain two services while ensuring they remain compatible with each other. Here are four specific kinds of technical complexity you'll face.

Integration with the main application or service

Plugging the decoupled authorization layer back into your main application can be harder than you think. Whereas authorization has historically been a synchronous process without side effects, decoupling introduces the potential for system failures when the authorization service can't be reached or an unknown response is received.

The decoupled authorization component must be carefully integrated to ensure the implementation is reliable. The application will need to retry calls to the authorization layer that fail due to a flaky network, for example. When no response can be obtained, perhaps because the authorization component has failed, the app should deny the user's request to prevent authorization being inadvertently granted.

Each app you develop will need to integrate the authorization layer before it can be consumed. These integrations should be backed by tests that verify the app correctly handles different authorization outcomes, such as grant, deny, and failure.

Management of user accounts and permissions

Decoupling authorization from application code doesn't mean you can forget about user accounts and permissions. These still need to be managed by your authorization layer, either directly within your authorization component or with an external identity provider.

The service you use should be flexible enough to store all the user data you require. All but the simplest systems will require a granular permissions model with support for roles and groups. You'll need a mechanism for setting up and maintaining this data, either via scriptable APIs for automated provisioning or an accessible web UI for human use.

Decoupling authorization without planning how you'll manage user accounts can cause problems as you reintegrate your components into your application. Apps need a dependable mechanism for establishing the user's identity, retrieving relevant attributes such as their team and project, and checking which permissions have been assigned. All this info has to be centralized across your services to preserve consistency.

Handling data filtering and pagination

Services that filter data and display results over multiple pages need to be adjusted so users are only shown the items they can interact with. For example, an API request for the first ten invoices in a system could expose a different set of items depending on the user: department leaders might only see invoices approved by their department, while accounting staff have unfiltered access.

To achieve this, you'll need to run your authorization policies against each item included in resource lists fetched by your application. The policies should verify that the items can be used in the current authorization context defined by the characteristics of the resource and the requesting user.

Unfortunately, performing authorization checks for lists of hundreds or thousands of records is often an inefficient process. It also has knock-on impacts on your pagination routines. When an item gets discarded because authorization is denied, a replacement must be loaded from the database to fill up the correct page size.

To properly address this complexity, plan how you'll integrate your data queries with your decoupled authorization policies. Select an authorization provider that includes features such as query plans to preemptively retrieve the list of resources that a given user can interact with. Use the plan to filter database queries at the point they’re made, instead of individually running authorization policies against each item in your result sets.

Maintaining security and privacy

Decoupled authorization can create security weaknesses and privacy concerns. Any new service increases your threat perimeter and creates an additional target for attackers. Splitting authorization out of your application converts it into a standalone component that might be easier for bad actors to manipulate.

Traditional authorization models are invisible from outside your application. Authorization checks occur within the code, providing no opportunities for attackers to investigate their logic. Decoupled authorization can be more visible if your service isn't properly protected. Network activity logs reveal the requests being made and the results obtained in response.

Insecure authorization APIs can leak data too. It's vital to ensure your authorization service only reveals attributes that the user's permitted to access. Otherwise, a rogue user or attacker could exfiltrate sensitive details by making direct calls to the authorization API.

Ensuring scalability and reliability

Authorization is a critical application component. It's involved in almost every user interaction, demanding exceptional scalability and reliability. Poorly optimized authorization is a bottleneck that compromises your whole system's performance.

Splitting authorization into its own service can increase latency as your apps have to wait for authorization checks to complete. Too many pending calls will increase congestion and lead to resource contention. If your authorization layer can't scale with user activity, people will be left waiting at times of heavy usage.

Failure resilience is equally important. If authorization goes down, users won't be able to log in or access functions that require permission checks. Authorization services should be deployed as multiple replicated instances to produce a fault tolerant architecture that can withstand individual instance crashes.