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:48.940000
 You know, before we get into the nitty
 gritty we need to understand what

0:00:48.940000 --> 0:00:54.280000
 they are. So JSON web tokens, abbreviated
 as JWT or, you know, plural

0:00:54.280000 --> 0:01:00.900000
 JWTs, are a compact URL safe and self-contained
 method for securely transmitting

0:01:00.900000 --> 0:01:03.500000
 information between parties.

0:01:03.500000 --> 0:01:08.300000
 Now JWTs are commonly used for authentication,
 authorization and information

0:01:08.300000 --> 0:01:15.080000
 exchange in modern web applications and
 a JWT or a JSON web token typically

0:01:15.080000 --> 0:01:20.500000
 consists, well, they need to consist
 of three parts or three sections,

0:01:20.500000 --> 0:01:26.700000
 right? So just think of a session ID
 and the way to understand it is you

0:01:26.700000 --> 0:01:31.760000
 have three session IDs that are conjoined
 together or separated by a full

0:01:31.760000 --> 0:01:37.360000
 stop, right? So those three parts are
 essentially the header, payload

0:01:37.360000 --> 0:01:41.720000
 and signature. So the header, this is,
 you know, this contains metadata

0:01:41.720000 --> 0:01:46.420000
 about the token, for example, the signing
 algorithm, the token type, the

0:01:46.420000 --> 0:01:52.080000
 payload, the second part, you know,
 essentially contains claims which

0:01:52.080000 --> 0:01:56.040000
 we'll get into claims or statements
 about the user session.

0:01:56.040000 --> 0:02:00.060000
 So this could be the use ID, the
 roles and the expiration, right?

0:02:00.060000 --> 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.660000
 This is, you know, the end.

0:02:07.660000 --> 0:02:12.180000
 This essentially ensures the token's integrity
 by cryptographically signing

0:02:12.180000 --> 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:20.800000
 end of this video, I can
 guarantee you that.

0:02:20.800000 --> 0:02:25.020000
 So, you know, before we even get
 into that, why were they created?

0:02:25.020000 --> 0:02:29.980000
 Because it, you know, sort of looks
 like a very, very nuanced type of

0:02:29.980000 --> 0:02:34.560000
 token. Well, JWTs were created to address
 the need for a lightweight,

0:02:34.560000 --> 0:02:38.860000
 stateless, and that's the key word there,
 and scalable method for managing

0:02:38.860000 --> 0:02:44.440000
 authentication and session data
 in modern distributed systems.

0:02:44.440000 --> 0:02:47.760000
 Traditional session-based authentication
 methods often require server

0:02:47.760000 --> 0:02:52.120000
-side storage and, you know, to manage
 session states which can be resource

0:02:52.120000 --> 0:02:54.160000
 intensive 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.340000
 authentication was created.

0:02:59.340000 --> 0:03:05.400000
 And you'll typically see that, you know,
 there was a need to, you know,

0:03:05.400000 --> 0:03:11.860000
 move away from having, you know, having
 session information stored server

0:03:11.860000 --> 0:03:18.420000
-side and more importantly, sort of having
 a token that can scale or, you

0:03:18.420000 --> 0:03:21.040000
 know, an authentication mechanism
 that can scale.

0:03:21.040000 --> 0:03:25.900000
 So, JWTs eliminate this need by embedding
 session related data directly

0:03:25.900000 --> 0:03:29.440000
 into the token itself,
 which we'll get into.

0:03:29.440000 --> 0:03:33.380000
 So, this is an example of what a JWT
 token looks like, which has been

0:03:33.380000 --> 0:03:35.420000
 base 64 encoded.

0:03:35.420000 --> 0:03:39.800000
 Now, if you remember what I just said
 a few seconds ago, we have the first,

0:03:39.800000 --> 0:03:43.040000
 which is the header, and they're
 separated with a full stop.

0:03:43.040000 --> 0:03:46.620000
 Then the second part, which is arguably
 going to be the longest, is the

0:03:46.620000 --> 0:03:49.580000
 payload, obviously, based
 on what it stores.

0:03:49.580000 --> 0:03:51.840000
 And then the signature
 is appended at the end.

0:03:51.840000 --> 0:03:53.840000
 So, they're all separated by a full stop.


0:03:53.840000 --> 0:03:57.980000
 In total, you'll have three sections
 or three tokens, if you will, that

0:03:57.980000 --> 0:03:59.620000
 are conjoined together.

0:03:59.620000 --> 0:04:04.540000
 And as a whole, they give you this
 right over here when decoded.

0:04:04.540000 --> 0:04:09.840000
 So, you have the header, and then of
 course the payload, the signature,

0:04:09.840000 --> 0:04:12.360000
 as I mentioned, right over here.

0:04:12.360000 --> 0:04:20.060000
 Essentially, you know, is sort of the, an
 encoded or, you know, cryptographically

0:04:20.060000 --> 0:04:28.160000
 signed version or, yeah, I would say
 cryptographically signed string as

0:04:28.160000 --> 0:04:36.100000
 a result of, you know, encoding
 or encrypting this.

0:04:36.100000 --> 0:04:39.280000
 But, you know, the bottom line is that
 at first glance, this looks quite

0:04:39.280000 --> 0:04:42.700000
 convoluted. And you might be asking
 as well, why did we move away from

0:04:42.700000 --> 0:04:47.180000
 session IDs, which were, you know,
 you could consider just this small,

0:04:47.180000 --> 0:04:52.760000
 you know, string right over here, or
 headache, you will, in this case.

0:04:52.760000 --> 0:04:56.260000
 But it's, well, this looks convoluted.

0:04:56.260000 --> 0:05:00.180000
 It's actually a very compact printable
 representation of a series of claims

0:05:00.180000 --> 0:05:03.580000
 along with the signature to
 verify its authenticity.

0:05:03.580000 --> 0:05:07.420000
 So, you can see this here with the header,
 you have the algorithm, which

0:05:07.420000 --> 0:05:13.060000
 is HS256, the type is JWT, the
 payload contains the subject.

0:05:13.060000 --> 0:05:16.640000
 Well, don't worry, we'll get into what
 each of these claims means, because

0:05:16.640000 --> 0:05:20.100000
 you, the payload is arguably the most
 important along with the header.

0:05:20.100000 --> 0:05:22.080000
 In fact, it's all important.

0:05:22.080000 --> 0:05:23.720000
 But don't worry, it'll make sense.

0:05:23.720000 --> 0:05:26.800000
 So, you know, subject name and
 then admin is set to true.

0:05:26.800000 --> 0:05:31.300000
 This is generally what, you know, you
 would consider session related data.

0:05:31.300000 --> 0:05:33.620000
 So, hopefully it's starting
 to make sense.

0:05:33.620000 --> 0:05:36.900000
 Now, that brings us to the, you
 know, elephant in the room.

0:05:36.900000 --> 0:05:41.600000
 And that is, you know, what is the
 role, or what are the role of JWTs

0:05:41.600000 --> 0:05:43.660000
 and authentication and
 session management?

0:05:43.660000 --> 0:05:45.700000
 Well, let's start off
 with authentication.

0:05:45.700000 --> 0:05:50.480000
 So, in the case of authentication, JWTs
 are widely used for authenticating

0:05:50.480000 --> 0:05:52.660000
 users in web applications.

0:05:52.660000 --> 0:05:56.900000
 And upon successful login, the first
 thing that happens is that the server

0:05:56.900000 --> 0:06:00.920000
 generates a JWT containing
 the user specific claims.

0:06:00.920000 --> 0:06:04.620000
 When I say claims for now, just for
 these slides, just think of it as

0:06:04.620000 --> 0:06:09.680000
 your session, you know, the information
 regarding your session.

0:06:09.680000 --> 0:06:13.860000
 Then the token is signed with a secret
 or private key, and we'll get into

0:06:13.860000 --> 0:06:17.160000
 that. And this is done
 to prevent tampering.

0:06:17.160000 --> 0:06:23.040000
 The JWT is sent to the client and stored,
 for example, a cookie or local

0:06:23.040000 --> 0:06:26.880000
 storage. And again, I mentioned this
 in the previous, in the previous

0:06:26.880000 --> 0:06:30.400000
 video, we were, you know, getting
 into token based authentication.

0:06:30.400000 --> 0:06:32.520000
 And then this is the key here.

0:06:32.520000 --> 0:06:36.560000
 For subsequent requests, the
 client includes the client.

0:06:36.560000 --> 0:06:39.080000
 So just think of this as your browser.

0:06:39.080000 --> 0:06:44.000000
 The client includes the JWT in the authorization
 header or in a cookie,

0:06:44.000000 --> 0:06:45.940000
 as we saw in the previous video.

0:06:45.940000 --> 0:06:50.140000
 And then obviously, just like you would
 if you had a session ID or, you

0:06:50.140000 --> 0:06:53.860000
 know, cookie, the server validates
 the token to authenticate the user

0:06:53.860000 --> 0:06:57.340000
 in your session data is contained
 therein already.

0:06:57.340000 --> 0:07:02.020000
 So this is an example of a get request
 being made to a protected resource.

0:07:02.020000 --> 0:07:04.420000
 The host is just acme.com.

0:07:04.420000 --> 0:07:08.580000
 And then in this case, we're using the,
 you know, bearer token as an example.

0:07:08.580000 --> 0:07:11.920000
 So the authorization header and then
 the bearer token right over here

0:07:11.920000 --> 0:07:16.380000
 is not enough space for me to include,
 you know, to include the actual

0:07:16.380000 --> 0:07:19.520000
 token in its entirety,
 but you get the idea.

0:07:19.520000 --> 0:07:22.980000
 And then we move on to session management,
 which I'm guessing a lot of

0:07:22.980000 --> 0:07:25.040000
 you are pretty curious about, right?

0:07:25.040000 --> 0:07:29.800000
 So JWT is enabled stateless session
 management, meaning the server does

0:07:29.800000 --> 0:07:34.300000
 not need to store session data, all
 necessary information, for example,

0:07:34.300000 --> 0:07:40.020000
 user roles, expiration, etc, is embedded
 within the token itself.

0:07:40.020000 --> 0:07:44.560000
 And what are the benefits that JWT
 provide for session management?

0:07:44.560000 --> 0:07:45.900000
 Well, firstly, scalability.

0:07:45.900000 --> 0:07:54.120000
 So it eliminates the need
 for domain authentication.

0:07:54.120000 --> 0:07:59.740000
 So, you know, this works really well
 in distributed systems and APIs.

0:07:59.740000 --> 0:08:03.400000
 And obviously it's decentralized, you
 know, session information is not

0:08:03.400000 --> 0:08:06.800000
 stored on the server side
 or in a central location.

0:08:06.800000 --> 0:08:10.260000
 So, you know, it allows third party
 services to validate tokens without

0:08:10.260000 --> 0:08:12.420000
 contacting the issuer.

0:08:12.420000 --> 0:08:17.260000
 All right. So now that we've sort of
 got a history or a background as

0:08:17.260000 --> 0:08:23.920000
 to what JWTs are, what they look like,
 as well as why they were created.

0:08:23.920000 --> 0:08:27.600000
 And the role they play in authentication
 and session management, we need

0:08:27.600000 --> 0:08:31.720000
 to take a deeper dive into the structure
 that I highlighted in the, you

0:08:31.720000 --> 0:08:35.800000
 know, the earlier slides, you know,
 and understand the header payload

0:08:35.800000 --> 0:08:40.060000
 and signature and what exactly they
 contain, how they're created, and

0:08:40.060000 --> 0:08:49.160000
 what the entire process looks like
 always comes first, right?

0:08:49.160000 --> 0:08:54.500000
 So the, you know, every JSON web token
 follows a syntax or a format where

0:08:54.500000 --> 0:08:57.160000
 we have the header, the payload,
 and then the signature.

0:08:57.160000 --> 0:09:00.440000
 So, you know, the first part, and again,
 they're separated with a full

0:09:00.440000 --> 0:09:03.480000
 stop. I have to remind you that
 because it's quite important.

0:09:03.480000 --> 0:09:07.800000
 Now this order is crucial because the
 signature, this is very important.

0:09:07.800000 --> 0:09:11.820000
 The signature is generated by hashing
 the header and the payload together,

0:09:11.820000 --> 0:09:15.200000
 which is what I was trying to explain
 earlier, but I couldn't sort of

0:09:15.200000 --> 0:09:18.400000
 articulate it as well as
 I did in this slide.

0:09:18.400000 --> 0:09:22.880000
 And the bottom line is that reversing or
 altering this order would invalidate

0:09:22.880000 --> 0:09:24.840000
 the token, obviously.

0:09:24.840000 --> 0:09:30.580000
 So the end, the final part, the third
 part of the JSON web token as a

0:09:30.580000 --> 0:09:31.860000
 whole is the signature.

0:09:31.860000 --> 0:09:36.640000
 And the signature is only created or
 generated by hashing the head end

0:09:36.640000 --> 0:09:38.460000
 payload together.

0:09:38.460000 --> 0:09:44.580000
 So that's the, you know, that I just
 wanted to get that out of the way

0:09:44.580000 --> 0:09:45.560000
 before we continue.

0:09:45.560000 --> 0:09:49.880000
 And I've sort of made it easier to understand
 in this particular slide.

0:09:49.880000 --> 0:09:55.540000
 And, you know, the key thing that I
 wanted to highlight is, you know,

0:09:55.540000 --> 0:09:57.100000
 the separation by dots.

0:09:57.100000 --> 0:09:59.540000
 So the format is header
 payload signature.

0:09:59.540000 --> 0:10:04.260000
 I've used a legitimate JSON web
 token here that I created.

0:10:04.260000 --> 0:10:10.980000
 And I've sort of colorized the three
 different parts, if you will, and

0:10:10.980000 --> 0:10:14.200000
 sort of highlighted what they
 are again, color coded.

0:10:14.200000 --> 0:10:17.840000
 So you have the header here, the payload
 in green and the signature at

0:10:17.840000 --> 0:10:21.500000
 the end. And you can see they're separated
 by dots or full stops, if you

0:10:21.500000 --> 0:10:24.100000
 will. So hopefully that makes sense.

0:10:24.100000 --> 0:10:28.220000
 Now let's get started with the JWT header,
 all right, or the first part.

0:10:28.220000 --> 0:10:33.020000
 So the header contains metadata about the
 token, such as the signing algorithm,

0:10:33.020000 --> 0:10:39.160000
 and examples of these are HS256,
 RS256, and the token type.

0:10:39.160000 --> 0:10:43.600000
 In this case, it's going to be JWT,
 or in most cases, I should say.

0:10:43.600000 --> 0:10:49.220000
 So what this means is that if you were
 to decode a JSON web token, if

0:10:49.220000 --> 0:10:53.500000
 you had the secret key, this is what
 the first part would look like the

0:10:53.500000 --> 0:10:57.920000
 header. And then we have the payload,
 which is arguably the most important

0:10:57.920000 --> 0:11:00.820000
 part of the JWT token.

0:11:00.820000 --> 0:11:05.320000
 So the payload is, as I said, the second
 part of the JWT and contains

0:11:05.320000 --> 0:11:09.360000
 claims that provide information
 about the user or session.

0:11:09.360000 --> 0:11:15.500000
 Claims can be registered, ISS, EXP,
 IAT Donorit will get into what each

0:11:15.500000 --> 0:11:21.000000
 of these means, you know, public or application
 specific or private agreed

0:11:21.000000 --> 0:11:27.860000
 upon. This section includes information
 like user roles, permissions,

0:11:27.860000 --> 0:11:33.720000
 and token payload is base 64 encoded,
 not encrypted, which means it is

0:11:33.720000 --> 0:11:37.280000
 generally speaking readable if decoded.

0:11:37.280000 --> 0:11:41.500000
 And then we have the JWT signature,
 which probably might have confused

0:11:41.500000 --> 0:11:45.280000
 a lot of you. So the signature is the
 final part of the JWT and ensures

0:11:45.280000 --> 0:11:48.000000
 token integrity and authenticity.

0:11:48.000000 --> 0:11:53.480000
 It is created by signing the encoded
 header payload and a secret key for

0:11:53.480000 --> 0:11:57.080000
 symmetric algorithms, or a private key.

0:11:57.080000 --> 0:12:02.560000
 This is very important for, you
 know, asymmetric algorithms.

0:12:02.560000 --> 0:12:06.000000
 So the signature ensures that the
 token has not been tampered with.

0:12:06.000000 --> 0:12:10.500000
 So in this case, I've just given you
 an example of a formula that's used

0:12:10.500000 --> 0:12:16.940000
 to generate the signature based on,
 you know, the based on an existing

0:12:16.940000 --> 0:12:18.420000
 header and payload.

0:12:18.420000 --> 0:12:21.640000
 So you have in this case, it's HS 256.

0:12:21.640000 --> 0:12:26.620000
 So you can see right where there's a
 function where base 64 URL and code

0:12:26.620000 --> 0:12:31.880000
 the header plus you append, you know,
 the dot or the full stop and then

0:12:31.880000 --> 0:12:38.080000
 concatenate base 64 URL and code the
 payload and then the secret over

0:12:38.080000 --> 0:12:40.720000
 here. So that's how that works.

0:12:40.720000 --> 0:12:45.540000
 Now, you know, I mentioned claims when
 we're talking about the JWT payload,

0:12:45.540000 --> 0:12:48.680000
 but we need to dive into these because
 it's very important that you understand

0:12:48.680000 --> 0:12:54.680000
 exactly what you're looking at when
 you're the payload of a JWT.

0:12:54.680000 --> 0:12:56.400000
 So what are claims?

0:12:56.400000 --> 0:12:57.880000
 That's a, you know, interesting word.

0:12:57.880000 --> 0:13:01.360000
 Well, claims in JWTs are key value pairs.


0:13:01.360000 --> 0:13:06.020000
 So just think parameter value, you know,
 in web on the web, but you know,

0:13:06.020000 --> 0:13:09.580000
 key value pairs in the payload
 section of the token.

0:13:09.580000 --> 0:13:13.900000
 These claims carry information about
 the user session or other relevant

0:13:13.900000 --> 0:13:19.000000
 data and are used by the application
 or service to process the token.

0:13:19.000000 --> 0:13:23.900000
 Okay, JWT claims are not encrypted by
 default unless the JWT is encrypted

0:13:23.900000 --> 0:13:28.820000
 using JWE, which will not get
 into at least in this video.

0:13:28.820000 --> 0:13:33.800000
 And therefore, you know, claims are
 base 64 encoded but easily readable.

0:13:33.800000 --> 0:13:38.960000
 So the bottom line is that they should
 not contain or include sensitive

0:13:38.960000 --> 0:13:40.260000
 information like passwords.

0:13:40.260000 --> 0:13:43.980000
 And hopefully that's giving you an idea
 as to where the vulnerabilities

0:13:43.980000 --> 0:13:47.880000
 come into play or where the misconfigurations
 come into play, because

0:13:47.880000 --> 0:13:53.200000
 sometimes, sometimes JWTs are not implemented
 correctly and they could

0:13:53.200000 --> 0:13:57.680000
 contain some juicy information
 in the payload.

0:13:57.680000 --> 0:14:03.060000
 So claims enable JWTs to a provide context,
 so include information about

0:14:03.060000 --> 0:14:04.340000
 the user session.

0:14:04.340000 --> 0:14:08.500000
 I'm drilling that in so that it sticks
 in your mind, authorized actions,

0:14:08.500000 --> 0:14:13.140000
 which is the next step,
 very specific to claims.

0:14:13.140000 --> 0:14:17.340000
 You know, in this case, you know, in
 terms of authorized actions, you're

0:14:17.340000 --> 0:14:21.480000
 defining user roles and permissions
 for resource access, and then see

0:14:21.480000 --> 0:14:23.480000
 support application logic.

0:14:23.480000 --> 0:14:27.420000
 So, you know, share data between
 services in a distributed system.

0:14:27.420000 --> 0:14:32.760000
 So let's get started with the first
 type of claims, which are registered

0:14:32.760000 --> 0:14:37.540000
 claims. So these are predefined optional
 claims that provide a standardized

0:14:37.540000 --> 0:14:40.000000
 way of describing common information.

0:14:40.000000 --> 0:14:44.080000
 Examples include, and remember,
 claims are found in the payload.

0:14:44.080000 --> 0:14:47.700000
 It's very important that you actually
 can you understand where we are

0:14:47.700000 --> 0:14:53.320000
 right now. So we have the issue, right,
 or ISS, whenever you see that,

0:14:53.320000 --> 0:14:56.300000
 that just identifies
 who issued the token.

0:14:56.300000 --> 0:14:59.640000
 So example would be a server
 or authentication service.

0:14:59.640000 --> 0:15:03.940000
 So whenever you see ISS in the payload,
 just know it's referring to who

0:15:03.940000 --> 0:15:08.540000
 issued it, or who issued that token,
 then you may find the subject or

0:15:08.540000 --> 0:15:14.340000
 sub. This identifies the subject of the
 token, often a user ID, all right,

0:15:14.340000 --> 0:15:17.520000
 often it's not always the
 case, but you may find it.

0:15:17.520000 --> 0:15:21.240000
 You then have a UD, which is not that
 common anymore, or it's not really

0:15:21.240000 --> 0:15:24.160000
 used that much. AUD is the audience.

0:15:24.160000 --> 0:15:28.800000
 So this indicates the intended recipients
 of the token, for example, a

0:15:28.800000 --> 0:15:33.500000
 specific API. You then have EXP,
 which is expiration time.

0:15:33.500000 --> 0:15:35.760000
 I don't think I need to elaborate
 on it, but I will.

0:15:35.760000 --> 0:15:40.900000
 So this specifies when the token expires
 and the key here, because it

0:15:40.900000 --> 0:15:44.180000
 may look confusing when you see it
 in that format, is that it's using

0:15:44.180000 --> 0:15:46.020000
 Unix timestamp format.

0:15:46.020000 --> 0:15:49.440000
 So you just see, you know, just
 a random set of numbers.

0:15:49.440000 --> 0:15:50.200000
 They're not random.

0:15:50.200000 --> 0:15:52.480000
 They are in Unix timestamp format.

0:15:52.480000 --> 0:15:55.780000
 And then you have IAT, which
 is, you know, issued at.

0:15:55.780000 --> 0:16:00.420000
 This indicates when the token was created
 again in Unix timestamp format,

0:16:00.420000 --> 0:16:05.560000
 and then NBF, which is not before, this
 specifies when the token becomes

0:16:05.560000 --> 0:16:09.100000
 valid. That can be very useful, 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, 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:23.640000
 would look like in the payload
 of the, of HAWT.

0:16:23.640000 --> 0:16:31.540000
 So issuer, subject, audience, expiry,
 and over here, if we go back, issued

0:16:31.540000 --> 0:16:34.040000
 at, just wanted to make sure.

0:16:34.040000 --> 0:16:38.820000
 And you can see this is the Unix timestamp
 format, subject, user ID typically

0:16:38.820000 --> 0:16:42.460000
 issuer can just be, you know, the website
 or the web application that

0:16:42.460000 --> 0:16:47.120000
 issued it. So yeah, that's what
 registered claims look like.

0:16:47.120000 --> 0:16:50.520000
 We then have public claims right now.

0:16:50.520000 --> 0:16:55.300000
 These are custom claims defined
 by the application developer.

0:16:55.300000 --> 0:17:02.720000
 So the key thing to note is that with
 the registered claims, these ones,

0:17:02.720000 --> 0:17:07.300000
 you know, you cannot create a public
 claim of your own that has the same

0:17:07.300000 --> 0:17:08.620000
 name as any of these.

0:17:08.620000 --> 0:17:12.680000
 That's the easiest way to say it, which
 is what I was alluding to here.

0:17:12.680000 --> 0:17:18.200000
 So, you know, these are custom claims
 defined by the application developer.

0:17:18.200000 --> 0:17:22.840000
 Public claims must be unique to avoid
 collisions with other claim names.

0:17:22.840000 --> 0:17:26.720000
 They typically store user specific
 or application specific data, which

0:17:26.720000 --> 0:17:31.420000
 makes sense. In the payload, you may
 want to save or to store, you know,

0:17:31.420000 --> 0:17:33.840000
 some other session related data.

0:17:33.840000 --> 0:17:36.240000
 That's, you know, that goes without
 saying, and how do you do that?

0:17:36.240000 --> 0:17:37.860000
 Well, through public claims.

0:17:37.860000 --> 0:17:42.280000
 So an example of this, or examples of
 these public claims would be a role.

0:17:42.280000 --> 0:17:46.920000
 So, you know, this would be very helpful,
 very common, very helpful in

0:17:46.920000 --> 0:17:48.380000
 defining the user's role.

0:17:48.380000 --> 0:17:50.720000
 So admin, user, etc.

0:17:50.720000 --> 0:17:52.540000
 Or privileges, if you will.

0:17:52.540000 --> 0:17:56.020000
 And then email. So, you know, stores
 the user's email, permissions, this

0:17:56.020000 --> 0:17:58.460000
 lists the access rights for the user.

0:17:58.460000 --> 0:18:02.400000
 I've given you the best example of
 what you're likely to encounter in

0:18:02.400000 --> 0:18:05.460000
 the domain or category of public claims.

0:18:05.460000 --> 0:18:09.100000
 Again, when talking about authentication,
 you'll see the role.

0:18:09.100000 --> 0:18:13.880000
 So maybe admin or not admin, the email,
 the permissions, what you're allowed

0:18:13.880000 --> 0:18:17.740000
 to do. So you can see it's
 starting to make sense now.

0:18:17.740000 --> 0:18:19.000000
 And then you have private claims.

0:18:19.000000 --> 0:18:22.960000
 So private claims are custom claims
 that are agreed upon between parties

0:18:22.960000 --> 0:18:25.200000
 exchanging JWTs, right?

0:18:25.200000 --> 0:18:28.060000
 They're not standardized and are typically
 used for application specific

0:18:28.060000 --> 0:18:32.220000
 data. Examples of these would be, you
 know, department, the specifies

0:18:32.220000 --> 0:18:36.280000
 the user's department, cart ID, for
 example, in an e-commerce web app

0:18:36.280000 --> 0:18:38.400000
 stores the shopping cart ID.

0:18:38.400000 --> 0:18:40.020000
 This is what it would look like.

0:18:40.020000 --> 0:18:43.400000
 So, hopefully that makes sense.

0:18:43.400000 --> 0:18:47.040000
 All right. So that brings us
 to the end of the video.

0:18:47.040000 --> 0:18:49.480000
 And hopefully, I know
 we've covered a lot.

0:18:49.480000 --> 0:18:52.200000
 These slides have, you know, been
 been made available to you.

0:18:52.200000 --> 0:18:54.500000
 So definitely go through
 it more than once.

0:18:54.500000 --> 0:18:56.420000
 Go through this video more than once.

0:18:56.420000 --> 0:18:59.780000
 Because I've sort of encapsulated quite
 a bit and I'm actually kind of

0:18:59.780000 --> 0:19:03.500000
 happy with how I've been able to compress,
 you know, at least everything

0:19:03.500000 --> 0:19:09.220000
 I've learned as well as everything I
 know or is publicly available about

0:19:09.220000 --> 0:19:12.760000
 JWTs. But now we're, you know, going to
 start exploring the vulnerabilities

0:19:12.760000 --> 0:19:17.400000
 individually. I didn't want to sort of
 give you a list of vulnerabilities,

0:19:17.400000 --> 0:19:23.920000
 you know, that affect JWTs, you know, as
 a whole or in a sort of a collective

0:19:23.920000 --> 0:19:26.160000
 series, but to explore them individually.


0:19:26.160000 --> 0:19:29.920000
 So that's what we'll be exploring
 in the next set of videos.