Stop Treating Authorization as an Afterthought

What's the difference between authentication and authorization?

If you're asking that, you're not alone. But here's the blunt truth: most teams obsess over authentication—passwords, MFA, SSO—and treat authorization as a checkbox. That's backwards. Authentication verifies who you are; authorization decides what you can do. And when authorization is weak, it doesn't matter how strong your login is. The attacker is already inside.

So here's my thesis: Build your authorization strategy around Attribute-Based Access Control (ABAC) from the start, not as a later add-on. RBAC is fine as a baseline, but if you're still relying on static roles alone, you're setting yourself up for a breach. The modern threat landscape demands context-aware, fine-grained decisions. And the technology is mature enough to make ABAC practical.

Authentication Is Solved (Mostly). Authorization Is Not.

Authentication has come a long way. Passkeys are phishing-resistant because each passkey is bound to a specific domain—a passkey created for your bank won't work on a look-alike site (Microsoft Passkeys). CISA calls phishing-resistant MFA the 'gold standard' and identifies FIDO/WebAuthn as the only widely available phishing-resistant authentication (CISA Phishing-Resistant MFA). So if you're still using SMS codes, you're behind. But even with perfect authentication, you still need to answer: what can this user do?

That's authorization. And it's where things get messy.

Consider this: a user authenticates with MFA, so you know they are who they say they are. But should they be able to delete that database? Access that customer record? Transfer funds? Authentication doesn't tell you that. Authorization does.

RBAC Is a Baseline, Not a Strategy

Role-Based Access Control (RBAC) assigns permissions to roles, and users inherit permissions by being assigned roles (Tenable). It's simple, scalable, and works well when job functions are stable. The ANSI INCITS 359 standard defines Core RBAC as the mandatory minimum, with static and dynamic separation of duty to prevent conflicts (NIST RBAC).

But RBAC has a fatal flaw: it's static. Once a user has a role, they have all its permissions, all the time. If that role includes access to sensitive data, you're relying on the user's goodwill and the hope that their credentials never get compromised. In a zero trust world, that's not good enough. Zero trust grants no implicit trust based on network location or asset ownership (NIST SP 800-207). RBAC alone can't deliver that.

ABAC Is the Answer (and It's Not as Hard as You Think)

Attribute-Based Access Control (ABAC) evaluates attributes of the subject, object, action, and environment—like time or location—to make fine-grained authorization decisions (Cisco Duo). NIST SP 800-162 defines ABAC as a methodology where authorization is determined by evaluating attributes against policies (NIST SP 800-162).

Why is this better? Because it's dynamic. You can say: 'Allow access to this financial report only if the user is in the finance department, the request comes from a managed device, and the time is between 9 AM and 5 PM.' That's context-aware. RBAC can't do that without exploding into thousands of roles.

And ABAC is practical. Most modern organizations use RBAC as a baseline and layer ABAC on top for context-aware decisions (Cisco Duo). You don't have to rip out your existing roles. You just add a policy layer.

Here's a concrete example: imagine you're running a SaaS platform. You have a 'Customer Support' role. With RBAC, that role might have read access to all customer records. But with ABAC, you can restrict it so that support agents can only view records for customers in their assigned region, and only during their shift. That's a huge reduction in risk. And if an attacker compromises a support account, they can't exfiltrate the entire customer database.

Don't believe me? Look at the alternative. Discretionary Access Control (DAC) lets owners decide, which is flexible but chaotic. Mandatory Access Control (MAC) is centralized and restrictive, common in government but overkill for most businesses. ABAC hits the sweet spot: granular, scalable, and context-aware (Cisco Duo).

The Counterargument: 'ABAC Is Too Complex'

Fair point. ABAC requires a policy engine, a way to manage attributes, and careful design. You can't just flip a switch. But the complexity is manageable if you start small. Begin with a few high-value use cases: privileged access, financial data, or customer PII. Use a policy engine like Microsoft Entra Conditional Access, which is Microsoft's Zero Trust policy engine and can base decisions on user, device, location, and risk signals (Microsoft Conditional Access). That's ABAC in practice.

Also, consider that the alternative—a breach—is far more complex and costly. The U.S. federal government mandated zero trust principles, including phishing-resistant MFA, by the end of fiscal year 2024 (OMB M-22-09). They're not doing this because it's easy; they're doing it because it's necessary. You should follow their lead.

How to Get Started Without Boiling the Ocean

• Inventory your roles and attributes. You probably already have roles. Now list the attributes that matter: department, location, device compliance, time of day.
• Pick one high-risk area. Don't try to ABAC everything at once. Start with privileged accounts or sensitive data.
• Use a policy engine. Conditional Access is a good start if you're in Microsoft's ecosystem. Otherwise, look at open-source options like OPA.
• Enforce least privilege. Grant only the minimum access necessary, and use just-in-time access for privileged roles (NIST PAM).

And don't forget separation of duties. Divide critical functions so no single person can cause damage (NIST SP 800-53). That's a core principle that ABAC can help enforce.

Finally, think about your tokens. OAuth 2.0 is an authorization framework, not an authentication protocol—an access token alone doesn't tell you who the user is (RFC 6749). Use OpenID Connect for authentication, which adds a signed ID token (OpenID Connect). And always use PKCE for public clients to prevent authorization code interception (RFC 7636). These are the building blocks of a secure authorization strategy.

The Bottom Line

Authorization is not a one-time setup; it's an ongoing process. But if you build on ABAC, you'll be ready for whatever comes next. The question isn't whether you can afford to do it—it's whether you can afford not to.

The single most important thing to remember: Authentication without fine-grained authorization is like locking your front door but leaving the windows open. Start with ABAC, layer it on RBAC, and never trust implicitly.

Sources

• Tenable - https://www.tenable.com/cybersecurity-guide/learn/key-iam-components
• Cisco Duo - https://duo.com/learn/access-control-models
• NIST SP 800-207 - https://csrc.nist.gov/pubs/sp/800/207/final
• Microsoft Conditional Access - https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management
• NIST SP 800-53 - https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final