Learn auth flow for social accounts in mermaid diagram
Social Auth Flow
Email Password First, Social Auth Next
Email Password Flow
Social Auth First, Email Password Next
Be the first to share your thoughts and start the conversation.
By logging in, you'll unlock full access to this and other free tutorials on JSM Pro.
Why? Logging in lets us personalize your learning experience, track your progress, and keep you in the loop with new workshops, coding tips, and platform updates.
You'll also be the first to know about upcoming launches, events, and exclusive discounts.
No spam—just helpful content to level up your skills.
If that sounds fair, go ahead and log in to continue →
Enter your name and email to get instant access
In this lesson, we explore the authentication flow of a Next.js application, focusing on both email/password and social login methods. The process includes creating user accounts, managing sessions, and ensuring that users can log in seamlessly whether they use traditional or social authentication methods.
00:00:02 Before we get started with finally implementing our Auth, I want to take a second to explain the entire flow of the application,
00:00:10 specifically regarding authentication.
00:00:12 Here you can see the diagram of the account creation.
00:00:16 So a user comes to the website and tries to initiate an email and password login, right within our Next.js application.
00:00:25 Then we handle that login attempt and send it over to NextAuth, which then asks the user for their email and password.
00:00:33 We forward that check to MongoDB and check if a user exists.
00:00:37 If a user doesn't yet exist, then we create a new user in the database.
00:00:43 We also create a new account to which we provide the credentials, such as the email and password.
00:00:50 And we also optionally send the verification email to their email service.
00:00:55 Finally, we return the user back for the password check, and once we verify the password, we generate a session.
00:01:02 Of course, I don't even have to mention it, but if a user already exists, we don't have to repeat those steps.
00:01:08 These are only for account creation.
00:01:10 If the user already exists, then we simply generate a session after the user passes a correct email and password.
00:01:16 Finally, we return that session from NextAuth to the Next.js app, and then the user completes the login, and we update the UI.
00:01:24 This is the authentication flow of more or less any application.
00:01:28 Now, for just a second, I also want to show you the social login.
00:01:32 As you can see, if a user initiates social login, we once again redirect to NextAuth, but here we have an extra step where NextAuth redirects to the OAuth provider,
00:01:44 such as GitHub or Google.
00:01:46 Then the OAuth provider itself prompts the user to log in through their platform, the user provides the credential, and then we get back the OAuth token
00:01:55 to our next auth.
00:01:56 If an account doesn't exist, we create a new account in our MongoDB database and also create a new user.
00:02:02 And if account does exist, we simply return the existing user, generate a session, return it, complete the login, and update the UI.
00:02:10 It's very similar to the email and password login, but now I want to teach you something more advanced.
00:02:17 What happens when a user uses the email and password method for the first time, but then when they come to the website the second time,
00:02:24 they forgot that they used just their email, and they want to use some kind of a social auth, like Google or GitHub, with that same email address.
00:02:33 Should we create a new account or should we log them into their email account?
00:02:37 Well, for that, we can implement an additional check.
00:02:40 This procedure is exactly the same as before.
00:02:43 User first tries to log in using a social login, for example, GitHub or Google.
00:02:48 But then later, this is the part that changes.
00:02:51 The user attempts to log in using their email and password.
00:02:55 We handle that login attempt.
00:02:57 We check for existing user with the email.
00:03:00 We return that existing user that was created from social auth because it's only a single user, right?
00:03:05 It's going to be Adrian, for example.
00:03:08 But we create a second account for that same user.
00:03:12 And this is the real reason why we have both the user and the account models.
00:03:17 Because now we can create a second account for the login and email credentials.
00:03:22 And the first one was for the social auth.
00:03:25 We can then update this user with a new name and image info.
00:03:29 If the user decides to pass it, we confirm it, and then we return a new session.
00:03:34 And of course, almost exactly the same thing happens when a user first signs up with email and password, and then later on,
00:03:41 they initiate the social login.
00:03:44 We want to check for that, then we return the existing user, but this time we create a new account for OAuth.
00:03:51 We update that OAuth profile with the new name and image coming from Google.
00:03:55 We confirm it and return the updated session.
00:03:58 I know this is a very low quality graphic, but I think it gets the job done.
00:04:03 You now understand the reasoning behind why we have two different models, one for the user and the second one for the account.
00:04:10 because a single user can have multiple accounts, but a single account can only belong to one user.
00:04:17 Now that you know that, we are one step closer to implementing it.
