
Lesson Description
The "Token Authentication & OAuth 2.0" Lesson is part of the full, Complete Go for Professional Developers course featured in this preview video. Here's what you'd learn in this lesson:
Melkey describes three authentication strategies: OAuth 2.0, Stateless, and Stateful. OAuth 2.0 leverages a third-party authentication provider like Google or GitHub. Stateless and Stateful token authentication use hashed tokens. Stateless relies on a client-side JWT. Stateful stores the authentication token on the server.
Transcript from the "Token Authentication & OAuth 2.0" Lesson
[00:00:00]
>> Melkey: Yeah, okay, moving on, so this gives us the ability to create users, now, let's talk about authentication. Okay, I'm gonna switch over to here. So I'm gonna briefly talk about this, there's different types auth methods, right? I'm sure most of us, if you've used auth before, you know that typically you have used one of these three.
[00:00:28]
And the three that I could think of, and I'm sure they're probably more, but the main three that I'm aware of is stateful token authentication, stateless token authentication and an OAuth 2.0, all right? I'm going to briefly give you an overview of all three, and I'm going to tell you which one we're going to use.
[00:00:45]
OAuth 2.0 I'm sure we're very familiar with this, it's whenever you use an application, and it gives you the prompt to sign in with Google, sign in with GitHub, sign with X, Y, Z, you can sign in with this. TLDR is using a third party provider like Google, GitHub, to basically store and validate who you are.
[00:01:04]
If you have a Google account and they know that you're legit, if GitHub knows you're legit, we can use that logic, that kind of ramp to also validate if you're legit for our application, right? If you're good enough for Google and GitHub, maybe a good enough for us, that's kind of how I like to view it.
[00:01:22]
There is a lot of really good pros to this, essentially Google and GitHub, they store everything rather in your system. You have to store their password, you have to store all these other information. You may store things related to their user profile on your site, but in terms of like things that could go pretty nasty, like passwords, gonna leave that to them.
[00:01:43]
There is this possibility that you may be storing a token, right? So typically when you get a redirect from Google or Github or whatever third-party identity provider, it's like, hey, here is this token, it is a temporary token. It has a short lifespan, which you then can basically handshake to get a longer term token with the identity provider.
[00:02:05]
And then how you handle the token tool up to you can store in your database, you can store in a client that's how you authenticate a user with OAuth 2.0. Super fast implement lots of libraries that does it, lots of Pros, some cons is like you obviously don't have access to their data, and you don't really have the full scope of the user.
[00:02:29]
And also, you're dependent on a third party. If Google goes down and your only way of authenticating is through OAuth 2.0 point using Google, you're kind of out of luck, right? So pros and cons, so stateless token auth is something we are all familiar with, this is JSON web token or a JWT pronounced.
[00:02:46]
And here, this is where everything is essentially encoded into a token, that is basically encrypted into three parts. A JWT has the hashing algorithm that's used to create the JWT, it has the signing signature of who created and issued that JWT, and then it has information that you choose to encode into the JWT itself.
[00:03:08]
This is typically stored on client side, like in memory so on, like a cookie or local storage. You'd get a JWT, store it there and you use it to authenticate, and this is great, right? It's typically done in memory. All the information is kind of contained within the token itself.
[00:03:26]
And a really good pro is that you don't need to perform an additional database lookup to really authenticate who that user is, because that will be typically stored on the token itself. Now there are some cons to this, such as, once you issue the JWT, you can't revoke it.
[00:03:45]
You have to change the signing method of what you use to sign that JWT, right? JWT, JWTs typically have like, expiry of 24 hours, but let's say you issue it and then you get a call that says, hey, my account was hacked, it logged in. What do you do now?
[00:03:59]
You have to change the signing method, of your system because you can't retract that JWT at all. Once it's out in the system, all you can do is when you when it comes back as a request, say that that signature is no longer valid, because we've revoked that or we changed the signature, okay?
[00:04:15]
That's gonna affect all the JWT on your system in case you do it in a pretty creative and intense way. Another thing, common with JWTs is if you store the wrong info on them, they could be pretty easily hacked. Anything on the client side like cookies, local storage, it's fairly safe but nowadays, like a lot of things are getting hacked, a lot of people are getting really smart.
[00:04:37]
Again, I hate to use the example of LLMs, but they're tools to be used to do this kind of stuff, right? So you typically want to encode the JWT with like superficial information, never store the password or anything important in a JWT, right? And then the last one is stateful token auth, okay?
[00:04:57]
And this one is the hash, the token is actually stored server side in a database with a user ID and expiry field, these tokens, think of it as just a different table in our database. It's gonna have a token table, that's gonna have who it belongs to the scope of it, when it expires and how can we use it, right?
[00:05:17]
The real good pro about this is our back end maintains control over the token throughout the entirety of the token. So we issued that token, the users can use it, but if we detect they're a bad user, we can easily just nuke that thing, from one call in our database, that thing's gone.
[00:05:33]
We don't change any signing methods, we don't do anything like that, just that thing's gone, that's it, we clean our hand out of it, right? Because we have control of it in terms of our database. The con to that is, that requires an additional database call. You have to check the integrity of that token through this new tokens table, which hence token handler which double hence token data store.
[00:05:56]
And I wrote this little snippet I don't know why I probably feel a little zesty, I guess. But even with a JWT, you probably would be doing additional database call to pull additional info even with a JWT, so I mean, is it truly a con? We can debate that, it does take a bit more time to set up, so you can just use the library like JSON or whatever and use it.
[00:06:21]
You actually have to do a little bit of setup, so we're gonna be using this one. We're gonna be using stateful token auth, it's rolling your own auth, some would say. I think that really blew up in 2023, if you have a strong opinion on it, obviously, I understand it and acknowledge it, I do think that was really blown out of proportion.
[00:06:46]
If you're not creating the own hashing algorithm, I think you should be okay if you use a shot 256, that's already made by computer science theorists, I think you are okay to handle token authentication yourself. So with that, that's what we're going to be exploring.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops