A bear playing hopscotch

Who is using authorization as a service, and why

Graham Neray

“It’s tied too deeply into the rest of our app.”

“But it’s on the critical path.”

“We have complex authorization…it’s too custom.”

This is what engineering leaders told me when we started Oso 3+ years ago. Still, while authorization is critical — if it doesn’t work, the app doesn’t work – it’s core to no one’s business. I heard from the same engineering leaders that RBAC is not the project most engineers are clammering to work on. And that it’s a pain. It’s made up of requirements that are hard to get right and always changing, and it’s often held together by fragile, interdependent pieces of code. Engineering leaders already lean into the as-a-service model for other parts of the stack that are  undifferentiated yet critical (e.g., feature flags, authentication)…Authorization is next.

Fast forward to today, and thousands of organizations are using Oso's authorization as a service for mission-critical authorization in applications serving millions of users worldwide. Working directly with many of these teams, we’ve learned why companies are moving to authorization as a service, and what they’re realizing as a result. Here’s a summary of the trends we see.

Transitioning from monolith to microservices

Problem

Moving to microservices breaks a lot of assumptions that are valid when building a monolith. One core assumption is that at any point, you can be sure that you have all the authorization data you need to resolve a given request. For instance, if you need to see if a user has write access to a specific file, you can easily call into your database to find out…because you have just one service and just one database.

But when you move to microservices, this is no longer true. The data you need to determine whether that user has write access on that document might live in another service. We’ve written about this problem extensively (Best Practices for Authorization in Microservices, Managing Authorization Data in Microservices). In this world, all roads lead to a central authorization service.

Example case studies

Wayfair

- Problem: International Supply Chain engineering team manages applications for interfacing with 16K suppliers. Team-wide initiative to move to microservices, which broke existing authorization system

- Result: POC’d Oso during hackathon and migrated thereafter. Now authorizes 120K end-users’ access to shipments, packaging, and all other supply chain data

Headway

- Problem: Scaling from monolith to microservices as the company brought on hundreds of thousands of users.

- Result: After doing a POC bake off against other solutions, Headway decided Oso fit squarely on their use case (app authz) and stood out in terms of overall quality, developer experience, and support level. They have centralized authorization so they can move to microservices and have a single place to audit authorization logic.

Centralize authorization and standardize

Problem

Authorization code is usually commingled with the rest of an app’s business logic, spread throughout the codebase. This can make it challenging to reason about, iterate on, test, and debug. E.g., you added a new role, but it’s not enforced everywhere — why? It can also lead to an inconsistent user experience, which is especially common when companies acquire other companies and try to unify their permissions models. Many companies are now adopting authorization as a service as a way to centralize their authorization logic and standardize across applications.

Example case studies

Intercom

- Problem: Had legacy custom authorization in 9-year-old Rails app, with code spread out throughout the application. Any time engineers needed to add a feature or make a change, they had to do so in many places – slowing them down. Authorization bugs were #1 source of bugs in bug bounty.

- Outcome: Migrated to Oso in 3 weeks with 2 engineers, providing a central place to manage authorization, eliminating authorization bugs, and opening up fine-grained use cases so they could move upmarket. Authorizes over 250K users per day.

"We (Intercom) went all in on Oso and it has been really great for us. As we moved upmarket, being able to consistently and accurately implement authz features helped us move a lot faster - and resolved a never ending source of bugs and confusion."

-Brian Scanlan, Principal Engineer, Intercom
Digimarc

- Problem: Acquired multiple companies and needed to consolidate them to provide unified customer experience. Each company and its apps had its own authorization implementation, as well as its own Admin UIs where users managed permissions.

- Solution: Migrated to Oso to provide central authorization system across all legacy and acquired applications in <1 month.

Verizon

- Problem: The Verizon Security Team had been using a homegrown RBAC system, which was unpredictable and painful to manage. It needed a trustworthy, repeatable way to enforce authorization across dozens of critical security systems, which share common concepts and permission sets but deal with a wide variety of systems and purposes.

- Solution: Migrated to Oso, providing not only single authorization solution and predictability, but also unit testing (more predictability!) and the ability to expose authorization policies to other parts of the business, like project managers and support personnel.

Audiostack

- Problem: Audiostack, the Enterprise generative AI platform handles lots of intellectual property like sound, content and voice. Permissions and the auditing that goes along with them are very important to ensure the trust and safety of their customers. They had a homegrown authorization service which didn't have good documentation, slowing down the team each time they added a new feature. On top of that, the service itself was running into scalability issues.

- Solution: Migrated to Oso, expanding their authorization capabilities into testing and debugging, up-leveling permissions and building trust with their customers on their way to GDPR compliance.

Result: Audiostack now relies on Oso as their centralized permission system. They've enabled their support teams to self-serve elements of access on behalf of their customers, including granting and revoking permissions, inviting users to Beta programs, granting access to specific voices and sounds, without involving the engineering team.

As a generative AI company that is focused on mid market and enterprise customers, it's incredibly important for us to be able to adapt as we move through the market and provide robust controls and protect our customer trust. The Oso dashboards also help us debug customer issues faster

Peadar Coyle, Co-Founder and CTO, Audiostack

Going upmarket to enterprise

Problem

When SaaS companies start to go upmarket, enterprise customers always want more. It starts with SSO and SOC2. RBAC is always on the list. While it may sound like a token requirement, having control over who can see and do what inside your application is a key strategy that enterprises use to mitigate their risk. (Broken authorization controls represent 3 of the top 5 Top OWASP Security Risks!)

SaaS businesses are increasingly taking the opportunity to ship not just the first RBAC request that gets them in the door, but also to adopt a model that allows them to quickly ship new authorization features – since they know more requests are coming.

Example case studies

Productboard

- Problem: Company mandate to drive more revenue from enterprise customers, and providing more control over access was top 3 initiative to do so. Specifically, they needed to be able to providing fine-grained control, e.g., this team can only see that board

- Outcome: migrated to Oso, opening up new features that drive both upsell revenue and drive more usage of Productboard in its customer base

Oyster HR

- Problem: Growth-stage HR SaaS company needed to expand support for roles as it moved upmarket. The problem was that it took 2-3 engineers 2-3 months to add a single role in its legacy Rails-based implementation

- Outcome: migrated to Oso, reducing the time to add a new role to <1/2 day

Fine-grained authorization & custom roles

Problem

After speaking with 1,000+ engineering teams about their authorization journeys, we’ve mapped out a maturity model for authorization (See: Authorization rules are always harder than you think). What we found is that when a company moves from one stage to the next, it’s often a significant refactor…and thus a common point at which we see companies adopt authorization as a service. Two common motivations that will push a company to revisit its approach to authorization are supporting fine-grained permissions (e.g., you can see this document but not that document) and custom roles (i.e., giving your customers the ability to define their own roles from a static set of permissions).

Example case studies

Arc

- Problem: Upstart bank for startups was seeing explosive growth. For the banking UI, it needed fine-grained control over resources like accounts, credit cards, and loans. CTO had “seen this movie before” and decided to build core authorization on solid foundation from beginning.

- Outcome: Built out full support for all required use cases in 3 weeks, supporting major launch and later scaling 10x during SVB collapse.

"Arc is a banking platform, so getting authorization right is critical. We knew our requirements could get complex – we’ve already got 40 permissions across 9 roles – and we wanted to lean on the experts. So, we researched 5 products and chose Oso for 3 reasons. Oso had the most intuitive and clear model. Oso was the most mature, with the best tooling and docs. The support from Oso has been unreal – almost like tapping someone on the shoulder."

– Raven Jiang, CTO, Arc
PagerDuty

- Problem: Needed a solution for granular access control in incident analysis platform.

- Outcome: Using Oso, PagerDuty was able to give its customers the tools to lock down permission and cordon off sensitive data for customers, like security incidents. Oso enabled them to delete code, which helps them move faster. You can read the interview with notes on their experience from the lead engineer, Will Gallego, here

"We looked at several SaaS options, but Oso Cloud just felt right. It was a snap to set up, adding further controls have been seamless, and it's been a super reliable product. It's great when you can solve a problem quickly and easily."

– Will Gallego, Software Architect, PagerDuty

Next steps in your analysis

These are the themes that we’re seeing among companies adopting authorization as a service, from startups to the Fortune 100. If you want to read more about authorization as a service and what it takes to build, you can read our authorization as a service overview. If you’d like to discuss your use case with some peers, you can join thousands of developers working on authorization in the Oso Community Slack.

Want us to remind you?
We'll email you before the event with a friendly reminder.

Write your first policy