This lesson is for PRO members.

Unlock this lesson NOW!
Already subscribed? sign in

Server JWT Authentication Setup

4:03 Angular 1.x lesson by

Adding JWT support to the server. Signing a JSON object as a payload and sending the signed token to the browser on authentication.

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

Adding JWT support to the server. Signing a JSON object as a payload and sending the signed token to the browser on authentication.

Avatar
Stefan

I've read that the contents could easily be decoded and read and are only protected against manipulation.

You said, that there's a specification on what should go in the payload. Got a link?

Avatar
Kent C.

Yeah, check this: https://openid.net/specs/draft-jones-json-web-token-07.html

And you definitely don't want to put anything in the payload that is sensitive. Play around with http://jwt.io/ for a little bit and you can see that the information can be decoded regardless of the secret.

In reply to Stefan
Avatar
inlightmedia

Do you know of any resources that might go through adding a secret to a environment variable? Thanks.

Here we have our application. I can log in, no errors, so it's successful. If I give it the wrong password, I get an error. If I don't give it a password at all, I get an error.

The problem with this application is I can still get a random user without being authenticated and we want to protect that resource.

The first step for doing that from here is to implement JWTs on the server. We're going to need a module called JSON Web Token. We'll require that and we'll call it JWT, JSON Web Token.

I'm just going to explain, really quickly, what a JWT is.

JSON Web Token is a specification for authentication. A JWT is an encoded JSON object that the server encodes using a secret key. The encoded JSON object is called a token. That token is sent to the client when the client authenticates. Then the client sends that token back on every single request.

The server, at that point, will decode that token using the same private key, so that it can identify who the user is and act accordingly. What we're going to do is set up the encoding of that token.

For simplicity's sake, we're going to create a JWT secret here and we'll just make it a bunch of random characters. Normally, you would want this to be stored in an environment variable or some other secure place, but we'll just leave it as a string in our app.

Now, we want to encode the user object when the user authenticates. If we scroll down here, instead of sending the user, we're going to want to send a token. We'll create that token now. Token is a JWT.sign and the payload is what is going to be the encoded object. We'll just encode the username for now, but there is an entire specification on what you should actually include in this that you can read up on. For our purposes, the username is sufficient.

Then we're going to give that secret that we set up earlier.

Now we have the token and we're going to send back the token to the client. Just for simplicity's sake, we'll send back the user as well.

On the front end -- before we were expecting a user with this login response. Now we're getting an object that has the user on it. We'll say VM user equals that user. We'll just alert with the response.data.token.

We'll refresh and we'll go ahead and type in the username and password. We got a big, honking error. Let's just go ahead and look at what that is here. It looks like the username is not defined. We'll go to our server and, lo and behold, it's user.username.

We don't need to refresh the page, because the server and the client are totally served up on separate servers. We can just go ahead and log in now. That's our token.

In future requests, we need to store this token somewhere so that it can be sent to the server over and over and over again for every protected resource request. Then the server can decode it back into this payload to identify who the user is and protect the resource that way.

Just to recap here. The client will send a request to log in and here we have that token. If we look at the request, we can see here we're sending the username and password. If we look here, we go to authenticate, we double check that the username and password are correct, and then we'll sign this token with the username and with that JWT secret. Then we'll send the token and the user across the wire.

If we look at the response here, you can see the token and the user comes back in the response. In future requests, that token will be used to make those requests to identify the user. We'll talk about that in the next video.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?