JWT Verification Utility

[00:00:00]
>> Speaker 1: OK, so locking down the routes with the JSON Web Token Authentication We already implemented the first side of JSON Web Tokens, which is creating them when someone signs up and signs in Cool Now, what do we do with that information Like I said, our API is super skeptical It doesn't trust anyone ever It knows no one

[00:00:00]
You have to send up your credentials every time You could think of our APIs like a bouncer They let you in the club the first time you left to hear something out of your car If you come back, they don't remember you You've got to do the same thing you did to get in the first time There's no special access

[00:00:00]
You've got to show your ID again You're going to get frisked for weapons again, everything all over again, and if you leave and come back, it's going to be the same thing no matter what Even every day for a year if you go to that same club, they're going to do the same thing That's how our server is going to be

[00:00:00]
It doesn't trust anyone So we're going to do something called the bearer token pattern It basically is where it's a pattern in which we can attach a JSON Web Token to a header, typically the Authorization header If you don't know what a header is, a header is a set of metadata It's just a key-value object that tells the server and the client more information about this request, like where it came from, caching strategies, things like authorization, credentials, and custom headers

[00:00:00]
You can do custom headers There's really nothing you can't put on the header, and they might be one of the most powerful things in HTTP, but it's just a key-value object So we're going to add an Authorization header on all of our requests to our API, and the value is going to be the word "bearer" followed by our token

[00:00:00]
And that's the strategy Then on our server, we need to check for that, decode it, identify and authenticate, and keep moving So we can just hop right into it We already have the other part of the code where we are generating, so we're just going to add some more code next to that Let's hop right into our JWT code here

[00:00:00]
And we already have our generate token The next thing we're going to do is the inverse of that We're going to verify a token So to verify a token, we're going to need the actual token itself And we could even type this response to be a promise of type JWT payload We need to make the same secret key that we used to sign it, so we'll get the secret key from the JWT_SECRET environment variable

[00:00:00]
The encoding is UTF-8, same thing we did before, which means we should probably make this its own function since we already did it twice Then we can verify the token, which not only validates the token that it's not expired, used the same signing secret (which means it's from this server), but it will also decode the token and turn it back into an object

[00:00:00]
That means this payload is going to be the same payload that we passed in when we created it, which is an object that has an ID, email, and username on it, assuming it's all valid We'll use verify from JOSE, passing the token and the secret key From here we can just return the entire payload There might be some TypeScript type handling that requires some additional type casting, but essentially we'll return the payload as a JWT payload.