OAuth and Social Login Systems

# CHAPTER 10

OAuth and Social Login Systems #

1. Introduction #

2. Learning Objectives #

• Define OAuth 2.0 and its primary purpose (Delegated Authorization).

• Understand the difference between OAuth 2.0 and OpenID Connect (Identity).

• Trace the steps of the OAuth Authorization Code Flow.

• Identify the roles: Resource Owner, Client, Authorization Server, Resource Server.

• Understand how to integrate third-party identity data into your database.

3. Beginner-Friendly Explanation #

This is Delegated Authorization. When a user "Logs in with Google" on your website, they do NOT give your website their Google password. Google handles the login, and gives your website a temporary barcode (an Access Token) to prove who they are.

4. OAuth 2.0 vs OpenID Connect #

However, developers started using OAuth to ask: "Who is this user?" To standardize this, the industry built OpenID Connect (OIDC) on top of OAuth 2.0. OIDC is specifically designed for Authentication. When you use "Log in with Google," you are technically using OIDC to request an "ID Token" containing the user's name and email.

5. The Four Roles of OAuth #

1. 1. Resource Owner: The User (You).

1. 2. Client: The Application requesting access (e.g., Spotify, or Your Custom App).

1. 3. Authorization Server: The system that authenticates the user (Google's Login Server).

1. 4. Resource Server: The system holding the user's data (Google's Database).

6. The OAuth Workflow (The Dance) #

1. 1. The Redirect: Your App redirects the user's browser to https://accounts.google.com/auth. The URL includes your App's ID and asks for the "email" and "profile" scope.

1. 2. The Consent Screen: Google asks the User: "Do you want to allow Your Custom App to see your email address?"

1. 3. The Authorization Code: The User clicks "Yes". Google redirects the User back to Your App's specific callback URL (e.g., yoursite.com/auth/google/callback) and attaches a temporary Authorization Code to the URL.

1. 4. The Token Exchange: Your backend server takes that temporary Code, attaches its own secret App Password, and sends a secure, hidden server-to-server POST request directly to Google.

1. 5. The Access Token: Google verifies the code and replies to your backend with an Access Token (and an ID Token).

1. 6. Fetching Data: Your backend uses the Access Token to ask the Google API: "What is the email address of the person who just approved this?" Google replies: "john@gmail.com".

7. Integrating Social Logins into Your Database #

You treat it exactly like a normal login, but you bypass the password check!

// Pseudo-code logic running inside the /callback route

const googleEmail = googleApiData.email;
const googleName = googleApiData.name;

// 1. Check if the user already exists in YOUR database
let user = await Database.findUserByEmail(googleEmail);

if (!user) {
    // 2. If they don't exist, create a new account for them instantly!
    // Notice we do not set a password, or we generate a random dummy password
    user = await Database.createUser({ 
        email: googleEmail, 
        name: googleName, 
        auth_provider: 'google' 
    });
}

// 3. The user is now authenticated!
// Generate YOUR OWN JWT Access Token for them, just like a normal login
const myAppToken = jwt.sign({ userId: user.id }, SECRET_KEY);

// 4. Send the token to the frontend to complete the login
res.redirect(`https://yourfrontend.com/dashboard?token=${myAppToken}`);

8. Backend Workflow: Passport.js and Socialite #

• Node.js: The industry standard is Passport.js. It has hundreds of "Strategies" (Google, Facebook, Twitter) that handle the OAuth flow automatically.

• Laravel (PHP): The industry standard is Laravel Socialite, providing a fluent interface to authenticate with OAuth providers in just three lines of code.

9. Best Practices #

• The state Parameter: When redirecting the user to Google in Step 1, you must include a randomly generated state string in the URL. When Google redirects back to you in Step 3, they return that exact string. You must verify it matches! This prevents CSRF attacks where a hacker tries to trick a user into logging into the hacker's account.

10. Common Mistakes #

• Assuming Email is Verified: When you get an email from a social provider, check their documentation. Google verifies emails, but some providers (like Twitter/X or older OAuth implementations) might return an unverified email. If you link a user's account based on an unverified email, a hacker could steal an account by registering a fake GitHub account with the victim's email address.

11. Exercises #

1. 1. Explain the fundamental difference between OAuth 2.0 and OpenID Connect (OIDC). Which one was designed specifically to handle user Identity?

12. Coding Challenges #

• Challenge: Research the documentation for the Google Identity / OAuth 2.0 API. Find the specific URL format required to initiate the authorization request (Step 1 of the dance). What are the three required URL parameters you must append to the request? (Hint: clientid, redirecturi, response_type).

13. MCQs with Answers #

14. Interview Questions #

• Q: Walk me through the Authorization Code Grant flow in OAuth 2.0. Explain the roles of the Client, the Authorization Server, and the Resource Server.

• Q: Explain the security purpose of the state parameter in an OAuth 2.0 request. What specific vulnerability does it mitigate during the callback phase?

15. FAQs #

16. Summary #

17. Next Chapter Recommendation #