WEBVTT 0:00:03.480000 --> 0:00:06.100000 Hello everyone and welcome. 0:00:06.100000 --> 0:00:10.440000 In this video or in this section we're going to be exploring JSON web 0:00:10.440000 --> 0:00:19.960000 tokens in quite a bit of detail, given the importance of JWTs and authentication, 0:00:19.960000 --> 0:00:22.020000 as well as session management to an extent. 0:00:22.020000 --> 0:00:31.100000 Obviously their importance or use case will be in terms of explaining 0:00:31.100000 --> 0:00:36.380000 JWT specifically and that's what this video is going to be focused on. 0:00:36.380000 --> 0:00:41.460000 So to kick things off, I know I've already explained what JWTs are but 0:00:41.460000 --> 0:00:44.340000 there's a lot more to understand about them. 0:00:44.340000 --> 0:00:49.480000 Before we get into the nitty gritty we need to understand what they are. 0:00:49.480000 --> 0:00:57.500000 So JSON web tokens abbreviated as JWT or Plural JWTs are a compact URL 0:00:57.500000 --> 0:01:02.160000 safe and self-contained method for securely transmitting information between 0:01:02.160000 --> 0:01:06.980000 parties. Now JWTs are commonly used for authentication, authorization 0:01:06.980000 --> 0:01:13.840000 and information exchange in modern web applications and a JWT or a JSON 0:01:13.840000 --> 0:01:18.640000 web token typically consists, well they need to consist of three parts 0:01:18.640000 --> 0:01:21.140000 or three sections, right? 0:01:21.140000 --> 0:01:26.880000 So just think of a session ID and the way to understand it is you have 0:01:26.880000 --> 0:01:32.520000 three session IDs that are conjoined together or separated by a full stop, 0:01:32.520000 --> 0:01:38.420000 right? So those three parts are essentially the header payload and signature. 0:01:38.420000 --> 0:01:43.720000 So the header, this contains metadata about the token, for example the 0:01:43.720000 --> 0:01:50.780000 signing algorithm, the token type, the payload, the second part, essentially 0:01:50.780000 --> 0:01:54.860000 contains claims which we'll get into claims or statements about the user 0:01:54.860000 --> 0:02:00.020000 session. So this could be the use ID, the roles and the expiration, right? 0:02:00.020000 --> 0:02:01.620000 This is very important. 0:02:01.620000 --> 0:02:05.600000 And then finally you have the signature or the third part appended. 0:02:05.600000 --> 0:02:07.400000 This is the end. 0:02:07.400000 --> 0:02:12.160000 This essentially ensures the tokens integrity by cryptographically signing 0:02:12.160000 --> 0:02:13.660000 the header and the payload. 0:02:13.660000 --> 0:02:18.560000 Now that seems confusing as it is already but it'll make sense by the 0:02:18.560000 --> 0:02:21.020000 end of this video I can guarantee you that. 0:02:21.020000 --> 0:02:25.020000 So before we even get into that why were they created? 0:02:25.020000 --> 0:02:30.740000 Because it's sort of looks like a very nuanced type of token. 0:02:30.740000 --> 0:02:35.740000 Well JWTs were created to address the need for a lightweight stateless, 0:02:35.740000 --> 0:02:39.680000 and that's the keyword there, and scalable method for managing authentication 0:02:39.680000 --> 0:02:44.200000 and session data in modern distributed systems. 0:02:44.200000 --> 0:02:47.740000 Traditional session based authentication methods often require server 0:02:47.740000 --> 0:02:52.520000 side storage and to manage session states which can be resource intensive 0:02:52.520000 --> 0:02:54.160000 and less scalable. 0:02:54.160000 --> 0:02:57.680000 We touched on this in the previous video with regards to why token based 0:02:57.680000 --> 0:02:59.400000 authentication was created. 0:02:59.400000 --> 0:03:09.940000 Then you'll typically see that there wasn't need to move away from having 0:03:09.940000 --> 0:03:15.060000 session information stored server side and more importantly sort of having 0:03:15.060000 --> 0:03:20.280000 a token that can scale or you know an authentication mechanism that can 0:03:20.280000 --> 0:03:25.920000 scale. So JWTs eliminate this need by embedding session related data directly 0:03:25.920000 --> 0:03:29.440000 into the token itself which will get into. 0:03:29.440000 --> 0:03:33.580000 So this is an example of what a JWT token looks like which has been base 0:03:33.580000 --> 0:03:38.920000 64 encoded. Now if you remember what I just said a few seconds ago we 0:03:38.920000 --> 0:03:43.020000 have the first which is the header and they're separated with a full stop 0:03:43.020000 --> 0:03:46.620000 then the second part which is arguably going to be the longest is the 0:03:46.620000 --> 0:03:51.260000 payload obviously based on what it stores and then the signature is appended 0:03:51.260000 --> 0:03:53.860000 at the end so they're all separated by a full stop. 0:03:53.860000 --> 0:03:58.220000 In total you'll have three sections or three tokens if you will that are 0:03:58.220000 --> 0:04:03.000000 conjoined together and as a whole they give you this right over here when 0:04:03.000000 --> 0:04:09.600000 decoded. So you have the header and then of course the payload the signature 0:04:09.600000 --> 0:04:17.480000 as I mentioned right over here essentially you know is sort of the an 0:04:17.480000 --> 0:04:24.920000 encoded or you know cryptographically signed version or yeah I would say 0:04:24.920000 --> 0:04:35.980000 cryptographically signed string as a result of you know encoding or encrypting 0:04:35.980000 --> 0:04:39.280000 but you know the bottom line is that at first glance this looks quite 0:04:39.280000 --> 0:04:43.300000 convoluted and you might be asking as well why did we move away from session 0:04:43.300000 --> 0:04:49.600000 IDs which were you know you could consider just this small string right 0:04:49.600000 --> 0:04:55.920000 over here or head if you will in this case but it's well this looks convoluted 0:04:55.920000 --> 0:05:00.180000 it's actually a very compact printable representation of a series of claims 0:05:00.180000 --> 0:05:10.920000 along with you have the algorithm which is HS256 the type is JWT the payload 0:05:10.920000 --> 0:05:15.320000 contains the subject will don't worry we'll get into what each of these 0:05:15.320000 --> 0:05:19.260000 claims means because you the payload is arguably the most important along 0:05:19.260000 --> 0:05:23.080000 with the header in fact it's all important but don't worry it'll make 0:05:23.080000 --> 0:05:27.480000 sense so you know subject name and then admin is set to true this is generally 0:05:27.480000 --> 0:05:32.640000 what you know you would consider session related data so hopefully starting 0:05:32.640000 --> 0:05:36.620000 to make sense now that brings us to the you know elephant in the room 0:05:36.620000 --> 0:05:41.720000 and that is you know what is the role or what are the role of JWTs and 0:05:41.720000 --> 0:05:45.160000 authentication and session management well let's start off with authentication 0:05:45.160000 --> 0:05:50.460000 so in the case of authentication JWTs are widely used for authenticating 0:05:50.460000 --> 0:05:55.720000 users in web applications and upon successful login the first thing that 0:05:55.720000 --> 0:05:59.840000 happens is that the server generates a JWT containing the user specific 0:05:59.840000 --> 0:06:04.420000 claims when I say claims for now just for these slides just think of it 0:06:04.420000 --> 0:06:10.180000 as your session you know the information regarding your session then the 0:06:10.180000 --> 0:06:14.620000 token is signed with a secret or private key and we'll get into that and 0:06:14.620000 --> 0:06:20.220000 this is done to prevent tampering the JWT is sent to the client and stored 0:06:20.220000 --> 0:06:25.160000 for example a cookie or local storage and again I mentioned this in the 0:06:25.160000 --> 0:06:29.420000 previous in the previous video we were you know getting into token based 0:06:29.420000 --> 0:06:34.240000 authentication and then this is the key here for subsequent requests the 0:06:34.240000 --> 0:06:39.480000 client includes the client so just think of this as your browser the client 0:06:39.480000 --> 0:06:44.620000 includes the JWT in the authorization header or in a cookie as we saw 0:06:44.620000 --> 0:06:48.220000 in the previous video and then obviously just like you would if you add 0:06:48.220000 --> 0:06:53.340000 a session ID or you know cookie the server validates the token to authenticate 0:06:53.340000 --> 0:06:58.600000 the user in your session data is contained there in already so this is 0:06:58.600000 --> 0:07:02.480000 an example of a GET request being made to a protected resource the host 0:07:02.480000 --> 0:07:07.100000 is just acme.com and then in this case we're using the you know bearer 0:07:07.100000 --> 0:07:11.080000 token as an example so the authorization header and then the bearer token 0:07:11.080000 --> 0:07:15.800000 right over here is not enough space for me to include you know to include 0:07:15.800000 --> 0:07:20.920000 the actual token in its entirety but you get the idea and then we move 0:07:20.920000 --> 0:07:24.280000 on to session management which i'm guessing a lot of you are pretty curious 0:07:24.280000 --> 0:07:29.480000 about right so JWT enables stateless session management meaning the server 0:07:29.480000 --> 0:07:33.980000 does not need to store session data all necessary information for example 0:07:33.980000 --> 0:07:40.520000 user roles or expiration etc is embedded within the token itself and what 0:07:40.520000 --> 0:07:45.380000 are the benefits that JWTs provide for session management well firstly 0:07:45.380000 --> 0:07:48.880000 scalability so it eliminates the need for server side session storage 0:07:48.880000 --> 0:07:54.120000 reducing resource usage you then have crossed domain authentication so 0:07:54.120000 --> 0:08:00.100000 you know this works really well in distributed systems and APIs and obviously 0:08:00.100000 --> 0:08:05.080000 it's decentralized you know session information is not stored on the server 0:08:05.080000 --> 0:08:08.840000 side or in a central location so you know it allows third party services 0:08:08.840000 --> 0:08:14.740000 to validate tokens without contacting the issuer all right so now that 0:08:14.740000 --> 0:08:19.160000 we've sort of got a history or a background as to what JWTs are what they 0:08:19.160000 --> 0:08:25.960000 look like as well as why they were created and the role they play in authentication 0:08:25.960000 --> 0:08:29.700000 and session management we need to take a deeper dive into the structure 0:08:29.700000 --> 0:08:34.740000 that i highlighted in the you know the earlier slides you know and understand 0:08:34.740000 --> 0:08:38.960000 the header payload and signature and what exactly they contain how they're 0:08:38.960000 --> 0:08:45.700000 created and what the entire process looks like end-to-end right so first 0:08:45.700000 --> 0:08:50.360000 things first the header always comes first right so the you know every 0:08:50.360000 --> 0:08:55.780000 JWT can follow a syntax or a format where we have the header the payload 0:08:55.780000 --> 0:08:59.860000 and then the signature so you know the first part and again they're separated 0:08:59.860000 --> 0:09:03.720000 with a full stop i have to remind you because it's quite important now 0:09:03.720000 --> 0:09:07.840000 this order is crucial because the signature this is very important the 0:09:07.840000 --> 0:09:11.800000 signature is generated by hashing the header and the payload together 0:09:11.800000 --> 0:09:15.580000 which is what i was trying to explain earlier but i couldn't sort of articulate 0:09:15.580000 --> 0:09:20.340000 it as well as i did in this slide and the bottom line is that reversing 0:09:20.340000 --> 0:09:25.980000 or altering this order would invalidate the token obviously so the end 0:09:25.980000 --> 0:09:31.320000 the final part the third part of the JSON web token as a whole is the 0:09:31.320000 --> 0:09:36.220000 signature and the signature is only created or generated by hashing the 0:09:36.220000 --> 0:09:43.580000 head and payload together so that's the you know that i just wanted to 0:09:43.580000 --> 0:09:46.980000 get that out of the way before we continue now i've sort of made it easier 0:09:46.980000 --> 0:09:52.840000 to understand in this particular slide and you know the key thing that 0:09:52.840000 --> 0:09:57.560000 i wanted to highlight is you know the separation by dot so the format 0:09:57.560000 --> 0:10:02.800000 is header payload signature i've used a legitimate JSON web token here 0:10:02.800000 --> 0:10:08.860000 that i created and i've sort of colorized the three different parts if 0:10:08.860000 --> 0:10:14.420000 you will and sort of highlighted what they are again color coded so you 0:10:14.420000 --> 0:10:18.120000 have the header here the payload in green and the signature at the end 0:10:18.120000 --> 0:10:22.560000 and you can see they're separated by dots or full stops if you will so 0:10:22.560000 --> 0:10:27.080000 hopefully that makes sense now let's get started with the jwt header all 0:10:27.080000 --> 0:10:31.000000 right or the first part so the header contains metadata about the token 0:10:31.000000 --> 0:10:37.440000 such as the signing algorithm and examples of these are hs 256 rs 256 0:10:37.440000 --> 0:10:42.320000 and the token type in this case it's going to be jwt or in most cases 0:10:42.320000 --> 0:10:48.320000 i should say so what this means is that if you were to decode a JSON web 0:10:48.320000 --> 0:10:53.120000 token if you had the secret key this is what the first part would look 0:10:53.120000 --> 0:10:57.500000 like the header and then we have the payload which is arguably the most 0:10:57.500000 --> 0:11:02.480000 important part is the second part of the jwt token so the payload is as 0:11:02.480000 --> 0:11:07.000000 i said the second part of the jwt and contains claims that provide information 0:11:07.000000 --> 0:11:13.800000 about the user or session claims can be registered the iss exp it don 0:11:13.800000 --> 0:11:19.000000 worry we'll get into what each of these means you know public or you know 0:11:19.000000 --> 0:11:23.260000 application specific or private agreed upon this section includes information 0:11:23.260000 --> 0:11:29.960000 like user roles permissions and token metadata and the payload is base 0:11:29.960000 --> 0:11:35.140000 64 encoded not encrypted which means it is generally speaking readable 0:11:35.140000 --> 0:11:41.100000 if decoded and then we have the jwt signature which probably might have 0:11:41.100000 --> 0:11:44.980000 confused a lot of you so the signature is the final part of the jwt and 0:11:44.980000 --> 0:11:49.980000 ensures token integrity and authenticity it is created by signing the 0:11:49.980000 --> 0:11:56.340000 encoded header payload and a secret key for symmetric algorithms or a 0:11:56.340000 --> 0:12:02.020000 private key this is very important for you know asymmetric algorithms 0:12:02.020000 --> 0:12:06.380000 so the signature ensures that the token has not been tampered with so 0:12:06.380000 --> 0:12:10.700000 in this case i've just given you an example of a formula that's used to 0:12:10.700000 --> 0:12:17.340000 generate the signature based on you know the based on an existing header 0:12:17.340000 --> 0:12:23.560000 and payload so you have in this case it's hs 256 so you can see right 0:12:23.560000 --> 0:12:27.400000 over here there's a function where base 64 URL encode the header plus 0:12:27.400000 --> 0:12:33.360000 you append you know the dot or the full stop and then concatenate base 0:12:33.360000 --> 0:12:39.980000 64 URL encode the payload and then the secret over here so that's how 0:12:39.980000 --> 0:12:43.520000 that works now you know i mentioned claims when we're talking about the 0:12:43.520000 --> 0:12:48.180000 jwt payload but we need to dive into these because it's very important 0:12:48.180000 --> 0:12:51.820000 that you understand exactly what you're looking at when you're analyzing 0:12:51.820000 --> 0:12:57.200000 the the payload of a jwt so what are claims that's a you know interesting 0:12:57.200000 --> 0:13:02.660000 word well claims in jwts are key value pairs so just the parameter value 0:13:02.660000 --> 0:13:08.120000 you know in web on the web but you know key value pairs in the payload 0:13:08.120000 --> 0:13:12.420000 section of the token these claims carry information about the user session 0:13:12.420000 --> 0:13:17.260000 or other relevant data and are used by the application or service to process 0:13:17.260000 --> 0:13:23.520000 the token okay jwt claims are not encrypted by default unless the jwts 0:13:23.520000 --> 0:13:28.980000 encrypted using jwt which will not get into at least in this video and 0:13:28.980000 --> 0:13:34.900000 therefore you know claims are base 64 encoded but easily readable so the 0:13:34.900000 --> 0:13:39.400000 bottom line is that they should not contain or include sensitive information 0:13:39.400000 --> 0:13:43.580000 like passwords and hopefully that's giving you an idea as to where the 0:13:43.580000 --> 0:13:47.240000 vulnerabilities come into play or where the misconfigurations come into 0:13:47.240000 --> 0:13:52.800000 play because sometimes sometimes jwts are not implemented correctly and 0:13:52.800000 --> 0:13:59.160000 they could contain some juicy information in the payload so claims enable 0:13:59.160000 --> 0:14:03.920000 jwts to a provide context so include information about the user session 0:14:03.920000 --> 0:14:07.820000 i'm drilling that in so that it sticks in your mind authorize actions 0:14:07.820000 --> 0:14:13.820000 which is that the next step um very specific to claims uh you know in 0:14:13.820000 --> 0:14:17.680000 this case you're uh you know in terms of authorizing actions you're defining 0:14:17.680000 --> 0:14:22.640000 user roles and permissions for resource access and then see support application 0:14:22.640000 --> 0:14:26.900000 logic so you know share data between services in a distributed system 0:14:26.900000 --> 0:14:32.760000 so let's get started with the first type of claims um which are registered 0:14:32.760000 --> 0:14:37.560000 claims so these are predefined optional claims that provide a standardized 0:14:37.560000 --> 0:14:42.520000 way of describing common information examples include and remember claims 0:14:42.520000 --> 0:14:46.200000 are found in the payload it's very important that you you actually can 0:14:46.200000 --> 0:14:51.160000 you understand where we are right now so um you we have the issue all 0:14:51.160000 --> 0:14:55.420000 right or ISS whenever you see that yeah that just identifies who issued 0:14:55.420000 --> 0:14:59.960000 the token so example would be a server or authentication service so whenever 0:14:59.960000 --> 0:15:05.240000 you see ISS in the payload just know it's referring to who issued it or 0:15:05.240000 --> 0:15:09.900000 who issued that token then you may find the subject or sub this identifies 0:15:09.900000 --> 0:15:15.600000 the subject of the token often a user ID all right often it's not always 0:15:15.600000 --> 0:15:19.720000 the case but you may find it you then have a ud which is not that common 0:15:19.720000 --> 0:15:24.960000 anymore or it's not really used that much uh a ud is the audience so this 0:15:24.960000 --> 0:15:29.220000 indicates the intended recipients of the token for example a specific 0:15:29.220000 --> 0:15:34.420000 api you then have exp which is expiration time i don't need to elaborate 0:15:34.420000 --> 0:15:42.680000 on it but i will so this because it may look confusing when you see it 0:15:42.680000 --> 0:15:47.500000 in that format is that it's using Unix timestamp format so you just see 0:15:47.500000 --> 0:15:50.720000 you know just a random set of numbers they're not random they they're 0:15:50.720000 --> 0:15:55.140000 in Unix timestamp format um and then you have it which is you know issued 0:15:55.140000 --> 0:16:00.100000 at this indicates when the token was created again in Unix timestamp format 0:16:00.100000 --> 0:16:05.520000 and then nbf which is not before uh this specifies when the token becomes 0:16:05.520000 --> 0:16:09.100000 valid that can be very useful uh you know if you want to sort of control 0:16:09.100000 --> 0:16:13.540000 when the token becomes valid and when it expires uh just more granular 0:16:13.540000 --> 0:16:18.100000 control there this is an example of the registered claims and what they 0:16:18.100000 --> 0:16:22.180000 would look like in the payload of the in the payload section or part of 0:16:22.180000 --> 0:16:30.520000 the of hwt so uh issuer subject audience expiry um and over here if we 0:16:30.520000 --> 0:16:35.040000 go back it should act uh just wanted to make sure and you can see this 0:16:35.040000 --> 0:16:40.080000 is the Unix timestamp format uh subject use id typically issuer can just 0:16:40.080000 --> 0:16:44.640000 be you know the website or the web application that issued it um so yeah 0:16:44.640000 --> 0:16:48.680000 that's what registered claims look like we then have public claims right 0:16:48.680000 --> 0:16:55.420000 now uh these are custom claims defined by the application developer so 0:16:55.420000 --> 0:17:02.220000 uh the key thing to note is that with the registered claims these ones 0:17:02.220000 --> 0:17:06.900000 uh you know you you cannot create a public claim of your own that has 0:17:06.900000 --> 0:17:10.580000 the same name as any of these that's the easiest way to say it which is 0:17:10.580000 --> 0:17:15.140000 what i was alluding to here so you know these are custom public claims 0:17:15.140000 --> 0:17:19.520000 are custom claims defined by the application developer public claims must 0:17:19.520000 --> 0:17:23.780000 be unique to avoid collisions with other claim names they typically store 0:17:23.780000 --> 0:17:27.800000 user specific or application specific data which makes sense in the payload 0:17:27.800000 --> 0:17:33.580000 you may want to save or to store you know some other session related data 0:17:33.580000 --> 0:17:37.000000 that's you know that goes without saying and how do you do that well through 0:17:37.000000 --> 0:17:41.200000 public claims so an example of this or examples of these public claims 0:17:41.200000 --> 0:17:45.800000 would be a role so you know this would be very helpful uh very common 0:17:45.800000 --> 0:17:51.640000 very helpful in defining the user's role so admin user etc uh or privileges 0:17:51.640000 --> 0:17:55.500000 if you will and then email so you know stores the user's email permissions 0:17:55.500000 --> 0:17:59.720000 this lists the access rights for the user i've given you the best example 0:17:59.720000 --> 0:18:04.580000 of what you're likely to encounter in the domain or category of public 0:18:04.580000 --> 0:18:09.140000 claims again when talking about authentication you'll see the role uh 0:18:09.140000 --> 0:18:13.880000 so maybe admin or not admin uh the email the permissions what you're allowed 0:18:13.880000 --> 0:18:18.120000 to do um so you can see it's starting to make sense now and then you have 0:18:18.120000 --> 0:18:21.400000 private claims so private claims are custom claims that are agreed upon 0:18:21.400000 --> 0:18:26.300000 between parties exchanging jwts right they are not standardized and are 0:18:26.300000 --> 0:18:30.140000 typically used for application specific data examples of these would be 0:18:30.140000 --> 0:18:34.920000 you know department the specifies the user's department cart id for example 0:18:34.920000 --> 0:18:39.420000 in an e-commerce web app stores the shopping cart id uh this is what it 0:18:39.420000 --> 0:18:44.280000 would look like so hopefully that makes sense all right so that brings 0:18:44.280000 --> 0:18:49.520000 us to the end of the video and hopefully i know we've covered a lot these 0:18:49.520000 --> 0:18:53.200000 slides are you know been made available to you so definitely go through 0:18:53.200000 --> 0:18:57.160000 it more than once go through this video more than once because i've sort 0:18:57.160000 --> 0:19:01.260000 of encapsulated quite a bit and i'm actually kind of happy with how i've 0:19:01.260000 --> 0:19:04.420000 been able to compress you know at least everything i've learned as well 0:19:04.420000 --> 0:19:09.720000 as everything i you know i know or is publicly available about jwts um 0:19:09.720000 --> 0:19:13.380000 but now we're you know going to start exploring the vulnerabilities uh 0:19:13.380000 --> 0:19:16.600000 individually i didn't want to sort of give you a list of vulnerabilities 0:19:16.600000 --> 0:19:23.540000 um you know that affect jwts uh you know as a whole or in a sort of a 0:19:23.540000 --> 0:19:27.140000 collective series but to explore them individually so that's what we'll 0:19:27.140000 --> 0:19:31.020000 be exploring in the next set of videos uh with that being said that brings 0:19:31.020000 --> 0:19:34.640000 us to the end of this video and i will be seeing you in the next video