JSON Web Token Security

[00:00:00]
>> Steve Kinney: I have one-ish more things to talk about. Let's talk about, one or two, kinda slightly more, they're not esoteric per se. They're very popular, but then also you know it when you need it kind of thing, right? So there has been two fatal flaws in all of our examples today, right?

[00:00:32]
One, they assume that you have one web server, right? And you have one database. And you can store your sessions in that database, right? And then you can hit a SQL query and you can go get the session out of the database. That seems great, right? Except that at any scale, that's probably gonna fall apart, right?

[00:00:56]
You might have your login authentication system. Is maybe completely separate from the app that you work on, right? All this origin stuff is going to be a real pain for you. And seeing those cookies, and you may be well, I guess I can't do this, right? And so there are some other options out there.

[00:01:15]
And again, if you have a single app, whatever you don't necessarily need these things. You could even choose to store your sessions in memory and not even put them in a database or whatever. You could put in them all in a centralized database as well. But you're gonna be sad between sharding and load balancing, cuz think about how many users you have.

[00:01:39]
Now think about the fact that they can be logged in on their phone, their iPad, and their browser, right? And just think about how much data that is, right? It's not particularly easy. So there is like a kind of like somewhat interesting idea that kind of takes a lot of things that we saw earlier and pulls it in together.

[00:02:01]
Now there's some risks involved in that. And I think, I asked before we did this workshop, what are some things that people wanted to know about. And this is like the most asked for thing, which is kind of like why we're covering it, because it's like one of those things that seems really like, I'm gonna be honest, like the first three, five, six, times that I was trying to read up this years ago.

[00:02:21]
I was like, this doesn't make any sense to me. And it's actually not that hard. He says, well, you'll be the judge of that when I'm done talking. But the idea is, what if we just didn't have sessions? What if I gave you a piece of data that told you who I'm and everything I'm allowed to do?

[00:02:39]
And you just trusted that thing, right? Before I explain it, just to prime your brains, remember the beginning when we signed cookies? Just think about that for like one second. Okay, it's not what this is, but it's not what it is either. Cool, and so JSON Web Token is pronounced jot, which I will not be doing.

[00:03:01]
If you say it out loud, the correct pronunciation is jot, I won't, okay? A JWT is some kind of value that is secretly broken up into three parts, right? One is how is this encrypted, right? So what is the encryption algorithm which we need to decrypt it? The other one is, remember those signed cookies, right?

[00:03:27]
You had like, Bobby Tables, and then you had like, a signature. It's basically, what is this person allowed to do and then that cryptographic hash that basically says like, hey, if that doesn't match this, don't even trust this thing, right? So it's kind of like taking some of those ideas that we saw before and pulling them all together, and now there is no concept of a session.

[00:03:52]
Basically, you need to trust whoever minted this thing, right? And that it matches everything you need it to match. But like it also then, like, considering you're signing it with a secret, no one else. If you have that secret on your end, you should be able to decode it.

[00:04:08]
There doesn't need to be sessions anywhere or a database. It's like you've got a secret key. You've got the same secret key. I'm gonna send you this message. Only we can decode it. If anyone tampers with it, even the parts we can see that hash part won't work.

[00:04:23]
And the claims are the stuff in the middle. It's like, what can this do? It's like, what's your username? Are they allowed, are they admins, right? You can put like all of the kind of rules of what they are and are not allowed to do in this token, and then we can trust it because I can both verify the middle part.

[00:04:40]
This is everything you're allowed to do, translates into this hash with the same key, and thereby this thing is legit, and if it doesn't, I'm throwing it in the garbage can, right? Various claims, a lot of fun. So this makes it super easy, right? How to do this on Web Token.

[00:04:59]
Sounds good, right? It was legit. I color-coded it, though, so that makes it nicer. That red part is details about the encryption algorithm. That middle part is that data payload of what can they do, who are they, all that stuff, right? And the last part is the signed encryption hash, right?

[00:05:27]
And so we decrypt the middle part and then we also then, basically do it a second time on that last part. If everything doesn't match up, somebody touched this thing, right? The same way we saw with the integrity on the CSP policies for like jQuery, right? The same key should both decode that and then also that hash should be the same thing again.

[00:05:52]
It's kind of hard to explain in words, but like it does give you the ability to say like, we know that this thing, we both are the only two people going to decode it. And then we verify that what we decoded actually has not been tampered with at all, through a lot of the same things we saw throughout different topics.

[00:06:09]
Then the question is, where do you put this thing, right? And this was one of the biggest questions I got, which was like, do I put in local storage? I put in local storage, right? I like the shaking of the heads, means we got it. And so there's some trade offs, and there's a right answer, don't worry.

[00:06:26]
But the cool part is, with no session storage whatsoever, now these systems can be completely decoupled. They can pass in any kind of, they can pass an authorization header. Doesn't even have to be the cookie. Like, microservices like that. We got browsers, we put in the cookie. But like different microservices can choose to put headers on there, as well on the backend, so backend engineers love it.

[00:06:46]
Frontend engineers that work at companies that have way too many different systems with too many origins is basically the only option, right? For the app that I work on, every single customer is on a different domain, and that's two levels. So like, I can't, and I don't want to, right?

[00:07:01]
Like have one cookie. And they're all subdomain of us, and we're not on that public list, so on and so forth, that I know of, I should check. So we use JWTs for this as well. And you can kind of pass it around. Since you don't need any storage, means you don't need databases to hold on to.

[00:07:17]
You don't need to have multiple services talking to those databases. If you ever set up a Cloud architecture, it's like microservices you've never seen before. Everything is its own tiny little thing. I joked with the head of our Cloud infrastructure. He's like, what does a front-end architect do?

[00:07:37]
I'm like, my job is to take the tiny microservices you broke everything into and make sure our customers never know you did that, right? It make it seem like one cohesive experience. So this is what we use for doing that. But yeah, and so it means that as long as this token is valid and we can prove that it's valid and the code is like two lines, honestly, there's a JSON web token library that looks very much like signing a cookie, and you just don't put in sessions.

[00:08:03]
I'll show if you want, we can decide. But like, it means that you don't need any of that stuff in the middle. That said, remember how we could invalidate a session on our database by just deleting it from the database? If your tokens get lost. You're kind of in big trouble, right?

[00:08:24]
It's not to be taken totally lightly, because if for some reason, you make a boo boo, we might be in for a problem, because they can just be saved and used. And they have an expiration date, but it's not the server that can change the expiration date on the cookie anymore or delete the session from the database.

[00:08:46]
We're not storing this thing anywhere. We're just saying that if this thing checks out right, then we should be good to go. But if you get a problem, you can. You do end up with a problem, right? And session IDs are easier because they're stored on the server.

[00:09:08]
You have some of that same origin policy things. You can get away with sessions in a stored, server side. It's not too bad. They are a little bit easier to decrypt at the same time. So it's not always the right answer, but usually your architecture will dictate one or the other, cool.

[00:09:29]
And so yeah, unless you have a completely stateless piece as well versus session ideas where you do need the data. That's me just saying stuff in a different way because I feel like I needed to at the time, cool. You can have checks, you can be business logic and try to figure out, hey, there's something about this one we no longer accept.

[00:09:50]
But it's not gonna be your favorite day at work, I'll tell you that much. Versus if sessions are bad, you can wipe it, you can drop that table and start over. Not that you should do that, it's gonna have a lot of bad consequences, but you could. And the jobs are going to be a little trickier.

[00:10:05]
So the biggest thing is that, it's telling you what algorithm to use. If you don't check to make sure you're all using the same algorithm, someone could force a weaker one on you. And a lot of times that is just you forgetting a line of code saying, hey, and check hashes with H256 or whatever, RS256.

[00:10:30]
If you forget to put that in your code, you're not always gonna have, but there's a venue for it. And if you misconfigure it, you're in some amount of trouble.