1:48 Introduction and Why Identity is Hard

1:48 Hello. And welcome back to the Rawkode Academy. I'm your host Rawkode, although sometimes known as David Flanagan. Today, we are continuing with Rawkode Live where we take a look and get hands on with open source software and the cloud native space to help make your lives a little bit easier. And, you know, for a second there, I forgot entirely what I'm doing and why I'm here. However, we're gonna be taking a look at a really cool open source project today because it solves a very difficult challenge. And I'm sure if you're watching this, you've had to implement

2:17 identity and authentication at some point in your career, probably many, many times. Fortunately, that is a lot easier today. To guide us on our journey of Zitadel, I am joined by Florian. Hello, Florian. How are you? Hello. I'm doing great. Thank you. Awesome. Can you just start and tell us a little bit more about you? For sure. I'm Florian. I'm CEO and and cofounder of Zitadel. And, I mean, there's many reasons why we built Zitadel, but one of which is we don't want to give people the pain that you need while building your own authentication authorization solution because there is, like,

2:36 Guest Introduction and Zitadel Origin Story

3:01 a lot of things to it. Right? So it's not just two input fields and the button because that's an absolute running deck. There is way more depth to it. And, yeah, we try to take a lot of that pain away from people. Yeah. I mean, surely, off end is as simple as a form and submit and then insert into user's username and password. You know? We don't need to worry about that crazy and hashing stuff or anything like that. Right? Well, that's certainly off for a good start. Yes. I mean, you can all already discuss

3:31 what hashing algorithms are correct and how to use them properly and what salt and what cost. And so, that's that's where the party starts. And that's not even without touching the new stuff. Right? Pass keys that's around the corner or many many already rely on and OTP and what kind of OTP there is. And so there is, like, so many flavors, and you can do so many things wrong. And I think it's specialization in-depth that's kind of the the the brilliancy behind the whole authentication and authorization and identity topic in general, and that's what we specialized in, basically.

4:06 Yeah. It's it's definitely one of those areas of software development that I think you're better just offloading that pain to someone else like you. Right? Because I know we joke, but it's just a username, a password, save it at database rate. You've got fine. That's that may be v one, but it's definitely not something you ship into production. That may have been cool in 1998, but not so much anymore. You also mentioned passkeys, which I think they're very exciting. And but supporting them is a bit of like the Wild West right now. I'm hoping you're gonna show me something a

4:34 bit more nicer. There's also hardware tokens. There's OTP. There's time based OTP. There's an OAuth too. So, you know, I I still see people getting all of this wrong today. You know when you go and you sign in to a website and it's like, okay. Log in with Google. Oh, shit. I didn't use Google. Okay. Log in with GitHub. They're both the same email address and I end up with two different accounts and it just all ends up confusing and I'm just pulling my hair out going, this has to be easier. It Zitadel's gonna solve all of that for

5:02 me. Is that right? For hopefully. No pressure. Honestly no. No. I mean, at least that's what you aspire to be. Right? I mean, it it's like I think sometimes of Citadel is like the stripe of identity. We try to keep the pumping work away of people who just want to build their applications. And, I mean, as soon as you start serving to enterprise customers, things can get really weird. Like, then you need to have support for SAML, and SAML can be weird. There is not even, a proper certification framework. And so there the that's why I said there's so many

5:37 moving pieces in that stack that I and that's my certainly a biased opinion, but I would rather use something that's predefined and brings brings a lot of the stuff Turkey with it rather than just building it out in whatever framework I have lying around. Even though I must say good things on on some of the frameworks out there. Some of them are doing really well made stuff as as long as you have, like, a tight scope. As soon as it gets broader with further integrations, it can get tedious. Awesome. Alright. I'm gonna go off on a tangent first

6:11 Zitadel Branding and Aesthetics

6:13 and then come back. But I just wanted to say, I have taken a look at a lot of tools in this space. And what I love about Zitadel that's different from all the other kind of awesome providers that I've seen is that people might think identity is hard and is enterprise y and it's no fun and that it should just be, like, black text on the way back around and boarding. But the Zitadel branding and the aesthetic, I just thought was absolutely top notch. I thought that was breath of fresh air. So I just wanted to say, like, kudos. That

6:44 would I love that. But let's get back. We could we could we could talk about who who the name is, the person on the team that does, but whatever. I wanna know what your background is and how you got into building open source company around identity. Sure. I mean, originally, I was a vehicle electronics engineer, so I I built yeah. I I honestly, that's kind of where where we all started. I I built and repaired electronics in vehicles, especially trucks and stuff and and first responder vehicles. And so there you had well, you should have a lot of security,

6:53 Florian's Background and Motivation for Zitadel

7:23 basically, but that well, there was not so much security in there at that time. And I thought, well, I don't stick to that area of expertise for too long because you get dirty hands. It's it's clam. You'll get snow on your head if you try to lay under a car. So, yeah, it was a nice time, but I I switched carrier pass after that. Basically, I I did some military service and then went into the whole we call call it IT at that point, where I did a lot of system engineering, basically. So mainly the networking stuff like Cisco at that

7:57 point in time. I got some certifications rolling, and then I I once again switched carrier paths to the software side. So, I mean, yeah, there's, like, a red a red line through all of that because can be programmed, switches can be programmed to some extent depending on the vendor. And then I switched to to companies who actually build software. And after some more project driven companies, I ended up in a company in Switzerland, which built services for the public sector. And there, I met the team that actually built and operated identity systems for the public

8:33 government. So first responders that needed to log in somewhere to check a citizen's record and such things. And during that time, the team and I, we identified a lot of problems around the existing solutions in the market. I mean, like, the Keycloaks and Fortrox of zeros. And we thought, why don't we just do better? And since it was like the rise of Kubernetes was really going at that point in time, that was basically 2016 where, yeah, the hype just started, we thought, why don't we build a cloud native identity infrastructure tool that is open source, that behaves well

9:10 on containerized platforms, and is more optimized for developers than the past tools. Right? Because the past tools, in our opinion, at least, were mainly focused towards IT guys. And we thought, well, we should have better APIs, and so let's invest some time on that end. Yeah. That's basically the origin story of me and kind of Zitadel as well to some extent. Awesome. I don't know why my camera keeps losing focus, but hopefully it fixes itself. Awesome. I'm assuming whether it be in a cloud native identity management solution, it's written in Go. Is that a fair assumption?

9:44 Technology Stack and Operational Advantages (Go vs Java, Keycloak)

9:50 Yes. It is. Mean Yeah. I mean, that's that's that's a good thing. I mean, it better if it is Rust, but I'm not gonna split here. It's right. But we you know, Keycloak was amazing back in the day. But running and operating Java, especially in containers on Kubernetes, is is really, really painful. And just having something that is I'm gonna say modern, but I don't mean that Keycloak is, like, integrated or anything, but, you know, built on more modern technologies. And again, I don't mean the Java. In fact, you know what I do. Java is old

10:18 and crap. I don't like it. So someone's gonna yell at me for that eventually, but that's okay. Oh, they did already a lot of yelling on our end too. Actually, I mean, to be honest, we took a lot of inspiration of Keycloak, but there were some concepts that were fundamentally blow broken to to what we thought, like that amount of realms you can run-in parallel and and how you need to configure and set up Keycloak to keep it scalable. And, I mean, in the past, you couldn't even do, like, proper zero downtime upgrades. And so there was a lot of operational

10:52 hustle in in in Keycloak, which we try to to solve as well during the process. And, yeah, the language was just one means of getting there. It has some some nice benefits go, but it also has some drawbacks. Right? So I'm not going to sugarcoat you too much there because there is a drawback, and we'll come to that as we we talk about how Zitadel is built, about about what what things we experienced during that initial build phase. Alright. Awesome. Well, let's cover just one more thing, and then we'll get on to the hands on component, and we'll actually show people

11:24 Open Source Model and Cloud Offering

11:27 how to get started. Zitadel, we said open source more than once now, but I I I wanna clarify. Is Zitadel you are a SaaS based company, so you do offer to manage all of this for people, and they can sign up for Zitadel cloud and get started without installing or running anything. But is it open source? Is it open core? What is your business model, and how do you work with open source community? We we think the everything related to authentication and authorization and audit capabilities and getting your data out of an identity system needs to be open.

12:03 And to the point in time, we run the same code in our cloud service. Our paying customers run the same code as the open source version that you can fetch from GitHub. So right now, everything is an Apache two license and fully open source. And I can tell where we will draw a line down the future will be things like analytics and and and reporting stuff because that's where we think we can provide value add stuff for for paying customers, basically. Because there is a lot of interesting data buried in identity. You basically get the high quality data pinned

12:38 to a user, and you can tell what happened with a user in the past, where he locked in from, what what what user agent he had, and all such things. And that can be used in a positive way for our customers. And and I can tell you what what's in there because that's a a huge bag of interesting features. But right now, the the as is state is really like is full blown open source deployed wherever you want, however you want. And if you're big enough and interested in a support contract, please call us up. There is a

13:08 contact section on our website. Or if you don't want to hustle off of operating Zitadel, well, use our cloud service. There is even a free tier that you can use to to get basically rolling with your project. Awesome. Alright. One last thing. I know I keep saying that, but I love that you give that history. Right? You went from a physical engineer, you went, no. Fuck that. I like it. To doing government jobs. Oh, no. Wait. Before that, you did networking. Right? So it's Cisco and CCNA and you went, no. Fuck that. CCNA went to the government, and then you did identity.

13:24 Getting Started: Self-Hosting with Docker Compose

13:43 And then you went, oh, identity in SAML. That's my jam. I mean, you know, you're a certain type of crazy. But But but in all honesty, XML is not exactly my favorite choice. Somebody needs to do it. Right? Alright. Well, let's dive into the crazy rabbit hole and take a look at Zitadel. So I'm gonna pop my screen up. We're still here. Amazing. This is like I said, the aesthetics on this are just very nice and the logos is lovely too. It's not important to the software, but it always makes me smile when I find a good really

14:20 good landing page. Thank you. And it's also pass along the celebrations there. Yeah. I'll go to pricing first. So, yeah, here is that free tier. So, you know, if you like what you see today, definitely go to .com. Jump in. You get a free instance with all the security features, and it can have up to 100 daily active users, which is probably adequate for most of but it's adequate for all my projects times 10 the activity. So that's pretty good. Let's go to documentation, and we're gonna work on the getting started guide for today. So I haven't looked at this. I always

14:58 like to come into it with a fresh set of eyes. So we're gonna be I have no I have no idea what we're gonna be working through, but I'm assuming we're gonna have some sort of random website that we can spin up where we could integrate Zitadel and get some sort of authentication system up and running all in Yep. Less than six or seven hours. Right? For sure. I mean, I would I would say we start with a self hosted Zitadel. Right? Because the the core message here is kind of yeah. Just use the open source

15:24 project. And you can simply start it by going on the top corner. There is navigation with self hosting. Yes. Perfect. And then I I would advise we use Docker Compose because it's basically the easiest to get started with. And the point blank, you can download that file and Docker Compose up the whole thing, and you should be ready with Zitadel that runs a CockroachDB in this case. We support CockroachDB and Postgres. It's a matter of choice, actually, or what you prefer. For the sake of simplicity, we use your Cockroach, usually. I I I default to Postgres for everything

16:01 Database Choice (Postgres vs CockroachDB)

16:03 because I've got twenty years of operating it, and it's and I know how to manage it. Cockroach is always one of those things. I'm like, it's really cool. I know it's got influence from Spanner, from Google, which means it's very, very cool, but I just haven't dived into it enough to really take on the operational responsibility yet. So Yeah. I mean, we're we'll just work on an article where we compare Postgres and Cockroach and some learnings from our operational side, operating the cloud service. And, yeah, that should come, yeah, I guess, in the next few weeks from our end

16:35 to explain more in-depth on when to choose what because, basically, both have their strong suits and weak suits. Right? Yeah. Alright. So we do have a dark horse pose. I'm already happy because it's under 40 lines. A million investors key cloak, I would be 400. So let's see. I will remove your restart because that's that's wild. Go away. Go. Put the custom away. I also just I don't need to do this, but I'm just doing it because if I were doing it if I were doing this on my own and I didn't have people watching,

16:44 Docker Compose Configuration Details

17:14 I would be like, why do people do the less syntax for environment? Because it loses the the syntax highlighting. I don't know why it's like, why would you do this? Anyway I need to ask my colleague why he did this actually. That's a good question. Yeah. That's that's all great. We need a 32 character string. It's just the master key. That's fine. We've got Zitadel network and Yeah. Everything down there. So we're using nice 3.8 stuff. We've got service healthy. This this is a nice Dockerfile except for your environment stuff. So I would say, p o's welcome since we're

17:50 open source. I I think I've also met that pull request. And I'll have, like, a forward paragraph description of why we should do it this way for a two lane change, but still. Yeah. So we'll let cockroach d p get healthy. Yeah. And then That should take out Yeah. Ten seconds. Ten ish seconds, Zitadel will do, like, the migrations here. And, yeah, as soon as you should see the Zitadel thingy, it's basically ready to run. So you can click the the URL there, and it should bring you to the management UI. At least that's what it should do.

18:15 Accessing the Zitadel Management UI

18:29 Perfect. And if you go back to the documentations page, there is the default user somewhere exactly. There will be Aviso that one point in time, but you can pass the configuration to to predefine that stuff if you want. Yeah. So I'm disappointed that your default password is password one exclamation mark and and not a hundred twenty two. I was very disappointed that in the last two weeks, bash dot org is down forever. I don't know if you ever used to read bash.org, but I I grew up with bash.org. I I I did from time to time.

19:05 Yeah. You can skip on the left lower left if you don't wanna set a multi factor off. I mean, for the sake of you can you can't just you can skip it away if you want. Right. Okay. We'll we'll do it. And then we need we certainly force you to change the password. What kind of security product would we be if we don't? It's like I have too many passwords stored on this local host and it's all I mean, they're the market so quick. Classic. Oh. I guess you you violated something. What was it? Perfect. Should work.

19:16 Initial Login and Password Change

19:53 So that actually password is invalid usually means the original password is invalid. Yeah. I probably typed that wrong. Perfect. Now it should basically give you a spin. Perfect. Off you go. Zitadel is running, basically. I mean, there is a lot of things you need to consider going to production. Right? But from from getting started experience, that's as as quick as Zitadel can be operationalized locally. Alright. Well, thanks for watching, everyone. We'll see you next week. Done. I I do like I mean, obviously, I'm not gonna run a docker compose file for any sort of production deploy. But again, this

20:12 Zitadel Instance is Running

20:37 is a Go application. So it's probably even easier to get it running. And then it's just about making sure that that database is backed up and you've got your store processes, all that operational stuff. But I love the simplicity of getting that started. And that master key, I'm curious. We passed in on the CLI. Can that read from, like, cloud KMS systems? I mean, what are my other options to keep that secure? I mean, you can pass it in usually, we recommend passing it in as RQ because all the other things are passed as environments,

20:52 Master Key Security

21:10 and so it's kind of easier to get the separation of concern going. Honestly, it's just an additional layer of security because some passwords in the database the password, but some secrets in the database are encrypted in an asymmetrical way, like with a s in that case. And it's just an additional safeguard if your database leaks. Somehow, you you do not leak out all the guts of of your Citadel. Right? So Okay. It's just more that because one one example that we use symmetric cryptography tool is for the private keys that we use to to sign jobs tokens,

21:47 for example, or the certificates for SAML and stuff. Mhmm. That's where what it mainly does right there. Okay. Alright. The onboarding process wants me to create a project, register my app, and log in to my app. So let's crack on. We'll call this the Rawkode Academy. I have a project, roots research ID, applications, rules, grants. Alright. All that fun off stuff. Yeah. Yeah. We can talk in a minute about all the the underlying concepts there. I would I would advise we quickly run, like, an OAuth proxy, for example, and that can be used as an example application,

22:22 Choosing an Example Application (OAuth Proxy)

22:30 or we can use a Vue application, or we can use a Grafana or whatever is to your liking. I I usually tend to use it for an an external tool like OAuth Proxy because it's just the binary on the config file and does a great job for showing people how how they can work. Yeah. Well, I'm assuming we have to create an application first. Is that correct? No? Yeah. That means you need to know what application. When we settle for for an OAuth proxy, yeah, go away and and create create a new application right there. There is

22:51 Application Types in Zitadel (Web, Native, SPA, API, SAML)

23:01 a wizard. We we try to give people, like, a little bit of guidance because if you click on new there, you see, like, multiple things there. Right? It's like web application, native applications, user agent, APIs, and SAML. The reason being, like, web application is your classic web application with a server rendered engine. Native is when you're using mobile apps or desktop apps, and user agent is basically the good old single page application. The API is kind of special because, yeah, it's for for back end systems. Like, you get the token, you want to do something

23:38 with it. But in this case, we stick to web application that works perfectly. Want to do SAML? Oh, no. I don't. I even though it's it's it's a thing. Yes. But I if you could skip it for today, you know, I I would advise doing that. Otherwise, we'll we'll be around midnight to to to do the metadata exchange. In this case, let's pick code here that works great for the the OAuth proxy. I'm just I I can explain the differences if you're interested, but let's let's keep it tidy for the moment being and dive after

24:02 Configuring the Application in Zitadel (OAuth/OIDC)

24:12 that into it again. Okay. Alright. Yeah. Just continue here. You because we can we can change that afterwards. It's fine. Alright. So So you get two values like there. You should copy them, especially the client secret. Otherwise, you can regenerate it. Perfect. And then let's go to trust the OAuth proxy. You should find it on on Google by quickly because we combine can combine multiple things here. Right? Yeah. Perfect. That's the thing. There is a download guide on the website on the yeah. On the on the yes? Nope. Nope. Not oh, yeah. Okay. No. It works perfect. You can download the prebuilt

24:58 binary or use Go, whatever suits your taste here. I often use the the prebuilt binary quickly. I wonder if it's in package x, which I I always check everything now. Is it off to a proxy or off proxy? It is. That's a good question. I have never checked it. I could think there is no. No. I like it. I'm I've I've become like, I used to use Knicks for all my local development environments, and it's just I just got so frustrated having to write Knicks myself. And then I discovered Package X, which is like a project from the person that originally

25:07 Setting up the OAuth Proxy Client

25:35 built homebrew. It's like reimagined homebrew, and it's it's really nice. I like the way it works. So Sure. Alright. We have a proxy. Perfect. So we have a planer at least. Yeah. If you go back to their page and the OAuth proxy page, there is an OAuth provider configuration. Yes. Go go ahead with this one, and then let's select the let's use Okta's. So there is oh, somewhere there is an Okta configuration, isn't it? Oh, there's OpenID Connect. Let's go with OpenID Connect. That's fine. Let's scroll down a little bit because we're gonna use a config file. No. No. Go

26:13 to scroll a little bit downwards. Yeah. Let's let's copy the this thing here. That's perfect right there. Yes. Because that's basically applicable to Zitadel as well. Perfect. So now let's call the the redirect URL there. Let's do HTTPS, And and I think in their guides, they use I mean, if you can you quickly go back to the your example? And a little bit upwards to the OpenEye Connect example. Yeah. Let's let's use the redirect URL there because that's the default port for Rawkode proxy, if I remember correctly. Perfect. You missed an h, but no worries.

26:58 And on the OIDC issue, you can use HTTP local host in our case because we don't use a DEX. We use Zitadel. But that's basically exactly local host eighty eighty. Yes. That should be fine. And then upstreams, let's use HTTP bin. That's basically where the OAuth proxy will send traffic as soon as it authenticated us. And email domains, you can use citadel. Local host. Perfect. And client ID, client secret, you just copied right before we switch to here. Perfect. And then I think the the cookie secret needs some c's more. That should be 16 bits, so just throw in, like, 11

27:31 Configuring Redirect URIs and Development Mode

27:55 c's or whatever. Yeah. Perfect. That's basically it. Now the redirect URL on on row two, that's that thing you should copy. Perfect. And then let's switch to Zitadel. And you have the redirect settings. Exactly. Throw it in there. Press enter. I I you need to to press the plus sign or press enter. I know. UX and bad. The development mode needs to be activated, and there is a reason for it. The in in in yeah. The specification basically demands to use HTTPS, and we don't want people to to fire away their production into whatever weird state they can they

28:49 can get it, and that's why we have, like, a development mode. So you need to turn it on to get an unsafe configuration rolling in Zitadel. But after that, you are fine to do whatever you want to do. It's just an additional safeguard for people. Yeah. Then let's save it. Perfect. No changes. So it should be already saved. Right? Yeah. Cool. Yeah. So let's start there at the OAuth proxy and see how it goes. That's basically it should be, like, OAuth proxy and then minus minus for configure, I guess, or something like that. Call that. Oh, no. I called it Rawkode.

29:18 Running the OAuth Proxy and Testing Authentication

29:32 Oh, could see I need some more bytes. Yeah. It's a classic. Whatever you throw in there, just two bites and off you go. Perfect. So, yeah, let's browse to local host 4178, I guess, off the top of my head. 4178, I guess. Right. Or is it not? Oh, I just quickly need to check the configuration. It's not written here. That's kinda bad. But 418. Yeah. Alright. Yeah. Wrong window. There we go. 418. Perfect. Forbidden. So if you click sign in here, we should do the good old OpenID round trip, and off you go. You have authenticated

30:30 with yourself with Zitadel. Right. Right? That's all it took. So what OAuth Proxy basically does here is it allows traffic only through when you have successfully authenticated with Zitadel. And if you go for your terminal in that case, You should basically see here that somewhere your user should be written out. Where is it? Is it I I it's in the lower third. There is, like, authenticated view of session, email, Zitadel, yada yada yada. You see that. Right? Yeah. Okay. I wanna I just wanna make sure I understood all this. Okay? So because that I mean, obviously, that all worked

30:36 Explaining the Authentication Flow

31:16 rather fast. So Yep. I mean, what we What we're that's 4188. What we did there, right, is okay. I don't need to sign out. It's just temporary authentication. Yep. What I want to do is log out of Zitadel Yep. And click sign in here. Okay. Cool. So what we've what we did was we set up Zitadel as an OAuth two provider. It's not going to other external subparity provider as the source of authentication. In which case, it was using my account here, which is currently signed out, where I can log back in, and it's gonna give

31:53 me back a token, and I'm now authenticated again. Okay. Yes. And I mean That was painless. Right? And you can do, like, many flavors of it. There is, like whatever I mean, we can plug in a view app. We can plug in a Symphony app. There is multiple ways of of attaching applications to Zitadel. And that's just for for the sake of simplicity. Yeah. Many prebuilt tools use, like, OpenID Connect or OAuth. I mean, that's kind of an overlapping term. There is a a proper differentiation between the two, but for the lack of better management, let's keep it like federated

32:36 authentication. And and those tools just rely on Zitadel on doing the authentication piece. Right? They get basically a code back, and with that code, they go to Zitadel and get back a token, oftentimes an ID token, an access token, which they can use then if they need it to communicate with another service or in that case, the proxy says, well, you are authenticated, mate. I I let you through and off you go. That's the that's the piece in in how fast it can go. It works also with Grafana. They have an OAuth provider. It works

33:09 Building Custom Login UIs

33:11 with GitLab. It works with many, many different systems. And, also, it works with language frameworks like Angular, Next, and and and multiple others. But that's not all Zitadel can bring to the table. And because that's just one protocol here. Right? Mhmm. With Zitadel, you can even build your own login UI, like the the thing you saw with the the the username password thing. You can build that on your own if you'd like to. There is an API for that, And and we can even, like, deploy a quick demo later on on on Versal or something like that where you can self

33:45 host the login page as well. But that's the the appeal of Zitadel, basically. So now we can talk details, I guess, or dive in any direction you want or we want to dive into. Yeah. I mean, there's a different a few different avenues we can do down here. Right? I think what I love is that in under thirty minutes, we've got an OAuth provider running, doing identity management for an organization, a team, a product, whatever you want. Yeah. And I have successfully logged in right off the bat. So we already seen the setup process. We created a project. You know, we

33:51 Core Concepts: Instances, Organizations, Projects, Grants

34:23 we can see that we configure the applications and how those all communicate. Let's talk about some of those security considerations that also come from you know, if I'm gonna roll my own identity solution, auditability is gonna be really important. So what is Zitadel given me to help me understand how my users are consuming and working with the projects that I create? Well, that's where the funny piece of Zitadel comes into play. It's we built Zitadel in a kind of unique way for the identity industries. For all those who are interested in a topic, it's basically based on event sourcing and

34:30 Audit Trail and Event Sourcing Architecture (CQRS)

35:00 and CQRS. So we truly separated the the writing side of the system from the reading side. And there is a lot of material on on reading up all those those two patterns. But the unique reason we chose basically to use event sourcing as a concept is that we have a perfect audit trail, so to say. We know what happened in the past. And we can quickly visualize that if you go on the right top corner of Zitadel, there is an instance button, and that's basically the root level of Zitadel because it it is has multitenant.

35:33 And in in in the top navigation, we have events. And if we could go there yeah. The event thingy. And that's basically all the things that happened in Zitadel so far. And you can filter them through different things, and and you can also look at the payload on the on the right side. You can expand the events. Yep. I mean, UI wise, it's not super, but somebody needs to improve the UI. Thing is, you can also get those information out through an REST API or a gRPC API in our case. And that means you can filter out whatever

36:12 your users did on whatever they did on on whatever resource. So it gives you a lot of insights what what happens in your system. So you can pull out each operation that Zitadel did and or a long time. You you see, like, accept languages and whatnot. So do, I guess, to build whatever you wanna build up on top on that. That's kind of the idea. Let's give our users back their data. Right? And that's just the the guts of Zitadel. It's basically a glorified SQL table in a Postgres. Right? It's just an events table where we write

36:47 an append only log, and, yeah, that's what's what's got thrown out there. Usually, you will have more than, like, so little events. But okay. You can also configure a a password Yeah. Just try to local policy. Just there's some interesting stuff. So let's go back to that and to and by the way, the minute you said CQRS and event sourcing, I was sold. I'm a huge advocate of event sourcing. I think it's such a powerful way to build software. So Yes. Go to events again because that's that's more technical errors. Here, you have, like, the the

37:32 the check password check failures. Right. There it is. And if you expand the event, you see some additional metadata. Yeah. But the IP address, user agent, stuff like that. Okay. Exactly. And the funny thing being all about we envision of Zitadel and the reason why we chose event sourcing also is we can train machine learning models that basically can identify threats in the past. And that's the funny thing with event sourcing. Right? You can train models, and then we can give them to our customers. And with their models, we can fortify our our our models and see whether they

37:45 Analytics and Threat Detection Potential

38:10 had breaches down the road or whether they had, like, signals that might have a weird feeling to them. And and and that basically is good for security operations and SOC centers in general. But that that as I said, that's the reason why we chose to keep everything open source in regard of the identity infrastructure piece and only keep the analytics piece to ourselves because that's the thing where where you can produce additional value for for paying customers. That's basically the story right there. Besides, what Zitadel is optimized to is definitely, like, b to b stuff

38:40 Multi-tenancy and B2B Focus

38:45 where you have multi tenants involved. And and I'm certainly I think we should talk about that in a in a minute or so because that that's the reason why Zitadel is built in a way it is built currently and from a data architecture standpoint. Oh, yeah. If you wanna go bonkers on the keyboard layout. Yeah. I'm here for this. I'm so happy. That's by the way, it's a a name you'll agree, what you're looking at. It it it uses the same APIs as everything. So we don't we we do, like, eat your own dog food thingy because we think

39:11 Zitadel UI using its own APIs

39:24 it's it's worth using our own APIs. That's why we we even have an ongoing effort to to create newer APIs, like a version two APIs that have an improved developer experience, basically. Yeah. You can customize your eyes and everything. I'll stop the second randomly. We do have a question in the chat, which we'll get to in just a second. So alright. We have Zitadel. Things are working. I'm clicking on things. The keyboard driven thing is a nice little cherry there just to sweeten the deal that I'm very happy about. But the question is oh, it's a bit small. Let me

40:06 Identity Brokering and Domain Discovery

40:06 can we dive into this a little bit more with regarding organization project grants and identity brokering? Sure. I mean, that's the the beef and butter work of Zitadel, basically. Because from a data architecture standpoint and you can go to our docs. I guess we have a graph for that. So if you quickly go go to our documentation, and then let's go to documentation on in in the top menu, and then concepts on the left side. Yes. And then there is let's use instances for the first. Yes. Perfect. So even though the graph is not especially the

40:46 nicest one in the world, it it we try to show what what's going on in Zitadel. And so one Zitadel binary can have multiple Zitadel instances. So you can run multiple virtual identity systems in parallel. That's basically how we operate our cloud service, and some of our customers operate their systems. And each Zitadel instance within itself is an isolated system. It has its own IDs in the database, and and and it basically acts as the thing you use as customer most of the time. And within an instance, there is a concept of organizations. You can think of them like in an

41:28 LDAP directory organizational units. They are comparable to realms in a Keycloak. It's not exactly the same because with Zitadel, the intent was, let's create one identity system that is the trust anchor. So you basically plug in your application into Zitadel. You trust Zitadel to do the job properly, and then you configure your your application inside an organization. Like, if I'm if if I'm creating a cloud service, for example, I create an organization for my own company. In our case, we have an organization called Zitadel in our cloud service. And therein, we have our applications or all the things that's tied together

42:12 And to to to have multiple applications combined together, we have what's called a project. So that's basically the hierarchy. It's instance, organization, and and project. And the users always belong to an organization. So a organization typically is is a vessel for either b two c users. So you can create an organization where you throw in all your customers, consumers, and then you can create organizations for each business customer or for each team. So that's more whatever your data model basically is. And and that helps you separating different configurations from each other. So, for example, if you have a b to b scenario,

42:56 well, customer a might want to use Azure AD to log in, so he can configure Azure AD in in his organization. And customer b wants to use Okta, so he can configure Okta in his organization. And it's clear, okay, customer a uses Azure AD, customer b uses Okta, and Zitadel knows through the username to which organization the user belongs and can forward accordingly, which basically turns into what what's called identity brokering because we take the identity of the external system, generate the user object in Zitadel, and attach the external identity to it, and give then

43:37 to the application that trust Zitadel an ID that was generated by Zitadel. And we do that because we want to, a, retain the audit trail. We wanna assign permissions to to to that user. And, also, maybe there is a scenario where the same user has multiple identity sources. Right? You already said in the beginning, like, okay. You might have a GitHub and a GitLab account. Maybe you want to attach both external identities to the same identity in Zitadel. That's basically the concept of identity brokering. So Okay. Can I just make sure I understand this Yeah? Correctly?

44:08 Linking Multiple External Identities to One User

44:15 So, you know, I'm a human, which means I have an identity. Right? I am me. And I go sign up first. Let's call it amazing service a, and I use my GitHub authentication, and I have an account, and I got access to whatever resources this company gives me. Right? But then my employer then signs a b two b deal with them, and they want me to log in with my Google account. I'm still the same person. Right? I'm not I've not been split in two. Yep. What we're what you said there is me as a person, I could log in

44:42 with my GitHub, attach my corporate identity. I'd be part of this organization, but still part of the b two c organization, but my authorization would be extended to the extra resources provided by my org other organization. Is that is that correct? That's feasible. It's not the default what we recommend because it's, like, it's it's hard for your company to manage stuff that way. In in Zitadel's world, it's actually totally feasible because that's where the concept of grants come in. Grants is basically a concept of an an an application provider can give a user permission to do something,

44:55 Grants and Delegated Permissions (B2B)

45:20 or an application provider can give an organization the right to do something, and in turn, they can assign the permission to their users. Right? So it's either direct to a user or indirect through an organization. And that's often what happens in the b to b scenario. It's basically, okay. I, as company, have a contract with GitHub, for example, and I want on my own to be able to give my users admin rights or viewer rights or billing administrator or whatnot to do because that's what I want to do. Right? I own the organization, Zitadel, on

45:58 GitHub. And that concept is basically what we call brands in different flavors. Okay. So everything we've talked about so far is on the Us end side of the I call it spectrum. Right? But I I I do see grant rules and authorizations. Does Zitadel offer off zed as well as off end? And how does we haven't seen that yet. So how does that work? Yeah. We try to to keep it lean at the moment there, and which basically means, yeah, on the authorization space, we provide role based access control and attribute ace access attribute attribute

46:05 Authorization Capabilities (RBAC, ABAC via Claims)

46:37 based access control. That's the two things we provide right now. And is that just done through claims within the GWT that you you provide? That's one way of doing it. Yes. I mean, you can throw it into a claim in a token. You can throw it in a sample assertion. You can throw it into to the user info, introspection response from Zitadel. So there's multiple ways tackling it. But generally speaking, yes, you're correct there. Alright. Nice. Yeah. I think this concept space is is a good way to understand the vocabulary that people would probably need to

47:12 bring on board and understand as they Yeah. Boards of the data there. You know? And so these organizations, projects, applications, grants, and so forth like this. It seems like a pretty good place where people should spend a little bit of time to be familiar before they start shipping this into production. Yeah. That's we usually recommend people at least getting some some briefer idea on instances, organizations, and projects because that's the meet main concepts if you're dealing with user management and authentication. As soon as you're diving into the authorization space, you should look at the grant

47:45 grant stuff, like, for the granted projects piece there because that's a delegated scenario where for example, if you're going back to the GitHub example, I, as GitHub, gives Zitadel the opportunity to self manage who is administrator. Right? And so GitHub delegates the administrator role to the organization Zitadel, and the organization Zitadel can give that role to somebody within Zitadel or even outside of Zitadel. So that's the the delegation model. And so that's mostly applicable to b to b scenarios because I, as Wendell says something to another business, and I don't really care whom of their crew is doing what besides that I

48:28 wanna have it auditable. Okay. Nice. Alright. I'm I'm gonna ask a question, and it's either gonna be a really good question. You're gonna have an amazing answer or you're gonna hate me. I don't know which way it's gonna go. Alright? But but so far, everything we did, we clicked around. Yep. And while it's got an amazing set of keyboard shortcuts, which I could explore for days, I am a as code kind of person. Yeah. What are my options? Do we have the ability to commit my organizations, my projects, stuff like that, at least some of it to get

48:35 Automation and IaC: APIs, Terraform, SDKs (gRPC/Protobufs)

49:05 or use SDKs? Like, is there any way for me automate like, let's assume my Zitadel's compromised. I need to rebuild it. No. That could just be a database resource, but maybe I wanna start for I don't know. Like, how how do I do this in a way that's reproducible? Can I? Sure. If you quickly go to our documentation page, there is, like on on the top, there is APIs because that's basically the starting point. There is a lot of APIs in Zitadel. And with without going into too much detail right now, because I could talk for hours

49:38 about APIs, It it always boils down to Zitadel providing APIs either standard based, like OpenID Connect or sample stuff. That's the baseline stuff. And then we have APIs to change objects in Zitadel, like create users, delete users, create applications, everything. And, for example, if you go to the left hand side and see user life cycle, for example, let's let's pick that one, and then you go for the user service. Yeah. That's you can look at the create user, for example. Yeah. That's basically resource based API where you can create users. Right? From there on out, you have multiple options.

50:21 There is, for example, a Terraform provider people use to manage resources in Zitadel. You can find that on GitHub or on the Terraform registry. Exactly. Which can help you configure, like, organizations and such things. It can also create users. It's not not what we usually recommend doing because reconciling users is kinda bad if the user changes thing and so back and so forth. But you can use Terraform if that's the the the poison of your choice. Right? You can use Pulumi. There is even a Pulumi provider built on top of the Terraform provider, or we already have some SDKs for certain

51:02 languages, for example, for Go or for .net to also do the same. Right? So that's why I said it's multiple angles tackling the same problem. So it kind of depends on your use case, what what fits your needs there. Yeah. I'm good with a terra firm provider. You should have started with that. Come on. Like, like, I was expected to open this resources list and see, like, you know, you you're like, oh, yeah. We we kinda have this TerraForm provider and a few people use it. I said, oh, there's gonna be, like, two resources. And then, like, everything is just

51:34 sat there. Yeah. It's it's it's it's not everything, but it's we try to keep it really, like, comprehensive, so to say. Because we have enterprise customers who also use Terraform, and they're quite happy because they can create new applications and projects across environments, for example, within their Zitadel. Right? They can just copy the environments and off they go. I mean, I would probably just raise some Rust. I mean, this API seems to be pretty comprehensive as well. So, you know, generate That's good. SDK and a way I go, I think I'd be quite happy. Actually,

52:09 there is a all our APIs based on on on gRPC. And if you go to our repository, I can quickly guide you through it. So that's you've got protobufs just hanging around waiting for me as well then. Okay. Exactly. It's it's that it's that simple. Like, close to everything has a has a proto with us. So if you go for Zitadel, the repository, and then it's a proto. Yes. And then you see there is Oh, buff. Very easy. Yes. So you can generate whatever you is your poison right there. And yeah. That's that's what you You've got the right

52:49 answer to everything today. I'm just smiling my entire way through this because, I mean, I've I've I've got a buff file. I I have I mean, it's got an instant gRPC SDK ready to go, and that works beautifully with Rust angle. So, I mean, I'm sitting pretty happy with that. We we use it even for, like, the the management console you you clicked around. The the the Angular code there as well uses gRPC web to to to change resources. And so we provide REST services, gRPC web, and gRPC. But, honestly, it's just a transformation of the

53:23 gRPC model to the other languages to the other API frameworks. And and as said, there is a v one API that that was more use case oriented. If you go for the Zitadel folder, you can see the difference there. Yes. That's that's the thing. And there you see, like, that's the old APIs on the top folder, so semantically not super nice. But the new APIs with the v two beta flag, for example, if we go for the yeah. Let's take the session API or whatnot. And then there is a session proto, and everything is nice

53:56 and tidy, and you have, like, the descriptor fields for the open API specification as well. And so it's it's up to pick your poison, really, like, what suits you best. That's why we were kind of hesitant in the past to create too many SDKs because we thought people, hey. There is your buff generates. Do whatever you do. Yeah. Everything is already there. Right? Yeah. Definitely. Buffs are pretty solid way to go. I mean, gRPC in general is is, like, if you go down that path and everyone can generate their clients, fine. But Buff does make

54:26 it just that little bit easier to consume. Oh, yeah. In the past, it was kind of painful. We've grown to see directly and so. Awesome. Alright. We do have a question on the chat, so we should pop over to that instead of me just clicking around helplessly having fun with them. Alright. So can there be multiple organizations that use brokering? For example, GitHub wondering about the discovery and creating the user upfront. Not sure I understand that question. Do you? I try to to I mean, I think I know where it points out. Yes. And I'm

55:06 just implying here, but, yes, multiple organizations in Zitadel can use GitHub. Though we should not we do not really comment recommend that they use the same configuration. In GitHub, anyway, you can't can only have, like, one redirect URL. So at least that was in the past like that. But you can have multiple GitHub IDPs in in in in Zitadel. The brokering piece happens on an instance level. So there is multiple ways of triggering what we call domain discovery. That's basically where Citadel tries to figure out on which organization a user belongs to. Ah. And we have if you go to the documentation

55:52 layer, basically, on the top left documentation again, there is where was it? Just use the search quickly. Domain discovery or discovery should should bring you up. Yeah. Domain discovery. Perfect. Because there is multiple ways Zitadel can discover where the user belongs to. First and foremost, we pass the username and figure out where the user belongs to because the username needs to be unique globally. And the same applies to if there is a identity provider configured for the whole instance, like, for everybody, well, then in that case, we can figure it out. If that's not applicable,

56:34 we can pause, for example, the user's email address and tell, okay. If the email address ends with at zitadel dot com, well, that belongs to the organization from Citadel, and then we can prompt the user, hey. This is your organization. Please use whatever is configured on that organization. That can be automatically redirecting to GitHub. It can be prompting the use of our passkey. It can be leaving the user a selection of things like username, password, and or GitHub. So there is multiple permutations of it, but that's basically the way Zitadel tries to figure out where the user belongs to.

57:16 And to make sure everything is unique in Zitadel, each user automatically gets an internal username assigned. And if you quickly go for Zitadel's UI, I can show you how that looks like. So we have, like, the the Zitadel organization here. That's the first organization that you create. And you you the yes. Exactly. You can you can. Yes. The user is perfect. Click just click on the user quickly here, and you see on the top right, there is login methods. So it's basically username, Zitadel minus admin, that's the username, at Zitadel dot localhost. That means the organization

57:55 is called Zitadel, and your Zitadel the whole thing is called localhost right now. And that's the semantics on how we can figure it out easily because we know, okay, Zitadel admin, well, there can only be one in at Zitadel in dot local host. So that that that's where it trickles down. You can define those those domains on your own. It's just we we pre regenerate something for you already. Oh, I'm so sorry. Answers the question. Yeah. I I mean, I I hope I answered the question. I'm not entirely sure. I'm just clicking about now, but yeah. Yeah.

58:32 You found the peso list. Well, yeah. Is there you you mentioned pass keys at the start, and I know it's very early in the pass key adoption. Does Zitadel support pass keys as a it does? Go for, yeah, password and security. That's the subcategory. And then pass less authentication, you can click or add method here. And then you can throw in a name, like, whatever. You can say, whatever suits your yeah. One password does does the trick. Add new, and then you should be prompted by your One password to actually store something. Oh, yeah. I guess you need to open password options

58:36 Passkey Support

59:13 because one password needs to be configured properly to work with the browser of choice. At least on on Mac OS, there it tries to store it on on the iCloud keychain as it looks like. Oh, yeah. It's trying to store on the iCloud keychain. Yeah. But pass keys, yeah, they work. That's the short answer here. I think it it took the iCloud thingy right now. All it did What? Yeah. Alright. Okay. Never mind. Yeah. The UI, one person and the iCloud key chain is sometimes a little bit wanky. I I do have it see, it's because

59:55 I I just I I change all my stuff too much. Right? But I this is the first day in, like, two years I've run Firefox. And whereas my one password to pass keys is all configured properly on my normal browser. So okay. I'll do that. I'll play with that later. Alright. Very nice. I like this. It's very cool system. I mean, I don't wanna say it's painless because it's it's identity. Right? It's it's not painless. You've already endured the pain for us. That that's the beauty of what Zitadel is bringing to the table, and I love that.

1:00:27 I mean, it's it's really a comprehensive thing, Zitadel. And what we we think Zitadel is best suited for is if you're building a b to b case, that's the strong suit of Zitadel. If you're running b to c, that's where we can work totally as well. It's not overly optimized for workforce identity, but because we like the the HR processes and stuff. But from a technological standpoint, it can do that as well. So it's just our our focus definitely is toward customer identity, so to say. And that's where we try to really, like, bring a turnkey solution

1:01:06 that does authentication for you. You can create identities. You can use external identity sources. You can even use LDAP if you like. I mean, if you go, like, for settings here, there is even, like, an identity provider section on the left hand side there. A little upwards. Yes. And then you have, like, a a lot of preconfigured providers here. And there is also SAML if you wanna give you the pain. You can do SAML as well. And there is, like, a Active Directory LDAP. You can also use that if you wanna authenticate with preexisting infrastructure.

1:01:43 It's more for for projects that are already established rather than new. Mhmm. If you click on one of those, you just get a whistle, basically. That's right. I I will take action. Nothing plays will happen. No. No. No. I'm pretty sure if I click on one of these, it's just it doesn't help spy at all. Act LDAP active directory SAML. Those are bad words in my book. This is a bit of a a random question. I know it's not that the it's not, like, the directly the use case result. You've covered what that is really well.

1:02:13 Machine-to-Machine Identity (Service Users)

1:02:17 But, you know, there's a there is machine to machine identity. Right? This is something that's more prominent, and I'm thinking of the use case of I operate a number of Kubernetes clusters for my Rawkode Academy infrastructure. And, like, you know, if I can do a generic YDC and I can hook that up to the Kubernetes RBAC stuff, like, has anyone explored this? Is this something that you've you've played with yourself? Yeah. We played around with Istio in the past quite a lot, and and some of our customers even use Istio. But we since then, well, left the Kubernetes world for our infrastructure.

1:02:52 I mean, not in a bad mood, but they'll try to to use, like, less operational overhead for a start up. And, yeah, operationalizing Kubernetes was kinda hard even though we did run Kubernetes in the past quite a lot. But we chose to use Cloud Run. I have a whole talk about why switching from Kubernetes to Cloud Run, but that's a different thing. Going from machine to machine stuff is kind of what Zitadel can do as well. Let me show you an example. If you go for users in in in your UI, And then you have, like, a toggle on

1:03:26 the lower a little bit on the left there, you have a toggle, which is barely visible, but we know that's that's a bad design decision. And then you can create service users. So if we quickly create the service user, just throw in whatever you wanna throw in as as username. Nothing really bad can happen here. Yes. Just create it and and off we go. Now you get basically a a a service user, and users in Zitadel are kind of the same. The only thing they differ is the the the means they have to authenticate themselves.

1:04:07 And so in a service user, you can basically choose to create personal access tokens. On the left side, you can just create tokens that can do whatever the service account can do. You can throw in an expiration date or just create it unlimited, and off you go. Or you can create keys. That's basically a pry a Jot private key process. Like, you get a Jot file from us, like a private key, and you can use that to sign your your payload, and then we can give you a nice tidy token back. We have a guide for that. So

1:04:40 and and our Go SDK can already take care of it as well as the Terraform library does all also the same. But the reason being, you don't leak the the your secret. Right? And that can be used to basically build machine to machine processes because a machine user in Zitadel can have rights in an application that is attached to Zitadel, or it can have rights in Zitadel itself. Like, for example, you build your your nice register UI and you want to create your users on your own, well, create a service user, call our API, and off you go.

1:05:18 Nice. Very cool. I'm gonna have to play with this a bit more. It's got a nice little robot icon. I mean Yeah. There is there's also a guide for that because Alright. There's a follow-up in the chat with regards to the b two b angle. Sure. So it says thank you. Thank you for the b two b case where the users don't exist in Zitadel initially, but they use an email domain to propagate them through to the correct IDP. Yep. That's possible. You can attach the domain to to an organization. Like, you can say acme.com

1:05:35 B2B User Discovery and Registration with Email Domains

1:05:57 belongs to the organization. And as soon as the user arrives from an IDP, like GitHub, for example, and the email address ends with at acme dot com, you can automatically register the user inside that organization who owns the domain, basically. Awesome. I'm gonna jump back to our big face mode. So I'll give everyone watching a little bit of a warning. If you do have any more questions, get them into the chat quick. Now I'm curious. I don't wanna talk about the Kubernetes side. Right? I think critical infrastructure, you know, needs its own Kubernetes cluster. You should be running

1:06:18 Deployment Considerations (Kubernetes, Cloud Run, Startup)

1:06:33 it with your standard workloads, which brings more complications. I actually even though I operate many Kubernetes clusters, I put critical stuff on, like, fly.io or I run it on railway. Like or even Cloud Run is another really good approach as well. Yep. It's like yeah. I hadn't I didn't know Cloud Run could do long running processes, though. That's not something I've explored before. I thought it was just serverless platforms, but I'm assuming your Zitadel isn't spinning up as a cold start every time, is it? Or It's like usually one second ish to to get ready and serve traffic.

1:07:09 Oh, Yeah. If you look at the Docker Compose file we opened, there is an argument passed to Zitadel there, which is start from init that basically advises Zitadel, hey. Start from from your init standpoint, like, okay. Try to do all the migrations and figure out whether everything is prep and ready and and whether the projections are there and all that stuff. But there is also a a start flag. So you basically can tell Zitadel just to start with whatever system is just there, and that increases the start up cold start times quite a lot. Like, you can

1:07:47 get one second call starts with that. That's how we operate Zitadel on on Cloud Run is basically we have a a job that applies the schema changes and stuff, but the scaling containers, they just start with the precondition of everything is already prepped and ready. And the same our Helm chart does the same. You get, like, a job that does the setup stuff and initialization, but the serving containers will not start with from scratch everything. That's basically how you can separate and and improve operational efficiency there. Nice. I like that. Alright. Let's finish on what's what's next. Right?

1:08:28 Roadmap and Future Development (Login UI, User Schemas, Actions/Events)

1:08:28 What are you and the team working on? What's on your road map for the next three or six months? New shiny features are always a bonus, but, of course, share what you can. I mean, there is also citadel.com/roadmap, but I will give you the the the yeah. There is it basically goes to a GitHub board. I mean, we are we are committed to transparency. That is one of our missions of really, like, let's keep things transparent because we are a security product. We wanna build trust in what we do, and so we try to keep as much

1:09:02 visible as feasible. Not not everything, but as much as feasible. And the the most important things we are actually working on is we are working on a an a an already made login that you can just fetch, and then you basically get the Next. Js application you can tailor to your needs, and it already brings along the components you need, like input fields and that things. So that's one thing we are currently working on. There is also there is already a a work in progress prototype on Zitadel slash TypeScript. One thing that will come is

1:09:39 user schemas is what should be soon the the the work should soon start. The idea being we want to give our users the the possibility to define how a user should look like because different needs across different ranges. Right? Like, what is mandatory, what's what's what's not mandatory, and all those things, and we wanna give people the flexibility to define it. And, also, what will land is an improved versions of our actions. Actions basically is you can run a little bit of JavaScript code, etcetera, at runtime to alter things, like to call an HTTP API to to fetch some data of your

1:10:20 CRM or whatnot. Or when a user registers, you can do an HTTP post to your application, such things. And we are working on an improved version there where you can intercept HTTP requests. So you can basically alter everything that Zitadel can give you from an API perspective and also an event feed. So you can basically tell Zitadel each event that matches to x y z throws something at me, and then I can react on it. So you can do event driven applications even further. Right? Like, if a user logs in, we can send event. If a

1:10:57 user password verification fails, we can send an event to you. You can do whatever you want with it. And so we wanna have, like, those features really extended. Main idea being you we give you an SDK. You can run that in a cloud flow or call, and you can handle what we send you and do whatever you wanna do with it. Right? Because we try to to build the developer experience around the actions thingy, like, with an embedded runtime. But so far, the we thought, well, there is cloud flow, course, there is they know there is multiple other tools that can do

1:11:30 edge functions. Why do we need what's the need for us to do the same? Let's just reuse what's are out there and use the developer experience, basically. Because it's easier to debug, right, if you have, like, full ID support and everything, and you can put pick your language of your choice and yeah, let let's basically define an API. We send you an HTTP request. We send you an event, and off you go. Nice. So extensibility, basically, is the the main topic there that will come. Yeah. I like that. Have you, anyone in your team, or any

1:11:59 Integrating with External Authorization Engines (SpiceDB, OPA, etc.)

1:12:04 tangential now? Right? But I'm just going there because it popped into my head. Like, I see a really compelling story for the for the author and I know there's some of the off c stuff, but, you know, SpiceDB is written in Go, Zitadel is written in Go. I could essentially just consume them both as libraries, ship a single binary to do off n and off c in a very and they both speak Postgres. Have you is that something you've ever explored to, like, do some interesting patterns there? Actually, yes. We're always looking into to what's the culmination or the perfect culmination of

1:12:40 identity? Like, you need our event capabilities. You need user management. You need audit, and you need authorization. And we think we should keep it open. That's why we came up with the events design, like sending events to other systems. So if a user changes and say that they'll let's send something to SpiceDB or whatever tool you wanna use, there is also permi permi permi permi permi yeah. Yeah. Warrant's Warrant is also out there. So let's let's give users the choice and try to keep, like, an let let's try to build kind of an ecosystem to some extent.

1:13:15 Maybe at one point when we we grow big enough, we will try to to to bring something more mature along to the party for people. But until then, we we advise to do that do it that way. Nice. Alright. Last question from the chat, and then we'll wrap this up for today. Have you had any thoughts or plans regarding fine grained authorization? It it per wraps perfectly. I mean, yes, we have a lot of ideas about it. We also thought of integrating it directly into the call product. Honestly speaking, we we try to focus a little bit

1:13:35 Fine-Grained Authorization Discussion

1:13:59 more on on authentication and integration pieces of Zitadel right now. But I said, maybe at one point, we'll try to integrate something. Until then, we we advise people to do what it is best, and that is basically use Zitadel for authentication and, like, role based authorization stuff Okay. Pass the info along to your authorization engine of choice that can be OPA, it can be Verint, it can be SPICE DB. Let let's let's try to use it that way because they have invested quite a lot of time of unbundling the fine grain authorization stuff. Right? Mhmm.

1:14:35 It's also a topic a topic with a huge depth to it. So that's Yeah. A whole journey. The replies is basically my question. Yeah. I wasn't sure if it was a bit more specific or if it was kinda, you know No. No. It it's decode correct in the same direction. Alright. That was awesome. It's such a good product. It's open source. People can get started today. There's a free tier on the cloud. I mean, just go start kicking the tires on it. This is a problem that, you know, if your if your company wants to

1:14:52 Conclusion and Call to Action (Community, Free Tier)

1:15:04 make money, they have to deal with identity. It's just there's no other way about it. Yeah. And why burden your developers with stuff that's already available open source right there to you? So thank you so much to Florian and to the entire Zitadel team. Again, amazing product. Can't wait to start kicking the tires on it myself. Any final words that you wanna share with people before we say goodbye? We certainly like to have engagement on on Discord, for example. So there is quite a lot in active community over there. If if people wanna hang out and ask questions about

1:15:35 Zitadel, the best way to go is zitadel.com/chat. That should send you to a discording web page. Otherwise, feel free to engage with us on GitHub as well because if we really try to to build the next great framework or or turnkey solution that can really bring you the value of not building authentication, of not caring about past case implementation, of of trying to avoid all those fallacies and having basically a a well defined ready made product for for the job. Right? And so enjoy the ride. Ask questions. There is a lot of weird things you can tackle once

1:16:14 you wanna scale such a system. Like, you get a lot of operational headache, and that's not especially due to Zitadel, but that's just generally, identity is weird because you deal with authenticated and not authenticated traffic. And, yeah, give us a shout out if you have interest or needs or questions. We are an open minded community. Alright. Well, I'm now in your Discord, so I'll be throwing all my questions to your team and the community as I explore. But thank you so much for your there. So we'll see each other again. Oh, you I know I know we could gonna be like,

1:16:52 I really hate that guy. Why is he just keep asking so many questions? No worries. No worries. Alright. Thank you so much, It was wonderful exposure project. Keep up the good work, and hopefully, I'll see you again soon. And to everyone who watched, have a wonderful day. Thanks. Likewise. Thank you for having me.