Authentication flow in Spring Boot - Performance & Optimization

Performance: Authentication flow

MEDIUM IMPACT

This affects page load speed and interaction responsiveness by controlling how quickly users can access protected content after login.

Handling user login and session validation

Spring Boot

public CompletableFuture<String> loginAsync(HttpServletRequest request) {
  return externalAuthService.validateAsync(request.getParameter("token"))
    .thenApply(valid -> {
      if (valid) {
        request.getSession().setAttribute("user", "authenticated");
        return "home";
      } else {
        return "login";
      }
    });
}

Asynchronous validation frees server threads, allowing faster response and better scalability.

📈 Performance GainNon-blocking, reduces server wait time by 200-500ms per request

Handling user login and session validation

Spring Boot

public String login(HttpServletRequest request) {
  // Synchronous call to external auth service
  boolean valid = externalAuthService.validate(request.getParameter("token"));
  if (valid) {
    request.getSession().setAttribute("user", "authenticated");
    return "home";
  } else {
    return "login";
  }
}

Synchronous external calls block the server thread, delaying response and increasing user wait time.

📉 Performance CostBlocks rendering for 200-500ms depending on external service latency

Performance Comparison

Pattern	Server Blocking	Response Delay	User Interaction Delay	Verdict
Synchronous external auth call	High (blocks thread)	200-500ms	High delay in login response	[X] Bad
Asynchronous external auth call	Low (non-blocking)	Minimal	Fast login response	[OK] Good

Rendering Pipeline

Authentication flow impacts the server response time which affects when the browser can start rendering protected content. Slow authentication delays the Critical Rendering Path and user interaction readiness.

→Server Processing

→Network

→First Paint

→Interaction

⚠️ BottleneckServer Processing due to synchronous blocking calls

Core Web Vital Affected

INP

This affects page load speed and interaction responsiveness by controlling how quickly users can access protected content after login.

Optimization Tips

1Avoid synchronous blocking calls during authentication to reduce server wait time.

2Use asynchronous or reactive programming to improve login response speed.

3Cache authentication tokens when possible to minimize repeated external calls.

Performance Quiz - 3 Questions

What is the main performance problem with synchronous authentication calls in Spring Boot?

A They block server threads, increasing response time

B They increase CSS paint time

C They cause layout shifts on the page

D They reduce JavaScript bundle size

DevTools: Network

How to check: Open DevTools, go to Network tab, filter by login request, and check the time spent waiting for server response.

What to look for: Look for long waiting (TTFB) times indicating blocking authentication calls.

Practice

1. What is the main purpose of the authentication flow in a Spring Boot application?

easy

A. To send emails to users after login

B. To style the user interface of the login page

C. To store user data in the database

D. To verify the identity of a user before granting access

Solution

1. Step 1: Understand authentication flow purpose

   Authentication flow is about checking who the user is before allowing access.

2. Step 2: Identify correct purpose in options

   Only To verify the identity of a user before granting access describes verifying user identity, which matches authentication.

3. Final Answer:

   To verify the identity of a user before granting access -> Option D

4. Quick Check:

   Authentication = Verify user identity [OK]

Hint: Authentication means checking who the user is [OK]

Common Mistakes:

• Confusing authentication with styling or data storage
• Thinking authentication sends emails
• Mixing authentication with authorization

2. Which of the following is the correct way to configure URL access rules in Spring Security?

easy

A. http.authorizeHttpRequests().requestMatchers("/admin/**").authenticated()

B. http.authorizeRequests().antMatchers("/private/**").denyAll()

C. http.authorizeRequests().anyRequest().allow()

D. http.authorizeRequests().requestMatchers("/public/**").permitAll()

Solution

1. Step 1: Identify correct method for URL rules in Spring Security

   Spring Security 6+ uses http.authorizeHttpRequests() with requestMatchers() for URL patterns.

2. Step 2: Check which option uses correct syntax and meaning

   http.authorizeHttpRequests().requestMatchers("/admin/**").authenticated() uses authorizeHttpRequests() and requestMatchers() with authenticated(), which is correct.

3. Final Answer:

   http.authorizeHttpRequests().requestMatchers("/admin/**").authenticated() -> Option A

4. Quick Check:

   Use authorizeHttpRequests() + requestMatchers() [OK]

Hint: Use authorizeHttpRequests() with requestMatchers() in Spring Security 6+ [OK]

Common Mistakes:

• Using deprecated authorizeRequests() in new Spring versions
• Using denyAll() incorrectly for access control
• Using anyRequest().allow() which is invalid

3. Given this Spring Security configuration snippet, what happens when a user accesses /dashboard without logging in?

http
  .authorizeHttpRequests(auth -> auth
    .requestMatchers("/public/**").permitAll()
    .anyRequest().authenticated()
  )
  .formLogin();

medium

A. The user can access /dashboard without login

B. The user is redirected to the login page

C. The user gets a 403 Forbidden error

D. The user sees a blank page

Solution

1. Step 1: Analyze URL access rules

   /public/** URLs are open, but any other request requires authentication.

2. Step 2: Check behavior for unauthenticated access to /dashboard

   Since /dashboard is not under /public, it requires login. formLogin() triggers redirect to login page.

3. Final Answer:

   The user is redirected to the login page -> Option B

4. Quick Check:

   Unauthenticated access redirects to login [OK]

Hint: AnyRequest().authenticated() means login required [OK]

Common Mistakes:

• Thinking permitAll() applies to all URLs
• Expecting 403 error instead of redirect
• Assuming access without login

4. Identify the error in this Spring Security configuration snippet:

http
  .authorizeHttpRequests(auth -> auth
    .requestMatchers("/admin/**").permitAll()
    .anyRequest().authenticated()
  )
  .formLogin();

medium

A. formLogin() is missing a login page URL

B. anyRequest().authenticated() should come before requestMatchers()

C. permitAll() on /admin/** allows unrestricted access to admin pages

D. requestMatchers() should be replaced with antMatchers()

Solution

1. Step 1: Review access rules for /admin/**

   permitAll() means anyone can access /admin/** without login, which is usually a security risk.

2. Step 2: Check order and methods

   Order is correct; anyRequest().authenticated() applies after permitAll(). formLogin() without URL uses default login page, which is valid.

3. Final Answer:

   permitAll() on /admin/** allows unrestricted access to admin pages -> Option C

4. Quick Check:

   permitAll() means open access [OK]

Hint: permitAll() means no login needed, risky on admin URLs [OK]

Common Mistakes:

• Thinking order of matchers is wrong here
• Assuming formLogin() needs explicit URL
• Confusing requestMatchers() with antMatchers()

5. You want to create a custom authentication flow that checks a user's email and password against a database and then grants access. Which Spring Boot component should you implement to handle this logic?

hard

A. UserDetailsService to load user data and PasswordEncoder to check password

B. AuthenticationEntryPoint to redirect users after login

C. CorsConfiguration to allow cross-origin requests

D. HttpFirewall to block unauthorized IP addresses

Solution

1. Step 1: Identify component for loading user info

   UserDetailsService is designed to load user details like email and password from a database.

2. Step 2: Identify component for password checking

   PasswordEncoder is used to verify the password matches the stored hash securely.

3. Step 3: Confirm other options are unrelated

   AuthenticationEntryPoint handles unauthorized access, not authentication logic. CorsConfiguration and HttpFirewall serve different purposes.

4. Final Answer:

   UserDetailsService to load user data and PasswordEncoder to check password -> Option A

5. Quick Check:

   Custom auth uses UserDetailsService + PasswordEncoder [OK]

Hint: UserDetailsService loads users; PasswordEncoder checks passwords [OK]

Common Mistakes:

• Confusing AuthenticationEntryPoint with authentication logic
• Using CorsConfiguration for authentication
• Thinking HttpFirewall handles login checks