Bạn có tám container Docker đang chạy trên một VPS. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, một trang trạng thái và một ứng dụng nội bộ do chính bạn viết. Mỗi cái có đăng nhập riêng. Sáng nào bạn cũng sao chép mật khẩu từ trình quản lý mật khẩu, và bắt đầu tự hỏi liệu đăng nhập một lần có đáng với chi phí vận hành hay không.
Thường là đáng. Câu hỏi là nên chạy nhà cung cấp danh tính nào.
Keycloak là lựa chọn mặc định quen thuộc, nhưng lựa chọn phù hợp hơn phụ thuộc vào stack của bạn trông thế nào, bạn quản lý bao nhiêu người dùng, và bạn đang tích hợp phần mềm đã chạy sẵn hay đang xây dựng xác thực vào chính ứng dụng của mình.
Bài so sánh SSO tự lưu trữ này xem xét Authentik, ZITADEL, Keycloak và Authelia qua những quyết định quan trọng sau khi triển khai: hỗ trợ giao thức, quản lý người dùng, quy trình làm việc của lập trình viên, yêu cầu tài nguyên, và điều gì xảy ra khi nhà cung cấp danh tính của bạn ngừng hoạt động.
Vì sao SSO tự lưu trữ quan trọng
Khi nhiều ứng dụng phụ thuộc vào cùng một nhóm người và nhóm quyền, các đăng nhập riêng lẻ không còn tiện nữa. Một nhà cung cấp danh tính tự lưu trữ cho bạn một nơi duy nhất để quản lý tài khoản, MFA, thành viên nhóm và chính sách truy cập, thay vì cấu hình các kiểm soát đó riêng rẽ trong từng ứng dụng.
Sự đánh đổi cũng quan trọng không kém: IdP trở thành hạ tầng mà các ứng dụng khác phụ thuộc vào. Đăng nhập mới và làm mới token có thể thất bại khi nó không khả dụng, nên sao lưu, quyền truy cập khôi phục, nâng cấp và thời gian hoạt động quan trọng hơn nhiều so với một ứng dụng tự lưu trữ thông thường.
Tóm tắt nhanh
Chọn Authentik nếu bạn muốn lựa chọn mặc định tốt nhất
Với một homelab, một stack công cụ nội bộ hoặc một nhóm nhỏ kết nối các ứng dụng sẵn có qua OIDC hoặc SAML, Authentik là lựa chọn mặc định vững nhất. Quy trình quản trị của nó dễ tiếp cận hơn Keycloak, nó hỗ trợ nhiều phương thức tích hợp, và cấu hình Docker Compose chính thức bắt đầu từ 2 nhân CPU và 2 GB RAM.
Chọn ZITADEL nếu bạn đang xây dựng ứng dụng
Chọn ZITADEL khi xác thực là một phần của sản phẩm bạn đang xây dựng. Mô hình tổ chức, API, đa người thuê, OIDC, SAML, passkey, MFA và hỗ trợ nhà cung cấp danh tính LDAP của nó hợp lý hơn với các nhóm ứng dụng SaaS và B2B so với một homelab điển hình.
Chọn Keycloak nếu bạn cần các tính năng danh tính cấp doanh nghiệp
Chọn Keycloak khi bạn cần liên kết LDAP hoặc Active Directory sâu hơn, nhiều realm, chính sách ủy quyền chi tiết, hoặc một môi trường vốn đã xây dựng quanh Keycloak. Tài liệu của nó khuyến nghị giới hạn bộ nhớ 2 GB cho các container Keycloak nhỏ sẵn sàng cho môi trường production; một VPS tất cả trong một chạy cả PostgreSQL cần thêm dư địa.
Lựa chọn thay thế: Chọn Authelia nếu bạn chủ yếu cần một lớp chặn đăng nhập
Chọn Authelia khi vấn đề chính của bạn là bảo vệ ứng dụng ở tầng reverse proxy thay vì vận hành một nền tảng danh tính đầy đủ. Nó cũng có thể đóng vai trò nhà cung cấp OpenID Connect, nhưng xác thực tại reverse proxy vẫn là trọng tâm của nó.
Cần kiểm tra gì trước khi chọn công cụ SSO
Trước khi so sánh tính năng, hãy đối chiếu từng công cụ với các ứng dụng, giao thức và nguồn danh tính mà bạn đã cần hỗ trợ.
Có bao nhiêu ứng dụng cần SSO?
Hãy bắt đầu từ ứng dụng, không phải từ nhà cung cấp danh tính. Một stack có sáu ứng dụng đã hỗ trợ OIDC hoặc SAML là một bài toán khác với một stack toàn công cụ nội bộ cũ không biết gì về cả hai giao thức. Trường hợp đầu hướng tới một IdP đầy đủ. Trường hợp sau có thể cần xác thực ở tầng reverse proxy.
Ứng dụng của bạn có hỗ trợ OIDC hoặc SAML không?
OIDC là lựa chọn phổ biến cho các ứng dụng web hiện đại. SAML vẫn quan trọng trong phần mềm doanh nghiệp và các tích hợp cũ hơn. LDAP có thể quan trọng khi ứng dụng mong đợi một thư mục thay vì một luồng SSO trên web. Hãy kiểm tra từng ứng dụng thực sự chấp nhận gì trước khi chọn IdP đứng ở giữa.
Bạn đang quản lý người dùng hay đang xây dựng đăng nhập vào một ứng dụng?
Nếu phần lớn công việc của bạn diễn ra trong giao diện quản trị khi kết nối các ứng dụng sẵn có, Authentik là điểm khởi đầu tự nhiên. Nếu xác thực là một phần của sản phẩm bạn đang xây dựng và bạn dự định tạo tổ chức, người dùng và quyền bằng mã, ZITADEL gần với quy trình đó hơn nhiều.
Bạn có cần LDAP, Active Directory hay chính sách nâng cao không?
Authentik, ZITADEL và Keycloak đều có thể kết nối với các nguồn danh tính dựa trên LDAP ở một dạng nào đó, nên riêng LDAP không còn quyết định cuộc so sánh. Keycloak trở nên đáng chú ý hơn khi liên kết thư mục đi kèm nhiều realm, các mapper chi tiết, yêu cầu đồng bộ hoặc chính sách ủy quyền ở cấp tài nguyên.
Authentik vs ZITADEL vs Keycloak vs Authelia
Bốn công cụ trùng nhau ở SSO, nhưng tiếp cận danh tính từ những hướng khác nhau: tích hợp ứng dụng, danh tính sản phẩm, IAM doanh nghiệp và truy cập qua reverse proxy.
Authentik
Authentik chạy triển khai lõi gồm một máy chủ, một worker và một cơ sở dữ liệu PostgreSQL. Redis không còn là một phần của stack: Authentik đã loại bỏ hoàn toàn phụ thuộc này trong bản phát hành 2025.10. Tài liệu Docker Compose hiện tại yêu cầu một máy chủ có ít nhất 2 nhân CPU và 2 GB RAM.
Đặc điểm nổi bật là giao diện quản trị. Công cụ luồng của Authentik, việc cấp phát ứng dụng và các chính sách theo nhóm dễ tiếp cận hơn mô hình cấu hình rộng hơn của Keycloak. Nếu bạn từng thiết lập một ứng dụng OIDC trong Keycloak rồi mất thời gian tìm hiểu vì sao các claim trong token bị thiếu, bạn sẽ nhận ra sự khác biệt rất nhanh.
Nó hỗ trợ SAML, OAuth2/OIDC, LDAP và RADIUS. Đây là lựa chọn mặc định đúng cho một homelab hoặc một nhóm kỹ thuật nhỏ chạy một stack ứng dụng tự lưu trữ.
ZITADEL
ZITADEL được viết chủ yếu bằng Go, cấp phép AGPL-3.0 và đang ở dòng phát hành v4.x. Bản triển khai gồm một API bằng Go, một giao diện đăng nhập Next.js và PostgreSQL, và yêu cầu hiện tại hỗ trợ PostgreSQL từ 14 đến 18. Tài liệu Docker Compose chính thức yêu cầu một máy chủ có ít nhất 2 GB RAM.
Đặc điểm nổi bật là API. ZITADEL cung cấp một bề mặt danh tính hoàn chỉnh qua gRPC và REST, và được xây dựng trên mô hình đa người thuê ngay từ đầu. Nếu bạn đang xây một sản phẩm SaaS và muốn lớp đăng nhập có thể lập trình, tự động hóa và đa người thuê theo mặc định, ZITADEL gần với thứ bạn cần hơn các lựa chọn khác.
Nó hỗ trợ OIDC, SAML, passkey, MFA, các nhà cung cấp danh tính LDAP và một giao diện SCIM v2 hiện được đánh dấu Preview. Mô hình tổ chức và quy trình ưu tiên API khiến nó phù hợp với các nhóm sản phẩm hơn là một homelab đơn giản.
Keycloak
Keycloak là một nền tảng quản lý danh tính và truy cập viết bằng Java, chạy trên Quarkus. Nó có bề mặt cấu hình lớn hơn các lựa chọn khác ở đây, nhất là khi Realms, Clients, Roles, liên kết người dùng và Authorization Services xuất hiện.
Tài liệu container chính thức của nó khuyến nghị giới hạn bộ nhớ 2 GB cho các triển khai nhỏ sẵn sàng cho production. Con số đó chỉ tính riêng container Keycloak; nếu PostgreSQL dùng chung VPS, hãy cho máy chủ thêm dư địa.
Lý do để chấp nhận độ phức tạp đó là cụ thể. Keycloak có thể liên kết các thư mục LDAP và Active Directory, ghi lại sự kiện của người dùng và quản trị viên, và thực thi ủy quyền chi tiết bằng RBAC, ABAC, chính sách theo người dùng, theo ngữ cảnh và các loại chính sách khác. Nếu bạn cần những kiểm soát đó, phần cấu hình thêm là có mục đích.
Authelia
Authelia là công cụ nhỏ nhất trong bốn: cấp phép Apache 2.0, một tệp nhị phân Go duy nhất, hiện ở phiên bản v4.39.x. Kiến trúc khác với ba công cụ còn lại: Authelia đứng trước một reverse proxy (nginx, Traefik, Caddy, HAProxy) và quyết định các yêu cầu có được phép tới backend hay không.
Authelia cũng bao gồm một nhà cung cấp OpenID Connect. Tài liệu của nó vẫn mô tả triển khai OIDC là bản beta mở, nhưng nhà cung cấp này đã được chứng nhận OpenID cho các hồ sơ Basic OP, Implicit OP, Hybrid OP, Form Post OP và Config OP. Bộ tính năng OIDC của nó hẹp hơn những gì Authentik hay Keycloak cung cấp cho quản lý danh tính, đó là lý do Authelia vẫn hợp lý nhất khi xác thực tại reverse proxy là công việc chính.
Chúng ta sẽ quay lại Authelia trong một phần riêng. Tóm tắt: trọng tâm của Authelia là kiểm soát truy cập tại reverse proxy, không phải quản lý danh tính đầy đủ.
So sánh tính năng
Bảng dưới đây giới hạn so sánh ở những khác biệt ảnh hưởng đến triển khai và quản trị hằng ngày.
| Tính năng | Authentik | ZITADEL | Keycloak | Authelia |
|---|---|---|---|---|
| Giao thức hỗ trợ | OAuth2/OIDC, SAML, LDAP, RADIUS, xác thực qua proxy | OAuth2/OIDC, SAML, nhà cung cấp danh tính LDAP, SCIM v2 Preview | OAuth2/OIDC, SAML, liên kết LDAP và Active Directory | Nhà cung cấp OIDC cộng xác thực tại reverse proxy |
| Quản lý người dùng và nhóm | Người dùng, nhóm, chính sách, luồng, ràng buộc ứng dụng | Người dùng, tổ chức, dự án, vai trò, cấp quyền | Người dùng, nhóm, realm, vai trò client, vai trò realm, liên kết | Quản lý người dùng gọn nhẹ, thường dựa trên tệp hoặc LDAP |
| Trải nghiệm dành cho nhà phát triển | Có API, nhưng thế mạnh chính là giao diện quản trị | Ưu tiên API, mô hình tổ chức và đa người thuê mạnh | REST API trưởng thành với một mô hình IAM lớn hơn cần học | Chủ yếu vận hành theo cấu hình |
| Tính năng doanh nghiệp | Chính sách, liên kết, outpost, kiểm soát truy cập ứng dụng | Tổ chức, dự án, passkey, liên kết, SCIM v2 Preview | Liên kết sâu, nhiều realm, sự kiện, Authorization Services | Quy tắc kiểm soát truy cập và tích hợp reverse proxy chặt chẽ |
| Độ dễ thiết lập | Điểm khởi đầu dễ hơn cho hầu hết các stack ứng dụng tự lưu trữ | Tốt nhất khi nhóm tư duy theo API và danh tính sản phẩm | Nhiều khái niệm và cấu hình hơn, nhưng kiểm soát sâu hơn | Đơn giản nhất khi công việc chủ yếu là xác thực tại reverse proxy |
| Hướng dẫn tài nguyên | Mức tối thiểu Compose chính thức: 2 nhân CPU và 2 GB RAM | Mức tối thiểu máy chủ Compose chính thức: 2 GB RAM | Bộ nhớ container khuyến nghị 2 GB cho các triển khai production nhỏ | Không có mức RAM tối thiểu chính thức có thể so sánh trực tiếp |
Công cụ nào hợp với stack nào?
Lựa chọn phù hợp nhất thay đổi tùy theo ai vận hành IdP và các ứng dụng tích hợp với nó ra sao.
Lựa chọn tốt nhất cho homelab
Authentik là lựa chọn mặc định cho một homelab nơi hầu hết ứng dụng đã hỗ trợ OIDC hoặc SAML. Nó cho bạn một nhà cung cấp danh tính đầy đủ mà không buộc bạn phải áp dụng mô hình IAM rộng hơn của Keycloak. Nếu phần lớn stack cần một màn hình đăng nhập tại reverse proxy thay vì SSO gốc, Authelia có thể là lựa chọn đơn giản hơn.
Lựa chọn tốt nhất cho stack doanh nghiệp nhỏ
Authentik phù hợp với hầu hết các stack ứng dụng nội bộ nhỏ, nhất là khi mục tiêu là một lớp danh tính duy nhất cho các công cụ như Grafana, Gitea, Nextcloud và Vaultwarden. Keycloak trở nên hấp dẫn hơn khi một thư mục sẵn có, nhiều realm hoặc chính sách ủy quyền sâu hơn là một phần của yêu cầu.
Lựa chọn tốt nhất cho lập trình viên và sản phẩm SaaS
ZITADEL phù hợp nhất khi xác thực là một phần của sản phẩm bạn đang xây dựng. Mô hình tổ chức, đa người thuê, API và bề mặt tự động hóa của nó hợp lý hơn khi người dùng và người thuê cần được tạo từ mã ứng dụng thay vì chủ yếu qua bảng quản trị.
Lựa chọn tốt nhất cho các nhóm doanh nghiệp hoặc nặng về tuân thủ
Keycloak hợp lý khi danh sách yêu cầu gồm liên kết thư mục phức tạp, nhiều realm, chính sách ủy quyền chi tiết và một nhóm có thể vận hành độ phức tạp IAM tăng thêm. Tự lưu trữ Keycloak không tự động khiến môi trường tuân thủ; sao lưu, tính sẵn sàng, ghi log, rà soát truy cập và kiểm soát thay đổi vẫn thuộc về nhóm của bạn.
Lựa chọn tốt nhất cho ứng dụng không có SSO gốc
Authelia là lựa chọn rõ ràng nhất khi xác thực cần diễn ra trước khi yêu cầu tới được ứng dụng. Nó đặc biệt hiệu quả với các reverse proxy bảo vệ công cụ nội bộ cũ, bảng điều khiển và dịch vụ vốn không tự hỗ trợ OIDC hay SAML.
Phần khó của việc tự lưu trữ SSO
Khi SSO là bắt buộc, một lỗi cấu hình hoặc một lần khôi phục thất bại có thể ảnh hưởng đến nhiều ứng dụng cùng lúc.
Cài đặt và cấu hình
Chạy được các container chỉ là bước đầu. DNS, TLS, URI chuyển hướng, claim của token, ánh xạ nhóm, gửi email và quyền truy cập khôi phục là những điểm khiến một triển khai SSO bắt đầu trở thành hạ tầng thay vì chỉ là thêm một ứng dụng Docker.
Tài nguyên máy chủ
IdP chỉ là một phần của ngân sách tài nguyên. PostgreSQL, reverse proxy, worker, băm mật khẩu, log và đồng bộ thư mục đều có thể tranh giành CPU và bộ nhớ khi dùng chung một VPS.
Quản lý cơ sở dữ liệu và sao lưu
Authentik, ZITADEL và các triển khai Keycloak production thông thường đều phụ thuộc vào một cơ sở dữ liệu. Hãy sao lưu cơ sở dữ liệu đó ra ngoài máy chủ, ghi lại cách khôi phục và kiểm thử việc khôi phục. Một tác vụ sao lưu thành công không đồng nghĩa với một quy trình khôi phục hoạt động.
Rủi ro bị khóa và khôi phục
Một URI chuyển hướng sai, một client secret hết hạn, một kết nối thư mục bị hỏng hoặc một chính sách quá chặt có thể khóa cả quản trị viên lẫn mọi người khác. Hãy giữ một đường khôi phục không phụ thuộc vào luồng xác thực mà bạn đang cố sửa.
Giữ cho IdP luôn khả dụng
Sự cố IdP không nhất thiết chấm dứt ngay mọi phiên ứng dụng hiện có. Các phiên hiện có có thể tiếp tục cho đến khi token hoặc cookie của chúng hết hạn, nhưng đăng nhập mới và làm mới token có thể thất bại. Hãy kiểm thử chế độ lỗi đó trước khi bắt buộc SSO trên toàn stack.
Khi nào bạn không nên tự lưu trữ SSO
Tự lưu trữ không còn là thỏa thuận tốt khi nhóm của bạn không thể khôi phục và vận hành lớp danh tính với độ tin cậy mà ứng dụng của bạn đòi hỏi.
Khi nào danh tính được quản lý an toàn hơn
Danh tính được quản lý đáng để trả tiền khi chi phí vận hành IdP cao hơn quyền kiểm soát bạn có được khi tự lưu trữ. Các dịch vụ như Auth0, Clerk, WorkOS và Microsoft Entra ID chuyển phần lớn tính sẵn sàng của nền tảng, việc vá lỗi và bảo trì hạ tầng sang nhà cung cấp.
Bạn vẫn sở hữu cấu hình ứng dụng, quyền hạn và kế hoạch khôi phục, nhưng không còn chịu trách nhiệm giữ cho chính nền tảng danh tính luôn trực tuyến.
Khi nhóm của bạn không thể chịu được thời gian ngừng hoạt động
Nếu không ai trong nhóm có thể khôi phục IdP, sửa PostgreSQL, thay một secret hết hạn hoặc chẩn đoán một kết nối liên kết bị lỗi trong lúc sự cố, tự lưu trữ danh tính có thể là đánh đổi vận hành sai lầm.
Sự cố rộng hơn một ứng dụng không khả dụng. Đăng nhập mới và làm mới token trên nhiều ứng dụng có thể thất bại cùng lúc.
Khi yêu cầu tuân thủ quá cao
Danh tính tự lưu trữ có thể dùng trong các môi trường chịu quản lý, nhưng tự chạy phần mềm không tự động tạo ra các kiểm soát hay bằng chứng mà kiểm toán viên mong đợi. Nhóm của bạn vẫn chịu trách nhiệm về ghi log, rà soát truy cập, sao lưu, quản lý thay đổi, tính sẵn sàng, ứng phó sự cố và mọi tài liệu mà khung áp dụng yêu cầu.
SSO tự lưu trữ không phải biểu tượng địa vị. Nếu nhóm của bạn không thể vận hành lớp danh tính một cách an toàn, trả tiền cho danh tính được quản lý có thể là quyết định kỹ thuật tốt hơn.
Cloudzy giúp được gì
Cloudzy thay đổi tầng triển khai; nó không loại bỏ công việc cấu hình danh tính và vận hành đã mô tả ở trên.
Vấn đề của việc triển khai SSO thủ công
Triển khai SSO thủ công nghĩa là chuẩn bị máy chủ, cài ứng dụng và cơ sở dữ liệu, cấu hình reverse proxy, thiết lập DNS và TLS, rồi mới bắt đầu cấu hình danh tính. Không bước nào trong đó thay thế được công việc OIDC, SAML, thư mục hay chính sách theo sau.
Triển khai SSO một cú nhấp trên Cloudzy
Cloudzy có triển khai một cú nhấp cho Authentik và Keycloak. Ứng dụng Authentik một cú nhấp có trong marketplace của Cloudzy. Ứng dụng Keycloak một cú nhấp cũng có trong marketplace của Cloudzy. ZITADEL hiện chưa có trong marketplace, nên hãy triển khai nó bằng cấu hình Docker Compose của nó trên một VPS tiêu chuẩn. Cài đặt một cú nhấp giúp ứng dụng cơ sở chạy được, còn cấu hình danh tính, DNS, sao lưu, nâng cấp, chính sách và kiểm thử khôi phục vẫn nằm trong tay bạn.
Xây dựng trên VPS Linux với quyền root, NVMe và sức mạnh AMD EPYC.
Xem các gói LinuxKhi nào nên dùng một VPS riêng cho IdP
Đặt IdP chung với các ứng dụng là hợp lý cho một homelab chấp nhận được thời gian ngừng hoạt động. Với một stack quan trọng cho kinh doanh, tách riêng nhà cung cấp danh tính loại bỏ một miền lỗi chung rõ ràng: khởi động lại, làm cạn tài nguyên hoặc xâm phạm máy chủ ứng dụng không còn kéo theo lớp danh tính sập cùng.
Một VPS riêng không đồng nghĩa với tính sẵn sàng cao, nhưng nó cho IdP ngân sách tài nguyên, lịch bảo trì và ranh giới khôi phục của riêng nó.
Khuyến nghị kích thước VPS
Hãy tính kích thước cho toàn bộ stack, không chỉ tiến trình IdP, nhất là khi PostgreSQL và một reverse proxy dùng chung VPS.
Yêu cầu VPS cho Authentik
Tài liệu Docker Compose chính thức của Authentik yêu cầu một máy chủ có ít nhất 2 nhân CPU và 2 GB RAM. Đó là điểm khởi đầu đúng cho một triển khai nhỏ. Hãy cho máy chủ thêm dư địa khi PostgreSQL, các outpost bổ sung, đồng bộ thư mục hoặc lưu lượng đăng nhập lớn hơn dùng chung máy.
Yêu cầu VPS cho ZITADEL
Triển khai Docker Compose chính thức của ZITADEL yêu cầu ít nhất 2 GB RAM cho máy chủ. Hãy tính kích thước một VPS tất cả trong một cho ZITADEL, giao diện đăng nhập của nó, PostgreSQL và reverse proxy cùng nhau thay vì chỉ xét riêng dịch vụ Go.
Yêu cầu VPS cho Keycloak
Tài liệu container của Keycloak khuyến nghị giới hạn bộ nhớ 2 GB cho các triển khai Keycloak nhỏ sẵn sàng cho production. Con số đó áp dụng cho riêng container Keycloak, không phải cho cả VPS cũng chạy PostgreSQL.
Nếu Keycloak và PostgreSQL dùng chung một VPS, 4 GB RAM hệ thống là điểm khởi đầu hợp lý. Hãy xem đó là hướng dẫn thực tế cho máy chủ chứ không phải mức tối thiểu chính thức của Keycloak.
Yêu cầu VPS cho Authelia
Authelia không công bố mức tối thiểu máy chủ 1 GB hay 2 GB có thể so sánh trực tiếp. Hãy tính kích thước máy chủ cho Authelia cùng với reverse proxy, backend lưu trữ, thư mục người dùng và mọi dịch vụ khác dùng chung máy.
Authelia thường có dấu chân triển khai nhỏ hơn việc chạy một IdP đầy đủ cùng PostgreSQL, nhưng yêu cầu VPS thực tế phụ thuộc vào phần còn lại của stack.
Ví dụ thiết lập: Authentik với Vaultwarden
Vaultwarden đã thêm hỗ trợ SSO OpenID Connect gốc trong phiên bản 1.35.0 vào tháng 12 năm 2025. Authentik là một ví dụ hữu ích vì phần tích hợp bộc lộ các thành phần OIDC mà bạn cũng sẽ gặp với các ứng dụng khác: URI chuyển hướng, thông tin xác thực client, scope, URL issuer và quyền truy cập khôi phục.
Thiết lập Authentik cơ bản
Trong Authentik:
- Tạo một ánh xạ scope email tùy chỉnh cho Vaultwarden. Vaultwarden yêu cầu scope email phải trả về email_verified: true hoặc hoàn toàn không có giá trị email_verified, trong khi scope email mặc định của Authentik hiện trả về false.
- Tạo một cặp ứng dụng và nhà cung cấp OAuth2/OpenID Connect.
- Thêm https://vault.example.com/identity/connect/oidc-signin làm URI chuyển hướng nghiêm ngặt kiểu Authorization.
- Chọn bất kỳ khóa ký nào đang có.
- Ghi lại Client ID, Client Secret và slug của ứng dụng.
- Đặt thời hạn hiệu lực của token truy cập lớn hơn năm phút.
- Thêm ánh xạ offline_access của Authentik vào các scope đã chọn.
- Thay ánh xạ email mặc định bằng ánh xạ email đã xác minh tùy chỉnh từ bước 1.
Thiết lập OIDC cơ bản cho Vaultwarden
Dùng:
DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://idp.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=vaultwarden
SSO_CLIENT_SECRET=<paste-secret-from-authentik>
SSO_SCOPES=email profile offline_access
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false
SSO_SIGNUPS_MATCH_EMAIL=trueThay các tên miền ví dụ, slug ứng dụng, client ID và client secret bằng giá trị từ triển khai của bạn, rồi khởi động lại Vaultwarden.
Cần kiểm thử gì trước khi bắt buộc SSO
Giữ SSO_ONLY ở giá trị false trong khi bạn kiểm thử đăng nhập, đăng xuất, làm mới token, khớp tài khoản và khôi phục. Cũng hãy kiểm thử điều gì xảy ra khi Authentik tạm thời không khả dụng.
Khi cả SSO và khôi phục đều hoạt động như mong đợi, bạn có thể quyết định liệu việc bắt buộc SSO cho mọi lần đăng nhập có hợp lý với triển khai của mình hay không.
Các khái niệm OIDC tương tự áp dụng cho các ứng dụng tự lưu trữ khác, nhưng URI chuyển hướng, scope, claim và giấy phép khác nhau. Hãy xem tài liệu SSO của từng ứng dụng thay vì sao chép nguyên cấu hình Vaultwarden.
Khi nào Authelia tốt hơn một IdP đầy đủ
Authelia trở nên hấp dẫn hơn khi ứng dụng hoàn toàn không cần hiểu về nhà cung cấp danh tính.
Xác thực tại reverse proxy
Authelia được thiết kế chủ yếu để bảo vệ ứng dụng ở tầng reverse proxy. Bạn định nghĩa các quy tắc kiểm soát truy cập, và Authelia quyết định một yêu cầu có nên tới backend hay không trước khi chính ứng dụng xử lý xác thực.
Bảo vệ ứng dụng không có OIDC
Điều này hữu ích cho các công cụ nội bộ cũ, bảng điều khiển và dịch vụ không hỗ trợ OIDC hay SAML. Thay vì sửa từng ứng dụng, bạn có thể đặt xác thực phía trước chúng tại reverse proxy.
Authelia cũng có thể đóng vai trò nhà cung cấp OIDC, nhưng xác thực tại reverse proxy vẫn là thế mạnh chính của nó.
Dùng Authelia cùng với Authentik
Bạn có thể dùng Authentik cho các ứng dụng hỗ trợ OIDC hoặc SAML và Authelia cho các ứng dụng cần xác thực tại reverse proxy.
Bạn không nhất thiết cần cả hai. Authentik cũng hỗ trợ bảo vệ ứng dụng qua proxy, nên dùng thêm Authelia chỉ hợp lý khi quy trình reverse proxy của Authelia giải quyết một phần cụ thể trong stack của bạn gọn gàng hơn.
Câu hỏi thường gặp
Authentik có tốt hơn Keycloak không?
Với hầu hết homelab và các stack ứng dụng tự lưu trữ nhỏ, Authentik dễ tiếp cận hơn. Quy trình quản trị của nó tập trung vào ứng dụng, nhà cung cấp, nhóm và chính sách mà không phơi bày quá nhiều độ phức tạp IAM cùng lúc.
Keycloak hợp lý hơn khi bạn cần cụ thể đến liên kết sâu hơn, mô hình realm hoặc Authorization Services của nó. Authentik là lựa chọn mặc định vững hơn cho SSO tự lưu trữ đơn giản; Keycloak phù hợp với các môi trường cần những kiểm soát bổ sung đó.
ZITADEL có tốt hơn Keycloak không?
ZITADEL phù hợp hơn khi bạn đang xây một sản phẩm và muốn danh tính điều khiển bằng API, tổ chức và đa người thuê. Keycloak phù hợp hơn khi bạn cần mô hình ủy quyền sâu hơn, các kiểm soát liên kết rộng hoặc một môi trường vốn đã xây quanh Keycloak.
Authentik và Authelia khác nhau thế nào?
Authentik là một nhà cung cấp danh tính đầy đủ xây dựng quanh người dùng, nhóm, ứng dụng, nhà cung cấp, luồng và chính sách. Các ứng dụng có thể tích hợp trực tiếp với nó qua các giao thức như OIDC và SAML.
Authelia tập trung vào xác thực và kiểm soát truy cập tại reverse proxy. Nó cũng có một nhà cung cấp OIDC, nhưng bảo vệ tại reverse proxy vẫn là trường hợp sử dụng chính.
Chọn Authentik khi các ứng dụng tích hợp trực tiếp với một IdP. Chọn Authelia khi xác thực chủ yếu cần diễn ra trước khi lưu lượng tới được ứng dụng.
Tôi có thể chạy Authentik trên VPS 1 GB không?
Không, nếu xét như một điểm khởi đầu được hỗ trợ. Tài liệu Docker Compose hiện tại của Authentik yêu cầu ít nhất 2 nhân CPU và 2 GB RAM. Triển khai lõi hiện tại dùng máy chủ Authentik, worker và PostgreSQL; Redis đã bị loại bỏ hoàn toàn trong Authentik 2025.10.
Hãy lấy 2 GB làm điểm khởi đầu tối thiểu cho một bản cài nhỏ và thêm dư địa khi các dịch vụ khác dùng chung máy.
Vaultwarden có hỗ trợ SSO OIDC không?
Có. Vaultwarden đã thêm hỗ trợ SSO OpenID Connect trong phiên bản 1.35.0 vào tháng 12 năm 2025. Nó cần một nhà cung cấp OIDC bên ngoài như Authentik, Keycloak hoặc ZITADEL.
Cấu hình chính xác tùy thuộc vào nhà cung cấp. Với các bản phát hành Authentik hiện tại, tích hợp được ghi trong tài liệu gồm một ánh xạ scope email đã xác minh tùy chỉnh, offline_access, thông tin xác thực client và URL issuer của ứng dụng Authentik.
Tôi có nên chạy IdP trên cùng VPS với các ứng dụng không?
Với một homelab chấp nhận được thời gian ngừng hoạt động, đặt chung có thể hợp lý. Với các ứng dụng quan trọng cho kinh doanh, một VPS riêng cho nhà cung cấp danh tính ngân sách tài nguyên riêng và đưa máy chủ ứng dụng ra khỏi miền lỗi chung.
Điều đó tự nó không tạo ra tính sẵn sàng cao, nhưng việc khởi động lại máy chủ ứng dụng, sự cố tài nguyên hay bị xâm phạm không còn tự động kéo IdP sập theo.
SSO tự lưu trữ nào dễ dùng nhất?
Authentik là điểm khởi đầu dễ nhất cho hầu hết những ai kết nối các ứng dụng tự lưu trữ sẵn có. Giao diện quản trị của nó khiến ứng dụng, nhà cung cấp, nhóm và chính sách dễ tiếp cận hơn mô hình realm và ủy quyền rộng hơn của Keycloak.
Authelia có thể đơn giản hơn khi bạn chỉ cần xác thực tại reverse proxy. ZITADEL hợp lý hơn khi người cấu hình danh tính là một lập trình viên làm việc chủ yếu qua API.
Thảo luận
Bình luận
Đăng nhập để tham gia thảo luận.