EPISODE 1642

[EPISODE]

[0:00:00] ANNOUNCER: Corbado is an authentication platform that provides APIs for developers to replace passwords with passkeys, such as Face ID or Touch ID. Vincent Delitz is a co-founder at Corbado, and he joins the show to talk about the platform, the changing authentication landscape, the challenge of session management with passkeys and more.

Gregor Vand is a security-focused technologist and is the founder and CTO of Mailpass. Previously, Gregor was a CTO across cybersecurity, cyber insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade, and can be found via his profile at vand.hk.

[INTERVIEW]

[0:00:52] GV: Hi, Vincent. Welcome to Software Engineering Daily.

[0:00:55] VD: Hi, Gregor. Thanks for having me.

[0:00:56] GV: So, Vincent, you're the co-founder, and you're responsible for product management at Corbado. So, could you give a quick overview of what Corbado does, and how did you find yourself co-founding the company, I think it was one and a half years ago?

[0:01:13] VD: Yes. Great question. So, Corbado is actually helping companies stitch passwords to improve user experience, boost security, and also increase ultimately the conversion rates. We achieve this by helping companies and software developers to add passkey authentication to their web native apps. For anyone who's not familiar with passkeys, it's kind of a new authentication standard that basically allows you to use Face ID or Touch ID to authenticate securely on web apps. It's built on public key cryptography, backed by Apple, Google, Microsoft, and we help developers by providing SDKs, APIs, or web components to easily integrate it into like their authentication services. It's like our passkey is a service authentication solution in the end, what we offer to our users.

Coming to the second question or the second part of your question, how I ended up like found Corbado, one and a half years ago. I need to tell you a bit more about my background. So, I have a background in Information Systems, studied in Munich. Many of my fellow students, I also did during my studies, internships, like large corporates like Lufthansa or BMW, for instance. In retrospect, it's been insane how like these companies were run compared to startups, or to like developer first companies.

So, back at these corporates, it was a huge and also like, prestigious company, mostly that I work for. But it's also like a huge machinery. There are many, many tasks that need to be taken care of, and many particular tiny tasks are taken care of by an entire full-time equivalent. Also, what I quickly learned and discovered in there is like, there's so many meetings, so many things you need to align, so many approvals that you need to get done, until you get in the end, something really shipped to production, and it's also like a huge people and political game that you have to play if you want to really succeed in like these corporates.

I quickly discovered for myself, I want to be like in a more agile, a more fast paced environment. So, I did some experiments in the consulting world, learned a lot of new things and interesting projects. It was a great learning. But towards the end of my studies, I actually asked myself, “Okay, what do you want to do after your studies?” And what kind of things I’m really passionate about?” In my case, it was software engineering. I learned to code in my early youth and also kind of the thing of building something from scratch, for something that really, really satisfies myself. It wasn't like creating tons of slides and spreadsheets compared to like the consulting industry.

So, in one of my last gigs as a freelance software engineer, towards the end of my studies, I was tasked with the implementation of authentication for, it was a basic software as a service application, and it took me I think, entirely two weeks to get things done. It was back then, based on offloads. I was quite new to this whole world of creating authentication flows. I asked myself, “Okay, two weeks for a simple password-based login and signup flow couldn't be any easier, and also, any more secure.” I mean, in general, it’s kind of secure, but just digging deeper into like the standard specification would be so much knowledge and time.

That actually made me think, “Okay, isn't there something easier for developers to provide authentication?” At the same time, I also – when working on this authentication part from the developer-facing position, I also had so many occasions from a user perspective where I had to provide a password for an online shopping application, or any arbitrary like SaaS application, and I didn't remember it. I hadn't put it into my password manager. So, I kind of abandoned the login flow or the shopping experience, which then also made me question something like, isn't there something easier for like the users?

These kind of two different trends or streams actually made me dig deeper into like passwordless authentication, which I discovered back then. Coincidently, this new term of passkeys came around back then. It was heavily pushed by Apple, Microsoft, and Google in early 2022. It's actually something where I thought, okay, passkey is kind of cool because it's like you improve the user experience, because users don't need to manage passwords. They don't need to remember it. They don't need to come up with them anymore. And on the other hand side, it's kind of secure because it's two FA by default. It's phishing proof. And it's based on public key cryptography. So, I found it's like the perfect symbiosis of user experience and also improving IT security or cybersecurity in general.

Then, I went digging deeper, also, like in passkey implementation. I discovered quickly, it's kind of hard to actually get things going. There’s so many things you need to take care of, so many things you need to consider, and it's highly complicated for an average web developer to get things going. I also spent weeks and months, eventually, providing like a working solution that could be applicable in real-life scenarios. And that's actually at the point when I discovered, “Okay, if I already have these issues, and if Apple, Google, and Microsoft proclaimed that it will be the new standard of authentication, that there will be also many other developers who will face similar issues.” That's where I came to the conclusion. Okay, I'm going to provide a solution that makes other developers’ lives easier when implemented passkeys, and ultimately make the internet a safer place for all users who rely on any kind of web authentication.

[0:06:24] GV: Fantastic. Some of this, I feel is almost right place, right time, passkeys. When the spec has been sort of evolved and evolved, and you're sitting there with the right knowledge from what you worked on previously, and then moving that into a product. I'm sure there's a few of those listening at the moment who maybe have a certain opinion about passkeys, whether it's a very positive opinion, or it might be actually a negative opinion, perhaps. What would you maybe say to those, certainly with maybe a less favorable opinion of passkey is at the moment, in terms of the device suddenly is taking over, instead of a password, and you can maybe come back from another device easily. All these kinds of things that we see coming up on, I would say a lot of forums at the moment, around passkeys. What were you thinking when you thought this is the future, and actually, these things are not maybe as large a concern, as some may think.

[0:07:19] VD: Slowly, and I can fully understand most of these people have kind of doubts or any counter arguments towards passkeys. I mean, passkeys, they're still kind of brand new. They've been around for almost a year or more than a year. But so far in the wild, they're not that many applications who have implemented passkeys and also the standard. So, it's kind of evolving their updates and more features being added to. But in general, I think passkeys are a huge improvement for the average non-technical user, because non-technical user has like a couple of passwords, or probably, in many cases, it's only one password that they use over a variety of different websites. Then it's like a huge IT liability. And these people who are our kind of doubtful, they’re more like the technical users who have like a password manager properly set up. It's synced on all the devices. But in real life, it's not the case that the average user has a password manager. It's also not synced.

So, I think passkeys in general, as they are proclaimed as the new standard, they will make the life for many, many users more secure and also easier when they needed to log in. But also, if you're a highly technical user, you know how to set up things, you know how to implement and set up web, then it's something that might be less favorable for you. But I think there will be a huge kind of hybrid phase where you can use your existing current authentication besides passkey authentication. But in general, the overall IT security levels will just increase, and users will just adopt it. Because I mean, 10 years ago, users just adopted to unlock their smartphone with Face ID and Touch ID, and I'm pretty convinced that this will happen also for web applications and native applications.

So, it's something that is like a huge trend, because Apple, Microsoft, and Google. They just have the power over all, our devices, browsers, and they can more or less enforce it as the new standard due to their power and their adoption of devices. But if you’ll have like any doubts, then you can just use whatever you prefer, instead of passkeys.

[0:09:20] GV: Yes, completely. And I think maybe something that's sometimes misunderstood is that it doesn't automatically require something like Touch ID. If you don't actually wish to set up Touch ID, you can then use your device's authentication, which might still be a password, but it's a password that you probably don't give out to many people. Of course, looking at the solution in general, as you've called out, it's as much about how it's implemented on the system side, the platform side, as it is about the users.

So, let's dive in a bit to Corbado and how it's doing this. Corbado is trying to help developers get going quickly with the auth, whether it's a new app, an existing app, or even replacing the auth entirely within that app. We do see quite a few solutions out there already, looking to address auth as a service. So, can you talk us through, we've got these kinds of three scenarios that you guys catered to, and can you talk through those and sort of how does that look to a developer?

[0:10:16] VD: Absolutely. So, I will answer this question in like two parts. So, either you're creating a new application from scratch without any legacy authentication, or you already have something existing in place that have already signed up users who are actively using your application. Let's start with the new application approach. So, if you're building a new app from scratch, it's pretty straightforward. There's no legacy system you need to deal with and you can go 100% passwordless, that you want to be future-ready for whatever solution comes.

Authentication in general, it’s one of the first thing that developers actually approach when building a new app. So, I mean, it always depends on your personal favors, but you just Google, “Okay, that's my tech stack, or have my favorable solution.” I mean, you just try to look for a component or SDK that you can easily add to your existing – to your application. Most of the times, you don't need to worry about it in the end. So, something that's already been built will take care of it. It’s also, what we want to fulfill with our promise, get off, done in one sprint. So, implemented once, and don't ever waste another kind of thought with it.

If you already have a web application, already, some existing users, it's something different, because things are getting more complex in there. There's already some flows that users are familiar with. There’s already passwords that user are currently logging in with, and you need to somehow maybe add only passkeys, because you don't want to switch your entire authentication solutions. It's like never change your running system. But you also want to provide like passkeys as kind of the new authentication solution to your users. We have come up with a couple of different ways to keep everything in place, you keep all the data, you keep all your existing authentication, but you can just use passkeys as kind of a drop in, or add-on to your existing application, and it's also kind of recklessly to test it out. And these three scenarios can be implemented according to your needs. The first scenario is that you use webhooks to just call password-based API endpoints in your current back end, and we’d take care of all passkey-related aspects. So, it's device management, it's actually the intelligence to detect if a device is passkey ready, to detect if a user has already passkeys to sync these passkeys and just make everything related to passkeys get going out of the box.

The second scenario, how you can integrate passkeys to an existing application is something that we call passkey association. It's actually only possible if you have already a user who has authenticated with a legacy authentication method. In there, the user creates an association token that can be redeemed to a passkey, which can be then used for future logins. But it's not that it's like a new user who can sign up with a passkey. But instead, it's like upgrading an existing user who is already in your system to use passkeys in the future. It's also an approach that we have seen at bigger companies, for instance, like TikTok, that just offer up modal or pop up where I can just click, “I want to activate my passkey or I just want to use Face ID”, in simpler terms, for the next authentication. And users create this passkey, and then when they need to relog, they can just use it.

The third scenario, that something that we currently develop is that it's like a database connector, which then automatic plugs into your database. It's also running on your systems or on your cloud, and it basically syncs all the passkey information and data that we have on our systems into your database. So, you keep all your data, all the data stays in the existing database, and we just and sync like all passkey-related information, so it's also something that can be used on-premise which many of our clients and customers actually favor. These are like the three possible ways how we can add passkeys into existing applications.

But that’s one thing that I would particularly mention and highlight is that from our surveys, and when talking to a in particular, small and medium-sized companies, the landscape for authentication solutions is kind of interesting, because 80% of applications, they don't have any authentication as a service solution, or they didn't have any kind of dedicated authentication solution, especially if they were built like 5 or 10 years ago, and it's like mostly a database, and it's also some custom-built authentication. This is completely fine at the beginning, but things get more complicated, and things have been getting more complicated over the past years by adding new forms of authentication.

For instance, it's like social logins. It's like single sign-on, it's also passwordless methods like magic links, or OTPs, and passkeys, they just create a new dimension of complexity because passkeys, to some degree, are device bound, and taking care of like this new level of complexity over time is just something that's really, really complex. I guess that like 80% of these companies who have something built in-house, they will transition eventually to any kind of authentication solution, because it's usually none of your core tasks and core capabilities to build authentication, but it's required in most apps. So, you will transition to like any authentication service in the future, in my opinion.

[0:15:22] GV: Wow. Yes. So, it does really cover a lot of sort of scenarios in terms of where you might be coming from, as a developer, whether it's, as you call it, whether it's a new app, or something in the middle. You mentioned social logins, I mean, that's something, I think, still a lot of users again, I would say, have either a love or hate relationship with. I'm kind of more on the end, of the hate end, if I'm being quite honest. I think from a security side, I think we're fairly well versed now that there's quite a lot of problems with that. But quite a lot of users still do use them. So, does Carbado integrate with those? Is that through other third parties? Or how does that kind of work?

[0:16:01] VD: So, right now, we started our product, or we developed the product before like passkey first authentication mindset. We try to employ passkeys wherever possible. But of course, you need to provide alternative ways of authentication. Currently, there’s other passwordless options, or it can use your passwords with these aforementioned three scenarios. Something like social logins with Facebook, Google, or whatever, something that we have on our roadmap, and we then also would need to implement an auth-based social login. But if it were just like kind of the standard nowadays, because some users, just as you said, prefer using their Google account or their Facebook account. But we also think that many people, once they have seen how easy it is to use passkeys, they will just switch to passkeys digitally like Google or Facebook-based solution. Because from a security standpoint, and also privacy standpoint, passkeys are way better in my opinion. There's nothing you need to tell your authorization server, what kind of solutions to use, and it's just so more secure, and also so more user-friendly. So, because in my opinion, people who use Google, Facebook, or whatever, they just use it out of kind of convenience, and passkeys, or even one upgrade more in terms of convenience so that I expect many more people switching over from like Google social logins to passkey-based logins.

[0:17:18] GV: I would completely agree with that. I think that social logins were clearly over, implemented, overused nowadays. There are definitely some cases, I would say things like GitHub login, I mean, is a great use case for that, for example, as to why you would want to kind of just have that all integrated on that access. But the likelihood that you actually want to give over a lot of information from whether it's Facebook, or LinkedIn, or Google just to A, another service is, I believe, diminishing.

So, Corbado, it does cater to both pure front-end apps and back-end server implementations. I found that quite interesting, kind of looking through the docs, through the spec. So, what led you guys to have the decision to serve both? Obviously, what challenges did you guys face at the implementation level, creating both of these solutions?

[0:18:08] VD: That's a very interesting observation. To answer the question, you need to take a look at kind of the evolution of Corbado in our company. So, we started a company with the mindset, we want to be an API first company, because we thought back then, developers, they just are happy to use an API and use this API for providing authentication in what way so ever. I think, this is true for many applications, and use cases, and also traditional methods and particular passwords. There's like one or two API endpoints, and then that's it. So we, back then focused mainly on providing like this back-end server implementations and pure API endpoints.

What we then quickly learned, is that if you want to implement passkeys properly, and make it usable also for non-tech savvy users, you need to take care of like the front-end aspect as well in a proper manner. I mean, another reason is also that passkeys, or web authentication, and the underlying standard, they also call APIs in your operating system via your browser. So, to start the Face ID and Touch ID flow, they need to call something on your client side. Actually, when we then dug deeper into providing solutions, we quickly recognize that it's so hard to provide only pure API calls, because there's so much things and so many steps you need to take care of in the front-end side as well. That actually got pretty quickly, very complicated, and took a lot of implementation time for the first developers we spoke with.

So, we thought, is there no better solution to provide an out-of-the-box, easy implementation way, which is like the case for API endpoints, but that also includes kind of the front-end side and also serves to the front-end developers in their best needs. Then, we decided to go with HTML five web components because web components, they're kind of simple to integrate. It's like one or two lines of HTML code. It's framework agnostic. You can put it into like any front-end framework, any JavaScript framework. And underneath, there are still like API endpoints that you can call. So, it's still REST API endpoints on our side that you can use. In our opinion, web components are kind of the new APIs, because they make things more easy for you, especially if there's something in the front-end that you need to take care of as well. And it's still possible to call like these API endpoints if you want to provide any ritual implementations or have very, very specific use cases.

It's also something that coincides with like a general observation that we think authentication moves more towards the front-end. Because like 10 or 20 years ago, there was, as I said, like an API endpoint for password authentication, and that's it. That was back then completely fine. But now, there's so many more authentication options, like the aforementioned ones, and so many more things that you need to take care of when it comes to user education, error messaging, and also like the whole UI and UX, that it's easier if you just have like a web component, which caters to front-end developer and back-end developer’s needs. That something that we kind of focus on right now, and still very confident that this will be like a general shift in the industry that more things move to the front-end, because saves a lot of time, and it's also then easier for users to provide just an out of the box user experience as well.

[0:21:22] GV: Yes, that's a really interesting observation. I think, yes, it's quite an interesting piece that it probably wasn't – probably not so long ago, there's a time if people said that authorization was moving to the front-end. They thought we were all being a bit strange. But we can honestly see with technologies like web authen, with passkeys, that is actually possible. So, who would you say is your typical customer at the moment? I mean, do you it’s developers that’s discovering Corbado or does someone else on the team discover and kind of throw it to the developers and say, “Hey, you can do this in a day when you told me it's going to take two weeks?” What does that look like?

[0:21:58] VD: Yes, so the typical customers right now are SasS companies, native app companies that just want to upgrade their logins, or just make use of passkeys, because they've heard of it and heard of all the benefits. Most of the times, they don't want to spend too much time implementation wise, they just want to get like passkeys working and make a tick to the box off the passkey requirement. Right now, we're focusing on targeting developers, because developers are the ones who either discover it in forums on Reddit, on Hacker News, or wherever, and they're also the ones who need to implement it in the end. So, we provide a lot of technical content, blog posts, documentation, and just some also thought leadership aspects for developers where we teach them how to use and how to implement passkeys in a very, very easy way. That's also the first actual distribution channel, that pretty works well for us right now. Because people, or developers in particular, they find it, they read it, they can go through the blog post, they sign up, and we have actually optimized the developer experience so that they can get a passkey-based authentication solution working with one Docker command.

On the other hand side, they're like, suffer, or how would I say, it's product managers, which are kind of like technical product managers who are responsible for authentication, identity, and the user experience, and they've also seen passkeys from the large tech companies like GitHub, like Google, like KAYAK who wrote our passkeys, recently, and are often more interested in like, what kind of benefits do I get in terms of conversion rates? What kind of benefits do I get and less people abandoning their shopping carts? And how can I make my customers and users in general happier? For them, it's not that we like provide a simple way of integrating passkeys from a technical point of view, but it's like, how could the flows for passkey look like? Because there is no best practice yet. There is no real standard yet. There are some guidance by the FIDO Alliance, but still out in the wild, there's just so few applications that have passkeys properly implemented. Some do it better, some do it less better, and we then provide and help them with coming up, “Okay, how could I potentially use a flow look like? Or how can you integrate passkeys in your password reset float so that you can tell your users, hey, this password reset will be the last password reset for you. Because in the future, you can just use passkeys, which is something that you cannot forget anymore.”

But to answer your question, right now, it's more likely that we focus on developers and occasionally there are product managers who are just interested in introducing pass keys in a very, very user-friendly way to their end users.

[0:24:30] GV: I mean, do you find that you have to help educate, well, both sides, actually. Is it, do you have to help educate the developers and their product side? I can imagine, perhaps you have developers coming to you saying, I can see the benefit, but I can manage to convince my product manager or even my CEO, like why we need this. Did you see that?

[0:24:50] VD: Yes, absolutely. So, right now, it's still a lot of user education or developer education, however you name it. I mean, the FIDO Alliance and like the large tech companies that do a great job in educating people from a user's perspective how to use passkeys. But when it comes to the particular implementation, there's still a lot of new things, even for experienced developers. Because passkeys, as I said in the beginning, are kind of hard to implement in a very, very pure way by just having a look at the standards and specifications.

So, for instance, passkeys are bound to one domain. So, you can't use like C names for your various websites to target all C names on one website or one domain. And that still requires a lot of user education and develop education. But most people actually agree that passkeys are the future. And they bring a lot of benefits once they are implemented. And helping developers in particular come to that point where they have successfully implemented passkeys is kind of our core focus right now. So, it's less that we need to convince them to use passkeys. They approach us with the initial wish to implement task is because they have read about the benefits. But it's still more like helping them on providing good SDKs, good web components, and good technical documentation to get things also than working from a software engineering perspective.

[0:26:06] GV: So, we'll just take a quick look at one more sort of part from the business side, if you want to call it that. Then, we'll dive back into a bit more technical. At the moment, the billing model is that you have a free plan, which is fantastic, and then you move to MAU based as a paid plan. So, maybe if you could just speak to what does MAU even stand for just, for those that don't know, and then sort of what led to that being the sort of model that you went for?

[0:26:31] VD: Great question. So, to answer what MAU stands for, it stands for monthly active users. So, that's the number of users who authenticate to your product via our services. I think in general, it's like for most developer tools, it's crucial to find like a point where people or developers are willing to pay for your service, because like most developer tools, everything can be built for free. There's no like IP, which is protected. And many people, many developers in particular still think I can implement passkeys on my own. I have like a library here that I found somewhere, and that's it. It's definitely a viable way to go. But there are many things that these people don't consider. Because, as I said, there's so many things that which are kind of new, which are kind of customer user-facing, and which then still take a lot of implementation time and a lot of your engineering resources, which we think you should be better putting onto like your core product.

When we initially came up with like the first thoughts about pricing, and also then talking to like other customers and people who had some kind of authentication service in place, it was quickly that MAU is kind of the standard for just measuring the usage of your product, because it grows linearly with the usage, and you can then also charge linearly for the usage of your product. On the other hand side, we also are firmly convinced the passkey is filled with the standard in a couple of years for authentication, and there will be a huge demand. This demand is based due to the user experience improvements, but also to the IT security improvements. We firmly believe that we want to make the internet a safer place by authentication or by secure authentication, in this case, by passkeys.

So, we then came up with like these three tiers. And the first tier, the Community Plan, which is completely for free, also does not have any restrictions in terms of monthly active users. So, you can use it with whatever kind of monthly active users you have. Then, you only need to pay if you have some more requirements in terms of you want to get rid of the branding, you want to add more admins or developers to your team, or you want to have some advanced monitoring capabilities, and that's actually then where we think that people see real value for, because these are features that are more connected to companies who have paying users, who need this kind of security, who needs compliance stuff. And that's where we then also switch to like a monthly active usage-based pricing model, because the more people actually log into your product, the more revenue you usually make from like one user who signs up to your servers. But if it's like only a hobby project, or if you want to just start with passkeys, and don't want to commit to anything, then you can just use our free plan without any restrictions in terms of the number of MAU.

[0:29:08] GV: Very interesting. I mean, would you see there being scenarios where Carbado actually, a company gets to scale, let's say, tens of thousands, or hundreds of thousands, or millions of users, maybe you could pick one of those numbers that actually makes sense for a company eventually, to leave Corbado. Or is that not how you look at it?

[0:29:30] VD: Actually, I'm not too scared about this potential scenario. Of course, this could happen that someone just in sources, this kind of capability. In source authentication, but I think what we've seen from like a larger industry perspective that especially larger players with huge numbers of monthly active users, they are more the players who want to outsource, like they're not core capabilities, be it payments, be it like authentication, because things are getting so complicated, it's also a risk for yourself. So, if you mess things up internally, then it's something that has a severe impact on your business, and then you usually move towards an authentication provider or a payment provider who is solely focused on like providing authentication or payment or whatever it is. I don't actually expect that many large companies, maybe Google, Apple, and so on, they can build it on their own. But I mean, any other company, which is not like one of the big tech companies who sooner or later outsource their authentication to a dedicated player.

[0:30:27] GV: I think that's a really good point. I, often, whether I'm sort of advising, whether what kind of solution we should be using, whether it's a company I'm working with, or just external. It is sort of look at who's providing the solution as their core business. That's probably where you're going to get the best solution. If you're even vaguely on the fence about whether to do it internally, then the likelihood is we can go to a company that does it as their absolute core business, then they have such a vested interest in that not failing. That is a much better route to go.

So, let's dive a little bit back to some of the technical side. One thing I was really interested in was the fact that Corbado, it talks about sessions. I can maybe already hear some people use [inaudible 0:31:13] hear the word sessions. Whenever it comes to authorization authentication, they have, in some contexts had a bit of a bad rep, and I think, obviously, we'll talk about it a bit. If there's maybe just a misunderstanding around what we're even talking about here. So, when I looked, Corbado sort of defined sessions a bit differently. I actually used the term short-term sessions via JWT. So, tell us all about sessions in Corbado?

[0:31:39] VD: Yes, session management. Session management, in my opinion, is one of the most crucial but also most complex aspects that comes after authentication. So, you already have authenticated. Gregor, has been authenticated as Gregor. But now how can we keep Gregor locked in? And how can we assure that only Gregor keeps making the right requests? If you browse the Internet and developer forums, there's so many discussions on the proper way to implement session management, be it on Reddit, be it on Twitter, or whatever. And for Corbado, we just chose the term sessions as it's quite commonly used for checking if a user is locked in, and if the request is legitimate, or if it's not. With like standards like OAuth or OIDC, there's also something already in place, which can do a lot of great things, if it's correctly implemented, and if it's correctly set up.

But what we've seen up in the wild, or we've been talking to developers, that many people and also myself, as I mentioned, in the beginning, were kind of inexperienced when they first were tasked to implement OAuth. And I think that's been also quite recently, some huge security leaks, disclosed. I think, with Grammarly, related to pure OAuth to implementation. That's also why we firmly think that in a first party scenario, where you don't need any kind of Google, Facebook, or other social provider login, which is based on OIDC, OAuth 2.0, the standard is in general, an overshoot, because you don't really need it. It's too complex for this simple scenario and we've also seen it quite often, for instance, like the security leaks that if it's implemented by developers who are not too experienced in it, it can be kind of severe. Most people that you speak with, I would say, like 90% of the developers, they don't really understand all the specifications and all the inner workings of OAuth 2.0. They might have heard of that they blindly believe the existing implementations and don't really understand what's going on underneath.

When we decided to build like a session management approach, we had two aspects in mind. It should be secure, and it should be also easily implementable for developers who are not working on authentication on a daily basis. The concept itself is not too far away from OAuth 2.0 or OIDC. So, instead of refreshing access tokens, we have kind of short-term sessions and long-term sessions. The short-term session is also decentralized. It's a JWT. So, there's all these benefits in terms of performance. It gets refreshed every couple of minutes. On the other hand side, we have long-term sessions, which are centrally stored in a database. So, you can also revoke sessions and have like a central handler to keep things in order, or if anything is, that you can just revoke all sessions for a particular user.

[0:34:24] GV: Yes, very interesting. I mean, I think some people may not even realize of OAuth 2.0 was invented in 2012. So, we're kind of still using technologies across the board that are actually if we look at real web history at this point, are quite old and not really angled towards a lot of the use cases of today, which I think clearly, Corbado, is kind of going towards that route. What would you say are any plans to add and iterate on any of these implementations? You kind of touched on, I believe, not exactly having refresh tokens, but having a short-term sessions kind of cover that scenario. Is that sort of how I'm understanding it?

[0:35:04] VD: Yes, absolutely. In general, we're still a startup, and I think iterating on whatever it is, is crucial to your business. So, we try to keep up with new trends and new things that come up in the authentication space. As you mentioned, the concept of refresh tokens, and also our short-term sessions, it's not too far away. We just tried to simplify things compared to like, this hard standard from often OAuth and OIDC. I think, in general, there will be always like an ongoing discussion in the developer community about using stateful and stateless sessions. And I think there's no solution that fits all and to make everybody happy. So, you need to pick a side. You can just take your standing, write a post on Reddit, on Hacker News, which might be very opinionated and you will be roasted. So, there's not like a solution that fits for everyone, and we just want to make a solution that is easily implementable, as I said, and also secure, and that might be in some cases, or in many cases, a favorable option for developers who just want to get things going, and have a proper way of handling sessions in their apps.

[0:36:11] GV: Yes. And another, I guess, part of the whole authentication and authorization, especially aspect is what's been termed zero trust. We've had quite a few episodes on Software Engineering Daily that have touched on these aspects, and just to kind of briefly recap, zero trust, quite a good analogy is an airport, where you get past security, but then you still get checks later on, before you board the plane or other places. How does Carbado sort of think about zero trust and integrate with that? Or that concept? Or not at the moment? Or thinking about it in the future? What about that?

[0:36:49] VD: I think, zero trust is something which is really great, and like the metaphor that you just came up with. So far, there’s not that we'll have like a particular feature in mind, which is branded as like a zero-trust feature. But in general, it's something that we internally discuss often, or if we do our research of adjacent technologies and what's going on in the cybersecurity landscape, you often come across zero trust. There might be some features and things that we will implement in the future. But right now, there is not like one particular feature, which is branded as a zero-trust feature. But still, it's something very, very interesting, where we will definitely put more effort and thoughts into.

[0:37:26] GV: I mean, just to recap, what's the best way for someone, I guess, I mean, a developer at this stage to get up and running with Corbado? I guess, one thing that still just to recap, do they need any auth implementation experience previously?

[0:37:43] VD: In fact, any kind of software developer can actually implement Corbado, because it doesn't need to have any previous experience with working on authentication. Our claim is to make authentication, and in particular, passkey first authentication seamlessly working for any developers with no previous authentication experience required. We do have a QuickStart and some Docker files that are pre-built, which you can just download and get it up and running in five minutes, and also offer various guides for most prominent frameworks, and programming language. So, it's kind of easy to just sign up, try it out, play around and see how things are working in terms of passkeys and from our developer’s perspective, and we are eagerly looking for feedback on more features, on more integrations, and also looking to improve our developer experience in general.

So, if there's anything, any requests that you have, just feel free to reach out, and we try to incorporate it, and make the authentication space and the Internet ultimately a safer place by providing great and easy passkey authentication.

[0:38:45] GV: Well, Vincent, it has been such a pleasure to speak today and learn a lot more about Corbado and passkey. So, thanks so much for your time.

[0:38:53] VD: Thanks, Gregor for having me. It was a pleasure. I really enjoyed it. Talk to you soon.

[END]