Authentication and authorization are the two central pillars of security of any application. Authentication is the identification of valid users and authorization is the process of determining what those users are allowed to do. User authorization plays a crucial role in securing access to your application by handling the privileges assigned to users, groups, or roles. In this way, access to individual routes, components, or services can be restricted based on your business needs.
A clear trend away from in-house solutions for authentication has emerged in recent years as more companies rely on third-party solutions like Okta or Auth0 to handle user authentication. The same widespread move towards third-party authorization services is taking shape now as many of the advantages that developers get from using an external authentication provider apply in authorization too.
In this article, I will go over the hidden costs of building and maintaining application authorization in-house. You’ll also learn how using a third-party authorization provider can save you development time and prevent security mishaps in today’s ever-evolving web applications.
While authorization is a wide-ranging topic, there are two dominant approaches: RBAC (Role-Based-Access-Control) and ABAC (Attribute-Based-Access-Control). The two differ mainly in the way that user rights and access privileges are assigned to individuals, but let’s look at what that means in practice.
Role-Based-Access-Control uses pre-defined roles (for example, “admin” or “trial-user”) to assign privileges to users based on the roles they have. This means that privileges are essentially copied from other users who already have the same level of access.
This simplicity is also a big disadvantage in systems as they scale. You can’t assign granular permissions like project and team-level administrative access without expanding your roles table. This makes maintaining RBAC a headache in a SaaS application with lots of users and permission levels.
Unfortunately, a lot of applications start by using RBAC in the early days and quickly realize how limiting this model is. Once you’re fully committed to an access control model, it can be extremely hard to change.
Attribute-Based-Access-Control takes a different approach by granting access to users based on each one’s attributes, the resources they’re requesting, and the environment they’re making the request from.
The main benefit of ABAC is that you have granular control over each user’s privileges. For example, using ABAC, you can give users of a human resources application the right to export personnel reports for only the regions they are responsible for. Because the model is designed to scale up to any number of attributes and permissions, it’s generally easier to build more dynamic permissions in ABAC.
However, the downside is that your maintenance effort can be higher. You need to audit these permissions on a much more granular level, and if you haven’t automated the configuration process, every new user requires a more extensive setup to assign all the correct rights.
This complexity also means the risk of errors due to misconfiguration is greater. So, you have to be ready to invest in a robust ABAC system, but as you’ll see, this is no small expense when done on your own.
Once you’ve decided on the user authorization model you want to use (RBAC, ABAC, or something else), you now have to decide how it’s going to get added to your application.
Authorization is one of the hardest parts of security to get right and one of the most expensive to fix when you get it wrong. A single slip might lead to user data being exposed, leading to a loss of trust and public relations nightmare.
For example, Microsoft revealed a network security misconfiguration that led to the leak of 250 million customer support records in 2020. “Misconfigurations are unfortunately a common error across the industry. We have solutions to help prevent this kind of mistake, but unfortunately, they were not enabled for this database.” Needless to say, this doesn’t instil trust in the brand.
Authorization includes a lot of layers and a lot of places for things to go wrong. From top-level concerns like assigning permissions to the fine-grained aspects of securing access to individual endpoints, each stakeholder involved must get things right in order for it to work.
This is part of the reason many companies are starting to lean on third-party authorization providers like Cerbos. By giving you an out-of-the-box authorization solution, you can skip a lot of the costs associated with building one in-house.
As you weigh your options, here are a few of the challenges you should consider when implementing authorization in-house:
With most software, ongoing maintenance costs quickly eclipse the initial buildout cost. Fixing an existing system requires knowledgeable engineers to be available, and because authorization is a cross-cutting concern, bug fixes might affect many parts of your application or business units.
One way to mitigate some of these maintenance costs is by abstracting the actual implementation of authorization from your core business logic. This way, you can make changes to roles or privileges at the end-point or function call level without changing every service you maintain.
A new business model, new user groups, or the need to replace one system component with another can bring new requirements for authorization. For example, you might want to provide external developers with direct API access to one of your core services. This might require a whole new ruleset to cover permissions, quotas, and field-level security rules.
Authorization, when done right, should not be visible to users at all. The most that a user will see of your authorization process is an access-denied page—and that should be a rare case.
So, while authorization is critical to get right, it’s not what your customers pay you for and likely not something they consciously think about at all.
The problem is that small to medium-sized companies rarely have the resources to hire a specialized team for authorization. That means that engineers are pulled away from their other backend development tasks to handle it, and many have to learn as they go. This increases the risk of getting something wrong in authorization because it isn’t really their core focus.
Depending on the size of your authorization system, the cost of building and maintaining it can quickly spiral out of control, and you may not have experts in-house to handle it.
So, there are three typical solutions to this problem:
One option is to bring on or train your own team of security specialists to handle authorization. This is obviously the most expensive way to handle the authorization challenge, but there is some value in having an in-house team you can turn to to maintain an authorization system.
If you can’t bring on full-time people, you might also consider consultants who can help train or design an authorization system for your team. Again, this option is expensive but more flexible than hiring people full-time.
Either way, bringing on full-time engineers will cost hundreds of thousands of dollars every year, so for most small to medium-sized businesses, this option is out of reach.
Another option is to use a widely trusted open-source library to handle authorization. Tools exist for many programming languages and frameworks and often adhere to industry standards that have been proven at scale.
Unfortunately, most open-source solutions still require a fair bit of work and technical expertise to weave into existing code. Documentation may be spotty, and because these are free to use, they don’t include any technical or implementation support.
With the library-based approach, if there are updates or security fixes to the library, the entire codebase needs to be updated, recompiled, and redeployed. You also have to grapple with dependency conflicts, runtime version mismatches, and API changes that require changes to a very large surface area of your code.
Finally, it may be difficult to share this authorization logic with other applications unless they are developed in the same language or framework. Reworking code from a library written in Python to work in your JavaScript application is not a realistic option.
An approach that is becoming increasingly popular is to delegate the access control decision to a service such as Cerbos that is deployed to your local network as a microservice or as a sidecar to your application.
As polyglot microservice architectures are becoming the norm, this approach makes a lot of sense. You can share your access control logic across the fleet by making it available over a simple, language-agnostic API and use your existing CI/CD processes to test and deploy new access policies without having to rollout changes to the whole fleet.
Cerbos also gives you fine-grained, context-aware access control for your application. The policies you create with Cerbos can then be linted and tested to ensure you’re not giving improper access to users, and you can update these policies quickly. No need to re-compile or re-deploy your application every time you change user permissions. Cerbos is self-contained and deploys into your own network without any external dependencies. So you are in total control of your data and your application’s availability.
Finally, by starting with Cerbos, you can try it out at no cost and make sure it’s a good fit for your web application before you commit.
Whether you build a bespoke authorization solution in-house, rely on a third-party library, hire consultants, or use a third-party service, it’s important to understand what you’re getting into. Picking the wrong authorization model or making a mistake in your implementation can be costly, so be sure you know the risks. As more applications use distributed, specialized services to solve problems like authentication, it’s likely we’ll see the same trend move forward in authorization as well.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。