Role-Based Access Control with Sam Scott, CTO at Oso

Transcript

[00:00:00] John Britton:

Hello, and welcome to the Yes-code Podcast, a show all about the Yes-code Pattern and the tools that implement it. Today, we have Sam Scott, Co-founder and CTO of Oso, joining us on the show to talk about their system for authorization.

With Sam, we talk about modeling, enforcement, and architecture of authorization systems, as well as their programming language, Polar, which is purpose-built for authorization.

Let's get started.

Welcome to the show! Today I have Sam Scott, Co-founder and CTO of Oso. It's great to have you, can you introduce yourself? Tell me a little bit about yourself.

[00:00:35] Sam Scott (Oso):

Yeah, thanks for having me, so yeah, I'm Sam, the Co-founder and CTO at Oso. Before I was doing this, I did a PhD in cryptography. I've been a long-term programmer, open source contributor, fan of Rust and all things coding.

[00:00:48] John Britton:

Excellent. What kind of open source projects have you been into?

[00:00:50] Sam Scott (Oso):

Basically I've just, I don't know, I've always been a fan of the ethos of open source. back when I started programming. I did a maths undergrad, I started learning programming through that and I had a teacher whose contributed to the SageMath.

a mathematical suite written in Python and some other tooling. And so I just started attending, they had these open workshop days and there was one at my university, so I attended that and that was like introduction to the open source contribution world. I was, you know, writing something, oh, what was it? It was something that could compute binomial numbers in like integers mod P or something like that.

[00:01:21] John Britton:

Very mathy.

[00:01:22] Sam Scott (Oso):

Later I got into cryptography, I did, contributed to some open source Rust cryptography things, and then, recently my company does a big open source, library thing.

[00:01:29] John Britton:

I've always, loved cryptography and it's interesting trying to explain how it works. There's this one YouTube video I've seen, which is like the colors mixing. You can mix colors, but you can't unmix them very easily. I just love that, analogy of cryptography.

[00:01:43] Sam Scott (Oso):

Yeah, analogies go a long way in cryptography. There's like, other good ones where you have a lock box that you can put a key in it, but you lock it with someone else's key or like you close a pad lock, they have the key to the pad lock, your key is inside the lock box. Analogies go a long way in cryptography. Beacuse it's like otherwise it's just bizarre abstract maths.

[00:01:58] John Britton:

I wanted to talk today, a little bit about Yes-code and a lot about Oso and authorization and RBAC and and those types of things.

I love programming. I think programming is a total superpower, being a programmer, I can create almost anything. But, every time I have an idea, I always get really frustrated that I have to start from like the most rudimentary building blocks ever.

And so tools like Oso and other Yes-code tools, which provide high level domain specific primitives that I can remix and compose how I want to really make my life a lot better, and I would love to hear a little bit from you about your philosophy towards how to design a developer focused tool. And what appeals to you about this idea of Yes-code.

[00:02:43] Sam Scott (Oso):

So this is a topic I was thinking about recently. We were actually writing a talk proposal for Rust Conf and I don't want to turn this into a whole thing about Rust and why Rust, but I did have a very, I had a very like, career changing moment for me with Rust, which was, I was doing an internship at Mozilla and I was trying to write some cryptographic primitive things in C and C++ and I was failing miserably because I wasn't a C programmer and I didn't have that experience. I didn't have that knowledge and so everything I was trying to do, it was just resulting in seg faults and, error messages I couldn't understand and I just told myself, it's fine. I'll stay in academia. I'll be a researcher. And I won't be a programmer.

I then, you know, I was in Mozilla, I'd heard about Rust and I started reading through the Rust book on the way, on the flight back. The tooling around it basically taught me how to do like systems level programming, the things that blew my mind about it was that it had a fantastic package manager like built into the compiler basically, into the core tooling, around, things like Cargo. So that, the week I'd spent on my internship fighting with CMake, trying to get the like entire Firefox buildchain to compile and stuff like that was, replaced by you just run like cargo build and it automatically downloads everything and runs.

The compiler, having these like beautiful error messages telling you, you can't try and mutate this thing in two places because, if this thread changes it, the other thread might not know. The whole tooling around it was, amazing from a just ease of use, saving time perspective.

It was those error messages that like told me what I was doing wrong and sort told me how to fix it. And then it was the, and I know this is a thing that you are sort of a big fan of in the Yes-code thing was the kind of the primitives that Rust provided.

The concept it had around type system, the ability to, represent different states inside of an enum or the trait system, it had. It just had, a lot of these really powerful building blocks. And to me, that combination of everything, just, it meant that it took me not that much time to, to get to a point where I could feel like I could proficiently wield those incredibly powerful tools and then have the confidence to go and build as I said, at the beginning, I could then go and contribute to open source cryptographic libraries, pretty high stakes stuff.

And I was someone who just, you know, a few months earlier had said, I could never be a programmer. And that was what Rust had achieved for me. It was like, oh, I can do this. And obviously was not an expert in Rust at the time and my code was pretty, pretty horrible and I had a very patient , uh ha, open source maintainer who like helped shepherd me through that process.

But that was what good tooling and, good developer experience meant to me. And so that's what I wanted to, that's what I see the core of good tooling, the core of good, developer tooling of Yes-code being.

All of the tooling around the things that aren't the core thing you're trying to do, package management, things like that should be super easy, error messages that don't just tell you what you did wrong, but like why, and then teach you how to use the products. Presumably that's building you towards having these incredibly powerful primitives that you can, wield and help represent your complex system.

[00:05:25] John Britton:

I could definitely relate to your experience using using C and having to do memory management yourself. My journey wasn't to Rust, it was actually to Swift and before Swift, it was Objective-C and in early Objective-C, You had to do your own resource counting. And then they had ARC, which is automatic resource counting. And then in Swift, you don't even to think about it. It has like basically the same thing built in.

When we were first building these systems, we had to invent resource counting and things like that. To make it possible to build what we wanted to build. And every engineer, every software developer had to understand how all that stuff worked. And now we've gotten it to the point where you don't even have to think about it. You don't have to know about it. It's all hidden beneath a really nice layer of abstraction.

And for me, that's the recurring theme in everything I've ever done about programming, whether it's helping engineers level up their skills or teaching somebody how to use a new specific kind of domain level tool, it's all about harnessing the power of abstraction.

And for me building a tool like a Yes-code tool or a developer tool, it's, not always the technical challenge it's, almost an artistic challenge of choosing the right abstraction. So you know, the comment that you made about. Error messages that don't just tell you what you did wrong, but they tell you how to fix it. I think a really great example of that is if you look at Stripe if you've ever used a Stripe SDK, whether it's, PHP, Ruby, Python, whatever. Whenever you hit a, an error, it doesn't just tell you the error. It tells you the error and where to go to find the solution, which I think is a really, really good pattern to follow.

What I really want to get into is Oso and the problem space of authorization, and I want to start with a differentiation between authentication and authorization.

I know a lot of people confuse those two terms. They don't understand what they are right off the bat. So maybe you can tell us what the difference between the two are and what you're focused on with Oso.

[00:07:10] Sam Scott (Oso):

Yeah absolutely. Typically those two things just bundled together as auth.

Authentication. It's all about, identifying who the user is. That's your typical login flow, you have a username and password, maybe multifactor auth, or maybe single sign on, but of that piece is authentication, right? Identifying like who the user is.

Authorization is typically the piece that comes next. Now that I know who you are, what are you allowed to do? And so the piece that Oso focuses on specifically is authorization for application logic. You're building your typical, B2B SaaS products, you need to decide like what can users do inside the application.

Authorization there is covering, how do I want that app to work? Do I want people to, have a collaboration system where they can invite people to collaborate on something. Do I want it to model their organization structure into groups and teams, can people set things as private? All of that is your core application authorization.

[00:07:57] John Britton:

Interesting. What, does Oso provide in this space? What did you see as an opportunity for the developers to extract out of their application into a library, into something that they can consume with, a simpler interface and hopefully a high level of functionality. What was the kind of delineation there.

[00:08:12] Sam Scott (Oso):

Yeah, effectively, we, we broke down authorization into of a few different areas of and like few different pieces that you need to solve.

So it's like the modeling piece, which is, how do you want your authorization logic to work? The, the piece I just touched on, is it roles, is it sharings, it groups? And just figuring out how do you go and implement that? Like, how do you write the logic? How do you build the data model. Stuff like that.

We talk about enforcement, which is how do you take that model, that modeling piece, and how do you make sure it's enforced or carried out in the application. How do you integrate that with your app? And this can be everything from, your core application, can the user do something. mean filtering the data based on what people can do. It might be like making the UI authorization aware. So it covers quite a lot.

And then finally there's like the architecture piece, which is if you're solving this across multiple services and you want it all to work consistently you just figure out how to take all that stuff and share it, share the logic, share the data around things like that.

Oso exists to, basically, solve those, all those three areas. This is something that people typically spend a lot of time building themselves. And we, ultimately we want developers to spend about a 10th of the time that they currently do an authorization. And so we do that by building a product that solves the, the problems across those three areas.

[00:09:23] John Britton:

This is really interesting to me. You said, developers will often build this themselves why is there such a tendency for, developers or, product teams to build this themselves versus use something else? Why don't they use a tool?

[00:09:37] Sam Scott (Oso):

It comes down to the complexities of those three areas I spoke about. And it's funny, because when we started out on going down this path, a lot of people we spoke to was like, "I just don't see how this could possibly be done as a separate product. It's so deeply interwoven with my core application. How could this, possibly be a separate app?"

We've seen like 22 different patterns of how people want their authorization system to work.

Naturally when you go out looking and you see a thing that does RBAC, it doesn't fit like your 22 different patterns. It does one of them or similarly from enforcement, I just spoke about it could be integrated everywhere from the UI back to the database.

you sort of look at that high degree of customization, tons of different places to integrate it, it's really, really hard to build a product that can actually do all those things with someone. And so it just hasn't existed previously. So people have only been able to build it themselves.

[00:10:18] John Britton:

What inspired you all to tackle this problem? Why did you go out and build Oso, in the face of it being such a complex problem and it also being something that's so tightly, coupled to my application, that people don't believe that it can be separated out. What inspired you to do it?

[00:10:35] Sam Scott (Oso):

First of all, I love a good, hard problem. Complex problems are the most fun. So I just had the personal, I'm not gonna shy away from a hard problem. The reason that we started the company in the first place was way more broadly just to make security, more fun for developers.

It was something I saw from my in cryptography. It was that it was like a topic, an area that people would often like shy away from and be scared to work on. That was like the main thing that, we were trying to solve when we started Oso.

And authorization, it just came up again and again, as something that people were spending, months, if not years on, on building, reimplementing multiple times. Nobody enjoyed it. Product managers were unhappy because those features that they wanted to get shipped that no one wanted to work on, your engineers didn't want to work on it, it was like painful, it was buggy, it was all these kinds of things. I don't know, we just saw that in inside of all of that, like mess and stuff that people were fighting with was actually what I think is a really, really fun, interesting problem, which is, figuring out how do you want your app to work?

[00:11:26] John Britton:

I definitely had this experience at a company that I worked at in the past where we had an authorization system baked into the app that was organically grown over a period of 10+ years. ,

There were all kinds of random checks throughout the codebase, and it was all very brittle in that if we changed our pricing or if we added a new product level, we had to go through the whole app and find all kinds of stuff and fix it. And there was a major project where they put a team of many engineers for a period of two to three years to redo the whole thing.

It was insanely difficult to change. So I wonder with Oso, are you targeting to go after existing applications and replace their current system, or are you targeting to go, from day one and be included? What's the surface area of a developer who's considering, "okay, I work at this company, we have this problem of authorization and what do I do?"

[00:12:18] Sam Scott (Oso):

We definitely strive to be easy enough that you use us from day one. I think that the challenge is for a lot of startups, started, the logic then it is very simple. You maybe have an admin column and an if statement that says, you if you're an admin, you can do this, otherwise, whatever.

It's kind of hard to beat that level of simplicity. And it's kind of hard to recommend someone, brings in any kind of third party dependency for that.

I think in the future, we'll get there. But today what we typically see is people talk with us when they hit some kind of like an inflection point of complexity. They're moving from, \ static roles, to as you said fine grain resource-specific roles, or they're moving from monolith to multiple services is the other big one where they're oh, we need to pull this out.

You're going through a giant migration then anyway, a great time to be like, maybe I should look at the existing product.

[00:13:01] John Britton:

When you're thinking about what to include what's the boundary? What's in what's out? How do you decide that?

[00:13:06] Sam Scott (Oso):

We, from the beginning strive to be as respectful of your application as possible. There's two different places where that shows itself. So we have the open source library, typically geared towards monoliths and we have Oso Cloud product, which is for those multiple services and they have different trade offs. In, in the library. You know, what we did is that represent your authorization logic using Polar, which is that policy language for authorization logic.

And it has the capability of expressing logic over your existing application data. And so we, have mechanisms where you evaluate the policy and then Oso can basically go and reach into your database and fetch your data.

And so that means when you build your app, you basically can not think about authorization have it as this like separate piece.

multiple services. That's just not possible. You fundamentally need to share data around. We want to, be that place to share that data, to store your core authorization data. That itself gets really messy because there's a very blurry line between application data and authorization data.

We actually have a whole we've written out that sort of talks about when you should put it in Oso Cloud and when you shouldn't. Basically focuses on "are primarily using this for authorization? it a role? Is it permission? Is it something like a group that's mostly used for that?

If so, it goes inside Oso if not stays inside your application we just make sure we build the tooling that makes it as easy as possible to integrate those two things.

[00:14:19] John Britton:

Can you talk a little bit about the developer first run experience? I kinda get this idea of, oh, so it's great for authorization. If I'm a monolith, I can use the library. If I'm doing a microservices distributed thing, I can use the cloud product to have, access to my same kind of logic across my whole infrastructure, if I'm going to implement Oso into my application, one of the things that I think about with Yes-code, is that the first run experience should be really straightforward.

And what's the first run experience like for a developer implementing Oso? maybe they're going through what you said that migration. They're saying, "Hey, we have hit an inflection point, we want to make a change." What do they experience as they go through that path?

[00:14:58] Sam Scott (Oso):

Typically what we see people do in any of these cases is they will, take Oso and they'll use it to implement. One use case, maybe it's something new they couldn't do previously. Maybe it's just something they want to the first thing they want to pull out of that monolith and put into a microservice.

It's like pretty easy to get started with. One nice self-contained use case that you can prove it out. Make that as, as easy as possible. And then kinda like gradually you can move over more and more stuff into Oso.

The first experience doesn't even necessarily start then. We, we kind of wanna show you the sort of the fun of using Oso as like, as soon as possible. So like today, what you can do is you can go to the website, you can go, sign into the kinda like sandbox environment and get like a, environment that you can play around with.

There's no billing or credit card detail, something like that. You just go log straight in. And you have, sandbox instance of Oso Cloud cloud, ready to go. You have, the command interface you can download, you have an auth token, you can go and we give you some guidance of, you can just start putting policies and start putting data into it and try it out.

So you don't even need to integrate with your app to get started, you can just, put, you can write the logic you want to try and do, you can put some example data in it, you can try it out.

Even that we found was , ah, there's kind a lot. You gotta download it. You gotta do some things. We actually just recently embedded that experience into the dashboard itself. So you can just kinda hammer a button and it basically just takes you through those steps of here's a policy, here's some data cool. Everything's working.

Because, we just want people to see that, like, that is what it's gonna be like with Oso. It's, like, you just, you put some data in it. You write some policy, you can now do authorization. Like, it's as simple as that.

[00:16:15] John Britton:

So in terms of trade offs, right? So we talked about, developers often build this themselves, they spend lots of time on it. What are the trade offs? Build versus buy. It doesn't have to specifically be Oso, but obviously your experience you're talking about Oso, but when it comes to authorization, what am I trading off in the positive and in the negative by choosing to buy an outside product or use an open source library or, offload that part, and what am I gaining?

[00:16:38] Sam Scott (Oso):

Historically there hasn't been a good option to buy instead of build. So everyone's done it. And if you look at companies who have done this, some kind of some good engineering blog posts out there from people like Airbnb, Slack, Carter, wrote whole paper on this.

You can see people who've built this in the past and it's been, full team of engineers, like six to eight engineers for like,, years and then full time maintenance in upkeeping it. And so that's, that's the cost of building, if you're VP of engineering or an engineering manager or something out there, and you're like, "oh, what can I do if I had that team to work on something else?" You know, that's, that's the cost of building it yourself.

[00:17:12] John Britton:

That's huge thing.

[00:17:14] Sam Scott (Oso):

That's a pretty big thing, yeah. a lot more fun stuff they could be doing.

[00:17:16] John Britton:

This is something that I think is a pattern among the Yes-code tools that I've seen. It's that existing companies that have high performing engineering teams that are able to invest in building the best internal tools will build systems like Oso for authorization for themselves, or in another problem, domain, they'll build an internal tool or an internal open source project.

And then over time, the engineering community will notice that companies are doing this pattern over and over again. And somebody will spin up a company and turn it into an open source library with a SaaS attached, or they'll turn it into a developer focused product and say, "you too can have the best tool in the industry that if you had an entire engineering team at your company to build it, you would build this."

But not everybody has it. And we all get to benefit because, something like authorization is orthogonal to our business. You and me, could have two different companies that are competitive to each other, but authorization through a third party. And we buy that. We both benefit by not spending the time, the effort, the money on a problem that is not going to directly give either one of us a competitive advantage.

[00:18:20] Sam Scott (Oso):

I have met and spoke with companies who do see a really clean authorization story as one of their core value props, I think is great, giving people really good insight into what you can access and things like that. But it's definitely the, typical thing.

Generally authorizations, like if you did everything right, no one knows it's there kind of situation.

[00:18:37] John Britton:

What's interesting about this too, and, I wonder if this corresponds to anything in your product. I see a lot of SaaS that charge for the enterprise level. The corporate level product based off of permissioning and security and that kind of a feature set. And I wonder if there's a correlation between the companies like you were saying they make that part of their pitch of saying we have a really great authorization story and kind of your ideal customer or the type of people that are using Oso is that can you make a case that will we make it easier to make that enterprise level jump as well?

[00:19:09] Sam Scott (Oso):

We don't need to make that case. It's normally the other way around people come to us because they're like, this has become a sales blocking issue for us. We are talking with blah, blah, Fortune 500 company and they need this feature and we don't want it to take six months because we want to land this deal. Can you help accelerate it?

Like our favorite people to speak to is like high growth startups who are going up market and they see this as being like a thing that unlocks like bigger deals for them.

[00:19:29] John Britton:

So, I love the way that you broke down the product into three core areas: modeling, enforcement, and architecture. As the developer, I really appreciate when I go to documentation, I saw this on your website as well that you presented this way in your docs. But I love when I see something that helped me grok the whole system.

What I want to talk about next is about the primitives that you expose. Within those kind of areas, what are the high level primitives you expose to the developer to utilize for modeling, enforcement, and architecture of the system.

[00:19:56] Sam Scott (Oso):

Yeah. I'm so glad you ran with the structure, everything we think about in those terms.

So for modeling we basically built Polar. It's a, declarative logic based language for expressing authorization logic. So it's something that we've been iterating on for, I don't know, well over two years at this point and basically.

There's a few pieces to that. There's the kind of the lower level piece of it. The, that kind of like logic language that makes it very easy to write composable authorization logic. And then there is a, coming back to the abstractions we spoke about at the beginning, we sort give you some high level abstractions over that, makes it very easy to in sort of different authorization patterns you need without needing to necessarily grok all those low-level details.

Roles. one that like everybody needs, do you have like organization roles? You're a member of an org. Do you have like project level roles where you additionally be an admin on a project and that gives you some extra granularity. Sharing, which is something you often implement with roles.

Like of these under the hood look very simply different. It's just like a relationship that you have with a particular resource, but we've just found that people like to think in terms of like the features or the patterns they're familiar with rather than kind of graph based relational logic and things like that.

[00:21:01] John Britton:

Makes sense.

[00:21:02] Sam Scott (Oso):

So that's modeling. On the enforcement side of this, so we're talking about like, how do you integrate this with your application? This kind of comes to the sort of client SDKs or libraries that we build out. We found that there is fundamentally two, again, like two, kind of low level primitives that you, need in this.

There's the manipulation of the data. So reading and writing data. So this is, telling Oso that a user has a particular role in an organization then reading that back and then there's like the authorization querying that comes around that, is, given all the data, I told you, given all the logic that I've told you can a user read this document?" And so we have a query interface that allows you to ask that kind of question.

Now those themselves are actually pretty, those are like incredibly flexible primitives in that you can query, not just, "can you read this document?" But you can say, "what are all the documents you can read?" You can say, "what are all the things you can do on this document?" You say, "what are all the users that have to read this document?" can compose all the different kinds of, authorization questions you might want to ask.

[00:22:00] John Britton:

So, you're not forcing them into one way of approaching the problem. You can say, you're rendering a page. What actions can this user do? Now you have a list of actions.

Not for each action you might want to do on the page. You have a conditional statement.

[00:22:11] Sam Scott (Oso):

Precisely, because, that's the thing, so, you need it in all those different places like authorization, the enforcement happens, all those different points. And so yeah, you wanna build that responsive UI that uses that authorization data. If you can get back yet, the user can read, but not delete this document. And you can hide or gray out, the delete button and you've got this like really rich authorization interface.

So, have built in this primitives that gives you that flexibility to ask those different kinds of questions is what powers that.

On the architecture side of things, the sort of the, the primitive, there's a bit of a pattern here, right? The primitive is basically the, the Oso service itself. We've built this to be incredibly performant scalable service that basically, enables us to clone or read-rep through your data many times anywhere around the world. So you can get instant access to authorization sessions. These are like very nice, like self-contained services that we that we built. then basically we give you the, and so that's like the core thing you query and that's like solving that, the architecture problems. And then that sort of has some simple things you can do with it, like create multiple environments that if you want to, test some changes before putting them into production, you can do that inside your dev environment.

If can spin up a new branch and have it have a new environment that goes along with that branch. So you can, show someone the impact of your PR and things like that. And so that's like the piece you get from the sort of the service piece.

[00:23:23] John Britton:

I had a couple of questions.

You built this language called Polar you said it's a declarative, DSL type of language.

Why did you make the decision that there had to be a language here, right? What properties does that give you?

And why is it declarative? Like why did you make those decisions and how does it make the architecture of the system, Oso and the whole service better for the users?

[00:23:45] Sam Scott (Oso):

We could do a whole podcast on just that, just, on just that one point. It's, there's, a lot to it there is, I think the nature of authorization as a problem is very branching, conditional logic, You're in GitHub and you want to know. Do you have, permission to close an issue or something then the reason you might have permission to close an issue is because you might have been the person who opened it, or you might have a role inside of a repository that the issue belongs to, you might have a role in the organization that repository belongs to, and the organization has a default role, which grants you that permission. And it's if this, then this, if this and this, if this, so like that kind of problem is just very well suited to logic languages. That's what they do. It allows you to extract that logic out into really nice, like, reusable components.

[00:24:27] John Britton:

I'd imagine that it being, uh, you know, written in a declarative language also lends itself to the distribution. One of the features you had talked about was that you can run this across multiple different services within your entire infrastructure. So how does the Polar language, you know, encoding of your rules and whatnot lead to that like feature ability.

[00:24:49] Sam Scott (Oso):

Right, exactly. So like by, yeah, by extracting that logic out and having it in a, in, you know, in a policy file in a separate language, it means it's very easy to reason about it separately and have that decoupled from the app, even just in a monolith situation, but yeah, in the multiple services, one, even more importantly that can have, know, that all that shared, you know, logic.

You can have that in one place. And that could power decisions for, you know, any kind of downstream application whether Node or Go or, or whatever they can all, you know, reuse that shareable logic.

[00:25:16] John Britton:

And then on the enforcement and architecture side, I think this kind of spans both of those. Um, you were talking about how you can query, um, kind of the decisions and then how the backend service is like globally replicated and, and all that stuff.

What I wanted to ask you about is, you know, you, you had mentioned it's fast, it's highly reliable, et cetera, et cetera but what helps you, achieve that?

Like, how is it that, you know, that team of six engineers at a medium to large size company built their own system versus you and the team at Oso built a backend infrastructure that's globally, scalable, replicated, et cetera. What are you doing to make that, um, so performant?

[00:25:56] Sam Scott (Oso):

Partially we're learning from what they did. I mean, we have one of the original authors and one of the original engineers, um, the Google project for example, is an advisor of ours. So, know, we we're learning from what the same things they did. Um, the, this sort of the, I think there's like a few, there's a few subtle details on like how we built the, the language and how that evaluates, that, I think makes it easier for us to build things performantly.

Um, Yeah, honestly, I think we're, you know, we're, we're learning from the same things they did. So the interesting thing about authorization, um, it's very, very read heavy, typically like two orders of magnitude more reads than writes because if you think about it like pretty much every request that goes through app is gonna do an authorization check, but how often is it actually going to go and like write new authorization data?

And so, you know, like our approach to that is we sort of have, um, kinda like a single writer, multi reader model, where we just, we make it very, very easy for us to add more readers to this. And our readers are basically these like self-contained services in Rust, so they can be pretty performant.

They use an embedded SQLight database so that we don't even have that additional like network hop.

SQL light when you are purely just doing reads and, um, you know, we can kind of compile our, we basically compile our like authorization logic into very efficient, like flat SQL queries. Those two together is just like, it just they just like sing.

[00:27:17] John Britton:

Are you just putting those SQLite databases in memory too? We just throw all in memory and yeah. If we, and if we need more, we can, you know, we can virtually scale those single instances a lot. Um, you know, we provision these for, you know, one com one company, one organization, we can, you know, virtually scale those up a ton.

[00:27:33] Sam Scott (Oso):

We can horizontally scale them a lot. Um, and we haven't even got to the point yet, but you know, these, these kinds of problems are pretty easily like shardable as well. So if, you know, you know, we get to a point where a company has, you know, there tens of thousands of companies that they are serving, they could shard by a customer and, you know, you've just given yourself an extra, you know, dimension of scalability.

Um, but you know, again, none of this is new. Like this is, this is the same kind of stuff that Google did with Zanzabar.

[00:27:59] John Britton:

What's really interesting about the way you talk about this stuff. It's like if I'm a, a user of Oso and I don't have that engineering team, um, that's building this whole system, it's almost like, you know, the crew over at Oso are that engineering team doing all of this really cool stuff. And this conversation we're having is kind of like, you know, me feeling like I'm walking down the hall, talking to the engineering team that works on auth and hearing all about all the cool stuff they're doing. So I really love this.

[00:28:23] Sam Scott (Oso):

I'm so glad you said that, I mean, that's how we think of ourselves. Like, I, we just wanna be that extension of your engineering team. And that's how we treat it a lot. It's like, when you, you know, if you, when you come and work with us, you know, we'll do, I will do actually, you know, like pairing sessions with them, figuring out what model they want, you know, out how to get things working like we are, you know, we're there for, to help you get it working.

[00:28:41] John Britton:

You made a comment about authorization rights, being much lower magnitude. And I had a question about that because I can kind of think of two types of rights to the authorization system. One is writing, for example, a member of an org has the permission to read any issue in the org let's say, or something like that, where it's not about any one particular user it's about, like, the structure of my app and the resources within my app. and then there's for example, a different kind of right. Which is like John joined the team. Right? Do you have a better way to talk about that? Is there a specific way I should be thinking about that?

[00:29:17] Sam Scott (Oso):

You nailed it. That is the right way to think of it. We just call that logic and data. That is the separation. So the, abstract logic you just described would be in the, it would be in your policy code. So typical thing for teams, what you'll say, um, the logic would say, you know, a, write a sort of a has role rule. You'd say a user has a role, some role on a organization, you know, is member "user team" and has role "team role" on the org. Like that's literally the three lines of code you'd, write in, in polar.

the data there, you would write it into Oso by saying, you know, like Oso tell "is member, John, Eng", like, and, and that like, so that like "is member" is the data and that's exactly what the logic's written over. And so those two things are like fully just in sync.

[00:30:05] John Britton:

cool. Um, so last thing I wanted to ask you about like kind of primitives and all of this stuff is this is really awesome design. Um, were there any experiences in your time as an engineer or, um, you know, within the team that really led you to this design that, that in inspired, you know, this path or is it like you were saying before, you know, kind of tried and true and we're making it broadly available?

[00:30:31] Sam Scott (Oso):

Uh, no, this has been a long, this has been a long path.

The the Polar piece has been a long, long path on, on trying to get it right. We hit on the logic programming piece of it, when an engineer on the team basically as like a little weekend project came back and was like, Hey, I think a Prolog would be a good fit for this and did a little POC of, of like how you'd represent this logic as prologue. And we're like, oh, that's that? That's awesome. We should like do that.

[00:30:50] John Britton:

So is Polar a Prolog?

[00:30:51] Sam Scott (Oso):

Currently, but it's morphing a lot. So it's actually, tending more towards a, um, a thing called miniKanren, which, this is like one of the the big lessons.

So I I'll try and give like the, the cliff notes, the high-level version. Right. So, you know, we started out with Prologue, you know, Prologue is built to be in a fully general purpose, logic program language that you can write, know, and what's like really good at, for example, is writing DSLs in Prologue. That's like how powerful it is. You can write web servers in Prologue, incredibly powerful and that was something that was, was kinda like too powerful for our needs. And it like introduced a lot of complexity for us on like building a full, full on language can do anything.

Um, we also had this challenge of like the data versus the logic, which, I, I'd say we got like 90% of the way of just like getting it really right. Which is that you want your logic to be logic and you want your data to stay as data and have that separation. Um, but we had it so that you would often write inside your policy. Very data specific things like how to ref you know, what fields to reference or what to call and things like that.

we sort of ended up getting to this sort of like final state of, of Polar was, um, yeah, based on this idea of miniKanren and there's this great PhD thesis by, it's William Byrd, I really hope I didn't get that wrong, who wrote his PhD thesis on this new idea of miniKanren, which is it's also a logic language, but it's called like a relational, programming language.

the kind of the crux of it is that you, um, the logic that you write expresses relationships between its inputs, which is like exactly what you want authorization to do. It's like, okay, I have a user and I have a repository or whatever, I want to like understand the relationship between them.

What it really cleanly encapsulates is this idea that you can, you know, ask it things like. Um, I have a user. I mean, the thing they're trying to do is read and the thing they're trying to do it to is of type repository, but I don't know exactly what it is get back the relations that need to exist.

Like, oh, okay. Well this needs to be a that belongs to an organization that the user has a member role for and, you know, returns those relationships, you just go and check and that's what we go and query for.

This all like fell into place and felt like we like finally got to like the right exact kind of right balance of what the language needs to do, the sort of the can do, what we need to push down to like SQLight or, or already anything else.

[00:33:09] John Britton:

Was there any kind of use case for the tool that you totally didn't expect that you saw, people using? And can you tell me about it and if it was challenging for you in any way. so

[00:33:19] Sam Scott (Oso):

Oh, there's been plenty.

There is, um, one company that's using us for some like workload orchestration scheduling things. Um, you know, they're using the fact that the, you know, Polar is a pretty powerful logic language to be able to, to represent things like, you know, you, you know, cannot schedule this task. If it's already got five things running or, you know, you can only provision this kind of resource on these kinds of instances and stuff like that.

I wouldn't say that I know full details, but one is definitely a little bit out there. Um, and it, you know, at times it kind of with what I, just what I was just saying, you know, at times it can definitely be challenging to tell people like that, like, know, what you're doing is really outside of what we are kind of intending and so like, you know, your mileage may vary in terms of like how smooth that experience is.

We try to be honest and upfront with like things that we haven't anticipated doing yet.

[00:34:10] John Britton:

I just think about, you know, um, unexpected use cases, uh, of things and there was a product I worked on once that essentially. Developers just started using it as a key value store. And it, it really just like hammered the utilization and it was a huge performance problem for us. So we had to kind of throtle some of that behavior.

Um, so it's always interesting to see what kind of unintended, uh, outcomes you get. Um, the other thing about users is uh, I was wondering if you might be able to tell us either specifically, or kind of like vaguely related to an industry or something, you know, a story of a development team that picked up Oso and solved some problems.

[00:34:46] Sam Scott (Oso):

I think one of my favorite favorite examples was when we worked, we worked with, uh, Intercom. Um, so there's an engineer there. Who's on the sort of security engineering team and they were in the typical situation where was spread all over the application. It was very hard to know like what was happening, where if you had, if you wanted to make a change, you had to go to I don't know, N different places to make it work.

And they had, you know, new features upcoming that they wanted to support. And so they, they were sort of looking at okay, maybe we can consolidate that logic into one place.

But that was like a great experience because they, you know, we, we sort of had like a channel in Slack. We were like keeping on, on top of things and they were like sending us, you know, results of it going through their, you know, full production testing suite where they'd showed, you know, everything's been cut over and you know, here are the metrics of it running.

We paired on some really interesting, gnarly, Ruby bugs. I learned more than I want to know about Ruby enumerators, um, and yeah, ultimately, you know, they had this like PR where they deleted like 4,000 lines of tests that they just didn't need anymore.

[00:35:43] John Britton:

Oh that's awesome that's got to be the best feeling ever, just deleting that much.

[00:35:47] Sam Scott (Oso):

It's like, because the logic is just encapsulated in this like small Polar policy file. So that, that was great. They were happy, we were happy, it really did embody that like principle that we just felt like, you know, an extension of their engineering team that we were just like chatting through slack together and like making things work.

[00:36:03] John Britton:

That story I was telling you before about the company that, that replaced their authorization system, because all the code was all strewn about and we wanted to prevent regressions, One of my coworkers created a library, for doing AB testing of code paths.

So essentialy what you would do would do is you'd have the old auth logic and the new auth logic, and you'd deploy that to production in two branches and you'd have the control and the experiment. And the control, which was the original code, is what would be used to make any decisions. And the experiment code would also be executed and the two results would be compared and sent to effectively like an analytics backend.

And over the course of those years, the percentage of disagreements between the control and the experimental code had to go to zero before we could shift things over and then using like a feature flag, we essentially said, don't use the control code anymore, use the experimental code because it all agrees all the time, but it was so irregular and so unpredictable that the only way to be confident was to like, literally just run it in production for years.

What do you wish, Oso had in terms of features or, or components that is not quite there yet? What are you planning on adding to the product in the coming months?

[00:37:11] Sam Scott (Oso):

You know, If I had to summarize the current state of, of Oso and Oso Cloud, I think we've worked most on those low level primitives. I think we've got those to a point where they're really solid.

I think there's a lot I'm excited do terms of the high level abstractions on top. you know, in the, you know, for the modeling, I think, you know, making sure that we can easily represent all 22 patterns and have them working.

I think the opportunities for the stuff we can build on top of this are kind of limitless. Some of the things that we've like kind of kicked the tires on is, you know, having a really nice visualizer for your policy. So you can kind of see it represented graphically instead of having to look through the, the codes.

I think there's a lot of great tooling we can build around this where, um, you can probably interact with your policy, like inside, inside the dashboard, you can, um, stuff like, think there's a lot to, a lot of great stuff that we could be inspired by from companies like PlanetScale, have like really beautiful UIs and flows around creating those like branches of their database and like running tests against it and running migrations and schema changes or know, they've got features like the rewind feature, where if like you do a migration, you wanna rewind it, that you won't like lose any data.

like all of those kinds of things, like you can build tooling, you can build around developer experience stuff, you can build around, when you have like the right primitives in place, that's, that's like what I'm, can't wait to, like for us to come build and to, and, and to have, and that's like on the roadmap.

[00:38:33] John Britton:

For the high level abstractions, I think for all of the kind of Yes-code style tools that I've looked at, you know, the primitives are kind of the bread and butter. Every developer wants high level primitives that they can remix, compose. However they want to fit, you know, any of those 22 different ways that you've observed people wanting to do things, but then I'm a developer who's really lazy, also efficient.

I just want to pick something up off the shelf that does, you know, team based authorization. And so the idea that, you know, you want to have these high level abstractions is like totally in line with what I think people want, um, I would love to be able to say on day one, I'm building a product, It's going to have a teams feature or an orgs feature.

How many, how many SaaS products go through the evolution of like, there's a, a single user and then there's the org user. Right. And they have to do the same migration and all this stuff. And if you could just click a button and say, add, add orgs to my business and have all the permissioning and stuff work automatically or relatively quickly, I think that'd be super powerful.

[00:39:32] Sam Scott (Oso):

Laziness, right? It's one of the three great virtues of programmers. Like, seriously,. That's that's why I, started programming the first place. Because I was lazy.

[00:39:39] John Britton:

In closing, are there any tools or products or open source libraries or things that you've seen recently that you are just really in love with that you think anybody who might be interested in Yes-code, would also find interesting.

I'm always looking for new things to check out and I'm sure, others are as well.

[00:39:55] Sam Scott (Oso):

So I mentioned PlanetScale already. I think they're definitely worth looking at, I, I think they embody Yes-code pretty well. another one that I think is a great developer experience story in the Yes-code style is, is Prisma.

Something that they have put painstaking effort into is the, so the Prisma is Kinda like, a, this I'll do them justice, but you know, it's like a modern ORM, maybe not in a kind of traditional way, but you know, it gives you a way of representing your, you know, they have a DSL for writing your, your schemas.

And then the thing that I think they do beautifully well is they take that database schema and they generate like a type safe TypeScript, uh, like a code generated TypeScript API for it. So that when you're, you know, going and saying, yeah, I wanna query my whatever, query my repositories and filtered by, uh, organization sort by blah.

Like those fields are all going to be type checked because it knows the schema.

[00:40:44] John Britton:

So in your IDE right away, you don't even have to do anything, Oh, that's amazing, I love that.

[00:40:49] Sam Scott (Oso):

I just think that, like that little example there is a, is a, is a really, it's just a great, great example of like the, when you, you know, go all in on developer experience, the kinds of things you can do. I, I would love to do something like that in Oso.

[00:41:03] John Britton:

Yeah. I love, I love things that make the, you know, when I'm sitting in my editor writing code, Making it so that I don't have to do, you know, 15 steps to get to how to test this thing. Um, just knowing from writing the code that it's gonna work or not is, is so valuable.

It's, like, even though it's only like a, you know, 15 seconds saved or whatever, as a developer, that just feels like a huge productivity boost when you don't have to do it, hundreds of times per day.

[00:41:28] Sam Scott (Oso):

Right. It's that loop? It's the hot loop, right? You're optimizing. It's the, you do that 15 seconds, thousand times a day it

[00:41:34] John Britton:

If folks want to get started with Oso, give it a try. Where should they go?

[00:41:38] Sam Scott (Oso):

Pretty much everything you want to find, you can find through the website, "osohq.com."

Given everything we spoke about today, and I think if the kinds of people who are listening to this, and if they're like nodding vigorously, I would say, just drop me an email directly.

"[email protected]", you can just hit me up and if you want to chat about any of this stuff available.

if you'd rather do it, the sort of via computer you can, through our website, we have like a Slack community you can find, email us, you can Intercom us. You can do any of them.

[00:42:04] John Britton:

Excellent. Well, that's very generous of you to offer to talk to people directly.

I really appreciate you coming on. This has been an awesome conversation, I've really loved it, and I look forward to speaking with you some more in the future.

[00:42:15] Sam Scott (Oso):

I appreciate you having me. This is, yeah, this was a lot of fun for me too.

[00:42:18] John Britton:

To find out more and stay in the loop with Yes-code, head to yescode.org.