Securing Methods with @PreAuthorize

1. Two Layers of Authorization: HttpSecurity vs. @PreAuthorize

In Spring Security, you have two primary ways to configure authorization:

1. Request-Level Security: Configured in your SecurityFilterChain bean using http.authorizeHttpRequests(...). This is ideal for broad, URL-based rules. You've already used this to make your login endpoint public (.requestMatchers("/api/auth/**").permitAll()) and secure everything else (.anyRequest().authenticated()). This is the first line of defense.

2. Method-Level Security: Applied directly to your service or controller methods using annotations like @PreAuthorize. This is perfect for fine-grained rules that depend on the user's role, specific permissions, or even the data being passed into the method.

A key interview topic is understanding the trade-offs.

In short:

• HttpSecurity rules are applied globally and early in the filter chain, based on URL patterns.
• @PreAuthorize rules are applied specifically and just before the method executes, allowing for more complex, context-aware logic.

In a robust system, you use both. HttpSecurity sets the baseline (e.g., all /api/** endpoints require authentication), and @PreAuthorize enforces the specific rules (e.g., only users with the ADMIN role can call the deleteUser() method).

2. Enabling and Understanding Method Security

To start using method-level security, you first need to enable it.

In your main security configuration class (the one with the @Configuration and @EnableWebSecurity annotations), add the @EnableMethodSecurity annotation.

@Configuration
@EnableWebSecurity
@EnableMethodSecurity // Add this annotation
public class SecurityConfig {
    // ... your SecurityFilterChain bean and other configs
}

That's it! This annotation tells Spring to look for security annotations on your beans and wrap them with the necessary security logic.

How does it work internally? This is a frequent deep-dive interview question.

When you call a method annotated with @PreAuthorize, you aren't calling your code directly. Here’s the flow:

1. Because of @EnableMethodSecurity, Spring creates a proxy around your bean (e.g., your controller or service).
2. Your method call is intercepted by this proxy, which triggers a Spring AOP (Aspect-Oriented Programming) interceptor called AuthorizationManagerBeforeMethodInterceptor.
3. This interceptor gets the expression from your annotation (e.g., "hasRole('ADMIN')").
4. It uses a MethodSecurityExpressionHandler to parse and evaluate this Spring Expression Language (SpEL) expression against the current Authentication object (which your JWT filter from the last lesson placed in the SecurityContextHolder).
5. If the expression evaluates to true, the interceptor calls your actual method.
6. If it evaluates to false, the interceptor throws an AccessDeniedException, which Spring's ExceptionTranslationFilter catches and translates into an HTTP 403 Forbidden response. Your method is never executed.

This diagram and the accompanying video segment provide an excellent visualization of this flow.

3. Implementing @PreAuthorize

Now, let's put this into practice. Let's assume your JWT contains a claim for authorities (or roles) like USER_READ, USER_WRITE, etc.

You can now secure your controller methods based on these authorities. The Spring Security documentation provides a list of the built-in expressions you can use.

The two most common expressions are:

• hasAuthority('PERMISSION_NAME'): Checks if the user has the specified authority.
• hasRole('ROLE_NAME'): A shortcut for hasAuthority('ROLE_ROLE_NAME'). It automatically prefixes ROLE_ to the name you provide.

Let's apply this to a hypothetical UserController.

@RestController
@RequestMapping("/api/v1/users")
public class UserController {

    // Accessible to any authenticated user
    @GetMapping("/me")
    public ResponseEntity<User> getMyProfile() {
        // ... logic to get current user's profile
    }

    // Only accessible to users with 'ADMIN_READ' or 'SUPER_USER' authority
    @GetMapping
    @PreAuthorize("hasAnyAuthority('ADMIN_READ', 'SUPER_USER')")
    public ResponseEntity<List<User>> getAllUsers() {
        // ... logic to list all users
    }

    // Only accessible to users with the 'ADMIN' role
    @DeleteMapping("/{id}")
    @PreAuthorize("hasRole('ADMIN')")
    public ResponseEntity<Void> deleteUser(@PathVariable Long id) {
        // ... logic to delete a user
    }
}

Hands-on Demonstration

The following video demonstrates this entire process, from adding @EnableMethodSecurity to testing the secured endpoints with Postman.

@PreAuthorize("hasAuthority('FUNDS_TRANSFER') and @ipWhitelistService.isAllowed(request.getRemoteAddr())")
public void transferFunds(...) {
    // ...
}

4. Beyond @PreAuthorize: Post-Invocation Checks with @PostAuthorize

Spring also provides @PostAuthorize, which works similarly but performs the authorization check after the method has been executed. This is useful when the authorization decision depends on the method's return value.

A classic use case is checking for data ownership.

@GetMapping("/{id}")
@PostAuthorize("returnObject.ownerUsername == authentication.name")
public Account getAccountDetails(@PathVariable Long id) {
    // This logic runs first...
    Account account = accountService.findById(id); 
    return account;
    // ...then, Spring checks if the owner of the returned 'account' object
    // is the same as the currently authenticated user. If not, AccessDeniedException.
}

This is incredibly powerful for preventing users from accessing data that doesn't belong to them, even if they have the general permission to read accounts. The CodeSnippet video you watched also has a great section on this (14:59 - 19:20) if you'd like to see a live example.

Conclusion

You have now learned how to implement a second, more granular layer of security in your application. By combining request-level and method-level authorization, you can build a robust, secure, and maintainable system.

Key Takeaways for Your Interview Prep:

• Layered Security: Use HttpSecurity for broad, URL-based rules and @PreAuthorize for fine-grained, business-logic-specific rules.
• Enablement: Method security is activated with @EnableMethodSecurity.
• Mechanism: It works via Spring AOP proxies that intercept method calls and evaluate SpEL expressions before execution.
• hasRole vs. hasAuthority: hasRole('ADMIN') is a shortcut for hasAuthority('ROLE_ADMIN'). Be clear about this distinction.
• @PreAuthorize vs. @PostAuthorize: Use @PreAuthorize for checks based on input parameters and user permissions. Use @PostAuthorize for checks based on the method's return value (e.g., ownership).
• SpEL is Powerful: Mention that you can reference method arguments, the authentication object, and even other Spring beans within your expressions to create highly dynamic authorization rules.

Preview of the Next Lesson:
So far, we've handled authentication and authorization within our own application's ecosystem. But what if you need to let users log in with Google, GitHub, or another company's identity system? In the next lesson, we will explore the core concepts of OAuth2 and OpenID Connect (OIDC), the industry-standard protocols for delegated authorization and federated identity.