Spring security: Khám phá framework bảo mật hàng đầu cho ứng dụng Java

Nội dung bài viết

Bảo mật là yếu tố cực kỳ quan trọng của các ứng dụng web để tránh các rủi ro như rò rỉ dữ liệu hay bị tấn công. Bài viết này sẽ hướng dẫn bạn hiểu về Spring Security, framework bảo mật hàng đầu cho Java, từ các khái niệm cốt lõi như Xác thực (Authentication) và Phân quyền (Authorization) đến ví dụ thực tế, giúp bạn tự tin xây dựng ứng dụng an toàn.

Đọc bài viết này để hiểu thêm về:

Các khái niệm cốt lõi trong Spring Security
Cách xây dựng ứng dụng với Spring Security
Các chủ đề Spring Security nâng cao
Các câu hỏi thường gặp về Spring Security

Spring Security là gì? Ai nên học Spring Security?

Spring Security là một framework mạnh mẽ và cực kỳ linh hoạt để bảo mật các ứng dụng Java được xây dựng trên Spring Framework. Nó cung cấp một giải pháp toàn diện cho cả việc xác thực (Authentication) và phân quyền (Authorization).

Trong hệ sinh thái Spring, Spring Security được xem là giải pháp bảo mật tiêu chuẩn và được sử dụng vô cùng rộng rãi. Do sự tích hợp sâu và chặt chẽ với Spring, nó đã trở thành lựa chọn hàng đầu cho hầu hết các dự án từ nhỏ đến lớn. Bất kỳ lập trình viên Backend hoặc Full-stack nào làm việc với Java Spring đều cần có kiến thức vững chắc về Spring Security. Ngoài ra, các vị trí như DevOps Engineer hay Security Engineer cũng cần hiểu rõ về nó để có thể cấu hình và vận hành hệ thống một cách an toàn.

Đọc chi tiết: Spring Java là gì: Hướng dẫn chi tiết cách bắt đầu với Spring

Ưu và nhược điểm của Spring Security

Ưu điểm của Spring Security

Toàn diện và mạnh mẽ: Cung cấp đầy đủ các tính năng bảo mật từ cơ bản đến nâng cao (chống CSRF, OAuth2/OIDC, SAML…).
Tích hợp sâu với hệ sinh thái Spring: Hoạt động liền mạch với các dự án Spring Boot, Spring MVC, WebFlux…
Linh hoạt và tùy biến cao: Hầu hết mọi thành phần mặc định đều có thể được thay thế hoặc mở rộng để đáp ứng yêu cầu nghiệp vụ.
Cộng đồng lớn và tài liệu đầy đủ: Dễ dàng tìm kiếm sự hỗ trợ, các bài hướng dẫn và giải pháp cho các vấn đề thường gặp.

Nhược điểm của Spring Security

Độ phức tạp cao: Kiến trúc dựa trên Filter Chain và số lượng lớp cấu hình có thể gây bối rối cho người mới bắt đầu.
Cấu hình dài dòng: Mặc dù đã cải thiện, việc cấu hình cho các kịch bản phức tạp vẫn có thể yêu cầu nhiều mã lệnh.

So sánh Spring Security vs Apache Shiro

Shiro thường được xem là đơn giản và dễ học hơn, phù hợp cho các ứng dụng có yêu cầu bảo mật không quá phức tạp. Tuy nhiên, Spring Security mạnh mẽ hơn, nhiều tính năng hơn và được hỗ trợ tốt hơn trong hệ sinh thái Spring.

So sánh Spring Security với các nhà cung cấp định danh (Identity Providers) như Keycloak, Okta

Đây không phải là đối thủ trực tiếp mà là các giải pháp bổ trợ. Keycloak/Okta quản lý danh tính tập trung, trong khi Spring Security đóng vai trò là “cảnh sát” bảo vệ ứng dụng và tích hợp với các nhà cung cấp này thông qua các giao thức như OAuth2/OIDC.

Các khái niệm cốt lõi của Spring Security

Để sử dụng Spring Security hiệu quả, trước tiên chúng ta cần hiểu rõ các thành phần cấu thành nên kiến trúc của nó. Đây là những khái niệm nền tảng, quyết định cách luồng bảo mật được xử lý trong ứng dụng của bạn.

Authentication (Xác thực)

Authentication là quá trình xác định và xác minh danh tính của một chủ thể (user hoặc hệ thống) đang cố gắng truy cập vào ứng dụng.

Trong thực tế, quá trình này thường liên quan đến việc kiểm tra các thông tin xác thực (credentials) mà chủ thể cung cấp. Ví dụ phổ biến nhất là kiểm tra sự trùng khớp của username và password với dữ liệu được lưu trong cơ sở dữ liệu. Các cơ chế khác bao gồm xác thực thông qua JWT (JSON Web Tokens), OAuth2, hoặc các nhà cung cấp định danh bên ngoài.

Khi xác thực thành công, Spring Security sẽ tạo ra một đối tượng Authentication chứa đầy đủ thông tin của chủ thể và đánh dấu là đã được xác thực.

Authorization (Phân quyền)

Authorization là quá trình diễn ra sau khi một chủ thể đã được xác thực thành công.

Nó quyết định xem chủ thể đó có được phép thực hiện một hành động cụ thể hoặc truy cập một tài nguyên nhất định hay không. Mục tiêu của nó là trả lời câu hỏi: “Chủ thể này có quyền làm việc này không?”.

Ví dụ, một người dùng đã xác thực với vai trò USER có thể được cấp quyền đọc danh sách sản phẩm (GET/api/products), nhưng sẽ bị từ chối khi cố gắng truy cập vào trang quản trị (GET /api/admin). Việc kiểm tra quyền hạn này chính là Authorization.

Principal

Principal là một đối tượng đại diện cho chủ thể đã được xác thực. Sau khi quá trình Authentication thành công, thông tin về người dùng (như username hoặc một đối tượng UserDetails chứa đầy đủ thông tin) được gói gọn trong một Principal. Đối tượng này có thể được truy xuất ở bất kỳ đâu trong ứng dụng để lấy thông tin về người dùng hiện tại của phiên làm việc đó.

GrantedAuthority

GrantedAuthority là một đối tượng đại diện cho một quyền hạn duy nhất được cấp cho Principal. Về cơ bản, nó là một quyền (permission) được biểu diễn dưới dạng chuỗi ký tự. Theo quy ước, các quyền hạn liên quan đến vai trò người dùng thường có tiền tố ROLE_ (ví dụ: ROLE_ADMIN, ROLE_MANAGER). Ngoài ra, nó cũng có thể đại diện cho các quyền chi tiết hơn như product:read hoặc user:delete.

Một Principal sẽ có một tập hợp các GrantedAuthority, và tập hợp này được sử dụng trong quá trình Authorization để quyết định quyền truy cập.

SecurityContextHolder

SecurityContextHolder là một thành phần cốt lõi của Spring Security, có nhiệm vụ lưu trữ SecurityContext. Theo mặc định, SecurityContextHolder sử dụng một đối tượng ThreadLocal để lưu trữ context, điều này có nghĩa là context bảo mật sẽ luôn có sẵn cho luồng xử lý của request hiện tại.

Bên trong SecurityContext là đối tượng Authentication (chứa Principal và các GrantedAuthority). Bằng cách truy cập SecurityContextHolder, chúng ta có thể lấy được thông tin của người dùng đang đăng nhập ở bất kỳ lớp (Service, Controller) nào trong ứng dụng.

Ví dụ:

// Ví dụ truy xuất username của người dùng hiện tại
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
String currentPrincipalName = authentication.getName();

Filters và Filter Chain

Kiến trúc của Spring Security trong các ứng dụng web được xây dựng dựa trên một chuỗi các bộ lọc servlet (Servlet Filters), được gọi là Filter Chain. Mọi request HTTP gửi đến ứng dụng trước tiên sẽ được chặn lại và đi qua chuỗi bộ lọc này.

Mỗi Filter trong chuỗi có một trách nhiệm cụ thể và được sắp xếp theo một thứ tự ưu tiên nhất định. Ví dụ về các filter quan trọng:

CsrfFilter: Áp dụng cơ chế chống tấn công CSRF.
UsernamePasswordAuthenticationFilter: Chặn các request đến URL đăng nhập, trích xuất username/password và tiến hành xác thực.
AuthorizationFilter: Chặn các request đến các tài nguyên được bảo vệ và quyết định xem người dùng có đủ quyền truy cập hay không dựa trên các GrantedAuthority của họ.

Request sẽ đi lần lượt qua từng filter trong chuỗi. Nếu một filter nào đó quyết định rằng request không hợp lệ (ví dụ: xác thực thất bại hoặc không đủ quyền), nó sẽ chặn request và trả về lỗi ngay lập tức mà không cần đi tiếp đến các filter sau hoặc đến Controller của ứng dụng.

Các bước cơ bản xây dựng ứng dụng với Spring Security

Bước 1: Khởi tạo dự án Spring Boot

Cách nhanh nhất để bắt đầu một dự án Spring Boot là sử dụng Spring Initializr.

Truy cập trang start.spring.io.
Thiết lập thông tin dự án:
- Project: Maven (hoặc Gradle tùy sở thích).
- Language: Java.
- Spring Boot: Chọn phiên bản ổn định (không chọn SNAPSHOT).
- Project Metadata: Điền Group, Artifact, Name, Description theo ý bạn.
Thêm các Dependencies cần thiết:
- Spring Web: Để xây dựng ứng dụng web, tạo các REST Controller.
- Thymeleaf: Một template engine giúp chúng ta tạo các trang view HTML đơn giản cho trang chủ, trang đăng nhập.
- Spring Security: Nhân vật chính của chúng ta.

Sau khi điền xong, nhấn nút GENERATE để tải file .zip của dự án về. Giải nén và mở dự án bằng IDE yêu thích của bạn (IntelliJ, VSCode, Eclipse,…).

Bước 2: Cấu hình Spring Security cơ bản

Điều kỳ diệu đầu tiên khi bạn thêm dependency spring-boot-starter-security là nó hoạt động ngay lập tức mà không cần một dòng code cấu hình nào.

Hãy thử chạy ứng dụng ngay bây giờ. Bạn sẽ thấy một dòng log quan trọng trên console:

Using generated security password: [một-chuỗi-password-ngẫu-nhiên]

Bây giờ, hãy truy cập vào http://localhost:8080. Thay vì thấy trang lỗi 404, bạn sẽ được tự động chuyển hướng đến một trang đăng nhập (http://localhost:8080/login). Đây chính là hành vi mặc định của Spring Security: bảo vệ tất cả các endpoint và tự động tạo một form đăng nhập.

Để đăng nhập, hãy sử dụng:

Username: user
Password: chuỗi mật khẩu được sinh ra trên console.

Hành vi mặc định này rất tiện lợi, nhưng trong thực tế, chúng ta luôn cần tùy chỉnh lại nó.

Tạo lớp cấu hình

Hãy tạo một lớp cấu hình để ghi đè các thiết lập mặc định. Tạo một package mới tên là config và tạo file SecurityConfig.java trong đó.

package com.example.demo.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(authorize -> authorize
                .requestMatchers("/", "/home").permitAll() // Cho phép tất cả truy cập vào trang chủ
                .requestMatchers("/admin/**").hasRole("ADMIN") // Chỉ user có role ADMIN mới vào được /admin/**
                .requestMatchers("/profile").hasAnyRole("USER", "ADMIN") // Cả USER và ADMIN đều vào được /profile
                .anyRequest().authenticated() // Tất cả các request khác đều cần phải xác thực
            )
            .formLogin(formLogin -> formLogin
                .loginPage("/login") // Chỉ định trang đăng nhập tùy chỉnh
                .permitAll()
            )
            .logout(logout -> logout.permitAll());

        return http.build();
    }
}

Giải thích đoạn code trên:

authorizeHttpRequests(): Bắt đầu cấu hình các quy tắc phân quyền cho các request HTTP.
requestMatchers(...): Dùng để chỉ định các mẫu URL.
permitAll(): Cho phép tất cả người dùng (kể cả chưa đăng nhập) truy cập.
hasRole("ADMIN"): Yêu cầu người dùng phải có vai trò ADMIN.
authenticated(): Yêu cầu người dùng phải đăng nhập.
formLogin(): Kích hoạt và cấu hình xác thực qua form đăng nhập.
logout(): Kích hoạt chức năng đăng xuất.

Lưu ý quan trọng: Kể từ Spring Security 5.7.0, cách cấu hình bằng cách kế thừa từ WebSecurityConfigurerAdapter đã bị deprecated (không dùng nữa). Thay vào đó, chúng ta định nghĩa một @Bean trả về kiểu SecurityFilterChain như trên. Đây là cách tiếp cận hiện đại và được khuyến khích.

Bước 3: Quản lý thông tin người dùng

Người dùng user mặc định là không đủ. Chúng ta cần định nghĩa người dùng của riêng mình.

Cách 1: In-Memory Authentication (Phù hợp cho demo)

Đây là cách nhanh nhất để tạo người dùng nhằm mục đích kiểm thử. Chúng ta sẽ định nghĩa thông tin người dùng ngay trong bộ nhớ.

Trong file SecurityConfig.java, hãy thêm một @Bean UserDetailsService:

import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;

// ... bên trong lớp SecurityConfig

@Bean
public UserDetailsService userDetailsService() {
    UserDetails user = User.withDefaultPasswordEncoder()
        .username("user")
        .password("password")
        .roles("USER")
        .build();

    UserDetails admin = User.withDefaultPasswordEncoder()
        .username("admin")
        .password("password")
        .roles("ADMIN", "USER")
        .build();

    return new InMemoryUserDetailsManager(user, admin);
}

Lưu ý: withDefaultPasswordEncoder() cũng đã bị deprecated và chỉ nên dùng cho mục đích demo. Ở phần sau, chúng ta sẽ dùng một PasswordEncoder mạnh hơn.

Bây giờ, hãy khởi động lại ứng dụng. Bạn có thể đăng nhập với user/password hoặc admin/password và truy cập các trang tương ứng với quyền hạn đã cấu hình.

Cách 2: JDBC/JPA Authentication (Sử dụng trong thực tế)

Trong một ứng dụng thực tế, thông tin người dùng phải được lưu trong cơ sở dữ liệu.

a. Tạo Entity User và Role (Giả sử bạn đã có dependency spring-boot-starter-data-jpa và đã cấu hình database)

// User.java
@Entity
@Table(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String username;
    private String password;
    // getters and setters
}

// Role.java (Nếu bạn muốn quản lý role động

b. Triển khai UserDetailsService

Tạo một service mới, ví dụ JpaUserDetailsService, để Spring Security biết cách “đọc” thông tin người dùng từ database của bạn.

package com.example.demo.service;

import com.example.demo.repository.UserRepository;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.core.userdetails.UsernameNotFoundException;
import org.springframework.stereotype.Service;

@Service
public class JpaUserDetailsService implements UserDetailsService {

    private final UserRepository userRepository;

    public JpaUserDetailsService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        return userRepository
                .findByUsername(username)
                .map(SecurityUser::new) // Chuyển đổi từ User entity sang UserDetails
                .orElseThrow(() -> new UsernameNotFoundException("Username not found: " + username));
    }
}

Lưu ý: Lớp SecurityUser là một lớp implement UserDetails để gói User entity của bạn lại.

c. Cấu hình PasswordEncoder

Lưu ý quan trọng: TUYỆT ĐỐI KHÔNG BAO GIỜ LƯU MẬT KHẨU DẠNG CHUỖI KÝ TỰ GỐC (PLAIN TEXT) TRONG DATABASE!

Mật khẩu phải luôn được “băm” (hashed) bằng một thuật toán mạnh, một chiều. BCrypt là một lựa chọn tiêu chuẩn và được khuyến khích.

Trong SecurityConfig.java, hãy định nghĩa PasswordEncoder bean:

import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.crypto.password.PasswordEncoder;

// ... bên trong lớp SecurityConfig

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

Khi tạo người dùng mới, bạn sẽ dùng bean này để mã hóa mật khẩu trước khi lưu vào database:

// Ví dụ trong một service tạo user
User newUser = new User();
newUser.setUsername("newuser");
newUser.setPassword(passwordEncoder.encode("strongpassword123"));
userRepository.save(newUser);

Spring Security sẽ tự động sử dụng PasswordEncoder bean này để so sánh mật khẩu người dùng nhập vào (sau khi đã băm) với mật khẩu đã được băm trong database.

Các chủ đề nâng cao của Spring Security

Khi bạn đã nắm vững các kiến thức cơ bản, thế giới Spring Security còn rất nhiều chủ đề thú vị và mạnh mẽ khác để khám phá. Dưới đây là một số hướng đi nâng cao giúp bạn xây dựng các hệ thống phức tạp và an toàn hơn.

Bảo Mật API Với JWT (JSON Web Tokens)

Trong các kiến trúc hiện đại như Microservices hoặc các ứng dụng Stateless (nơi server không lưu trữ session của người dùng), cơ chế formLogin dựa trên session không còn phù hợp. Đây là lúc JWT tỏa sáng.

Cách hoạt động: Khi người dùng đăng nhập thành công, thay vì tạo một session trên server, hệ thống sẽ cấp cho họ một chuỗi token (JWT) đã được ký số. Trong các yêu cầu tiếp theo, người dùng chỉ cần gửi token này trong Authorization header. Server sẽ xác thực chữ ký của token để xác thực người dùng mà không cần truy vấn database hay bộ nhớ session.

Lợi ích: Giảm tải cho server, dễ dàng mở rộng (scaling), và là tiêu chuẩn vàng để bảo mật giao tiếp giữa các service.

OAuth 2.0 & OpenID Connect (OIDC)

Bạn chắc chắn đã từng thấy các nút “Đăng nhập với Google” hoặc “Đăng nhập với Facebook”. Đó chính là ứng dụng của OAuth 2.0 và OpenID Connect.

OAuth 2.0: Là một framework về phân quyền. Nó cho phép một ứng dụng (ví dụ: trang web của bạn) có được quyền truy cập giới hạn vào tài nguyên của người dùng trên một server khác (ví dụ: Google) mà không cần biết mật khẩu của người dùng.
OpenID Connect (OIDC): Là một lớp định danh nằm trên OAuth 2.0. Nếu OAuth 2.0 chỉ giải quyết việc “ủy quyền”, thì OIDC giải quyết việc xác thực – “người dùng này là ai?”. Nó cung cấp thông tin hồ sơ người dùng dưới dạng một token đặc biệt gọi là ID Token.

Spring Security cung cấp một module spring-boot-starter-oauth2-client cực kỳ mạnh mẽ để tích hợp các luồng đăng nhập này một cách dễ dàng.

Method Level Security (Bảo Mật Cấp Phương Thức)

Bên cạnh việc bảo mật dựa trên URL (authorizeHttpRequests), Spring Security còn cho phép bạn áp dụng các quy tắc bảo mật trực tiếp trên các phương thức trong tầng Service.

Cách sử dụng: Bằng cách bật @EnableMethodSecurity và sử dụng các annotation như @PreAuthorize, @PostAuthorize, và @Secured trên các phương thức.

Lợi ích: Cung cấp một lớp bảo mật chi tiết và chặt chẽ hơn, gắn liền với logic nghiệp vụ.

Ví dụ:

// Chỉ người dùng có vai trò ADMIN mới có thể gọi phương thức này
@PreAuthorize("hasRole('ADMIN')")
public void deleteUser(Long userId) {
    // ... logic xóa người dùng
}

// Chỉ người dùng nào có username trùng với `username` trong path
// mới có thể xem thông tin của chính mình.
@PreAuthorize("#username == authentication.principal.username")
public UserProfile getProfileByUsername(String username) {
    // ... logic lấy profile
}

Khi ứng dụng Frontend (ví dụ: React, Vue) của bạn chạy trên một domain khác (vd: myapp.com) và gọi API đến Backend Spring Boot chạy trên domain (vd: api.myapp.com), trình duyệt sẽ mặc định chặn các yêu cầu này vì lý do bảo mật.

CORS là một cơ chế cho phép server chỉ định những “nguồn” (origin) nào khác được phép truy cập tài nguyên của mình. Spring Security cho phép bạn cấu hình CORS một cách linh hoạt:

// Ví dụ cấu hình CORS trong SecurityFilterChain
http.cors(cors -> cors.configurationSource(request -> {
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowedOrigins(List.of("https://myapp.com"));
    config.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
    config.setAllowedHeaders(List.of("*"));
    return config;
}));

CSRF (Cross-Site Request Forgery) Protection

SRF là một kiểu tấn công trong đó kẻ xấu lừa người dùng đã đăng nhập thực hiện một hành động không mong muốn trên một trang web. Ví dụ: lừa người dùng nhấn vào một link để tự động chuyển tiền từ tài khoản của họ.

Cách Spring Security bảo vệ: Đối với các ứng dụng stateful (sử dụng session), Spring Security mặc định đã bật tính năng chống CSRF. Nó hoạt động bằng cách yêu cầu mọi request thay đổi trạng thái (POST, PUT, DELETE) phải đính kèm một token bí mật, ngẫu nhiên (gọi là CSRF token). Token này chỉ được tạo ra và biết bởi server và client hợp lệ. Kẻ tấn công không có token này sẽ bị chặn.

Lưu ý: Cơ chế bảo vệ này thường không cần thiết cho các API stateless sử dụng token (như JWT) vì chúng không dựa vào cookie session của trình duyệt để xác thực.

Các câu hỏi thường gặp về Spring Security

Sự khác biệt giữa hasRole() và hasAuthority() là gì?

Cả hasRole() và hasAuthority() đều dùng để kiểm tra quyền hạn, nhưng có một quy ước ngầm:

hasRole(“ADMIN”): Tự động kiểm tra quyền hạn có tên là “ROLE_ADMIN”. Spring sẽ tự thêm tiền tố ROLE_ cho bạn.
hasAuthority(“ROLE_ADMIN”): Kiểm tra chính xác quyền hạn có tên là “ROLE_ADMIN”. Bạn phải cung cấp toàn bộ tên.
hasAuthority(“WRITE_PRIVILEGE”): Dùng cho các quyền chi tiết, không phải là vai trò.

Nói ngắn gọn, hasRole() là một trường hợp đặc biệt của hasAuthority() được thêm vào để cho tiện lợi.

SecurityContextHolder hoạt động thế nào với các phương thức @Async? Tại sao thông tin đăng nhập bị mất?

Đây là một vấn đề kỹ thuật kinh điển.

Vấn đề: Mặc định, SecurityContextHolder sử dụng chiến lược ThreadLocal để lưu trữ thông tin bảo mật. ThreadLocal chỉ gắn dữ liệu vào luồng (thread) đang xử lý request. Khi bạn gọi một phương thức được đánh dấu @Async, Spring sẽ tạo một luồng mới từ một ThreadPool để thực thi nó. Luồng mới này không có thông tin về SecurityContext của luồng ban đầu, dẫn đến việc Authentication trả về null.
Giải pháp: Bạn cần thay đổi chiến lược lưu trữ của SecurityContextHolder trước khi ứng dụng khởi động. Hãy chuyển sang chế độ MODE_INHERITABLE, chế độ này sử dụng InheritableThreadLocal để tự động sao chép context từ luồng cha sang luồng con.

Khi nào tôi nên tự viết một AuthenticationProvider tùy chỉnh?

Bạn cần một AuthenticationProvider tùy chỉnh khi cơ chế xác thực của bạn không theo chuẩn username/password thông thường mà DaoAuthenticationProvider (provider mặc định) xử lý.

Các trường hợp phổ biến:

Xác thực người dùng bằng cách gọi một API của bên thứ ba.
Xác thực bằng một cặp API Key và Secret Key được gửi qua header.
Quy trình xác thực yêu cầu nhiều yếu tố (multi-factor) phức tạp không được hỗ trợ sẵn.
Xác thực dựa trên chứng chỉ client (client certificate).

Để làm điều này, bạn cần tạo một class implement interface AuthenticationProvider và ghi đè hai phương thức:

authenticate(): Chứa logic xác thực chính của bạn.
supports(): Chỉ định loại Authentication token mà Provider này có thể xử lý.

Sau đó, bạn đăng ký Provider này vào AuthenticationManager.

Khi nào chỉ cần Spring Security truyền thống, khi nào cần thêm Spring Boot?

Dùng Spring Boot + Spring Security: Phù hợp khi bắt đầu bất kỳ dự án mới nào, hoặc xây dựng microservices.

Vì Spring Boot có tự động cấu hình (autoconfiguration), nó sẽ tự động thiết lập bảo mật cơ bản cho bạn. Bạn chỉ cần thêm một dependency starter duy nhất. Cách này giúp phát triển cực kỳ nhanh chóng.

Tìm hiểu thêm: Tổng quan về Spring Boot Security

Dùng Spring Security Truyền thống: Chỉ khi bạn bị buộc phải làm vậy hoặc do nhu cầu cá biệt của dự án, chủ yếu là để bảo trì các dự án cũ không được xây dựng trên Spring Boot.

Vì yêu cầu cấu hình thủ công mọi thứ (thường qua file XML), quản lý thư viện phức tạp và tốn nhiều công sức cho những thiết lập cơ bản.

Tổng kết

Qua bài viết, chúng ta đã đi từ các khái niệm cốt lõi đến việc xây dựng một ứng dụng thực tế với Spring Security. Hy vọng bạn đã có một nền tảng vững chắc để tự tin áp dụng công cụ mạnh mẽ này. Hãy nhớ, bảo mật là yếu tố không thể thiếu, và đây chỉ là điểm khởi đầu trên hành trình làm chủ Spring Security của bạn.