Credentials management on the modern web
Hello, and welcome to this session.
I'm happy to have you join me today, as I discuss credential management on the modern Web.
When we think about the modern web the modern web is built around three core tenets and that is speed, capability and security which allows us to answer three important questions about the web as an ecosystem.
Fast.
How powerful is it as you build it, and stuff on it?
Secondly, how safe is it as we build it and stuff on it?
And lastly, how, how fast is it as we build it and stuff on it?
In this case you're going to discuss security about how do you manage access Web apps that are tied to an authentication service and how do we store credentials that allows us to access this particular Web apps?
So basically credential management.
When we think also about credentials, there are three important things to note.
So being able to remove friction from signin flows one time, one top signing so after signing, I mean, with account choosers, and then ability to store credentials that allows us to access this Web apps.
Removing friction from signing flows basically involves being able to automatically sign-in back users into a site, even if their session has expired or they saved credentials on another device.
So maybe a mobile device or a laptop.
So being able to sign in with a one tap sign in with account choosers is basically tied to what we call federated credentials.
So federated credentials is where we are using social.
Social signing providers like Google, Facebook and Twitter.
So by natively prompting that chooser to allow users to choose from different accounts they have with Google, you know so to sign in with, into this particular Web app.
And then the next thing is how do we store credentials?
So basically being able to store a username and a password combination.
So what we call password credential metatype and then or even federated account details.
So basically just like I mentioned, our social sign-in with Google, Facebook, and Twitter and other likes, and then and then these credentials also can be able to be synched across devices by the browser.
So these three important aspects ...introduces us to one important API called the Credential Management API.
This API involves three important aspects also that is.
Signing in users.
We're going to look at how to sign in users, and then you're also going to look at how to save credentials from forms.
So basically tied towards a password type of a credential management.
And in this overview, I'm going to show some code snippets and I'll be discussing some of them.
So it's going to be really interesting.
So in signing in users as an aspect, so we have five steps tied to each.
So the first thing with this API or using the the, the, the credential manager API is to be able to get credential information.
And then the next thing is to authenticate the user wuth these credentials, and then do something like I logged in the user, but they are already authenticated.
All right.
So I've been able to update the UI and stuff.
And then a very important thing to do is to handle authentication errors, and then naturally be able to allow users to sign out, and what do we do with credential management management API when a user signs out out of our Web application?
So the first step, so credential getting credential information.
So the first natural thing is to check that the credential management API is supported within the browser, they might access with if they're not supported if it is not supported, then do something else, right?
So in this case we check if possible, conditionally supported and federated credentials supported of it.
And then the next thing is to check that our user is not signed in.
So if a user's not signed in, then that's when we trigger the credential API and we can provide two credental meta types.
So that is password-so could be a username and a password they've federated, which has different providers like Google, Facebook, Twitter, LinkedIn, and all that.
All social service providers, authentication service providers, and then mediation: silent.
So this is kind of giving control to the users to manually check a sign in and whatever's.
And then one interesting aspect with this credential management API is that it's asynchronous.
So after ideally checking that the conditional API is supported and setting, setting up the conditional methods we want to use the next thing on it that we nest is to put a then and then we get the credential.
If we have to also confirm that a credential was actually returned.
And then we have two handlers that handles the password.
If it is a password, if it's of type password, then we send maybe a request to a custom [?], or an API endpoint.
And then we handle that.
So a username and a password.
And then if it's federated in this case, social sign-in, like for example, Google sign-in, you could handle that particular federation.
A federated account with that particular function that handles that.
So that's how you can be, you have to do it and then otherwise, yeah, we just end the process and proceed.
So in this case, if all goes well then just nest it still on the credential management API, you need to get the profile.
And another important thing, you need to check that the profit is actually returned.
So if your profile is actually returned, you need to update the user interface.
And that is how you do so, you can have a method that does that.
So maybe a pro providing a popup, say that you are dedicated or redirecting into, or display a user profile somewhere in the UI and to stop.
Otherwise you can do something else, like setting up a profile.
So you have "profile does not exist" we can also do whatever you want to do.
Yeah, so basically that is the flow.
And then, natural, one important thing that I was talking about is being able to handle authentication errors what my friend calls defensive programming.
And I totally agree with it.
So you need to be able to inform users if anything fails within the authentication process using the credential manager API.
So you can just send them an alarm that sign in failed.
And another important thing, and a diverse aspect to look at it as an engineer is to be able to log errors.
So I think it's very important just to allow you to monitor the performance of your Web app, and the entire processes.
So you can have a custom endpoint that actually captures errors and logs them to a custom dashboard, or can use our third party kind of a service provider to log the same.
So it's very, very important to get all of those errors when they come.
And then the last thing is how do we handle ... signing out ...our user.
That signed out you, we need to also stop the credential management API from [?] to sign in.
Right.
And this is how you do so, you call the preventSilentAccess method on top of the credential API.
And this is how you stop.
If you don't do this, what will happen is even if the user's signed out, they'll always be automatically signed in with the credential management API, once they access this way across the browsers.
So it's very important to get note of theat.
And then the last thing is the flow, just trying to bring everything together.
So this is how everything will look like.
So this is vanilla JavaScript, so you can see you get a sign in button.
So if someone clicks, we check, if the credential management is supported, if it's supported, we get the credential management, then authenticate the user.
Update the profile and handle any errors if they're available.
So basically that is the entire flow.
That's how everything will look.
And then the next aspect of the condition management API is being able to save credential from forms and using them to authenticate users back into a web app.
So it has also five steps.
So the one, one, the first one is being able to include autocomplete, so automatically just filling out the form with a credential and signing in the users and then prevent form from submitting naturally or yeah by self submitted, I mean And then another thing is to be able to authenticate the user by sending a request to a backend or whatever.
So it's the same approach we use with a password credentials, right.
And then being able to store credentials and then doing something like update the UI.
So these have included auto complete.
So if we had a username or a password automatically filled in those inputs field, and then after that, I will need to prepare the popups on me.
So this is naturally the way to do it.
And then after that you can send now a request your back end.
So maybe you have an API's signing endpoint that does handles your authentication or customer authentication.
And that's how you do.
And then you have to include it into their credentials.
And then after that, you need to store it.
So this how you store it.
So you need to check if PasswordCredential is supported, if it is supported, you get the credential and store it.
And whatever credential was saved here.
And then you can resolve and do something else, like handling the profile and stuff.
So this is how the UI will look like.
So where you have like Chrome, the browser are prompting the user to save the same just giving them control of whether to save their credentials and allow them to auto sign the next time they visit, [?]. Yeah.
And then the next thing is update the UI with the profiles.
We'd already talked about it, so you can have a method [?] and then naturally handle errors.
As we discussed in the previous aspect of the credential management API So the flow summary of the same, so you can see we have, this is how it looks like.
So basically you get the form that collects a username and a password, and then prevent it from submitting itself and then sending a request.
Next on to eight is the shared password credential with the form, you store the credential.
After storing the credential, the next thing is you handle sign-in.
So that is now after the credential has been stored, then you need to definitely handle the sign in, the complete the sign in and then naturally catch any errors the occur.
And that is it guys about this session and I'm happy to have had the chance to talk to you about the same.
And you can always ask questions at any time at my Twitter handle @mayeedwin1, and I'll be happy to answer them.
Thank you so much and see you again soon.
Thank you.