In the last section we did a discussion about what the decrypts library was doing for us.
We only really spoke about the crypt in the context of creating a user account and we haven't really
talked about the more important aspect which is how we compare a password in the future when the user
is trying to sign in.
So when we talk about that in the future you know how to assign a user in the decrypt stuff is going
to start to make a lot more sense.
So if it's still is kind of like I don't really know what's going on here.
Don't sweat it.
Once we talked about log in it's going to be a little bit more clear.
So to continue on our application let's look at our asudden location controller.
We've got these Sign-Up handler in here right now we can successfully sign a user up and create their
account.
And at the very bottom we left a point in here which we said that we want to respond Reclast and Kading
that the user was created.
And so we respond success.
True.
If you recall though this doesn't really fit the requirements of authentication that we had sent up
for in the past.
We were looking at a diagram and we said that when a user is signing in or signing up and we verify
their credentials we said we would give them back in identifying piece of information to include on
all future requests and they could then in the future use that identifying piece of information to follow
up with making some number of requests.
So inside of that inside the Sign-Up handler right here at the very end we're sending back just success
true which is like pretty worthless right it's not really doing that much.
We really want to send back.
Is that identifying piece of information after a user signs up.
We now consider them to be logged into our application.
And so at this point in time we want to send back that identifying token keywords here being token.
So in this section we're going to work at producing a token of sorts that the user can store and use
in the future to make authenticated requests.
So let's talk a little bit about the token that we're going to create the token that we're going to
create is specifically called a Jason web tokin or JWT.
Let's talk about how we're going to create the token and how we're going to make use of it.
So this diagram right here shows two different phases in our applications lifecycle on the top.
It's shown in the case of when a user is signing up or signing in and on the bottom we're showing what
happens in the future when they try to make an authenticated request.
So on the top we're saying that we're going to take a user's ID.
So at this point in time we're going to assume that we've already verified their username and password
or we've just created their user account you know everything looks good.
We want to give them a token.
So we're going to take the user's ID.
We're going to combine it or encrypt it with some secret string that we are going to create very shortly
and that produces a Jason web tokin or JWT.
So in essence take a user id encrypt it with a string that produces a token that we can send back to
the user.
The user can then in the future include this token on request to make authenticated requests.
So in the future if the user gives us a token we can decrypt it using our secret string.
And that's going to result in the User ID.
We can then verify this is user and so they have access to these different resources so they are now
authenticated.
The key here is that if the secret string is incorrect or some like you know someone malicious tries
to decrypt our string or decrypt the token if they do not have the correct string or the correct secret
here it is not going to result in a user ID.
So that is where the security comes from.
We have to make sure that we always keep our secret 100 percent secret.
We never want to accidentally post this on our good hub or copy paste it to someone else.
This string right here is absolutely paramount to our applications security.
So one more time to watch this again and they will work on the implementation.
We are going to create a Jason web token.
The purpose of which is going to be authenticating users to create a token.
Are you going to encrypt the user's ID with our secret string that is going to produce a web token in
the future when someone wants to make an authenticated request.
They're going to send us their token.
We'll take that token we will decrypt it with our secret string and that will yield a user ID and we
can then verify that this user exists.
They are now signed in.
They have access to you know so and so resources.
All right so with this overview out of the way let's get started on the implementation and the next
section.