WEBVTT 0:00:03.680000 --> 0:00:09.180000 Hello everyone and welcome to the next section of this course where we 0:00:09.180000 --> 0:00:14.920000 will be taking a look at token based authentication, more specifically 0:00:14.920000 --> 0:00:19.200000 JWTs or JSON web tokens. 0:00:19.200000 --> 0:00:28.020000 Now, before we even delve into JWTs and all the security misconfigurations 0:00:28.020000 --> 0:00:33.640000 of vulnerabilities contained therein, we need to actually get an understanding 0:00:33.640000 --> 0:00:42.780000 as to what token based authentication is and how it differs from the forms 0:00:42.780000 --> 0:00:48.100000 or the types of authentication that we saw or that we explored earlier 0:00:48.100000 --> 0:00:49.400000 on in this course. 0:00:49.400000 --> 0:00:55.560000 Now, again, that may have answered one of your earlier questions as you 0:00:55.560000 --> 0:01:00.340000 went into this section and that question may have been, why are we covering 0:01:00.340000 --> 0:01:06.500000 token based authentication after session management and that will become 0:01:06.500000 --> 0:01:08.020000 apparent shortly. 0:01:08.020000 --> 0:01:12.760000 The bottom line is that token based authentication is sort of a modern 0:01:12.760000 --> 0:01:19.900000 form of authentication that as you probably guessed utilizes tokens. 0:01:19.900000 --> 0:01:24.520000 And so, you know, before we get into specific types of tokens and how 0:01:24.520000 --> 0:01:31.000000 they are used for authentication, namely JWTs, we need to understand token 0:01:31.000000 --> 0:01:32.660000 based authentication. 0:01:32.660000 --> 0:01:35.400000 So, let's not waste any time. 0:01:35.400000 --> 0:01:39.480000 All right, so what is token based authentication? 0:01:39.480000 --> 0:01:44.260000 Token based authentication is a modern method used to securely validate 0:01:44.260000 --> 0:01:50.660000 and authorize users or applications and that's very important in web environments 0:01:50.660000 --> 0:01:53.440000 or on the internet as it were. 0:01:53.440000 --> 0:01:58.560000 So, instead of maintaining the session state on the server, as we saw 0:01:58.560000 --> 0:02:03.140000 previously with session management testing, tokens are issued to clients 0:02:03.140000 --> 0:02:07.220000 and passed back and forth to authenticate requests. 0:02:07.220000 --> 0:02:13.280000 These tokens encapsulate user or application identity and relevant permissions 0:02:13.280000 --> 0:02:18.220000 enabling a seamless and scalable form of authentication. 0:02:18.220000 --> 0:02:22.900000 Now, as I said, that probably doesn't explain it all that well. 0:02:22.900000 --> 0:02:25.460000 However, it'll start to make sense as we proceed. 0:02:25.460000 --> 0:02:33.020000 Just the key takeaway from this slide is to think of tokens or token based 0:02:33.020000 --> 0:02:40.040000 authentication as sort of a much more secure where at least it's trying 0:02:40.040000 --> 0:02:46.280000 to be a much more secure alternative to the traditional session management. 0:02:46.280000 --> 0:02:52.060000 So, moving on a little bit, you may have asked the question already to 0:02:52.060000 --> 0:02:54.180000 yourself if you haven't already. 0:02:54.180000 --> 0:02:58.920000 What types of tokens do we have that fall under token based authentication? 0:02:58.920000 --> 0:03:03.280000 That is. Now, the most common one that I'm sure you've come across quite 0:03:03.280000 --> 0:03:08.900000 a bit because it's been there for a while, although not in different shapes 0:03:08.900000 --> 0:03:13.080000 and forms and that is, of course, bare tokens. 0:03:13.080000 --> 0:03:16.200000 So, what are bare tokens or what is a bare token? 0:03:16.200000 --> 0:03:20.900000 Well, this is a simple token format that grants access to resources when 0:03:20.900000 --> 0:03:24.160000 presented. How is it used? 0:03:24.160000 --> 0:03:26.480000 It's often used in APIs. 0:03:26.480000 --> 0:03:30.860000 So, the server assumes the bearer of the token has the authority to access 0:03:30.860000 --> 0:03:36.940000 the resource. So, this is sort of one use case and we'll actually talk 0:03:36.940000 --> 0:03:41.580000 about the use cases of token based authentication as we progress in this 0:03:41.580000 --> 0:03:45.700000 video. But this is typically what the request would look like. 0:03:45.700000 --> 0:03:49.760000 So, in this case, you know, we're making a GET request to a user profile. 0:03:49.760000 --> 0:03:53.520000 And instead of, you know, authenticating, you can start to see why this 0:03:53.520000 --> 0:03:55.280000 will be very useful for APIs. 0:03:55.280000 --> 0:03:59.400000 You just get a, you know, bearer token, which I'm sure if you have interacted 0:03:59.400000 --> 0:04:06.400000 with an API before, you probably know how that works. 0:04:06.400000 --> 0:04:11.840000 But authorization, and this is within the HTTP request, right? 0:04:11.840000 --> 0:04:15.280000 So, you can see authorization and then bearer, and then you have the token 0:04:15.280000 --> 0:04:20.900000 there. Now, the disadvantage with this is, again, this is akin to just 0:04:20.900000 --> 0:04:23.280000 having a password, right? 0:04:23.280000 --> 0:04:29.820000 And sort of going back to the locked door or, you know, secret room or 0:04:29.820000 --> 0:04:35.000000 important room analogy that I used in the beginning of this course, this 0:04:35.000000 --> 0:04:41.440000 is still just like using, you know, a single key to access a, you know, 0:04:41.440000 --> 0:04:46.280000 a secure, a secure room or secure door, if you will. 0:04:46.280000 --> 0:04:52.840000 But again, the key thing to keep in mind is, you know, this sort of works 0:04:52.840000 --> 0:04:59.100000 really well, for instances where, again, this works or this form of authentication 0:04:59.100000 --> 0:05:03.000000 would be, let's say, efficient, hence, you know, APIs. 0:05:03.000000 --> 0:05:15.780000 So, I want you to pay close what these specific types of tokens are used 0:05:15.780000 --> 0:05:19.700000 for. And then more importantly, the security consideration. 0:05:19.700000 --> 0:05:24.960000 So, starting off, you know, given what I've just said, it's fairly obvious 0:05:24.960000 --> 0:05:29.060000 that they need to be kept secret because, you know, they're easily exploitable 0:05:29.060000 --> 0:05:33.900000 if intercepted, or if someone gets your, your bearer token, it's pretty 0:05:33.900000 --> 0:05:37.240000 much game over, right? 0:05:37.240000 --> 0:05:40.100000 Um, some are another security consideration. 0:05:40.100000 --> 0:05:45.700000 You know, this is probably, I would say, an advantage, but it's sort of 0:05:45.700000 --> 0:05:49.400000 baked into the generation of bearer tokens, especially when you talk about 0:05:49.400000 --> 0:05:53.680000 APIs. And that is the fact that they're very short lived in that they 0:05:53.680000 --> 0:05:56.220000 have an expiry, which is, you know, good things. 0:05:56.220000 --> 0:06:01.340000 So security considerations, or that particular section just refers to, 0:06:01.340000 --> 0:06:04.580000 again, as it says, security considerations. 0:06:04.580000 --> 0:06:08.900000 So, you know, they must be kept a secret, obviously. 0:06:08.900000 --> 0:06:13.000000 No one else can get their hands on them, or should get their hands on 0:06:13.000000 --> 0:06:17.420000 them if they don't have the correct permissions or, you know, authority. 0:06:17.420000 --> 0:06:24.180000 But the advantage security wise is that, generally speaking, you know, 0:06:24.180000 --> 0:06:27.440000 they have an expiry or are short lived. 0:06:27.440000 --> 0:06:30.880000 And as a result, you know, you constantly need to keep renewing them. 0:06:30.880000 --> 0:06:34.660000 I'm sure a lot of you have interacted with APIs have been through this 0:06:34.660000 --> 0:06:40.900000 before. You then have the infamous JWTs or JSON Web Tokens, which we'll 0:06:40.900000 --> 0:06:44.940000 be exploring, you know, from the next video onwards, and we'll be diving 0:06:44.940000 --> 0:06:50.420000 deep into that. But what is a, you know, JSON Web Token really focusing 0:06:50.420000 --> 0:06:54.400000 on its categorization as a token in this case? 0:06:54.400000 --> 0:07:00.060000 Well, this is a self-contained token format that includes a header payload 0:07:00.060000 --> 0:07:03.980000 called, what you'd call claims. 0:07:03.980000 --> 0:07:05.320000 Don't worry, we'll get into that. 0:07:05.320000 --> 0:07:06.820000 And a signature. 0:07:06.820000 --> 0:07:11.720000 All right. Now, in terms of its usage, it's widely used in modern web 0:07:11.720000 --> 0:07:15.480000 applications for stateless authentication. 0:07:15.480000 --> 0:07:20.780000 Right. So remember authentication, session management, state, stateless, 0:07:20.780000 --> 0:07:24.160000 and why session IDs were created? 0:07:24.160000 --> 0:07:26.680000 Well, in this case, you're still not getting that. 0:07:26.680000 --> 0:07:31.300000 You know, if you read the description here, widely used in modern web 0:07:31.300000 --> 0:07:35.480000 applications for stateless authentication, so very important to keep in 0:07:35.480000 --> 0:07:40.200000 mind. The advantages are that, you know, obviously it's portable and stateless, 0:07:40.200000 --> 0:07:43.760000 allowing servers to offload session management. 0:07:43.760000 --> 0:07:46.620000 And this is what a JSON Web Token looks like. 0:07:46.620000 --> 0:07:48.500000 Now, don't worry if it looks complicated. 0:07:48.500000 --> 0:07:50.700000 It really is quite simple. 0:07:50.700000 --> 0:07:55.240000 We'll get into, you know, what each of these segments or each of these 0:07:55.240000 --> 0:07:59.400000 parts of the token as a whole mean and what they represent. 0:07:59.400000 --> 0:08:02.960000 You know, in the next video, when we actually get introduced to JSON Web 0:08:02.960000 --> 0:08:08.340000 Tokens formally, we then have OAuth tokens, right? 0:08:08.340000 --> 0:08:14.220000 Now, these are tokens used in the OAuth 2.0 protocol to authorize applications 0:08:14.220000 --> 0:08:16.980000 or users to access resources. 0:08:16.980000 --> 0:08:21.540000 Now, there's two types of tokens or two types of OAuth tokens. 0:08:21.540000 --> 0:08:25.860000 We have the access tokens, which as the name suggests, grants permissions 0:08:25.860000 --> 0:08:30.260000 to access resources and then refresh tokens. 0:08:30.260000 --> 0:08:36.800000 These ones are used to obtain new access tokens without reauthentication. 0:08:36.800000 --> 0:08:41.460000 So an example flow of how OAuth tokens work, you know, in relation to 0:08:41.460000 --> 0:08:47.420000 authentication is a user, a user authenticates with an OAuth provider. 0:08:47.420000 --> 0:08:53.300000 For example, Google, the access token is issued to the client application. 0:08:53.300000 --> 0:08:58.980000 And then the client uses the token to request resources from the server. 0:08:58.980000 --> 0:09:03.780000 So this is typically seen, you know, or it's a token typically used between 0:09:03.780000 --> 0:09:06.300000 web applications. 0:09:06.300000 --> 0:09:12.500000 So again, just think of the example here with Google where you can use 0:09:12.500000 --> 0:09:18.180000 your Gmail account, you know, to sign into other websites. 0:09:18.180000 --> 0:09:22.080000 That's, you know, not a very good example, but don't worry, we'll also 0:09:22.080000 --> 0:09:25.840000 touch on OAuth in another video in a different section. 0:09:25.840000 --> 0:09:29.180000 So we also have OAuth tokens and then moving on. 0:09:29.180000 --> 0:09:33.780000 I want to discuss the placement of tokens because this is arguably one 0:09:33.780000 --> 0:09:38.040000 of the things that will really, really separate you from, you know, just 0:09:38.040000 --> 0:09:43.540000 an average web app pentast and that is understanding not, you know, not 0:09:43.540000 --> 0:09:49.640000 just the different types of tokens, you know, which are their own, you 0:09:49.640000 --> 0:09:52.560000 know, they need to be studied individually. 0:09:52.560000 --> 0:09:55.920000 And we will do that, but also where they're placed. 0:09:55.920000 --> 0:10:01.140000 And when I say placed, I mean within, you know, standard HTTP request. 0:10:01.140000 --> 0:10:05.720000 So what does it actually look like when you have, you know, regardless 0:10:05.720000 --> 0:10:10.620000 of whether using a JSON web token, a barot token, etc. 0:10:10.620000 --> 0:10:15.820000 Where are they typically placed and, you know, where should they be placed? 0:10:15.820000 --> 0:10:18.280000 And, you know, there's no real answer to that question. 0:10:18.280000 --> 0:10:23.180000 You know, when we speak about it from a best practice perspective, you 0:10:23.180000 --> 0:10:25.820000 know, these examples will help you understand that. 0:10:25.820000 --> 0:10:31.960000 So the first, you know, which really applies to all is typically used 0:10:31.960000 --> 0:10:37.340000 by, by the bearer tokens is the authorization header, right? 0:10:37.340000 --> 0:10:39.200000 So it's an HTTP header. 0:10:39.200000 --> 0:10:44.260000 As we saw previously with, you know, authorization and then bearer and 0:10:44.260000 --> 0:10:48.980000 then the token. So in this case, this is the most common and secure method. 0:10:48.980000 --> 0:10:54.920000 Why? Well, it keeps tokens separate from the request body or the URL, 0:10:54.920000 --> 0:11:00.140000 which is, you know, that should never be done, you know, passing tokens, 0:11:00.140000 --> 0:11:06.060000 you know, in the actual URL as a parameter is not a good idea. 0:11:06.060000 --> 0:11:11.540000 And this all in turn reduces the, you know, the risks of exposure. 0:11:11.540000 --> 0:11:15.420000 The benefits of this are that it works seamlessly with APIs and browsers 0:11:15.420000 --> 0:11:17.480000 for obvious reasons. 0:11:17.480000 --> 0:11:21.940000 And it prevents token leakage through logs as the tokens aren't in the 0:11:21.940000 --> 0:11:29.180000 URL. So, you know, you'll come across this quite a lot. 0:11:29.180000 --> 0:11:34.360000 You then have the query parameters, which is now, I would say, really 0:11:34.360000 --> 0:11:42.000000 not the solution to implement in really any case, unless you really want 0:11:42.000000 --> 0:11:47.240000 to pass in your tokens, you know, as a parameter in the URL. 0:11:47.240000 --> 0:11:57.620000 So the usage is that tokens are appended as part of and then the token 0:11:57.620000 --> 0:12:02.500000 is passed as a value of the parameter axis token. 0:12:02.500000 --> 0:12:04.820000 And, you know, that's never a good idea. 0:12:04.820000 --> 0:12:09.400000 And I've highlighted the risks here, where firstly, the tokens might get 0:12:09.400000 --> 0:12:14.220000 exposed through browser history, logs or referral headers. 0:12:14.220000 --> 0:12:18.660000 And, you know, generally speaking, I think you probably know this already. 0:12:18.660000 --> 0:12:23.960000 You know, this opens up the possibility of, you know, the fact that it 0:12:23.960000 --> 0:12:31.360000 might be cached by proxies or servers, even your VPN, you know, probably, 0:12:31.360000 --> 0:12:35.340000 I should say it most likely is being logged. 0:12:35.340000 --> 0:12:39.200000 If you know, if you're if you are going through a proxy, and I mean, you 0:12:39.200000 --> 0:12:43.760000 know, proper proxy, not a web proxy like burp suite, although that even 0:12:43.760000 --> 0:12:44.800000 makes it easier. 0:12:44.800000 --> 0:12:46.580000 But we then have the request body. 0:12:46.580000 --> 0:12:50.380000 Now this is something quite common, I would say. 0:12:50.380000 --> 0:12:55.260000 In this case, you know, the request body is used, or you know, this particular 0:12:55.260000 --> 0:12:59.880000 placement is used primarily in post requests, not really get requests. 0:12:59.880000 --> 0:13:03.880000 So it's really when you're, you know, sending or submitting data. 0:13:03.880000 --> 0:13:07.800000 So again, here we have a post request being made to an API endpoint. 0:13:07.800000 --> 0:13:11.260000 The actual endpoint is called resource. 0:13:11.260000 --> 0:13:17.320000 And then you can see in this is, you know, JWT, well, with APIs, you know, 0:13:17.320000 --> 0:13:21.300000 as you would with in JSON format, you can see the content type, head, 0:13:21.300000 --> 0:13:23.260000 a application, JSON. 0:13:23.260000 --> 0:13:29.240000 You have the curly braces, token, just token here, you know, this will 0:13:29.240000 --> 0:13:32.280000 become familiar to you as we progress. 0:13:32.280000 --> 0:13:35.340000 But there's some important considerations here. 0:13:35.340000 --> 0:13:40.020000 Firstly, this is suitable for scenarios requiring data submission. 0:13:40.020000 --> 0:13:44.300000 And again, you may be asking, why am I showing you all of these examples? 0:13:44.300000 --> 0:13:49.580000 Well, you know, you can, once you start understanding where you're likely 0:13:49.580000 --> 0:13:56.440000 to define these tokens, you know, when you get good at that, or when you 0:13:56.440000 --> 0:14:01.160000 improve your intelligence and, you know, your methodology on that front, 0:14:01.160000 --> 0:14:03.800000 you just become much more effective. 0:14:03.800000 --> 0:14:05.840000 And you know what you're dealing with almost immediately. 0:14:05.840000 --> 0:14:10.400000 And you know when to, where to start testing for vulnerabilities. 0:14:10.400000 --> 0:14:17.100000 So another, another, another consideration here is you generally want 0:14:17.100000 --> 0:14:20.220000 to avoid using this method in get requests. 0:14:20.220000 --> 0:14:24.760000 Since get requests are generally not designed to carry sensitive data. 0:14:24.760000 --> 0:14:30.920000 So this is giving you an idea as to, you know, when these are used. 0:14:30.920000 --> 0:14:39.300000 And more importantly, if you see this being used, you know, to have you 0:14:39.300000 --> 0:14:45.340000 seen this particular method or this type of placement being used in, you 0:14:45.340000 --> 0:14:49.400000 know, for example, get requests, then you know, you start to understand, 0:14:49.400000 --> 0:14:53.440000 you know, that there probably is, you know, that probably isn't a good 0:14:53.440000 --> 0:14:58.940000 idea. And you then know when and how to narrow your attack or your testing, 0:14:58.940000 --> 0:15:01.400000 but getting out of myself. 0:15:01.400000 --> 0:15:04.300000 And then of course, you have the classic cookie. 0:15:04.300000 --> 0:15:08.500000 So the usage is that tokens are stored as cookies and automatically included 0:15:08.500000 --> 0:15:11.360000 in requests to the same domain. 0:15:11.360000 --> 0:15:16.140000 So you have the set cookie at a here auth token is equal to token, whatever 0:15:16.140000 --> 0:15:19.960000 that may be secure HTTP only. 0:15:19.960000 --> 0:15:25.420000 So some considerations here are, you know, the security features. 0:15:25.420000 --> 0:15:29.520000 So with HTTP only, as I've mentioned earlier on in this course, this prevents 0:15:29.520000 --> 0:15:32.920000 JavaScript access to the token. 0:15:32.920000 --> 0:15:38.500000 The secure attribute here ensures that the cookies only ever sent over 0:15:38.500000 --> 0:15:43.400000 HTTPS. Now, this is actually very, very strong. 0:15:43.400000 --> 0:15:47.260000 This is a very secure way of doing it in terms of placement and of course, 0:15:47.260000 --> 0:15:50.860000 transmission of the of the token. 0:15:50.860000 --> 0:15:55.600000 And the, you know, with that being said, there are some risks to be aware 0:15:55.600000 --> 0:16:03.420000 of. So what this obviously leads to, if not configured, if not configured 0:16:03.420000 --> 0:16:07.620000 correctly, or if not paired with the correct protections are vulnerabilities 0:16:07.620000 --> 0:16:13.460000 like cross site request forgery, the proper, the proper protections being 0:16:13.460000 --> 0:16:19.440000 the CSRF token. So, you know, whenever using cookies, you know, cookies 0:16:19.440000 --> 0:16:25.340000 have their own risks and you then pair it with the tokens, you know, you're 0:16:25.340000 --> 0:16:30.260000 getting some advantages, but you still need to remember or be, you still 0:16:30.260000 --> 0:16:33.540000 need to be cognizant of the issues with cookies to begin with. 0:16:33.540000 --> 0:16:38.260000 So there's never a silver bullet in terms of, you know, placement and, 0:16:38.260000 --> 0:16:47.640000 you know, transmission of the tokens, you know, the, the, the, the safe 0:16:47.640000 --> 0:16:51.420000 or secure of this information and requests. 0:16:51.420000 --> 0:16:56.420000 And, you know, this will start to make sense as we explore JWTs because, 0:16:56.420000 --> 0:17:01.900000 you know, they're, they're actually used quite a bit and you start to 0:17:01.900000 --> 0:17:07.620000 see, you know, through various lab examples or lab demonstrations, just 0:17:07.620000 --> 0:17:09.660000 how varied this can get. 0:17:09.660000 --> 0:17:12.800000 But he then have custom headers. 0:17:12.800000 --> 0:17:18.620000 This is not really that common, although you will see it, I would say 0:17:18.620000 --> 0:17:21.100000 about 20% of the time. 0:17:21.100000 --> 0:17:25.280000 So in this case, the usage is that, or the use case that some systems 0:17:25.280000 --> 0:17:28.840000 may define a custom header for token transmission. 0:17:28.840000 --> 0:17:33.480000 The most common that you'll see is X of X auth token. 0:17:33.480000 --> 0:17:39.360000 And in this case, some considerations are obviously this is less standardized. 0:17:39.360000 --> 0:17:44.580000 And, you know, it's very useful in systems with specific security needs 0:17:44.580000 --> 0:17:46.480000 or existing conventions. 0:17:46.480000 --> 0:17:49.860000 So, you know, really something that comes into play when you're building 0:17:49.860000 --> 0:17:54.640000 something custom or when an organization is building something quite bespoke 0:17:54.640000 --> 0:17:57.780000 and they wanted to work a certain way. 0:17:57.780000 --> 0:18:04.300000 So I've sort of summarized the best practices for placement and you might 0:18:04.300000 --> 0:18:08.900000 be thinking to yourself, well, I'm not really defending or, you know, 0:18:08.900000 --> 0:18:10.700000 developing secure web applications. 0:18:10.700000 --> 0:18:15.520000 I want to hack them, but it's very important that you understand, you 0:18:15.520000 --> 0:18:18.540000 know, the best practices that are typically followed. 0:18:18.540000 --> 0:18:24.420000 And this, again, will give you a better idea of where to test or I should 0:18:24.420000 --> 0:18:31.340000 say what to test for, you know, where to look for tokens. 0:18:31.340000 --> 0:18:35.500000 And yeah, so as I mentioned, use of the authorization header. 0:18:35.500000 --> 0:18:39.560000 This is preferred for most scenarios, especially RESTful APIs. 0:18:39.560000 --> 0:18:41.520000 So keep that in mind. 0:18:41.520000 --> 0:18:44.300000 This is a very important slide. 0:18:44.300000 --> 0:18:47.660000 Some of you will realize it right now. 0:18:47.660000 --> 0:18:51.960000 Some of you may be a few months from now or a year, but you'll come back 0:18:51.960000 --> 0:18:57.820000 to this slide. Another best practice or consideration is to avoid query 0:18:57.820000 --> 0:19:05.580000 parameters. So, you know, passing the token as the value of a parameter. 0:19:05.580000 --> 0:19:11.580000 In the URL, so they should only be used when absolutely necessary. 0:19:11.580000 --> 0:19:16.020000 And then secure tokens in cookies, something very important. 0:19:16.020000 --> 0:19:22.360000 So if cookies are being used for tokens, then they need to be configured 0:19:22.360000 --> 0:19:26.500000 with the HTTP only secure and same site attributes. 0:19:26.500000 --> 0:19:31.880000 If they don't have that, they could be something interesting there. 0:19:31.880000 --> 0:19:35.160000 And then of course, encryption and Crib data in transit. 0:19:35.160000 --> 0:19:40.140000 So always use HTTPS to protect tokens regardless of placement. 0:19:40.140000 --> 0:19:42.560000 And then of course, minimize token exposure. 0:19:42.560000 --> 0:19:46.440000 So avoid placing tokens in locations where they can easily be accessed, 0:19:46.440000 --> 0:19:48.520000 logged or cached. 0:19:48.520000 --> 0:19:55.540000 So, you know, as we proceed, there's a couple of use cases or examples 0:19:55.540000 --> 0:20:00.560000 that I want to use just to, you know, finalize this particular video. 0:20:00.560000 --> 0:20:06.740000 And hopefully this, you know, you came into this video, you know, maybe 0:20:06.740000 --> 0:20:09.900000 knowing a few things about token based authentication. 0:20:09.900000 --> 0:20:13.580000 But coming out, I really want you to understand what they're all about 0:20:13.580000 --> 0:20:19.760000 and sort of demystify the whole token based authentication category of 0:20:19.760000 --> 0:20:26.680000 authentication. So, in this particular case, let me just go over here 0:20:26.680000 --> 0:20:28.120000 and show you this. 0:20:28.120000 --> 0:20:38.880000 So these are the, these are some of the, I would say, use cases potentially, 0:20:38.880000 --> 0:20:40.680000 which I explained. 0:20:40.680000 --> 0:20:43.780000 Let me just take you to the first most slide here. 0:20:43.780000 --> 0:20:49.760000 So, you know, where are you likely to see tokens or what type of web applications 0:20:49.760000 --> 0:20:54.440000 are you likely to see tokens being used in? 0:20:54.440000 --> 0:20:58.000000 So firstly, modern web applications, that goes without saying otherwise, 0:20:58.000000 --> 0:21:00.920000 I wouldn't be, you know, recording this course. 0:21:00.920000 --> 0:21:04.980000 So token based authentication is lightweight, as we've been able to see, 0:21:04.980000 --> 0:21:10.320000 stateless and aligns well with the architecture of SPA's, progressive 0:21:10.320000 --> 0:21:13.420000 web apps, PWAs and other modern web applications. 0:21:13.420000 --> 0:21:18.480000 So it's very much, you know, part of the fore when you talk about modern 0:21:18.480000 --> 0:21:20.880000 day web applications. 0:21:20.880000 --> 0:21:27.420000 And as a result, you need to be, you know, very well versed in not only 0:21:27.420000 --> 0:21:36.540000 identifying tokens, but also, again, identifying when specific, you know, 0:21:36.540000 --> 0:21:41.520000 when, when tokens should be used, whether it's the, you know, it's the, 0:21:41.520000 --> 0:21:44.500000 it's the right decision to use token based authentication. 0:21:44.500000 --> 0:21:50.200000 Because again, if you don't understand the differences between, you know, 0:21:50.200000 --> 0:21:56.900000 what we had with, you know, the standard authentication or login form 0:21:56.900000 --> 0:22:02.100000 and then session management through session IDs, and, you know, how it 0:22:02.100000 --> 0:22:08.520000 differs from token based authentication, you really won't know what types 0:22:08.520000 --> 0:22:11.040000 of tests to run, where to look, etc. 0:22:11.040000 --> 0:22:15.420000 Anyway, I've been hopping long enough on, you know, on why understanding 0:22:15.420000 --> 0:22:16.860000 this is important. 0:22:16.860000 --> 0:22:21.400000 But the next obvious candidate is going to be restful APIs. 0:22:21.400000 --> 0:22:26.160000 So the reason for that is tokens can be passed easily in HTTP headers, 0:22:26.160000 --> 0:22:30.500000 making them suitable for APIs that need to authenticate multiple clients. 0:22:30.500000 --> 0:22:35.400000 For example, web, mobile, IoT, Internet of Things. 0:22:35.400000 --> 0:22:37.860000 And then we have microservices architectures. 0:22:37.860000 --> 0:22:41.780000 So tokens eliminate the need for centralized session storage. 0:22:41.780000 --> 0:22:45.500000 Very important to understand that, allowing each service to validate the 0:22:45.500000 --> 0:22:49.660000 token independently, enabling better scalability and reliability. 0:22:49.660000 --> 0:22:54.240000 And then we have the elephant in the room, which is cross domain authentication 0:22:54.240000 --> 0:22:55.860000 and single sign on. 0:22:55.860000 --> 0:23:03.960000 So tokens, examples of which are sharing of authentication information 0:23:03.960000 --> 0:23:08.380000 across different domains or systems, which is, you know, core requirement 0:23:08.380000 --> 0:23:11.060000 for SSO single sign on. 0:23:11.060000 --> 0:23:14.120000 But with that being said, that's going to be it for this video. 0:23:14.120000 --> 0:23:16.600000 And I will be seeing you in the next video.