Transcript from the "JSON Web Token Authentication" Lesson
>> Scott Moss: So JWT authentication. They're basically tokens passed to every single request to check on the auth server. So if you compare it to something like sessions and cookies on the server, right, that's a traditional authentication mechanism where, on the server, the server keeps track of sessions stored somewhere.
[00:00:20] You have some session state where it's in redis, in memory. Somewhere you're keeping track of sessions of a user that's interacted with the database and that's how you know they are authenticated or not. When they're not, you get rid of that session. They had to create a new session.
[00:00:34] So that's like a stateful authentication method. JWT is the quite opposite. It's stateless. The server doesn't keep track of anything. It has no idea what's happening. They're not keeping track of who's asking for anything. All the server does is create a token and gives it to an authenticated requestor.
[00:00:51] And from that point on, the requestor has to send that token on every single request. It's stateless. It doesn't remember what happened last time. You have to send it every single time, and then it checks every single time to see if you're authenticated. So a JWT authentication is basically a bearer token strategy that allows the API to be stateless with user auth.
[00:01:10] What does that mean? Bearer tokens are basically just somebody came up with a way that they can use tokens to authenticate in the authorization header and they call them bearer tokens and JWT is just one type of those. There is many types of bearer authentication methods whether it's like API keys or whatever, JWT is just one of them.
[00:01:30] So the reason I'm saying bearer because you'll see that word when you're implementing this.
>> Speaker 2: Does bearer mean the same thing as client?
>> Scott Moss: Yeah basically, yeah, it's basically saying your API is allowing some untrusted resource to access it. Right, this happened like I said when SaaS company started saying, we wanna develop a API product and allow people to integrate, so we need a way to have untrusted resources access our API.
[00:01:58] Whereas everything before then was all internal. You only use your API for your product, you never really let somebody else use it so you don't have to think about that so this is where this came from. JWTs are created by a combination of secrets on the API and a payload like a user object, so you'll have like some secret.
[00:02:15] You'll pick out the type of algorithm you wanna run to hash it. And then you basically hash that payload, or whatever algorithm you wanna run on it. And that payload is usually, sometimes, something to do with the user. Something to identify about the user. It's role, it's Id, something to identify by it.
[00:02:33] So after we verify this data we see on the request, we know who it was. Now we can do our identification part. So we'll authenticate them, then we'll identify them, and we'll allow our controllers to authorize them. And we can do all three of those with JWT.
>> Scott Moss: Like I said, must be sent with every single request where the API.
[00:02:51] And then API will then try to verify the token was created with the expected secrets. So once you send API a token, the API tries to verify that token, like, hey, was this token created by me with these secrets? And if it was, it will then undo the process of tokenizing that object and it will get back the payload that was created to make that token.
[00:03:13] So if you created a token off a user object, once the token is verified, you'll get back that same user object. So it's a way of passing around a stateless object, basically. Then now, you know who the user is. You can pass that information along across middleware so your controllers know who it is trying to access some type of data and if they're authorized to do it.
[00:03:33] So, it's completely stateless. After a successful verification, JWT payload is accessible in the server. And like I said, it can be used for authorization and identification. Any questions on JWT stuff?
>> Speaker 2: Is the overhead considered to be relatively small for this?
>> Scott Moss: Yeah, it's actually pretty small. Surprisingly, in MyTAN it's easier to set up a system to use JSON web tokens than it is what cookies in sessions.
[00:04:07] Store sessions you need some type of session state. You gotta set up Redis. And you can even store sessions of Mongo if you want to cuz Mongo uses in memory. There's nothing that's set up on the server. Like there's literally nothing. It's basically free. It's not that hard at all because it's pushing off all the work to the client.
[00:04:23] It's like client has to store this token somewhere, not me. I don't care where you store it. Just send it to me, and I'm gonna check a header, and then I'm gonna verify it, and that's it. I don't have to do anything else. So, yeah, the overhead is a lot simpler than a stateful implementation.