Decode and Verify JWT Encoded Data in Express

[00:00] We've reopened the server.js file, and we're going to modify the Domino Data root. This is the one we're going to test to see if the user has a specific role.

[00:08] First, what we're going to do is deconstruct half of the request headers, the authorization header, and the Node DOM AuthSession ID. Might as well do it at the same time.

[00:17] Once we've done that, we're going to check to see if we don't have an authorization header. Let's immediately return back to the browser with 401, because we need one of those.

[00:32] As part of the RFC specification, we need to include the word "Bearer" in front of our JWT token in the authorization header, but actually to decode it, we need to remove that now. Initially, our default my token value to the authorization value. Now, we're going to look for the word "Bearer," and if we have it, we will remove it.

[00:54] The JWT library has a .verify method, and what happens is, if the token is not verified correctly, then it will throw an error. We'll catch the error, and we will return to the browser, again a 401 status.

[01:19] We'll just put bad token in this case. The method is going to be setting a decoded JWT object, and we'll use the .verify method, pass it our token, and we will also need to pass it our secret.

[01:36] Normally, your secret would be stored locally in an environment variable, and don't store them inside your source control. If we get to this point, we can now deconstruct our username, and our user roles.

[01:50] For this demo, we're going to check to see if we've got an Admin role. We're using includes method of the array. If we don't have an Admin role, we're going to return a 403 status code this time, which is a forbidden status code, rather than authorization missing.

[02:09] If we get to this point in our code, we have successfully got the role, and we can continue to give back our Domino Data. Let's now see that working.

[02:18] OK. I've restarted my server, refreshed my browser page, and I've modified the .get Domino Data call to always use local storage. The first thing I'm going to do is login to get my Node DOM AuthSession ID.

[02:29] Once I login, I get the local storage set. I use my get user roles button, and that's now going to set the JWT token locally with a Bearer. Finally, I'll click get Domino Data, check the console, and we're getting back some data correctly on the tab.

[02:46] As you can see, the authorization header's been set, and so, it's a Node DOM AuthSession ID. Let's try modifying the JWT token on my client.

[02:56] If a user came in, and said, "Right, I am going to modify this value here." And, you can do that inside the Chrome tools.

[03:02] I'm just going to add some values in. If I try and get Domino Data again, if we look at the network tab, I see a 401 unauthorized if I click on the tab, and if I look at the actual response, it's a bad token, which it is, because I've modified it.

[03:17] Let's put that back, so the first thing we'll do it is click get user roles, that should reset my local

[03:21] Bearer token. Get Domino Data to make sure it's still working. It is.

[03:29] What we're going to do is, we're going to modify what role we should have on the server. I've reopened my server.js file, I'm going to change Admin to test, I've changed my error message as well. Save that. Going to restart my server, and retest it in the browser.

[03:46] I've reopened my browser page. If I now click get Domino Data this time, we can see we get a 403, which is a forbidden status code. Look at the response we get, and it says test role required.

[03:58] We've now got our Node server successfully decoding user roles. Therefore it can detect what roots the user actually can call based on the roles that have been sent to them originally by Domino.