It's now time to build some features for this project that are not just building CRUD and database tables and everything specific to this domain, but actually addressing features that our users might have or might have in the future. And one thing that really bothers me is when we require every user to create a new email and password or username and password for every single new service they sign up for, because I as a person don't want to have to do that all the time. So we can ask the question here of, are we just targeting programmers? And if so, can we just rely on GitHub authentication? Let's assume the answer for now is yes. So if that answer is yes and we're going to use GitHub, we've got Socialite, which is a first-party Laravel tool for social login. And the great thing about Socialite is it has, well, there's a lot of great things about it, but it also has built-in authentication layers for tools like Facebook, Twitter, LinkedIn, and ding, ding, ding, GitHub.

And the great thing about Socialite is it has, well, there's a lot of great things about it, but it also has built-in authentication layers for tools like Facebook, Twitter, LinkedIn, and ding, ding, ding, GitHub. Now, if we did want to access an authentication provider other than those that come out of the box, we can just Google Laravel Socialite providers. We'll find socialiteproviders.com, which gives you access to a huge list of providers outside of the first-party ones that are provided. But since we're working with GitHub, we don't even have to worry about that. The docs for Socialite are really good. We're going to run composer require laravel/socialite. And then we are going to add some configuration items. It's going to tell us right here we've got a config/services.php,

And then we are going to add some configuration items. It's going to tell us right here we've got a config/services.php, and that's where we're going to use the specific keys that Socialite is going to look for. We can see we're looking for the GitHub key because that's the provider we're using. And even better, GitHub is the example that they give, which makes life easy for us. So config/services.php. We're just going to add a new one for GitHub. And as you can see, by default, it's assuming that we're going to have these two environment variables. So we're going to want to add GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET to our .env.example file. And also to our actual .env file, which unfortunately doesn't always load.

So we're going to want to add GitHub client ID and GitHub client secret to our .env.example file. And also to our actual .env file, which unfortunately doesn't always load. Don't know why. Somebody knows they can tell me why. There we go. And then this redirect can either be a fully qualified URL like this, or it can be a relative URL, in which case Socialite will fix that for you. So we can just say /auth/callback, which is the most common redirect URL. So the way things work with Socialite is you have two routes. The first route is the one where if the user visits it, it's going to then redirect them away to the authenticating application like GitHub or Facebook or whatever else.

The first route is the one where if the user visits it, it's going to then redirect them away to the authenticating application like GitHub or Facebook or whatever else with a specific qualified URL that says once they log in, send them back over here. Once they log in, it sends them back to the second URL on our side, the second route. And that is what's going to be what receives basically the webhook showing all their authentication information. The great news is the documentation makes it super clear how to set those up. You can see in the routing section right here, you got your two routes, the first one that sends you away and the second one that receives you back. So let's grab those really quickly. Put them in our routes file.

So let's grab those really quickly. Put them in our routes file. Now we could put them in auth.php. We're going to at some point have to decide, are we going to have both GitHub login and a traditional login or GitHub only? I would say if you're only targeting developers, GitHub only is great. Symposium, the original Symposium targets developers, but we wanted it to work for non-developers, so we actually kept both going. So that's going to be up to you. So you paste this in here. We bring in Socialite. And it's defining our two paths, auth/redirect and auth/callback. So again, if a User is visiting this particular URL, it sends them away and then it sends them back here,

And it's defining our two paths, auth/redirect and auth/callback. So again, if a user is visiting this particular URL, it sends them away and then it sends them back here, at which point we can pull some information from the response that we get back from that provider. Now let's pause for a second and figure out where we're getting those GitHub credentials from. When you do social login like this, you're working with creating an OAuth application at some third-party provider, Facebook, GitHub, Google, whatever else. And that OAuth application is basically representing to them our app in their system. So I would go to them and I would say, hey, GitHub, I'm interested in creating an app called Symposium, and I want it to be able to connect to your tool using OAuth. So I want to create an entry in your tool for my app.

and I want it to be able to connect to your tool using OAuth. So I want to create an entry in your tool for my app. And that tool will be where I set up settings. For example, what's the logo that you should show when someone's trying to decide if they authenticate with me? What is the text you should show or the website or the callback URL? And so what we want to do is we want to go into GitHub and we want to set up an actual app for Symposium there. Now, if you're not familiar, I maintain a website called consoles.dev. And if you just go there, it'll let you click through to the developer consoles behind lots of different tools, including GitHub. Or you can just memorize that there's specific short strings for them, consoles.dev slash GitHub. For some of those tools, it just takes you to general admin console.

Or you can just memorize that there's specific short strings for them, consoles.dev slash GitHub. For some of those tools, it just takes you to general admin console. But as much as possible, I wanted to take you to the OAuth console because sometimes those are very hard to find. So here we're going to say new OAuth app. We're going to name this app Symposium for Laracasts. You can see I did this before and made a mistake. So we get this autocomplete. The homepage is going to be symposiumapp.com. Application description is going to be Symposium. For a Laracasts course.

Application description is going to be Symposium. For a layer casts course. Callback URL. So in some tools, it will allow you to just use the callback URL that you have defined in your config/services.php. Some tools override that with whatever you put here. And I believe GitHub actually cares about the specific one being correct. So you can't just put the live one here. And then we say register application. Oops. And then you say register application.

Oops. And then you say register application. And you've got a client ID now. And you can generate as many secrets as you want. So we're going to generate a secret right now. This is going to be our primary secret. And there we go. Our app is now going to be authenticated correctly. So we'd like to test it out, but we actually don't have a button for it. Now, if you want to work like the live Symposium app does, you've got to sign in with an email or sign in with a GitHub button.

So we'd like to test it out, but we actually don't have a button for it. Now, if you want to work like the live Symposium app does, you've got to sign in with an email or sign in with GitHub button. A lot of apps don't even worry about that. They're just going to do GitHub only. And I love doing GitHub only. The downside of doing GitHub only is if you have a non-technical audience or a partially non-technical audience like Symposium does, then they're stuck. They have to go sign up for GitHub just to use your app. And so what we did there was allow them to have both. But obviously, GitHub is easier, especially if you don't want to create a new user account. So let's go to our Login view right above our Login button.

But obviously, GitHub is easier, especially if you don't want to create a new user account. So let's go to our Login view right above our Login button. Well, right before, we're just going to say /auth/redirect. Log in with GitHub. It's going to be ugly. We're just trying to get the functionality working here. So there you go. Log in with GitHub. And it takes us over to Authorize Symposium for Laracast. And if we had uploaded a logo, it'd be showing it there.

And it takes us over to Authorize Symposium for Laracast. And if we had uploaded a logo, it'd be showing it there. It's saying, you know, who sets it up, and you could ask more information about it. And we're going to say, yes, authorize Matt Stauffer, which will redirect to symposium.test. But first, what happens when we authorize? Well, right now, it just gets the user and doesn't do anything. The tutorial in the documentation shows us some more things to do. But before we do that, let's just take a look together to see what do we actually get back there. So we get an actual Laravel Socialite user object. And we've got some clearly accessible properties here.

So we get an actual Laravel Socialite user object. And we've got some clearly accessible properties here. There's all this useful information. But for example, we got avatar. That's my actual very old avatar. And if you expand down to the User, you can get a lot more information. If you refresh that page, it's going to say, we can't do this because you're only allowed to use that authentication callback once. So we would have to go to Auth::redirect again. And now we're called back to this page where nothing is happening. So let's go back to the documentation, which walks us a little bit through the most common workflow,

And now we're called back to this page where nothing is happening. So let's go back to the documentation, which walks us a little bit through the most common workflow, which is once you get that User back, you then say either create a new User for that or update the existing User with the primary lookup not being their email address because they could have changed their email address, but instead the primary lookup being their GitHub ID. So we're just going to grab this directly. So again, we grab that GitHub user ID. We grab the name, we grab the email, token, and the refresh token. For now, we're saying either create or update an existing User in our database table based on the information we get back from Socialite.

For now, we're saying either create or update an existing User in our database table based on the information we get back from Socialite. And then log them in. And then redirect to the dashboard. That's a pretty reasonable way to do social login only. So let's test it to make sure it worked. Again, if we refresh this page, we should get an error. Yep, that's totally fine. You might want to handle that particular error so that people, if they have that error, don't get an error page, but instead get redirected back to the login page or something.

You might want to handle that particular error so that people, if they have that error, don't get an error page, but instead get redirected back to the login page or something. And this is now a point where we see that our database expects User to have a password. So we can modify our database tables to require that. As always, we can either create a new migration, or if we haven't pushed this up to staging, we don't even need to worry about that. We can just modify our create_users_table. We can make our password nullable. While we're at it, we should be adding our GitHub fields. So we've got token and refresh_token.

While we're at it, we should be adding our GitHub fields. So we've got token and refreshToken. And of course, we need to add those to our $fillable on the User model too. And then we can migrate fresh seeds. We redirect. And of course, we have a unique constraint failing because we've already seeded that User, but that User is trying to create a new one. So if you do end up doing what we did in Symposium, which is allow you to do both a traditional login and a Socialite login, you have to update this code that comes from the documentation to say,

which is allow you to do both a traditional login and a socialite login, you have to update this code that comes from the documentation to say, well, what if this is a User that previously had only authenticated through email and now is authenticating through socialite? Because that's not the most common use case, the most common use case is that you're just going to do socialite and that's it. We're not even going to worry about that, and we're just going to go to our database seeder and drop that User for now. So now that User shouldn't exist. So when we redirect, it should say, great, I just created a new User for you.

So now that User shouldn't exist. So when we redirect, it should say, great, I just created a new User for you. And if we go to our database, we should see two users, which is the one that we seeded, and then this one right here, which came in from our GitHub connection. So that's the basics of social auth, but let's say we wanted to pull a little bit more information from GitHub other than just who you are, your email, your password. Well, there are all those other fields we have accessible to us. So let's say, for example, we wanted to pull your profile picture.

Well, there are all those other fields we have accessible to us. So let's say, for example, we wanted to pull your profilePicture. We don't actually have that as a concept right now, but if we did, when a User comes in every single time, we can make sure that we're updating their avatar. So we can say, let's say we had a avatarUrl. We'd say GitHubUserAvatar. And there you go, a common user requested feature, which is social login. In this particular case, we did GitHub,

which is social login. In this particular case, we did GitHub, but we could also have done Google or Twitter or Facebook or actually multiple options. You can have buttons for a few different ones. You just got to have a different redirect URL for each. And it was a few lines of code. Instantly, User is able not only to log in with GitHub, but it will constantly update their information from GitHub every single time they log in.

but it will constantly update their information from GitHub every single time they log in. And we can even pull in other information outside of just their login information, for example, their avatar and much more. See you in the next one. Thank you.