Ben:
Hey, everyone. Welcome to PodRocket. Today, I'm here with Sam Scott who's the co-founder and CTO at Oso. Is that how you pronounce it? Oso, is that like as bear in Spanish?

Sam Scott:
Exactly, yeah. Spanish for bear. Exactly.

Ben:
Awesome. I remember from my sixth grade Spanish class, the animal unit, so that came to mind. And I guess your logo is a bear, so I probably should have as well.

Sam Scott:
Exactly.

Ben:
So yeah, excited to learn about what you're building. Can you give us a quick overview to what is Oso?

Sam Scott:
Yeah, sure. So first of all, thanks for having me on. It's good be here. So basically, the goal of Oso is to reduce the time developers spend on building authorization in their applications. And so I think most people interact with these features as users, as the way that you assign different permissions inside an application, the things that you're allowed to interact with, maybe you think about something like Google docs, where you can maybe share different files with people, you can give them different levels of access, viewer, editor, commenter, things like that. And basically, this is work that pretty much every single development team in the planet is just doing themselves from scratch, normally doing 3, 4, 5 different iterations, spending anywhere from a few months, to multiple years, to ongoing. And basically, the goal of Oso is to reduce that time, so people aren't spending time on authorization, and instead get to focus on their core app.

Ben:
Got it. And so we've spoken on the podcast before to a bunch of companies attacking off from different directions. We've spoken with Stytch, and I think we spoke to Auth0, we spoke to Clerk.dev, so we've spoken to a bunch of those. How does Oso compare to those types of companies and products?

Sam Scott:
Great question. So yeah, auth, as it's often all lumped together, is a ginormous space covering everything from... There's authentication and authorization, two big separate concepts, but also, there is multiple different places where you even care about doing authentication, authorization. There is building it into your product, your app, if you're on a product team, building it into your app, and then there's the pieces you interact with in AWS to get access to your infrastructure. There's things that happen in side internal corporate, so it is a giant, giant space. There's multiple different companies attacking different parts of this. And I think historically, I think a lot of people have been focused on the authentication side of things. This is more around basically, logging into applications, identity. It's everything from signing in with username and passwords, doing multifactor authentication, integrating with single sign on solutions, when you can log in with your Google account, stuff like that. All of that kind of thing covered in the authentication side of the world. So when you think about something like an Okta or an Auth0, that is typically their wheelhouse, user identity, user management, logins.

Sam Scott:
There are some... I think authentication's a space that's still relatively new, I would say. So you do see new startups coming along, like Clerk, who I think they're... One thing I love about them is they're taking a very developer centric view of the world, like, how do we make this as easy as possible for developers to use, to integrate with their apps, to produce a really great product experience? And so there's a lot going on in that that area. Authorization is, I think, in many ways, an even younger space. There aren't really any existing dominant vendors who've been around for a while doing this. We could maybe talk about why that is later, but ultimately, authorization is, now that you know who somebody is, you've logged them in, you've authenticated them, I know that I'm Sam or whoever that is, deciding what the person is allowed to do, so that's the core of authorizations. Now I know who you are, what can you do inside the application? Can you see this document? Are you allowed to edit on it? Are you allowed to create such and such a thing? Can you invite other users to it? All of those questions about, what are you allowed to do inside the app?

Ben:
Got it. So basically, that distinction between authentication, which is figuring out who the person is, how do they securely log in? But then once you know who they are, what can they do? What can they view? What can they edit? All those kind of things. So, prior to Oso existing, would you say the majority of companies just build their own system from scratch? Or were there other tools on the market, or frameworks, or products that helped there?

Sam Scott:
Yeah. I would say it's largely do it yourself. I think most web frameworks, their ecosystems will have packages that exist in the space to roll something yourself inside the app. I think the Rails ecosystem, for example, obviously Rails been around a long time, has a very, very healthy ecosystem, so there's some packages there, things like CanCan, or the successor, CanCanCan, or Pundit, for example, which are packages explicitly for Rails that can help you build something inside your Rails app for authorization. But I think those tend to be... For the record, I think those are both great packages, for example, but they tend to focus, I'd say, more on the simpler side of the use cases. They still require you to do quite a lot of work yourself on top of it. And there's not many just out of the box, everything included packages that would just handle everything.

Ben:
Got it. And so what does it look like to use Oso? So when you get started, how does it integrate? What types of apps does it integrate with? And then walk me through how it works.

Sam Scott:
Yeah, so we have a cloud offering called Oso Cloud. It's basically your typical SaaS product that gives you a couple of things. There's an API for configuring your authorization logic, which you do through writing your authorization policies, so where you describe who can do what. You have simple APIs for basically managing your authorization data. So if I want to add teams to my product, then the kind of things I need to do, I need to have the data modeling for teams, I need to have the authorization logic, I need to build out the APIs to assign user to teams, and so on, and so on. All of that, you get through Oso Cloud. So basically, the workflow for doing that is you write your policy logic to say, "I want teams." And we already have a baked in data model that can just handle that kind of thing for you. So all you really need to do is just add a couple lines to your app to call the API to, say, add such and such to a team. Or when I want to check, can someone do something? It's just going to use that extra data model of teams to make that decision. And so really, it's just a case of configure with policies, integrate the APIs, you're good to go. Add any authorization features you need.

Ben:
And this is maybe a naive question, but why is Oso a SaaS product, versus typically, this would just live in code as rules in your backend that determine for a given resource what users can and can't do, you'd have teams in your database. Why build this as a separate SaaS product that interfaces with your application via API?

Sam Scott:
Yeah, that's a great question. So we actually didn't start out with the cloud product. So we actually started with the Oso Library, which isn't a fully open source product, and it's a library that you just integrate into your application. Basically, what we found is that the Oso Library is actually pretty good for monolithic use cases. So again, thinking back to that, you have a single Rails app, or you have maybe a single Python, Django application, something like that. The Oso Library there is actually really nice fit just to integrate into your application to add... Don't add any extra infrastructure or dependencies on third parties, and you're ready to go. You get mostly the same experience with the cloud product. You still get to write authorization logic as policies, but it integrates with your local data. So what we found though, is that, I think, more and more, we see a lot of people are operating in microservice environments, or bare minimum multiple service, service orientated architectures.

Sam Scott:
And we found that a lot of people were, even using the library product, they were investing a lot of time into the data modeling piece, figuring out the right schemas. Coming back to that teams example, it's like, you want to add teams to your app, you need to figure out, okay, what's the data model look like? Do I do my database migration? And how do I think about that? How do I integrate all these kinds of things? And so basically, through that experience of the Oso Library, we found that there was more we could basically do for our users if we just gave them a set of APIs, both in terms of doing less thinking about the data modeling, much easier for us to make this highly performant and scalable stuff like that, and then for people in those multiple service or microservice architectures, this was just becoming work that they were themselves doing otherwise. Everyone we were speaking to was building authorization microservices with Oso Library already, and we just felt we could save them that work.

Ben:
And tell me a bit more about how you actually define your policies. Is it configuration as... Do you write code? Or is it EML or JSON? Or is it a Gooey? How does that work?

Sam Scott:
Yeah, so we actually developed the Polar language, which is a language... It's a policy language for writing authorization logic. It has its roots in logic based programming, so it was inspired by things like Prolog, and Datalog, and more recently, something called miniKanren, as ways that we'd allow people to express authorization logic. And this has been, forever, a really interesting part of the development process for us, which is that authorization logic, it's so inherently conditionally brilliant logic, lots of branching logic. You can see a document if you belong to a group and the group as a membership of the folder that the file is in. And it's like all these if this, then this, otherwise, this.

Sam Scott:
All that branching logic just means that having a declarative logic based language is a really nice paradigm fit for it. And so that's at the center of Oso policies is this Polar language. Got some incredibly strong, primitive, powerful premises for building logic. And basically, though, what we've done on top of that, because we don't want people to have to become experts in the language we have to write stuff, we provide these building blocks on top of it. So for things like... Or if you just want to add groups to your application, you want to add something like teams, we want it just to be the case of you say, "Give me teams," and then we say, "Sure. Here you go." And so you get that... You have the power under the hood, but we give you this high level abstractions.

Ben:
Got it. And did you... When you decided to go with the DSL approach, creating this new language Polar, was it just that you didn't see a way to do it using existing tools? Like you mentioned some of those languages, like Prolog, or even doing it more in a declarative language? A popular declarative language, you just didn't think it would be as clean as crafting it yourself?

Sam Scott:
Yeah. Yeah. It's a great question. So funny enough, the 0.01 of Polar was actually just a Python library itself. It was pure Python, and we just exposed APIs for it, but we found that the things you had to do just didn't even look like Python anymore. You're constructing these weird objects and it was effectively a DSL in itself, so that's what pushed us towards a DSL approach. I think the... We did look at, should we just use an existing Prolog implementation? I think one of thing that Prolog... One of the things I find really interesting about Prolog is it's conceptually very different to how we think about normal programming languages in that it actually has a very simple... The core logic of it is quite simple. And in some ways, the power of it is it's just a conceptually simple model that is really good for building DSLs, rather than it being like...

Sam Scott:
The language itself is something that you really want to necessarily just use as is, in some ways it's built to be good for building DSLs. And so when we were just looking at the kinds of things we wanted to do to have... One of the things we were keen on having was a static type system, authorization very centric around, what data am I protecting? I'm protecting a document. We wanted to have type system be a core part of it. We knew that it'd be important to integrate with application data. All of these aspects just meant the... It made sense for us to build a language that could just semantically have those as core concepts, rather than it be something that was artificially tacked on after the fact. And so it is the mix of those two things. Prolog itself is well suited to building your own thing on top of it, and then we had specific things we wanted to have the language.

Ben:
And you bring up a good point there about how application data is central to writing your policies. And you can imagine, if you have your typical enterprise SaaS, role based access control, there might be different parts of your application, the different users at different roles, and they can do different things, and you need to have that state from your application database as inputs to your rules. So how does that work? Is it since everything is interfacing through API, you just send over, in your API requests, the data that we relevant and then the rule processes that? Is that way the right way to think about it?

Sam Scott:
Maybe part of it. So for cloud, actually, the focus is on us being your authorization service. If you were to build this yourself, what is all the functionalities you expect it to do? And so when I talk about... When you think about things like, yeah, role based access, or assigning users to groups and accessing based on that, sharing things with people, all of that data is managed by your service because that is its core responsibility is to give you that functionality. So a lot of that authorization data, that will live in Oso Cloud, so when it needs to make an authorization decision, it uses that. But oftentimes, the piece that you said is true, the scenario you described is also useful for when you have Excel inputs coming in. A very common use case is someone wants to bring their Google groups with them, so this would be the customers of our users. So you're building your products, you want someone to be able to gain access to projects based on the Google group they belong to, so that will come from your identity provider, and you'll send that along with the request to Oso. And then we can maybe translate that to your domain specific logic. Like, "Oh, okay. So yeah, this group becomes this role and this role can do these things."

Ben:
I see. But Oso also has its own data store that stores state on your users, and various permission levels, or what team they're on, or are they an admin or a regular person, those kinds of things.

Sam Scott:
Yeah, precisely. Because for a lot of the authorization data, and this is one of the really interesting challenges of it is, fundamentally, that has to be shared across all your microservices. You have a document service, and you have a project service, or whatever it is. Both of those need need to know what role a user has, and so you end up in this situation where it's like, well, do you synchronize the data everywhere? Typically, you'd put it in a service. And we want to be that service, that place that you can put it and interact with it.

Ben:
In terms of the policies and configuration of Oso, what does it look like in terms of testing that, and then also version control for the policies?

Sam Scott:
Yeah. So today, we basically recommend that people take a get up style approach to their policy management. It is just code. Have it and get repo, have your CICD workflows around that. I think in the future, there's possibility that we'd do more policy management, but personally, I'm a fan of everything that's comes with the get ups workflow. It's all the tools that we already know exist around it. And then basically, the things that we do inside Oso Cloud to make it easy to build those workflows, we make it very easy for you to create new environments based on staging environments or per branch testing environments. You can easily fork your existing authorization logic, deploy new policy, test it out, and then when you're ready, merge it maybe to the main branch into production. For people familiar with PlanetScale, for example, I think they're doing something very similar with databases. I think it's a really awesome model, the idea that you can fork your database for easily create a branch, deploy schema change, and then when it's tested and ready, it gets merged into production. There's a lot of great stuff there that we're cribbing some notes off of.

Ben:
So I imagine given the type of product you're building and space you're building in, you've probably had to think a little more in depth about security than the average SaaS startup. Not that the average SaaS startup doesn't care about security, but just as a core infrastructure provider that deals with access, authorization, et cetera. So can you tell us a bit about your overall security posture and any learnings that you've had as you've thought through your security and compliance program?

Sam Scott:
Yeah, absolutely. So I think a lot of it starts with the team. So I, myself, for example, I have a PhD in cryptography, not that's necessary directly relevant to security in SaaS products, but I come from that security world, deeply steeped in a lot of that. We have actually a few members on the team who've run product security at other teams. Like Intercom, for example, they've had that experience of securing SaaS infrastructure. And so where that's led us to is... I think the great thing with security these days is there's quite a lot of low hanging fruit, things you can do that really aren't that hard, but massively increase your security profile. So for example, requiring multifactor on all the core products we use.

Sam Scott:
Actually, somewhat recently, and earlier this year, for example, we made it so that no one just has basic parcel access to your AWS. We're doing it all federated through our G suite accounts, and so all the user access is configured through that. We don't give people just full root access to our production instances. A lot of the stuff comes from internally, so we make sure we ourselves have minimal access to everything we're running. So that's where we are today, is just doing the things that you might do once you start having a full on security team, maybe a series B company thing you might do. We've had people who've seen this story before. They see that the stuff you can do today for quick wins, and we're just trying to do as many of them as we can.

Ben:
So I'm curious to learn a bit more about what the long term future looks like for Oso. So maybe you could start with the next year or so, and then touch a bit on long term vision.

Sam Scott:
Yeah. So I think the next year, you're going to see a lot of stuff coming out from us very quickly. So Oso Cloud, I mentioned a few times. We're still relatively early on. So today, for example, we're in a private beta. So you can go to the Oso website, you can try out the cloud product. We have a sandbox too that you can try out, but for users going to production with it, we do that in more of a hands on way. We'll work with people inside the requirements. So Oso Cloud, pretty early. There's a lot of stuff I'm really excited for us to be doing on that over the next year. So just touching a few of those, I think we spoke around a little bit earlier about the policy logic, and how much coding you need to do, versus how much features you can just drop in. So one of the things I'm excited about, we have, internally, a laundry list of 20 common use cases and patterns that we see people need in authorization, everything from roles, to group-based access, to approval flows, to usage quotas, everything like this.

Sam Scott:
Our goal over the next few months is just to steadily pick them off and have, first of all, docs, so that you can just go, "Oh, cool. That's all I need," but also some more interactive UI features where you can, through the cloud dashboard, just be like, "Yeah, give me groups," you hit a button, and your app now just has that feature. So I think that one's going to be... I think that's going to be really exciting and give people the ability to go in, add a few new features, see what the policy impact would look like, and stuff like that. So I think that would be a good one. And I think from there, a lot of this is just going to be about giving people the confidence that the authorization is just working. There's nothing left for them to do. So today, we have things like request logs. You can see the things that have been going through the service, but we want to be able to give people more and more insight into maybe, here are the parts of your policy that are currently being used.

Sam Scott:
Maybe here are parts that aren't. Suggesting possible ways you can clean up and re-fax your policy. You have some... Maybe built a feature, you added some logic, but no one's been using it in months, so it suggested that you can remove that from your policy. And I think what all this does, it just gives you this, as I said, this peace of mind that your authorization is just there, it's working, it's doing everything it needs you to, and we're the ones, on a day to day basis, thinking about, is everything working like it should? So I think that's a big piece. Yeah, so that's a good chunk of it. I think the other side of things, again, internally, our company goal is that Oso is successful when developers are spending about a 10th of the time on authorization. Today, we're starting with the modeling piece. Everything you need to do through the authorization logic and the data models, but I think what we're going to do more and more of is what we think of as the enforcement side.

Sam Scott:
It's having good integrations in API gateways, to maybe for all microservices, you just have a single place to integrate. It's having integrations for frameworks, like Ruby on Rails or maybe something like Express, so that when it comes to the case of adding authorization to your app, that becomes a matter of a couple lines of code and maybe a few minutes. All of this just in service of reducing the time people spend on authorization. So that's some of the... Yeah, that's some of the pieces I'm excited about over the next year. I think in the longer, longer term, I mentioned this very briefly at the beginning, in the auth space, there's authentication authorization, but then there's also multiple different places where you would think about doing authorization, and so I would just love to see people using Oso across all forms of different authorization. So you need access to infrastructure, that it becomes super easy just to integrate Oso there, that you...

Sam Scott:
You maybe even... One request we hear a lot, this may be in the future roadmap, is if people could use Oso instead of, say, AWS IAM, which historically, has always been hard to use. And for a little bit of fun one day, I did do a little Polar to IAM converter thing, so you could write Polar policies in and get IAM policies out. We would love to just be lingua franca everywhere for authorization logic. Yeah. And then finally, in the even longer term, something I'm personally excited about because it was raised related to research. I did it in my PhD. So one of the projects I worked on there was doing formal protocol analysis of TLS, how we scale the internet the internet. And we used that to successfully find some pretty big vulnerabilities in the TS 1.3 drafts and things like that, so I've seen the real world power of that. It's something... Doing that formal verification, it's something that has been used at pretty great success at AWS.

Sam Scott:
They have a thing called Clover for analyzing if a S3 bucket is public. So yeah, in the longer, longer term, you could even imagine us providing not just that declarative policy, but even rigorous proofs around what is and isn't possible inside your policy, making sure that there cannot be any single logical bug inside of it, and things like that. It's a pretty... Yeah, it's a pretty broad set of things that we could potentially get to cover. Just ground things, again, though, where we are today, again, is really focusing on helping application developers spending less time with that inside their apps. And so I think, again, more of the shorter term things, I think, we'll work on is if you need to implement an approval flow system into your app, making sure that we can give you all the tools to make that happen as quickly as possible.

Ben:
Well, Sam, thanks so much for joining us. It's been great learning about Oso. For anyone who wants to check it out. It's just Osohq.com, so you can go to the website. And any other resources that you'd recommend if people want to learn?

Sam Scott:
I think you'll find all the best links linked from there.

Ben:
Great. Well, thanks again, Sam.

Sam Scott:
Thanks very much having me.

Speaker 3:
Thanks for listening to PodRocket. You can find us @Podrocketpod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcast. Thanks.