Mock OAuth Implementation

Welcome to the second lesson of the "OAuth Fundamentals & Mock Implementation" course! In this lesson, we'll focus on creating a mock Google OAuth implementation. This approach allows us to simulate real-world OAuth interactions in a controlled environment, reinforcing your understanding of OAuth processes without needing actual third-party services. By the end of this lesson, you'll be equipped to create a mock OAuth flow, enhancing your grasp of how OAuth—an authorization framework—can be leveraged for authentication purposes. Let's get started! 🚀

🔒 Security Note for This Unit:

In this lesson, we're implementing a simplified OAuth flow to focus on understanding the core concepts. We'll use basic patterns like /success routes and tokens in URLs. In Unit 4, we'll upgrade to production-ready security with CSRF protection (state parameters). For now, focus on understanding how OAuth connects the pieces together.

⚠️ CRITICAL SECURITY WARNING - Tokens in URL Parameters:

Our current implementation passes tokens like /?token=xxx in URL query parameters. This is unsafe for production:

• ❌ Tokens appear in browser history
• ❌ Tokens leak through server logs
• ❌ Tokens exposed via HTTP Referer headers
• ❌ Tokens can be bookmarked and shared

Production solutions:

• ✅ Use HttpOnly, Secure, SameSite cookies (recommended approach)
• ✅ Use Authorization Code + PKCE flow with proper token handling
• ✅ Never use query parameters for sensitive tokens in real applications

We use query parameters in this demo for educational clarity only. In production OAuth implementations, you should always use secure cookie-based session management or proper token storage mechanisms. This course focuses on understanding OAuth flow mechanics; implementing production-grade token delivery is covered in advanced security courses.

In a mock Google OAuth implementation, we simulate the process of authenticating users through Google without actually connecting to Google's servers. This is useful for learning and testing purposes, as it allows us to understand the OAuth flow without the complexity of real-world integrations.

We implement a basic mock Google OAuth provider using pre-built HTML templates to focus on the OAuth authorization code flow logic. The mock implementation involves template loading, OAuth route structure, and JWT token integration with OAuth-authenticated users.

The first step is loading and serving OAuth consent screens. We use pre-built HTML templates that simulate the Google OAuth interface:

package com.codesignal.pastebin.controller;

import org.springframework.core.io.ClassPathResource;
import org.springframework.util.FileCopyUtils;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.RequestMapping;

import java.io.IOException;
import java.io.InputStreamReader;
import java.io.Reader;
import java.nio.charset.StandardCharsets;

@RestController
@RequestMapping("/api/oauth")
public class OAuthController {
    
    private final String googleTemplate;
    
    public OAuthController() throws IOException {
        this.googleTemplate = loadTemplate("templates/google-oauth.html");
    }
    
    private String loadTemplate(String path) throws IOException {
        ClassPathResource resource = new ClassPathResource(path);
        try (Reader reader = new InputStreamReader(resource.getInputStream(), StandardCharsets.UTF_8)) {
            return FileCopyUtils.copyToString(reader);
        }
    }
}

Understanding resource loading:

The classpath is where Java looks for classes and resources at runtime. In Spring Boot, src/main/resources is automatically part of the classpath.

Why use ClassPathResource? It works consistently whether your app runs from an IDE, JAR file, or Docker container—regular File I/O fails when resources are packaged inside JARs. ClassPathResource handles these deployment scenarios automatically and avoids hardcoding filesystem paths.

This code loads HTML templates from the classpath. By using a separate template file, we keep the OAuth logic clean and focused, while the HTML handles the user interface. FileCopyUtils.copyToString() reads the entire file into a String for serving.

OAuth implementations follow a standard route pattern for handling the authorization flow:

import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.GetMapping;

// Mock Google OAuth consent screen
@GetMapping(value = "/google", produces = MediaType.TEXT_HTML_VALUE)
public String mockGoogle() {
    return googleTemplate;
}

// Google OAuth success handler
@GetMapping("/google/success")
public ResponseEntity<?> googleSuccess() {
    // Handle OAuth callback logic
    return null;
}

This structure provides two essential endpoints:

• /api/oauth/google - Serves the consent screen template.
• /api/oauth/google/success - Handles the OAuth callback after user consent.

The clean route structure keeps the focus on OAuth flow logic rather than HTML details. We use Spring's @GetMapping annotation to define route handlers and specify MediaType.TEXT_HTML_VALUE to indicate we're returning HTML content directly to the user's browser.

The OAuth authorization code flow follows these steps in our mock implementation:

1. User visits /api/oauth/google. The consent screen is displayed.
2. User grants permission. The template form submits to /api/oauth/google/success.
3. Server processes callback. The user is created/found and a token is generated.
4. User is redirected. Back to the application with the authentication token.

Important Security Note: In production OAuth implementations, you must include a state parameter to protect against CSRF attacks. This parameter should be:

• Generated randomly when displaying the consent screen
• Stored temporarily (e.g., in session or Redis)
• Validated when processing the callback
• Removed after successful validation

We're omitting state validation in this mock implementation to keep the focus on understanding the basic OAuth flow, but never skip this in real applications—it's a critical security requirement.

The callback handler processes the OAuth response with mock data:

import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import com.codesignal.pastebin.model.User;
import com.codesignal.pastebin.model.Role;
import com.codesignal.pastebin.repo.UserRepository;
import com.codesignal.pastebin.util.JwtUtil;
import java.net.URI;

@GetMapping("/google/success")
public ResponseEntity<?> googleSuccess() {
    try {
        // Create or find a mock Google user
        User user = users.findByUsername("google_user").orElseGet(() -> {
            User newUser = new User();
            newUser.setUsername("google_user");
            newUser.setPassword(null); // OAuth users don't need passwords
            newUser.setRole(Role.USER);
            return users.save(newUser);
        });
        
        // Generate JWT token with expiration (24 hours)
        String token = jwt.generateTokenWithUserId(user.getId());
        
        // ⚠️ SECURITY WARNING: Using query parameters for tokens is unsafe!
        // This is for educational purposes only - see security note above
        HttpHeaders headers = new HttpHeaders();
        headers.setLocation(URI.create("/?token=" + token + "&provider=google"));
        return new ResponseEntity<>(headers, HttpStatus.FOUND);
    } catch (Exception error) {
        System.err.println("OAuth error: " + error.getMessage());
        HttpHeaders headers = new HttpHeaders();
        headers.setLocation(URI.create("/login?error=oauth_failed"));
        return new ResponseEntity<>(headers, HttpStatus.FOUND);
    }
}

OAuth users are handled differently than regular users since they authenticate through external providers:

// Create or find a mock Google user
User user = users.findByUsername("google_user").orElseGet(() -> {
    User newUser = new User();
    newUser.setUsername("google_user");
    newUser.setPassword(null); // OAuth users don't need passwords
    newUser.setRole(Role.USER);
    return users.save(newUser);
});

Key aspects of OAuth user creation:

• No password required. OAuth users authenticate through Google.
• User lookup. Check if the user already exists before creating.
• Simple user data. The mock implementation uses basic user information.

Understanding the code pattern:

Lambda expressions (() -> { ... }) are short anonymous functions in Java. The () -> syntax means "take no parameters and execute this code block." It's a concise way to write inline functions without declaring separate methods.

Why orElseGet() vs orElse()? The method orElseGet() only executes the lambda if the user doesn't exist—it's lazy. Using orElse() would always create the user object even if not needed, wasting resources. Always prefer orElseGet() for expensive operations like database saves.

What does "atomically" mean? Actually, this operation isn't atomic—there's a race condition where two requests could create duplicate users simultaneously. We use it here for simplicity in a mock implementation. Production code would need unique database constraints or transaction locking to prevent duplicates.

Spring Data JPA's findByUsername() returns an Optional<User>, which either contains a user or is empty. The orElseGet() method provides a fallback that creates and saves a new user only when needed.

After successful OAuth authentication, we generate a JWT token for the user session:

import com.codesignal.pastebin.util.JwtUtil;

// Generate JWT token with expiration (security best practice)
// Tokens expire after 24 hours to prevent replay attacks
String token = jwt.generateTokenWithUserId(user.getId());

// ⚠️ SECURITY WARNING: Passing tokens in URLs is unsafe (see note above)
HttpHeaders headers = new HttpHeaders();
headers.setLocation(URI.create("/?token=" + token + "&provider=google"));
return new ResponseEntity<>(headers, HttpStatus.FOUND);

This integration:

• Uses existing JWT system. The same token generation as regular authentication.
• Includes user ID. Links the token to the authenticated user.
• Adds expiration claim. Tokens expire after 24 hours for security.
• Uses environment-based secret. JwtUtil loads secret from application properties.

The JwtUtil class encapsulates JWT operations, providing generateTokenWithUserId() to create tokens with proper expiration. Spring's ResponseEntity with HttpStatus.FOUND (302) creates a redirect response.

Why we use JwtUtil with injected configuration instead of constants:

• Secrets should never be hard-coded in source code
• Application properties allow different secrets per environment (dev/staging/production)
• Supports secret rotation without code changes
• Follows Spring Boot's externalized configuration pattern

Here's the complete OAuth controller implementation:

package com.codesignal.pastebin.controller;

import com.codesignal.pastebin.model.Role;
import com.codesignal.pastebin.model.User;
import com.codesignal.pastebin.repo.UserRepository;
import com.codesignal.pastebin.util.JwtUtil;
import org.springframework.core.io.ClassPathResource;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.http.ResponseEntity;
import org.springframework.util.FileCopyUtils;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.io.IOException;
import java.io.InputStreamReader;
import java.io.Reader;
import java.net.URI;
import java.nio.charset.StandardCharsets;

@RestController
@RequestMapping("/api/oauth")
public class OAuthController {

    private final UserRepository users;
    private final JwtUtil jwt;
    private final String googleTemplate;

    public OAuthController(UserRepository users, JwtUtil jwt) throws IOException {
        this.users = users;
        this.jwt = jwt;
        this.googleTemplate = loadTemplate("templates/google-oauth.html");
    }

    private String loadTemplate(String path) throws IOException {
        ClassPathResource resource = new ClassPathResource(path);
        try (Reader reader = new InputStreamReader(resource.getInputStream(), StandardCharsets.UTF_8)) {
            return FileCopyUtils.copyToString(reader);
        }
    }

    // Mock Google OAuth consent screen
    @GetMapping(value = "/google", produces = MediaType.TEXT_HTML_VALUE)
    public String mockGoogle() {
        return googleTemplate;
    }

    // Google OAuth success handler
    @GetMapping("/google/success")
    public ResponseEntity<?> googleSuccess() {
        try {
            // Create or find a mock Google user
            User user = users.findByUsername("google_user").orElseGet(() -> {
                User newUser = new User();
                newUser.setUsername("google_user");
                newUser.setPassword(null); // OAuth users don't need passwords
                newUser.setRole(Role.USER);
                return users.save(newUser);
            });
            
            // Generate JWT token with expiration (24 hours)
            String token = jwt.generateTokenWithUserId(user.getId());
            
            // ⚠️ SECURITY WARNING: Passing tokens in URLs is unsafe!
            // Production: Use HttpOnly, Secure cookies instead
            HttpHeaders headers = new HttpHeaders();
            headers.setLocation(URI.create("/?token=" + token + "&provider=google"));
            return new ResponseEntity<>(headers, HttpStatus.FOUND);
        } catch (Exception error) {
            System.err.println("OAuth error: " + error.getMessage());
            HttpHeaders headers = new HttpHeaders();
            headers.setLocation(URI.create("/login?error=oauth_failed"));
            return new ResponseEntity<>(headers, HttpStatus.FOUND);
        }
    }
}

Understanding constructor injection: The constructor public OAuthController(UserRepository users, JwtUtil jwt) uses Spring Boot's dependency injection. Spring automatically provides UserRepository and JwtUtil instances when creating the controller—no need for new keywords. This pattern makes dependencies explicit and immutable (final fields), improving code clarity and testability.

To test the complete OAuth flow:

1. Navigate to /api/oauth/google. See the consent screen.
2. Click the authorization button. The form submits to /api/oauth/google/success.
3. User is created/found. Database interaction occurs.
4. JWT token is generated. The user session is established.
5. Redirect to main app. The user is authenticated with the token.

The HTML template handles the user interface, while your controller logic manages the authentication flow.

In this lesson, we explored how to create a mock Google OAuth implementation focusing on the core OAuth authorization code flow logic. We learned about template loading with Spring's ClassPathResource, OAuth route structure with @GetMapping, user creation for OAuth users with Spring Data JPA, and JWT token integration with proper expiration.

Important security reminders:

• Tokens in URL parameters are unsafe - we'll discuss secure patterns in Unit 5
• Always use externalized configuration (application.properties) not hard-coded values
• JWT tokens should always include expiration claims to prevent replay attacks

You now understand how these components work together to create a complete OAuth flow in Spring Boot. As you move on to the practice exercises, you'll implement these concepts and reinforce your understanding by building the OAuth routes yourself. Keep up the great work! 🌟