In 2013, poor authorization practices led to one of the largest data breaches in history. Over a three-week period, hackers stole 40 million credit and debit card accounts from retail giant Target by exploiting the account of an HVAC contractor. The attack began with an email-based phishing scam that tricked an employee at the HVAC company into revealing their credentials. As a vendor to Target, the HVAC company had legitimate access to Target’s systems. Using the stolen credentials, the hackers infiltrated Target’s network and installed malware on the retailer’s point-of-sale systems, enabling them to collect customer data. The breach resulted in direct costs to Target of nearly $300 million, along with reputational damage that is difficult to quantify.1
The Target breach underscores the critical importance of not only knowing who is accessing your systems (authentication) but also controlling what they can access (authorization). The HVAC vendor had access to Target’s systems for electronic billing, contract submission, and project management. However, the hackers were able to extend this access beyond those legitimate uses to reach systems used to update point-of-sale devices. Target’s failure to properly restrict access to critical systems created a significant vulnerability that the hackers exploited.
But I don’t want you to get the idea that authorization is just about securing IT systems—it’s also fundamental to how modern cloud applications function, enabling features that wouldn’t be possible otherwise. For example, services like Google Docs and Dropbox rely on authorization to allow users to share documents with specific people while restricting access to others. Without this capability, these applications would not be possible.
Another example is Amazon Web Services (AWS), where authorization enables Amazon to securely provide hundreds of cloud services to millions of customers at scale in a cost-effective manner. As a global distributed system taking advantage of multi tenancy to service millions of customers, AWS uses a sophisticated policy-based authorization system to help customers control access to the services running inside their accounts.
Several trends make authorization a more important topic that it has been:
More and more software is being delivered as a service (so called Software as a Service, or SaaS). As we’ve discussed cloud-based services can’t provide the needed levels of functionality and security without strong authorization systems.
Perimeter-based security architectures like firewalls are giving way to zero-trust architectures. Rather than assuming everyone inside the perimeter is trusted, zero-trust systems assume breach and authorize every access. This isn’t possible without flexible authorization systems that can determine whether to grant access based on the context of the request.
Internet of Things (IoT) and interconnected devices mean that more and more computer systems are talking to each other on their owner’s behalf. Restricting their access to the role they play protects them and prevents them from becoming a vector that hackers can exploit to break into other sensitive systems.
Regulatory compliance is yet another reason why authorization is increasingly important. Laws like the Health Insurance Portability and Accountability Act (HIPAA) and General Data Protection Regulation (GDPR) require that access to personal information be carefully controlled so that only the right people and systems can use it. Beyond controlling access, these laws also require that you be able to audit access to show compliance.
In addition to these, the rise of GenAI and particularly AI agents that can act on your behalf pour gasoline on the smoldering identity industry interest in authorization. Am I talking to a human? Does this agent have authority to make a doctor's appointment on the patient's behalf? These and other questions mean that making good authorization decisions, knowing what decisions were made, and easily incorporating authorization infrastructure into your apps and infrastructure is vital.
Notes
The story is interesting beyond the fact that it highlights the need to properly manage access. Target’s response, or rather lack of one, provides several important security lessons: Cyber Case Study: Target Data Breach provides more details
Photo Credit: Hacker Stealing Credit Cards from DALL-E (public domain). Prompt: Draw a wide picture of a hacker stealing credit cards from an online store.
As you are no doubt aware, the authorization systems you mention in your post are from a class of authorization systems that I call closed loop as opposed to open loop. The distinction I make between the two, is that in closed loop systems the issuer of the authorization (be it a token or a set of permissions tied to an accout) is also the verifier of the authentication of the accessor in order to release the resource or grant access to the presenter of the authorization. So the Issuer forms a closed loop with verification authentication and authorization grant. This of course is extended via federation so that IdP acts as both issuer and verifier.
Whereas in an open loop system the issuer of the authorization and verifier/grantor of authentication/access are two different entities. Open loop systems require extra infra-structure such as a neutral verifiable registry that maintains key state.
This open loop architecture enables cross trust domain transfer of authorizations without exposing each trust domain to privilege escalation
The cross trust domain problem is IMHO the root cause of privilege escalation attacks because in closed loop systems everyone, everyone's, vendor, and everyone's vendor's vendor i.e every connected system must belong to the same trust domain.
What this means is that closed-loop zero trust architectures are at best a half-measure. They still are vulnerable to privilege escalation attacks, albeit less vunerable because the frequency, and scope of verifications limits the extent of the attack.
Therefore, the ultimate solution to the authorization problem IMHO must solve the cross-trust domain problem which requires an open loop architecture.