EPISODE 1634

[EPISODE]

[0:00:00] ANNOUNCER: SimpleWebAuthn is an open-source TypeScript-centric pair of libraries, front-end and back-end, that make it easier for devs to implement WebAuthn on the web.

Matthew Miller started the project in 2019, and it has grown in tandem with the popularization of WebAuthn. He joins the podcast today to talk about the history of the project, starting from the first commit, the problems it solves, its design, 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:56] GV: Hi, Matthew. Welcome to Software Engineering Daily.

[0:00:59] MM: Hi, Gregor, thanks for having me. It's a pleasure to be on a show and have an opportunity to talk about WebAuthn and passkeys and all that fun stuff.

[0:01:08] GV: Yes, Matthew. It’s great to have you here for an episode today. As you say, we're going to be talking all things WebAuthn, passkeys, Fido, the SimpleWebAuthn open-source framework, and everything in between. So, perhaps could you start off by introducing what is the SimpleWebAuthn framework, and your background and story that led you to produce what seems to have become a bit of a labor of love, that’s taken a lot of time of yours and effort, and benefited many developers as well. 

[0:01:40] MM: Sure. So, briefly put, SimpleWebAuthn is a TypeScript-centric pair of libraries, one for the front-end, and one for the back-end, that work together to make it easier for developers to implement WebAuthn-based authentication. As for the question of why I started this project, you're absolutely right. It's a labor of love. Over the years, this isn't the first time I've worked on or created an open-source project that is really focused on the developer experience. And as a developer, historically, I've done a lot of full-stack development in all different languages. Honestly, I kind of build things to solve the problems that I have. When I do enough research, and I'm able to pull something off, a question that inevitably comes up next is, “Huh, I wonder if anyone else would benefit from this?” And at that point, that's when I kind of go and look at what – I spent a little bit of time researching other libraries or frameworks that might solve the same problem.

Oftentimes, I'll find that they don't. So, then I look at the code that I have, and that's when I kind of try to figure out, okay, how can I build some nice abstractions that like, they're not going to add their own trouble. They're really going to save time, mostly integration-style time. So, SimpleWebAuthn was no different.

I guess for a little bit of history, since you asked, I had to go digging, because I wanted to really find out like what was the timeline of my WebAuthn experience, and it turns out my journey with WebAuthn started, let’s say, on 2019. And just completely offhand, maybe like Hacker News, top article was this post about webauthn.io. I was like, “Well, what the heck is this?” So, I clicked onto there, I found a webauthn.io and webauthn.guide, very old, very established websites, maybe, in the space. And it was an effort out of Duo Labs to educate people on the benefits of WebAuthn. They weren't called passkeys back then. It was just WebAuthn.

And at the time, too, I had the perfect setup to kind of experience WebAuthn and what this sort of alternative to username and password and multifactor was, and it was just such a streamlined experience that just something clicked in my head. And I was like, “I got to know more about this. This feels awesome to use.” It's a very quick experience. You can get in and out of the phishing-resistant aspects of it. I can get into some of these things later.

But being able to experience those for myself was very compelling. So, from that, I ended up spending, I'd say, maybe like a couple of months where I just sat down and was like, “Okay, let's build something with WebAuthn.” I found some medium articles from a gentleman named Yuriy Ackermann, who basically wrote out quasi pseudocode in how to perform all these various response verifications within the WebAuthn space. So, I kind of took all those and learned a lot about how to use work with bytes and JavaScript, which is not really something that I'd had to do as a full stack dev. Everything is JSON. 

So, over the course of a couple of months. I pulled all this together. I built this thing, I called it project clover. You're not going to find it by that name anywhere else. It was just purely a sort of an experiment, an exercise in trying to build out what ended up being a password of a single sign-on. So, I use magic links to kick off, registration authentication, and I built this thing that worked. And like you could click a sign in with Project Clover button, it would kick you over to another website, you would do your password authentication, and you will get sent back, just like federated login, with sign in with Google, sign in with Facebook, that kind of thing.

And at the end of it, so I worked on that maybe July through August, and I got to a working demo pretty quickly. It was rough. It was me just working on a hackathon in my free time or anything. It wasn't going to take off, or so I thought. So, around August 2019, I finished this. I had this thing and I start showing it around work and colleagues. I'm like, “Hey, you guys ever heard of WebAuthn? Look at this thing it can do and look what the authentication experience is like.” And at the time, I was working in consulting, and so I was working for, it was called Digital Ventures under the Boston Consulting Group umbrella. So, we were like a Fortune 100 incubator.

So, I was trying to look at this technology through the lens of like, well, how could we offer this as a feature for some of the things we're building? Its higher security. Would customers be interested in that? And never really caught on just due to the nature of the work. For about six, seven months, I didn't really do anything with it. I kind of sat on it, went back to work and pondered on it. Around mid-2020, I decided, “Well, hey, I have this thing like WebAuthn, it seems I've been seeing hints that more people are becoming interested in WebAuthn.” I had this whole thing that essentially implemented the spec more or less, with probably 80% of the spec was already something implemented, just something I'd written for fun.

I said, “Well, getting this far and implementing WebAuthn actually had a lot of pitfalls for developers.” Number one, like in browser land, there's no such thing as a standard library, really. You had your global classes that have various functionality on them. But there's nothing to, for example, convert from you and eight arrays, from array buffers to anything that's JSON serializable, and that was a real pain point. Because coming from a full stack experience, doing a lot of those single page applications, you live and breathe JSON.

So, that was a pain point that I had identified in my own journey with WebAuthn. And then in addition, on the back-end, there was all this validation or verification logic, that's like, “There's no way a website that wants to adopt WebAuthn is going to implement all of this logic. Because it's very complex, it's very easy to get wrong, and this is a prime thing for a library to tackle.” I said, “Well, I have 80% of the WebAuthn spec, pretty much already written. I think this is the early days of L2 at the time, and that's sort of like API version. So, you can consider it like V2.”

Again, this is May 2020. I went all the way back and I found the initial commit where I had created the SimpleWebAuthn project, had my initial commit message, all nicely laid out there with code that I had pulled out of my Project Clover experiment, and formed the basis of what I quickly decided was going to be a mono repo that would seek to address. There will be two libraries that work together. That was the goal. Two libraries that work together to simplify the front-end story and the back-end story of working with WebAuthn. That was really kind of where it all began.

[0:07:52] GV: Yes. I've got to say, I have used this library extensively, and I think it was the facet, you're pointing out, it is both sides. It’s the back-end and the front-end. That for me, it was a bit of a light bulb, where I was able to go into the docs and just keep flipping between client and server, and there are all these calls that need to be made. There's a lot of back and forth going on, effectively. But this library really does simplify all that from, at least from my experience.

So, what has been the engagement and the feedback, I guess, from developers so far, and what kinds of projects are you seeing adopt this library? I think, is around a thousand stars almost, at this point, which is very impressive. I think, just over the last six months, because I think when I looked to the repo, initially, it was maybe February. When I checked back again, suddenly, slight explosion had happened, I think. Yes. So, what is the feedback you've been getting and where have you seen this? 

[0:08:47] MM: Well, so it's been over three years now, where I've had this open-source code out there, and I've just continued to work to improve it. Like the initial benchmark was, let's implement WebAuthn. So, between May 2020, and February 2021, like the library was in a beta mode. I was just kind of working out in the open. It was open source, essentially, from the beginning. I was just working to craft this API that made sense to me for the initial version. I don't even really know how people find it, to be honest. Almost at a thousand stars, and 993 stars, just before this meeting, I checked, because I wanted to say it was at a thousand. But as much as GitHub stars mean anything really, it's still kind of nice to see that number go up.

But over time, people would just stop by and they're like, “Hey, I have this issue with your library. I can't do such and such.” Or, “I'm getting this weird kind of error.” Those two types of feedback are the thing that has sort of sustained, rather it's represented the community engagement with SimpleWebAuthn. I'm putting this work out there. There are a lot of people that pivot their open source efforts into some kind of community, where they're like, “Oh, yes, let's build a brand and let's do live streaming and stuff like that.” And I never really knew how to start that. So, I never really tried. Then I had a kid. And now, I just don't have time or energy for any of that stuff.

So, I've been content to tinker on this thing as sort of the one thing, the labor of love that I continue to make time for, because I honestly believe I've received enough feedback that's convinced me that it has helped people, and I want it to continue to help people. So, when people stopped by, they'll often be like, “Hey, I have this weird error. This type of response is causing your library to crash.” I’ll be like, “Oh, you work through that. You debug what the problem is. You try to reproduce it. You push an update.” Or some people will say, like, “Hey, I want to use this for, for example, secure payment confirmation.” It is a way in some limited use cases too.

Essentially, on top of WebAuthn, browsers will be able to offer an API for e-commerce sites to authorize payment of something. You make a purchase. But in a way that allows like a bank-held credential or the bank to verify and authorize that on behalf of the user. So, the user still, somebody is going to murder me for that description of it, because I'm not that dialed in to SPC. But we had somebody come by and say, “Hey, your WebAuthn library is phenomenal. It's super great. With this one small tweak, we could use it for this entirely different use case.” I was like, “Well, as a bit of a purist, it may not be.” I just wanted to focus on just one use case. I didn't want to have to like branch out and think about all this secure payment confirmation and follow the evolution of that.

My wheelhouse is WebAuthn. This is SimpleWebAuthn. Passkeys, sure, we'll cater to that, because that's WebAuthn. But at the end of the day, I didn't want to have to expand my time and commitment to this project. But somebody came along and said, “Hey, this is all it takes, and I will submit the PR to get that in.” So, I'll do the code review and I'll get that in.

Not only are people coming by and asking for help. I have an active discussion section that where people just ask Q&A questions or troubleshooting questions. More than happy to help out with that. They'll raise legitimate issues with library, but they'll also submit PRs that add new functionality. I'll accept some and I'll reject some, because I have an idea of how wide the scope of this library should be.

So yes, that's been the bulk of people's engagement with the library. Like I said, I don't know how people come across this. It doesn't come up on any of the tech sites that I post about. I know it's used in a couple of frameworks that are more – they have more GitHub stars than mine do. So, I have to assume that they're more popular than mine. But yes, it's just people come by, and I'll just respond as they arrive.

[0:12:42] GV: Yes. And well, I can certainly attest to that. So back in February, I was looking for a library for this purpose. And well, honestly, I was thinking of putting together my own library. Then of course, I then realized, that's probably not a great plan, given the complexity. Yes, I think there was SimpleWebAuthn. I believe there's another framework and I really looked at both and I do kind of see this as a bit of a one-way door, once you start implementing something like this to unwind that. But at least in my head was going to be difficult. So, I wanted it to be the right choice, as much as you can make that right choice.

I think, it was actually just, I saw your GitHub and then, saw things like your personal site and some blog posts you've put out. To me, it was just so much authenticity. This is clearly what you're passionate about, and that's all I really asked for if I'm going to trust a library to this degree with security is, who's behind it? And is this something that they are actually passionate about? And passionate about keeping up? It seems like the answer was in fact, a yes.

[0:13:45] MM: Thank you. Authenticity is what I aim for. You can't fake enthusiasm for anything like this, especially because it's just, I have ended up in such authentication weeds that I never would have imagined because I am in InfoSec right now. I work for Duo Security under the Cisco umbrella, and working on helping them build out their WebAuthn-based password of support. And I got that job through websites that came out of Duo Security. So, I've really come full circle in my career.

But it's a career path I never planned for. I didn't prepare for it, I didn't go to school for it. Programming has been the one constant that's gotten me into all of these various opportunities to work on stuff like this. But the common thread through all of it is just I believe so strongly that WebAuthn, and now passkeys, as they're coming to be called, is such a compelling, strong way to authenticate things. I want to enable more people to use them.

So, the work on SimpleWebAuthn was really just the beginning for me. Shortly after I started on SimpleWebAuthn – so, webauthn.io is a website that you may have heard about. It's a testbed website that offers people the ability to play around with WebAuthn and kind of get a feel for the various flows of both registering. People think of them as Touch ID, face ID, Windows Hello. If you want to get into the weeds a little bit, they're called modalities. Those are just ways of authorizing the secure hardware on a device to essentially sign something with a private key. Then, your local device is doing this all locally. There's nothing in the cloud.

Then, that response can be fed back to a website that's using passkeys for authentication and using public key cryptography. The public key that comes with that WebAuthn response can be used by the website to verify that the user who's logging in and ostensibly has access to the corresponding private key is that person. So, by nature of this, these are some of the things that start getting into the properties of WebAuthn that make them such a compelling authentication alternative, is that they're phishing resistant, because you have the authenticator. When I say authenticator, you can think of it as like Touch ID on your MacBook. Windows Hello is an authenticator as well. Face ID on your mobile device, or fingerprint sensor on Android, those kinds of things.

When you're using those, you're essentially, you're protected by not only the device itself, but also the browser. Because in WebAuthn, it's not just the user and like the thing that they know, sort of thing. The reason this is all multi-factor authentication is because in a single gesture, in a single scan of your face, in a single scan of your fingerprint, in pin entry, because that's just as valid in WebAuthn, is pin entry as well. In that single gesture, users providing multiple factors of authentication. They're providing something you have, which is the actual access device, or the security key, if you have like a roaming authenticator, and then providing something you know, which is the pin or your local login password in some scenarios, ironically. Or something you are, which is the biometric.

So, the browser and the authenticator also do origin verification. You have all these things that are working together outside of the user needing to coordinate this, in a very streamlined experience that also prevents users from being fished in a way that they could by an attacker that's mirroring a legitimate website, and essentially just intercepting your requests, and replaying them on the attacker site. Because a lot of things about WebAuthn that prevent those scenarios from happening to offer, a really like not only a fast way to log in, which is going to resonate with most people. The convenience and the quickness of the authentication ceremony, are going to resonate with more people than if you start getting into, “Oh, yes, they're phishing resistant.” If the database gets popped, a public key on one site isn't going to be reusable in any way on another by an attacker.

[0:17:29] GV: I think you brought up a really good point at the beginning there, which is around the locality of this, which is that a question I get quite often is, “Oh, you're using WebAuthn in your platform. So, you're seeing my device on your platform.” And I think that's something I struggle to explain to sort of a layman easily by saying, “I don't, actually. I get a public key. That's it.” So, what could you, maybe speak to just to sort of, again, explain that concept where this authentication is not happening on the platform side. It's actually happening completely on the user side, and it's just the platform simply receiving something that says, “Hey, this is definitely this device that has been assigned to this person.” 

[0:18:14] MM: Sure. So, I want to get a little pedantic here.

[0:18:20] GV: Please do.

[0:18:20] MM: In the WebAuthn space, the platform is going to be a reference to typically like a hardware device. Because there's this concept of a platform authenticator, which is an authenticator, some kind of secure TPM and HSM, Secure Enclave and Apple land. They all have these buzzwords, and I think it's a Trusted Execution Environment is the general term and then HSM, TPM. And those are specific implementations of Trusted Execution Environments.

But what's happening is that platform authenticators are – I'm going to keep it Apple-centric, because it just makes it a little bit easier to talk about. But for example, like at the Secure Enclave on an Apple device, is the authenticator that has access to the private keys that can be used to sign what's called a challenge that a website will present to the user’s authenticator. So, the platform authenticator is – so when you say platform in the context of WebAuthn, that's what I think about. It’s a platform authenticator. This is your phone. For most people, this is face ID, or the fingerprint sensor. And for laptops, for Macbooks, that's going to be Touch ID. For Windows devices, it’s going to be Windows Hello. Those are platform authenticators. So, I think in your earlier question, if I could rephrase a little bit, it may be like, what is the relationship between a platform authenticator that is responding to a request to sign in on a website. You'll hear me say, relying party. Sometimes relying party in WebAuthn context is the website that the user is trying to log into.

Okay. Now, with a little bit of groundwork laid, thank you for the opportunity to get a little technical there. So basically, what happens when you sign into a website is you are essentially, a website is going, “Okay, here's a random one-time value and I need you, with your private key, that you have previously registered with me that I can use this public key to verify. I need you to generate a signature over this data. Give that back to me. And I will verify that your private key signed it. Because previously, maybe you've signed in with username and password, and your website pops up something and is like, “Hey, do you want to sign in with a passkey?” And you go, “Yes, sure, whatever.”

So, you click, “OK”, you scan Touch ID and you move on with your life, and you don't really think anything more of it. In both that and most importantly, in an authentication ceremony, what's happened is the website will give a random one-time value. The idea is that this helps prevent replay attacks. It's called a challenge. You get a challenge. It's just random bytes. It doesn't mean anything. The authenticator will sign over that and some other information that the browser gives it, because WebAuthn is a browser API first and foremost, so the browser is always in play here.

The browser will give the challenge and some additional information to the authenticator. The authenticator will sign over that information with its private key, and it will then, the authenticator will hand that signature back to the browser, and the browser will put together a response and give the response back to the JavaScript API, for the relying party, for the website, to then verify and go, “Okay. Yes, this was the challenge I expected. The signature is one that I can verify with the public key that your authenticator previously generated and gave to me. Well, come on in. Come on in.”

In addition, there are some protections. And like I mentioned earlier, the browser and the authenticator work together to help prevent phishing. So, for just a quick recap, phishing is a way for an attacker to craft a website that otherwise looks legitimate, on a domain that looks legitimate at a glance. If you don't spend time scrutinizing it, it may be a zero for an O, and otherwise, looks like a website that you've signed into. And if you accidentally provide your credentials to it, congratulations, you've been fished. You've given an attacker everything that they need to then go to the legitimate website, sign in as you and start wreaking havoc.

So, what happens is the browser is very pivotal in this because the browser knows what the origin of the website is. And for all of the various abuses that are possible with crafting a URL that looks legitimate, the browser can see through that and the browser can go, “Well” – okay, first and foremost, like for example, an attacker is trying to send you authentication options. The input for the WebAuthn API that doesn't match, like a specified value that don't correspond to this website from which the API call is happening. That's not allowed. The API requests will fail and the authenticator will never be asked to recognize anything for the site because the browser knows that this is just not going to work. And additionally, authenticators store, passkeys by [inaudible 0:22:38] is called a relying party ID. RPID. It's the effective domain.

So, for example, like if you have softwareengineeringdaily.com, and the RPID would be softwareengineeringdaily.com, and the authenticator would know, would have a passkey for your site as the hash of your website, of your RPID. So, if somehow the browser's just not doing its job, and a request from an attacker’s website still makes it through the authenticator, the authenticator won't have anything mapped to that website. So, there's another layer of protection there. There's a lot of these things baked into WebAuthn at the spec level, that dictate how the client is supposed to offer this functionality that help keep users from accidentally giving away things that an attacker could use to then impersonate that user without the user knowing it.

Additionally, too, there's one extra benefit that liked emphasizes – there's people that – password reuse is the reality of life. Like, yes, we can wag our finger and go, “You shouldn't use passwords”, but like, we're all humans, we're all people, we only have so much mental capacity to maintain all of our login. Some of us who are more savvy, get a password locker in play, and there you go. A lot of that is taken care of by the password locker for unique passwords on every website. But for majority of people, they're reusing it, they have a mnemonic, or some kind of system that they use. And maybe they just, password reuse is reality.

So, on a website that may have its user database compromised. Your password then goes out there to the dark web or whatever you want, however you want to characterize it. A malicious actor could take that information and try some other websites where maybe you've reused it. And if you've reused your password on another website, sort of the blast radius of password-based authentication is very large, potentially very large, and the user wouldn't be any the wiser really. It was through no real fault of the user, nor the website that got popped that the blast radius was extended out to unrelated websites. 

Now, with passkeys, what is really cool to think about is the fact that because of public key cryptography, a public key is kind of useless. If you have it in the context of WebAuthn, all you can do is verify that a response came from the corresponding private key. So, a relying party stores a public key in a database. And if you imagine a scenario in which a website has used the passkeys exclusively for authentication. They have not a single password because they have achieved the dream. And one day, just something bad happens and their database gets leaked on the Internet. All the attackers would ever see would be like user IDs, and public keys that correspond to passkeys that users were using to log in. And an attacker can't do anything with it.

First of all, passkeys are unique per website. So, every cryptographic key pair, every private key is unique per website, which means every public key is unique per website. So, you can't even really like go to another website and try to – you can't do anything with it. It entirely cuts that off. So, that is one of the really cool benefits of passkeys that I think can be underappreciated in a way that keeps everyone safe.

[0:25:36] GV: Yes. I think the way you explained how that process works, and just how passkeys in general, are working is really helpful, because there is sort of, I would say, a little bit of maybe misunderstanding, in the, I would say, probably the developer community at some stages as to sort of what's going on here, and why would we move eventually away from passwords to passkeys effectively?

Can we maybe just go back to – it was great that you gave a very good definition of platform in this context, and I think that's one area I found interesting, where, at least from what I see. For example, if I go into incognito from a chrome profile, that is a different key to if I'm not in incognito. So, it could be slightly confusing for users where maybe they have two Chrome profiles, and actually one profile does lock them in and one doesn't. Is that kind of how the spec was meant to work?

There's another case here where I've seen so Bitwarden, the password locker have implemented passkeys. And again, it was, even for me, on the first go around, I was a bit confused what was going on here, because Bitwarden pop up and say, “Hey, would you like to save this passkey?” I thought, “Well, hang on a second. I've not used my Touch ID. Passkey of what??” And it is, my understanding is the passkey of having logged into Bitwarden. So again, is that how this spec was kind of supposed to be implemented? Or is this, Bitwarden for example, taking a slightly different approach?

[0:27:13] MM: These are really great examples. And they kind of touch on a lot of the transition and the evolution of passkeys over time. So, to your first question about a user that has multiple Chrome profiles, maybe not being able to sign in across them. Okay, so let's start here.

When we talk about authenticators, there used to be hardware devices. There was these cryptographic key pairs, were pretty much isolated and existed on individual pieces of hardware. They represented device binding, is what you'll sometimes hear. The idea there is that wherever, on whatever piece of hardware, a cryptographic key pair, for the purposes of WebAuthn was generated, it remained on that device. So, every single device that you had, your multiple phones, your multiple laptops, whatever, each of them in a WebAuthn world would have to be registered to a website so that you could log in on all of them.

Security keys were kind of the exception for this because security keys were the first eponymous roaming authenticator. Security keys are a way to register a single device that you could then take to multiple devices and use to login on all those devices. Otherwise, platform authenticators used to generate key pairs that were exclusively device bound, and they would not move between them. So then, that's where you had that story where you would have to register every single one of your devices to log into a website.

There are a couple of problems with this initial support for WebAuthn. The first one was that if you think about security keys, like great, you can register that and you can use it across devices, very convenient. But if you accidentally threw your security key into the ocean, or it got run over, or crushed, or thrown in the wash too many times, something bad happened to it. By the nature of public key cryptography, you could not regenerate that private key, you were locked out of all your websites. That was a real problem. So, what was the solution to that? Buy two UB keys. Buy two security keys. If I want to keep it vendor-agnostic here.

Great. So then, on every website that you wanted to register, or that you wanted to use WebAuthn to sign in, you then have to register two security keys. One that you would keep sensibly off-site, but then if you kept it on-site, how would you register it as a backup? So, there was a ton of user friction in that flow. They also had a cost associated with them. Nobody wants to spend 20, 30, 40, 50 bucks per key, when you had to maintain two of them. It was just, for consumer adoption, that was a nonstarter.

That was why platform authenticators were so compelling, because they were authenticators that were integrated into the hardware that people had on hand. Just like the best camera is the one that you have on you, that is your smartphone camera, is most people's best camera. The best authenticator for WebAuthn that you had was the one that was baked into the device that you were using, your smartphone, or your laptop, or your computer. But the problem with that was that if you – this is a perfect example for it. In the US, every two years, historically, was your phone trade-in cycle. So, you could not have passkey – WebAuthn would have no chance of success if it could not survive a user going to their mobile provider and going, “It's been two years. I want the latest and greatest phone.” And you trading your phone, that is the only thing that has access to your WebAuthn credential. Now you're locked out of everything. No, that's not going to – there would be no way for mass consumer adoption with that model either.

That was sort of the first couple of years of WebAuthn. Why it never really took off, but it was still – it wasn't in a position to really take off. But then WebAuthn got to a point where we're like, “Okay, we have enough hardware and software buy-in, in the form of Apple, Google, Microsoft are basically in agreement that this is a compelling, authentication future state. And they're now signaling publicly, their interest in getting on board with this and adding support to their operating systems.” So now, questions sort of became, now you had the buy-in from the big three, that question became, well, how do we get people to use it? How do we address those scenarios, the device loss scenarios? That's where syncing came in.

That was when passkeys came on the scene. Passkeys wasn't a purposeful effort to give a friendly name to WebAuthn. And so, that's why when you see passkeys, passkeys are WebAuthn. So, when you want to learn about how passkeys work, learn about how WebAuthn works, because that's exactly what they are. It's just a nicer name for it. But passkeys also bring along with them some things that WebAuthn didn't. That’s namely syncing, because that solves the big problem of device loss. What's happening now is previously those cryptographic key pairs that used to be locked and isolated on the devices that created them, are being encrypted locally, that encrypted blob is being synchronized across Apple, Google, Microsoft. Their respective clouds to devices that have access to those, to then be decrypted locally, so that you essentially have multiple copies of the same key pair on multiple devices. That streamlines this experience tremendously.

Now, a user, the authenticator used to be synonymous with a piece of hardware. And that's no longer the case. And the spec never said, the WebAuthn spec, never said that an authenticator had to correspond one to one to a piece of hardware. It just said that authenticator had to manage the credential. So, what happened with passkeys is the definition of an authenticator was reinforced to be the idea of an authenticator.

Now, what we kind of ended up in is we sort of, like, yes, we still think of WebAuthn authenticators as being grouped into that platform versus cross-platform, paradigm bifurcation. But what's really going on is we have like virtual authenticators that are sitting on top of the access to the actual hardware and are handling the synchronization in a way that the spec is not concerned with, the synchronization part that is. So, the synchronization is handled by the platforms across the platform’s respective operating systems, and the user is saved from all of these frictions that used to be the reality of WebAuthn use back in the day.

Now, going back to that every two-year phone upgrade cycle, all the user has to do to get back into their sites is trade in their phone, and then sign back in with their iCloud account, their Google account. Microsoft is a little bit of taking their time to perfect their passkey implementation on Windows. So, in due time, it will be signing with your Microsoft account on your Windows device, your Google account, and your Android, and assume Chrome OS, and then your iCloud account on iPad OS, Mac OS, iOS. 

That is what passkey is really infer, is that synchronization of credentials, because that was the only way to gain mass user adoption. Now, that passkeys are on the scene, you're seeing a lot more effort to sort of educate the public to change hearts and minds to make passkeys something desirable, and also, kind of bringing this all full circle to the simple WebAuthn story. Adoption now is the big challenge. Because in just a short span of time, we have people all the way – devices that run Android eight, up until now, Apple has somehow achieved phenomenal operating system upgrade percentages in like your high 80%, 90%. So, my point is anything modern, that can run basically anything from like 2019, 2020 kind of thing, have access to passkeys. All the capabilities required for that. All the cryptographic hardware, and modern evergreen browsers that are able to update rapidly and offer WebAuthn and support it much more quickly than OS update-based support ever was able to accomplish. And what that all means is that now access to the technology is available to a majority of people. Now, you need the websites to support it. So, that thinking was one of the reasons why I decided to continue with SimpleWebAuthn, is because I saw the adoption and the interest grow, and my thinking was well now like we have to make it easy for developers to use WebAuthn, because it's developers that are going this stuff. And if developer friction represents adoption friction.

So, that’s why when I started SimpleWebAuthn, I got the attention of Duo. I knew that Duo has its own WebAuthn library. They have two of them, actually. One was a Golang library and another one is Py WebAuthn. And my interest, because I'm also a Python head, was to take that Py WebAuthn project and inject some of my experience from building SimpleWebAuthn into that, and keep that project going. Now, once I join Duo, I very quickly took over that project because no one else at Duo who created that was there anymore. So, it was a perfect opportunity for me to come in and try to make it easy.

If you look at the API of Py WebAuthn, it's almost identical to SimpleWebAuthn and it's not a coincidence. It's because I wrote, I rewrote the library. It also works with SimpleWebAuthn browser, and that's not a coincidence, either. That was to make my life easier and using them webauthn.io. So, that has been kind of my focus lately, is how can we continue to try and make it easy for developers to implement WebAuthn?

[0:36:07] GV: Thank you for clearing that up. I think that's very helpful. When we're talking about WebAuthn and passkeys, I think that's an excellent way to explain it. And one carve out, I think, is worth calling out over the air is Firefox and Touch ID on Macbooks, which doesn't work still, which is quite frustrating and often ends up in a lot of, as a developer going down the rabbit hole, trying to fix that one and realizing we're waiting on Firefox fixing it, I believe. Is that the right way to explain it?

[0:36:41] MM: Okay. So, this goes back to your original question of like, if you have the concept of an authenticator, because it wasn't bound to hardware, Chrome, Mac OS, Chrome specifically had what was called a profile authenticator, and that is why when you have multiple Chrome Profiles, each of them has their own credential store that is bifurcated by Chrome profile. So, when you have multiple Chrome profiles, Chrome wasn't doing any synchronization, and even internally within the app. They were bound to the browser profile, which also was kind of a foot gun where some people like to go in. I've worked with people and troubleshot issues that people have had, where they'll go in and they'll clear their browsing history. And Chrome, for a little while, made it a little too easy to blow away all of your WebAuthn credentials too, which locked you out of your website.

I won't dwell too much on that, because what we're seeing is that the platforms, and when I say platforms, now, the platforms, the operating systems are offering access to Windows Hello, like experiences now on Mac OS. Especially, if you are on – what are you on? We're on a Mac OS 14. You 13.5 and newer, I believe on Mac OS. Chrome added in Chrome 118, you now have access to the exact same iCloud Keychain-backed WebAuthn experience that Safari users have experienced historically.

So, what we're seeing now being achieved on Mac OS is the same kind of one WebAuthn experience regardless of browser, that Windows Hello has represented, historically. Now, to your question about what is going on with Firefox on Mac OS, it's just, there is, currently, an effort in Mozilla land to implement those platform APIs, those operating system APIs, so that the historic lack of support for Touch ID and Firefox will no longer be an issue, at some point. We could drop in the show notes, a link into Mozilla's bug tracker, where they're tracking the work to actually implement that because we're actively working towards it, to achieve the same thing in Firefox that Chrome has gone through the effort of implementing so that no matter what browser you use on Mac OS, it's no longer a question of what browser you're using on Mac OS. It's just, have a recent enough browser, that has implemented the OS API that's there, and available for third parties to integrate with, and then your passkey experience feels a lot like Windows Hello.

So, I'm very, very excited for that. But the conversation, I want to take it into the idea of a passkey provider API, because now, the platform's like I said, there's sort of three actors in play here in a WebAuthn ceremony. It's the relying party, the website, the user is trying to log into, the browser that the user is viewing the website they're trying to log into through, and the authenticator that the browser communicates to in response to the website calling WebAuthn. The passkey provider APIs are additional API's that third parties can integrate with to be authenticators.

The idea behind all of this, and to be clear, these insights that I have are because I'm an active member of the web authentication working group through, which is part of the W3C, and also, I participate in the FIDO Alliance, which is sort of the other half of FIDO too, through my work with Cisco. So, I know ostensibly like, we've been talking about SimpleWebAuthn, which is a personal project that I set up a very strong firewall. I don’t work on it, work time at all, because I wanted to maintain control over that. 

But in last year, around the same time, there was this idea of okay, third parties are like one password, Dashlane, Bitwarden, NordPass, all these password providers, and potentially other companies want to be able to play and maintain relevance in a passkey centric world. Because if you think about it, passkey is just kind of sort of an existential threat to them. But they have masterfully found relevance by treating passkey management, kind of like password management. That is to say, users go to these companies and subscribe with these companies and trust them with their secrets already, what is the passkey? But another secret.

So, the passkey provider APIs were a way for third parties to officially integrate with the MacOS. I'm going to call it the Safari WebAuthn experience, that sort of way of authenticating, or with Windows Hello, and being offered – and in Android. I shouldn't leave Android out, because Android has really good third-party support for passkeys. And showing up as an option on there, while the overall experience is the same, regardless of the additional password manager or the passkey provider that you have installed on your app. 

The reality of where we are with all of this is that passkey providers have all found success with their product and know the realities of how users interact with their product. And one of the strange realities is that browser extensions are very common way for users to interface with their chosen password manager. And unfortunately, passkey provider APIs require a native application in the mix to implement those native OS API calls. But a browser extension is about as far away from a native app as you can really get, because the browser extensions, their runtime is the browser, and it's the browser in the native app that would have access to the OS APIs.

So, it's been a really – I have very complex feelings about the current state of WebAuthn. Emphasizing the fact that these are growing pains that will be addressed with time. We are very early, all of us, the ecosystem, the major players in the space, the websites adopting them are very early days still. And these are problems that can get worked through. But what we're seeing is that for the sake of a unified auth experience, regardless of the browser, and the operating system that you're using, the browser extension offers, and the browser extension that intercepts WebAuthn. So, for example, Windows Hello, or the Mac OS platform authenticator never actually get the WebAuthn response.

On the surface, you hear about that hijacking, API hijacking, API interception, like, ooh, that's bad. But you got to think about it from the perspective of the password manager, is they want to offer a consistent experience, regardless of where you are, because they offer functionality that brings a user's secrets to where the user is. And fairly, recent WebAuthn history, passkeys were only being synchronized across the first party, Apple, Google, Microsoft Cloud, and their respective operating systems. So, for example, if you registered a passkey that was going to get synchronized, and you registered on your MacBook, you could not turn around on your Windows machine and use that credential with Windows Hello, because there was no synchronization of any data between Microsoft's cloud and Apple's cloud. So, people said, “Oh, this is vendor lock-in. People are going to” – these are just Apple, just wants to keep you on your stuff so you can't synchronize. It’s like, okay, it’s fun to hate on them, I guess. I kind of grew out of that, and eventually most people do, I think.

But it was just because it was still really early days, and there are tough questions around how do you securely synchronize private keys without exposing them in a clear text way, in that intermediate state? So, those are problems that are also being worked on. But in the meantime, while a synchronization technique gets finalized, that Apple, Google, and Microsoft will eventually adopt, I have to imagine at some point, I don't have any insider knowledge there. Third-party passkey provider or third-party password managers, rather, were already in a state where they were synchronizing all of these secrets securely between operating systems. That was their opportunity to get in on this, and to have a value proposition above and beyond, or rather to customers that wanted to be able to use a passkey across that threshold, across the ecosystem.

So, the passkey provider APIs were a way for sort of there to be this happy medium where yes, we have many players that could be synchronizing things across, but we want the overall WebAuthn experience to be the same so that a user can get familiar with it. But the rate at which the platforms offered those kinds of APIs, because they had to be thought of, they had to be implemented. OS rollouts are on slightly longer timetables than browser rollouts. So, it just took time for those APIs to become available.

In the interim, for those password managers that were largely browser extension-based, they couldn't tap into those official APIs. And so now we have this current state where, for example, one password will pop up a thing and say, “Hey, do you want us a passkey?” And you're like, “Okay, sure.” You click it and like, you're not asked to do Touch ID, or anything like that. It just happens. Honestly, as a user, I enjoy that. I do appreciate how streamlined they've made that experience. But as someone hyper knowledgeable on how WebAuthn “should work”, it's odd to consider the fact that, for example, you could think of the unlocking of a password vault, as the providing of a pin with a security key. You have to not only have the device that has the one password account signed into, but you also have to know the vault, the master password to unlock that.

So, if you provide both of those, you are doing multi-factor authentication. It's just that the user verification step took place at the time of vault unlock, which may or may not be immediately at the time of authentication. It might have been 30 seconds ago. So, there is a balance to be had here, between usability and security. It's an eternal struggle to find that happy point where everybody feels like there's enough security and users feel like it's something that they actually want to use.

This is just an example of all of these various players in this space, trying to find their happy medium on that spectrum, and some organizations will like it, some will not. Some users will love it, some will not. I think that's just what we're finding now, is everybody's trying to find that happy medium. In the meantime, as third parties try to find that visa vie, their browser extensions, the operating systems try to offer ways for official integrations via native apps, and how do you – what are the ergonomics of that to make it easy to implement. But then also, what our users expectations are also kind of being discovered. Because that's the funny thing about passkeys is, we have all suffered under the oppression of username and password and multi-factor authentication for decades that we've all internalized it. And like, yes, when I log in, the experience has to suck. Because if it doesn't suck for me, it's going to be too easy for someone else to come in and login as me.

But then, you experience WebAuthn. You're like, “Okay, I go to sign in. I click one button, I tap my Touch ID, and I'm logged into the website, and it happens in a fraction of a second.” A lot of people will be like, “I'm logged in. That was too fast. There's no way that that is more secure than me having to pull out my phone, look up an OTP code, and put that in, or wait for a text message.” And educating users about how this is a superior authentication technology is just going to take time, and people getting used to this is going to take time, because we're challenging norms that people have gotten accustomed to and that's always going to take time.

[0:47:54] GV: I was at a conference yesterday. I'll not name the large tech company that threw it. But I actually showed them what I'm working on, which uses exclusively WebAuthn and passkeys to register and showed to the developer advocates, registering for my platform. And even they couldn't believe how fast that was. They said, “What? That's now signed up?” And I said, “That's it.” So, seeing kind of even the surprise on their face, was a bit of a light bulb for me as well, realizing that everything you've just said over the last sort of five minutes, there are just so many bits to this, that everybody's perception of what WebAuthn or passkeys is, and how that looks to them is actually quite different right now. I'm really hoping in, let's just say, a year from now, we're having another conversation, and we're actually going to hopefully laugh about few things that were the case today. And we can say, “Isn't it fantastic that we've got this sort of unification.”

So, I think that's a good place to leave. That's a lot of detail on WebAuthn and passkeys, which has been fantastic. Good place to kind of leave that there. And let's just switch gears briefly back to SimpleWebAuthn and the fact that you had to take a spec and convert that into a library. I'm sure there's a lot of developers out there that have thought about doing this, not necessarily in this area of development of security, but anything that kind of interests them. Could you maybe just speak briefly to kind of what was that process like? And for example, what are maybe just some brief pitfalls that you could give any developer tips on, in terms of don't let the spec take you in this direction or something? How did you find that process?

[0:49:38] MM: So, part of my journey, it was really standing on the shoulders of giants kind of thing, because, like I said, I had a lot of full stack web app development experience under my belt when I pursued a lot of this. So, I was comfortable with TypeScript. I was comfortable of JSON. Getting stuff into a format where you could move them around and working with imagining API design that felt fairly sane to use, and sane in the sense that like, “Oh, yes, this is a library that I want to use.”

So, I went into it, thinking I had a decent sensibility of what I would want to work with, the kind of library I would want to work with, where I really was benefited from being able to lean on people smarter than myself in this regard was taking those previous those medium articles that I think I'd mentioned very way at the beginning of the show, by a gentleman named Yuriy Ackermann, who I don't even know what motivated him to do it. But he was taking these what's called attestation statements that are cryptographically, verifiable. It's an attestation, I’m trying to think about an alternative way to describe it. But it's a cryptographically, verifiable statement about properties of an authenticator, that if you do everything correctly, you can chain it back to a known manufacturer, so that the website can go, “Yes, I only want to accept certain security keys for whatever reason. You need FIP certification.” That starts getting into like government regulations, stuff like that.

But the toughest aspect for me was looking at the spec, and like, if you sort of peel out the concept of attestation from WebAuthn, there is still a base level of cryptographic verification that you can achieve passkey authentication with, without getting into the attestation weeds. So, the real struggle for me was trying to build a library for an API, that to me felt like it didn't have a lot of developer influence in the way it was crafted. I say that with all due respect. The people working on the spec, who worked on the spec prior to my discovering it, got through L1 and L2. These people are insanely smart and there are so many foot guns in the world of cryptography that all of these people have developed a nice usable API out of, in a way that offered tremendous security properties. So, I have immense respect for everything that they had done, up until that point.

But one of the things that came out of my, or one of the feelings that I had, when I was trying to build SimpleWebAuthn was like, practically speaking, in my experience of all the single page applications that I had built, of all the websites that I had built, JSON was the median by which API information was transmitted to a server, and was received from a server. The one thing that does not serialize the JSON really well is [inaudible 0:52:21] arrays, is array buffers. Practically speaking, you try to pass those into JSON.stringify, you're going to get some weird data structure, that doesn't make any sense to you unless you know what you're looking at.

So, that was one of the things that I sought. I sat down, I thought to myself, like, “This is really awful, for a couple of reasons.” Like you try to stringify a sequence of bytes. It's nonsensical. But also, if I wanted to encode this into something, those tools do not exist on the front end, unless you pull in a third-party library.

Now, ironically, yes, I was trying to build a third-party library. But also, as a dependency, minimalist, I wanted to encapsulate that functionality in this library. If I was going to do it, I wanted to offer as much functionality as I could. So, that was one of the things that I had to do, was like, I had to figure out what my encoding structure was going to be to get these byte sequences, these array buffers, into something that would make – survive the trip to the server, and for the server to specify to give to the front-end, because the front-end needed to receive these byte sequences from the back-end as well. 

So, SimpleWebAuthn abstracted a lot of that for the developer, so that the developer didn't have to think about that. Like I would look at the spec and I'd be like, “Okay, well, the server is supposed to specify these values as array buffers.” The spec uses base64 URL encoding for some other values, like credential ID and raw ID. And like, why not focus on not introducing another new technology. Some people might be like, “I'll just use base64, whatever.” But there's a difference between base64 and base64 URL, as I've come to become intimately familiar with. It's like, without getting too into the weeds there, it was, like, how do we look at the spec? How do we paper over that so developers don't need to know about that?

But then also, what I ended up doing was after I built that SimpleWebAuthn, and I ended up joining with Duo, and I joined the web authentication working group. One of the things that I sought to introduce was that developer’s perspective in the future API design. So, one of the things that I don't really make a big deal about this, but I figure, “Hey, I have a platform now here on this episode, so why not talk about this a little bit more?” There is new JSON serialization methods coming to WebAuthn in L3. You can read about them now on like the editors draft. But that was my biggest contribution, I would say to WebAuthn, is our native methods that browsers will soon offer to all developers, that will obviate the need for a front-end library, like simple WebAuthn browser. Because these JSON APIs represent a way for a developer to architect a system that uses JSON to get information to and from it, and as long as you use base64 URL encoding, these native browser APIs will know how to convert those into the array buffer centric options that need to get fed into WebAuthn.

In addition to that, I also added in new, like two JSON methods on responses that come out of WebAuthn, so that in a single line, you can convert that WebAuthn response, all of the array buffers in it, into a format that you can just immediately send off to the servers JSON. That, I think, is going to help with adoption. If you bake that into the API, people are going to be able to use it without having to think about pulling in extra dependencies.

Boy, that was – I don't know if that really directly answered your question, because it kind of went all over the place. But I think it just represents how a developer that wants to write to a spec may discover some aspects of the spec that they don't like. And if you can find a platform for surfacing those up, I was very privileged to be participating, or to get a foot in the door of the WebAuthn working group and to be a direct contributor to the WebAuthn API, because I stumbled into a job with Cisco. But there are community groups, the W3C has tons of community groups that are intended to be a way for people who do not have an opportunity to join a working group, to still influence the direction of these things, because the community groups and working groups often have a lot of overlap. You will have people in the working group that are also part of the community group. So, you get a lot of this osmosis of ideas that make their way into the spec, officially. Or you have some specs that are written at the community group. They're not technically specs, but still a way to drive that improvement based on your own experiences that I think if you have an eye for that, and you can look out for those community groups, those represent a great way to take a spec to sort of ask those questions too when you have issues on implementing them, you can just go to those community groups and somebody there will be knowledgeable enough to have an answer. Then, just keep going keep asking those questions too. 

Because if you have questions, chances are other people trying to use it or having the same thing too. If you want to be a library maintainer in open source, it's a thankless job. But if you want to be an open-source maintainer that tries to abstract some of the rougher points of APIs that you've come to grow fond of, there are plenty of opportunities to try and share upstream, I suppose, so that everyone else can benefit from those. Real quickly, on the subject of community groups, if you've listened to this entire episode, and you're like, “Boy, I really want to know more about it.”

I am one of the co-founders of the WebAuthn adoption community group. It's called part of the W3C, the WACG. It's open to anyone to join. You can represent yourself. You don't have to be representing a company or anything like that and we meet every other week and just talk shop. So, we'd love to have you come on board, and you can learn more about it and start your WebAuthn journey, if you want. Sorry, I just wanted to plug that real quick.

[0:57:49] GV: I think that's great to talk about. I mean, I think taking a spec, it’s not just looking at something and then going away and coding. There's a lot of dialogue and a lot of questions that should be asked, and I think that's really great that you've highlighted that, which is it should be something where there's probably a community around the area, or even the spec that you're potentially looking at to create a library from. Don't just go away into your kind of cave, so to speak, and try and create this thing. It’s likely that you're going to be really looking to create a library based on something that you genuinely would like other people to find helpful. Then, it's likely having spoken to others, as you develop it. It's going to really help this with the end product, so to speak.

[0:58:34] MM: And finding that community of like-minded enthusiasts is also you're going to get a better product out of it too, I think. If you're not necessarily interested in trying to like influence change at the spec level, but you still have a passion for writing libraries, finding other people who are passionate about it, you can bounce ideas off of, and through collaboration and working together, you can come to a library API that is better than you would have been able to do in isolation. I'll admit, like, the SimpleWebAuthn, I would argue. It remains simple to use. But that was because it still remains featureful because I've had people who come in and they propose their idea, and I suggest ways they might streamline the API in some way, or still try and keep things simple to use. And yes, it's tremendous how people can come to you, and sort of inspire you to think of something in a new way, and you can bring additional functionality in an API that ultimately people are going to want to use. And I think that's really important for library maintenance. Because if nobody wants to use your library, nobody's going to up star you, or give you stars on GitHub.

[0:59:38] GV: Well, I think this has been a really helpful insightful dive into the world of WebAuthn and passkeys, but also the fact we have to see it through the lens of SimpleWebAuthn and how you went about that has been fascinating and I'm excited for this L3 development and you heard it here first, on this episode, which I think is very cool. I'm excited about it, especially because just you mentioning things like base64 and base64 URL are different. That takes me back to February, going, “Wow, I've got to really learn about just stuff that feels different again.” I thought JSON, we were kind of done with that. But no, there's actually parts of where we're trying to go with the web in general, which maybe isn't what we're used to, so to speak. So, anything that can help that adoption can only be a good thing, I think.

So, Matthew, it's been fantastic to have you on today. We've learned so much. Where can people find you? And what's the best way to get in touch?

[1:00:37] MM: Sure. So, if after all of this, you want to learn more about SimpleWebAuthn itself, maintain a website, a documentation website, simplewebauthn.dev. You can find a link to GitHub where I'm active there and open and receptive to issues and discussions and PRs. Also, in general, if you want to get a hold of me for anything else, my personal website is millerti.me. It’s Miller Time with a period right at the middle of time. You'll find my blog there and additional ways to get ahold of me there. So, please feel free to email me. I'm on Mastodon as well. Happy to connect.

[1:01:11] GV: Awesome. Well, thanks so much again, and hope we catch up again soon.

[1:01:15] MM: Yes. Thanks, Gregor.

[END]