Authorization Is the Last Layer Companies Still Build from Scratch

Authorization as a service is a category that barely existed five years ago. Authentication got handed off to Auth0 and Okta a decade back. But authorization, the logic that decides what a user can see, edit, or delete inside your app, is still built from scratch at most companies. This is starting to change, driven by the cost of keeping homegrown systems alive and the growing demand for fine-grained access control from enterprise customers.

Why Authentication Got Outsourced but Authorization Didn't

A decade ago, most companies built login systems from scratch. Custom login flows, password hashing, session handling, token management. Then standards like OpenID Connect and SAML grew up. Auth0 launched. Okta scaled. The problem became clear enough to hand off. Today, building your own login system is rare.

Authorization followed none of that path.

Graham Neray, co-founder and CEO of Oso, explains why authorization resisted the as-a-service model longer than almost any other layer: "Permissions are still fundamentally broken out in the world."

The core challenge is that permission checks happen at many levels. They run in the frontend, in backend API handlers, and in database queries. In a single-service app, all the data you need for an authorization check is in one place. In a microservices setup, the data might live in a completely different service. Neray calls this "a pretty hard problem to solve at scale."

Authentication asks one question: is this person who they say they are? Authorization asks a different question for every action, against every resource, with logic unique to each app's data model. That made it very hard to turn into a standard product.

The difference between RBAC vs ABAC matters here too. Role-based access control (RBAC) assigns permissions through fixed roles. Attribute-based access control (ABAC) looks at changing properties like department, resource sensitivity, or request context. Most real apps need a mix of both, which makes building authorization from scratch even harder.

The Real Cost of Homegrown Permissions

Every growing SaaS company hits the same turning point. The first permissions setup, a few role checks hard-coded into the API, works fine at 10 customers. By 100 customers, edge cases pile up. By 1,000, the system eats engineering time that should go toward the product.

Neray has seen this cycle hundreds of times: "Everyone has built this sort of thing from scratch. They start with something simple. It gets more complicated over a period of time. Band-aid, band-aid, band-aid. And then everyone does a big refactor."

The costs are real and specific:

• Engineering headcount: Companies that keep homegrown authorization often put six or more engineers on it full-time. At $250,000 per year each (Neray's estimate), that's roughly $1.5 million per year spent on a system that isn't the product.

• Time to ship new features: Adding a new role to a homegrown system can take a week, a sprint, or longer. Neray contrasts this with a managed service: "It takes you a minute to add a new role instead of a week or a month."

• Growing technical debt: Each patch makes the next change harder. Teams become afraid to touch permissions because they don't fully understand what might break.

Neray frames the build vs buy authorization decision the way the rest of the infrastructure stack already proved out: "AWS, Twilio, companies like this over the last 15 or 20 years have normalized the idea that if the thing isn't making your beer taste better, you should consider buying it instead of building it."

Oso's first open-source user showed the upside from another angle. They sold software to defense manufacturers and used Oso to build fine-grained permission features they charged hundreds of thousands of dollars for. The permissions layer went from a cost to a revenue driver.

When Fine-Grained Access Control Becomes a Business Requirement

The trigger for most companies to rethink permissions isn't a security incident. It's a sales deal.

Neray identifies the pattern: "Usually the driver to adopt Oso is about a company moving up market. Maybe they want to serve large banks. They want to sell to the federal government. In order to do that, they need fine-grained access control over who can do what inside the system."

Fine-grained access control goes beyond basic RBAC. Instead of putting users into broad roles (admin, editor, viewer), fine-grained systems check multiple factors: the user's relationship to the specific resource, their attributes, the context of the request, and conditions around the environment. The result is precise, real-time decisions rather than static role lookups. This is where the RBAC vs ABAC distinction matters most. Enterprises often need both models working together, sometimes combined with relationship-based access control (ReBAC), to meet their needs.

The Slack story shows the cost of solving this without outside help. Around 2018, Slack was growing fast and launched Enterprise Grid to move up market. The product needed fine-grained permissions: the ability to say that one user owns a particular channel while another user owns a different channel. No off-the-shelf authorization service existed at the time. Slack spent millions of dollars building and maintaining a custom system.

Allan Leinwand, who approved that project as SSVP of Engineering at Slack, later became CTO of Webflow. When Webflow hit the same point, growing fast and needing fine-grained access control for enterprise customers, Leinwand chose to buy Oso instead of building again.

Neray describes two types of buyers. The first: "People who have built these systems before, they start their next project, they come straight to Oso and say, I don't want to build this again." The second: companies that have stacked up enough patches to know the next rewrite needs to be the last. Guy Podjarny, founder of Snyk and now founder of Tessl, falls into the first group. He's been using Oso from day one.

Authorization as a Growth Engine, Not Just a Security Control

Most security purchases come down to risk reduction. Authorization as a service is different because the feature itself is what enterprise customers pay for.

When a SaaS product adds fine-grained access controls, it opens deals that weren't possible before. Government contracts, financial services clients, healthcare organizations: all need detailed permissions as a condition of doing business.

Sasha Sinkevich, co-founder of YSecurity and Cyberbase.ai, raised this point on the podcast: "The value add from a SIEM is very different than the value add from a security control that enables your growth." Neray agreed: "This is quite different from me trying to sell you a SIEM. Usually the buyer for Oso is the CTO or the SVP of engineering, and there's pain coming from someone on the product and go-to-market side saying, we need to build these things."

This shift matters for how security teams talk about authorization inside their company. It's not a budget line for risk reduction. It's a step you need to take before you can close revenue. The ROI is clear: replace a team of six engineers with a managed service, ship enterprise features faster, and close deals that require fine-grained controls.

Jon McLachlan, co-founder of YSecurity and Cyberbase.ai, captured the bigger idea: "If you can actually position security to be your market distinguisher, your secret weapon, you're going to get more of those deals, the bigger ones, the ones that are more sticky and care deeply about security."

The AI Dimension

The shift to AI agents makes the authorization problem more urgent. Every company adding agents to its product needs to answer the same question: what can this agent do, and on whose behalf?

Traditional role-based systems can't answer that question on the fly. An agent's task changes every time it runs, and it can be tricked in ways humans can't. Neray's summary is direct: "If you want to add agents to your product, you basically have to figure this out."

Companies that already have a solid authorization layer, like Productboard (an Oso customer for three years), have moved further on their agentic journey than companies still running homegrown permissions. The foundation for agent authorization is the same foundation needed for enterprise-grade human authorization: a central, policy-driven permissions engine that can check access in real time.

Companies building authorization from scratch today will face the same problem twice: once for human users, and again for agents. The ones that bring in outside authorization now solve both problems with one investment.

Hear the Full Conversation

Graham Neray joined hosts Jon McLachlan and Sasha Sinkevich (co-founders of YSecurity and Cyberbase.ai) on Episode 89 of The Security Podcast of Silicon Valley to talk about why authorization is still the most under-invested layer in the SaaS stack. They cover how the shift to AI agents makes the problem urgent and what Neray learned about selling infrastructure products to skeptical engineers.

The episode also gets into Neray's advice on starting a company, the Catch-22 of selling security to security-conscious buyers, and why the best advice he got at 19 was "no one knows what they're talking about."