1. 17:00 17/08/2026
Nhiều người cảnh giác khi một ứng dụng yêu cầu mật khẩu, nhưng lại dễ bấm Chấp nhận khi ứng dụng chuyển sang màn hình đăng nhập OAuth. Cơ chế này có thể giúp đăng nhập an toàn hơn vì người dùng không phải chia sẻ mật khẩu cho ứng dụng bên ngoài. Tuy nhiên, nếu cấp quyền quá rộng hoặc không thu hồi đúng lúc, tài khoản vẫn có thể trở thành cửa ngõ để đọc dữ liệu, gửi thư hoặc truy cập tệp.
OAuth hoạt động như thế nào?
Khi người dùng chọn đăng nhập bằng tài khoản doanh nghiệp, nhà cung cấp danh tính sẽ hiển thị danh sách quyền mà ứng dụng yêu cầu. Sau khi đồng ý, ứng dụng nhận được token thay vì mật khẩu. Token này đại diện cho một số quyền cụ thể và có thể tiếp tục hoạt động cho đến khi hết hạn hoặc bị thu hồi, tùy thiết kế của nhà cung cấp.
Ví dụ thực tế: một nhân viên muốn dùng công cụ lập lịch họp và cấp quyền đọc toàn bộ hộp thư, danh bạ cùng các tệp trên hệ thống lưu trữ. Nếu ứng dụng bị xâm nhập, bị bán cho chủ mới hoặc chỉ đơn giản là không còn được sử dụng, token cũ có thể tạo ra rủi ro lớn hơn nhiều so với nhu cầu ban đầu.
Các bước kiểm soát nên áp dụng
- Lập danh sách ứng dụng đã được cấp quyền: kiểm tra bảng điều khiển của nhà cung cấp email, hệ thống định danh và dịch vụ lưu trữ. Ghi nhận tên ứng dụng, chủ sở hữu, người cấp quyền, phạm vi quyền và ngày đánh giá gần nhất.
- Áp dụng nguyên tắc ít quyền nhất: công cụ chỉ cần tạo lịch không nên được phép đọc toàn bộ email. Nếu ứng dụng yêu cầu quyền quản trị hoặc quyền đọc dữ liệu diện rộng, cần có lý do, người phê duyệt và thời hạn rõ ràng.
- Bật quy trình phê duyệt tập trung: với tài khoản doanh nghiệp, quản trị viên nên hạn chế việc người dùng tự ý đồng ý cho ứng dụng chưa được kiểm tra. Danh sách ứng dụng tin cậy cần có người chịu trách nhiệm và chu kỳ rà soát.
- Thu hồi quyền khi thay đổi công việc: nhân viên chuyển bộ phận, nghỉ việc hoặc ngừng sử dụng dịch vụ phải được kiểm tra các kết nối OAuth, không chỉ đổi mật khẩu. Việc đổi mật khẩu không phải lúc nào cũng tự động vô hiệu hóa mọi token đã phát hành.
- Theo dõi dấu hiệu bất thường: chú ý ứng dụng mới xuất hiện, token được dùng từ vị trí lạ, hoạt động đọc dữ liệu tăng đột biến hoặc yêu cầu quyền mới sau một lần cập nhật.
Góc nhìn dành cho đội phát triển
Ứng dụng nên yêu cầu phạm vi quyền hẹp, dùng PKCE cho luồng phù hợp, kiểm tra tham số state để giảm nguy cơ liên kết phiên sai và chỉ chấp nhận redirect URI chính xác thay vì ký tự đại diện quá rộng. Access token nên có thời hạn hợp lý; refresh token cần được bảo vệ, luân phiên và thu hồi khi phát hiện bất thường. Không nên lưu token trong nơi dễ bị mã độc trên trình duyệt đọc được, cũng không ghi token vào log hoặc hệ thống theo dõi lỗi.
Một quy trình đơn giản nhưng hiệu quả là: đăng ký ứng dụng, mô tả quyền cần thiết, kiểm thử, phê duyệt, theo dõi và đánh giá lại theo chu kỳ. Khi có sự cố, hãy vô hiệu hóa ứng dụng hoặc thu hồi token trước, sau đó kiểm tra nhật ký truy cập, xác định dữ liệu đã bị đọc hay thay đổi, rồi mới khôi phục quyền cần thiết.
OAuth không phải là vấn đề cần loại bỏ. Rủi ro nằm ở việc cấp quyền theo thói quen và quên quản lý sau đó. Xem mỗi token như một chìa khóa có phạm vi, thời hạn và chủ sở hữu cụ thể sẽ giúp doanh nghiệp giảm đáng kể bề mặt tấn công từ các ứng dụng bên thứ ba.