API Design in Node.js (using Express & Mongo) JSON Web Tokens
This course has been updated! We now recommend you take the API Design in Node.js, v4 course.
Transcript from the "JSON Web Tokens" Lesson
>> Speaker 1: So what we're gonna do now is we're gonna talk about authentication, which I really, 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 [LAUGH] and it just feels good when it works.
[00:00:22] And, I always have people try to break my stuff. See if you can get in here. I built this one system one time, before I knew much about authentications. It was reading all these blog posts and tutorials, and I built this one system, to the point where I couldn't get in myself.
[00:00:37] I didn't know how to get in my own, I had to drop the entire database and all this stuff because 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.
[00:00:52] So, there are many ways to protect your API, right? What's a typical way you would protect an API?
>> Speaker 2: Everything needs a header with some password or something, like a basic off.
>> Speaker 1: Okay, so a basic off. That's one way, any other way? I know we got some back-end people here, .net experience.
[00:01:20] How do you guys protect your APIs?
>> Speaker 2: Cookies.
>> Speaker 1: Cookies, exactly. I was wondering if somebody was gonna say that cuz, I know we know cookies in here. Yeah, so cookies is probably the thing that people use for authentication, authorization, identification, right? So that's the thing. So you have your cookies and then you'd have a session store, where you store your sessions, some key value pair, maybe your using Redis, or whatever you're using, you have some session store.
[00:01:50] Sorry, I really have something in my eye, if you see me wiping up here. Probably looks like I'm crying, I'm not [LAUGH], my eye is really bothering me for some reason. So, yeah, you have cookies in a session store. And a session store is just like a key value pair of, who's logged in right now, right.
[00:02:07] So that when they make a request, those cookies are automatically still in the header and we can de-serialize those cookies, match it against something in the session store, like aw, it's this person, hey, how's it going? That's what we normally do, and that works, there's nothing wrong with that.
[00:02:23] Who here has done mobile development with Android of iOS? All right, then you probably know that either you just didn't deal with cookies on iPhone or if you did, it was really, really hard. Not as easy as the web. So what we're gonna be using this JSON web tokens or JWT for short.
[00:02:44] It's pronounced jot, like j-o-t, but it's JWT. So JSON web tokens or JWT. So JWT is an open standard that's heavily used. Here's a link I included you can click on it, and we'll be playing around with some stuff in here. This is a website built by this company called Alt Zero, who have authentication as a service, and they do a whole bunch of JWT stuff.
[00:03:06] They have this really nice site where you can decode, and encode, and mess around with different algorithms, with the JSON web tokens, and look at all the libraries for other languages. It's pretty cool. But, we'll be using JSON web tokens, like I said, it's an open standard that's heavily used so it is not like some corporate company came up with this.
[00:03:27] 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's signed in with a session store or have cookies. So there is no session store anymore, there are no cookies anymore. Does that sound dangerous to anybody?
[00:03:46] 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? 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 get me every time, right?
>> Speaker 2: [LAUGH]
>> Speaker 1: I know, but you'll see.
>> Speaker 1: So, the json web token will be sent on every single request, because rest is stateless and we know not of the previous request because it's stateless. So, we don't know who you were the last time you made a request.
[00:04:20] If you don't send us a token every single time to this protected resource, then you're just not gonna get it even though we gave it to you a second ago. They gave it to you a second ago because you had your json web token, this request you didn't, so you're just not gonna get it, right.
[00:04:31] It's an easy thing, give us a token that works and is valid, and maybe we might even check that token see if it's a real user. And then, if you have their appropriate identification authorizations then we'll give you the resource. So like I said, the token since we don't have session store, we don't have cookies or anything like that, the token has to be stored on the client that is requesting the resources.
[00:04:54] So if the client was a web browser in this case, we would store the json web token on the client, somewhere where it can persist. And that's probably gonna be local storage local storage, right? Or, local storage is the common, you guys know what I'm talking about, like you open up the browser and you click on Resources.
[00:05:11] You get all this stuff over here. Local Storage, Session Storage, Cookies, Application Cache for offline applications. Web SQL, which is like a database in your browser. The newer index, sorry, index DV is the newer Web SQL. So Local Storage is like a key value pair store for your browser.
[00:05:30] So, this is where you would store your json web token. You give it a key, give it a value, and it will be there specifically for this browser. Cookies store is kind of the same thing but not really. So that's where we store our tokens, right on the client, put them right there.
[00:05:53] Or at least that's where the client will store their tokens, 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 OAuth2.
[00:06:36] 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.