WEBVTT 0 00:01.760 --> 00:02.110 All right. 1 00:02.110 --> 00:04.300 It's time to level up yet again 2 00:04.300 --> 00:06.220 and we're now on level 6 3 00:06.220 --> 00:10.520 and on this last level we're going to talk about third party 4 00:10.650 --> 00:11.240 OAuth. 5 00:11.710 --> 00:14.400 Now what exactly is OAuth? 6 00:14.410 --> 00:22.130 You might have heard of this term but all it is it's simply a open standard for token based authorization. 7 00:22.150 --> 00:24.040 Now what did all of that mean? 8 00:24.040 --> 00:25.390 Well let me explain. 9 00:25.390 --> 00:27.030 So you've heard of Facebook right? 10 00:27.040 --> 00:29.740 But let's say that we're building a different web app. 11 00:29.740 --> 00:35.260 Let's say we're building a social network that's going to be the new Facebook and it's going to be called 12 00:35.410 --> 00:43.210 bracebook. And bracebook is an awesome social network for people who have braces. 13 00:43.210 --> 00:49.660 Now when you're a new user who's signing up for bracebook you probably won't have any friends in the 14 00:49.660 --> 00:50.490 beginning right? 15 00:50.500 --> 00:56.110 And nobody likes a social network where you have no social connections and nobody wants to feel like 16 00:56.260 --> 00:57.640 they have no friends. 17 00:57.640 --> 01:05.020 So what can we do as the developers of bracebook to make this process of joining our social network 18 01:05.110 --> 01:06.430 a little bit easier? 19 01:06.430 --> 01:13.510 Well we can ask the user for permission to access their Facebook account and see which friends they 20 01:13.510 --> 01:19.570 have on Facebook are already users of our service bracebook. 21 01:19.570 --> 01:25.960 So now once a user sign up they'll already see that three of their friends are already on bracebook 22 01:26.200 --> 01:33.260 and they're ready to get started in a new life of socializing with their be braced friends. 23 01:33.280 --> 01:35.380 Now how would this work exactly? 24 01:35.440 --> 01:42.490 Well, on our login page we can ask the user to sign in either manually where they don't get the benefits 25 01:42.580 --> 01:49.630 of instantly connecting with their friends who have braces or we can get them to login with Facebook. 26 01:50.230 --> 01:58.510 And in this case what would happen is we would make a GET request to Facebook asking them for this user's 27 01:58.570 --> 02:06.350 friends on Facebook and Facebook would return with a POST request with that list of users and emails. 28 02:06.370 --> 02:08.990 So this might be a really simplified version of that. 29 02:09.070 --> 02:15.450 It's just a straight up table of this particular user's friends on Facebook and all of their emails. 30 02:15.460 --> 02:23.350 So then this gets passed over to our server where we can compare it against our database of users and 31 02:23.350 --> 02:28.220 see whether if we have any matching users who have the same email addresses. 32 02:28.270 --> 02:36.400 So now we know that for this user we have three friends of theirs who are already on bracebook and we'll 33 02:36.400 --> 02:41.290 be able to automatically add them as a friend onto bracebook. 34 02:41.290 --> 02:46.630 And it's also a similar scenario if you are signing up to LinkedIn for example. If you couldn't be bothered 35 02:46.630 --> 02:54.100 to type in all of your contacts email addresses to find on LinkedIn and add them individually, then what 36 02:54.100 --> 03:00.970 LinkedIn might do is it asked you to log in via Google and it will look through all of your contacts 37 03:01.060 --> 03:06.450 on Gmail in order to add them automatically to LinkedIn. 38 03:06.460 --> 03:15.340 So by using OAuth we're able to access pieces of information on these third party websites such as their 39 03:15.340 --> 03:18.480 friends, emails or their contacts on Gmail. 40 03:18.670 --> 03:25.910 But in our case because we're talking about authentication and leveling up the security of our authentication 41 03:26.050 --> 03:34.420 another really big benefit involves delegating the task of managing passwords securely to these companies 42 03:34.420 --> 03:36.270 like Facebook and Google. 43 03:36.280 --> 03:39.440 So as we mentioned before, every day or so 44 03:39.490 --> 03:46.090 yet another company gets hacked. And these companies tend to be kind of low tech companies, companies 45 03:46.090 --> 03:53.200 that are not Facebook, Google, Amazon, who are really known for having great engineers, great teams who 46 03:53.200 --> 03:59.680 are able to implement all of these levels of security for the authentication on their website. And they 47 03:59.680 --> 04:05.110 probably have thought about hashing and salting passwords or other data that they're storing. 48 04:05.230 --> 04:11.440 But there's more. There are things such as not only salting the passwords but also peppering the passwords. 49 04:11.440 --> 04:19.600 Some companies also encrypt the entire database containing the hashed passwords and have a wide array 50 04:19.690 --> 04:26.650 of complex mathematical solutions to keep their user passwords under lock and key. 51 04:26.650 --> 04:33.100 Now as a web developer, we could implement all of those things that I just spoke about and address all 52 04:33.100 --> 04:40.540 of the edge cases but it would take us a lot of time and a lot of development hours. So why not simply 53 04:40.540 --> 04:45.210 delegate this task to a large company like Facebook and Google? 54 04:45.310 --> 04:52.270 So then every time we log in our user we simply ask them to login on Facebook and Facebook will then 55 04:52.330 --> 04:55.620 authenticate them using their own secure methods. 56 04:55.630 --> 05:01.780 And once that's done, Facebook sends us back a message saying "This user is authenticated. 57 05:01.790 --> 05:03.560 There are real Facebook user 58 05:03.740 --> 05:07.280 and they have got their correct username and passwords. 59 05:07.280 --> 05:09.720 So go ahead and authenticate them as well." 60 05:09.860 --> 05:12.590 And that will make our lives a lot easier. 61 05:12.590 --> 05:14.640 We'll have a lot less liability 62 05:14.810 --> 05:19.940 and this is the way that you're seeing a lot of websites going where they only have third party log 63 05:19.940 --> 05:20.160 in. 64 05:20.170 --> 05:22.850 Like login with Twitter, Facebook, Google, GitHub. 65 05:23.360 --> 05:28.290 But in order for us to be able to do all of this we need to learn about OAuth. 66 05:28.340 --> 05:33.330 That is the glue that binds all of this together and makes it actually tick. 67 05:33.350 --> 05:36.470 Now what exactly is special about OAuth 68 05:36.470 --> 05:42.920 because there's a lot of other open standards that does something similar to this? But OAuth is quite 69 05:42.920 --> 05:44.420 special in three ways. 70 05:44.480 --> 05:50.230 The first way is that it allows you to grant a granular level of access. 71 05:50.270 --> 05:56.660 What does that mean? That means that when your user logs in with Facebook, you can request specific things 72 05:56.750 --> 05:58.880 from their Facebook account. 73 05:59.360 --> 06:06.260 So you could say that for my app I only really need their profile and email address. But say if you were 74 06:06.260 --> 06:11.660 Tinder and you wanted to know who or their friends were so you don't accidentally match them up 75 06:12.020 --> 06:15.170 then you might want to know also their list of friends. 76 06:15.560 --> 06:17.750 So this is what I mean by granularity. 77 06:17.840 --> 06:23.750 The app developer can determine what kind of data do they need from the user's facebook account and 78 06:23.750 --> 06:26.120 request those accordingly. 79 06:26.120 --> 06:32.960 Now the second thing about OAuth is it allows for either read only or read and write access. 80 06:32.960 --> 06:39.140 So in the case of Facebook this means that you can either ask them to just retrieve pieces of information 81 06:39.530 --> 06:43.250 about their Facebook account so what's their name, what their email, 82 06:43.310 --> 06:44.680 who are their friends. 83 06:44.990 --> 06:48.520 Or you can ask for right access as well. 84 06:48.560 --> 06:55.520 Say for example in this case if WordPress wanted to be able to post to Facebook on this user's account 85 06:55.760 --> 06:59.780 then they would need to ask for read and write access. 86 06:59.780 --> 07:06.110 And the third thing is that the third party that you're using to authenticate your users should be able 87 07:06.110 --> 07:10.510 to revoke access at any point on their website. 88 07:10.520 --> 07:15.350 So that means if you're on authenticating with Facebook, the user should be able to go into their Facebook 89 07:15.350 --> 07:22.910 account and deauthorize the access that they granted to your websites, say bracebook. And they don't actually 90 07:22.910 --> 07:27.780 have to go onto your website where maybe you're less keen to give up this access. 91 07:27.830 --> 07:34.280 So now that we've looked at what's special about OAuth, the next thing to talk about is, well how does it 92 07:34.340 --> 07:36.690 actually work in reality? 93 07:36.710 --> 07:44.570 So the first step is to actually tell this third party, be at Facebook, Twitter or Google, about our Web 94 07:44.660 --> 07:47.380 application because they don't know about us 95 07:47.390 --> 07:48.190 right? 96 07:48.200 --> 07:54.830 So we have to set up our app in their developer console and in return we get what's called an app id 97 07:54.950 --> 08:01.850 or a client id and we or our website is then the client which will make their request to Facebook 98 08:02.060 --> 08:04.280 to authenticate our user. 99 08:04.280 --> 08:09.170 Now once you've set up your app, the next step happens when the user tries to log on to your website. 100 08:09.560 --> 08:16.100 So when the user hits up bracebook.com and they want to authenticate, we give them an option to log 101 08:16.100 --> 08:17.750 in with Facebook. 102 08:17.900 --> 08:24.350 So once they click on that option then we'll take them to the actual Facebook website so that they 103 08:24.350 --> 08:31.970 are seeing a familiar interface, a trustworthy interface and they'll log into Facebook using their Facebook 104 08:31.970 --> 08:39.950 credentials. And without OAuth what we would have to do is to ask the user, "Hey what's your login credentials 105 08:39.950 --> 08:40.640 for Facebook? 106 08:40.640 --> 08:42.920 Can you give me your Facebook password?" 107 08:42.920 --> 08:44.530 Nobody wants to do that. 108 08:44.540 --> 08:47.870 That seems super sketchy and really insecure. 109 08:47.980 --> 08:55.220 OAuth makes that step a lot easier because it gets them to log in on the website that they actually trust 110 08:55.280 --> 08:56.540 which is Facebook 111 08:56.540 --> 08:56.750 right? 112 08:56.740 --> 09:03.350 Something that they've been using for a long time. Now once the user logs in on this third party 113 09:03.350 --> 09:08.720 then they have to review the permissions that our website is asking for. 114 09:08.720 --> 09:15.710 So for example you might want your profile and email address and they review that and they're like OK 115 09:15.890 --> 09:17.710 I'll grant that permission. 116 09:17.720 --> 09:25.000 So now that they've granted the permission and they've successfully logged in on Facebook then our web 117 09:25.000 --> 09:31.820 site will receive an authorization code from Facebook and this allows us to check to make sure that 118 09:31.820 --> 09:38.060 the user actually successfully signed on to Facebook. They had the right username and password. 119 09:38.150 --> 09:43.500 So we're now able to authenticate them and log them on to our website. 120 09:43.640 --> 09:52.350 But if we wanted to go a step further, we can also exchange our authentication code for an access token. 121 09:52.430 --> 09:58.490 And when we receive that access token from Facebook we would save it into our database because this 122 09:58.490 --> 10:05.150 is the token that we can use if we want to request for pieces of information subsequently. This access 123 10:05.150 --> 10:09.550 token is valid for a lot longer than the authentication token. 124 10:09.590 --> 10:15.130 So the way you should see it is that the authentication code or the OAuth code is kind of like a ticket 125 10:15.140 --> 10:18.290 right? A ticket that you are going to use once to enter the cinema. 126 10:18.770 --> 10:24.410 But the access token is kind of more like a year pass and it comes with benefits like backstage access 127 10:24.760 --> 10:31.700 where you get to request pieces of data from Facebook including their friend list or that username or 128 10:31.700 --> 10:36.650 their password whatever it may be that they granted you permission to access. 129 10:36.650 --> 10:42.200 So the OAuth code is what we need to authenticate user that they successfully managed to log in through 130 10:42.200 --> 10:49.070 Facebook and the access token is what we'll use to access pieces of information that are stored on that 131 10:49.070 --> 10:50.040 user's account 132 10:50.090 --> 10:54.800 nn these third parties website for example their email or their friends list. 133 10:54.860 --> 11:00.680 So now that we've seen all of this let's go ahead and actually put it into practice and in our case 134 11:00.950 --> 11:07.100 we're going to be implementing login with Google using a passport and Google OAuth. 135 11:07.160 --> 11:07.460 All right. 136 11:07.490 --> 11:14.210 So enough theory let's get started implementing it and adding login with Google to our website. 137 11:14.720 --> 11:21.410 So first things first, let's head over to passportjs.org and we're going to go and find the strategy 138 11:21.410 --> 11:22.550 that we need. 139 11:22.550 --> 11:28.000 So here you'll find this two Google OAuth strategies. One is passport 140 11:28.010 --> 11:30.130 Google OAuth and the other one 141 11:30.140 --> 11:35.990 if you scroll down a little bit is passport Google OAuth 2.0. 142 11:36.020 --> 11:38.470 Now it's quite important that we choose the right one. 143 11:38.540 --> 11:44.680 And we're using the latest implementation of OAuth, OAuth 2.0 with Google. 144 11:44.690 --> 11:46.460 So let's select this one. 145 11:46.460 --> 11:54.150 Now here we have the actual strategy NPM package passport-google-oauth20. 146 11:54.170 --> 11:57.270 So in order to use it we first have to install it. 147 11:57.290 --> 12:05.660 So let's go ahead and copy this over to our hyperterminal making sure you're still in the same directory 148 12:05.780 --> 12:10.660 and we're going to npm install this package. 149 12:10.670 --> 12:16.470 Now while that's going, let's take a look at what else we need to do in order to set it up and use it. 150 12:17.090 --> 12:23.960 So the first thing they want us to do is to create an application on the Google developers console 151 12:24.350 --> 12:26.380 and there's a direct link that should take you there. 152 12:26.550 --> 12:31.940 Now once you're here you should be able to go ahead and create a project. So you can either click on 153 12:31.940 --> 12:36.020 here or go over here and click on new project. 154 12:36.020 --> 12:41.840 Now we're going to give our project the name of secrets and you can leave everything else and go ahead 155 12:41.840 --> 12:42.980 and click Create. 156 12:43.490 --> 12:43.750 All right. 157 12:43.760 --> 12:50.120 So that takes a little while but once it's done, we should be able to go ahead and set up our credentials 158 12:50.420 --> 12:51.480 for Google 159 12:51.500 --> 12:51.990 OAuth. 160 12:52.100 --> 12:58.340 So let's click on this tab and the first thing we have to do is go to the OAuth consent screen over here 161 12:58.880 --> 13:04.630 and we're simply going to configure the screen that the user sees when they login through Google 162 13:04.670 --> 13:08.190 and grant your application access to their data. 163 13:08.390 --> 13:13.130 So it's helpful for them to know what application they're talking about 164 13:13.130 --> 13:15.980 so we're just going to put in the name of our app here, 165 13:16.250 --> 13:21.380 and if you have a logo for your app this is where you would upload it. 166 13:21.410 --> 13:28.700 So that on that screen when the user gets asked for permission for your app to access say their contact 167 13:28.730 --> 13:34.790 or their friend or whatever it may be, they can quickly identify who it is that's asking for it and just 168 13:34.910 --> 13:39.150 be rest assured that it's the right one that they're giving permission to. 169 13:39.170 --> 13:42.570 But in our case we're going to leave all of that as blank. 170 13:42.800 --> 13:49.520 And the last thing I want to point out on this page is the part where it says scopes for Google APIs. 171 13:50.060 --> 13:56.450 And here are the fields that you will receive once the user logs in through Google. 172 13:56.450 --> 14:03.740 So in our case, we're probably only interested in the email and the profile ID of our user who's logged 173 14:03.740 --> 14:04.230 in. 174 14:04.310 --> 14:10.940 Now if you wanted more data from them such as. I don't know. their YouTube viewing history, their list of 175 14:10.940 --> 14:18.950 contacts on Gmail then, you would have to add a scope. And in order to add scopes you need to enable certain 176 14:18.990 --> 14:25.210 APIs. And Google API library has a whole bunch of APIs that you can actually tap into. 177 14:25.340 --> 14:31.520 So you can see where they've been using the maps API, you can see what emails have they got that are 178 14:31.520 --> 14:34.280 in drafts using the Gmail API, 179 14:34.280 --> 14:40.760 you could see what the YouTube videos they're looking at and you can also find out who their contacts 180 14:40.790 --> 14:46.650 are through the Google people API. And all of those involve jumping through extra hoops. 181 14:46.760 --> 14:52.620 But in our case we only want to authenticate them through the use of Google login. 182 14:52.700 --> 14:58.400 So we don't have to do any of that and all we need are the default ones that we get for free without 183 14:58.430 --> 15:05.590 even the user needing to see a permissions page because these three things are transmitted every time you 184 15:05.590 --> 15:06.730 authenticate with Google. 185 15:07.330 --> 15:13.420 So now that we're done, the last thing I'll add is that once your website is up and running and you've 186 15:13.420 --> 15:19.810 got a custom domain name and it's being hosted, then you'll want to add all of those things in here like 187 15:19.870 --> 15:25.600 a privacy policy page or terms of service link and also your main domain. 188 15:25.600 --> 15:27.700 So let's go ahead and hit save. 189 15:28.210 --> 15:34.840 And now we get to create our API credentials by clicking on this button. And the one that we want is the 190 15:34.960 --> 15:41.380 OAuth client ID and this is going to allow us to authenticate them using Google. 191 15:41.380 --> 15:47.700 So we're going to be using the OAuth 2.0 protocol and we are a web application. 192 15:47.710 --> 15:54.640 So we'll take that radio button and the name of our app is of course again secrets and there's two other 193 15:54.640 --> 15:56.440 fields that we have to fill in. 194 15:56.440 --> 16:03.080 One is the origin, so where is that request to Google going to come from. 195 16:03.160 --> 16:06.680 And in our case it's going to come from our local host. 196 16:06.850 --> 16:16.480 So we'll put an http://localhost:3000 and this is obviously for when we're 197 16:16.480 --> 16:17.620 testing. 198 16:17.620 --> 16:21.480 And when your websites live you can come back here and change it at any time. 199 16:21.730 --> 16:26.530 But while we're testing all of this, it's really important that we have all of these addresses and that 200 16:26.530 --> 16:28.730 yours as much as what you see on screen 201 16:28.750 --> 16:29.350 exactly. 202 16:30.010 --> 16:34.270 So the second thing that we have to add here is the redirect 203 16:34.270 --> 16:34.810 URI. 204 16:34.960 --> 16:40.720 So this is a route that we're going to plan out on our server when Google has authenticated our user 205 16:40.750 --> 16:47.950 to return to so that we can then locally authenticate them and save the session and cookies and all 206 16:47.950 --> 16:48.250 of that. 207 16:48.700 --> 17:00.250 So here we're gonna put HTTP://localhost:3000/auth/google 208 17:00.730 --> 17:07.690 /secrets. And I'm gonna come back to this route very very shortly but for now just check to make 209 17:07.690 --> 17:15.310 sure that you have inserted in here exactly the same string as I have because if it's not, then our authentication 210 17:15.310 --> 17:18.940 will fail and it'll be hard to identify down the line. 211 17:19.060 --> 17:24.790 So once you've made sure that both of these are correct then go ahead and hit enter and that adds those 212 17:24.850 --> 17:31.130 to our credentials and we can go ahead and create a client ID. 213 17:31.270 --> 17:40.150 So now we get a OAuth client ID and a client secret and these are super important and you should also 214 17:40.180 --> 17:41.680 keep them secret. 215 17:41.680 --> 17:45.190 So that means we're going to put it into our .env file. 216 17:45.190 --> 17:52.270 So I'm going to copy my client ID, I'm going to go back to Atom and open up my .env file and I'm 217 17:52.270 --> 17:55.030 going to add it in using the .env format. 218 17:55.060 --> 18:01.940 So this one is gonna be CLIENT_ID and it's going to be equal to that string that I copied 219 18:01.960 --> 18:09.410 over without any quotation marks or any other sort of Javascripty type of things. 220 18:09.460 --> 18:12.410 And the second one is going to be my client's secret. 221 18:12.580 --> 18:17.090 So let's copy that and add an CLIENT_SECRET 222 18:17.090 --> 18:19.920 and this is gonna be equal to that string. 223 18:19.960 --> 18:20.170 All right. 224 18:20.170 --> 18:27.100 So now that we can save those two things and we can get back to setting up our Google OAuth strategy using 225 18:27.100 --> 18:28.150 passport. 226 18:28.270 --> 18:29.470 So we've done this part. 227 18:29.470 --> 18:36.760 We've created an application on Google Developer console and we now have a client ID and client secret. 228 18:38.340 --> 18:45.600 So now we get to configure our strategy. And the first thing that we have to do is we have to require 229 18:45.660 --> 18:47.820 this package in our code. 230 18:47.850 --> 18:53.880 So I'm gonna go ahead and copy this part and I'm gonna change it to a const but other than that I'm 231 18:53.880 --> 18:55.720 going to leave it exactly the same. 232 18:55.770 --> 19:03.510 So it's a new constant called GoogleStrategy and it uses the passport-google-oauth20 package that we installed 233 19:03.510 --> 19:07.430 just now and we're going to use it as a passport strategy. 234 19:07.830 --> 19:14.190 And the next part is where we get to set up our Google strategy and configure it using all of those 235 19:14.190 --> 19:16.890 details that we received just now. 236 19:16.890 --> 19:23.760 So I'm going to select and copy all of this code from passport use down to the very last semicolon just 237 19:23.760 --> 19:25.290 before authenticate requests. 238 19:25.500 --> 19:31.260 And I'm gonna paste it in here below where we have serialize and deserialize our user. 239 19:31.260 --> 19:33.570 So right here. 240 19:33.570 --> 19:38.430 And it's really important that your code goes in the right order. 241 19:38.460 --> 19:44.190 So for example we can't put that code above this line because it won't work and we can't put it above 242 19:44.190 --> 19:48.250 the session because then it won't save the user login sessions. 243 19:48.270 --> 19:54.380 So this is where we're going to put it after all of the setup and right before all the routes. 244 19:54.450 --> 19:57.750 So let's go ahead and update some of these place holders. 245 19:57.810 --> 20:04.380 So we have to add in our client ID which is in our .env file and so we're going to write process 246 20:04.830 --> 20:15.140 .env.CLIENT_ID. And we're going to do the same for our clients secret. And finally 247 20:15.380 --> 20:22.880 we have to change the callback URL to the same one that we put in on the Google API dashboard. 248 20:22.880 --> 20:26.230 So if you want to remind yourself what it is that you set 249 20:26.270 --> 20:29.660 just click on that and you'll be up to see it right here. 250 20:29.690 --> 20:35.570 And in fact I'm just going to copy that string directly so I don't make any typos and I'm going to paste 251 20:35.570 --> 20:39.630 it in between the quotation marks. And my callback 252 20:39.680 --> 20:47.630 URL hits up a path on my server at /auth/google/secrets which 253 20:47.630 --> 20:49.940 we will set up very very shortly. 254 20:49.940 --> 20:54.170 Now there's just one more thing that we need to add to this configuration. 255 20:54.470 --> 20:59.990 And the only reason why we need it is because Google has recently announced that they are sunsetting 256 21:00.290 --> 21:07.550 the Google+ API and all things related to Google+. And they're finally giving up on trying to 257 21:07.550 --> 21:13.060 make people use their Google+ service as a social media site. 258 21:13.070 --> 21:19.130 So if we head over to the GitHub repository for this package you can either paste this into Google 259 21:19.520 --> 21:22.720 or right click here and click copy. 260 21:22.760 --> 21:28.130 Now if you click on this actual address it takes you to a resource but we actually want to view it on 261 21:28.130 --> 21:28.820 Github 262 21:28.820 --> 21:32.140 and you can see that the link is here in the text. 263 21:32.150 --> 21:36.080 So we're just going to copy that and then I'm going to paste it in here 264 21:36.080 --> 21:40.260 and that's the actual repository on GitHub. 265 21:40.310 --> 21:43.230 So here if you go into the issue section 266 21:43.790 --> 21:48.910 I've noticed that people have been talking about the Google+ deprecation. 267 21:49.220 --> 21:56.430 And the problem is that Google made a recent announcement saying that Google+ is sunsetting. 268 21:56.450 --> 22:01.640 So previously this package relied on Google+ to obtain user information 269 22:01.640 --> 22:04.560 so they got the user's Google+ profile. 270 22:04.670 --> 22:09.530 And people are wondering how would we proceed once that API deprecates. 271 22:09.530 --> 22:15.920 So if you scroll down a little bit, you'll notice there's a post by this guy MarshallOfSound usually 272 22:15.920 --> 22:21.860 the most helpful posts have the most upvotes or thumbs up and you can see that when you're just scrolling 273 22:21.860 --> 22:23.460 through as well. 274 22:23.460 --> 22:29.600 And this guy is very kindly done all of the heavy lifting for us and he's put in a new pull request 275 22:29.690 --> 22:36.590 to fix this package in regard to this deprecation of the Google+ API. 276 22:36.620 --> 22:45.640 So now what he's saying is all you have to do to fix this is to simply add this in these strategy options. 277 22:45.770 --> 22:51.860 So let's go ahead and copy all of this and we're going to paste it right at the end here as the final 278 22:51.860 --> 22:52.750 option. 279 22:52.760 --> 22:58.160 So after the callback URL we're going to add a comma to separate it and we're going to paste in the 280 22:58.250 --> 23:06.050 userProfileURL option set as this link. And I'm just gonna delete the single quotation marks and 281 23:06.050 --> 23:07.970 change it into double 282 23:08.000 --> 23:14.990 just for consistency sake and now when we use passport to authenticate our users using Google OAuth 283 23:15.290 --> 23:20.750 we're no longer gonna be retrieving their profile information from their Google+ account but instead 284 23:20.810 --> 23:26.900 we're going to retrieve it from their user info which is simply another endpoint on Google. 285 23:26.900 --> 23:29.570 Now how would you have known to do this? 286 23:29.570 --> 23:37.700 Well it's very likely that at some point if the Google+ API deprecates then your code might not work. 287 23:37.850 --> 23:41.720 You're probably going to get some warnings down the line in your console 288 23:41.720 --> 23:48.530 and it'll tell you something like "Google+ API deprecated. Fix it by doing this." And I'm simply pointing 289 23:48.530 --> 23:54.620 you to this to future-proof the course because I know that in a few weeks or a few months Google is 290 23:54.620 --> 23:57.230 going to pull the plug and your code might break. 291 23:57.230 --> 24:03.680 But adding this means that we should be now future-proof and it should now work for you even if you're 292 24:03.680 --> 24:06.650 listening to this far ahead in the future. 293 24:07.280 --> 24:14.180 So the next thing I want to point out is here are all the options for using the Google strategy to log 294 24:14.180 --> 24:14.800 in our user. 295 24:15.470 --> 24:19.150 And once that's gone through we have a callback function 296 24:19.340 --> 24:25.760 and this is where Google sends back a access token, which if you remember, is the thing that allows us 297 24:25.850 --> 24:34.490 to get data related to that user which allows us to access the user's data for a longer period of time. 298 24:34.700 --> 24:40.580 We've got their profile which is essentially what we're interested in because that's going to contain 299 24:40.580 --> 24:46.160 their email, their Google ID and anything else that we have access to. 300 24:46.430 --> 24:54.500 And finally we use the data that we get back, namely their Google ID, to either find a user with that 301 24:54.500 --> 25:00.260 ID in our database of users or create them if they don't exist. 302 25:00.290 --> 25:08.270 Now I think you have to realize is that if you try to search for this method, findOrCreate, it's not 303 25:08.360 --> 25:12.270 actually a MongoDB or a Mongoose function. 304 25:12.440 --> 25:18.410 And if you click the first thing you see in Google is a Stack Overflow query and this guy says "I can't 305 25:18.410 --> 25:22.330 find the documentation on this function and I can't make it work." 306 25:22.370 --> 25:26.330 And the answer is "This is not actually a function. 307 25:26.450 --> 25:28.690 It's something that passport, 308 25:28.700 --> 25:35.750 the people who documented this package came up with as pseudo codes or fake code and they basically 309 25:35.750 --> 25:41.570 try and tell you to implement some sort of functionality to find or create the user." 310 25:41.780 --> 25:47.330 And they point out how you might be able to implement something like this. 311 25:47.480 --> 25:56.660 So findOne, and then create the user and then save the user. So you can either follow this advice or 312 25:56.960 --> 25:59.950 something that might make your life a little bit easier 313 25:59.960 --> 26:06.490 is this guy has pointed out that there's actually an NPM package called mongoose-findorcreate. 314 26:06.800 --> 26:12.910 And this package essentially allows you to make that code just work. 315 26:12.980 --> 26:19.880 So they've created that function for you in the package and it does exactly the same as what this person 316 26:19.880 --> 26:21.740 has described up here. 317 26:21.740 --> 26:27.320 And all you have to do to make this work is to just install it and require it. 318 26:27.320 --> 26:28.990 So let's go ahead and do that. 319 26:29.000 --> 26:32.270 Let's npm install mongoose-findorcreate. 320 26:32.270 --> 26:38.920 I'm just going to copy it from the docs and paste it in here. And once that's installed the next thing 321 26:38.920 --> 26:43.360 we have to do is to require it in our app.js. 322 26:43.390 --> 26:49.890 So I'm going to create a new constant right at the top and I'm going to set it to equal findOrCreate. 323 26:49.900 --> 26:54.220 Notice how this is spelt exactly the same as this 324 26:54.220 --> 27:01.480 and when we tap into this findOrCreate it's going to look inside this package to see how it should implement 325 27:01.570 --> 27:02.890 that function. 326 27:02.890 --> 27:09.820 Now the final step that the documentation tells us to do is to add this as a plugin to our schema. 327 27:10.300 --> 27:16.410 So similar to what we did with our passportLocalMongoose package, we're going to also add this findOr 328 27:16.420 --> 27:23.800 Create package as a plugin. So userSchema.plugin findOrCReate. 329 27:23.800 --> 27:30.880 So now our code should work and we should be able to tap into our user model and call this function 330 27:30.880 --> 27:34.170 findOrCreate which previously didn't exist. 331 27:34.180 --> 27:39.970 So now that we've set all of this up in our backend, the next thing to do is to figure out a way for 332 27:39.970 --> 27:42.620 us to be able to tap into it from our frontend 333 27:42.640 --> 27:43.210 right? 334 27:43.300 --> 27:49.150 At the moment on our website there's no way of logging in with Google. 335 27:49.150 --> 27:57.550 If I run my server and I go over to localhost:3000 then you can see when I click on login or register 336 27:57.670 --> 28:05.170 there's no button for me to go down the Google authentication route because all of this is linked up 337 28:05.170 --> 28:07.750 to our local authentication. 338 28:07.750 --> 28:09.190 So what do we have to do? 339 28:09.190 --> 28:12.180 Well, we have to add some buttons onto these websites. 340 28:12.550 --> 28:18.940 So if you head into our views and go over to register.ejs, if you scroll down you can see there's 341 28:18.970 --> 28:22.560 a section of HTML code that is commented out. 342 28:22.590 --> 28:28.420 So if you select all of it and uncomment it by using Command + / or control + / on 343 28:28.420 --> 28:32.760 Windows then we now have activated our code here. 344 28:32.770 --> 28:38.830 So now when I refresh this page we get a button over here that says "Sign up with Google". And let's go ahead 345 28:38.860 --> 28:44.710 and do the same on our login page so that they can access the sign in with Google both when they try 346 28:44.710 --> 28:46.390 to login and register. 347 28:46.420 --> 28:51.670 So these buttons are pretty much identical other than where they're located. 348 28:51.670 --> 28:59.530 One is in registered and one is and login. And they both contain a anchor tag that links to the href/ 349 28:59.530 --> 29:02.200 auth/google. 350 29:02.200 --> 29:07.700 So when the user clicks on this button it's gonna make a get request to this path. 351 29:07.990 --> 29:14.270 And we haven't actually addressed that in our code so let's do that now. Inside our app. 352 29:14.260 --> 29:20.000 js right below where we've got our app.get/ root route, 353 29:20.050 --> 29:27.340 let's go ahead and add a app.get for the route that the button will hit up which is /auth 354 29:27.670 --> 29:36.610 /google. And then let's add our callback. And inside our callback is where we're going to 355 29:36.610 --> 29:39.610 initiate authentication with Google. 356 29:39.850 --> 29:46.150 So to do that we're going to use passport of course and we're going to authenticate our user. 357 29:46.450 --> 29:51.640 And then we provide the type of strategy that we want to authenticate our user with, 358 29:51.640 --> 29:54.900 so this is going to be "google" as a string. 359 29:55.060 --> 29:57.580 But in this case we're using the Google strategy. 360 29:57.580 --> 30:01.070 And notice how this is very similar to the code that we've got down here 361 30:01.210 --> 30:05.100 when we authenticated our user using the local strategy. 362 30:05.500 --> 30:11.620 So we're starting to see how passport can be used flexibly and by adding in or switching out different 363 30:11.620 --> 30:18.190 strategies we can implement lots of different ways of authenticating our user using the same library. 364 30:18.190 --> 30:21.110 Now the next thing we have to provide is a scope. 365 30:21.730 --> 30:23.950 Now how do I know about all of this? 366 30:23.950 --> 30:26.330 Well of course it's from the documentation. 367 30:26.380 --> 30:32.650 So if you scroll down a little bit on the passport Google OAuth documentation page you can see that they've 368 30:32.650 --> 30:34.750 got all of this in here for you. 369 30:34.990 --> 30:40.390 So for simplicity's sake, you can simply go ahead and copy this and paste it in here as well. 370 30:40.540 --> 30:47.200 So in this case what we're doing is we're saying use passport to authenticate our user using the Google 371 30:47.200 --> 30:55.390 strategy which we have setup over here as a new Google strategy passing in all of those things to help 372 30:55.420 --> 31:01.720 Google recognize our app which we have set up in the dashboard. And then we're saying when we hit up 373 31:01.720 --> 31:08.500 Google, we're going to tell them that what we want is the user's profile and this includes their email 374 31:08.650 --> 31:15.620 as well as their user ID on Google which we'll be able to use and identify them in the future. 375 31:15.640 --> 31:21.910 So I'm just gonna go and change those single quotes to double quotes again for consistency. It doesn't 376 31:21.910 --> 31:29.500 actually change anything about our code. And this line of code here should be enough for us to bring 377 31:29.500 --> 31:33.540 up a pop up that allows the user to sign into their Google account. 378 31:33.580 --> 31:39.240 So let's go ahead and save our app.js and make sure that our is still running. 379 31:39.240 --> 31:42.450 And let's go ahead and test it out on local host. 380 31:42.560 --> 31:44.600 So let's head back to the home page, 381 31:44.600 --> 31:48.610 go over to register and click on the "Sign up with Google". 382 31:48.890 --> 31:57.320 And now you can see we get redirected to a page on Google itself and we're able to login using our 383 31:57.320 --> 31:58.130 Google account. 384 31:58.610 --> 32:05.750 So I'm going to select my account to login, but then I get an error and it says "Cannot GET / 385 32:05.780 --> 32:08.930 auth/google/secrets. 386 32:08.930 --> 32:16.520 Now if that route is familiar to you, there's a good reason for that because that's what we set up right 387 32:16.530 --> 32:20.730 here, our authorized redirect URI or URL. 388 32:21.170 --> 32:28.270 And this is where Google will send the user after it's authenticated them on their server. 389 32:28.280 --> 32:31.070 You can see it's pointed us back to our website 390 32:31.070 --> 32:33.090 localhost right? 391 32:33.530 --> 32:40.160 So we need to add this route to be able to authenticate them locally on our website and to save their 392 32:40.160 --> 32:43.370 login session using sessions and cookies. 393 32:43.370 --> 32:50.030 And if you take a look at the next part of this authenticate request documentation, you can see they 394 32:50.030 --> 32:53.290 provide an example of how you might set this up. 395 32:53.300 --> 32:55.360 So it's again going to be an app.get. 396 32:55.750 --> 33:02.420 And this request, this GET request, gets made by Google when they try to redirect the user back to our 397 33:02.420 --> 33:03.410 website. 398 33:03.560 --> 33:08.140 And this string has to match what we specified to Google previously. 399 33:08.360 --> 33:11.650 And then we're going to authenticate the user locally 400 33:11.990 --> 33:16.210 and if there were any problems we're going to send them back to the login page again. 401 33:16.280 --> 33:23.090 But if there were no problems then we can redirect them to the secrets page or any other sort of privileged 402 33:23.150 --> 33:23.810 page. 403 33:24.260 --> 33:31.840 So let's go ahead and copy all of this and paste it into our app.js right below the other app.get. 404 33:32.840 --> 33:36.430 And I've just noticed that this is also single quotes. 405 33:36.470 --> 33:41.580 People are very inconsistent when they type Javascript but I like to keep it all the same 406 33:41.660 --> 33:43.160 so it doesn't confuse me. 407 33:43.460 --> 33:46.220 And we're also going to change it here. 408 33:46.280 --> 33:52.350 Now notice here that the route is /auth/google/callback. 409 33:52.370 --> 33:58.070 We have to make sure that this gets changed to the route that Google actually tries to hit up which 410 33:58.070 --> 34:04.370 is the one that we specified here which is gonna be /auth/google/secrets or whatever 411 34:04.370 --> 34:06.490 you typed into your dashboard. 412 34:06.710 --> 34:13.400 And all we have to do is change this to secrets so that it matches exactly. 413 34:13.400 --> 34:19.340 Now the rest of the code we can leave as the same because the if the authentication fails then we're going 414 34:19.340 --> 34:21.850 to redirect them to the login route, 415 34:21.860 --> 34:28.220 we have a app.get for the login route. But if it was successful then we're going to redirect them 416 34:28.280 --> 34:30.260 to the secrets page. 417 34:30.440 --> 34:39.980 So we res.redirect it's going to go to /secrets and this will take them to here. And 418 34:39.980 --> 34:45.710 we can check to see if the user is authenticated in which case we'll render the secrets page 419 34:46.100 --> 34:48.990 otherwise we'll redirect them back to the login page. 420 34:49.010 --> 34:55.640 So this is pretty much all the code that we need in order to allow users to login using Google on our 421 34:55.640 --> 34:56.130 website. 422 34:56.900 --> 35:04.130 So let's check out what we get back from Google by going into this callback function and let's simply 423 35:04.130 --> 35:09.430 log the profile of the user that we get back. 424 35:09.440 --> 35:17.210 So now, when the user clicks on that button that says "Sign up with Google", it will hit up the /auth/ 425 35:17.270 --> 35:25.040 google route which gets caught over here and that will initiate authentication on Google's servers asking 426 35:25.040 --> 35:28.580 them for the user's profile once they've logged in. 427 35:28.760 --> 35:35.450 Now once that's been successful, Google will redirect the user back to our website and make a get request 428 35:35.510 --> 35:41.840 to /auth/google/secrets. And it's at this point where we will authenticate them locally and save 429 35:41.840 --> 35:43.490 their login session. 430 35:43.490 --> 35:48.490 Now once they've been successfully authenticated, we take them to /secrets. 431 35:49.010 --> 35:56.690 But at this stage, the Google authentication has already completed and this callback function gets triggered. 432 35:56.690 --> 36:02.710 And we will log that profile and try to create them as a user on our their . 433 36:02.750 --> 36:05.940 So let's save our app.js and test it out. 434 36:06.020 --> 36:09.420 So let's go back to our home page localhost:3000. 435 36:09.530 --> 36:16.910 Let's register over here, click on "Sign up with Google" and I'm going to sign in using my Google account 436 36:17.030 --> 36:17.730 here. 437 36:17.750 --> 36:21.470 Now at this point you might end up with an error like this. 438 36:21.530 --> 36:24.860 "Failed to serialize user into session". 439 36:24.920 --> 36:26.300 Why is this? 440 36:26.300 --> 36:29.390 Well, at which point do we serialize our user? 441 36:29.930 --> 36:31.270 It's right over here 442 36:31.280 --> 36:31.810 right? 443 36:31.850 --> 36:40.190 And this code actually comes from a package that we used earlier on, the passport-local-Mongoose package. 444 36:40.910 --> 36:49.370 And they provided a simplified way of serializing and deserializing your users using their package. 445 36:49.550 --> 36:56.060 So it's through the use of this package that's been added to the userSchema where this method serialize 446 36:56.060 --> 36:59.120 User and deserializeUser comes from. 447 36:59.120 --> 37:05.180 Now however, if we look at the passport documentation and how they configure the passport package to 448 37:05.180 --> 37:11.410 serialize users and deserialize users, you can see it's a little bit longer but it means that it's going 449 37:11.410 --> 37:17.090 to work for all different strategies not just for the local strategy. 450 37:17.630 --> 37:25.430 So let's go ahead and replace the code where we serialize and deserialize our user for local authentication 451 37:25.910 --> 37:30.420 and replace it so that it can work with any kind of authentication. 452 37:30.530 --> 37:38.360 So let's hit save over here and now if we go back to localhost:3000 we register our user 453 37:38.360 --> 37:43.400 using Google then you can see it takes us straight to the secret page. 454 37:43.400 --> 37:51.140 Now the other thing we tried to find out is we tried to log the Google Profile that we got sent after 455 37:51.140 --> 37:57.390 the user has been authenticated by Google. And you can see that it's this JSON over here 456 37:58.070 --> 38:01.490 and it has a id for the user. 457 38:01.490 --> 38:07.060 So this is going to uniquely identify this user on the Google user database. 458 38:07.130 --> 38:14.840 It has their name and it can split it into family name and given name. It also got some photos if they 459 38:14.840 --> 38:17.140 have any, a picture of them. 460 38:17.210 --> 38:25.490 But the most important thing for us to save into our database is this id because this id will identify 461 38:25.490 --> 38:28.220 them when they next try to login. 462 38:28.220 --> 38:34.020 So if they create any data on our website we're going to associate it all with this id. 463 38:34.100 --> 38:41.300 So if you look inside our database at the moment, you'll notice that a new user was created. 464 38:41.720 --> 38:50.480 But all we have is an automatically generated MongoDB id and nothing else whereas our previous users 465 38:50.480 --> 38:55.320 had a username and a salt, a hash or an email and a password. 466 38:55.370 --> 39:01.520 But in this case we don't really have anything for this user and we don't have any way of tying this 467 39:01.520 --> 39:04.520 newly registered user with their Google id. 468 39:04.700 --> 39:09.290 So the next time they log in we won't be able to find them on our database. 469 39:09.830 --> 39:17.330 And I can confirm this by simply logging out and trying to login again, sign in with Google, and you 470 39:17.330 --> 39:22.760 can see that in our database all we've done is just create a new user. 471 39:22.760 --> 39:30.050 We now have the seventh user. So that Google id is not being tied to the id on our user database. 472 39:30.080 --> 39:36.170 So let's go ahead and delete these two entries and let's go and fix our code. 473 39:36.500 --> 39:44.780 So at the moment when we get the data back from Google not only do we log their profile but we also 474 39:44.810 --> 39:52.430 try to find it in our database or create them on our database and that's all based off a field called 475 39:52.520 --> 39:57.290 Google id which is supposed to exist on our collection of users. 476 39:57.680 --> 40:04.090 But at the moment, our collection of users only have two fields that we work with: email and password. 477 40:04.190 --> 40:10.100 And this is based off the days when we were still logging users only through the local authentication 478 40:10.100 --> 40:10.520 method. 479 40:11.060 --> 40:16.680 So let's go ahead and add a new field called googleId with a capital I. 480 40:16.700 --> 40:18.520 It's also going to be a string. 481 40:18.710 --> 40:25.610 But this time when a new user registers on our website, we're going to find and see if we already have 482 40:25.610 --> 40:32.750 a record of their Google id on our user database in which case we're gonna save all the new data associated 483 40:32.750 --> 40:40.500 with that id or otherwise we're going to create it on our database and save this information for future. 484 40:41.060 --> 40:48.440 So let's save our app.js and log out of our website and then go ahead and register again. And 485 40:48.440 --> 40:50.630 we're going to sign up with Google. 486 40:50.810 --> 40:56.840 And now if we go over to our Robo 3T you can see our new user gets created with an id that 487 40:56.840 --> 40:59.900 identifies them on our user database 488 40:59.900 --> 41:04.550 but another id that identifies them as a unique Google user. 489 41:05.030 --> 41:11.930 So this is their id which means that if I log out now and I tried to login again, I get to the secrets 490 41:11.930 --> 41:15.620 page but we don't actually create a new user. 491 41:16.010 --> 41:19.070 They're still being identified as user 6. 492 41:19.100 --> 41:25.430 And this is the same thing even if I log out and try to register again as the same Google user. You can 493 41:25.430 --> 41:32.390 see that I'm still not creating another user here because I'm able to find this user by their Google 494 41:32.390 --> 41:40.510 id and know that they already exist. Now remember that because we're authenticating our users using 495 41:40.510 --> 41:41.320 Google 496 41:41.320 --> 41:46.990 we only get what's equivalent to their user name on the Google user database. 497 41:46.990 --> 41:51.940 We don't get their password and this is great because it means we don't have to save it. 498 41:51.940 --> 41:58.960 We don't have to take care of it if it gets lost or it gets leaked that's all on Google and they have 499 41:58.960 --> 42:04.540 a lot more engineers, a lot more resources, to keep their user's passwords or whatever other pieces of 500 42:04.540 --> 42:05.620 information safe 501 42:05.620 --> 42:09.130 and all we need to do is just to retrieve it when we need it. 502 42:09.130 --> 42:16.120 So the last thing I want to do before we finish up is to style up our buttons because if we add a few 503 42:16.120 --> 42:19.690 more buttons over here, sign up with Google, sign up with Facebook, 504 42:19.690 --> 42:23.760 it doesn't really shout to me that this is something related to Google 505 42:23.770 --> 42:24.100 right? 506 42:24.760 --> 42:31.420 So what we're going to use is something called social buttons for Bootstrap and all we have to do is 507 42:31.420 --> 42:38.290 go ahead and download the code and inside the extracted folder you should see a file called bootstrap 508 42:38.410 --> 42:40.900 -socia.css 509 42:40.990 --> 42:49.370 and we're simply going to drag that file into our public CSS folder next to our styles.css. 510 42:49.390 --> 42:52.310 So I'm just going to grab that and pop it over here. 511 42:52.990 --> 43:00.010 So if you take a look at it you can see that it's basically a minified version of some styles that we 512 43:00.010 --> 43:05.910 can apply to any of our buttons to add in some much needed styling. 513 43:05.950 --> 43:11.980 So first things first, if we're going to add in a new stylesheet we have to head over to our header 514 43:12.010 --> 43:15.560 .ejs and add it in as a link. 515 43:15.670 --> 43:22.510 And whenever I add in any sort of styles from any external source say Font awesome or Bootstrap or in 516 43:22.510 --> 43:24.420 this case the social buttons, 517 43:24.490 --> 43:27.430 I'd like to put it above my custom style sheet. 518 43:27.820 --> 43:34.080 So that means I can go into my styles.css and override anything that came from other people. 519 43:34.090 --> 43:39.290 So this is where I'll be adding in a link for that style sheet. 520 43:39.400 --> 43:45.490 And if you right click on that stylesheet that we just got we can click on rename which allows us to 521 43:45.490 --> 43:46.830 see its full name 522 43:46.870 --> 43:50.200 and I'm going to copy it and paste it over here. 523 43:50.770 --> 43:56.350 And we're going to make sure that there is no forward slash before the css and this href should now 524 43:56.350 --> 43:59.890 point to that new file that we downloaded and incorporated. 525 44:00.400 --> 44:08.650 So now let's hit save and go over to our register page and update that anchor tag so that we add in 526 44:08.710 --> 44:10.630 the required classes. 527 44:10.630 --> 44:17.290 So the classes that we need are btn-social which adds some of the sizing and the rounded 528 44:17.290 --> 44:18.710 corners et cetera, 529 44:18.820 --> 44:21.580 and then whichever social button we want. 530 44:21.670 --> 44:27.670 So in our case it's going to be btn-social and Beatty and btn-google. 531 44:27.670 --> 44:34.600 So now if we hit save and go over to our register button and refresh, you can see it now start looking 532 44:34.810 --> 44:43.990 a lot more like a proper "Sign up with Google" button. And in the future if you wanted to add another button 533 44:44.050 --> 44:53.710 say, I don't know, "Sign up with Facebook" then all you have to do is to change this to Facebook and change 534 44:53.710 --> 44:56.740 the icon to Facebook. 535 44:56.740 --> 45:03.790 And when we refresh you can see we now have multiple social signing opportunities for the user and it's 536 45:03.940 --> 45:07.390 all styled with very little effort from us. 537 45:07.390 --> 45:14.200 So I'm going to go and delete that last part and I'm going to go into my login and also implement the 538 45:14.200 --> 45:16.250 same thing for this button here. 539 45:16.360 --> 45:20.850 So btn-social and btn-google. 540 45:20.950 --> 45:31.120 So now both my login and register pages have their buttons styled up and also working plus best of 541 45:31.120 --> 45:37.390 all because we've implemented sessions and cookies even if I go ahead and navigate to a different page 542 45:37.870 --> 45:44.400 I should still be authenticated and be able to access the secrets page without logging in again. 543 45:44.440 --> 45:52.090 But notice that when I click on log out and I tried to log in again I don't get taken to Google again 544 45:52.180 --> 45:54.370 and have to log into my account. 545 45:54.370 --> 45:59.900 And the reason is because we're only persisting the login session on our Web site. 546 46:00.280 --> 46:06.250 So it means that once they manage to get to secrets and they navigate around on our website, if they 547 46:06.250 --> 46:14.260 wanted to access the authentication required route to secrets remember that in our code when they hit 548 46:14.260 --> 46:21.700 up the secret route we run the req.isAuthenticated to see whether if we can render that page 549 46:21.730 --> 46:22.630 for them. 550 46:22.630 --> 46:29.380 So this login session and log out session is related to how they can access our website but it doesn't 551 46:29.410 --> 46:32.960 log them out of their Google account. In order to do that 552 46:32.980 --> 46:39.240 we would need a button that would redirect them to accounts.google.com/logout. 553 46:39.350 --> 46:46.610 But that's kind of annoying because it means that it would log them out of their Gmail, their Google 554 46:46.610 --> 46:53.140 Maps and every single other service that they use on Google which is usually not what you want. 555 46:53.150 --> 46:59.480 So in our case we only need our session to persist for the users login for our website and we don't 556 46:59.480 --> 47:02.570 need to worry about logging them out of Google. 557 47:02.570 --> 47:10.070 So now that we've implemented the Google OAuth social login strategy and we've kind of delegated this 558 47:10.070 --> 47:18.860 whole complicated process of securing a user's sensitive information to Google, as a challenge I want 559 47:18.860 --> 47:23.090 you to try and see if you can implement login with Facebook. 560 47:23.120 --> 47:29.270 It will involve pretty much the same steps as what we've done with Google but it will involve a little 561 47:29.270 --> 47:32.090 bit of searching around and a little bit of googling and a 562 47:32.090 --> 47:37.790 little bit of figuring it out. But at this stage you should be able to struggle through this and figure 563 47:37.790 --> 47:41.300 out how you can implement it without too much help from myself. 564 47:41.810 --> 47:45.440 So best of luck and I'll see you on the next lesson.