Screaming in the Cloud - Building Smarter Authorization Systems with Sam Scott

Episode Date: June 4, 2024

This episode explores the intricacies of authorization in software development with Sam Scott, CTO and co-founder of Oso. This conversation highlights the subtle yet critical differences between authentication and authorization, and why understanding these distinctions is pivotal for securing applications effectively. Sam shares his journey from a cryptography PhD to tackling real-world software security problems, emphasizing Oso's mission to streamline authorization for developers. The episode is rich with insights on how fine-grained authorization can significantly improve security posture and user experience, drawing on examples from prominent tech companies like AWS and Google Cloud. Sam also introduces Oso's innovative approach to authorization, simplifying permission management without sacrificing flexibility or control, making it an indispensable tool for developers navigating the complex landscape of modern software security.Show Highlights: (00:00) Introduction (01:49) Insights from Sam's PhD in cryptography(01:56) Understanding the difference between authentication and authorization(04:05) The real-world implications of key management and the role of authorization in security(06:02) Explaining role-based access control and its practical applications in cloud environments(10:47) The complexities of managing access controls in microservices architectures (15:37) How Oso simplifies the implementation of authorization for developers (19:21) Discussion on the importance of consistent authorization practices across internal and external applications(25:14) Sam explains the challenges and necessity of implementing user impersonation features in authorization systems(31:12) The future of authorization technologies and integrating them into business practices(35:38) Where to find more resources about Oso and get involved with their communityAbout Sam:Sam is the cofounder/CTO at Oso, working on making security and authorization more accessible for developers. Sam previously got a PhD in Cryptography and was a contributor to TLS 1.3Links referenced: Oso Website: https://www.osohq.com/Oso’s Authorization Academy: https://www.osohq.com/academy/authorization-academyOso Community: https://join-slack.osohq.com/https://oso-oss.slack.com/join/shared_invite/zt-1ygg193va-UTUiT7Gwt7DjZGgF96Ze~w#/shared-invite/email* Sponsor Oso: https://www.osohq.com/

What is sort of the right way to do it that will lead in a good user experience for your customers? Right. Not just about like, what is good? How can you implement this in a way that gets off your roadmap? Like, what do we think would be truly like delight your customers? Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today on this promoted episode is brought to us by our friends at Oso. And what else is brought to us by Oso?

That's right. Their CTO and co-founder, Sam Scott. Sam, thank you for joining me. Hey, Corey. Thanks for having me. Oso makes it easy for developers to build authorization into their applications. With Oso, you can model, extend, and enforce your authorization as your applications scale. Organizations like Intercom, Headway Product Board, and PagerDuty have migrated to Oso to build fine-grained authorization

backed by a highly available and performance service. Check out Oso today at osohq.com. That's O-S-O-H-Q dot com. Instead of starting at the beginning, because that makes way too much sense, I want to pick up on something that I noticed about your background. Specifically, you have a PhD in cryptography, which my biggest takeaway from this was always called Schneer's Law, which is, as Bruce Schneer famously said, anyone can invent an encryption algorithm that they themselves cannot break. The takeaway, of course, is don't roll your own

cryptography. And the other thing I try never to get involved with is rolling my own authentication. So you have a PhD in cryptography and now you work for a company that does authentication. Are you just like effectively hanging out with a bad idea bear or something and coming up with these ideas? What is your life like? How did you get into this position? I mean, someone's got to solve those problems. And I like the hard problems. They're the most fun ones. I will have to correct you immediately with the misconception that almost everybody makes. We work on authorization, not authentication. Excellent. Excellent. And I want to begin with the even dumber question then. What is the difference between the two?

So authentication is typically about identity, like who are you, right? You use name and password, single sign-on, like how does the other person, the other side of some interaction know who you are? That's like the authentication piece. Authorization is normally what comes next, right? Now that I know who you are, right? You're Query in some domain, I don't know, you belong to some organization, like, okay, now I know who you are, what can you do? Can you research such documents? Do you accept the standard features? Things like that. In other words, great. So when I start having too much to drink on a plane and ranting

like, you don't know who I am, I'm Corey Quinn, and they'll say, yes, we know exactly who you are. No, you're not allowed to fly the plane. That is exactly right. Yeah. Got it. I somehow don't imagine that's going to be making it into one of your slide decks anytime soon. But no Got it. I somehow don't imagine that's going to be making it into one of your slide decks anytime soon. But no, it's an interesting problem.

And someone that I once worked with in the early days of my career pointed out something that at the time I, a wet behind the ears 20 something who, of course, knew better, scoffed at it. But they said that ultimately every every security and networking job in its final form becomes about identity and access management. And I laughed and I laughed and he was really on to something in hindsight. Yeah. I mean, basically what you're summarizing is how I found out my PhD was worthless. Have you had the expression, turtles all the way down? Oh, yes. The world stands out. What was it? What's the expression? There's some mythology that said, oh, the entire world exists in the back of a turtle. Plausible as anything else. So what's the turtle standing on? Another turtle.

It's turtles all the way down. Exactly. And so the same thing is true in insecurity. And this is kind of what I found out with working on like interesting cryptography, which is. So I know some of the stuff I did was around, like, how do you make sure that like data is encrypted? And like, if the keys changing, you need to rotate them and so on and so on and so on. And there were definitely some interesting technical problems to work on.

I had a lot of fun and built some fun maps. When you get to the, in practice, what is hard about keeping data secure, it's like, who has access to your keys in KMS? Who has in KMS, right? You can get those keys. If you can get the keys, it's game over, right? It doesn't matter

what encryption standards you use and how frequently you're rotating your keys. It's a, oops, I wrote a, I wrote an access control rule that lets somebody get access to the product encryption keys

and now it's game over. And that's kind of where the authorization piece comes in, right? It's like, you know, are you making sure the right people have access to the right things? Maybe not the bottom title,

but it's definitely a pretty low one. I know that they're not the same thing as you just corrected me on, but I can't shake the feeling that I'm not the only person that makes that mistake. Take AWS as a terrific example. Please take it. Take it somewhere far away from here. The problem that I have is that by authenticating that I am me to my AWS account, the only way that is expressed is in the form of credentials and ideally short-lived ones because I'm not a complete lunatic. But there's no distinction to my mind between, yes, I have the credentials that prove I'm me and also by extension by being me, I therefore have access to do the following number of horrifying things. Yeah, deeply, deeply coupled and related problems, right?

So it's the kind of the one you described, like, you know, I, you know, I authenticate, identify who I am. And like, I belong to, I'm inside of an AWS organization or account. And that's going to give me access to a bunch of things by probably by default, right? Like almost every app in the world

is going to have some amount of like authorization. That's maybe not expressed very explicitly as like, this is authorization happening right now, but it's just a, you know, when, you know, when you go and read the database, you filter by an org ID or something like that. Like that is, that is authorization, but it's kind of implicit. It's like woven in,

but it starts getting more and more interesting when you start getting to more like more complex fine-grained versions of that right so sure you've done you've done some of the basics up front you've identified you put in your credentials you get access to some things but your AWS account probably has a ton of IAM rules describing the precise resources that you have access to at any given time in In fact, if you do things correctly, and maybe according to best practices, you might not even have access to things directly. You might have access to assume a role and that role might grant you access to things.

And that is another really good example of like authorization. It comes up everywhere, like role-based access control. The general idea being, instead of just describing what Cori can do, I say, well, Cori has this role much, much like other people in this organization do, and they can all collectively do the same kinds of things. Now, that's exactly what we do. And in most accounts that I have, that role lets me assume administrator access. And the reason being is that I've always viewed AWS accounts as being the ultimate trust boundary, because it doesn't matter if you just have developer rights and can never touch the things in the production side of that account. Things like service quotas, there's no way to restrict those.

So suddenly you have a script that runs amok. You're not going to be able to suddenly autoscale in the production side of the environment. So there has to be that boundary there somewhere. I do this through IAM Access Identity Center. The source of identity is Google Workspaces. And then I wind up assuming roles based upon my group membership inside of that. And that gets me most of the way there. There are then additional roles we assume in client accounts where,

surprise, I don't want to be able to break things there. So it tends to be very narrowly scoped to begin with. And we can scope that further when we have customers in particularly sensitive environments. We do not break production or you're not allowed to save money anymore has always been our the thing that we've observed in our client accounts. But being able to assume those roles correctly and make sure that the right people who are working the right account have access. We don't just grant, oh, everyone here can have access to everything. For a small company,

we do a remarkable amount of segmentation just because I've worked in regulated compliance heavy environments before. You want to keep the sensitive stuff as narrowly contained as you can because then you don't really have to worry about access outside of those things. Well, okay, we have to make sure

that all the discussion of the sensitive client stays within a given bounded area of Slack where only certain people can access. Great. So we code name everything. And then it's a lot easier just because in case someone slips, we aren't suddenly having to deal with data breach issues. Right, exactly. And so like building an authorization system is all around, I guess, enabling users of your own product to be able to support flows that make the most sense for them. And with something very platform-y, like an Amazon, naturally, you're going to want to give your users a lot of flexibility so they can tailor things to exactly how they're setting

things up and building things. But in a lot of cases, you maybe want to give people minimal configurability. You want to just give them the typical path that they would take and not think about it too much, for example. So it's kind of a wide spectrum. Yeah, it's a, because the problem that I found, and this is where I start to get political on it, so you'll have to bear with me. But I've been saying for a while that Google is number one when it comes to security and AWS is number two. And Azure did not finish their at the kids table eating crayons as they're going to do. Terrific.

And the reason behind this is the usability approach. By default, anything in a Google Cloud project can talk to anything else in a Google Cloud project. That works terrifically well for me and disastrously for people at a bank. But by the time you're a bank, you have an InfoSec team that can disable that behavior and build in a least access model, which is great. The danger of the AWS approach, and I gave a conference talk recently at an event that whizzed through, that it was about an actual screenshot of something I have hanging out in my code build

environment, where I have four or five different policies assigned to it. And the last one that I added was administrator access. And there's a to-do to go back and fix this later. And this was in 2018. I have not yet gotten to do that yet. And it's because you try to do something, it doesn't work. You expand, try again, doesn't work. And if you're doing this through something like CloudFormation, each iteration takes an hour. So great. By the time I was finally, it was the hell with it. I just want this to go. That's the problem with continually failing to get the right permission dialed in. So you just say,

just go ahead and give it to me everything. I'll deal with it in my own time. Yeah, you're appreciating the choir here. Much like how roles can be this pretty convenient authorization abstraction to group people together based on similar things they do together. These are all admins, right?

Like similarly on what I think about as the resource management side, like the entities you have access to, having that ability to just group things into some kind of hierarchy with orgs and projects is such a simple model for you to wrap your heads around, but gets you so far. As you described, just being able to do that level of opinionated structuring of missions goes a long,

long way. Yeah, I'm very interested to see how these problems evolve because what we're currently doing is not sustainable. Clearly, it's not. And the thing that I figured out as I went down this path early on when I started doing this independently is I

turned my nose up at anything that would look like RBAC or SSO because I was independent. And I already have a great SSO thing that works. It's called 1Password. I stuff all of my passwords into it and things are great. Where this starts to break down is when you start dealing with other people. How do you validate that everyone is using 1Password, for example? Well, when you mandate SSO, that solves some of these things, and you have a single chokepoint to wind up controlling access and enforcing MFA and the like, whereas having to play whack-a-mole at other environments.

That was something that I found to be extraordinarily challenging, and I wish I'd done a bit differently setting out to do it. Yeah, in that it's nice to be able to have a single dashboard. When I bring someone on as a contractor to work on a project, for example, there are certain levels of granularity to permissions that they should have. And they vary from contractor to contractor. Having a catch-all contractors group doesn't work.

It has to be, okay, are they a contract cloud economist? Okay, great. Which accounts are they working on? Make sure they only have access to those accounts. They still need access to shared stuff internally, but they probably don't need access to, for example, the employee portal and so on and so forth. And each one tends to be these bespoke things. And honestly, if I'm being direct, what we'll see is great. We just now have a pattern that we apply to

most contractors that start based on the template that we built from our first contractor. Yeah. I think the world you're kind of getting towards here reminds me a lot of the world of SAML. SAML, OAuth, SSO. These terms are, I guess, interact inter-applicably, just between things. All the documentation for all of these things, in my experience, presupposes that I have a directory management background. Everything assumes I know what an OU is, which okay, great, not everything lends itself to the OU model, especially when those OUs are not hierarchical and it becomes an obnoxious

painful problem. Yeah, absolutely. I mean, I think the thing that's nice about SSO, I'm sick of it, is because it creates, as you say, it creates that pretty clean, convenient checkpoint where it's like as an implementer, I don't really need to care too much about how you authenticate like somebody else, your, your it admin side of how someone should authenticate.

And like, once you're in authenticated, like I can kind of continue on and do, you know, do, do the stuff that I care about when you get into like trying to do that or an authorization standpoint. I mean, like you described by bringing in Google workspace groups to use those to determine which roles you can have access to. That's when you end up in the like the gnarliest of gnarly like federation problems where, yeah, you're talking about three or four different standards, protocols, specifications to implement to get that data.

Nobody does it in the same way, even though there is technically a standard. And then you need to go and implement an interface inside your app that lets your users configure how they want to connect those different pieces of information up and decide what they can do with it right like i'm out of breath just trying just trying to talk about it i know there is it's like it's like that classic xkc cartoon like i'm just going to create a new specification standardize all these things and build that one and then we have another new one congratulations you just built the latest standards no no one no one sets out trying to build something bespoke and unique.

Like, ah, we're going to build a unification thing. And unfortunately, it just doesn't work. The thing for us, I think it's kind of a two-sided problem in both of which are hard. It is both hard to build an authorization system that allows you to kind of bring in arbitrary external data and let people configure that and manipulate it into how they want to do authorization

inside of their product. Like that side of it is already hard, let alone the like abstraction or unification of the like, you know, where that data comes from part. And so at least for us, we can make progress on solving the first of those two problems. And we make it easy for people to implement.

Cool, I have groups from Google workspaces and I want people to be able to use that inside of my products. We can make, we can solve that half of it at least. That's the painful part. That's the thing that's hard in my experience to get right. It's the, it's always the new thing suddenly turns that your, turns everything you've been doing on its head. And I think at enterprises, this gets a lot easier because there aren't that many new worlds left to conquer. You are not the first person who tries to expense a rental car at a company that has 2000 people. But when you're 10 people, maybe you are when you grew during a pandemic. So I'm curious to know on some level, what what is it that you folks do exactly?

I mean, so why should I use why should these also to wind up solving these problems? Because you already have some compelling stories like, well, honestly, our logo is a bear and we're named after the Spanish word for bear. So terrific. The puns are going to be there for days, but that, that drifts a little bit too much into my personal labers. What are the, what are the reasons that you exist? What is it you solve for customers that hurts? Yeah. So the reason that we exist is, I think there are probably two main reasons. So first of all, something we just observed

is that people have been reinventing this wheel of authorization again and again at like every single company they went to. They've spent like six months, 12 months, you know, multiple years

re-implementing authorization within that company. Like how do people, how do people get access to stuff inside of this product? Rebuilding, you know, organization roles,

user groups, rebuilding, you know, the ability to share things with people and bring them access to it. Everyone's just like rewriting this code again and again and again from scratch. And so it just kind of seemed like one of those, those obvious problems that like,

what if there was just a company that could solve that for you? So not, there's like that side of it. We just like help take that implementation away from people. And they're like, what if there was just a company that could solve that for you? So that is like that side of it. We just like help take that implementation away from people. I know like I love authorization. I think it's a super interesting problem, but I don't think like every company in the world

wants to be authorization experts and crush it. And so I think it's one of those problems that's like a really good fit for people to like outsource somebody else. I think the other half that maybe touches on some of what we've just been talking about, which is people don't really talk about authorization a lot. They don't

think about it a lot and talk about what is good authorization and bad authorization and have compared AWS, IAM, Google Cloud approach much in depth. We have. We have a lot of opinions on what is the right way to do it that will lead in a good user experience for your

customers. Not just about how it that will lead in a good user experience for your customers, right? Not just about like, what is good, how can you implement this in a way that gets off your roadmap? But like, what do we think would be truly like delight your customers when it turns, when it comes to being able to do authorization? And so those are kind of like two of the big problems

that we help solve for people. Take this piece of implementation work that your team would otherwise be spending, you know, potentially years on and we do it for you as a service, great. But we kind of almost work as like a partner with all our customers, like a design partner with all of our customers.

We're like, you know, okay, what are your customers trying to do? And like, can we leverage the patterns that we've seen to help guide you on like making that not suck? It feels like there's a Goldilocks story here, as in, if nothing else, t-shirt sizing. You must be at least this tall to ride slash get value from Oso.

And I'm wondering, is there a sweet spot that you have for customer profiles around company size? Like that's, we're a venture-backed company, that's our ambition kind of thing. But it's true that like today, I think where we see our sweet spot is kind of two main categories of people. People who are maybe going upmarket, they're going after larger enterprises and they're realizing that they're getting like a ton of sales requests. Like, hey, to use your product,

like we need to be able to segregate access within different teams or within different groups, right? Like we have sensitive data in, this group are working on this other group shouldn't get access to. And we'll see this, a lot of companies will start getting those requests. It's no longer enough that you log in and you have access to this, the organization that that is sufficient. We need to start getting things more granular. So companies that hit that point, that's normally around the size of customers they're going after. That's a really good one. No one is excited by the prospect

of building permissions except for the people at Oso. With Oso's authorization as a service, you have building blocks for basic permissions patterns like RBAC, REBAC, ABAC, and the ability to extend to more fine-grained authorization as your applications evolve.

Build a centralized authorization service that helps your developers build and deploy new features quickly. Check out Oso today at osohq.com. Again, that's O-S-O-H-Q dot com. When I wound up working at my first startup, I was their first non-developer technical hire, which is always a weird place to find yourself in. But I wound up picking up a lot of good patterns that I carried with me forward from that. One of them was that when our auditors showed up, because we were in the payment space, they asked us like how they authenticated to the Wi-Fi. It's like, oh, great. The password is on the wall. And they stared at me like, oh, that's not going to be good. Like, OK,

so where's your Active Directory? Our what now? I'm sorry, that's not going to be good. Like, OK, so what? Where's your active directory? Are what now? I'm sorry, this is not a Windows shop. And they said, OK, let me distill this down for you. Very simple terms. Once I'm on the Wi-Fi, what does that grant me access to? And the answer was the Internet and that printer over there.

They're like, wait, OK, but from the office, you can wind up then getting special access into other things. Like, no, that sounds like something an insane person might do. We wind up instead either using a VPN if we're trying to get into something sensitive or more commonly, every API endpoint is hardened and we authenticate with signed requests on all of them.

And they're like, I've never seen that before. And it's, yeah, the reason we did it is because everything that did the traditional gateway stuff was really expensive. And we'll see how this works out. Now, apparently it's called Zero Trust or Beyond Corp and everyone pushes it as a best practice. And during the pandemic,

we saw the VPN concentrators and a lot of enterprises start melting out of their racks when everyone used them at once. But that was a, but it was sort of an interesting, almost by accident. It's easy to sit here and say, oh, because I was a visionary. No, because I was cheap and didn't really know any better. No, I see that kind of playing out a lot. It does remind me of like an interesting or important clarification I want to make, because I think probably, I take this difference for

granted, but it's probably not one that everybody does who's listening to this. The kind of thing you're talking about is sort of internal company authorization, maybe even like infrastructure platform authorization. For us to be like, within Oso, what do I have access to? What AWS servers can I access?

Which products can I access? Can I get to the email? Can I talk to the printer? That's all internal to the business. What can I get to the email? Can I talk to the printer? Stuff like that. That's all like internal to the business. What can you get access to? The authorization that we typically focus on is for companies building B2B SaaS products, right? Like you're building a, and let's say GitHub, it's an example we use a lot, right? You're building GitHub.

What authorization do you let your users do? How do people authorize and get access to things within the GitHub products? You can access GitHub organizations, you can maybe access certain repositories. I can set roles at different levels within an organization that means you can push to repositories or not. So for people

who are building those SaaS products like a GitHub, we're helping implement that kind of authorization within that product. It's almost like you're skipping ahead in my notes as far as things I wanted to talk about, because this is exactly where we're headed with the conversation. Because one thing that AWS did or Amazon did in the early 2000s, which I thought was great, is Bezos passed by decree the idea that every company talks to each other via hardened APIs with the expectation that those things can become public at any time. And that caused some great things and some terrible things too. Like it turns out when you don't have a company holistically talking to each other as

humans, you wind up with travesties like the billing system, but that's neither here nor there. The painful part though, is that I think comes from a lot of cases where companies treat internal authorization versus customer authorization as very different things. And there are times you can't escape it, but increasingly as I get older, that feels more and more like an anti-pattern. I think it's because the idea that once you wind up with a trusted network or a trusted inside group of people who are employees, you on some level wind up with a M&M style security. You've hardened the perimeter and then you no longer feel the need to wind up defending anything

inside of that perimeter. Now, in many cases, this is a good thing. There's a reason that Slack doesn't have a block button. It's because you, that's it, I've had enough. I never want to hear from those bastards in accounting ever again is all well and good, but you can't really have a functional business when that's the kind of thing that happens. Whereas I never want to hear from these people in public again who say mean things about me on the Internet. Ahem, ahem. Okay, that's a bit more understandable. But for some reason, I've always had the impression that treating employees as once you're in the in-group, you're in, is a security misstep. I think I understand.

So you're saying like when you're building a product, like you're building something in GitHub, like you shouldn't treat employees' access to things within GitHub the same as external people's access to GitHub. Yes. Now, maybe there are permission groups that can only apply to people who have a GitHub employee flag set in their profile. But the way they log in, the way

that identity gets passed out should absolutely not be a sidecar system. Now, yes, you need a break glass way for them to get access to things. If that identity system is what breaks, you'd better have a way to get in and fix that quickly. But as a standard operating procedure, yeah, going in the front door the way that your customers do, first means you don't have to build and maintain separate systems for this that are going to diverge. And two, when there are customer side issues with this, you'll see them because they impact you as well. Yeah, that's a really great point. And that one is a, I mean, just the reason people don't is like, it's hard to, it's really hard to implement that well, because to do so, you need to have a authorization system that's flexible to handle, you know,

potentially suddenly users who can have access to multiple accounts. And as we kind of spoke about right at the beginning, the easiest thing to do is use hard code. Someone logs in and they only have access to the account they belong to. If you now suddenly have a support user who needs to go and debug a customer account

and they should get some limited access to that customer account, that they should get some limited access to that customer account. That's certainly undermined the entire way that you implement authorization inside your company and going to require you implementing all kinds of hacks and workarounds to make that happen. Something called impersonation, the ability for a customer support person to impersonate a user

so they can see what they would do and get access to some things that they would get access to. Doing that well basically requires you having a a lot of extra code to kind of handle these different special cases. And it ends up being a different code path just in a different way. Or you need to have like a very sort of powerful, generic, flexible authorization system that can treat, hey, can this user access this other thing as a generic question, regardless of how they get access to. And so, yes, 2D knows his phone, we support that kind of situation really nicely. You treat all users the same. You can have a user with a global admin, super admin case,

right? You're like, another say startup and you say, yeah, I don't know how to access everything. You have a global super admin, they can access everything. But over time, you can implement things like support agent can get access to this customer's account if there's an open support ticket for that customer and they've been assigned to it. You can start writing very granular logic where the sweet spot is for that internal customer support person.

There's zero friction to them seeing the things they need to see. Oh crap, I'm assigned a ticket. It's fine. I go to see that customer, I can see all the things. But they don't suddenly have access to every company under the sun. Yeah, that's where it gets weird. Yeah, that's where it gets a bit concerning and strange, exactly. And even in the areas of the

internal infrastructure where every employee has access to stuff, there are things you want to be very guarded about. Even my business partner, the CEO, does not have access to writable to any of the audit logs, for example. I do at the moment, but as far as I can, they're not mutable. But there are, I know ways around these things. But again, I own the company. What am I going to do? Do this against myself? But there will be ways that we wind up sharding that in the future.

Sometimes at clients, what I see is we go into optimize their AWS account and there's a carve out, sometimes a separate organization, sometimes a series of accounts because people with access to one are not allowed to touch the other, which great, awesome. Usually that's the security boundary

and you take a look at it, it's less than 10% of spend. So great, awesome. Let them do what they're going to do. We'll work around them. I love seeing that pattern. You know, and it reminds me, going back to the turtles analogy, I said authorizations invite the bottom turtle. The bottom turtle,

in my mind, is lawyers. Because ultimately, all of these technical approaches, right, at some point, there's going to be some layer at which, like, you can't guarantee that nobody can ever do a thing. Generally, at that point, that's where lawyers come in, or auditors, where you, you know, sign a document saying, or a policy saying that I do not do these things. And if I do like, please hold me accountable to it. So like, yeah, you're right. Like certain point you have to have like some boundary where somebody can break glass, do a thing. But generally you write a policy and you let lawyers enforce it. One of our early attorneys, one of the first generals counsel we had here was probably sort of better understanding of defense in depth than most security people I know. And his advice was very simple. He's like,

do not lose your shirt in business. Here are four things you do. Use them in this order. Step one, be a nice person. People don't want to sue their buddy to have good contracts when that's for when that breaks down. Step three, have insurance so that this covers these things when that turns against you. And step four, have a legal entity so you don't lose your house when things completely go to custard. That's the shell. Use them in that order. And yeah, that's the way to think about these things. Because if you just go out there and say, oh, we don't need contracts or insurance or legal entity because I'm a nice person and everyone likes me, that's not going to work super well. Let me rephrase. That works super well until one day, all of a sudden,'m trying to understand what your adoption looks like. I have to imagine you get no greenfield environments because I have an idea. I'm going to build

something and see if it works. No one's thinking about security on the first step for that, unless it's a security company, in which case they think about security sooner than most, but still not soon enough to suit how most people think about these things. There's always some means that people are using to authenticate and then validate that they have authorization to do things. How do you roll out in an environment where things are, I guess, already pre-existent? So first of all, you'd be surprised.

There are a good amount of people who they started a company and they had so much pain from authorization previously and they knew that it's going to be important to them because they're in, yeah, say security or health tech or fintech and they're like you know what i want to get this out of the way before we do anything else because i've seen how bad it can be if you wait oh that does happen as well but coming back to your question though like you know how do people like maybe adopt this incrementally or migrate um there's kind of a few

parts of this so one like what we've done what we, what we often help people do is adopt this incrementally by implementing the net new functionality they care about. So maybe they're migrating from monoliths to microservices and they want to start seeing how do I have an authorization microservice? We'll help them do that part

while maybe keeping the existing stuff running as it is. It might be a case of they've already got multiple services and they're rolling out a new service that's going to require some new functionality, some new capability. We'll say, okay, let's just implement it into that one new service. Let's do that new stuff that you couldn't previously do. That was going to take you, you know, have a long, you know, six months, 12 months in your roadmap to like roll out that new,

you know, sharing capability before you go and add this new microservice. Like we'll help you do that piece on that one service so you can kind of see it, see the patterns. And then we can gradually start bringing over the old stuff over time. I lied to you. I did have one more question I wanted to get into. And I'm worried of how this might wind up shaking out.

You recently wound up rolling out something called distributed authorization. And the reason I'm nervous to talk about it is I'm concerned it might be some blockchain horseshit. Well, yeah, no, don't worry, it's not. Would have been awkward otherwise. Yeah, the cryptography in my PhD has zero to do with the blockchain-y side of crypto,

which is why I had to call it PhD in cryptography and not PhD in crypto, which makes me sad. But yeah, no, so distributed authorization. It's something we're pretty excited about because we've been kind of wanting to release it since the beginning of Syingoso, like four or five years ago, of how we think authorization should work.

And it's called distributed authorization as a contrast to centralized authorization. So historically, people, if they want to have some kind of consistent way of doing authorization across the company, across multiple services, they put everything in a central microservice. All of the authorization logic, they put all the data that's necessary, which can end up being a lot of data.

All of the user data and the roles they have, all the resources you want to have access to in Google Cloud, all the projects and all the resources and all the projects they belong to. All of that data gets shoved into this central service and you have an API that says, can I use a do-it-thing or not? That was kind of the old way. It was kind of painful because it really went against microservice best practices of how you ideally want to decouple

and draw good boundaries between services. It had this horrible coupling where you're synchronizing and sending all your data centrally. But it was kind of the only way to get a consistent authorization implementation at a large scale. What we've done with distributed authorization

is we've basically made it possible for people to integrate a consistent authorization implementation into individual services while leveraging the data those services already have and own and manage. So rather than going through this process of synchronizing

and sending all this data centrally, you can just like roll out authorization in one of those services, leveraging the data you already have. Doesn't that dramatically increase the attack surface? You wind up effectively without the central source of truth that you are guarding on some level. Ignoring the split brain problems of distributed systems

and in fact, how you establish Quorum. I guess, you can re-involve Paxos for fun. Why not? You have a PhD in this sort of thing anyway. It'll be fine. No, what I'm trying to figure out is, does that mean that you have to be a lot more guarded as far as... There's no longer a central,

I guess, crown jewel area. Suddenly, everything becomes a theoretical tax point, doesn't it? Not really. I mean, in the sense that with a central service, you can already forget to call the API or just ignore what the API tells you. You're already trusting that the services enforcing the authorization are actually going to check your service and do something with it.

There's already that amount of trust there. I think, though, there is an interesting distinction, which is the logic for who can do what in this world still lives inside that central authorization service. You have one place to look at the logic, you have one place to audit who can do what. It's mostly just the data piece that is now being deferred to handle inside the database.

So when I actually go and fetch a list of servers that you have access to based on projects it belongs to, that might just happen in the database that you have already built rather than inside the central service. So there's just a little bit of weather processing happening that's different. And in both cases, you're still getting a full audit log of the authorization that took place.

So with Oso, right, every time someone makes an authorization call or all the servers that I have access to, we'll audit servers that I have access to. We'll audit logs that that request took place. Like what was the user, what were they trying to do? And what was the data that we would have gone and looked up to answer that question? That makes sense.

I have to imagine that's rather compelling for people who have bought into your vision of authorization. Yeah, I mean, this feature came from a lot of feedback from customers who really, people really want this, like, I want to put authorization behind an API. I want to call that. I don't want my teams to go and re-implement everything from scratch every single time. That's the thing they're trying to get towards.

But forever, like for a long time, it came with this like big cost of, okay, but to do that, you just go around to every single team and tell them, here's how to get the data into the service so that it can do those things for you. And so I think removing that whole part of the conversation, I think is pretty exciting for people. They can now go to that team and be like, hey, we have taken care of that authorization thing for you. You don't have to think about commissioning and roles and groups and all that kind of stuff.

We're just going to give you a library that you implement, client library and API that you're going to integrate into your app. And you're good. You're done. We've got it. We're going to audit things. We're going to review things. Don't worry about that. You can just carry on and do things happily, which I think will really change how people think about female authorization. I look forward to seeing how this winds up

evolving. Thanks for taking the time to speak with me about it. If people want to learn more, where's the best place for them to find you? Yeah. Well, so yeah, thank you for having me here. And I mean, all this information is at osohp.com. From there, there's like a couple of paths you can go down. We have a ton of educational content for developers like Authorization Academy.

If any of this kind of, you know, if we went too fast, I know I speak pretty fast. You can kind of read that stuff in depth. You can go and just start trying out the Oso product for free. Like, you know, there's this, you know, an unlimited free trial. You can just sign up for and try out. And we also have like a Slack community

if you want to like get into a bit more of a discussion and you're kind of thinking through some thoughts, but you have not talked about them. We've got a safe space for you to talk about authorization. So you can find all that from osohq.com. And we will, of course, put links to all of that in the show notes. Thank you so much for taking the time out of your day to have this conversation with me.

I really appreciate it. Thank you for having me. Sam Scott, CTO and co-founder at Oso Security. This promoted guest episode of Screaming in the Cloud has been brought to us by Sane. And I'm cloud economist Corey Quinn. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. If you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment that makes sure to start with the phrase, don't you know who I am?