1 00:00:00,930 --> 00:00:03,210 ‫So we have our user model set up 2 00:00:03,210 --> 00:00:06,440 ‫ready to save users with secure passwords. 3 00:00:06,440 --> 00:00:08,850 ‫And so next up, we're gonna really implement 4 00:00:08,850 --> 00:00:11,670 ‫user authentication and authorization. 5 00:00:11,670 --> 00:00:14,230 ‫So in simple terms, the whole work flow 6 00:00:14,230 --> 00:00:16,530 ‫of logging users in and allowing them 7 00:00:16,530 --> 00:00:19,360 ‫to interact with certain protected resources 8 00:00:19,360 --> 00:00:22,163 ‫that non-logged in users cannot access. 9 00:00:23,100 --> 00:00:26,050 ‫Now there are many authentication methods out there, 10 00:00:26,050 --> 00:00:29,360 ‫but the one we're gonna use is a very modern, simple 11 00:00:29,360 --> 00:00:34,360 ‫and secure approach called Json Web Tokens or JWT for short. 12 00:00:35,170 --> 00:00:38,100 ‫So Json Web Tokens are a stateless solution 13 00:00:38,100 --> 00:00:39,500 ‫for authentication. 14 00:00:39,500 --> 00:00:43,410 ‫So there is no need to store any session state on the server 15 00:00:43,410 --> 00:00:47,360 ‫which of course is perfect for restful APIs like the one 16 00:00:47,360 --> 00:00:48,580 ‫that we're building. 17 00:00:48,580 --> 00:00:53,080 ‫Because remember, restful APIs should always be stateless. 18 00:00:53,080 --> 00:00:56,300 ‫And the most widely used alternative to authentication 19 00:00:56,300 --> 00:01:00,240 ‫with JWTs is to just store the user's log-in state 20 00:01:00,240 --> 00:01:02,420 ‫on the server using sessions. 21 00:01:02,420 --> 00:01:05,150 ‫But then of course does not follow the principle 22 00:01:05,150 --> 00:01:08,700 ‫that says that restful APIs should be stateless 23 00:01:08,700 --> 00:01:12,293 ‫and that's why we're opting for a solution like JWTs. 24 00:01:13,130 --> 00:01:15,960 ‫So now let's take a look at how authentication 25 00:01:15,960 --> 00:01:18,660 ‫actually works with Json Web Tokens. 26 00:01:18,660 --> 00:01:21,600 ‫And assuming we already have a registered user 27 00:01:21,600 --> 00:01:25,380 ‫in our database, this is how a user logs into the app. 28 00:01:25,380 --> 00:01:28,700 ‫So the user's client starts by making a post request 29 00:01:28,700 --> 00:01:32,330 ‫with the username or email and the password. 30 00:01:32,330 --> 00:01:35,400 ‫The application then checks if the user exists 31 00:01:35,400 --> 00:01:37,430 ‫and if the password is correct. 32 00:01:37,430 --> 00:01:40,340 ‫And if so, a unique Json Web Token for only 33 00:01:40,340 --> 00:01:44,010 ‫that user is created using a secret string 34 00:01:44,010 --> 00:01:46,290 ‫that is stored on a server. 35 00:01:46,290 --> 00:01:49,410 ‫And a JWT itself is really just a string 36 00:01:49,410 --> 00:01:51,150 ‫that looks something like this. 37 00:01:51,150 --> 00:01:54,170 ‫But we're gonna talk more about the JWT itself 38 00:01:54,170 --> 00:01:55,770 ‫in the next slide. 39 00:01:55,770 --> 00:02:00,440 ‫Anyway, the server then sends that JWT back to the client 40 00:02:00,440 --> 00:02:04,160 ‫which will store it either in a cookie or in local storage. 41 00:02:04,160 --> 00:02:06,930 ‫And just like this the user is authenticated 42 00:02:06,930 --> 00:02:09,570 ‫and basically logged into our application 43 00:02:09,570 --> 00:02:12,720 ‫without leaving any state on the server. 44 00:02:12,720 --> 00:02:16,310 ‫So the server does in fact not know which users 45 00:02:16,310 --> 00:02:17,930 ‫are actually logged in. 46 00:02:17,930 --> 00:02:20,960 ‫But of course, the user knows that he's logged in 47 00:02:20,960 --> 00:02:25,040 ‫because he has a valid Json Web Token which is a bit like 48 00:02:25,040 --> 00:02:29,270 ‫a passport to access protected parts of the application. 49 00:02:29,270 --> 00:02:32,470 ‫So again, just to make sure you got the idea. 50 00:02:32,470 --> 00:02:35,330 ‫A user is logged in as soon as he get back 51 00:02:35,330 --> 00:02:39,720 ‫his unique valid Json Web Token which is not saved anywhere 52 00:02:39,720 --> 00:02:41,030 ‫on the server. 53 00:02:41,030 --> 00:02:44,840 ‫And so this process is therefore completely stateless. 54 00:02:44,840 --> 00:02:49,300 ‫Then, each time a user wants to access a protected route, 55 00:02:49,300 --> 00:02:51,940 ‫like his user profile data, for example, 56 00:02:51,940 --> 00:02:55,360 ‫he sends his Json Web Token along with a request. 57 00:02:55,360 --> 00:02:58,480 ‫So it's a bit like showing his passport to get access 58 00:02:58,480 --> 00:03:00,450 ‫to that route, right? 59 00:03:00,450 --> 00:03:03,870 ‫And that's probably the best and easiest way to understand 60 00:03:03,870 --> 00:03:05,320 ‫this whole idea. 61 00:03:05,320 --> 00:03:07,910 ‫Now once the request hits the server, 62 00:03:07,910 --> 00:03:11,140 ‫our app will then verify if the Json Web Token 63 00:03:11,140 --> 00:03:12,580 ‫is actually valid. 64 00:03:12,580 --> 00:03:15,760 ‫So if the user is really who he says he is. 65 00:03:15,760 --> 00:03:17,710 ‫And more about how this step works 66 00:03:17,710 --> 00:03:19,660 ‫a bit later in this video. 67 00:03:19,660 --> 00:03:22,710 ‫Now if the token is actually valid, well, 68 00:03:22,710 --> 00:03:26,210 ‫then the requested data will be sent to the client 69 00:03:26,210 --> 00:03:29,400 ‫and if not, then there will be an error telling the user 70 00:03:29,400 --> 00:03:32,600 ‫that he's not allowed to access that resource. 71 00:03:32,600 --> 00:03:34,880 ‫And as long as the user is logged in, 72 00:03:34,880 --> 00:03:38,230 ‫this is how it's gonna work each time that he requests data 73 00:03:38,230 --> 00:03:39,843 ‫from any protected route. 74 00:03:40,840 --> 00:03:43,000 ‫Now what's very important to note here 75 00:03:43,000 --> 00:03:47,570 ‫is that all this communication must happen over https. 76 00:03:47,570 --> 00:03:51,510 ‫So secure encrypted http in order to prevent 77 00:03:51,510 --> 00:03:55,840 ‫that anyone can get access to passwords or Json Web Tokens. 78 00:03:55,840 --> 00:03:59,090 ‫Only then we have a really secure system. 79 00:03:59,090 --> 00:04:02,430 ‫But we will talk about that later in the section, okay. 80 00:04:02,430 --> 00:04:05,120 ‫So I know that this can look quite confusing 81 00:04:05,120 --> 00:04:06,900 ‫in the beginning when you first try 82 00:04:06,900 --> 00:04:09,120 ‫to wrap your head around it, but actually 83 00:04:09,120 --> 00:04:13,490 ‫the principle itself is actually quite simple, all right? 84 00:04:13,490 --> 00:04:15,830 ‫And this is really all you need to know in order 85 00:04:15,830 --> 00:04:20,370 ‫to be able to implement authentication using JWT. 86 00:04:20,370 --> 00:04:22,740 ‫But let's now dive a little bit deeper into how 87 00:04:22,740 --> 00:04:25,880 ‫the JWT itself actually works. 88 00:04:25,880 --> 00:04:30,310 ‫So a Json Web Token looks like left part of this screenshot 89 00:04:30,310 --> 00:04:35,310 ‫which was taken from the JWT debugger at jwt.io. 90 00:04:35,940 --> 00:04:38,650 ‫So essentially, it's an encoding string 91 00:04:38,650 --> 00:04:40,430 ‫made up of three parts. 92 00:04:40,430 --> 00:04:44,140 ‫The header, the payload and the signature. 93 00:04:44,140 --> 00:04:47,910 ‫Now the header is just some metadata about the token itself 94 00:04:47,910 --> 00:04:50,910 ‫and the payload is the data that we can encode 95 00:04:50,910 --> 00:04:54,470 ‫into the token, any data really that we want. 96 00:04:54,470 --> 00:04:56,690 ‫So the more data we want to encode here, 97 00:04:56,690 --> 00:04:58,890 ‫the bigger the JWT. 98 00:04:58,890 --> 00:05:01,750 ‫Anyway, these two parts are just plain text 99 00:05:01,750 --> 00:05:04,860 ‫that will get encoded, but not encrypted. 100 00:05:04,860 --> 00:05:08,790 ‫So anyone will be able to decode them and to read them. 101 00:05:08,790 --> 00:05:11,730 ‫So we cannot store any sensitive data in here. 102 00:05:11,730 --> 00:05:13,460 ‫But that's not a problem at all 103 00:05:13,460 --> 00:05:16,580 ‫because in the third part, so in the signature, 104 00:05:16,580 --> 00:05:19,370 ‫is where things really get interesting. 105 00:05:19,370 --> 00:05:22,990 ‫The signature is created using the header, the payload 106 00:05:22,990 --> 00:05:26,020 ‫and the secret that is saved on the server. 107 00:05:26,020 --> 00:05:27,080 ‫Remember that? 108 00:05:27,080 --> 00:05:28,760 ‫And this whole process is then called 109 00:05:28,760 --> 00:05:30,883 ‫signing the Json Web Token. 110 00:05:31,900 --> 00:05:35,590 ‫So again, the signing algorithm takes the header, 111 00:05:35,590 --> 00:05:40,590 ‫the payload and the secret to create a unique signature. 112 00:05:40,650 --> 00:05:43,200 ‫So only this data plus the secret 113 00:05:43,200 --> 00:05:46,160 ‫can create this signature, all right? 114 00:05:46,160 --> 00:05:49,200 ‫Then together with the header and the payload, 115 00:05:49,200 --> 00:05:52,310 ‫these signature forms the JWT, 116 00:05:52,310 --> 00:05:55,190 ‫which then gets sent to the client. 117 00:05:55,190 --> 00:05:58,320 ‫Now as I mentioned briefly, right in the first slide, 118 00:05:58,320 --> 00:06:02,000 ‫once the server receives a JWT to grant access 119 00:06:02,000 --> 00:06:05,010 ‫to a protected route, it needs to verify it 120 00:06:05,010 --> 00:06:07,730 ‫in order to determine if the user really is 121 00:06:07,730 --> 00:06:10,120 ‫who he claims to be, right? 122 00:06:10,120 --> 00:06:13,890 ‫In other words, it will verify if no one changed the header 123 00:06:13,890 --> 00:06:16,580 ‫and the payload data of the token. 124 00:06:16,580 --> 00:06:20,030 ‫So again, this verification step will check 125 00:06:20,030 --> 00:06:23,350 ‫if no third party actually altered either the header 126 00:06:23,350 --> 00:06:26,280 ‫or the payload of the Json Web Token. 127 00:06:26,280 --> 00:06:29,650 ‫So, how does this verification actually work? 128 00:06:29,650 --> 00:06:32,560 ‫Well it is actually quite straightforward. 129 00:06:32,560 --> 00:06:35,410 ‫So once the JWT is received, 130 00:06:35,410 --> 00:06:38,920 ‫the verification will take it's header and payload 131 00:06:38,920 --> 00:06:41,540 ‫and together with the secret that is still saved 132 00:06:41,540 --> 00:06:45,440 ‫on the server, basically create a test signature. 133 00:06:45,440 --> 00:06:48,390 ‫But the original signature that was generated 134 00:06:48,390 --> 00:06:53,390 ‫when the JWT was first created is still in the token, right? 135 00:06:53,930 --> 00:06:56,550 ‫And that's the key for this verification. 136 00:06:56,550 --> 00:06:59,180 ‫Because now all we have to do is to compare 137 00:06:59,180 --> 00:07:02,590 ‫the test signature with the original signature. 138 00:07:02,590 --> 00:07:05,050 ‫And if the test signature is the same 139 00:07:05,050 --> 00:07:08,460 ‫as the original signature, then it means that the payload 140 00:07:08,460 --> 00:07:11,760 ‫and the header have not been modified, right? 141 00:07:11,760 --> 00:07:13,690 ‫Because if they had been modified, 142 00:07:13,690 --> 00:07:16,720 ‫then the test signature would have to be different. 143 00:07:16,720 --> 00:07:19,600 ‫Therefore in this case where there has been no alteration 144 00:07:19,600 --> 00:07:22,990 ‫of the data, we can then authenticate the user. 145 00:07:22,990 --> 00:07:24,940 ‫And of course, if the two signatures 146 00:07:24,940 --> 00:07:27,520 ‫are actually different, well, then it means 147 00:07:27,520 --> 00:07:29,870 ‫that someone tampered with the data. 148 00:07:29,870 --> 00:07:32,780 ‫Usually by trying to change the payload. 149 00:07:32,780 --> 00:07:35,470 ‫But that third party manipulating the payload 150 00:07:35,470 --> 00:07:38,750 ‫does of course not have access to the secret, 151 00:07:38,750 --> 00:07:41,370 ‫so they cannot sign the JWT. 152 00:07:41,370 --> 00:07:44,320 ‫So the original signature will never correspond 153 00:07:44,320 --> 00:07:46,050 ‫to the manipulated data. 154 00:07:46,050 --> 00:07:49,160 ‫And therefore, the verification will always fail 155 00:07:49,160 --> 00:07:50,700 ‫in this case. 156 00:07:50,700 --> 00:07:53,850 ‫And that's the key to making this whole system work. 157 00:07:53,850 --> 00:07:57,190 ‫It's the magic that makes JWT so simple, 158 00:07:57,190 --> 00:07:59,790 ‫but also extremely powerful. 159 00:07:59,790 --> 00:08:01,560 ‫So let me summarize it again. 160 00:08:01,560 --> 00:08:04,830 ‫Without the secret, no one will be able to manipulate 161 00:08:04,830 --> 00:08:07,920 ‫the JWT data because they cannot create 162 00:08:07,920 --> 00:08:10,960 ‫a valid signature for the new data. 163 00:08:10,960 --> 00:08:13,570 ‫I mean they could manipulate the data of course, 164 00:08:13,570 --> 00:08:16,870 ‫but it will always fail the verification step. 165 00:08:16,870 --> 00:08:19,900 ‫Now, don't worry, we're not gonna actually implement 166 00:08:19,900 --> 00:08:22,660 ‫these JWT algorithms by ourself. 167 00:08:22,660 --> 00:08:24,830 ‫They are very complex and we're not gonna 168 00:08:24,830 --> 00:08:27,060 ‫reinvent the wheel here, all right? 169 00:08:27,060 --> 00:08:29,910 ‫But it's still very important to actually understand 170 00:08:29,910 --> 00:08:32,110 ‫how this whole process works behind the scene. 171 00:08:32,110 --> 00:08:35,570 ‫And I hope that this lecture did just that for you. 172 00:08:35,570 --> 00:08:38,370 ‫But now, let's move on to the next lecture 173 00:08:38,370 --> 00:08:40,433 ‫to actually start using all this.