UserDetailsService và BCrypt: Quản Trị Danh Tính Chuẩn

TL;DR: UserDetailsService là giao diện chuyên trách nhiệm vụ tra cứu thông tin định danh: phương thức loadUserByUsername truy vấn cơ sở dữ liệu và trả về đối tượng UserDetails chứa mã băm mật khẩu, quyền hạn và 4 cờ trạng thái tài khoản. BCryptPasswordEncoder không chỉ là hàm băm một chiều mà tự động sinh chuỗi salt ngẫu nhiên 16 byte nhúng trực tiếp vào chuỗi đầu ra. Hệ số cost factor (mặc định 10-12) biến độ trễ có chủ đích (~400ms) thành vũ khí chống lại các cuộc tấn công brute-force từ GPU hiện đại.

Tại sao kiến trúc xác thực cần tách rời lớp User Lookup?

Trong một hệ thống thực tế, nguồn dữ liệu người dùng có thể đến từ nhiều nơi khác nhau: cơ sở dữ liệu quan hệ PostgreSQL, máy chủ thư mục LDAP, nhà cung cấp OAuth2 hoặc bộ nhớ tạm cho integration test.

Nếu DaoAuthenticationProvider tự mình thực hiện truy vấn cơ sở dữ liệu, việc thay đổi nguồn lưu trữ sẽ buộc bạn phải viết lại logic xác thực cốt lõi. Spring Security phân tách rõ ràng hai trách nhiệm:

1. Nguồn dữ liệu ở đâu? → UserDetailsService đảm nhận việc truy vấn và đóng gói thành UserDetails.
2. Xác thực bằng cách nào? → DaoAuthenticationProvider nhận UserDetails, đối soát mã băm BCrypt và kiểm tra trạng thái hoạt động.

Giao diện UserDetailsService và UserDetails có hợp đồng gì?

Giao diện UserDetailsService chỉ định nghĩa một phương thức duy nhất:

public interface UserDetailsService {
    UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;
}

Hợp đồng bắt buộc:

• Nhận vào định danh duy nhất (thường là email hoặc username).
• Trả về đối tượng UserDetails đại diện cho người dùng tại thời điểm đăng nhập.
• Ném UsernameNotFoundException nếu không tìm thấy — tuyệt đối không trả về null để tránh gây lỗi NullPointerException làm sập luồng xử lý.

public interface UserDetails {
    String getPassword();                            // BCrypt hash stored in database
    String getUsername();
    Collection<? extends GrantedAuthority> getAuthorities();
    boolean isEnabled();                             // Active account
    boolean isAccountNonExpired();                   // Contract expiration
    boolean isAccountNonLocked();                    // Brute-force lock
    boolean isCredentialsNonExpired();               // Password age policy
}

Làm thế nào để triển khai UserDetailsService truy vấn từ Database?

Dưới đây là cách triển khai chuẩn mực kết hợp với Spring Data JPA:

@Service
@RequiredArgsConstructor
public class AppUserDetailsService implements UserDetailsService {

    private final UserRepository userRepository;

    @Override
    @Transactional(readOnly = true)
    public UserDetails loadUserByUsername(String email) throws UsernameNotFoundException {
        AppUser user = userRepository.findByEmail(email)
            .orElseThrow(() -> new UsernameNotFoundException("User not found: " + email));

        return User.builder()
            .username(user.getEmail())
            .password(user.getPassword())            // Raw BCrypt hash from DB (do NOT re-encode)
            .authorities(buildAuthorities(user.getRoles()))
            .disabled(!user.isActive())
            .accountLocked(user.isLocked())
            .accountExpired(false)
            .credentialsExpired(false)
            .build();
    }

    private List<GrantedAuthority> buildAuthorities(Set<Role> roles) {
        return roles.stream()
            .map(role -> new SimpleGrantedAuthority("ROLE_" + role.getName()))
            .toList();
    }
}

Lưu ý quan trọng:

• Đánh dấu @Transactional(readOnly = true) để tránh lỗi LazyInitializationException khi duyệt danh sách roles của Entity.
• Trả về chuỗi hash nguyên bản từ database vào .password(...), tuyệt đối không băm lại mật khẩu tại đây.

Thuật toán BCrypt bảo vệ mật khẩu bằng cơ chế gì?

1. Tại sao không dùng MD5 hay SHA-256?

MD5 và SHA-256 là các thuật toán băm nhanh được tối ưu cho việc kiểm tra toàn vẹn tập tin. Một chip GPU thông thường có thể thực hiện hàng tỷ phép tính MD5/SHA mỗi giây, giúp kẻ tấn công phá vỡ bảng từ điển mật khẩu trong vài phút.

BCrypt đảo ngược quy luật này: chậm rãi là mục tiêu bảo mật chủ đích. Mỗi phép băm ở cost factor 12 tiêu tốn khoảng 400ms trên CPU hiện đại, khiến việc brute-force hàng tỷ mật khẩu trở nên bất khả thi.

2. Chuỗi Salt nhúng sẵn

BCrypt tự động tạo chuỗi salt ngẫu nhiên 16 byte và nhúng trực tiếp vào chuỗi kết quả:

$2a$12$EhSpMo65qH3R2v7nFuT9ue   sgpEv0bA5DVUKa8dCb3l4G4EkD9Xpwu
 |   |  |______________________|  |______________________________|
algo cost  salt (22 char = 16B)       hash (31 char)

Khi kiểm tra bằng passwordEncoder.matches(rawPassword, storedHash):

1. Thuật toán trích xuất salt và cost factor từ chính chuỗi storedHash.
2. Băm rawPassword bằng đúng salt và cost factor đó.
3. So sánh kết quả với phần chuỗi hash ở đuôi. Bảng cơ sở dữ liệu không cần lưu thêm cột salt riêng lẻ.

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder(12); // Recommended cost factor for production
}

Bốn cờ trạng thái tài khoản trong UserDetails hoạt động ra sao?

UserDetails cung cấp 4 cờ boolean kiểm soát vòng đời tài khoản:

Việc tách biệt thành 4 ngoại lệ độc lập giúp frontend hiển thị thông báo chính xác cho người dùng thay vì chỉ trả về một thông báo lỗi chung chung.

DaoAuthenticationProvider phối hợp kiểm tra trạng thái và mật khẩu thế nào?

DaoAuthenticationProvider tuân thủ quy trình kiểm tra nghiêm ngặt:

Thứ tự thực thi mang tính chiến lược: kiểm tra cờ trạng thái tài khoản trước, kiểm tra mật khẩu sau. Nếu tài khoản đã bị vô hiệu hóa hoặc bị khóa, hệ thống từ chối ngay lập tức mà không tiêu tốn 400ms tính toán BCrypt, đồng thời ngăn chặn các cuộc tấn công timing attack.

Những cạm bẫy thường gặp khi xử lý UserDetails và BCrypt là gì?

• Băm lại mật khẩu trong loadUserByUsername: Gọi encoder.encode(user.getPassword()) sẽ biến chuỗi thành "băm của chuỗi băm", khiến matches() không bao giờ trả về true.
• Thiếu Transaction khi đọc Roles: Thuộc tính roles thường được đánh dấu Lazy trong JPA. Nếu thiếu @Transactional(readOnly = true), việc chuyển đổi sang Authority sẽ gây ngoại lệ LazyInitializationException.
• Quên gắn tiền tố ROLE_: Phương thức hasRole("ADMIN") trong cấu hình tự động so khớp chuỗi ROLE_ADMIN. Cần đảm bảo danh sách GrantedAuthority được gán tiền tố phù hợp.

Khi nào nên cân nhắc sử dụng Argon2id thay vì BCrypt?

Argon2id (quán quân Password Hashing Competition) là thuật toán băm tốn bộ nhớ (memory-hard). Mỗi phép băm buộc phải sử dụng một lượng RAM nhất định (~16 MiB), làm vô hiệu hóa khả năng tính toán song song của các dàn chip GPU chuyên dụng.

Nên chọn Argon2id cho các dự án mới trong lĩnh vực fintech, y tế hoặc khi có yêu cầu tuân thủ chuẩn NIST. Với các hệ thống hiện hữu đang lưu trữ hàng triệu hash BCrypt $2a$, việc giữ nguyên BCrypt hoặc sử dụng DelegatingPasswordEncoder để nâng cấp dần là lựa chọn tối ưu.

Những điểm then chốt cần ghi nhớ là gì?

• UserDetailsService đóng vai trò cầu nối dữ liệu, ném UsernameNotFoundException khi không tìm thấy người dùng.
• BCrypt bảo vệ dữ liệu bằng cơ chế tính toán cố tình chậm và salt ngẫu nhiên nhúng trực tiếp trong chuỗi mã băm.
• Hệ số cost factor 12 cân bằng hoàn hảo giữa trải nghiệm người dùng và an toàn bảo mật.
• DaoAuthenticationProvider luôn thẩm định các cờ trạng thái trước khi thực hiện so khớp mật khẩu.

Bạn đã nắm vững UserDetailsService và BCrypt chưa?

Bài tiếp theo: Form login, HTTP Basic & session