// docs / baas security / auth0 hardening

Danh sách kiểm tra bảo mật Auth0: 22 mục

Auth0 là một nền tảng identity-as-a-service với bề mặt khổng lồ — ứng dụng, API (resource server), tenant, action, rule (cũ), connection và grant. Cấu hình sai bất kỳ cái nào trong số chúng đều là một auth bypass. Danh sách kiểm tra này là một kiểm toán 22 mục trên các ứng dụng, danh sách trắng callback / logout, token và xoay vòng refresh, custom action, RBAC, phát hiện bất thường và giám sát liên tục. Mỗi mục có thể xác minh trong Auth0 Dashboard trong dưới 10 phút.

Để xem danh sách kiểm tra tương đương trên Clerk, xem Danh sách kiểm tra bảo mật Clerk. Để hiểu lý do tại sao các cấu hình sai lớp danh tính là điểm mù của công cụ AI, xem Vì sao công cụ AI lập trình để lại lỗ hổng bảo mật.

Loại ứng dụng và loại grant

Loại ứng dụng và các loại grant được bật là các cài đặt có ảnh hưởng cao nhất trong Auth0. Sai chúng mở ra các lớp tấn công mà không có lượng mã frontend nào có thể đóng lại.

Dùng Application Type = Single Page Application cho các ứng dụng chỉ trình duyệt và Regular Web Application cho các ứng dụng render phía server. Loại sai cho phép các loại grant sai — ví dụ, một Regular Web App với SPA grant bật flow Implicit không PKCE, làm rò rỉ token qua URL fragment.
Tắt loại grant Implicit trên mọi ứng dụng. Dashboard → Application → Advanced Settings → Grant Types → bỏ chọn Implicit. Flow Implicit trả về token trong URL fragment, nơi chúng được ghi trong lịch sử trình duyệt và analytics. Dùng Authorization Code với PKCE thay vào đó.
Tắt grant Password trừ khi bạn có nhu cầu được tài liệu hóa. Grant Resource Owner Password Credentials (ROPC) yêu cầu bạn tự xử lý mật khẩu người dùng — đánh bại hầu hết những gì bạn đã mua Auth0 để làm. Hãy tắt nó trừ khi tích hợp hệ thống cũ.
Bật Authorization Code với PKCE trên mọi client công khai. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = bật. PKCE là bắt buộc cho ứng dụng di động và SPA để ngăn chặn việc chặn code.

Danh sách trắng URL callback và logout

Open redirect trên đường dẫn callback OAuth là một primitive đánh cắp token. Danh sách trắng của Auth0 là phòng thủ duy nhất của bạn.

Đặt Allowed Callback URLs là đường dẫn callback production chính xác của bạn — không ký tự đại diện. https://yourapp.com/callback, không phải https://yourapp.com/*. Callback ký tự đại diện cho phép kẻ tấn công chuyển hướng token đến các subpath tùy ý trên tên miền của bạn.
Đặt Allowed Logout URLs thành danh sách hữu hạn. Cùng quy tắc: chỉ URL rõ ràng. Một redirect logout mở cho phép kẻ tấn công tạo các trang lừa đảo trông giống trạng thái sau logout của bạn.
Đặt Allowed Web Origins thành chỉ origin production của bạn. Được dùng cho xác thực ngầm (làm mới token qua iframe ẩn). Một origin ký tự đại diện cho phép các trang của kẻ tấn công thực hiện auth ngầm với tenant của bạn.
Đặt Allowed CORS origins cho các endpoint API, không phải cho ứng dụng. Tenant Settings → Advanced → Allowed CORS origins. Mặc định là rỗng (bị hạn chế); chỉ thêm các origin rõ ràng mà bạn kiểm soát.

Token và xoay vòng refresh

Thời hạn token, xoay vòng refresh và thuật toán ký quyết định bán kính ảnh hưởng của bất kỳ rò rỉ token nào.

Bật Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Mỗi refresh phát hành một refresh token mới và làm vô hiệu hóa cái cũ. Kết hợp với thời hạn tuyệt đối, điều này hạn chế việc đánh cắp token.
Đặt Refresh Token Reuse Interval thành 0 (hoặc thấp nhất mà khả năng chịu phát lại của bạn cho phép). Khoảng thời gian tái sử dụng cho phép một token được dùng hai lần trong cùng cửa sổ — hãy tắt nó trừ khi bạn có lý do cụ thể để giữ.
Đặt Absolute Refresh Token Expiry thành 14-30 ngày, không phải vô hạn. Application → Refresh Token Expiration → Absolute Expiration. Auth0 mặc định chỉ Inactivity, có nghĩa là một phiên không hoạt động có thể tồn tại nhiều năm.
Đặt JWT Signature Algorithm thành RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 sử dụng ký bất đối xứng nên client không thể giả mạo token. Đừng bao giờ dùng HS256 cho ứng dụng đối mặt với client.
Xác minh claim aud và iss trên mọi JWT mà API của bạn nhận. Dùng SDK Auth0 chính thức ở phía server — nó xác minh chúng tự động. Phân tích JWT thủ công thường bỏ qua xác thực audience, đó là một auth bypass.

Action và mã tùy chỉnh

Auth0 Actions (và Rules cũ) chạy phía server tại đăng nhập và các sự kiện vòng đời khác. Chúng có quyền truy cập vào toàn bộ ngữ cảnh yêu cầu. Mã không an toàn ở đây là một lỗ hổng phạm vi toàn tenant.

Đừng bao giờ log event.user hoặc event.transaction như một object toàn bộ. Chúng chứa địa chỉ email, địa chỉ IP và PII khác. Chỉ dùng log cấp trường, và chỉ log những gì bạn cần.
Dùng kho secret cho bất kỳ API key hoặc URL webhook nào. Actions → Edit → Secrets. Đừng bao giờ nội tuyến một API key dưới dạng chuỗi literal trong mã action — mã có thể nhìn thấy bởi bất kỳ ai có quyền truy cập trình chỉnh sửa Action trên tenant.
Xác thực đầu vào trước khi lưu chúng dưới dạng user_metadata hoặc app_metadata. Một action tự phục vụ ghi event.body.name vào user.user_metadata.display_name là một vector XSS đã lưu nếu frontend của bạn render trường đó mà không escape.

RBAC và resource server

Nếu bạn dùng Auth0 RBAC, ánh xạ vai trò-tới-quyền là lớp ủy quyền của bạn. Sai nó thì bất kỳ người dùng đã xác thực nào cũng có thể chạm vào các endpoint admin.

Định nghĩa Resource Server (API) rõ ràng trong Auth0 Dashboard, không phải ngay tại chỗ. Mỗi API có một định danh (audience), scope và cài đặt ký. Không có API đã đăng ký, mọi token được phát hành cho "Auth0 Management API" ngầm định — sai audience.
Cấu hình Permissions cho mỗi API và yêu cầu chúng trong mã của bạn với claim scope. Đừng kiểm tra thành viên vai trò trong logic ứng dụng; kiểm tra scope trong access token. Scope là cơ chế ủy quyền native của OAuth.
Kiểm tra rằng một người dùng đã xác thực không có vai trò / scope yêu cầu không thể chạm vào các endpoint đặc quyền. Đăng nhập với tư cách người dùng thường, thử gọi POST /api/admin/users/delete. Phản hồi phải là 403.

Phát hiện bất thường và log tenant

Auth0 phát ra các sự kiện có tín hiệu cao. Hãy thiết lập chúng để cảnh báo nhóm của bạn, không chỉ để nằm trong bộ đệm log.

Bật Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Mỗi cái đều tắt mặc định ở các gói miễn phí; bật tất cả cho production.
Stream log tenant đến một SIEM hoặc log ứng dụng của bạn. Dashboard → Monitoring → Streams. Auth0 lưu giữ log 30 ngày trên hầu hết các gói; lưu giữ dài hạn yêu cầu một stream vào hệ thống của riêng bạn.
Cảnh báo khi tăng đột biến fcoa (failed cross-origin auth) và fp (failed login). Một đợt bùng phát các sự kiện này trong cửa sổ ngắn là credential stuffing. Định tuyến đến kênh on-call của bạn.

Các bước tiếp theo

Chạy một lượt quét FixVibe với URL production — check baas.clerk-auth0 đánh dấu các client secret Auth0 trong bundle JavaScript và các lớp phơi nhiễm nhà cung cấp danh tính khác. Để xem tương đương trên Clerk, xem Danh sách kiểm tra bảo mật Clerk. Để có cái nhìn tổng quát trên các nhà cung cấp BaaS, đọc BaaS misconfiguration scanner.