Hello and welcome to secure JavaScript programming with Vladimir [inaudible]. In this video, we will talk about what to do in the front-end in a single-page application regarding authentication. I decided to go in a special way today, which is I took an application from Github named view authentication example, and we will go through the authentication choices and mechanism used by the author, and see if we want to keep them, if they are to be replaced, and updated. That to view the application, I am aware that a lot of you may be using different frameworks such as Angular, such as React. This actually won't change much. We won't focus on the view part, we will highly focus on the concepts linked to authentication and session management. When we download the application locally, first thing, we need to do is of course npm-install. Luckily, I've already done that. As always, we'd have been waiting for three minutes in this video and now we need to do npm run serve so it will build the application and serve it locally. It's blazing fast that's because I had the application built-in cache as always, it'd took a lot of time. We have a small application that has a login screen. If I refresh the first login screen and there another login screen, I've got already two login pages and that's actually confusing because we have two different code path even if we're using the same component. Let's click on "Login". The first thing we can notice is that actually it's offered me to add the password to my password manager. I dismissed it quickly and I should not have but that's actually very interesting. That means that the form has been properly designed for the password manager to recognize that this is a login field. If you don't do that, well, it will push away people who have security best practices in their daily life. You really want your formulary to be tested against password managers. In may case it's LastPass, but there are other ones like Dashlane. I think it's actually critical that in your Q&A plan, you actually check that the password managers detect a field properly, identify that there is a new login on a new website. To do that, actually, it has to go in your formulary. When you do the input parts, you must make sure that your form has an action field so in that case, it's not available. Let's inspect that in the console it will be better. You must make sure that the firm has an action. In that case, it's not the case, so it can probably be made better. Then you want to make sure that the username part is uptight text or email. It will lead to password manager and the autocomplete do its magic. Even when created an account you want the password manager to be able to suggest a strong password. Then you have the field for password where you must make sure that the type is password. Not only it will hide the password from being seen. Let me do this. You see now the field is not hidden as it should so that's the first thing you do. You want to make sure that the browser knows it has to hide the password from the page, but also it will let the password manager of your user actually know that this is a password field. When you are on a sign-up page, it will detect that you are on the sign-up page and suggest a password. When you are on a login page, it will suggest the accounts to the user. I know it's overlooked, but it's actually critical. Part if you want to protect your users, you want to play well with the tools they use to protect their passwords. Now that we have logged in, let's inspect a couple of things. We will inspect the application cookies, and as you can see, there are no cookies for this app. If I go to local storage, I see a lot of things that shouldn't be there, but I see that there is a user token. Let me clear up the local storage. You know the story. When you do web dev, you have a lot of things. Here, once again my password manager was actually able to detect at those on the website. Now let's check the application state. If I go to the local storage, I see that there is a user token. First of all, there might be setting to put that into session storage depending on your authentication flow, because you don't want the user to actually just have to open the website to be authenticated, maybe. Secondly, this one is more problematic for me. The token must be in an HTTP only cookie. Because in case of XSS, in case of other kind of attacks, this must not be accessible to JavaScript. One may ask, yeah, but in that case, who do I know if I'm logged in on it? I know it's not an ideal solution from a dev architecture experience points. But you can have data about the user in the local storage. Namely, his authenticated username in the local storage or in your cookies that is available through JavaScript. But the token itself should ideally never been accessible by the JavaScript code in the browser, otherwise, in case of cross-site request forgery or XSS is that our other attacks I detail insight learning track, it can be hijacked and stolen to another domain. Also are the same thing for the other databases in browser, you don't want to have the user token in it. Now, let's open network and logout. When we logout, we see that there is no network access. When we logout, we see that they just removed the token from the local storage. That's another very bad practice. You must make sure that the token is invalidated in your logout routine. You need therefore to tell the back end server site that the token is not valid anymore, to do that, what you need to do an HTTP request and then log out endpoint. Probably if you go to the logout method. Instead of just cleaning up the state, you must also have a call that tells the back-end to invade the data token and the current session. Another interesting part is that if you use cookies, you will have a simple life cycle. You will just call slash logout and the back-end will update your cookies that contains a state of authentication. You don't have to fetch anything here more or to handle the states on your SPA site. Because then that's a back-end who handle that reside cookies by removing them, invalidating them, or stuff like that. Another reason why it's actually important to have the token in the cookie rather than in a local storage is that it makes your life easier. If I remember well, there are some calls here. You've got API call that is actually a method that have to get the token somewhere. Because it's not in a cookie to do authentication, you need to actually be able to know what is the token, and you need to fetch it and update your JavaScript code. When you use a cookie, the browser will automatically add the cookie to the request, and that's one extra thing you don't have to think about. If you don't have to think about token management in your front-end application because it's all cookie driven, well, that's an area where you limit the impact of doing bad stuff and failing at doing security. So, for your own safety, for the safety of your website, you should use HTTP only domains scoped, same site expiring cookies. That's 10 times more safe than any alternatives. Question is, can this cookie be a JSON Web Token or a JWT? But never say JWT token because it means JSON Web Token and it doesn't mean anything. Can it be a JWT? Well, it doesn't really matter. The content of the JWT is important for the server, but should not really be used in the front-end. In that case, you should rather use a JSON Web Signature, a JSON Web signed payload which will actually contain things that are signed. It comes from the right back-end, but it can't be used for authentication. It's just here to hold data that are checkable but that can't be really weaponized if leaked. But that's only if you need them. One thing that is actually very well done in this application is in the router part. Before loading any view, it checks if the user is authenticated. In a perfect world, it would be document.cookie that includes the libraries for our front-end cookie management. Well, that's important for two reason. For of course, user experience. You don't want people to be able to see pages that are not allowed to access, and if you want to do a very good UX, you want to redirect them to the first page they wanted after they logged in. I mean, I want to access page A, I need to login then I have a login view, and then it brings me immediately to page A not to the root of the website. It's something you want to do. But it's also important to not let part of your websites accessible without checking authentication because it will just create a weird journeys for scanners and start to enable spamming your back-end with an authenticated request. If slash admin require the current user to be an admin, calls to the admin API will burst with authentication failures if you let this being accessed without authentication of the front-end, and that will actually make a back-end person, whether it's you, whether it's someone else in your team very, very unhappy. If I can do it here on front-end authentication, use cookies and as the back-end person to set the cookies you need about the user authentication. It will reduce the area where you can fail and therefore reduce the security risks on your applications. Thanks so much for watching this video. I hope you enjoyed it and let's meet together soon again. For those who are wondering, I still have a cookie on my desk right now. You know that I really love cookies by now. Bye. Have a great day.
