Authorization Is the Last Layer Companies Still Build From Scratch

Authorization as a service 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. That’s starting to change, driven by the cost of keeping homegrown systems alive and by enterprise customers who now ask for fine-grained access control before they sign.

On episode 89, Graham Neray, co-founder and CEO of Oso, explained why the last layer is finally moving, and why the companies that move it first tend to be the ones closing bigger deals.

What is authorization, and how is it different from authentication?

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. Can Alice edit document 42? Can this support rep see that customer’s billing page? Can a tenant admin invite someone into a workspace they don’t own? Once login is done, you hold a verified identity. Everything after that is authorization.

The answers depend on your data: who owns what, which folder a thing lives in, which tenant, which plan, whether the record is locked. And the check has to hold in three places: hide the button in the UI, reject the call in the API, filter the query in the database. Miss one and you have reproduced the category OWASP ranks first. Broken Access Control tops the 2025 OWASP Top 10 with the highest number of occurrences in the contributed data, roughly 1.84 million across 40 weakness types (OWASP Top 10:2025, A01 Broken Access Control). Two of OWASP’s prevention rules read like a product spec for this whole category: “Except for public resources, deny by default,” and “Implement access control mechanisms once and reuse them throughout the application.” Most codebases have implemented that second rule many times over, once per endpoint.

Why did authentication get outsourced but authorization didn’t?

A decade ago most companies built login from scratch. Then OpenID Connect and SAML matured, Auth0 launched, Okta scaled, and the problem became standard enough to hand off. Authorization followed none of that path. “Permissions are still fundamentally broken out in the world,” Neray said on the episode. The core challenge: permission checks happen at many levels (frontend, backend API handlers, database queries), and in a microservices setup the data you need for a check might live in a completely different service.

Two things made login outsourceable. The protocols were standard, so a login flow at one company looked like a login flow at any other. And the boundary was clean: the identity provider hands your app a token and steps out of the way. The authentication layer has kept improving on its own since then, all the way to the device-bound credentials that make stolen passwords useless, precisely because nobody’s product logic lives inside it.

Authorization has neither property by default. “Editors of a document can comment on it, unless the folder is locked, unless you’re the workspace admin” is your product. The facts that decide it sit in your tables. Until recently there was no shared vocabulary for handing that logic to anyone else, which is why every engineering team wrote its own dialect. What changed is that the vocabulary arrived, partly from standards bodies and partly from Google.

RBAC vs. ReBAC vs. ABAC: which authorization model does your product need?

Three models cover almost everything a SaaS product does, and the distinction matters because most real apps need a mix, which is exactly what makes building from scratch so hard.

RBAC, role-based access control, assigns permissions through roles: admin, editor, viewer. NIST’s David Ferraiolo and Rick Kuhn formalized the model in 1992, it became American National Standard INCITS 359 in 2004, and a 2010 economic analysis by RTI International for NIST estimated the research had saved industry $1.1 billion (NIST, Role Based Access Control project). Roles map to the org chart and make onboarding fast, which is also their weakness: when a role is the only knob, people get “admin” so they can do their job, and roles multiply until nobody can say what any of them means.

ABAC, attribute-based access control, evaluates attributes of the user, the resource, the action and the environment against policy. NIST SP 800-162 defines it as a method where “authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships” (NIST SP 800-162). Department matches department, the record isn’t classified, it’s business hours. ABAC handles context that roles can’t, at the price of policies that are hard to enumerate: try listing everyone who can see a record when the answer depends on the clock.

ReBAC, relationship-based access control, derives access from how things relate: Alice is an editor of document 42; document 42 sits in a folder; the folder belongs to a workspace Alice’s team owns. This is how Google Docs sharing has always felt to a user, and in 2019 Google published how it works. Zanzibar, described at USENIX ATC, stores and evaluates access control lists for hundreds of Google services including Calendar, Cloud, Drive, Maps, Photos and YouTube. The paper reports trillions of ACLs, millions of authorization requests per second, a 95th-percentile latency under 10 milliseconds and availability above 99.999%, after three years in production (Pang et al., Zanzibar: Google’s Consistent, Global Authorization System, USENIX ATC 2019). Its data model is a tuple of object, relation and user, and a wave of open-source and commercial authorization services adopted it.

Oso’s own framing is that fine-grained authorization is “an access control approach where permissions are determined not just by a user’s role, but by a combination of attributes, relationships, and contextual data” (Oso, What is fine-grained authorization). That combination is the point. Writing a role check is easy. Expressing “editor of this document, in an unlocked folder, during business hours, unless the tenant admin says otherwise” once, and enforcing it everywhere, is the actual engineering problem.

What does homegrown authorization really cost?

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

“Everyone has built this sort of thing from scratch. Band-aid, band-aid, band-aid. And then everyone does a big refactor.”

Graham Neray, co-founder and CEO of Oso, on episode 89

The costs are specific. Companies often put six or more engineers on homegrown authorization full-time, roughly $1.5 million a year on a system that isn’t the product. Adding a new role can take a week or a sprint instead of a minute. And each patch makes the next change harder, because the rule now lives in a dozen handlers and two database views, and nobody remembers which copy is canonical. Neray frames the build-versus-buy decision the way the rest of the infrastructure stack already settled it: “AWS, Twilio… have normalized the idea that if the thing isn’t making your beer taste better, you should consider buying it instead of building it.”

Slack shows what solving it alone costs. Enterprise Grid, the product that took Slack upmarket, launched in early 2017 with PayPal, Capital One and IBM already using it (CIO Dive, February 2017). To sell it, Slack needed to say that one user owns this channel while another owns that one, across very large organizations. As Neray told it, no off-the-shelf service existed, so Slack spent millions building a custom system. Allan Leinwand, who approved that project, later became CTO of Webflow, and when Webflow hit the same point, he chose to buy rather than build it twice.

When does fine-grained authorization become a sales requirement?

The trigger to rethink permissions usually isn’t a security incident. It’s a deal. “Usually the driver to adopt Oso is about a company moving up market,” Neray said. “They want to sell to the federal government. In order to do that, they need fine-grained access control.” Fine-grained control goes beyond broad roles, checking a user’s relationship to the specific resource, their attributes, and the request context for precise, real-time decisions.

You can hear the requirement arrive in the language procurement uses. Can our admins define their own roles per team? Can a contractor be given one project without seeing the rest? Can you show us who can access what, and prove the rule is enforced? Each of those is a fine-grained authorization question wearing a procurement badge, and each one has a habit of appearing in the same week as the request for your SOC 2. The Security criteria in every SOC 2 lean heavily on logical access: who is authorized, how access is granted and removed, how often it’s reviewed. A centralized authorization layer answers all of that from one place, because the policy says who can do what and the decision log shows it happened, which is why the teams that centralize permissions tend to breeze through the access-control section of a SOC 2 Type 2.

That is what makes authorization unusual among security investments. Most security purchases reduce risk. Authorization is different: the feature itself is what enterprise customers pay for, and when a product adds fine-grained controls, it opens deals that weren’t possible before. As our co-founder Sasha Sinkevich put it on the show: “The value add from a SIEM is very different than the value add from a security control that enables your growth.” And Jon McLachlan 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.” That’s precisely the posture behind turning security into a sales asset.

Neray put the same idea in one sentence, and it’s the one we’d tape above a founder’s desk:

“Security should not just mitigate risk. It should unlock revenue.”

Graham Neray, Oso, episode 89

How do you answer “why shouldn’t we build it ourselves?”

Every founder who has tried to sell infrastructure to engineers knows the objection, and Neray has heard it more than most:

“Engineers don’t ask ‘Should I buy this?’ They ask, ‘Why shouldn’t I build it myself?’”

Graham Neray, Oso, episode 89

For a technical buyer, the competition is their own roadmap far more often than another vendor, and a service has to beat the in-house option on depth, speed and durability or it loses to a weekend of hacking. So here is the honest version of the answer, the one we give founders who ask us whether to build the permissions layer themselves. Build it when a handful of role checks genuinely covers every customer you have, and when authorization is not on the critical path of any deal. Buy it, or adopt a dedicated framework, when any of four things is true: an enterprise prospect has asked for custom roles or per-resource sharing; the same rule is enforced in more than one place; the data a check needs lives in a service other than the one doing the checking; or agents are about to start calling your API. It’s the same arithmetic we apply to security staffing in In-House, On-Demand, or YOLO?: you can almost always build it; the question is what the roadmap loses while you do.

Neray’s other lesson from the episode is for anyone selling the buy side of that argument. He tried to sell the vision for Oso with nothing but a conversation: no deck, no demo. The feedback was useless until he showed up with a faked-out demo and a documentation page, at which point people started telling him the truth.

“The quality of feedback is directly correlated to how real the product is.”

Graham Neray, Oso, episode 89

That applies to your own permissions feature, too. When an enterprise prospect asks whether admins can scope access per team, a slide describing the roadmap gets a polite nod; a working screen in the demo gets a security review scheduled. He also told us about the Friday night the first Oso customer signed, on a verbal from their CTO over Zoom, and the ten minutes he sat alone at his desk absorbing the fact that someone had paid for the thing. Andrew Rubin made a related point about technical founders and selling in our Illumio post: the concrete artifact is what turns a thesis into a company.

What changes when AI agents start calling your API?

AI agents make all of this urgent, and they change the shape of the question. Every company adding agents must answer: what can this agent do, and on whose behalf? Traditional role-based systems can’t answer that on the fly. An agent’s task changes every run, and it can be tricked in ways humans can’t. “If you want to add agents to your product, you basically have to figure this out,” Neray said, and, more bluntly: “You want agents in production? You have to get permissions right.”

The agent-specific work is its own subject, so we gave it its own posts. Why agents need least privilege more than humans ever did covers scoping an agent’s permissions per task; the read-before-write permission ladder covers when an agent earns the right to change production; and governance at onboarding covers making agents declare what they need before they run. All three assume the layer this post is about exists. Companies building authorization from scratch today will face the problem twice, once for human users and again for agents. The ones that bring in a real authorization layer now solve both with one investment.

The decision: what to do about authorization this quarter

If you sell software to enterprises, the fine-grained authorization request is coming whether or not you’ve planned for it, and the companies that treat it as a feature rather than a fire drill get the deals. Three moves, in order.

First, inventory the rule. Pick your most sensitive resource and count how many places decide who can touch it: UI, API handlers, database views, background jobs. The number is usually a surprise, and it is the size of the refactor you’re avoiding.

Second, write down the last three enterprise asks you delayed or lost on permissions: custom roles, per-project access, proof of who can see what. That list is your product spec and, conveniently, your business case.

Third, run the build-or-buy test above with your engineers in the room. If the answer is buy, pilot the service on a single resource type and let the policy generate the access-control evidence your next security review will ask for.

If you’d like a map of where you stand today, an AI access control audit inventories every identity and permission in your product, human and agent, and cuts them to least privilege with the evidence buyers ask for; if you’re designing the permissions model for a new enterprise tier, that’s the kind of work our product security team does alongside yours. And if you’d rather hear the argument first, Graham makes it in 37 minutes on episode 89, including the story of the agent that deleted a production database and then lied about it.