Authentication & Authorization Strategies

[00:00:00]
>> Jem Young: Authentication versus authorization. This one I had to spend some time on too because mentally I was like, this doesn't make any sense, Jem. So I had to stare at it for a while. Different things, different things. Authentication: Who are you? When I log in with, when I log in my email, how does someone, how does the system know that that's me? Generally speaking, I have my email or username and then I have a password, and together those things are validated and so like, okay, Jem is who he says he is.

[00:00:32]
Authentication. Authorization is, maybe my subsequent requests, do I still have that permission? We already authenticated me, but how do I know that I'm still me? How do I know there's not someone in the middle who's taking my credentials? And that's authorization. What am I allowed to do that? Is the subsequent request allowed to do that? And they're two different things. It's really easy to get them mixed up because you can authenticate someone, trust them forever, but it turns out they left their computer open at the library or something like that, and now I don't know, you're, I don't know why you'd be on the bank at the library.

[00:01:08]
I don't know what people do, but yeah, maybe you left your app open and now anybody can use it. And we got around that, we talked about this yesterday, we log people out automatically. That's one way we guarantee they're not, we keep the authorization fresh. There's different ways of handling that, but there are different things. So authentication, several ways to do it. Username and password, most common.

[00:01:34]
You have multi-factor auth, biometrics, you have certificate where the client has a certificate and can only encrypt things. We have single sign-on, which is pretty helpful service. I think we missed, so there's like some novel ones, email login, but that's kind of a pain in the butt. I think that's the username and password. Oh yeah, that's it. I don't really like that one. I don't either. Oh, the passwordless.

[00:02:00]
Yeah, or what's the new one? Passkeys, yeah. Isn't that a lot more of an authorization concern rather than authentication? You can authenticate yourself with, well, I mean, I mean specifically like I think there's another layer to it that's called like OpenID Connect and that's the authentication. I think that's an implementation of OAuth that predated. Oof. Which made it weird. It is really complicated.

[00:02:30]
There's two versions too, and they're very different. Yeah, I'll say that's, I've never had to implement OAuth myself, so I don't have those horror stories, but I'm aware of them. I've heard it's a great user experience, terrible to implement. The authentication, it's going to depend, how much do you trust your user, how savvy are they? If you're in an enterprise environment, you probably want to have multi-factor authentication or OAuth or something like that.

[00:03:06]
Username password is probably the weakest of all of these, but also the most common. They really love SSO too. So if we, it's interesting, this is interesting, maybe thought exercise, if we have our authentication not at the load balancer or at the edge, we have it at the web server. Anybody run into this issue before? You remember the name for it? I just remember that different session IDs, if they're not what they call sticky session.

[00:03:42]
Cookies is the thing that comes to mind, but yeah. Yeah, sticky sessions. The idea of the whatever the authentication is, it maintains some sort of state that says this session is valid, the session is not. You could write that to another service, but generally you're not doing that, you're doing it on the service itself. But that does mean that state is not shared between servers. You could, but then you're making it really complicated.

[00:04:03]
But that does mean for every single session, for every single request from the client, it has to go to the same server every single time. That's called a sticky session. It's fine. You can, you have routing algorithms that can do that. It just says, hey, based on your session ID or some other parameter, you're always going to go to the server. Not a big deal. However, we talk about scaling up, scaling down, that's when it becomes a problem.

[00:04:32]
So we generally want to put authentication further at the edge, even though it's really tempting to let our web server do it. AWS has ALBs for load balancers that handle the session IDs anyway. A JSON web token is a pretty good way. You don't need to be, doesn't need to be sticky. It can be validated instantly on whatever that server is. Different levels of authorization. Does someone have the ability to access the thing they're accessing?

[00:04:56]
You're going to have a lot of databases. Should everybody have permission to go into all those databases? Maybe, maybe not. Do you have different tiers of users? Do you have an admin and you have regular users? Do you have paid users and not paid users? Every layer might have different authorization level on what they're allowed to do, and that's something you have to check every single time. We won't get into the weeds on that, but there's different strategies.

[00:05:20]
You can do role-based authentication, what's someone's role, and then we have blanket permissions across the board. You can have attributes. Hey, where's this person located? What kind of computer are they on, or something like that? Where are they in the network? You can have policy-based authentication, which is helpful in large regulatory environments. We have a blanket policy. You can access this, you can't access this.

[00:05:46]
We can turn it off and on, adjust those permissions at will. In all this, you have to think, what if someone, what if it turns out a bunch of user accounts were compromised? Hey, I just got hacked, I got phished. How do I turn that off quickly? Real, these are real problems. Depending on your authorization strategy, that can be really easy or really difficult. I mentioned JWT, JSON web token. Cool.

[00:06:09]
Takes a while to deauthenticate it though, versus something at session base, you just reach to that server, flip a switch, they're no longer authorized. But when someone gets in your system, and they might, you have to think, hey, what is my authorization identification strategy? If you have a refresh strategy with JWTs, then can you kind of at least limit the amount of time that would be valid for the auth token so that if you did, you can't like invalidate it really like you can a cookie or a session ID, but like you just have it sort of short-lived that potentially they'd only have, you know, 30 seconds to a couple minutes.

[00:06:58]
You could. What's the tradeoff you're making there though? With short-lived auth tokens. More resources it takes to, and your client has to reauth frequently, which gets a little annoying with refresh tokens. Yeah, adding a lot more resources to do for a relatively small but important edge case. Maybe that's important though. Yeah, depends. Revocable tokens are clutch, yeah. So when it comes to authentication, and this applies to almost all system design is, you know, which one's better for distributed systems?

[00:07:38]
We talked about this earlier. Stateless, yeah, stateless means we're not tied to a particular server, we can scale up, we can scale down. That server goes down, no big deal. We just automatically switch to the next one. However, stateful is a lot easier to implement. You know, you can invalidate a lot faster, and so it's really tempting to do it and it could be okay, depends on your use case. So we can have something based on a session, which is a session is some predetermined amount of time of when the person is, the client is live essentially based on that session.

[00:08:15]
Anybody ever use a session cookie? Familiar with the concept? And you close that browser tab, session goes away, session ends. Session-based is pretty fast. You can deauthenticate really quickly, and it's kind of logical too. You don't have to think a whole lot about like, hey, is this person valid or not? They close a tab or something, session's over, you have to reauthenticate. It is more stateful though.

[00:08:46]
We want to use token-based where we can. I asked if the web server shouldn't be doing this anyways. So we talked about JWT, JSON web tokens, pretty robust. That's going to be the go-to most of the time. So if someone ever asks in a sort of interview, what would you use for a token or authorization, you could say JWT. People be like, okay. There's also API keys. We've all used APIs. That's the thing too.

[00:09:14]
How do you revoke them quickly? Depends on your system. I get sort of the API key somewhere and then some associated ID with that. Cookies, we've all used cookies. We probably won't get too much into the authorization authentication generally, but it's good to keep in mind like all this stuff is going on around you, and we may offload it to be like, oh, that's handling authentication, cool, not important.

[00:09:41]
But we now recognize it is a thing you have to do, and it could be expensive, it could be not expensive, depends on the implementation. Maybe not the best summary for stateless architecture for security, but security's hard, but stateless architecture just makes it easy. I don't know why I put that with security, but that's a good lesson. Yes, for like, you're talking about distributed systems. If we get onto something like microservices, we typically use, you would have to use like stateless JWTs to authenticate between services, right, because, um, the event that somehow a bad actor got into your internal network, I don't know how that would happen, but without securing each service, then they would essentially be able to read, write, do whatever.

[00:10:37]
So is that a common practice to do? Yeah, it's, you know, two people that are super paranoid in the world of engineering: security engineers and SREs. Always paranoid. They have to be, it's their job. Security thinks, yeah, if someone got in, how far could they get? Especially in a microservice architecture. There's a few approaches to doing that. One, you could build a really giant wall around your internet.

[00:11:10]
You say no one's going to get past this, it's many layers to get past that. But once you are in, you can move around freely. The downside of that, and this is where most of the hacks come from, because someone will get in through, what's the social engineering, social engineering. It's always like one, it's like a user support base. Oh, I know Zendesk, yeah, yeah, not throwing shade on Zendesk, don't sue me, but you know, that's a really common one.

[00:11:39]
Hey, I'm Jem. I need to reset my password and the customer service for someone says like, cool, who are you? And like they read off some stolen credentials. Cool, alright, I reset your password, you're in. Boom. And now I'm in the entire service. There's no one stopping me. And the worst part is no one knows that either, because I'm just a regular user. But the upside of that is it makes it really easy to move around.

[00:12:05]
We don't have to think about, hey, I need to validate my request to this other microservice. It's much easier to program around that. The other one is you don't trust anyone. You need permission, explicit permissions to move around. That's a lot heavier, it's a lot more secure, but it's a pain in the butt to work with. If anybody ever worked in that sort of environment. So again, trade-offs. Everything's a trade-off.