Authentication with Google Cloud

[00:00:00]
>> Erik Reinert: Okay, so really quickly we're going to now go over to Google Cloud because we want to set up the credentials. We basically we want to get all of the like, you know, configuring and like credentials and all that stuff out of the way. So I'm going to quickly switch to my right account and then I'm going to go to cloud.google.com and then make sure you're logged in.

[00:00:25]
And then once you're logged in, click on Console. Console. Although I will say I don't, I don't know whose UI I hate worse, Amazon's or Google's. I can't stand material. Ui. Yeah, just to clarify, we're using GCP or Google Cloud for being able to log in with Google so that Google is handling authentication for our app, Correct?

[00:00:50]
Right. Yeah. So let's talk about that really quickly while you guys are getting there. Who here likes authentication and managing it? Anybody? No. Okay, cool. Yeah. So this is a whole other argument of like, do I go to here to manage my auth or do I roll my own auth?

[00:01:09]
Now let me say this. Rolling your own auth is really not that difficult. It's not. Most people overcomplicate it and worry about too many security parameters like, what happens to this? Dude just get it started. You'll figure out along the way what's the problem. But that was kind of the approach we took here, which was like, why rely on another service to roll off when you could just simply use something like GCP to create OAuth tokens and just call it a day.

[00:01:42]
That's why we're using gcp, because it's a very simple auth approach that is easy to set up and then we're just done. There's no need of a third party service or all this other stuff. It's literally just create some credentials, set them and then we're off to the races.

[00:02:03]
Once you're logged in and you're at this page, the next thing you're going to go to is API and services and then you're going to click on credentials. Now I already have it, it's right here, right? But what we're going to want to do is we're going to want to create credentials up at the top and then we're going to want to click OAuth Client ID.

[00:02:30]
Now you may not see this. How many of you do not see this when you click that? Okay, it may ask you for something called the OAuth consent screen, right? Yeah. Okay, so this is Very simple. You just have to do a couple of quick clicks. It's basically just next, next.

[00:02:51]
But you're just, you're basically just telling Google who you are. That's it. Because this is an actual application that they are validating on their platform. So they want to validate that you are in fact who you say you are for the application. So do me a favor. I can't see that again.

[00:03:07]
I only get to see it once per project, so I'd have to go to a completely new project to see that. But once you go through that process, you will get back to this page.
>> Male: Should we use the internal audience type so we don't have to submit our app for.

[00:03:20]
>> Erik Reinert: Yes. Yeah, yeah. So it asks you to like submit app or just use. I think it's external audience. Is that.
>> Male: Actually that option is disabled for me because it says because you're not a Google workspace user, you can only make your app available to external general audience.

[00:03:36]
>> Erik Reinert: Yes, yes, yes. Yeah, that's the option you want. Yeah, yeah, yeah. Basically what Google is saying is because Google doesn't have you as a organization in their accounts, you're just gonna use it like any other app using Google Credentials would use it. So it's just a normal third party thing.

[00:03:54]
So it may send you back to Overview. Just click on clients again and then Create Client and then bam. You should be able to be right where I am. So you just wanna make sure you're back on the create OAuth client ID page. Cool. Awesome, so we're gonna click Application type and we are going to click Web application.

[00:04:14]
You'll give it a name? I would give it the name normally. Okay, so really quickly, let's talk about service credentials. These are the things that aren't fun to talk about, but I feel like I should share them with you because these are the things that honestly can ruin a company.

[00:04:32]
And you might be like, why? What does that mean? How can you ruin a company, dude? I cannot tell you how many times I've heard some random oauth or keys were generated, somebody forgot about them, and now two years later they still exist because they didn't know and name it.

[00:04:48]
Right. And so now somebody's backdoored into our services because that got exploited and has now become available, right? This course isn't a security course [LAUGH] I'm not trying to necessarily teach you the best ways of doing security. However, two things about this that I want to point out.

[00:05:10]
One, if you're creating authentication credentials on third party services at all, try and scope it to the service that you're deploying. So for example, I would say FEM FD service, since that's the service that we're deploying. If I had another service, then I would go in, create credentials for that other service and then use those credentials.

[00:05:32]
Now you might be like, well, that sucks. I have to manage all these credentials. Yeah, but if one of them gets exploited, it's going to be a lot easier to deal with just one instead of every system that uses those credentials. So that's the main takeaway I want you to do, or I want you to have here is at least isolate well, so that if you get into a scenario where something bad happens, you can separate that without necessarily blowing up everything underneath it.

[00:05:58]
And I've been in that scenario too, where credentials were globally used. Like again today, we created the AWS user with the administrator star Star. If you guys don't remember to delete that and then that were to get out into the world, then okay, that's not good. So, yeah, be aware of these credentials that you're generating just so that you don't shoot yourself in the foot in the future.

[00:06:24]
Okay, so what we're going to do now is we're going to type in or down at the bottom, you're going to see authorized redirect URIs. Who here knows how OAuth works? How many of you don't know how OAuth works? Really quickly? Okay, okay. No, it's all good. It's all good.

[00:06:39]
To be fair, I don't know if I fully do. So we'll see if I can restate it. So OAuth is really about handshaking. That's the easiest way to put it. It's about saying like, okay, we're going to go somewhere, we're going to get validated, and then when we come back, we can now say that we've been validated and we can act upon that validation.

[00:07:00]
That's the easiest way to put it. What happens though, is that when you use something like OAuth, the provider needs to know that you are who you say you are. Say, for example, I set up a credentials, right, how does the provider know to send you back to where you were, right?

[00:07:21]
Because we redirect them to you or to the provider. So then how does the provider know how to get back, right? Because we've all done that. We've clicked OAuth, we click a button, it goes to something else and then somehow we end up back on the website. That is what the redirect URI is, and that's part of the OAuth flow, where in the specification OAuth says, well, hey, if we're going to do this, we need a URL of some sort to send the user back to that you confirm is your URL and then we can validate that and then you can get the request.

[00:07:55]
What happens underneath the hood is it becomes again this handshake handoff where the user logs in, they get sent over to the third party. The third party then generates the access key or a little token for that specific OAuth request. Then the user almost has a little bag now where it's like, okay, go back home.

[00:08:15]
And then they go back to your app with that secret or whatever. And then you take that and you validate it when you get to that webhook endpoint. So users actually go to an API before they get back to your page. So they'll hit an API endpoint, you'll get that data, you'll go, cool, I got the email, put it in the database.

[00:08:39]
And then nine times out of 10, what you won't see is the, the application will then redirect you to the front page or something like that. So you never see that callback URL. But that's basically how OAuth works is you ship them out to a third party, that third party says, well, I know the URL that I'm supposed to go to.

[00:08:58]
So now I'm gonna send them back with their little packet. And then once you get that packet and open it up, you should see their email and everything so that then you can authenticate them, create a session with that email, then send them back to the front page.

[00:09:13]
So yeah, there's still like programming is never simple, there's still work you have to do somewhere. But normally that whole process I just described is a lot easier than sending out emails. Sending out emails and transactionals is really annoying. So this is why developers, especially front end developers and stuff, are getting really, really hyped about OAuth is because you don't have to deal with email, you can just immediately get started.

[00:09:39]
And again, it's a validated endpoint that you don't have to worry about. Okay, cool, so we're going to go to authorize redirect URIs now that you guys understand that, and we are going to put in our local host callback URL. So I'm going to just go ahead and copy and paste it and then I'll let you guys write it in yours, but we're basically going to do HTTP localhost8080auth Google callback.

[00:10:10]
I don't think you need to click Add uri. I think it's already there. So I think we're good. So go ahead and type that in. I'll give you a second here. HTTP, not HTTPs. Yep [LAUGH] All right. Yep, we're going insecure for right now. I mean, again, it's local host.

[00:10:28]
Of course. Yeah. I mean, you could kind of think of local host as like an SSL in a way. Normally, nothing is gonna get on localhost unless your computer is hacked, so should be fine. But to go back to what I said earlier, and this is something we are going to do in this course, you will probably also want to create credentials per redirect, like URI if it's in different environments.

[00:10:55]
For example, this is dev token, right? Now, if I put this in prod, that does technically mean that I could use that localhost URL in the production environment because it's the same token, meaning that application expects it. Now, again, I'm not here to teach you security, but I have messed up enough to know where some of these problems can happen.

[00:11:21]
So normally what you would do is you would create a no oauth client for that environment with that specific URL. So again, in the future, if somebody tried to use that token or if they figured out a way to bypass the normal authorized redirect, they can't use that token in production and access things.

[00:11:40]
But for this, we're not going to worry about it. So I'm going to hit create and I'm going to dox myself, but I'm going to do it so that you guys can see it. And then I'm going to delete this and do this off screen. So you will get this.

[00:11:53]
Yeah, good luck chat. Try and get in as quick as you can. You will get this oauth client created, you'll get a client id, a client secret, and then you can even click Download JSON. I would recommend downloading that JSON, but at least copy the client ID and the client secret and like put it in a separate window or notepad or something.