On this episode we chat with Sam Scott, co-founder and CTO of Oso, which is trying to make security simpler for developers. Pull it from your favorite package manager, add it to your application, and start enforcing authorization over API requests, data fetches, and UI components. The team hopes that they can create a foundational technology – a policy engine and language – that sets them up to solve a much broader array of problems for developers in the future.
You can learn more about Sam on his LinkedIn here. You can find him on Twitter here.
Learn more about Oso, check out the code, and join their Slack community here.
Our lifeboat badge winner of the week is Evgeny Lisin, who answered the question: How to find UIWebView in Project and replace it with WKWebView?
Sam Scott The particularly challenging piece with authorization is, it's really hard to pull it out of the application authentications often done is is kind of like front door check, like, you logged in, you have your credentials, whatever it is, and from there you're good.
Ben Popper They were pushing email magic links and password lists and, right, getting you in the front door, knowing who you are, the stuff they're trying to handle with the SDK API for developers.
SS And it's great. You can make that experience like really slick. So it's just like for the developer, they just kind, you do get that sort of Stripe like experience. Authorization is a tricky one because like very interwoven with the app itself. And we can probably go into that later. But that's, that's kind of like some of the challenges we're solving as around that piece.
[intro music]
BP Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk about all things software and technology. Today, we are joined by my frequent co-host, Ryan Donovan. Hey, Ryan.
Ryan Donovan Hey Ben, how you doing today?
BP Good. Thank you. You're editing currently my piece on the metaverse, you're looking for a little more profundity? I just wanted to get out a few, you know, musings. I wanted to do like a Monday musings, let people chew it over. You know, I'm not bringing the big insights. I'm bringing in the casual observations.
RD Yeah, it's definitely a new idea. You know, get people talking.
BP It's an old idea. But I'm new to it. That's the problem. So today, we have a great guest joining us. We have Sam Scott from Oso. Sam, welcome to the program. Sam, welcome to the program.
SS Hey, thanks for having me. You've lost me already with your metaverse thing. So we're off to a good start.
BP Good!
RD That's how new it is.
BP My premise is that you're living in it. You just don't know it. You're on you're on the road to the metaverse whether or not you know it. But Sam, tell us a little about yourself. Who are you? And what is Oso?
SS So I'm Sam. I'm the CTO and co-founder of Oso. And so we're start up who, you know, as a mission. We're trying to make security more accessible for developers. That's kind of our bottom line. But more specifically, we've built a product that helps developers with authorization.
BP Gotcha.
RD Can you tell me the difference between authorization and authentication? I've written API docs and I always get it confused.
SS Yeah, for APIs is particularly hard because there's this like authorization header that stating authentication is horrendous. Generally, you know, people groups in this earth and kind of handwave which one they're talking about. It's just, you know, it's kind of fine. But yeah, so authentication, it's all around, you know, identity, like, you know, who are you? The classic, you know, you go to whatever website and you log in username and password. That's, that's the authentication piece. Authorization typically happens afterwards. So now that I know who you are, what are you allowed to do? You know, what date can you see? What actions can you take? That kind of thing.
BP So tell me if you're familiar with this company, if you're not, we don't have to go down this road. But recently, I was talking with the co founder and CTO of a company called Stytch and it sounded like they had a similar premise, but for authentication, which is like, this is too hard for developers these days, people want to get their projects up and running. They want to make it easy for users to come and be safe. So we'll be the Stripe of authentication. Are you in a similar role, but for authorization, and then we tease those things apart?
SS Yeah, I think in a sense. And I'm first of all, I love the focus a lot of companies are taking on security for developers. It seems like is rising a lot. The particularly challenging piece with authorization is, it's really hard to pull it out of the application authentications often done is is kind of like front door check, like, you logged in, you have your credentials, whatever it is, and from there you're good.
BP They were pushing email magic links and password lists and, right, getting you in the front door, knowing who you are, the stuff they're trying to handle with the SDK API for developers.
SS And it's great. You can make that experience like really slick. So it's just like for the developer, they just kind, you do get that sort of Stripe like experience. Authorization is a tricky one because like very interwoven with the app itself. And we can probably go into that later. But that's, that's kind of like some of the challenges we're solving as around that piece.
BP Yeah, I mean, break it down for us. Like, like we said, you know, some of what happens when you get to the front door can be done almost without interacting too heavily with what's inside of the app itself. For you, talk us through a little bit of, yeah, sort of the mechanics, because it sounds like right, it's more like knowing what's inside of this service, and what role or responsibility does this user have within our, within our walled garden, within our domain? Therefore, we know what they are allowed to touch or read or write or not?
SS Yeah, exactly. So you just mentioned, you know, roles, responsibilities, right. So there's, you know, this concept of role based access control, it's one that, you know, almost every enterprise or you know, business app is going to is going to use, it's, it's where you decide who can do what based on the role they have. And I like a very simple level, it often breaks down as as just like an admin or a member. You know, if you're not an admin, you can invite other users, you can, you know, maybe modify the organization settings and things like that. And, you know, members have the, you know, regular streamline access to the app, but like within that, you know, we're talking about probably a multi tenant app, right? So you have users belong to specific organizations, they can only do things for like that one organization. Right? So even just at this basic level, right, we're already seeing what you can do depends on the organization, you belong to the role you have in that org. And then, you know, maybe the thing you're trying to access, does that belong to the same org or not? You're already kind of getting into this difficulty of just trying to describe who can do what, very much based on this kind of application data and the, you know, the modeling and data model you have in your app.
RD Yeah, I think security is super important. A lot of this authorization happens at the API call level, right?
SS I mean, it depends. I mean, I think you sort of end up with like, various different layers. And it's sometimes it's not always obvious, like which layer you've actually even done the authorization app. So like at the at the API level, you tend to get some of those kind of broad checks, where it's like, you know, have you have you logged in at all, what kind of user Are you maybe dictates what kind of endpoints you can be hitting. But as you sort of get into more, more complicated applications, you know, we use like GitHub as an example of one which has got like really compelling authorization stories. You know, where you need to start understanding, like, if you are the person who created this issue, then you're the one who can close it, you can also close it if you're an admin of the repository. And at that point, it really starts getting like deep into the like, app code into the controllers inside the business logic. There's really no other way to do it when you need to go that granular.
BP Right. Like, if I were to head over to your webpage and see this, it says batteries included authorization, like what are you trying to convey there? Because I think I understand from what you said at first, right, this is a little bit more complex, we need to like, not just give you something simple, you can use as a front door, but get inside, understand your business logic, understand, you know, the pathways and statuses and roles and responsibilities you've defined. Like, when you say batteries included, does that mean that it's powerful on its own, but easy to customize for the client? What are you trying to imply there?
SS Yeah, there's kind of two parts of it, right. So like, the kind of low level under the surface, you know, what also is there's, you know, there's a policy engine underneath that. It's this kind of, like, very powerful, flexible tool for expressing who can do what in your app. The batteries included pieces, specifically, you know, we have been working in this space for like, three-ish years at this point. So we've seen a bunch of those patterns already. So instead of just saying, you know, here's a, here's a powerful tool gogo builds, we're gonna include those batteries and be like, okay, we'll give you those best practices built in, like, here's, here's how you should think about structuring that authorization logic. And, you know, here is a, you know, an SDK that you can add your app is going to encode some of these best practices of, you know, what errors to return, and you know, what to do with authorization and things like that.
BP Gotcha. Gotcha.
RD Yeah, I think I've seen a lot of authorization systems use OAuth2. And that's always complex. I've worked with developers that didn't quite fully understand it themselves. Right. But I think Google came out with an internal authorization system, right? Can you talk about that?
SS Yeah, yeah, that's right. So this was back in about 2019, Google released this paper, on a system, they have this internal system they have called Zanzibar. And I think they described it as like a liberal scale, consistent authorization system, something like that. And I think they worked on this from, you know, 2013, or something like that. And it's, it's basically how Google does authorization at Google, across like all of their services, right, from Google dogs to YouTube, things like that. And there's a couple of really interesting parts of Google Zanzibar, it's like, number one is they have a, they sort of come up with this authorization model called like relationship based access control. You know, it's a more general version of roles, in a sense, and it's, you know, you describe, sort of like I was doing earlier, what people can do based on these, like relationships between data. So you know, this repository belongs to this org, if you have a role on this org, then you have this role in the repository, and you sort of almost like, trace through those edges of a graph.
RD Right! Because, you know, we use Google Docs, and you can have Google Docs and so many organizations, right? And you can have granular permissions on each document.
SS Or you can invite someone to a folder, and then they have access to the sub folders and subfolders and sub folders. And then the files inside this sub folders. And, you know, the permissions kind of cascade down, down like that. So there's like one interesting part, really interesting parts, just that model. And then I think the second interesting part is that they made that work for for Google scales, which I think is something like, you know, hand this system handles like 10 million client queries per second. That's like 10 million authorization searches per second.
BP So I guess, yeah, like on your site. You mentioned a couple of clients here. Some of them I'm familiar, like, we use Intercom here at Stack Overflow. But I guess, you know, when you have these examples, is it possible for you to talk us through like, what they were struggling with? Or like, where the pain points in the friction where and how you helped out, you know, an Intercom or a Wayfair?
SS Yeah, so a lot of what people are looking for, is, I think in part a sort of impart a mental model. In part, just just a sort of a certain amount of consistency or someone else who's just like done this thinking around, you know, where the sharp edges are authorization or like, what is the right, you know, interface to expose to developers for authorization. Authorization is typically something that people have just sort of ad hoc built themselves from scratch internally, and they have kind of various different flows. And, you know, they haven't anticipated all their future needs right at the beginning, right, like, it's completely understandable. So what I think what ends up happening is, at a larger company, you have these systems that have been refracted a number of times, and no one really understands quite how they work, no one can really see the full picture of it, because the code is kind of split up in, you know, all throughout the codebase. And so kind of one of the things you can do with Oso \is kind of consolidate that into, like one place. So you just, you just have your authorization logic and like Oso policies, and then your app, you know, in your business logic, your app is just calling out Oso, this thing is allowed or not. And that means like, you can just like in that, in that movement. Now you can see everything in one place, it's something that thing is easier for people to wrap their heads around, it's a bit more concise. So that's kind of like often step one. And then step two is then often, you know, extending it to do something more powerful. Maybe they want to do some more fine grained things with like attribute based access control and things like that.
RD On the actual API calls, are you spitting out tokens for people to use?
SS No. So we're entirely on the back end piece right now. So you know, the general flow or assumption is, you know, user comes, they authenticate, they log in, in your, you know, app, you're probably going to fetch like a user object or user model. You pass that through, oh, so when you need to make an authorization decision, can this user do this thing to this resource? That's like the core inputs that we take to make that decision. On the on the UI side, though, there is a there's an interesting sort of, again, place where you know, this authorization tends to kind of sprawl out into the app. One of the really common problems that we've heard from people is, how do you make your UI sort of authorization aware? Right, like, if the user is not allowed to delete this thing, maybe we shouldn't show them the delete button, because that's just an annoying experience. They hit delete, and they get like an error pop up or something. And so, you know, how can you like make that information available to the front end so that you can render things a bit nicer?
RD Yeah, I think there's a lot of move towards stateless apps. So having that information stored somewhere is a lot harder if you want to be completely stateless.
SS Right? You're not just rendering it from the back end and filtering out like just in time or something, maybe. So that's an interesting one. And it's sort of one of the one of the pieces of flexibility we have in the in the product is kind of let you return like the list of permissions a user has for a particular object. So you can do that filtering on the front end.
BP I love that. So not just making it more secure, but less frustrating for people who don't need to trip themselves up with authorizations they don't have.
SS Oh, yeah, I mean, user experience is like my number one drive for authorization. Honestly, it's everything, everything we do, we talk about that.
RD I feel like security is both complicated and boring. I feel like a lot of people don't really want to do deal with it.
SS I mean, I find that fascinating, because, like, aren't the complicated things that are the most fun? [Sam & Ryan laugh]
RD I mean, you have a PhD in Cryptography. So, I mean.
SS Yeah, that's true. There's a lot of tedium. And there's a lot of frustration around some of these, like more complicated things, especially with security where it's, it's like unfun complexity. I know you mentioned OAuth. And I mean, my eyes still glaze over when I'm trying to look at like the eight different OAuth flows I need to pick from. [Sam laughs] Please, why!
BP Yeah, I was having a pretty interesting conversation this morning, which is a little off topic, but kind of gets us to the idea of what people are allowed or not allowed to do in a system. So there's a big story today about Polychain, which is like a DeFi network that had the world's largest hack, whatever you want to call it, but a ton of money was taken out of the system. And so the argument that I've been listening to sort of back and forth was if you're an advocate of DeFi, you say, like, it's not a black box, like a bank, you know, like, you can go in and look at all the code and you understand the rules and like the rules are set and agreed to and consensus. So in that sense, it's more transparent, and it's safer. You know, the problem is that A, most people who end up trading, these networks don't read the rules, they couldn't, you know, like, they're, they don't fully understand the code that's been executed, and they're all allowed to interact with other chains. And that creates like new permutations of what happens or whatever. But it's interesting to think about, like, right, at this point, people are out there working on in these open distributed systems where people are authorized to do one thing or another. And then you wake up one day and realize somebody has figured out they're authorized to take. You know, like, they hacked it, but really what they did was just, you know, a better reading of the rules. They found, you know, a way to make the code do what they wanted and walk away.
SS That brings a brings up one of my like, favorite moments during my late PhD. When I was still in academia was I was at like a sort of roundtable thing where it was like half academia and half industry. And people were talking about trusted execution environment and things like that. And people were like, it was very much needed academics going down. They're like, oh, but what are some compromises this work? And I remember someone from from Amazon was like, yeah, at that point, it becomes a legal problem. So, you know, we have you know, an auditor will come into a, you know, bonkers data centers where there's like armed guards and barbed wire, the auditors will come in and look at the system and be like, yep, no one can access that. It's like it's not an academic security for them anymore. It's a legal thing. [Sam & Ben laughs]
BP Yeah, exactly. I mean, that was essentially, yeah, Polychain sent an email after was all done being like, Look, you stole so much money, you know, the government's gonna get involved. So please give it back. Like they were like, the people with the guns are going to show up soon. So Sam, we've been talking a lot Ryan and I with different guests about like, when does it make sense to start on a path towards microservices, Docker and Kubernetes? Can you be a big company that needs scale and flexibility? Or can you start as you know, a small startup, maybe you know, it's a little bit more work at the beginning. But these days, not even so much. And then you have all this opportunity to scale? So when you think about a tool like Oso, is it just as reasonable for a five person team that's looking for product market fit to start using you now so that everything makes sense? Or is this something people come to you with, as you sort of pointed out when they've got a lot of internal logic, but not everybody can see it in the same way, it kind of needs to be consolidated and perhaps streamlined and improved?
SS That's a great question. So we've actually, if anything, we've, you know, optimized more for the early stage startup. We've you put a lot of focus on kind of making this great get started with, right, if you're using Python, it's pip install. So you're, you're ready to go, you know, it's an open source library. So there's, like, zero barrier to using this, there's nothing set up. And yeah, we, you know, we focused on on making the, you know, simple things really, really simple. The kind of complex things possible. And so we kind of do have this, like, sort of bimodal distribution, where it's like, very early users, they just, they don't want even think about authorization, they just want someone to take care of them. Very healthy startup mindset right there. They just use Oso and they're kind of good to go. But you know, for people who are hitting those kind of frustrations, refactors, they kind of see the power and flexibility of it. And they kind of equally like the idea of having a simpler interface.
BP Gotcha.
RD Yeah. It lets them focus on what they're good at, right?
BP How does the pricing model work for scale? Like, how does a five person startup use it versus a big enterprise company?
SS I mean, it's all open source right now. So the price and mode is the same, it's free from free for both. You know, typically what we see, as you spoke about, you know, Microsoft's environments, and this is actually how, for example, we are using this, you know, you have your micro services, you probably have like a central user management Identity Service. That's, for example, like minting minting tokens, or the login users in using OAuth or something like that. And then you know, the individual microservice in this case, we'll be able to take that information in, you know, the roles on a user, that kind of thing. And use that to do authorization. The sort of the nice thing around that is you get to stay true to the kind of micro service architecture where each service manages and owns its own data. Right? If you have you know, I was using GitHub, right, you have like the issues service or something that that's the, that's the data it manages. And it's got all the context, it needs to do authorization for that, it kind of goes back. So we have this kind of like golden rule we speak about which is you should build authorization around your app, you shouldn't like re architect your app around authorization. And that's that's kind of what we see with the use of the library. It's like in a monolith, you use a library, you're good to go. As you start, like peeling out microservices, and splitting up concerns and like moving data out with them. That's fine. Like you just put the library on that as well. And, and like you're good. So like coming back to Zanzibar, which we spoke about that earlier. You know, the Zanzibar approach is you centralize like all of that authorization data. So everything that says, like what belongs to wha hoo, what roles do people have you put all that in one big central place. So you end up like refactoring, rearchitecting your entire app around that, like central data store? You know, the benefits is it's if you're Google, you kind of have this like incredibly hard data scaling problem anyway. So it kind of helps you address that. But I think you shouldn't make that kind of change. Because you want to do authorization and centralized. You should do that because you have like a data scaling problem.
RD Hmm. So why did you make it a library instead of a service?
BP Yeah. What is the business model here?
SS Yeah, honestly, we tried to make it a service because it's way easier to pitch from a business standpoint. And it's even easier to develop and manage when you can just push out updates to your service. The reason we did and is because we know we're focusing on the most the best thing for the developer. And we just couldn't justify the need to send your application data to a third party service to do authorization. You know, it's impossible that you know, user belongs to an organization. This produces an organization like, do you really want to be synchronizing that data with an external services o you can do authorization? Or would you rather have a library that is embedded in your app and works with the data you already have?
RD Right, gets around any sort of PI issues.
SS Gets around PII issues, it means the like, Integration story is like super simple. You import the app and you can write your policies like directly every application data without re architecting or reengineering anything. And because we were really optimizing for the developer experience and the ease of use, it's just it is the only way we saw that being being feasible.
BP And so where do you hope it develops from here? Like, is your venture back now? You want to make it the best solution? And obviously, you know, have as widely used as possible, how does it develop in the future?
SS Yeah, so I'd say the the version of the library we have out right now, it's already pretty great. It's like incredibly helpful. And you can see it from, from, you know, the people using it. I know we have some stuff I'm very, very excited about that we're working on now that we're coming out sort of shortly that I think takes that stuff to the next level, and is really going to make this—it's going to take it from being a tool that helps you like solve a complex problem to a tool that makes the problem not even that complex anymore. So we need to get that stuff done means put that stuff out there. And basically, we just want to get as many developers using that as possible. In the future, we have, you know, we have some ideas of stuff we're going to build on top of that as a commercial offering. That would be kind of a more traditional SaaS offering that provides like additional functionality on top of that, but ultimately, the library itself is staying open source.
[music]
BP Alright, I'll read a lifeboat badge, which we do at the end of every episode to give a shout out to someone the community who helped us and then we'll say our goodbyes. Awarded two days ago to Evgeny Lisin: 'How to find UIWebView in Project and replace it with WKWebView?' Alright, well, if you want to know, there's a lifeboat badge winner who has helped out the Stack Overflow community and left some knowledge out there for everyone. I am Ben Popper. I'm the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper, email us podcast@stackoverflow.com. And if you liked the show, leave us a rating and a review. It really helps. Ryan, who are you?
RD I'm Ryan Donovan. I edit the blog and the newsletter. I'm a ghost on Twitter @RThorDonovan. And if you have a great idea for a blog, please email me at pitches@stackoverflow.com.
BP Sam, who are you? Where can people find you online? And where should they go if they want to check out more about Oso?
SS So I'm Sam, the co-founder and CTO os Oso, you can find out more about us at osohq.com. And on Twitter, I guess, I'm @samososos. You'll be able to find that I'm sure.
BP Yeah, we'll put the link in the show notes. [Sam laugh]
SS Thanks.
BP Alright. Thanks for your time. Thanks for listening everybody. Talk to you soon.
[outro music]