JWT Best Practices

[00:00:00]
>> Steve Kinney: So the question everyone wants to ask, which is where do I put them? You've got a few options. Local storage, this is the worst option. No, there's a worse option. No, no, this is maybe the worst. Which is, do you remember how documented out cooking in the very beginning of this workshop were, I'm just gonna go get that, cuz I can get it from JavaScript.

[00:00:17]
You can do it at local storage too. Machines, you're one cross-site scripting attack from someone being able to grab one if you store it in local storage. That's not saying don't use JWTs, it's saying don't put it in local storage. And you can't do HTTP only, right? And they are stored for a very long time coz local storage, the browser at one point gets angry with you and starts.

[00:00:39]
Jettisoning stuff, but generally speaking, it's been there for a very, very, very, very, very long time.
>> Steve Kinney: Session storage, other than the fact that it doesn't last as long and is tab specific, that seems cool. But it's still accessible by JavaScript. It's just less bad than the previous option.

[00:00:59]
But also, as soon as they close that tab, they have to log back in again, which might be fine. Story in the cookie is my favorite, except for that last one in the lower right corner, right? And this is where you have to start thinking about the other ones.

[00:01:11]
If you can do this one, do this one, I think I have a slide saying this is the right answer if I'm gonna say to you now and then, we'll see it again. Which is basically, you get all the things that we've talked about this entire time, right?

[00:01:22]
It's almost I was building up to something. Theoretically, if you don't configure the cookie, right? But we've been talking about this for hours, right? You use all the stuff we saw, and then basically, you get all the protections that come with cookies, and you get the statelessness that.

[00:01:40]
Yes, you can't revoke them as easily as you can with Session, so it's worth thinking about. And the only problem is that cookies are limited to somewhere between 4 kilobytes and 5 kilobytes in size, right? And you saw, depending on how much stuff you're loading into that cookie and how many – let's say you have multiple JWTs, or Jots, as the cool kids call them.

[00:02:01]
You could blow past that limit, right? So that's the reason why this might not work, but if you can get away with cookies, it's the right idea. And then there's not storing them. You can store them in memory, but as soon as someone leaves that page or reloads the page you're starting over again.

[00:02:21]
But that could be a feature or a bug, depending on how you think about it, right? Hey, they got this thing. They can do all these administrative actions if they navigated away from this page at all. We start over might be something worth considering cool. So I'm gonna say put them in cookies and make sure you do all the stuff that we talked about.

[00:02:40]
You can basically keep them very short lived that way. If they do get out, it's 15 minutes of pain instead of several days worth of pain. And then server side, you could just simply refresh them the same way we can do with cookies and give it a new value and update them.

[00:02:59]
And then I'll do all the stuff that we just talked about, right? I will show you the library. The problem was, hey, here's how you make a JWT, is that I will show you how to do an express, just by looking at the code, it's two lines of code.

[00:03:11]
It's gonna be a little bit different. The more conceptual part is, it is basically just a stateless, data-baseless way to prove identity through just unguessable numbers versus checking with a database. But you need to make sure I would say, until you feel comfortable with everything we talked about previously.

[00:03:32]
The risk is, if you lose these things, it's hard, you don't control the source of truth. Anything is easily decoded don't put it in there either. It's basically everything that we said. And so I'll show you just even there's a package, I think the sample code will give you the point.

[00:03:54]
But again, I care less about coz not everyone uses I don't use express in the back end. So I can't be and this is the best library, right? Because we have go microservices on the back end personally,
>> Steve Kinney: Cool, so this is a version of access, but again, I can't speak too much, because generally speaking, actually, let me just show you my notes.

[00:04:28]
>> Steve Kinney: This is in the repo too. This is a dumbly simple version to kinda make my point without going too far into the weeds, okay? So remember how we signed that cookie in the very beginning? We had a cookie secret. Same idea. I put an invariant environment variable like an adult this time.

[00:04:46]
And then you basically say, hey, the same way you said a cookie before. This probably has more properties than this, but this is the point. This is their username, this is everything you can do. And maybe you can get away with just this, I don't care. And you sign it with the secret.

[00:05:01]
And you say what algorithm you used, right? And now you can pass this thing around in an authorization header in a cookie or whatever.
>> Steve Kinney: This one's bad, don't do this one. Do this one down here. If you signed it originally with this algorithm, make sure you verify it with the same algorithm.

[00:05:19]
That's the only true mistake that you can make here. But basically you just say, verify with the same secret on the receiving end, which could be you. It could be they logged in. I minted the Jot, said it, I minted the JWT, sent it off, and it came back, and I'm just saying it again.

[00:05:36]
So that point, sharing the secret is super easy. It's just you, and you're just not storing the session anywhere. But basically it's about signing it and verifying it, but you need to make sure that you have the same secret and you are using the same algorithm, right? And that's kinda key for just transport mechanism and making sure that it works.

[00:05:56]
Again, there's trade-offs and unfortunately if there was a right answer, we would just do that all the time and I wouldn't have to show you two things. But I think given your architecture, you can make the call on this one. I have done the session thing for the longest time at my previous job, and now we just use these.

[00:06:16]
I think this is good, but we have to, right? Where architecture setup. So it was never, which one should we use? It was a backend team was, this is what we got, right? And we then needed to kinda pass around in our own applications. We'd use the same process for everything else as well.