Permissions are the gift that keep on giving, with Or Weis from Permit.io

[00:00:00] Track 1: Hello and welcome back to APIs you won't hate. Uh, as always, I am your host, Mike Fulco. I am sitting down here today to talk with a new friend of mine named or Weiss from permit.io, or it's great to sit down and chat with you. How are you doing today?

[00:00:14] Or Weis (Permit: I'm great. Super excited to talk with you, Mike.

[00:00:17] Track 1: Yeah, likewise. Likewise. Uh, it's, um always interesting to meet people who are working in the developer experience world, especially around, uh, APIs and things like that, which is obviously why you and I are talking today. Um, yeah. So let's start here. Why don't you tell me a little bit about yourself, uh, and your, your sort of history before, uh, uh, permit.io, which is what you're working on right now, uh, and how we got to permit existing.

[00:00:41] Or Weis (Permit: Sure. Sounds like a plan. So, um, my name is, or Weis, you probably gathered that by now. My background starts in the intelligence score in the idf. I was an officer, developer, reverse engineer, engineer team, yada, yada. Basically a cliche, an Israeli entrepreneur. Uh, afterwards I [00:01:00] worked in a startup called Antigua, where we built containers before containers were a thing.

[00:01:04] but with a terrible go-to market. Even worse than Dockers after they ruined their go-to market. Um, I worked a couple startups, founded a startup called React that was acquired by metadata io was a VP of r d and a cyber security company. And, uh, between late 2016 till up, uh, almost three years ago, I co-founded and ran a ceo, a company called Brook Out. Uh, which is another, uh, dev tool, uh, production debugging solution. I didn't go as far as saying the company that created the production debugging space. And, uh, during my time at Rout, I ended up building access control to our product times when the company wasn't even three years old. And I just said, stupid. I don't wanna do it once, let alone five times. reflecting on it. I realized that throughout

[00:01:56] my career I've been building this crap part of my French for [00:02:00] thousands of times, and I get at no point, at no point did I want to. um, I got together with a friend of mine myself. We are now friend. We know each other for 18 years, which makes me feel old. And he, uh, aside from serving with me in the unit, he also worked at Facebook Meta where he worked on their internal developer tools and in infrastructure and authorization. And he saw that they've invested a team of 30 people for half a decade to build the level of access control that they have. So we did the math and we quickly realized that it's not only a huge problem now and a huge annoyance now, it's only gonna get far worse down the road as the complexity of software continues to arise, and as more machine learning agents are mixed in.

[00:02:44] So if you think it's hard to manage users and their access to your product, wait till you need to manage their machine learnings, uh, machine learning models as they talk to your machine learning models. I, I just got back from con eu. uh, in Amsterdam [00:03:00] and if some one thing was apparent is that every company now is plugging in a machine learning model, a chat G p t like thing into their software. Um, and that's gonna make access control there and security there quite a challenge, I'd say.

[00:03:15] Track 1: I'll say. Yeah. Yeah. It's a really interesting, uh, feature set to be working on. I feel like every product team I've worked on, every product I've worked on, every project I've worked on, whether it's for, for a formalized company or not, this feels like one of those things where it's like, ends up being engineered into the product later on, right?

[00:03:32] Like

[00:03:33] prime on the list of tech debt is, oh, we'll put in permissions later. For now, we'll just only give logins to the people who need it, that kind of a

[00:03:39] Or Weis (Permit: Yeah. Yeah. You know, everyone starts, like we all talk about permission models, but everyone starts with the most classic one, which is called admin. Not admin, meaning I'm the developer, I'm the admin. All of you guys will stick with whatever else I, I'll leave out. And then requirements start to funnel in, and then your stakeholders want permission, so you go, okay.

[00:03:58] Okay. Okay. So we'll have. [00:04:00] admin, super admin, I'll be the super admin, and then, uh, just a regular user. And then it moves to access control lists, and then it moves into our ARB is like the bread and butter of this world, right? Roll based access control. You have a role that gives you permissions, but then it continues.

[00:04:18] Like a lot of people think it's, it ends there, but it doesn't. You have attribute based access control, like how do you define a policy like only users that have paid for a feature can use it. Is that like a billing, like a paying roles? What, what, what would be that? And then you have role based access and control and just on and on.

[00:04:37] This is, I like to say the permissions is the gift, the gift that keeps on giving. And I, I mentioned my story at Rout, so. I, I literally went through the same thing, the same point, same pain point. okay, I'm done with this. Like the fourth time or fifth time I built it, I was like, I have built the best dam access control solution out there. It's perfect. I'm never gonna have to touch it [00:05:00] again. And I remember it really shattered me. Uh, one of our, uh, business partners, Cisco came in, they were co-selling out, and they came in and said, at some point, we want our own back office. And I was like, ah, shacks. I didn't think of that one. Okay. Out the window.

[00:05:17] Start from scratch yet again. And because every product is a snowflake and because every product manager is a unique being, and because your security compliance is always your own thing, there's constantly new things that each product needs to tackle in a proprietary way.

[00:05:35] Track 1: Sure. Yeah. I think that's pretty easy to imagine. Um, especially with these sort of like evolving product scape where, where, um, project teams will add features to their product that add complexity or add, uh, collaboration needs and things like that. Um,

[00:05:49] one thing that I feel like has been coming up quite a bit lately, which is probably related to what you're working on, is everyone and their brother is building an AI-based tool, which is.

[00:05:58] Uh, usage based. And so you may pay [00:06:00] for credits per use or something like that in advance, and that's sort of a different view of access control, right? You may only get, I don't know, call it a hundred executions of some bit of functionality per,

[00:06:09] uh, you know, payment that you make. And so that's a very different feeling than do you have access to this thing as a user?

[00:06:15] It's do you have access to this thing as a user and have you paid for it and you still have, you know, leftover bits of credit.

[00:06:21] Or Weis (Permit: Yeah. These kind of quotas add challenges both in how you manage the data. your

[00:06:27] authorization layer needs, also in the realtime event driven aspect that you need for it as part of your application, it's no longer something that you can manage statically or you can manage with periodic updates.

[00:06:39] It's alive with the same pace of change of your application, and it's in a performance critical way. Sometimes, like if you were. Allow them to exceed the quota, or if you allow them, or if you allow the quota to be miscalculated when it's kind of in a race condition, it can even really break things and affect the financials. So you need the authorization layer [00:07:00] to not just be well organized and well modeled. You also need it to be extremely performant and event driven, and it's really hard to do if you haven't planned for it in advanced, and if you haven't set the groundwork for that. So a lot of what I try to do when I work with, uh, the community that we've built around our open source project, Opal and around permit as a company, it's not just, um, these tools, it's also providing the best practices and tools to think about this problem.

[00:07:29] I spend most of my time and also the best, like this is what I like the most about my job, talking to fellow kindred spirits and just geeking out on the tech and helping people like myself solve, solve this problem. So it's we, we really try to also bring in the best practices to the table. The decoupling your policy and code, creating a separate microservice for authorization building in and.

[00:07:51] Event driven architecture that will enable you to scale it out and, uh, keep it with the pace of the changing requirements of your application and the [00:08:00] pace of the application itself. Like a lot of people don't realize this, but like in a average microservice application, you need to handle three authorization queries on average for every incoming request. So unless you have something that is ready for that scale and pace, you're gonna have a bad time.

[00:08:17] So, and if you plan for it though in advance, even if you don't build. Even if you don't use any tools, if even you don't use the open source, but you just couple out the things that you need to be independent, like the policy from the code, like the data plane from the authorization engine itself, um, you can save a lot of pain just by having a little bit of foresight.

[00:08:39] Track 1: Yeah. You know, it's interesting. I feel like we, we've dove in headfirst here and one of the things that. I find comes up a lot with people who may be new to building applications that have sort of a user facing feature, uh, of any, uh, form is the, the important difference between authentication and authorization.

[00:08:58] Uh, right. I feel like those things are easy [00:09:00] to, uh, confuse. So, um, can you maybe help disambiguate that? What is authentication, what is authorization and what do they have to do with each other?

[00:09:07] Or Weis (Permit: Yes, of course. I, I do that disin variation basically, uh, three times a day. So happy to do so.

[00:09:13] Track 1: Perfect.

[00:09:14] Or Weis (Permit: So maybe first let's start with identity management. So I am identity management and access control. So you have identity management authentication and authorization permissions. These are all three cascading waterfall like tiers that connect to one another. So identity management happens on the organization side. That's just deciding which identities you have, which are part of the organization, which are not, and what data or attributes or claims you have about them. Then as you move towards products or applications, those users or identities want to consume you move through authentication, which is the main responsibility for that. Is to verify the identity. So it's talking to the identity management, talking to other sources of identity, biometric data, um, uh, one time password tokens that you send over [00:10:00] SMS multi-factor. And that's allowed to determine if you are who you say you are. usually culminates in creating adjacent web token. That's like, uh, it's a cryptographically signed document,

[00:10:12] Track 1: Mm-hmm.

[00:10:13] Or Weis (Permit: kind like your passport that you take with you either in your cookie or in your http enters or whatever else you use to communicate with your end app. And then you go and you get into the app itself and you have your identity and a lot of times additional claims like. You belong with this department. Your current location or residency is this country. Um, and then the application needs to decide what you are allowed to do or not, which is very different from authentication. That's authorization or, uh, permissions. There. You need to evaluate a policy, take in the relevant data of what's happening now and what's the current context like.

[00:10:50] Where are we in the world? What this, which service am I, uh, what are they trying to do, et cetera, et cetera, and come up with an answer. Can they do this or not? And the [00:11:00] challenge there is that that's deeply ingrained into the code, into the product. Unlike authentication that just happens once at the gateway. Authorization needs to happen for every little request interacting with the system. Otherwise, it'll be vulnerable.

[00:11:13] Track 1: Yeah. Yeah. That is a, uh, great synopsis there. And I think maybe the biggest disservice that new developers run into is that we tend to refer to both of them casually as off, right. Problematic, very, very problematic that those two things have different functions and they're, they're codependent and use the same name.

[00:11:31] Or Weis (Permit: Honestly, in defense of every developer out there, the ecosystem hasn't done us any favors. If you

[00:11:37] Track 1: Yeah.

[00:11:37] Or Weis (Permit: it, you, even in HTTP when you, there are multiple authentication methods. One of them is called the Bear Token, and you literally write in the http headers, it's authorization, and then the bear token, the adjacent web token. So for Authe, we are literally calling the authentication, the authorization. So everyone's confused and you have things like O off. And [00:12:00] specifically o uh, oof two, um, which talks about authorization, but it's part of, uh, like in single sign on in, uh, it's how you do authentication.

[00:12:12] Track 1: Yeah.

[00:12:13] Or Weis (Permit: it's really a mess out there.

[00:12:14] I, I think our predecessors kind of, uh, left a lot of technical debt for us to fix. Um, that's, that's being engineers we

[00:12:23] built on the shoulder of giants and on the crap they left as well.

[00:12:28] Track 1: for sure. Yeah. Maybe it's, uh, an opportunity for us that the, uh, the language creates such ambiguity in what we've got going on here. Uh, there's also quite a.

[00:12:37] Or Weis (Permit: I try to call this permissions just to avoid the

[00:12:39] Track 1: Yeah. Yeah. Okay. Actually, that's perfect. So my next question is, uh, I, I feel like I hear people use permissions and entitlements, uh, in, in the same context often, and this is probably something I'm guilty of, that I sort of think of those two things as the same.

[00:12:55] Is that in your world, is that roughly the same thing?

[00:12:58] Or Weis (Permit: So they're very different[00:13:00]

[00:13:00] Track 1: Perfect.

[00:13:01] Or Weis (Permit: but I don't, uh, begrudge anyone confusing them or interchanging them. I think it's okay. It's like we don't need to make a big issue out of it. But if you wanna be, uh, if you wanna be nitpicky, um, permissions are what you're allowed to do or not. Entitlements are, um, Claims or values or, uh, information that can be used to make those deductions. So for example, you can have the entitlement of a manager or an admin in a system that can be even coming from the, uh, identity management that would still need to be translated into an application level role. In the applications that you are providing, and that needs to be translated into specific permissions. So I like to think of a permission as the intersection between identity, resource, and action. So, or a principle. So instead of a identity, if you prefer [00:14:00] this person with this context, or this entity with this context can also be an automated agent. Obviously this entity with this context. What are they allowed to perform this action against this resource or not? Uh, and in, literally in permit. So we really, we really put a lot of effort in building a simplified ux. Part of the cool things about permit is that we have a low-code, no-code editor that generates policies code for you. So we literally took that concept in tri, translated into a table. So when you, you wanna say, oh, I have the permission. Uh, an admin as their permission to delete a file. You literally click a check box at the intersection between file and delete

[00:14:43] Track 1: Yeah. Yeah, that was a wonderful explanation, and I can tell that this is something that you've done more than once, and clearly this is not a part of the, the stack that I, uh, dip my toes into too often. Uh, this is one that I'm gonna keep in my pocket very, very handily as a hey, even, uh, someone who's been around the block a few times, [00:15:00] uh, gets the answer wrong pretty regularly, you know?

[00:15:03] Or Weis (Permit: Yeah. And, uh, by the way, I get these kind of, there's a lot of these little confusions out there, both

[00:15:09] in the implementations of things and all just the names that you have of things. And, um, so what we try to do with that, like, I really just make it approachable for people as much as possible. So I spend a lot of my time, like, I encourage people listening to us reach out to me and like, uh, or WISE, or w e i s on.

[00:15:28] Twitter on GitHub, on LinkedIn, whatever, like, and I'm happy to help. I'm happy to answer questions like even silly ones. Um, so

[00:15:36] Track 1: Yeah. Perfect. Yeah. Thank you. Um, so I'm, I'm interested in hearing maybe some of the basics of about permit then. So, uh,

[00:15:44] Or Weis (Permit: mm-hmm.

[00:15:45] Track 1: maybe let's start here first. Uh, how does it work? Is, does permit essentially work as a middleware? Is it something that you integrate into, um, your API side? Uh, does it, is the generated code something that I inherit?

[00:15:56] How does, how does it work?

[00:15:58] Or Weis (Permit: Terrific question. [00:16:00] So at the core of it, we are providing a policy engine for you to work with. So maybe you've heard of open policy agent opa, or maybe you've heard of Cedar from aws, and there a bunch of others. These are engines that are general purpose. You load them with policy. You load them with data and then you can query them. So we provide that agent for you, bundle up all nicely in a container that you can run it as a sidecar or as a cluster next to your app or if you, and soon it'll be available from aws. You'll have Amazon verified permissions. So that's a service that will be running that agent for you. And we can, and we layer on top of that. So we, but we enable you to run this next to your software and that's very important. For two reasons. Two, actually three reasons. Uh, the first one is latency. As I said before, every microservice application on average handles three authorization queries per request. Even if you just go out to an external cloud, uh, for one, for a 50 [00:17:00] milliseconds roundabout, uh, you'd be killing the performance of your app. So this needs to be as little latency and ideally zero latency. So by deploying the service next to your app, ideally is a sidecar, or at least on the same physical machine, you remove the latency aspect. Yeah. For part, obviously permissions or security is a critical aspect. If that doesn't work, you, you, you don't want your app to work, let's put it that way. So if you're dependent on the external availability of, for example, our SaaS service or any our cloud, Well, you're gonna have a bad time, so you want everything, that decision engine to be able to answer everything locally. this is where our open source project Opal comes in. Opal Open Policy administration layer is a way to keep policy agents up to date with the policy and data that they need in real time. So you opal subscribes to, uh, policy management from permit or your own use of it as an open source project and it fetches the instructions for data and [00:18:00] policies. It needs policies arrive directly from GI repositories cuz we want to manage them as policies, code and data arrives from whatever you needed, including your local database. So this is where the security aspect comes in. You can load data into your authorization layer with permit. Without being dependent on, uh, sharing it with permit at all. Cuz Opal sends instructions on where to get the data instead of the data itself. we now understood the pdp, the container that can, that runs in your app. We also provided hosted, but ideally in production, at least you run it as part of your app. All that's left is for your app to consume the decision point. Uh, via enforcement points. Um, there are multiple ways you can do so. You can, uh, apply it in the code and you can apply it externally, like in a reverse proxy or API gateway. But applying it in the code is the most classic in what, uh, most people do. So we provide a function and SDK function in para basically in every language you want called permit duct check. [00:19:00] receives three arguments and I think will sound familiar to you. Identity, resource, and action. you're basically saying this identity, the identity being the Jason Web token that you got from your authentication, by the way, that's how we seamlessly connect your authentication providers and identity management without having to replicate any of them at all. Um, so you have the identity performing this action on this resource. So in your app, you are describing what's happening instead of describing how you should handle it. You, so you don't put the policy there, you're just doing the description. With that permit, that check flow. By the way, even for people who doing the open source option or doing, uh, completely building on their own, I really recommend this pattern decouple your policy and code and work with identity resource action.

[00:19:45] It simplifies reasoning. It allows you to put this sec the policy separately and it gives you a lot of elasticity with mutating your app or mutating your authorization there afterward. So you put in that permit check, it directly talks to that [00:20:00] PDP that lives inside your app. So zero latency, you get authorization decisions and you're good to go. Now we only need to do is manage the policy. So this is where the para permit, uh, control plan comes in. We have a policy editor UI that I'd like to say a monkey can use, or even a product manager if they're smart enough.

[00:20:18] Track 1: Ah,

[00:20:19] Or Weis (Permit: by the way, the product managers love that joke. I'm not sure why, but they just love it. Um, so we generate code for you. The policy editor is something that you can, uh, do some clicks with. It does both Rback, role-based access control and avac. So you can do very complex policies, but with an interface that you can easily use yourself and obviously easily delegate to other people. This is actually one of the most important things that I think. um, we have permit recognize is that you don't want to do this. Like you don't want to build the policy and take care of it all day. Groom it like a bonai tree. You wanna get rid of the scrap, so you wanna bake something in and delegate this to [00:21:00] the other people. Product security, compliance, sales, professional services, support, whomever, everyone and everyone needs to connect in the end of the day.

[00:21:08] Building access control is about connecting people and systems to what you've built in a secure fashion. and any company building a product, that's what you're doing all the time. So you want to enable all the people around the table to do so without turning yourself into a bottleneck. So that's what that, um, policy, uh, low-code, uh, policy generator does for you. But still, you get off the best practices here cuz it's a low code interface that generates code. So, for example, if you're choosing Rego or Cedar, we write that code for you. Uh, by the way, these are complex languages. They're not like, Um, Python or do, uh, derivatives of data log or prologue. So

[00:21:49] those are basically a rule engine that recursively runs between all of the rules and functions that you wrote. So it's kind of, it's not a run of your me run of the meal, uh, [00:22:00] language. So it also can be a lot of, uh, annoyance just to learn this new thing. So we just take that off the table. You can just generate the policies for you, but they get pushed into GI and in Git you can add more code on your own if you want, you can do code review.

[00:22:13] So if that product manager creates a policy, you can review it. You can do tests on the, you can do benchmarks. So you, while you delegate access to the access control, you don't lose the control yourself. That's something that is very important, by the way, I think with every developer product, every developer, pro product should be very powerful, uh, but easy to use and you can choose on that slider as a developer, how much you want to go deep into the reads, but you never should be forced to.

[00:22:40] You always should be able to, but never forced to. That's my, in general, my philosophy about, uh, dev tools.

[00:22:46] Track 1: Sure.

[00:22:46] Or Weis (Permit: generate that code for you. And, uh, we provide a lot of other interfaces like user management and the audit logs and, uh, interfaces that you can embed for your end customers. But that's, uh, in just a basic concept.

[00:22:59] Track 1: Yeah, [00:23:00] there's, there's a lot to digest there. Um, I think one of the fundamental things that. Um, maybe is a, is a subtle point that I feel like is probably something that permit is using quite, um, elegantly. Is that all authe, um, make sure I'm saying this right, authentication providers who use JWTs,

[00:23:16] uh, is JWT is a secure but also a mutable thing, right?

[00:23:20] Like you can send information within that token, uh, which is important. It sounds like you're tapping into that functionality to be able to, uh, you know, provide the permissions information to enable, um, various scenarios for, for whatever the cases may be there. Um, That is, that's a subtlety that I think a lot of, um, uh, author, uh, yeah, authentication providers don't get across super well.

[00:23:40] Like they tend to say, they dangle it in front of you. We use JW T, but I think the breadth of what that means is, uh, a little trickier than, than maybe not trickier, but a little more, uh, deep than it seems on, on first glance.

[00:23:52] Or Weis (Permit: They, they actually do something that is, that is more insidious. They tell you that they provide rule-based access control for you [00:24:00] and they're doing two major sins at once There. One, they tell you that they've done rrb back for you, so you are done. But then you get that Jason web token and you still need to write code. to actually enforce access. And

[00:24:13] what happens is when the claims change or if the, uh, identity management, uh, for the customer, uh, ends up sending different things, they, you actually haven't built arrb. You've built claims or entitlements, and now you need to process them into your actual policy and you actually need to write code or something to handle that. And the second part is that they're actually confusing the term roles. So there are two kinds of roles here. There's the roles that you have in the organization and the roles that you have in your app, and they're not the same thing. If you were the, for example, the VP of marketing that, what does that mean in the app?

[00:24:51] Are you an editor? Are you an admin? Are you a monkey? What

[00:24:54] does that mean? So the translation, a critical application concept, [00:25:00] logic, translation, needs to happen and. A lot of times they, they try to kind of minimize the difference there. Um, but that actually creates more work for you as a developer. So recognizing that early, by the way, I'm not saying don't use those claims.

[00:25:15] Those claims are great. Those are amazing attributes that allows you to connect to the customer side and have, uh, the ability to build complex attribute based access control policy. but you need to recognize that, that there, that thing that you need to manage that complexity and not just assume that some magic ferry would come in and, uh, make it all work for you.

[00:25:36] Track 1: right? Yeah, that's a fair point. Uh, so I wanna talk about onboarding then for permit. What are, what does your typical, um, use case look like when people are coming to permit? Like where, where are they at in the product development lifecycle? Are they brand new? Are they working on something where they're trying to shoehorn in permissions or are they reworking permissions entirely?

[00:25:56] Or Weis (Permit: So most often than not, it's someone that's already has something in place, but [00:26:00] a new requirement has come in. As I mentioned before, permissions is the gift,

[00:26:03] the gift that keeps on giving. So every three, six months. There's new requirement comes in and you either completely refactor or, uh, refurbish your, uh, authorization layer. Um, and so we do get some people starting from scratch, but most people have something in place and something that we recognize is that you don't want to touch it as long as it's working. As long as you don't have another requirement or an issue, you, you should, I encourage you, stick with what you have. but once you do come to that point when you need to upgrade, Recognize that it's probably not the last time. And then it's a question of how do you best utilize your time to both meet the current requirements and make it easier next time you need to upgrade. And that's, and that's where the best practices come in. Decoupling policy in code, working with policy as code, making it event driven, creating the interfaces for the ever stakeholders. There's a talk that I gave at covering all of [00:27:00] these in details, so I couldn't just Google it.

[00:27:03] Track 1: Yeah, I'll make sure I put a show note, a link in the show notes as well.

[00:27:07] Or Weis (Permit: Sure. Uh, so I don't, I won't go too much in, in the reads into that, but by recognizing that you can really improve things, a lot of times when people, uh, I get a lot of calls, like we have a LY link on the footer of our website. I get a lot of calls for that and, uh, I tell people like, what do you actually need to do now? You shouldn't like refactor everything at once. Let's be focused here. We need to be cost effective, but let's also recognize what are the easy things that we can implement that will minimize technical debt later. a lot of times it can be even something very simple, like, uh, just decouple it out. Just create the microservice for authorization if you don't have one.

[00:27:48] It can be even a, like a lamb function that currently just returns true for everything,

[00:27:53] Track 1: Yeah.

[00:27:53] Or Weis (Permit: can gradually add more logic into it and then switch in place, add, replace it with a different container or a different service, or a different [00:28:00] open source project. Okay. Um, but, but by starting to have that modularity, you do two things. A, you set the ground for what you actually want to build, and you are communicating to the re to the other engineers, uh, about where this is going. Th this is, by the way, the mirror image of this is where most of the pain comes from. By putting the authorization in the app itself, what do you end up having is organic drift where people just, other engineers just add more things into it.

[00:28:26] So you find a lot of these if conditions that have logic, both for the app itself and for the

[00:28:31] authorization there. And then when you wanna change it, you have to cherry pick and kind of go one by one to fix it up. by putting it separate, you are communicating to everyone. This is a separate thing. Don't push your silly if condition here.

[00:28:44] It, it doesn't go here. Uh, so you are also, um, more, uh, dirt or unrelated stuff accumulating there. Uh, and that will also say you work later. You less cleaning to do, aside from just setting [00:29:00] the stage.

[00:29:01] Track 1: Yeah, I have personally done that many times where I've had to go in and, uh, dees up that if statement that I wrote months and years ago or someone else wrote months and years ago, uh, as complexity increases. And I think that's one of those things that, um, you're paying yourself a big favor in the future if you're able to sort of, even just at the early stage, like you said, kind of.

[00:29:20] Plum plumbing and if true, or whatever, you know, a return true statement there. Um, very, very similar weirdly to, to, um, in a, in a recent past life, I was doing developer advocacy at Stripe, uh, and

[00:29:31] changing your pricing strategy, uh, you know, months down the line is an infuriating process if you haven't thought of it in advance.

[00:29:38] Uh, so giving yourself, like decoupling all of the logic of everything so that you can plug and unplug things is really helpful, especially in a world where you may need to test or iterate on things or. Uh, you know, add complexity too. That's, um, that's a bit of wisdom that is not to be taken for granted.

[00:29:52] Certainly.

[00:29:54] Or Weis (Permit: I, by the way, I really love Stripe. We drive a lot of, uh, inspiration from. from the play there. I really love [00:30:00] both the developer alignment and the thought around the how a product should grow and how you, um, not only provide it for the developers, but. For the developers, for everyone else. That's a philosophy that I really subscribed to,

[00:30:14] Track 1: Yeah.

[00:30:15] Or Weis (Permit: one of the features that we ended up creating for permits is something that we call permit elements. And we just reaped up the concept directly from Stripe Elements, right? And so with Stripe Elements, you have readymade UI components for billing, for, uh, like a checkout, for example, that you can abandon your app. And so we've done the same with, uh, With permit elements, these are already made experiences for user management and access control. And actually, when you think about it, these are the main things that you actually do with access control. These are experiences, you know, like things that you've seen a billion times. Uh, user management. With the ability to assign roles, API key management, secrets management audit logs for yourself, for your end

[00:30:57] customer, multi-tendency management approval [00:31:00] flows.

[00:31:00] One user starts from action, another user approves it, invites permission, requests, emergency access, personation, and this list just goes on and on and on and on. So the philosophy is is not unique to any app. Why? Why in the hell should I build this? Why can't I focus on what actually my apps needs to do? So we just provided, already made, you can always build it on top of our api. Again, that's the same philosophy. You should always have the power to do whatever you want. You're the developer, you know best, but if you don't want to, you shouldn't be forced to. And so we provided off the shelf.

[00:31:37] Track 1: Yeah, I think that's very smart. The, um, UX designer part of my brain also really loves that because you're not reinventing the wheel, uh, and you're taking advantage of presumably permit elements. If, if I went in and looked at the UI library, it would look awfully familiar, and just by seeing it, I would be keyed into what the likely functionality of that bit of interface does, uh, which is.

[00:31:58] A wonderful thing because you're taking [00:32:00] advantage of all the deep, you know, ingrained psychology that we've given ourselves from using, uh, software for all these years. Um, yeah, definitely always a good idea to reuse things and not, uh, create, you know, clever, um, parallel patterns for things when you don't have to.

[00:32:13] Uh, so, or we, we've talked a little bit about, um, your product from a. I guess from a ground up standpoint. So, um, really interesting to hear, you know, the, the very basics of where the problem came from and then sort of why, uh, it's important to think about this from the beginning of, uh, building out your software, but then also what it's like to take on complexity and why permit can help with that.

[00:32:35] Um, I, I know, um, There's a lot of developers who will come to this thing with a, okay. I think I fit the scenario you're talking about here. Um, what, what is the first thing that a developer does when they jump in with permit? What is sort of Hello world?

[00:32:50] Or Weis (Permit: Uh, so the yellow world is picking, so per permit is very granular. So you can put pick, if you just apply it to like a single function, a single microservice, a single [00:33:00] route, a single middleware, single application, whatever you choose. So it's about picking the right granularity for you to start. Like, what do you actually care about now?

[00:33:10] What do you actually wanna try? Adding that one permit check and seeing how you change things from the editor, they propagate into get and in real time, propagate. into the, your live application and you are able to change the permission, just toggle one action on and off very quickly. That's the, that's usually where you get it. And, uh, and then you move to like, okay, let's add another role and assign it very quickly. Now

[00:33:36] let's make the roles dynamic and assign it very quickly. Now let's have different, two different applications or two different tenants with slightly different policies. And it gradually, everyone kind of drifts from there into their own snowflake scenario. Um, and it's, uh, it's very easy to start and the end of the day it's just embedding an SDK or potentially a microservice. Um, you don't have to put in the microservice initially [00:34:00] if you just wanna tr test that we hosted for you, but again, please put it in production. It's highly recommended.

[00:34:06] Um, so yeah, that, that's kind of the basic flow.

[00:34:09] We try to keep it

[00:34:10] as simple as possible.

[00:34:12] Track 1: sure. Yeah. When evaluating developer tools, I think that's an important thing, and it kind of keys into what you were saying before, that you should be able to opt into whatever depth of thing you need. Um, but a lot of devs who may be listening to this may need to go sell this to their team as, Hey, this will make our lives better.

[00:34:27] Uh, and it's really, really genuinely better if you can do that by implementing it in a small place and saying like, this is what this thing does in an atomic version of itself. Uh, Can you, like, either we can see the value in this or not, and by not having to go and rewrite your entire application structure, your entire, uh, API stack, whatever it may be, you at least are able to have the discussion and sort of sell that to your PMs or, uh, business stakeholders wherever the case may be there.

[00:34:52] That's, uh, a very, very helpful set of features to have.

[00:34:55] Or Weis (Permit: Yeah, you also wanna build confidence in this on your own. Just

[00:34:58] as your, as a [00:35:00] professional, you wanna say, this is something that I trust. This is final thing that has the performance profile that we

[00:35:05] need. This would actually have the features and, uh, interfaces that we need. So we also encourage our people to run this side by side with their existing, uh, authorization solution.

[00:35:14] Initially, don't actually gate, don't actually enforce the fossil. Just

[00:35:18] see that it produces the same result. At the same pace as what you already have in place, then you gradually build confidence. Sometimes people would give it like a couple days to run. Often they don't get to that. Like they see that it works and they start running with it. But it's malleable enough for you to pick the, the level of trust that you have and gradually grow it and see that it doesn't bite your back just because you deployed it.

[00:35:43] Track 1: right?

[00:35:44] Or Weis (Permit: very email thing. Right.

[00:35:45] Track 1: Yeah.

[00:35:46] Or Weis (Permit: and we've actually, when it comes to. making this more relevant for the bigger team. Uh, this is where a lot of features that we have that people don't necessarily think about when they're building [00:36:00] authorization come in.

[00:36:00] And those are the cur features of authorization for authorization or

[00:36:05] permissions for permissions or roles for roles. for example, we have a concept called a project and a concept called an environment. These are silos for your policy and data. A project would be an application that you run and you can have different applications with different policies. An environment would be a separate deployment of, uh, the same application also can have, you want different policies in staging than you have from production, for example.

[00:36:30] Track 1: Sure.

[00:36:30] Or Weis (Permit: Um, and you can assign specific access to specific people to specific deployments. Um, so for example, and that also enables kind of more complex r and d patterns as opposed to individual comp, uh, contributor patterns.

[00:36:45] So for example, you can say something like, um, as part of our preview branches, we, every time we deploy a new preview branch, um, we want to create an environment, a deployment environment thread, and we wanna control the access to it as well. So use our API and you create a, [00:37:00] uh, permit environment and you assign access to it only to the developer that deployed it. And so suddenly you have these dynamic patterns that are very easy to use, that are not just about these, uh, uh, permissions and access control for your app, for your customers. It's also how you as a developer with your team work on this in a way that you don't st stop on Trevor's toes. And these are the things that, that, hey, it's really hard to build on your own or even realize that you might need,

[00:37:29] Track 1: Right. Yeah,

[00:37:30] Or Weis (Permit: I think, a big enabler for developers to work on the, as a team on these things.

[00:37:35] Track 1: I can certainly imagine why it makes sense to spin up an entire product around that too. That's represents a level of scope creep that started from, Hey, we need two different types of users to, uh, you know, an entire galaxy of permissions and complexity that comes along with that. It's super fascinating.

[00:37:48] Uh, so tell me about what's next for permit? What are you working on now?

[00:37:52] Or Weis (Permit: Uh, so we're working with something very exciting that is, uh, Um, I think, uh, even a little groundbreaking [00:38:00] and, uh, also kind of puzzling. It's called uh, ez, which stands for front end only Authorization. which, uh, I think only by the, that title, like front end only authorization, like that sounds like an oxymoron because how can you have authorization something secure in the front end? Um, and the, the reason the explanation for that is it's front end only, just like, uh, serverless has no servers. So

[00:38:27] we provide basically the, uh, backend component that will do the authorization for your front end. But the idea is that you'll be able to consume sensitive APIs directly from the front end without writing any backend code. And I'll explain, let's say you want to use, uh, Twilio to send an sms. Or strive to send an invoice, or you wanna talk to a chat bot in Slack, you wanna do this in your front end, just one, click a button. The user clicks a button, and that happens. Currently you can't do that. You have to [00:39:00] write backend code.

[00:39:00] It will add the secrets. We'll check for permissions and we'll actually call that external service. Otherwise, if you put that. In the front end, it's exploitable. Um, first of all, everyone's gonna steal your account key and second, they'll just circumnavigate your permissions cuz they're, they could just edit them in the front end. So what do you usually do is you, if you're a front end developer, you go and ask a backend engineer to write this for you. Or if you're a full stack or you're savvy enough, you'll go and write backend code in addition to the front end code that you actually want to write. Uh, but with FOAs you can just take that off the table cuz Foaz is a generic purpose, um, implementation of that backend component.

[00:39:41] They need to write. So it includes

[00:39:44] the, our policy engine that can do any enforcement that you want on when this is okay for the identity running in the front end. Now to consume or use that external service. And you can apply the application logic, not just the end account, like the Twilio logic, the [00:40:00] actually what it means in your application, and it injects the secretes that you need for like the token for the, for Twilio or Stripe or whatever. And then proxy is your call. From the front end to the actual end service and returns the answer to you. So you can securely use that from the front end without giving up any of the security, while not having to write glu code, which is like literally, uh, the amount of time people wrote That line of code adjusted proxies things to Twilio is, uh, I dread, I just dread the thought so much wasted time. Um, And by the way, also, this also applies for your own code. Let's say you have a backend service that you want to consume and you want, you want to let people use, but you don't have the granular permissions that your customers want there. ideally, you'll end up embedding permit into that service. But let's say you don't wanna open it up right now, you just want a quick solution. You can apply for as, as a gateway there as well. So you can slap on [00:41:00] permissions on whatever you need. and focus on what's important for you now, but gradually already build up, build up that, um, groundwork to scale into a more complex permissions model. So, so that's, that is for as front end only authorization, and we are launching it soon in two ways.

[00:41:17] One, as a standard, as an open source standard and how you take general purpose decision engines like opa, couple them with Vault solutions to manage the secrets. Um, and with a proxy that will do the actual calling bundle those together with this standard and the schema and APIs we offer. And this, uh, and you can implement foz on your own and obviously is a service that we just provided.

[00:41:40] We have this proxy component. We have the, uh, management APIs and management UI just get started and consume all of those, um, uh, sensitive services directly from the front end. And I think this is also. very empowering for front end developers. a you're in, you have [00:42:00] less dependency on the backend and backend engineers. And I think it finally, and I think this is important and finally brings front end engineers into the actual conversation of security. You're not just tagging along with the rest of the org. You can actually lead that conversation. I think that's important. We need like, Security is something that is really based on the weakest link. And if we

[00:42:25] have places where the, the conversation around security is not strong enough, this is where those vulnerabilities are going to arise. So we need to embrace everyone into that conversation and hopefully this will enable front end developers to do that.

[00:42:39] Track 1: Yeah, sure. I can think of a lot of devs who will be happy that they don't have to think about splitting things out to the server side. And, um, it's also an interesting problem for, um, devs who are learning the ropes, right? Where it's not obvious when you come up with an idea for like, oh, I wanna build this simple project for whatever it may be.

[00:42:57] Uh, and then one day you stumble into, oh, I, [00:43:00] you know, I, what does the secret key mean? Why is it a secret? Who is it a secret from? And you suddenly realize that you've left yourself open to attack and things like that. Um, generally speaking, right to date, certainly the, um, path to take for that is to go spin up a server somewhere or to use a lambda, or in some cases an edge.

[00:43:17] Uh, edge deployment to be able to execute that code. Um, why do you think it's, uh, interesting to do this now and why is this, um, an important use case to start tackling?

[00:43:28] Or Weis (Permit: So first of all, we are seeing an emergence in this, the entire IAM space as the complexity of software continues to arise. This entire space with us and regardless of us is constantly evolving. We're seeing new products come in, as also we are seeing more threats come in. Um, applications become more complex, they also store more value and more data, and more people want to, um, take advantage of that. the risks that we are facing are also on horizon. This entire space as a result of that, is also on horizon. So, [00:44:00] and then that's basically supply and demand. More engineers need these things. More engineers need to build more of these things. More engineers need more velocity against this, these things. So they wanna just build their software, but they're stuck building all these security features, all of this glue code or, um, security additions that need to that. So, want to simplify that. We wanna take it back to basics. We wanna enable the front end code to focus on being front end code and easily consume the services without having to build the actual security components, but be able to consume them. Um, so I think, uh, at the basics, just supply and demand. And for us, we've already built this general purpose, easy to manage, uh, policy engine that you can do all the policies you want with, uh, as I said, an interface that a monkey can use. Uh, so that really can take that friction off. And this is, I think what you want here is a front end developer.

[00:44:54] You want the velocity to build your app without a hassle. So that's what we're bringing to the [00:45:00] table.

[00:45:00] Track 1: Yeah, maybe it'll allow my fellow front end developers to stop needing to call themselves full stack developers to get any respect around here. Uh, you know, especially now that GitHub co-pilot is, is able to cough up people's, uh, dirty secrets in their code, like, uh,

[00:45:14] I think that was one thing that was found pretty early on is API keys that GitHub co-pilot knows about from someone else's environment that actually got, accidentally got committed to Git and all that.

[00:45:22] Um, yeah, it's a super fascinating use case. So you, you're in early access right now? Is that what you said?

[00:45:27] Or Weis (Permit: Yes. So we we're launching it for everyone very soon. Maybe when this is launched, it's already when this, uh, podcast goes live. Maybe we've already launched it. Um, but otherwise it's very, very soon. And, uh, for those that want early access, there's a button on our website. Uh, sign up and you'll, you'll get that access as well.

[00:45:47] Track 1: That's great. Well, I will make sure that we also have a link to Foaz in our show notes here. Uh, and it sounds like, or you're a pretty accessible guy on the internet. So, uh, for for listeners to the show, I would encourage you to reach out to or, [00:46:00] um, it's, uh, been a very, very fascinating conversation and I think you're under some really cool stuff.

[00:46:05] Uh, at permit. Uh, I would be, uh, more than interested in chatting with you again in the future as things develop and as the I am space tends to keep changing too. Um, or Weiss, thank you so much for joining today. It was really a pleasure to have you on APIs you won't hate.

[00:46:18] Or Weis (Permit: Pleasure, Thank you, Mike. Uh, look forward to, uh, staying in touch

[00:46:22] Track 1: Thanks again. We'll do it

[00:46:23] Or Weis (Permit: everyone don't Yeah. Reach out

[00:46:26] Track 1: All right. Thanks Laura. Take care.

[00:46:28] Or Weis (Permit: Take care. Bye-bye.

[00:46:29] Track 1: Bye.

[00:46:30] ​