[OAuth] Bài 0: Vì sao những kiến thức bảo mật bạn biết có thể đã lỗi thời?

Chào anh em.

Nếu anh em đang làm backend, đặc biệt là thiết kế kiến trúc microservices hay cấu hình bảo mật trên Spring Security, khả năng cao những config OAuth 2.0 anh em đang dùng đã lỗi thời. Thế giới bảo mật không đứng yên, và những luồng xác thực (flows) từng được coi là chuẩn mực nay đã trở thành lỗ hổng chí mạng.

Series này ra đời không phải để nhắc lại lý thuyết suông. Mục đích là đập đi xây lại tư duy thiết kế hệ thống an toàn, cập nhật thẳng lên tiêu chuẩn mới nhất.

1. Nền tảng: Xác thực (AuthN) và Ủy quyền (AuthZ)

Đừng nhầm lẫn hai khái niệm này. Đây là chốt chặn đầu tiên của mọi kiến trúc hệ thống:

• Xác thực (Authentication - AuthN): Trả lời câu hỏi "Bạn là ai?". Định danh người dùng (VD: Username/Password, Biometrics).

• Ủy quyền (Authorization - AuthZ): Trả lời câu hỏi "Bạn được phép làm gì?". Phân quyền truy cập sau khi đã định danh (VD: Quyền Read/Write database).

2. Định hình lại ma trận thuật ngữ

Khi các hệ thống cần giao tiếp chéo, hàng loạt chuẩn ra đời. Hãy phân định rõ vai trò của chúng:

• SAML: Giống như tờ "Giấy giới thiệu" thời xưa. Thường được nội bộ các tập đoàn lớn dùng để nhân viên đăng nhập một lần (SSO) vào mọi phần mềm của công ty (Mail, ERP, HR). Rất an toàn nhưng chuẩn này (dùng XML) lại khá cồng kềnh cho web/mobile app hiện đại.

• OAuth 2.0: Đây là một giao thức Ủy quyền (AuthZ). Thay vì bắt người dùng giao mật khẩu gốc cho app lạ, hệ thống sẽ cấp một cái Access Token (như chìa khóa phụ chỉ mở được cốp xe). Nó chỉ quan tâm đến việc cấp quyền, hoàn toàn không thèm biết danh tính người dùng là ai.

• OIDC (OpenID Connect): Vì OAuth 2.0 "mù tịt" về danh tính, người ta xây đè OIDC lên trên để giải quyết khâu Xác thực (AuthN). OIDC sinh ra một cái ID Token (như CCCD điện tử) để ứng dụng biết chính xác user tên gì, email ra sao.

• JWT (JSON Web Token): Đây không phải là giao thức bảo mật! Nó chỉ đơn thuần là chất liệu (định dạng chuỗi ký tự) dùng để chứa thông tin bên trong cái thẻ Access Token hay ID Token kia thôi.

3. Tại sao phải cập nhật ngay lúc này?

Công nghệ nền tảng không sai, nhưng các pattern triển khai cũ đã bộc lộ kẽ hở.

Các thói quen code như trả thẳng token về URL trình duyệt (Implicit Grant) hay để client tự cầm mật khẩu gửi lên server (Password Grant) hiện đã bị hacker khai thác triệt để. Nhóm chuyên trách bảo mật toàn cầu đã chính thức tung ra RFC 9700 (The Security Best Current Practice).

Bộ tiêu chuẩn này KHAI TỬ các pattern cũ và bắt buộc áp dụng các rào chắn mới. Dù anh em làm dự án cá nhân hay maintain hệ thống đòi hỏi khắt khe, việc tuân thủ cấu trúc của RFC 9700 giờ là yêu cầu bắt buộc để chống rò rỉ dữ liệu.

Hành trình tiếp theo của series sẽ bóc tách thẳng vào vấn đề: Lỗ hổng cũ nằm ở đâu và làm thế nào để cấu hình các "vũ khí" mới vào kiến trúc hệ thống hiện tại.