This application uses JSON Web Token (JWT) to handle authentication. JWT replaces the traditional cookie/session authentication used in traditional web applications. Scott introduces JWT and talks about how these tokens will be used.
(chill flute jingle) - So what we're going to do now is we're going to talk about authentication, which I really like; I'm a big fan of. I'm not a security expert, but I like authentication for some reason. I don't know why, I just like it. I like that it sucks and it's really hard, and it just feels good when it works. And like, I always have people try to like break my stuff, like, see if you can get in here. I built this one system one time, before I knew much about authentication, just like reading all these blog posts and tutorials and I built this one system, to the point where I couldn't get in myself.
I didn't know how to get in, I had to like drop the entire database and all this stuff, because I, it was so well protected, I couldn't get in it. And I just wasn't knowledgeable enough to figure out what I was doing wrong, so that was pretty funny to me. So, there are many ways to protect our API, alright. What's a typical way you would protect an API? - [Man] Everything needs, like, a header with some password or something? Like a basic Auth? - Okay. So a basic auth.
That's one way. Any other way? I know we got some back end people here. Dot net experience. How you guys protect your API's? - Cookies. - Cookies. Exactly. I was wondering, like, I know we know cookies in here. Ah, yeah. So cookies is probably, like, the thing that people use for authentication, authorization, identification, right? So that's like the thing. So you have your cookies and then you'd have, like, like a sessions store, right? Where you store your sessions, some key value pair, maybe using Red S, or whatever you're using, you have some sessions store.
Sorry, I really have something in my eye if you see me wiping up here. It really looks like I'm crying and I'm not. My eyes like really bothering me, for some reason. So yeah, you have cookies and like a session store. And like a session store is just like a key value pair of, like, you know, who's logged in right now. Right? So we can, when they make a request, those cookies are automatically sit on the header, and we can, like, de-serialize those cookies, match it against something in a sessions store, like, ah, it's this person. Hey, how's it going? All right? That's what we normally do. And that works.
There's nothing wrong with that. Um, who here's done mobile development? With Android or IOS? Then you probably know that either you just didn't deal with cookies on I-phone, or if you did, it was really, really hard. Not as easy as the web. So we're going to be using this Jason web tokens. Or JWT for short. It's pronounced jot, like j-o-t. But it's JWT. So it's Jason Web Tokens or jot. So the JWT is an open standard that is heavily used.
Here's a link I included. You can click on it and we'll be playing around with some stuff in here. But this is a website built by this company called Alt zero, who are like, they have, like, authentication as a service, and they do, like, a whole bunch of JWT stuff. They have this really nice site where you can, like, decode and encode and mess around with different algorithms with Jason web tokens and look at all the libraries for other things, which is pretty cool. But, we'll be using Jason Web Tokens. Like I said, it's an open standard that's heavily used. So it's not, like, some corporate company came up with this.
Like, it's an open thing. It's collective. It's open source. So, because we're using a token approach, we don't need to keep track of who signed in with a sessions store, or have cookies. So there is no sessions store anymore. There are no cookies anymore. Sounds ... that sound dangerous to anybody? Yeah. That's what I thought too the first time. I was, like, that sounds incredibly dangerous. That doesn't make any sense. Why would I do that? Like, I want the server to be a source of truth, to figure out who's signed in and who's not.
If I leave it up to the client, then they'll just, they'll get me every time. Right? But, you'll see. So, the Jason web token will be sent on every single request because the rest is stateless, and we know not of the previous requests. All right, because it's stateless. So we don't know who you were the last time you made the request. If you don't send us a token every single time to this protected resource, then you're just not going to get it. Even though we gave it to you a second ago. We gave it to you a second ago because you had your Jason Web Token.
This request, you didn't. So you're just not going to get it, right. It's an easy thing. Give us a token that works and is valid and maybe we might even check that token to see if it's a real user, and then, if you have the appropriate identification and authorizations, then we'll give you the resource. So like I said, the token, since we don't a sessions store and we don't have cookies or anything like that, the token has to be stored on the client that is requesting the resources. So, if the client was a web browser, in this case, we would store the Jason Web Token on the client somewhere where it can persist.
And that's probably going to be local storage, right? Or, local storage is the common. You also, I mean, you guys know, I'm talking about the, like, if you go into the browser, and you click on resources. You got all this stuff over here; local storage, session storage, cookies, application cache, or off line applications, web SQL, which is like a database in your browser, then the indexedDB, or I'm sorry, IndexedDB is the newer web sequel. So local storage is, like, a key value pair store, for your browser. So this is where you would store, like, you Jason Web Token.
You give it a key, give it a value. And it'll be there specifically for this browser. Cookie storage is kind of the same thing, but not really. So that's where we would store our token. It's right on the client. Put them right there. Or at least, that's where the client would store their tokens. The server doesn't care. The server doesn't care where you do the tokens. It's just like, I gave you a token. If you want something from me, give me the token back. That's it. It's a handshake.
Note, tokens can be used for, like, O op 2. They work. You can replace the tokens you normally use for O op 2 with Jason web tokens. They work the same way. It's pretty cool, actually. Um, and they're actually really used in implement. At least in Java scripts. So note, we will not be going over, like, the algorithms behind all this stuff. So if you're some security person, you really dig, you know, messing around with shahs and how that stuff works and the time complexity and all that good stuff.
We won't be doing that. I'm not a computer scientist. I'm not a security expert. We can talk about it. But we will not be going over that stuff in detail. Besides, this website right here, like I said, does a pretty good job of telling you all about that stuff.
This course was created by Frontend Masters. It was originally released on 12/30/2015. We're pleased to host this training in our library.
- Executing Node.js
- Using Express
- What is middleware?
- Testing in Node.js
- Using Mongo with Node.js
- Data modeling
- Querying data with Mongoose
- Identifying sensitive routes
- Configuring the deployment