‫So we have our user model set up
‫ready to save users with secure passwords.
‫And so next up, we're gonna really implement
‫user authentication and authorization.
‫So in simple terms, the whole work flow
‫of logging users in and allowing them
‫to interact with certain protected resources
‫that non-logged in users cannot access.
‫Now there are many authentication methods out there,
‫but the one we're gonna use is a very modern, simple
‫and secure approach called Json Web Tokens or JWT for short.
‫So Json Web Tokens are a stateless solution
‫for authentication.
‫So there is no need to store any session state on the server
‫which of course is perfect for restful APIs like the one
‫that we're building.
‫Because remember, restful APIs should always be stateless.
‫And the most widely used alternative to authentication
‫with JWTs is to just store the user's log-in state
‫on the server using sessions.
‫But then of course does not follow the principle
‫that says that restful APIs should be stateless
‫and that's why we're opting for a solution like JWTs.
‫So now let's take a look at how authentication
‫actually works with Json Web Tokens.
‫And assuming we already have a registered user
‫in our database, this is how a user logs into the app.
‫So the user's client starts by making a post request
‫with the username or email and the password.
‫The application then checks if the user exists
‫and if the password is correct.
‫And if so, a unique Json Web Token for only
‫that user is created using a secret string
‫that is stored on a server.
‫And a JWT itself is really just a string
‫that looks something like this.
‫But we're gonna talk more about the JWT itself
‫in the next slide.
‫Anyway, the server then sends that JWT back to the client
‫which will store it either in a cookie or in local storage.
‫And just like this the user is authenticated
‫and basically logged into our application
‫without leaving any state on the server.
‫So the server does in fact not know which users
‫are actually logged in.
‫But of course, the user knows that he's logged in
‫because he has a valid Json Web Token which is a bit like
‫a passport to access protected parts of the application.
‫So again, just to make sure you got the idea.
‫A user is logged in as soon as he get back
‫his unique valid Json Web Token which is not saved anywhere
‫on the server.
‫And so this process is therefore completely stateless.
‫Then, each time a user wants to access a protected route,
‫like his user profile data, for example,
‫he sends his Json Web Token along with a request.
‫So it's a bit like showing his passport to get access
‫to that route, right?
‫And that's probably the best and easiest way to understand
‫this whole idea.
‫Now once the request hits the server,
‫our app will then verify if the Json Web Token
‫is actually valid.
‫So if the user is really who he says he is.
‫And more about how this step works
‫a bit later in this video.
‫Now if the token is actually valid, well,
‫then the requested data will be sent to the client
‫and if not, then there will be an error telling the user
‫that he's not allowed to access that resource.
‫And as long as the user is logged in,
‫this is how it's gonna work each time that he requests data
‫from any protected route.
‫Now what's very important to note here
‫is that all this communication must happen over https.
‫So secure encrypted http in order to prevent
‫that anyone can get access to passwords or Json Web Tokens.
‫Only then we have a really secure system.
‫But we will talk about that later in the section, okay.
‫So I know that this can look quite confusing
‫in the beginning when you first try
‫to wrap your head around it, but actually
‫the principle itself is actually quite simple, all right?
‫And this is really all you need to know in order
‫to be able to implement authentication using JWT.
‫But let's now dive a little bit deeper into how
‫the JWT itself actually works.
‫So a Json Web Token looks like left part of this screenshot
‫which was taken from the JWT debugger at jwt.io.
‫So essentially, it's an encoding string
‫made up of three parts.
‫The header, the payload and the signature.
‫Now the header is just some metadata about the token itself
‫and the payload is the data that we can encode
‫into the token, any data really that we want.
‫So the more data we want to encode here,
‫the bigger the JWT.
‫Anyway, these two parts are just plain text
‫that will get encoded, but not encrypted.
‫So anyone will be able to decode them and to read them.
‫So we cannot store any sensitive data in here.
‫But that's not a problem at all
‫because in the third part, so in the signature,
‫is where things really get interesting.
‫The signature is created using the header, the payload
‫and the secret that is saved on the server.
‫Remember that?
‫And this whole process is then called
‫signing the Json Web Token.
‫So again, the signing algorithm takes the header,
‫the payload and the secret to create a unique signature.
‫So only this data plus the secret
‫can create this signature, all right?
‫Then together with the header and the payload,
‫these signature forms the JWT,
‫which then gets sent to the client.
‫Now as I mentioned briefly, right in the first slide,
‫once the server receives a JWT to grant access
‫to a protected route, it needs to verify it
‫in order to determine if the user really is
‫who he claims to be, right?
‫In other words, it will verify if no one changed the header
‫and the payload data of the token.
‫So again, this verification step will check
‫if no third party actually altered either the header
‫or the payload of the Json Web Token.
‫So, how does this verification actually work?
‫Well it is actually quite straightforward.
‫So once the JWT is received,
‫the verification will take it's header and payload
‫and together with the secret that is still saved
‫on the server, basically create a test signature.
‫But the original signature that was generated
‫when the JWT was first created is still in the token, right?
‫And that's the key for this verification.
‫Because now all we have to do is to compare
‫the test signature with the original signature.
‫And if the test signature is the same
‫as the original signature, then it means that the payload
‫and the header have not been modified, right?
‫Because if they had been modified,
‫then the test signature would have to be different.
‫Therefore in this case where there has been no alteration
‫of the data, we can then authenticate the user.
‫And of course, if the two signatures
‫are actually different, well, then it means
‫that someone tampered with the data.
‫Usually by trying to change the payload.
‫But that third party manipulating the payload
‫does of course not have access to the secret,
‫so they cannot sign the JWT.
‫So the original signature will never correspond
‫to the manipulated data.
‫And therefore, the verification will always fail
‫in this case.
‫And that's the key to making this whole system work.
‫It's the magic that makes JWT so simple,
‫but also extremely powerful.
‫So let me summarize it again.
‫Without the secret, no one will be able to manipulate
‫the JWT data because they cannot create
‫a valid signature for the new data.
‫I mean they could manipulate the data of course,
‫but it will always fail the verification step.
‫Now, don't worry, we're not gonna actually implement
‫these JWT algorithms by ourself.
‫They are very complex and we're not gonna
‫reinvent the wheel here, all right?
‫But it's still very important to actually understand
‫how this whole process works behind the scene.
‫And I hope that this lecture did just that for you.
‫But now, let's move on to the next lecture
‫to actually start using all this.