![]() ![]() ![]() They'll actually just carry a token that we need to send back to Google to get the profile information we're looking for. But if you remember from last week, our user won't return with their Google profile information in hand. Once they sign in, we want to Google to redirect them back to our site. When the user goes to our login route, whether that be a button or a link, we want to send them to Google so they can sign in. ![]() So let's quickly review what we want to happen: That would get old pretty quickly right? We'll use cookies to avoid that. And while that might not seem like a big deal, imagine having to log in every time you visit any website or application. Plus, we'll need to use another service that gives our user's browser some information that ensures that our application will remember them the next time they visit. We'll create the routes we need to handle the authentication process with Express. Last week, we did a deep dive into Passport's Google Strategy and the callback function we have to give it to store that user in our application's database or retrieve that user's information if they're already in our database. In the first part of this series, we went over how to get your Google credentials for OAuth as well as how to set up the basics for your development environment. Alright folks, here it is: our third and final post detailing how we can use Google's OAuth API with Passport to give our users the ability to login as well as authenticate those users on behalf our applications behalf. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |