AdonisJS In 30 #9.0

How To Add Social Authentication with AdonisJS Ally & Google

In This Lesson

We'll learn how we can use AdonisJS Ally to add social authentication to our applications. We'll use Google for our demonstration, but this same process also applies to GitHub, Facebook, Discord, LinkedIn, Twitter, & more

Created by: @tomgobich
Published: 1 year ago

Chapters

00:00 - Creating Our AdonisJS 6 Project
00:51 - Installing & Configuring the AdonisJS Ally Package
01:50 - Understanding the Social Authentication Flow
03:56 - Creating the Social Auth Controller & Routes
05:08 - Redirecting to Google for Social Authentication
05:36 - Handling the Google Callback with the User's Details
05:55 - Checking for Social Authentication Errors
07:55 - Finding or Creating A User Record
13:26 - Logging In the User
13:45 - Displaying Errors & Our Login/Register with Google Form
14:56 - Specifying our Callback URL for Google
16:38 - Database Environment Variables
17:05 - Entering the Google Cloud Console
18:00 - Creating Our Google OAuth Consent Screen
20:45 - Creating Our OAuth 2.0 Google Client ID & Secret
22:20 - Migrating Our Database
22:44 - Testing Our Social Authentication Flow with Google
24:20 - Adding A Logout Form
25:06 - Final Seamless Flow Example

Join the Discussion 0 comments

Be the first to comment!

Transcript

to call this social auth ally example. We'll create a brand new project here together so that we know that we're starting at the exact same point as one another. Let's go ahead and enter there.
For this demonstration, we're going to make use of EdgeJS very slightly just to show our login with Google button. So let's go ahead and start with the web starter kit there, and we're going to use the session
authentication guard as well as Postgres SQL for our database. Now feel free to use whatever database driver it is that you use on your personal machine. I have Postgres set up online, so that's what I'm using here today.
While this is installing our dependencies, we can go ahead and open up Visual Studio Code open folder and get this project opened up. Okay, here we go.
By now, if we jump back into our terminal, everything should be good to go. Let's cd into our social auth ally example project, and we can clear out our terminal.
We'll do node ace add at AdonisJS slash ally to both install and configure the AdonisJS ally package inside of our project.
Now during the configuration step, it's going to ask us which providers we plan on using, and this is a multi-select, so you can select as many as you actually plan on using inside of your application.
For the most part, so long as you don't need any extensive user details, Ally is going to keep all of these different drivers consistent in its implementation. So today we're just going to go through how to approach this with Google, and you should
be able to fill in the rest on your own. So I'll select Google here, and we can move forward with that. This has now added in an Ally configuration, it's updated our AdonisRC.ts file, as well
as our environment variable expectations. So if we now jump into our project, take a look at those new environment variables. What it's expecting is a Google client ID and secret.
These are the environment variables Ally is going to use to authorize a request with Google. But right now we're going to leave these blank and we'll circle back after we've filled out all of our code necessary to implement AdonisJS Ally.
Now the very first question you may have about this process is what's the code flow that we're going to end up implementing here today in terms with authorizing against Google
and getting the user's details back as well as authenticating that user? Well as noted, we added in session authentication inside of our project, and we do actually need to make use of it inside of this flow.
So there's going to be two things that we're interfacing with. First there is a Google side, so we'll put that in a box of its own.
And then there is our AdonisJS application, so we'll have that in a box of its own there. When users click on their login with Google button, we're going to redirect them over to Google.
So this is our redirect step. Google will then ask the user to log in with their Google credentials if they are not already logged in.
If they are logged in, then it will simply ask them to authorize our application to access the user's Google account information.
So this may have a login step and then there's also an authorization step there as well that happens outside of our application.
Once the user has logged into their Google account and authorized our application to
access their Google user information, Google will send the user back to our AdonisJS application
via a callback URL that we've defined both in our AdonisJS application as well as our Google's configuration.
And that callback URL must match between the two in order for things to work. Once we get back into our AdonisJS application, that's where we'll need to discern whether
or not the user is registering or logging in. If they're registering, then we need to create a brand new AdonisJS user record for that
user using the Google information that's been provided to us via that callback. Otherwise, we can use that same user information to just log the user in if they already have
a user account inside of our application. And it's for this login and registration step that we're going to be using our session authentication with.
So even though the two login steps between our AdonisJS and Google application are separate and the only thing being shared between these two is the user's information, this whole
process as we'll see at the end of this lesson is going to be a seamless experience for our user. So let's first jump back into our terminal real quick and let's get a controller set up.
So node ace make controller, and we'll call this our social auth controller, and I'm going to do hyphen s there to keep it social auth rather than social auth.
And let's add in a redirect and a callback method inside of this controller. Clear that out and jump back into our text editor. We'll start by jumping into our routes file.
And for this flow, we'll need two routes. So we'll have a router dot post to Google slash redirect and use our social auth controller and its redirect method.
We'll also give this a name of as Google redirect. Then we'll also have a router dot get pointing to Google slash callback that will again use
our social auth controller, its callback method, and we can give it a name of Google dot callback. Now, if you're using multiple social providers and not just using Google, you can also use
a route parameter in place of the hard coded Google. So we could call this our provider that would then pass in whether or not we're using Google,
LinkedIn, discord, or whatever social provider it is that you're using there. Then anywhere that we hard code Google throughout this flow, you would instead make reference to this social provider route parameter instead.
To keep things straightforward though, I am going to hard code Google here. Okay, let's next command click into our social auth controller for our redirect.
We'll want to grab Ally out of our HTTP context.
Using Ally, we want to await Ally and then use our Google provider to redirect our user out to Google.
This will temporarily take the user outside of our application to go log in with Google as we referenced here in our flow. This is the redirect portion that initiates this whole flow to allow the user to log in
with Google itself. Then once they've logged in or canceled the process in any way, Google will send the user back to the callback URL that we've defined, which is going to be handled by our callback
method here. So for this, we're going to want our response, session, auth, and Ally. Let's grab reference to our social provider by setting that equal to Ally, and then just
using the active provider for the request. And there's three validations that we need to do to ensure that everything worked properly. First, we need to check whether or not access was denied, and we can do that using the method
access denied off of our social provider. When this happens, we can just send a flash message with a key of an error and a value
of access was denied, and then return the user back to where they initiated this request. For us, we're just going to do this with our homepage.
But for you, this is most likely going to be a login or register page. The next is checking for a state mismatch.
So we'll do searchable.stateMismatch and call that very similarly to how we're calling our access denied.
Again, we want to session flash and redirect the user if the state is indeed mismatched. When that's the case, we can say request expired, please try again.
And then there's one more, and that's just a general errors that may occur throughout the process. We can check that by calling hasError.
And if that returns back truthy in any way, then something went wrong with the process. It wasn't an access issue and it wasn't a state mismatch issue, but it was something else.
So we can try to get what that error was via social getError. And this is optionally going to be provided.
So we can provide a fallback for that if it's nullish to an unexpected error occurred. And then again, redirect the user back to wherever it was that they initiated the request.
So access is going to be denied if the user tells Google, no, I don't want to authorize this request or no, I don't want to provide authorization to this application to access
my user. That's when we're going to get an access denied error. Our state mismatch is going to happen when communication between our AdonisJS app and Google is expired.
AdonisJS is going to initiate that redirect with a CSRF token, and that token needs to match up between our AdonisJS app and Google.
Otherwise we'll get that state mismatch error. And then of course we just have the general hasError down here if anything else throughout the process runs into an issue.
So that's our validation checks to ensure everything worked correctly. With that set, we now need to determine whether or not we're registering a brand new user or logging in a preexisting user.
So we can access the Google user via await, we can reach for our social provider and call the user method.
Then we can make use of AdonisJS's firstOrCreate to get back our applications user, which we'll just call user here. So we can import our user model and call firstOrCreate.
This takes in two payloads. The first is the search payload. These are keys that we actually want to search for the user with. And then the second is the store payload, which is what's actually used to store a brand
new user. And the search and store payload are merged if we are indeed storing a brand new record as well. So in order to search, we have a couple of options.
First, we could try and search via email and then use the Google users email.
And then in terms of our save payload, we could say the full name is from our googleuser.name.
And I believe name falls back to nickname automatically inside of AdonisJS Ally. But just for safety sake, because it doesn't take much for us to do this as well, we can
go ahead and fall back to nickname if a name is not provided there too. So let's give that a save for right now so that it formats.
The reason I don't like this approach is because emails are prone to change. If the user changes what their Google email is inside of their Google account, the next
time that they come to log into our application, this email won't match what we've saved inside of our database for the user.
And then this flow will end up registering them as a brand new user rather than logging them into their pre-existing account. In addition to this, some social providers may not provide an email at all.
Google creates an email with every one of their accounts via Gmail. So we don't really have to worry about that with Google itself, but you may with other social providers.
So what I like to do instead of using email for this is to use the actual social provider user ID to perform this search for a user inside of our database.
So let's start by jumping into our create user migration and let's add in a table string and let's call this our Google ID.
And I would recommend keeping all of your social provider IDs inside of separate columns so that they don't end up colliding with one another.
We want this to be nullable with the assumption that you're also going to add an email and password authentication to your application. And then since the Google ID is separate and specific to Google, we can also go ahead and
make this unique inside of our database to ensure that none of our users collide with one another. Additionally, if a user signs up with Google inside of our application, they're not going to be setting a password. So for that, we have two options.
We can either make this nullable or we can generate out a fake password for the user whenever they register. For me, I like making this nullable as if we were to add in an email password login
flow. Password would be required in that. So there's no way for any user to mock up a null password to get access to an email.
And then from here, you can also store whatever additional information about the user you want from that social provider. So you could say store in their Google email here, and I could set that to nullable as well.
And you also have access to an access token and a refresh token as well. If you need to make requests out to Google on user's behalf.
If you don't, I would recommend not storing that information as it could potentially leak access to their account if your database is ever compromised. So we'll leave them out here today.
And if you do store them, you can take an additional security step by encrypting them inside of your database as well. Okay. So our migration here is done and we currently have it set up in a way where we would allow
email and password authentication and or Google authentication. Next let's jump into our app models in our user model and add these two new columns in.
We could do at column, declare Google ID, we've set that as a type of string, but it could also be null. And we've also set our password now to be nullable as well.
So we'll update that to null or string too. And then we have one more column, which is our Google email, a string or null. Okay. Back to our social auth controller now.
Let's replace our email search with a Google ID search. Now using the Google user's ID value.
In addition to that, we can fill out the email as the googleuser.email, and then we can fill in the Google email with that same googleuser.email value too.
These two emails will be synced whenever the user first creates their account, but we can keep them separate because if the user changes their Google email, that's not indicative
that they'll want to change their email inside of our application as well, but that's up to you completely on how you want to handle that. So that should be all that we need there is this first or create call.
It will either find a user and return that user back using the Google ID value, or it will create a user by merging that Google ID with our store payload consisting of our
full name, email, and Google email. Now let's say very briefly that you were going to store the Google access and refresh token. You can get access to that via the googleuser.token.
And inside of here is the expires at, expires in, granted scopes, the token's ID, refresh, the token itself, and the type of token.
So the access token would be googleuser.token.token. And then the Google refresh token would be that googleuser.token.refresh token that we saw there.
And I would also encourage you to go ahead and just import encryption from at AdonisJS core services encryption and encrypt those values whenever you're storing them.
You can also set this up as a model hook as well. So just encryption.encrypt. And then conversely, there is an encryption.decrypt for whenever you need to make use of those
values that would end up looking something like this. We're not storing those here in this example, so I'm just going to go ahead and omit that altogether. Okay.
Now that we have our user, all that's left is to log them in. So we can await, auth, use, web, and log that new user or existing user that we've now fetched
into our application and then return, response, redirect to our homepage or wherever you need the user to go from there. That leaves us now with our homepage.
So let's jump into there and let's just get rid of everything that's inside of the body currently. So let's scroll down to the bottom of our document here and just delete that out.
Okay. Now, this default welcome page is using the TailwindCSS CDN, so we do have access to Tailwind here.
So we can do at if, check our flash messages to see whether or not we have an error from our social authentication flow.
If we do, we can display a div with a class, text read 500, and then just display that flash message error, just like so.
Then we want to check and see whether or not we have an authenticated user. So we can do at if await auth.check, as our homepage here is not authentication guarded.
So we need to attempt to load that user in if once found else, and then just end our if down there. If auth check found a user, we can display their details via auth user, and then we can
just display the full name. Otherwise, if we did not find a user, then we want to have a form method post with an
action set going to our Google redirect route, and we're doing this as a post so that we can make use of CSRF protection there.
And we can have a button of type submit login registered with Google. One more thing to take care of here inside of our code, and that's jumping into our config and the ally config.
This is where we define that callback URL that Google should send the user back to inside of our AdonisJS application.
And this would look something like HTTP semicolon slash slash localhost 3333 slash Google slash callback as its final value.
This localhost 3333 is going to change depending on what environment we're currently in. If we're on localhost, then it would obviously be what we're seeing here.
But out on production, it's going to be whatever your domain is for your application. So a great place to plop that value is inside of our environment variable.
So we jump into our dot EMV above our app key. Let's add in an app URL, set this to HTTP semicolon slash slash, and then we can use
the host value from this environment variable file as well as the port value to build out this application URL.
So this dollar sign port is just going to inject in the port environment variable there and the dollar sign host will do the same with host.
Then we'll jump into our start EMV.ts and we can add in a validation for this as well as app URL EMV schema string.
And due to the way that we're defining this on our localhost, we don't want to add in a string format for this as URL or anything. We'll just leave it as string.
So with that said, we can jump back into our ally config, switch our strings to backticks, and in place of our localhost 3333, we can instead use our EMV, call the get method,
and reach for our app URL value to build that out. Now the URL portion will be dynamic depending on what environment we're in, so we don't need
to worry about changing out this config in any way between development and production. Then we need to finish filling out our dot EMV file.
For this, we first need to start with our database credentials. So the user for me is Postgres, that's where it is password, and then I'm going to make use of a pre-existing database I have called test.
It already has data in it. I'm just going to truncate that out whenever we run our migrations. You're going to most likely want to use node-ace-migration-run.
I'll use node-ace-migration-fresh so that it wipes this test database I have clean and then just migrates onward from there. Before we do that though, we need to finish filling out our environment variables with
our Google client ID and secret values. So we need to jump into our browser for this. Should be able to search for something like console, Google, and I think it filled out
for me there in the URL, but we'll Google it here just to make sure that we have the right one, console.cloud.google.com.
This will take you into your Google Cloud console and looks like my test from this is scheduled for shutting down, so I'll go ahead and just cancel out of that.
You'll either be dropped in whatever last project it was that you were working in inside of Google Cloud or no project at all since mine was scheduled for deletion.
We'll just jump into here, hit new project, and we'll call this ally-social-auth-example and go ahead and hit create. Once that's done, it should drop you into that newly created project, which you can
confirm by looking at the dropdown right up here. If it didn't, just click on that dropdown and switch to it by clicking on whatever that project name is.
Okay, let's click on the hamburger menu over here, go into API services, and then you should see this OAuth consent screen option. We want to jump into there first.
If you're building out an internal application only people inside of your organization are going to use, you'd use internal there.
If you're building an application similar to Adocastss where anybody and everybody can log in with Google, then you would want to select external as the user type here.
So select the applicable one for your application there and then hit create. I'm going to note that this may change in the future because they're warning me right
here that they will have a new experience soon, but the general flow here should remain the same. So we have our app name, call this Ally Social Auth Example.
They're going to require me to use an email that I have set up with whatever I'm logged in with. So I'll set that as my user support email.
You can add in an app logo, but I do believe adding an app logo here requires you to go through an actual manual verification process. So we will skip on that.
And then you have app domain options that you can set here consisting of your homepage, privacy policy, and terms of service. We're just on local host, so we're not going to have any of that here today.
And then we also have our authorized domains and then the developer email here that's required. So I'm just going to fill in the exact same one I added above.
In terms of our authorized domains, we can leave that blank for right now. We'll be able to add in our local host whenever we get to creating our token.
So we'll hit save and continue here for now, which will take us into scopes. If you have any additional scopeful information that you need to get from Google on behalf
of your user, this is where you would want to request that information. Again, that may make you go through a manual review process depending on what those scopes are. We're going to skip all of that here today.
And then we come into our test users. As we're creating our OAuth consent screen right now, it's been created inside of a test mode.
And this means that only users that we add specifically inside of this test users field are going to be able to register or sign in to our application using Google.
And this is also capped at 100. So anybody that you want to be able to test with on your local host while your OAuth consent screen is in test mode, you'll want to add user emails for here.
So again, I'm just going to stick with the same email I've been rolling with so far. Just add that in. And there we go. Hit save and continue.
And it's telling me the following email addresses are either not associated with a Google account or the account is not eligible for designated as a test user. I believe it's the latter there for me because this is also the owner of this application.
So it would make sense that that would already be a valid test case. So I think that's all that that meant there.
And it should drop us now into a summary where we should be able to just hit back to dashboard. It's at this dashboard where you see this publish app option.
This is where you go from that testing phase into an actual OAuth consent screen you can use in production. So whenever you're done with everything, you want to make sure that you publish your application
here before deploying out your application with Google login abilities. So we're now done with our OAuth consent screen.
Let's next jump into our credentials and we need to create an OAuth 2.0 client ID that we add into our AdonisJS environment variable.
So we'll click on Create Credentials right up here and create an OAuth client ID credential. We need to select our application type.
We are working with a web application, so we'll select on that one. We can give it a name. I'll stick with the same old Ally Social Auth example.
And then it's going to ask us to fill in our authorized JavaScript origins. I would recommend doing different credentials between development and production just to make it easier to recycle those tokens if you need to in the future.
But for our authorized JavaScript origins here, what we want to do is add in our HTTP, localhost, 3333 domain that our application runs on locally.
Then we also want to add in our authorized redirect URLs. Now don't get this confused with the redirect URL that we have inside of our AdonisJS application.
This is instead the callback URL, and we can verify this by jumping over to the question mark where it says users will be redirected to this path after they have authenticated with Google.
So this is our callback URL here. So we'll add in our URI, and this is going to be HTTP semicolon slash localhost 3333
or whatever port it is that you run your applications on locally slash Google slash callback. Once we have that set, go ahead and hit create.
It notes this may take up to five minutes to a few hours, hopefully, definitely the former there. And there we go. It immediately popped me into the screen where I can see now my client ID and client secret.
We want to give that client ID there a copy. Jump back into our text editor. This is our client ID, so we'll plop it in there.
Then we want to jump back into the browser, copy our secret now, and plop that in as our secret. We're now all done with Google Cloud, so we can hit OK on that, and let's temporarily
hide our browser away, and let's make sure that everything migrates A-OK inside of our database. So let's open up our terminal here.
Again, I'm going to run node-ace-migration-fresh, but you most likely just want to run node-ace-migration-run if you're working with a brand new database. And there we go.
We have now migrated our create users table. So let's boot up our application, npm run dev. Make sure that the server address that your application is running on matches the one
you've added via your OAuth credentials inside of Google. Otherwise, you're going to run into issues. Once all is set there, we can go ahead and open up our browser.
I'm going to open up a brand new private window here just to ensure that nobody is logged in via Google whenever I go through this flow.
And we'll enter into our localhost 3333 URL, and we should be welcomed by our login slash register with Google button. Let's give that a click, and we should get redirected out to Google.
So that made a POST request up to our Google redirect URL, where it then redirected the user out to Google. I'm going to go ahead and log in with one of my test users here.
Enter in that user's password, hit next, got the two-factor authentication there. So I'll go through with that. And now that we've actually authenticated and logged into our Google account, now Google's
going to ask me if I want to authorize the Ally Social Auth Example application that we've set up to access my Google account information.
So I can either hit cancel here, which will end up with an access denied error, or I can hit continue to authorize this request and move forward with the flow.
So if I hit cancel here, you'll see that we got redirected back to our application with an access was denied error. If I now log in with register with Google one more time, you'll see that I'm already
logged in, so I can select my account and we're taken right to the authorization step. This time, if I continue, we'll instead be redirected to our application where we can
now see that our user was successfully registered inside of our database and authenticated as well with AdonisJS, as we see our user's name right up there.
From there, everything authentication based works the exact same as it would with any traditional session-based authentication flow inside of AdonisJS 6.
For example, if we quickly jump back into our text editor, go into our routes, we can
add in a router.post.logout, async, take in response and auth, await auth use web.logout,
and then return response redirect back. Jump into our homepage inside of our if auth check.
So when we have an authenticated user, let's add in a form method post with an action going out. I don't think we gave this an alias, so I'll just do slash log out there at our CSRF field
and then a button type submit that says log out. If I click back into our browser, there's our log out button. If I now click it, boom, our user has now been logged out of our application.
Now since we've fully completed the flow on Google's side, whenever I hit log in register with Google again, you'll see that we're immediately redirected right back to our application
and logged in with Google, making for a very seamless flow inside of our application here. We're already logged in on Google's side and we've already authorized our application to
access our Google user's information. So everything just works seamlessly.

AdonisJS In 30

9 Lessons

2h 59m

Stop losing your best ideas!

Use our integrated note feature to capture and organize your key insights. Take a note at any timestamp and jump instantly back to that moment in the video with a single click.