Trong backend, có những phần nhìn qua tưởng đơn giản nhưng lại là nơi dễ gây ra hậu quả nghiêm trọng nhất. Authentication và Authorization là một trong số đó.
Rất nhiều hệ thống gặp sự cố bảo mật không phải vì hacker quá giỏi, mà vì phần xác thực và phân quyền được làm theo cách “cho chạy được”. Thêm một middleware kiểm tra token, thêm một cột role trong database, vài câu if trong controller – nhìn có vẻ đủ dùng. Cho đến khi hệ thống lớn hơn, số lượng người dùng tăng lên, hoặc mô hình quyền trở nên phức tạp hơn dự kiến.
Nếu bạn đang học backend, đây là một trong những chủ đề cần hiểu đúng ngay từ đầu. Vì khi đã làm sai ở tầng nền tảng này, sửa lại thường tốn kém và rủi ro hơn rất nhiều so với viết lại một API thông thường.
Mục lục
Authentication và Authorization không giống nhau – nhưng thường bị trộn lẫn
Authentication là quá trình xác minh bạn là ai. Authorization là quyết định bạn được phép làm gì. Hai khái niệm nghe có vẻ rõ ràng, nhưng trong thực tế triển khai, chúng thường bị trộn lẫn vào nhau.
Rất nhiều hệ thống kiểm tra token hợp lệ và mặc định coi như mọi hành động phía sau đều hợp lệ. Hoặc phân quyền được viết rải rác trong từng endpoint, mỗi nơi kiểm tra một kiểu. Ban đầu không vấn đề gì. Nhưng khi quyền truy cập thay đổi, hoặc khi cần bổ sung thêm vai trò mới, backend bắt đầu xuất hiện những logic chồng chéo và khó kiểm soát.
Vấn đề không nằm ở việc dùng JWT, session hay OAuth. Vấn đề nằm ở cách bạn tách bạch hai khái niệm này trong tư duy kiến trúc. Nếu không phân định rõ ràng, bạn sẽ rất khó mở rộng mô hình quyền sau này.
Sai lầm phổ biến: thiết kế quyền dựa trên vai trò quá đơn giản
Ở giai đoạn đầu, việc gán cho người dùng một trường role như “admin”, “user” là đủ. Nhưng hệ thống hiếm khi dừng lại ở mức đó.
Khi sản phẩm phát triển, quyền truy cập thường trở nên tinh vi hơn: một người có thể là quản lý của một nhóm nhưng không phải nhóm khác; một người có quyền chỉnh sửa nhưng không được xóa; một đối tác có quyền đọc dữ liệu nhưng chỉ trong một phạm vi nhất định.
Nếu backend được xây dựng với giả định quyền chỉ xoay quanh vài vai trò cố định, bạn sẽ phải viết thêm rất nhiều điều kiện đặc biệt để xử lý ngoại lệ. Mỗi ngoại lệ như vậy làm hệ thống thêm phức tạp và khó kiểm soát.
Từ góc độ nghề nghiệp, điều quan trọng không phải là nhớ nhiều mô hình phân quyền, mà là hiểu rằng quyền truy cập có xu hướng phức tạp dần theo thời gian. Kiến trúc ban đầu cần đủ linh hoạt để hấp thụ sự phức tạp đó.
Logic phân quyền bị rải rác khắp nơi
Một trong những dấu hiệu nguy hiểm nhất là logic authorization nằm rải rác trong controller hoặc service. Mỗi endpoint tự kiểm tra quyền theo cách riêng. Ban đầu bạn có thể nắm được toàn bộ hệ thống trong đầu. Nhưng khi số lượng API tăng lên, không ai còn chắc chắn tất cả các đường đi đều đã được bảo vệ đúng cách.
Khi phân quyền không được tập trung hóa, việc thay đổi chính sách trở thành ác mộng. Bạn phải rà soát lại từng endpoint, từng điều kiện, và luôn có nguy cơ bỏ sót.
Một backend trưởng thành thường tách authorization thành một lớp rõ ràng, có quy tắc nhất quán và có thể kiểm thử độc lập. Điều này không chỉ giúp bảo mật tốt hơn mà còn giúp hệ thống dễ mở rộng.
Người học backend nên tự hỏi mỗi khi thêm một điều kiện kiểm tra quyền: mình đang giải quyết vấn đề đúng tầng kiến trúc chưa?
Phụ thuộc quá nhiều vào client
Có những hệ thống tin tưởng rằng nếu frontend không hiển thị nút “xóa”, thì người dùng sẽ không thể xóa. Đây là một giả định nguy hiểm.
Authorization phải luôn được thực thi ở phía server. Giao diện chỉ là lớp hiển thị. Nếu backend dựa vào logic phía client để kiểm soát quyền, hệ thống gần như chắc chắn sẽ gặp vấn đề khi có người dùng cố tình khai thác lỗ hổng.
Ở góc độ tư duy hệ thống, bạn cần nhìn backend như ranh giới cuối cùng bảo vệ dữ liệu và tài nguyên. Mọi quyết định về quyền truy cập phải được xác minh độc lập với client.
Thiếu chiến lược quản lý token và phiên làm việc
Authentication thường được triển khai bằng token hoặc session. Nhưng cách quản lý vòng đời của chúng mới là phần quan trọng.
Token có hết hạn không? Có cơ chế thu hồi không? Khi người dùng đổi mật khẩu, token cũ còn hiệu lực không? Khi quyền của người dùng thay đổi, hệ thống xử lý như thế nào?
Những câu hỏi này ít khi được đặt ra trong giai đoạn đầu. Nhưng khi hệ thống có hàng nghìn hoặc hàng triệu người dùng, những chi tiết nhỏ đó có thể trở thành yếu tố quyết định mức độ an toàn của toàn bộ backend.
Với người học backend, đây là lúc bạn nhận ra rằng authentication không chỉ là “verify token”, mà là quản lý toàn bộ vòng đời của danh tính trong hệ thống.
Không xem bảo mật như một phần của kiến trúc
Nhiều dự án xem authentication và authorization như phần bổ sung sau cùng. Tính năng được xây trước, bảo mật thêm vào sau. Cách tiếp cận này có thể tiết kiệm thời gian ngắn hạn, nhưng về dài hạn sẽ khiến hệ thống khó kiểm soát.
Khi bảo mật không được tích hợp vào tư duy thiết kế ngay từ đầu, bạn sẽ phải vá lỗi thay vì xây dựng cấu trúc bền vững. Và càng vá, hệ thống càng phức tạp.
Tư duy kiến trúc ở đây không phải là làm mọi thứ trở nên quá nặng nề, mà là đặt câu hỏi đúng từ đầu: ai được truy cập tài nguyên này? Trong điều kiện nào? Và khi điều kiện thay đổi, mình có thể điều chỉnh dễ dàng không?
Bài học nghề nghiệp: đừng xem nhẹ phần “ít thấy” nhất
Authentication và authorization hiếm khi tạo ra giao diện đẹp hoặc tính năng ấn tượng. Người dùng không nhìn thấy chúng. Nhưng khi chúng sai, hậu quả thường rất rõ ràng.
Với người học backend, việc hiểu sâu hai khái niệm này là một bước tiến lớn. Nó cho thấy bạn không chỉ quan tâm đến việc xây tính năng, mà còn quan tâm đến tính toàn vẹn của hệ thống.
Backend giỏi không chỉ là backend chạy nhanh. Đó là backend kiểm soát được ai đang làm gì, trong phạm vi nào, và có thể chứng minh điều đó một cách nhất quán.
Kết luận: phần dễ làm sai nhất lại là phần quan trọng nhất
Authentication và authorization dễ làm sai vì chúng thường được triển khai vội vàng. Nhưng một khi hệ thống đã đi vào vận hành, sửa lại phần này thường rất khó và đầy rủi ro.
Nếu bạn đang học backend, hãy xem đây là nền tảng chứ không phải phần phụ. Hiểu rõ sự khác biệt giữa xác thực và phân quyền. Thiết kế mô hình quyền có khả năng mở rộng. Tập trung hóa logic authorization. Quản lý vòng đời danh tính một cách cẩn trọng.
Đó không chỉ là kiến thức kỹ thuật. Đó là tư duy của một người xây dựng hệ thống có trách nhiệm với dữ liệu và người dùng.
INDA Academy tự hào là đơn vị tiên phong trong việc đào tạo phân tích dữ liệu và AI chuyên sâu, đặc biệt cho khối ngành Ngân hàng – Tài chính – Bảo hiểm tại Việt Nam. Sau hơn 12 năm “thực chiến” cùng những dòng chảy dữ liệu khổng lồ, chúng tôi đã xây dựng nên một hệ sinh thái đào tạo toàn diện, giúp hàng nghìn học viên chuyển mình từ người mới bắt đầu trở thành những chuyên gia lành nghề, sẵn sàng đáp ứng tiêu chuẩn khắt khe của các doanh nghiệp lớn.
Điểm khác biệt lớn nhất tại INDA chính là triết lý đào tạo dựa trên các dự án thực tế (Project-based) và lộ trình cá nhân hóa nhờ ứng dụng AI. Chúng tôi không chỉ dạy bạn cách sử dụng công cụ, mà còn truyền tải tư duy khai phá giá trị từ dữ liệu để đưa ra quyết định kinh doanh chính xác.
Tìm hiểu thêm về các khóa học TẠI ĐÂY:
Lộ trình đào tạo Data Engineer
Lộ trình đào tạo Data Analyst
Lộ trình đào tạo Tester
Khóa học Data Engineer nâng cao – Thực chiến 5 dự án doanh nghiệp
Khóa học Data Analyst nâng cao – Thực chiến 5 dự án doanh nghiệp
