Authelia: cổng 2FA và quy tắc truy cập đặt sau reverse proxy, từ mô hình đe dọa đến thử nghiệm
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Authelia: người gác cổng đứng cạnh reverse proxy, không phải một IdP đầy đủ
Authelia là máy chủ xác thực và phân quyền mã nguồn mở, cung cấp xác thực hai yếu tố (2FA) và đăng nhập một lần (SSO) qua một cổng web. README mô tả nó như người đồng hành của reverse proxy: proxy hỏi, Authelia trả lời cho phép, chặn hoặc chuyển hướng yêu cầu. Cách định vị này quan trọng, vì nó cho biết sản phẩm sinh ra để bảo vệ ứng dụng web phía sau proxy, không nhằm thay thế mọi chức năng quản lý danh tính. [1]
Thế mạnh theo tài liệu là bộ quy tắc kiểm soát truy cập khớp theo tên miền, đường dẫn, người dùng, nhóm, mạng và phương thức HTTP, kèm lựa chọn một hay hai yếu tố cho từng quy tắc. Ngoài ra dự án có phần OpenID Connect 1.0 để làm nhà cung cấp danh tính cho những ứng dụng biết nói giao thức này. [1][7]
Nên cân nhắc Authelia khi đội kỹ thuật nhỏ đã có reverse proxy, muốn thêm 2FA và quy tắc truy cập cho nhiều công cụ nội bộ mà không dựng cả một hệ thống danh tính nặng. Không nên chọn khi hạ tầng không thể bảo đảm mạng đủ tin cậy, như phần mô hình đe dọa sẽ giải thích. [10]
Khuyến nghị của bài: thử trên một tên miền phụ chứa công cụ ít quan trọng trước, kiểm tra kỹ các header chuyển tiếp, rồi mới nâng dần lên các hệ thống có dữ liệu nhạy cảm.
Công cụ nội bộ đang mở ra Internet chỉ với một ô mật khẩu
Rất nhiều đội vận hành dựng bảng điều khiển giám sát, trang quản trị, wiki hay môi trường thử rồi đặt sau một tên miền. Mỗi công cụ có cơ chế đăng nhập riêng, có khi chỉ là mật khẩu cơ bản, có khi không có gì. Thêm 2FA cho từng nơi là việc không thể làm đồng nhất, và nhân sự vào ra làm danh sách tài khoản phân tán.
Authelia thu hẹp bài toán này ở tầng cổng. Mỗi yêu cầu qua reverse proxy phát sinh một yêu cầu xác thực gửi tới Authelia, và Authelia chỉ dẫn cho proxy cho qua hay chặn. Theo tài liệu kiến trúc, phần dữ liệu của ứng dụng không đi qua Authelia, chỉ các thành phần xác thực như header Authorization mới tới đó. [3]
Điều mô hình này không làm được là biết ngữ cảnh nghiệp vụ bên trong ứng dụng. Authelia quyết định ai được vào miền nào, đường dẫn nào, không quyết định ai được xem hồ sơ nào trong ứng dụng. Phần đó vẫn phải do ứng dụng xử lý, một ranh giới cần nói rõ khi cân nhắc dùng cho dữ liệu cá nhân. [3][7]
Sơ đồ ba nhân vật: trình duyệt, reverse proxy và Authelia
Tài liệu kiến trúc mô tả Authelia kết nối trực tiếp với reverse proxy nhưng không bao giờ kết nối trực tiếp với backend của ứng dụng. Vì vậy các API được bảo vệ có thể là REST, GraphQL hay bất kỳ API HTTP nào. [3]
Quy trình theo tài liệu là: người dùng chưa đăng nhập vào ứng dụng, proxy hỏi Authelia, Authelia thấy không có cookie phiên nên chuyển người dùng tới cổng xác thực. Sau khi xác thực, trình duyệt nhận cookie phiên có hiệu lực cho mọi tên miền con của miền được bảo vệ. Lần truy cập sau cookie được chuyển cho Authelia và proxy được lệnh cho qua. [3]
README liệt kê các proxy được hỗ trợ gồm nginx, Traefik, Caddy, Skipper, Envoy và HAProxy, cùng một số Ingress Controller và Gateway trên Kubernetes. Authelia cũng được mô tả là có thể chạy độc lập từ gói cài, nhị phân tĩnh hoặc container, và dùng cơ sở dữ liệu từ xa cùng Redis để đạt tính sẵn sàng cao. Bản Lite trong gói compose dùng lưu trữ người dùng bằng tệp và SQLite, và README nói rõ nó không mở rộng tốt. [1]
Ba hồi của một yêu cầu: header chuyển tiếp, cookie phiên, mã phản hồi
Hồi thứ nhất là nhận diện đích đến. Tài liệu tích hợp proxy cho biết Authelia dựa vào các header do proxy đặt: X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-URI, X-Forwarded-For, cùng phương thức và URL gốc tùy cách triển khai điểm authz. Nếu thiếu hoặc sai, Authelia không biết yêu cầu nhắm vào đâu nên không áp dụng đúng quy tắc, cũng như sai miền cho cookie hay sai địa chỉ công khai. [8]
Hồi thứ hai là nhận diện người dùng. Có hai cách: cookie phiên với cờ HttpOnly và Secure, hoặc header Proxy-Authorization theo kiểu basic. README nói cách thứ hai dùng được cho điểm cuối nằm dưới chính sách một yếu tố. Kết quả danh tính được đối chiếu với bộ quy tắc kiểm soát truy cập. [1][8]
Hồi thứ ba là phản hồi. Theo tài liệu, nếu người dùng đã xác thực và được phép, Authelia trả 200 OK. Nếu cần xác thực một yếu tố hoặc nâng lên hai yếu tố thì người dùng được chuyển tới cổng, với 401 cho yêu cầu XMLHttpRequest. [8]
Ba quyết định kiến trúc đã ghi lại: điều Authelia cố tình không làm
Kho chứa một nhật ký quyết định kiến trúc, và ba bản ghi cho thấy tư duy thiết kế. ADR1 giải thích rằng quy tắc kiểm soát truy cập không tương thích với luồng mã cấp quyền của OpenID Connect, vì phương thức, URI tài nguyên, tham số truy vấn và IP máy khách không được truyền tới nhà cung cấp OpenID, và luồng này chỉ diễn ra một lần khi đăng nhập. Kết luận là việc phân quyền thường nên làm ở ứng dụng khách. [4]
ADR3 ghi nhận đề xuất dùng nhãn Docker để định nghĩa quy tắc truy cập đã bị từ chối nhiều lần, cuối cùng ngày 2026-04-04. Lý do gồm nhãn không có thứ tự trong khi quy tắc khớp đầu tiên quyết định kết quả, quy tắc phức tạp khó mã hóa thành nhãn, khó hợp nhất với tệp cấu hình, chính sách thay đổi ngầm theo trạng thái container và nhu cầu truy cập socket Docker. [6]
ADR2 về cấu hình qua biến môi trường và secret ở trạng thái Proposed, phần quyết định ghi N/A. Nội dung chỉ ra danh sách chứa đối tượng khó cấu hình qua biến môi trường vì thiếu bộ phân tích, và đề xuất dùng template để nạp. Đây là hạn chế thực tế cho ai muốn quản lý toàn bộ cấu hình phức tạp bằng biến môi trường. [5]
Tính năng đã xác minh, tách rõ phần ổn định, phần beta và phần chỉ nằm trong kế hoạch
README liệt kê các phương thức yếu tố thứ hai: khóa bảo mật FIDO2 WebAuthn, mật khẩu một lần theo thời gian (TOTP) và thông báo đẩy qua Duo. Ngoài ra có đăng nhập không mật khẩu bằng WebAuthn passkey, đặt lại mật khẩu có xác minh qua email, và hạn chế truy cập sau quá nhiều lần thử sai. [1]
Về OpenID Connect, README nói Authelia được chứng nhận OpenID cho các hồ sơ Basic OP, Implicit OP, Hybrid OP, Form Post OP và Config OP, đồng thời thừa nhận phần này vẫn thực chất nằm ở trạng thái beta trên lộ trình. Vì vậy bài không gọi nó là tính năng ổn định hoàn toàn. [1]
Về kiểm soát truy cập, quy tắc có thể khớp tên miền, biểu thức chính quy cho đường dẫn, chủ thể như nhóm, phương thức và dải mạng, như ví dụ cấu hình trong tài liệu. Tài liệu ADR3 bổ sung rằng đánh giá theo thứ tự nghiêm ngặt, quy tắc đầu tiên khớp quyết định chính sách, và nếu không khớp quy tắc nào thì dùng chính sách mặc định. [6][7]
Ai nên cân nhắc: đội nhỏ, nhiều công cụ web, đã có reverse proxy
Người hưởng lợi nhiều nhất là đội hạ tầng nhỏ vận hành nhiều dịch vụ web nội bộ trên Traefik, nginx hay Caddy, cần 2FA và quy tắc theo miền mà không muốn đụng vào từng ứng dụng. Với họ, thêm Authelia nghĩa là thêm một dịch vụ cạnh proxy và một tệp cấu hình quy tắc. [1][3]
Nhóm thứ hai là người tự lưu trữ dịch vụ và muốn cấu hình nằm trong Git. ADR3 nhấn mạnh quy tắc nằm trong tệp để thứ tự rõ ràng, kiểm toán được và đặt dưới quản lý phiên bản. [6]
Nhóm ít phù hợp gồm tổ chức cần mô hình đe dọa không giả định mạng nội bộ đáng tin. Với hệ thống như BDSG Foundation hay phamvanthu.com, nếu có nhiều công cụ tri thức nội bộ đặt sau proxy, đây là kiểu bài toán có thể thử, nhưng bài không khẳng định tổ chức nào đang dùng.
Tình huống giả định: nền tảng tuyển dụng khóa các công cụ vận hành sau một cổng 2FA
Hình dung một nền tảng tuyển dụng trực tuyến tại Hà Nội, khoảng 80 nhân sự, nơi nhà tuyển dụng đăng tin và ứng viên tải hồ sơ. Ngoài sản phẩm công khai, đội vận hành có nhiều công cụ nội bộ: bảng điều khiển giám sát, công cụ phân tích dữ liệu, trang quản trị nội dung tin tuyển dụng, wiki và vài môi trường thử. Phạm vi đề xuất chỉ là các công cụ nội bộ này, không phải đăng nhập của ứng viên hay nhà tuyển dụng. Đây là tình huống giả định.
Mọi công cụ đã nằm sau Traefik hoặc nginx. Đề xuất là thêm Authelia và gán mỗi tên miền con một chính sách. Wiki chỉ cần một yếu tố từ mạng văn phòng hoặc VPN, bảng giám sát cần hai yếu tố, còn công cụ xem hồ sơ ứng viên để quản trị cần hai yếu tố kèm giới hạn nhóm. Các loại điều kiện này, gồm tên miền, nhóm, mạng và phương thức, khớp với bộ tiêu chí mà tài liệu mô tả. [1][7]
Dữ liệu hồ sơ ứng viên gồm thông tin cá nhân, nên có ba lưu ý. Authelia chỉ quyết định ai vào công cụ, còn việc ai được xem hồ sơ nào phải do công cụ xử lý. Header Remote-User và các header danh tính truyền xuống backend không được ký, nên backend phải nằm trong mạng tin cậy. [3][10]
Triển khai thử đề xuất bắt đầu ở một tên miền phụ cho công cụ ít nhạy cảm, dùng backend người dùng bằng tệp với vài tài khoản, sau đó chuyển sang LDAP nếu công ty có sẵn thư mục. Việc chọn nguồn người dùng, yêu cầu pháp lý về dữ liệu cá nhân và nhật ký truy cập nằm ngoài nguồn đã đọc; đội cần tra cứu tài liệu cấu hình tương ứng và tham vấn pháp chế. [10]
Vận hành từ ngày đầu: ghim phiên bản, đọc ghi chú phát hành, kiểm tra header
README nêu rõ Authelia đang được phát triển tích cực nên có thể có thay đổi phá vỡ tương thích. Khuyến nghị của dự án là ghim thẻ phiên bản thay vì dùng latest, và đọc ghi chú phát hành trước khi nâng cấp. Cổng xác thực lỗi sau nâng cấp có thể khóa cả các công cụ phía sau. [1]
Tài liệu tích hợp proxy yêu cầu đọc hướng dẫn kiểm chứng xác thực chuyển tiếp (validating forwarded authentication) trước khi triển khai, và khuyên người mới đọc hướng dẫn bắt đầu. Danh sách header bắt buộc được coi là một phần cấu hình được hỗ trợ và được giả định có mặt trong các phát triển sau này. Vì vậy, kiểm thử tự động nên gồm một bước xác nhận proxy truyền đúng header. [8]
Cuối cùng là cấu hình. ADR2 cho thấy danh sách đối tượng không dễ cấu hình bằng biến môi trường, nên tệp cấu hình trong Git, kèm template để nạp secret, là hướng thực tế hơn. [5]
Mô hình đe dọa: mạnh ở cổng, nhưng giả định mạng bên trong đáng tin
Tài liệu mô hình đe dọa nêu Authelia chạy trong mạng được coi là tin cậy và phụ thuộc mạnh vào lớp bảo vệ đầu tiên của reverse proxy. Các bảo đảm nếu cấu hình đúng gồm: ứng dụng không truy cập được nếu thiếu phép, hỗ trợ 2FA, phiên có hạn mềm và hạn cứng, chống dò mật khẩu bằng cơ chế điều tiết, yêu cầu xác minh danh tính khi đăng ký thiết bị 2FA, tạo phiên mới sau khi nâng đặc quyền và phòng chống tiêm LDAP. [10]
Phần quan trọng không kém là giới hạn. Yêu cầu tới Authelia lẽ ra do reverse proxy khởi tạo nhưng hiện máy chủ nào khác cũng có thể gửi, vì giữa hai bên chưa có quan hệ tin cậy. Các header Remote-User, Remote-Name, Remote-Email và Remote-Groups truyền cho backend không được ký, nên kẻ trong mạng có thể giả mạo. Dự án chọn đầu tư vào OpenID Connect để giải quyết bài toán ủy quyền này. [10]
Tài liệu cũng liệt kê các bảo đảm tương lai như gắn cookie phiên với IP, xác thực giữa Authelia và proxy, cho phép cấu hình proxy tin cậy. Vì tệp tài liệu có thể chưa phản ánh hết trạng thái hiện tại, bài coi đây là danh sách có thể đã lỗi thời và phải đối chiếu với cấu hình thực tế. Về lỗ hổng, dự án theo mô hình công bố có phối hợp và yêu cầu báo riêng, không mở issue công khai. [9][10]
Với dữ liệu cá nhân, cần giữ HTTPS, tách mạng giữa proxy, Authelia và backend, và hạn chế người đọc nhật ký. Ngoài ra README nêu dự án đang tìm tài trợ cho kiểm toán bảo mật mã nguồn, nên bài không coi là đã được kiểm toán độc lập. [1]
Apache-2.0 và những thứ giấy phép này không phủ tới
Tệp LICENSE tại commit đã ghim là văn bản Apache License 2.0, với dòng bản quyền 2026 Authelia. README cũng khẳng định Authelia theo giấy phép Apache 2.0 và các tệp tài liệu đã đọc mang nhãn SPDX Apache-2.0. Giấy phép cho phép dùng, sửa và phân phối, kể cả thương mại, với điều kiện giữ thông báo và tuân thủ các điều khoản về bằng sáng chế. [1][2][3]
Danh sách tệp ở commit còn cho thấy thư mục LICENSES chứa văn bản Apache-2.0, BSD-3-Clause, MIT, OFL-1.1 và một tệp có tên LicenseRef-Trademark. Bài chưa đọc các tệp này nên không thể nói chính xác chúng áp dụng cho phần nào, chỉ ghi nhận rằng kho không chỉ có một giấy phép và có vẻ có điều khoản nhãn hiệu riêng. Nhóm triển khai cần đọc trước khi dùng tên hay logo Authelia.
Giấy phép bao quát mã nguồn tại commit này, không bao gồm các phụ thuộc bên thứ ba, ảnh container được dựng riêng, dịch vụ thuê ngoài hay thiết bị bảo mật. Trong các tệp đã đọc không có dấu hiệu một bản thương mại tách biệt hay thư mục có giấy phép hạn chế, nhưng đó là nhận xét giới hạn theo tệp đã đọc. [1][2]
Chi phí: ít phần mềm, nhiều kỷ luật
Không có phí bản quyền cho phần mã trong kho, theo giấy phép đã đọc. Nguồn lực cần cho một triển khai đơn giản gồm thời gian kỹ sư để cấu hình quy tắc và proxy, một máy ảo hoặc container nhỏ cho Authelia, nơi lưu trữ người dùng và phiên, thời gian giám sát và bảo trì sau mỗi lần nâng cấp phiên bản. Bài không đưa giá vì không có nguồn đã đọc. [1]
Nếu cần tính sẵn sàng cao thì thêm cơ sở dữ liệu từ xa và Redis, tức hai thành phần nữa phải vận hành, sao lưu và vá lỗi. Thời gian triển khai thật do đội tự đo. [1]
Khoản chi hay bị quên là cho sự cố. Nếu cổng xác thực lỗi, các công cụ phía sau có thể không vào được, nên cần tài khoản khẩn cấp và đường truy cập dự phòng, được phê duyệt và giám sát. Phần hạ tầng này thuộc thiết kế của đơn vị triển khai.
Đặt cạnh các lựa chọn khác: proxy xác thực, IdP đầy đủ và dịch vụ trả phí
Ở mức cách tiếp cận có ba hướng. Hướng thứ nhất là cổng xác thực phía proxy như Authelia, tập trung vào bảo vệ ứng dụng web với quy tắc truy cập. Hướng thứ hai là IdP đầy đủ như authentik hoặc Keycloak, quản lý danh tính theo hướng rộng hơn một cổng đứng cạnh proxy. Hướng thứ ba là dịch vụ danh tính trả phí do nhà cung cấp vận hành.
Điểm khác biệt có thể xác minh từ nguồn: Authelia tự mô tả là companion của reverse proxy, mô hình đe dọa giả định mạng tin cậy và header danh tính không được ký. Bài không có nguồn để nêu cụ thể tính năng của Keycloak hay authentik trong phần này. [3][10]
Cách chọn gợi ý: chỉ cần chặn và đòi 2FA trước nhiều ứng dụng web thì hướng proxy đơn giản hơn; cần vòng đời người dùng hay đăng ký tự phục vụ thì xem IdP đầy đủ; không muốn tự vận hành thì xem dịch vụ trả phí.
Hạn chế và những trường hợp không nên dùng
Hạn chế đầu tiên là giả định mạng tin cậy. Header Remote-* không được ký và không có quan hệ tin cậy giữa Authelia với proxy, nên phân đoạn mạng kém sẽ làm giảm giá trị của 2FA. Hạn chế thứ hai là OpenID Connect vẫn được mô tả ở trạng thái beta trên lộ trình, dù đã có chứng nhận. [1][10]
Hạn chế thứ ba là cấu hình phức tạp có giới hạn: danh sách đối tượng khó qua biến môi trường, và dự án từ chối cấu hình quy tắc bằng nhãn Docker. [5][6]
Không nên dùng khi hệ thống chỉ phục vụ HTTP, khi thiếu reverse proxy chuẩn, hoặc khi cần bảo vệ truy cập chi tiết ở mức bản ghi trong ứng dụng. Cũng không nên dùng nếu đội không thể theo dõi ghi chú phát hành, vì README cảnh báo về thay đổi phá vỡ tương thích. [1][3]
Kế hoạch thử sáu tuần, có tiêu chí vào và ra
Tuần 1 và 2: dựng Authelia ở môi trường thử sau cùng loại proxy với sản xuất, chỉ bảo vệ một tên miền phụ. Kiểm tra bằng ca thử: người chưa đăng nhập bị chuyển hướng, người đã đăng nhập vào được, yêu cầu XMLHttpRequest nhận 401. Tiêu chí: mọi ca đúng như tài liệu mô tả, và danh sách header bắt buộc được proxy truyền đầy đủ. [8]
Tuần 3 và 4: viết bộ quy tắc cho ba nhóm công cụ với chính sách một và hai yếu tố, thử các điều kiện theo nhóm, mạng và phương thức. Với mỗi quy tắc, viết ca cho phép và ca chặn. Do thứ tự quyết định kết quả nên cần đảo thứ tự để chắc chắn kiểm thử bắt được lỗi. Tiêu chí đề xuất: không ca nào cho truy cập sai. [6][7]
Tuần 5: thử vận hành, gồm nâng cấp phiên bản, mất kết nối cơ sở dữ liệu hoặc Redis nếu dùng, và đăng ký lại thiết bị 2FA. Đo thời gian khôi phục. Tuần 6: kiểm tra phân đoạn mạng để bảo đảm backend chỉ nhận yêu cầu từ proxy, và rà soát mô hình đe dọa với đội bảo mật. [1][10]
Tiêu chí dừng: không giữ được tính đúng của header sau nâng cấp, không đảm bảo mạng backend tin cậy, hoặc đội thấy chi phí vận hành cao hơn lợi ích. Các ngưỡng số do đội đặt trước khi bắt đầu.
Kết luận: tốt khi hiểu đúng vai trò của một người gác cổng
Authelia cung cấp 2FA và quy tắc truy cập đứng cạnh reverse proxy, với kiến trúc đơn giản dễ hiểu và nhật ký quyết định minh bạch về những điều dự án cố tình không làm. Tài liệu tại commit đã ghim đủ để hình dung đầy đủ luồng yêu cầu, ràng buộc header và phản hồi. [3][6][8]
Cần nhớ rằng đây là tài liệu tại một commit và Authelia còn thay đổi phá vỡ tương thích giữa các bản, nên mọi kết luận cần kiểm tra lại trước khi triển khai. [1]
Điều kiện quan trọng là mạng bên trong phải đáng tin và HTTPS phải bắt buộc, vì header danh tính không được ký. Với nền tảng tuyển dụng trong tình huống giả định, bước hợp lý là thử ở phạm vi nhỏ, đo, rồi mới mở rộng. [10]
Nguồn và phương pháp
Đây là nghiên cứu tại bàn (desk research), không phải công bố khoa học được bình duyệt. Dự án được chọn từ kho lưu trữ GitHub Trending có phạm vi giới hạn: chỉ gồm danh sách Python, Go, JavaScript và Swift, thiếu các ngày 2026-09-03 và 2026-10-12, và không phải bảng xếp hạng chính thức top 100. Authelia xuất hiện 19 lần, từ 2026-02-03 đến 2026-10-02; bằng chứng được dẫn là trang ngày 2026-02-03, vị trí 17 trong danh sách Go. [11]
Nội dung được kiểm tra ngày 2026-10-12 tại commit a4aec2d5dbb92c11b4fa12a90f6022f411f9ca3d, ngày commit 2026-10-10. Các tệp đã đọc gồm README, LICENSE, tài liệu kiến trúc, ba bản ghi quyết định kiến trúc, và bốn tài liệu bổ sung ở cùng commit: kiểm soát truy cập, giới thiệu tích hợp proxy, giới thiệu bảo mật và mô hình đe dọa. [1][2][3][4][5][6][7][8][9][10]
Tác giả không cài đặt, chạy, đo hiệu năng hay triển khai Authelia. Tình huống, kế hoạch thử và giả định chi phí là đề xuất, mọi số liệu chỉ lấy từ nguồn đã trích dẫn.
Xem mã nguồn Authelia trên GitHub