(upbeat music) (audience applauding) - Thanks, John.
So, yeah, I'm gonna talk to you about the state of credential management.
So, as John mentioned, I work primarily on payments at the moment.
Oh my god, look what happened (laughs) it's all good, so, back on (mumbles) So, yeah, I work on payments and payments is almost done and now we're looking at new ways of doing payments, so I'm not gonna talk about payments, I'm gonna talk about credentials.
But you'll see the relevance on how these things kind of sit together.
So, the more security and more authentication that you have there, within your payments particularly, the less chance of fraud.
That's the Twitter version.
So, why do we sign into websites? Anybody? Come on, it's slick, it's like the last talk (laughing) We all gotta get like pumped up.
So, we sign into, for instance, we wanna buy something, we'll now authenticate ourselves because this gives us, for instance, our address might be stored on Amazon.
On GitHub, why do we sign in? So we can identify ourselves to GitHub and that gives us certain super powers like we can merge pull requests, we can make comments. Things like that.
So, personalization and identity is obviously really important. Equally important as, like, why do we sign out? So, we might sign out because we want privacy. So, you know, for whatever reason I wanna sign out and not be seen by a particular website.
And as part of that, we give up certain affordances, so we may not be able to comment anymore or merge pull requests on GitHub.
So, equally as important as each other.
And another really important use case is being able to switch accounts.
You may have multiple GitHub accounts, you might have multiple Twitter accounts, and so on. So, this is part of an authentication flow. So there's various use cases.
So, lets look at the anatomy of creating an account.
So, a login screen of some sort.
So we have, generally, some kind of credential and hear me say the word credential a lot.
So like the email address we could use, something like a first name, and a password. So, pretty standard stuff.
Generally, on the web, we will use a form for that, right? So this is where Mandy's talk comes in really handy, cause you'll see the power again of HTML.
So, we can capture this idea with a form but you'll notice underneath, there's this other stuff. There's this federated stuff, so sign in with Google, sign in with Facebook. So this is something, not super new, but it's also something that we generally have to deal with. Like in the olden days we were only doing like, oh let's just sign in with the form, but now we also have these federated login mechanisms as well, so OAuth and so on. So, let's now look a little bit about credential management. So, user name and passwords we can take as a set of credentials.
So, how do browsers deal with this stuff? So, generally it's pretty simple.
We have a domain and it has a bunch of credentials. These are my real passwords for example.com (mumbles) (audience laughing) So you'll have like, one user name will be marcosc, another one mcaceres, and whatever.
And we can have a whole stack of these.
And these get stored in the browser's credential database. So, you all would have seen this in browsers, right? So, you know, it remembers things for you.
And the really cool thing about that, is that, then, if you have like a sync account or you've logged into Chrome through Google, this syncs across multiple browsers and across multiple devices.
That's really awesome.
So, then when you go to sign in, magically, the browser knows.
So it doesn't matter what device you're on. So that's really, really cool.
So, now, that's relevant for, again going back, relevant for users.
So for you, as developers, you might be like, ooh I want access to these funky things, how do I get at these things? And thankfully, browsers already provide this for you. So, just using a simple form, and I was kinda snotty about his last year, about the autocomplete attribute, and I asked people, let's see if it's gotten any better. How many people are using autocomplete this year? Not many better (laughs) OK, learn to love these things.
Autocomplete, and you can basically say I want this to be a new password.
And this will automatically tie together your form with the password manager.
So, with the credential manager inside the browser. How awesome is that? So, if you also have a login form for your current users you can just put in like, hey autofill that username for me and autofill the current password for me.
And then, depending on which browser, so for instance, in Chrome it will show up like this, and in Safari for instance, which is really cool, it can suggest a new password and that's really powerful. So, now you don't need, or the users don't need to remember or repeat patterns or passwords and do other silly things. They can just be like, oh suggest me a password. So that's really awesome.
OK, so hopefully I've convinced you forms are cool (laughs) can I use forms? Who knows what version of HTML forms were added? It was like (mumbles) HTML two or three or something. So, yeah, forms are very well supported and autocomplete is also very well supported. So please, at a minimum, if you take anything away from this talk, just use the forms with autocomplete. It'll make your life, or your user's lives, much better. Now, we can get a little bit fancier.
So there's a new API called the Credential Management API which is really, really funky.
So, I'm quite excited about it.
Essentially, what it does is it give us an API, so it gives us two parts, there's two parts to this API. There's navigator.credentials which is just an object just as a global demo. And then we have these interfaces which are PasswordCredential and FederatedCredential. You remember I talked about federated logins? We can now have an API specifically for those. Which, you saw from the forms, we couldn't do that with forms.
So, and they all hang off this credentials base class that you can't actually make instances of, but you can definitely make instances of PasswordCredential and FederatedCredential. So, what does that class actually look like? It's very simple and it's very cool, So you just have PasswordCredential and what it takes this little JSON Blob kind of structure or even cooler, it takes your existing HTML form and then looks for that autocomplete attribute. So it goes oh, autocomplete, new password I got that, boom, I'll add it straight in, or the current password, boom, I'll add it straight in. And even cooler, you can put the little icon, you will see why you can do that.
ID is the username so that might be email, whatever. Name is the name of the UI so it's like logging into GitHub. And the password's the password.
And the type for this particular PasswordCredential is just going to be password.
Easy, right? Really cool, super, super basic.
And now, for the other side that I talked about, the navigator.credentials is how you actually access this thing, so it's a little database.
It's literally the same database that the browser uses. So you have your basic database, which you can go, hey get me the password for this particular site and it will give you the password, and you can go and like get people's passwords which is a little bit scary.
(audience laughing) It's really funny, you can go and try it on any site, go and type navigator.credentials and then like get, password, true, and you'll see their password. So, you can store a credential, you can create a credential, if it's that data set, you'll see why this is useful rather than using the constructor.
And preventSilentAccess is for when you log out. Which I'll show you an example of, and that'll all make sense.
So, when logging in, you had this idea of mediations. So, how do you wanna log in? So, we're used to, for instance, clicking on submit. Like, login and we click a button.
What if we didn't need to do that? What if you just log in silently with with no friction? We can totally do this with this API.
The same with GitHub, we can give you the option, so the user can say, don't bug me I just wanna log in silently, cause I use GitHub a lot, I use whatever a lot, don't bug me.
Or the user might have multiple accounts.
In that case we can say optional.
So, OK, choose an account or you may require the user to log in.
So, on GitHub for instance, if you go to like you wanna add somebody to your project, like, you know, so you're working on repo and it's like I wanna give this person some rights, (coughs) excuse me, you essentially, GitHub will force you to re-authenticate. So in those situations you can say, hey I really need you to do this.
So, demo time.
(mumbles) So, let me jump into Chrome.
So, here we have a website just running off local host and I'm going to essentially just use as a username, just my email.
Brand new password.
And remember how I mentioned about the icon URL? I can use me, and then I can save this credential just using the API.
So you see the browser (mumbles) you're trying to save a credential.
Save, OK, we save it.
And now remember what I said about the mediations? I'm now gonna log in to this site with silent mediation, boom, signing in that's me. You can see at the top there.
I could've done that programmatically and it'll just happen. So, I've signed in.
So, again with optional, given that I only have one account, boom, signed in.
And now required, now it forces me to make a choice. Boom.
So I can add another one.
So I'll just add this one, any random password, and I'm gonna use code png, save that credential, save it, and let's see again, optional, so there's my code logo and my normal logo.
So that's really cool, really useful.
Boom, very simple idea, super nice.
The demo Gods were kind today.
(audience laughing) Look, even the emoji's turned back that's (mumbles) OK, so as I mentioned, I just wanna emphasise this, because it's a progressive enhancement you can literally create a password credential by just sending in a form.
You can take a HTML form and say new PasswordCredential with this form and like as I mentioned before, the autocomplete attributes are taken into consideration and you get a new PasswordCredential.
So, this is essentially how you would update a password. So, you create the credential then you go, oh I'd like to post it to check that like, does it meet my criteria? And then I do a fetch, if it returns it's OK, yeah, I can save this. I store it, navigator.credentials have stored that credential in the credentials database. Super simple.
So, from there you can just imagine all the really cool things you can do.
These things are all super basic and there's no magic to it.
So, here's an example of signing out.
So, we destroy the applications (mumbles) so we might clear the cookies, whatever we need to do. And then we say, hey, navigator.credentials.preventSilentAccess which basically prevents the web application from doing that silent mediation.
So it prevents, basically just prevents silent mediation. So can't just like automatically re-log the user in. They are now required to press something to log in again. Cool, so now for federated.
So, federated can be really frustrating.
So, I'm sure you've all experienced this.
Like sometimes it'll just have Facebook and other time you think Google.
And then you can't remember which one you used. Does that happen to people? Happens to me.
I know I got like, on stack overflow, I got a different score on each account, it's real annoying. So, anyway, we can solve this.
So you'll see that this is even more annoying when you have like, oh I'm gonna sign in with Google, and then it's like well but which one of my fricking Google accounts? So, that's also a problem.
Which the federated part of the API can solve, or at least help with.
So, again we have this FederatedCredential class. It's pretty much the same as the PasswordCredential class.
So again, we have a constructor, we send in a little bit of data, and then the only real difference is, you'll see they're the same name, (mumbles) ID all the same. Only difference in the, say, like oh, which protocol did I use and who the provider was. Neat, right? So, as I mentioned here, as I said initially, because these things sync across browsers, and across devices, you get that benefit of like, oh, hey user, last time you logged in using Google, you wanna log in again using Google? So it's a really nice hint and it doesn't store, so it doesn't store the actual Federated.Credential data but it just says, OK, this is what the user used last time. OK, so if this was working, doesn't matter, all we know is that passwords suck.
So, we know why passwords suck, they're hard to remember, people just type Today123, and so on.
So, I'm sure everyone's, the majority of people even developers here, you've all experienced why passwords suck and even in our own, as users, we know why passwords suck.
So remembering them, reusing stupid patterns, thing like that, it's not good.
So, given that this is a talk about the web, you get to watch an ad now.
(audience laughing) And you can't skip it.
(audience laughing) (dramatic music) - [Host] And now, for your final memory challenge, Are you ready? - [Contestant] Yes, sir.
- [Host] This morning you created an online banking password, what is it? (dramatic music) - [Contestant] Oh, dear, OK.
It's mine, so I'll remember it.
I mean, it was today, I can see it, see it. Nope (mumbles) (climactic music) Muffins.
No, that's not her name.
(clock ticking) (mumbles) No, it's, (mumbling) cat names, no, no, no, no, no, no, I got, I'm gonna, I still have time left.
(clock ticking) - [Audience Member] Need a hint? (laughs) (laughing) (baby crying) (gasps) (screeching) (dramatic music fades away) (triumphant music) (audience laughing) - It's pretty awesome, right? If you have like an iPhone 10, it's pretty amazing. So, I'm not here to tell you like, Apple phones, they have a trillion dollars now, so they don't need our money.
(audience laughing) Credential management, 100%, but can I use it? No.
(audience laughing) Honestly, I discovered this after I prepared the talk (laughs) but from Mozilla's standpoint, we're very interested in implementing and there's a really good reason why other browser vendors are not doing it. Cause we hate passwords.
We think they're a bad idea because we know why they're a bad idea.
So we're hoping that we may be able to get away from passwords.
I personally don't think passwords are going away, and I think Apple get that they're not going away, that's why Safari has that beautiful integration of generating passwords for you and syncing them across. Like once you buy into the Apple ecosystem, they sync everywhere including apps, like websites and apps kinda sync together, it's amazing. So, and you have that other affordance which is using your face to retrieve a password. So, wouldn't be nice to bring that to the web? So, very quickly, that's where the web authentication API comes in.
So, what's important here is, you know, having some kind of credential which is something that you know.
So this might be a name, some kind of, again, a password or a pin code, something that you have for instance, your phone, or something that you are, so your fingerprint, your face.
So you can take variations of these, combine them together to, again, create some kind of credential which allows people to log in to a site or authenticate yourself.
And this is what the web authentication API does. Another thing you can do, as I mentioned, so, these technologies which are quite common, so, fingerprint scanner, new one from, not newest, newest one from Microsoft, Microsoft Hello and then YubiKeys as well.
And I happen to have a YubiKey, the little tiny one, I have it plugged in to my device at the moment.
So, the PublicKeyCredential class is essentially how we model these things.
It's beyond the scope of time that I have to explain how this all works, I'm just gonna show you a little bit of code. This is as much code as it takes to actually talk to a YubiKey device.
So basically you have a challenge that comes in at the top, the challenge, you have a 32 bit array that comes in from the server and that's the challenge that you sent to the device. Then you basically say these are the algorithms, so you have like, PublicKeyCredential, using public key, which, class, algorithm, ADSA, doesn't blah, blah, blah. The reply, (mumbles) replying party, replying party.
The replying party is some website.
And then you have the user's details so again, like Firefox user, the display name will be like Firefox user, and then the actual login information which is the ID, so [email protected], you bundle that together into a public key and literally just go, navigator.credentials.create and boom, and suddenly what happens is the browser will now try to do authentication. So, demo time.
Here's Firefox, not Nightly, none of that.
Just normal everyday Firefox, cause there's been Firefox since '62 or something. And we're gonna do code on the (mumbles) and I'm gonna register as a new user here.
So, now it's asking me to touch my YubiKey (robotic beeping) (audience laughing) Yay, (mumbles) successful.
So now we can go back and I can login using that credential. Magic finger! Boom, logged in.
That nice? So I really like it on new Macs you have, oh, we can't use this yet but eventually I hope Apple will let us use the thing on the fricking keyboard so you can just log in using that. So, and Microsoft yesterday announced that Microsoft Hello now works with this API so that's a big deal.
So, can I use this? Yeah, you can see it's already happening, we've got like three browsers already gonna support this, so it's pretty huge, and particularly for Windows users.
So, that's essentially the state of credential management on the web and web authentication.
(audience applauding) (upbeat music)