Nếu bạn từng xem bảng giá của một số nền tảng CIAM dạng SaaS, hẳn bạn đã nhận ra chúng đắt đến mức nào và nhiều khả năng đã cân nhắc một giải pháp tự lưu trữ.
Bài viết này nói về bốn nền tảng CIAM tự lưu trữ mà một nhóm SaaS B2B nhỏ thực sự có thể vận hành mà không biến nó thành công việc toàn thời gian thứ hai: ZITADEL, FusionAuth, Logto và Ory Hydra. Chúng không cùng một hình dạng, và cái phù hợp với bạn phụ thuộc vào loại sản phẩm B2B bạn đang xây dựng nhiều hơn là vào một danh sách tính năng. Tôi đã chạy chúng song song trên cùng một VPS trong một tuần để dựng nên bài so sánh này, và những gì tiếp theo là phiên bản tôi sẽ gửi cho một nhà sáng lập nhắn tin riêng hỏi tôi về CIAM.
Một điều nói trước: bài này bàn về CIAM như một tính năng sản phẩm, không phải SSO nội bộ cho chính đội ngũ của bạn.
Phiên bản ngắn gọn
Bốn nền tảng CIAM tự lưu trữ, mỗi cái một dòng:
- ZITADEL nếu bạn muốn đa thuê bao và tổ chức B2B có sẵn ngay từ đầu.
- FusionAuth nếu bạn muốn một giao diện quản trị chỉn chu và lịch sử phát hành dài, ổn định.
- Logto nếu bạn muốn trải nghiệm lập trình viên gọn gàng nhất ngay ngày đầu tiên.
- Ory Hydra nếu bạn làm việc ở tầng giao thức và muốn có cỗ máy OAuth 2.0, chứ không phải một ứng dụng đăng nhập dựng sẵn.
Tóm lại: ZITADEL là lựa chọn đầu tiên an toàn nhất cho một SaaS B2B điển hình, và phần còn lại của bài viết sẽ mổ xẻ lập luận đó.
Vì sao CIAM là một quyết định khác với SSO nội bộ
Nếu SSO cho đội ngũ nội bộ sập, thiệt hại thường nằm trong tầm kiểm soát. Các kỹ sư của bạn có thể mất quyền truy cập Grafana hoặc một công cụ nội bộ khác trong một giờ. Nếu CIAM sập, khách hàng trả tiền của bạn hoàn toàn không đăng nhập được vào sản phẩm. Điều đó biến câu hỏi từ "công cụ xác thực nào tiện cho đội của chúng ta?" thành "hệ thống xác thực nào chúng ta có thể tin tưởng như một phần của chính sản phẩm?"
CIAM, loại hạ tầng danh tính mà một SaaS B2B cần, cũng đòi hỏi những nguyên hàm mà nhiều công cụ SSO nội bộ không chú trọng. Khách hàng của bạn không phải một người dùng đơn lẻ; đó là một tổ chức (một tenant) với người dùng, vai trò, thương hiệu riêng và có thể cả kết nối SAML riêng tới một IdP doanh nghiệp. Bạn không chỉ xác thực con người; bạn đang cô lập người dùng của công ty này khỏi người dùng của công ty khác bên trong cùng một sản phẩm. Đó chính là hình dạng B2B mà bốn công cụ dưới đây nhắm tới, mỗi cái một kiểu. Keycloak giờ đã có Organizations như một khái niệm hạng nhất, nên gạt nó sang một bên như thứ chỉ dành cho nhân viên nội bộ là đã lỗi thời; tôi giải thích lý do nó vắng mặt trong phần Câu hỏi thường gặp.
Tam giác tự xây, đi mua hay tự lưu trữ ở đây cũng khác. Viết OAuth từ đầu là một sai lầm không đáng có. Bạn đang ra mắt một sản phẩm SaaS, không phải một nhà cung cấp danh tính. Mua dịch vụ được quản lý (Auth0, Clerk, WorkOS) là lựa chọn đúng khi đội của bạn không có chút năng lực vận hành nào và có ngân sách hợp lý. Tôi sẽ không bao giờ bảo một startup hai người tự lưu trữ phần xác thực ngay ngày đầu. Tự lưu trữ trở nên hợp lý khi giá theo MAU của CIAM được quản lý vượt qua chi phí hạ tầng cộng với thời gian kỹ thuật thường xuyên, hoặc khi bạn cần kiểm soát trực tiếp phần triển khai và tầng dữ liệu. Ở những đội tôi từng làm việc cùng, thời điểm đó thường rơi vào khoảng giữa "chúng ta đã có sản phẩm thật" và "chúng ta đã có bộ phận customer success thật".
Nếu bạn đang tìm SSO cho ứng dụng của chính mình chứ không phải của khách hàng, thì đó là một bài so sánh khác. Giờ đến các lựa chọn hàng đầu của chúng tôi.
Bốn công cụ, lần lượt từng cái
Tôi chọn bốn cái này vì chúng đủ mang hình dạng CIAM để đánh giá như hạ tầng sản phẩm, chứ không chỉ là SSO nội bộ. ZITADEL, FusionAuth, Logto và Ory đều cho bạn một con đường tự lưu trữ thực sự và đủ độ phổ biến để cân nhắc nghiêm túc. Những lựa chọn chỉ là thư viện, những giải pháp thiên về SSO nội bộ và những cái chưa đủ chín được xử lý tốt hơn ở phần Câu hỏi thường gặp.
ZITADEL
ZITADEL là nền tảng danh tính do Thụy Sĩ phát triển, viết bằng Go, với kiến trúc event-sourced và backend PostgreSQL. Tính đến ngày 27 tháng 7 năm 2026, bản phát hành GitHub mới nhất là the 4.16 series, current as of July 2026. ZITADEL chuyển từ Apache 2.0 sang AGPL-3.0 kể từ v3; với cách dùng SaaS thông thường, tác động thực tế thường không đáng sợ như nghe qua, và tôi nói kỹ hơn ở phần Câu hỏi thường gặp.
Điều làm ZITADEL nổi bật với SaaS B2B: tổ chức và đa thuê bao là những nguyên hàm hạng nhất, chứ không phải các tính năng bạn ghép lại từ những đối tượng chung chung. Bạn tạo một Organization, nó có người dùng, chính sách, thương hiệu và thiết lập truy cập riêng, và bạn có thể cấp dự án cho tổ chức đó để quản trị viên của họ tự quản lý việc gán vai trò cho người dùng của mình. Bạn không phải tự nghĩ ra khái niệm "tenant" chồng lên những người dùng chung chung. Bạn bắt đầu đã có sẵn nó.
Trải nghiệm lập trình viên theo hướng API-first, với các API tài nguyên REST v2 hiện tại cộng thêm truy cập gRPC và REST tới các dịch vụ v1 cũ. SDK chính thức và của cộng đồng bao phủ những stack máy chủ phổ biến. Bảng điều khiển quản trị đủ dùng nhưng thô hơn của FusionAuth.
Nhận định của tôi: Nếu bạn đang xây một SaaS B2B và biết chắc sẽ có tenant, tôi sẽ bắt đầu từ ZITADEL. Trong các lựa chọn tự lưu trữ, đây là cái được định hình rõ ràng nhất quanh bài toán đăng nhập B2B.
FusionAuth
FusionAuth là nền tảng có trụ sở tại Mỹ của Inversoft, LLC (một LLC ở Delaware, hoạt động dưới tên FusionAuth), tồn tại lâu hơn ba cái còn lại và điều đó thể hiện rõ, theo nghĩa tốt. Giao diện quản trị cho cảm giác được thiết kế kỹ hơn hẳn, tài liệu đã chín, và nhịp phát hành đều đặn chứ không dồn dập. Nếu bạn từng kế thừa một tích hợp xác thực bốn năm tuổi và thầm cảm ơn kỹ sư trước đó vì đã chọn phương án nhàm chán, thì FusionAuth chính là phiên bản CIAM xứng đáng với lời cảm ơn ấy.
Thứ khiến người ta vấp là giấy phép: FusionAuth Community miễn phí để tự lưu trữ, nhưng phần lõi của sản phẩm không phải mã nguồn mở. Sản phẩm được điều chỉnh bởi giấy phép riêng của FusionAuth, và các giới hạn ấy quan trọng nếu bạn định phân phối lại, nhúng, đổi thương hiệu, bán lại hay lưu trữ FusionAuth cho khách hàng của chính bạn. Bản Community tự lưu trữ bao phủ trường hợp cốt lõi của SaaS B2B; các gói trả phí bổ sung tính năng chẳng hạn SAML do IdP khởi tạo, MFA nâng cao và giao diện riêng theo ứng dụng, trong khi SCIM, Tenant Manager và chính sách MFA ở cấp ứng dụng nằm ở gói Enterprise.
Về hình dạng B2B: FusionAuth mô hình hóa tenant và ứng dụng, nhưng lớp trừu tượng là "xác thực đóng gói theo từng tenant" chứ không phải "tổ chức B2B như một đối tượng miền". Nó chạy được (tôi đã ra sản phẩm trên đó), nhưng đa thuê bao cho cảm giác giống một nguyên hàm cô lập hơn là một mô hình B2B hạng nhất. Bộ SDK chính thức và thư viện client khá rộng:
- Angular
- React
- Vue
- iOS
- Android
- Go
- Java
- .NET
- PHP
- Python
- Ruby
- TypeScript
Các thư viện phía máy chủ là client API mỏng. So với những cái còn lại, bảng điều khiển quản trị dễ giao cho một người vận hành không phải kỹ sư hơn.
Nhận định của tôi: Nếu đội của bạn coi trọng độ chỉn chu của giao diện và một lịch sử dài, ổn định hơn là các nguyên hàm B2B thuần chất, hãy chọn FusionAuth. Đây là lựa chọn "nhàm chán" nhất trong danh sách, và đó là một lời khen.
Logto
Logto là cái mới nhất trong bốn, do Silverhand Inc. phát triển và được cấp phép theo MPL-2.0, và là cái quan tâm đến bảng điều khiển của mình một cách rõ ràng nhất. Việc cài đặt ngày đầu tương đối nhanh. Bạn cấp phát, bấm qua trình hướng dẫn, và trong khoảng mười lăm phút đã có một nhà cung cấp OIDC hoạt động với giao diện đăng nhập mặc định tử tế (tôi đã bấm giờ trong tuần chạy song song cả bốn). Các hướng dẫn khởi động nhanh chính thức bao phủ những framework và stack máy chủ hiện đại, nên nếu stack của bạn là "Next.js + Postgres + gì đó", bạn sẽ thấy quen thuộc ngay.
Câu trả lời cho B2B của nó có tên là Logto Organizations. Nó bao phủ các nguyên hàm B2B cốt lõi: tư cách thành viên tổ chức, vai trò trong phạm vi tổ chức, lời mời thành viên, cấp phát just-in-time và tích hợp SSO doanh nghiệp. Mô hình tổ chức mới hơn của ZITADEL, nên tôi sẽ thử mọi luồng SAML, SCIM hay liên kết danh tính bất thường với khách hàng mục tiêu của bạn trước khi cam kết.
Cái giá phải trả là độ chín: Logto là lựa chọn mới nhất ở đây. Lộ trình chạy nhanh, điều đó tuyệt khi tính năng bạn cần xuất hiện, và khó chịu khi một thay đổi phá vỡ tương thích xuất hiện. Nếu SaaS B2B của bạn nằm ở phía đơn giản của phổ đa thuê bao (một nhóm nhỏ tổ chức và không có yêu cầu liên kết danh tính kỳ lạ), trải nghiệm lập trình viên của Logto khiến phần còn lại của quyết định dễ hơn nhiều.
Nhận định của tôi: Nếu bạn muốn ngày đầu nhanh nhất và nhu cầu B2B vẫn còn tương đối đơn giản, hãy chọn Logto.
Ory Hydra (và bộ Ory)
Ory Hydra là máy chủ OAuth 2.0 / OpenID Connect thuộc hệ sinh thái Ory, được cấp phép theo Apache-2.0. Bộ Ory đầy đủ ghép Hydra với Ory Kratos (danh tính và quản lý người dùng, đăng nhập tự phục vụ, đăng ký, MFA và khôi phục tài khoản), Ory Keto (máy chủ ủy quyền kiểu Zanzibar đóng vai trò điểm ra quyết định chính sách) và Ory Oathkeeper (proxy danh tính và truy cập, thực hiện xác thực, ủy quyền và biến đổi các yêu cầu HTTP đến). Bạn tự lắp ghép thứ mình cần. Tất cả đều viết bằng Go và các API rất gọn gàng.
Điểm mấu chốt (và đây không phải khiếm khuyết; với đúng đội ngũ thì đó là ưu điểm) là Hydra là cỗ máy, không phải ứng dụng. Theo thiết kế, Hydra kết nối tới một ứng dụng đăng nhập và chấp thuận riêng biệt do bạn cung cấp. Nếu bạn muốn có sẵn màn hình đăng nhập, đây không phải công cụ dành cho bạn. Nếu bạn đang xây thứ mà luồng xác thực là một phần của sản phẩm (nền tảng cho lập trình viên, cổng B2B riêng, hay sản phẩm API-first với quy trình onboarding tùy biến), thì việc không bị áp đặt giao diện chính là điều bạn cần.
Câu chuyện B2B ở đây mang tính lắp ghép chứ không phải trọn gói. Bạn có thể mô hình hóa đa thuê bao bằng cách nối các schema của Kratos và quan hệ của Keto vào tầng tổ chức của riêng mình, và nó chạy được, nhưng phần đấu nối là bạn làm. Cái giá là nhiều việc lắp ống hơn; cái lợi là quyền kiểm soát trải nghiệm. Tài liệu của Ory bao phủ bề mặt giao thức rất sâu, nhưng mô hình lắp ghép mặc định rằng bạn thoải mái khi tự ra quyết định ở tầng giao thức. Nếu "audience claim" hay "PKCE" chẳng gợi lên gì với bạn, hãy bắt đầu từ một trong ba cái còn lại.
Nhận định của tôi: Nếu bạn đang xây thứ gì đó ở tầng giao thức (cổng xác thực, luồng tùy biến, nền tảng cho lập trình viên) và các ứng dụng tiêu chuẩn cảm thấy gò bó, Ory là câu trả lời đúng. Với một SaaS B2B điển hình muốn đăng nhập chạy được ngay hôm nay thì không.
So sánh nhanh trong một cái nhìn
Đây là bản tóm tắt bốn công cụ trong một bảng, hữu ích cho lượt đọc thứ hai, không thay thế cho các phần mô tả ở trên.
| Công cụ | Giấy phép | Mô hình tenancy | Nguyên hàm B2B | SDK | Bản được quản lý |
|---|---|---|---|---|---|
| ZITADEL | AGPL-3.0 | Organizations hạng nhất | Mạnh: tổ chức, vai trò có phạm vi và thiết lập ở cấp tổ chức | REST v2; gRPC/REST v1 cũ; SDK chính thức và của cộng đồng | Có (ZITADEL Cloud) |
| FusionAuth | Giấy phép FusionAuth; gói Community miễn phí khi tự lưu trữ | Tenant + ứng dụng | Cô lập mạnh; ít mang hình dạng B2B | SDK web, di động và máy chủ đa dạng | Có (FusionAuth Cloud) |
| Logto | MPL-2.0 | Organizations | Vai trò tổ chức, lời mời, cấp phát JIT, SSO doanh nghiệp | SDK web, di động và máy chủ hiện đại | Có (Logto Cloud) |
| Ory Hydra | Apache 2.0 | Ghép Hydra + Kratos + Keto | Tự dựng từ các nguyên hàm | Client sinh tự động; ở mức thấp hơn | Có (Ory Network) |
Nên bắt đầu với cái nào?
Bốn kịch bản ngắn bao phủ phần lớn các đội mà tôi thường trao đổi về chuyện này.
Bạn đang xây một SaaS B2B và biết chắc sẽ có tenant. Bắt đầu với ZITADEL. Các nguyên hàm đa thuê bao và tổ chức được thiết kế đúng cho việc này, bề mặt API đầy đủ, và bạn sẽ mất ít thời gian nghĩ ra mô hình tenant hơn so với ba cái còn lại. Việc chuyển sang AGPL đáng được rà soát pháp lý, nhưng một bản triển khai không sửa đổi và tích hợp riêng biệt thường là một tình huống SaaS đơn giản.
Bạn muốn giao diện quản trị chỉn chu và một nền tảng ổn định, dễ đoán. FusionAuth. Gói Community đáp ứng nhu cầu cốt lõi của nhiều đội; hãy dành thời gian đọc kỹ giấy phép và bảng tính năng. Những tính năng như SAML do IdP khởi tạo, MFA nâng cao và giao diện riêng theo ứng dụng đòi hỏi gói trả phí, trong khi SCIM, Tenant Manager và chính sách MFA ở cấp ứng dụng nằm ở Enterprise.
Nhu cầu B2B của bạn hiện tại đơn giản và bạn muốn ngày đầu nhanh nhất. Logto. Trải nghiệm lập trình viên ngày đầu của nó nhanh nhất trong bài kiểm tra song song của tôi. Hãy chấp nhận rằng bạn đang đặt cược vào một hệ sinh thái non hơn, và xem lại lựa chọn nếu yêu cầu của bạn lớn dần tới những trường hợp biên về liên kết danh tính mà bạn chưa thử.
Bạn đang xây thứ mà luồng xác thực là một phần của trải nghiệm sản phẩm. Ory Hydra (thêm Kratos, thêm Keto nếu bạn cần phân quyền). Bạn sẽ viết nhiều mã hơn. Bạn sẽ có nhiều quyền kiểm soát hơn. Nếu sự đánh đổi đó chưa hiển nhiên với bạn, thì bạn không phải đối tượng của Ory. Hãy chọn một trong ba cái còn lại.
Nếu có hai mô tả trong số này giống bạn, hãy mặc định chọn ZITADEL. Nó phù hợp rộng nhất và là cái tôi sẽ giao cho một nhóm sáng lập nhỏ mà không cần hỏi thêm nhiều.
Tự lưu trữ khiến bạn trả giá gì (về mặt vận hành)
Đây là phần kém lãng mạn của bài viết.
Kỷ luật sao lưu PostgreSQL của bạn giờ là thứ mà công việc kinh doanh phụ thuộc vào. Trong những triển khai này, trạng thái danh tính bạn phải bảo vệ có thể gồm bản ghi người dùng, thông tin đăng nhập đã băm, bí mật MFA, thông tin xác thực client OAuth và dữ liệu phiên. Mất trạng thái đó, khách hàng của bạn có thể mất luôn khả năng đăng nhập. Hãy thiết lập sao lưu tự động trước khi người dùng thật đầu tiên đăng ký, thử khôi phục, và đưa tình trạng sao lưu vào cùng kênh cảnh báo với thời gian hoạt động của ứng dụng.
Nhịp phát hành thay đổi theo thời gian. ZITADEL v4.16.1 ra ngày 17 tháng 7 năm 2026 sau vài bản phát hành trong tháng 6, trong khi mỗi dự án ở đây giữ nhịp và chính sách tương thích riêng. Hãy xem nhịp đó là chuyện bảo trì, không phải lối tắt để đánh giá chất lượng. Đọc ghi chú phát hành trước khi chạy docker compose pull, và lên lịch một cửa sổ vá lỗi định kỳ. Bỏ qua các bản cập nhật của nhà cung cấp danh tính hàng tháng trời có thể khiến bạn tụt lại phía sau các bản vá bảo mật và tương thích ngay trong lần rà soát nghiêm túc đầu tiên.
Những thứ tầm thường luôn âm thầm ập tới: gia hạn chứng chỉ TLS (dùng reverse proxy với Let's Encrypt, tự động hóa việc gia hạn và cảnh báo khi thất bại), cấu hình máy gửi thư cho email xác minh và đặt lại mật khẩu (SES, SendGrid, Postmark: chọn một cái và cấu hình SPF/DKIM/DMARC cho đúng, nếu không email đặt lại mật khẩu sẽ rơi vào thư rác), xoay vòng thông tin xác thực client OAuth khi một kỹ sư nghỉ việc, và giới hạn tốc độ trên các endpoint đăng nhập để một đợt tấn công credential stuffing không ghim chặt CPU của bạn.
Mẹo: nếu bạn dùng Postgres được quản lý, đừng mặc định rằng tài khoản cơ sở dữ liệu lúc chạy cũng tạo được schema. Hãy tạo sẵn cơ sở dữ liệu và người dùng, cấp quyền sở hữu hoặc quyền cài đặt cần thiết, rồi chạy lần thiết lập đầu tiên bằng đúng thông tin đăng nhập mà mỗi công cụ mong đợi. Nếu không, lần chạy đầu có thể gãy với một lỗi phân quyền cơ sở dữ liệu mơ hồ và bạn sẽ đốt cả tiếng đồng hồ đuổi theo hướng sai.
Thứ mà con đường tự lưu trữ tiết kiệm cho bạn bằng tiền, nó lấy lại bằng trách nhiệm sở hữu. Sau khi cài đặt, hãy dự trù vài giờ kỹ thuật mỗi tháng để giữ tầng danh tính khỏe mạnh. Những đội phân bổ con số không thường phát hiện ra cái giá đó muộn hơn: giữa một sự cố, ở một trường hợp biên SAML kỳ quặc, hoặc trong đợt rà soát bảo mật đầu tiên.
Nên triển khai ở đâu
Một VPS Linux chạy Docker Compose có thể là điểm khởi đầu hợp lý để đánh giá và cho những tải công việc vừa phải, nhưng việc định cỡ cho môi trường thật và tính sẵn sàng cao phụ thuộc vào lưu lượng, yêu cầu bảo mật và mức chấp nhận thời gian chết của bạn. Các lựa chọn triển khai phổ biến xếp như sau:
- Hosting chia sẻ không chạy được cái nào trong số đó. Chúng cần lưu trữ bền vững, cổng tùy chỉnh, quyền root cho runtime container và một backend cơ sở dữ liệu thực thụ. PostgreSQL là con đường mặc định cho phần lớn danh sách này, nhưng theo đúng nghĩa đen thì nó không phải cơ sở dữ liệu duy nhất được mọi công cụ hỗ trợ.
- Kubernetes chạy được cả bốn, nhưng con đường chính chủ thì không đồng đều. ZITADEL, FusionAuth, và Ory phát hành Helm chart chính chủ, trong khi tài liệu tự lưu trữ của Logto tập trung vào triển khai bằng Docker và máy ảo. Với một SaaS B2B nhỏ chưa tới ngưỡng mà Kubernetes tự sinh lời ở những chỗ khác, đây thường là kỹ thuật quá đà. Hãy dùng nó khi phần còn lại của hạ tầng đã nằm sẵn ở đó.
- Bare metal thì ổn nếu bạn vốn đã ở trên đó. Phần lớn các đội SaaS B2B thì không.
Với một bản thử nghiệm nhỏ trên một node, tôi sẽ bắt đầu ở 4 GB RAM, 2 vCPU và 60 GB lưu trữ NVMe, rồi kiểm tra tải trên đúng luồng đăng nhập thật. Đó là mốc để lập kế hoạch, không phải mức tối thiểu cho môi trường thật ở mọi trường hợp. Các ứng dụng tương đối nhẹ, nhưng PostgreSQL cần bộ nhớ còn việc băm mật khẩu cần dư địa CPU. Hướng dẫn cho môi trường thật của ZITADEL khuyến nghị dành sẵn bốn nhân CPU cho các đợt cao điểm băm mật khẩu.
Khi sản phẩm đã thật và lưu lượng ổn định, hãy định cỡ lại dựa trên số đo. Lưu trữ nhanh giúp giảm độ trễ của PostgreSQL, còn dư địa CPU quan trọng khi băm mật khẩu diễn ra đồng thời. Hãy theo dõi bộ nhớ, I/O cơ sở dữ liệu, độ trễ đăng nhập và mức bão hòa CPU thay vì mặc định rằng một tài nguyên là quan trọng nhất.
Chạy CIAM trong môi trường thật nghĩa là thời gian hoạt động của nó giờ là vấn đề của bạn. Chúng tôi chạy các máy Cloudzy Linux VPS cho loại tải công việc này, với lưu trữ NVMe và SLA thời gian hoạt động 99,95% trên nền tảng bên dưới. Cloudzy cũng cung cấp VPS ZITADEL chỉ với một cú nhấp nếu bạn muốn bỏ qua kịch bản cấp phát ban đầu; ba cái còn lại cung cấp image container chính thức cho cách cài bằng Docker. Để có góc nhìn ở tầm quản lý về việc kiểm soát truy cập ăn khớp thế nào với phần còn lại của tư thế bảo mật, hướng dẫn thực hành tốt nhất về IAM bàn về nó từ góc độ chính sách.
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 LinuxCâu hỏi thường gặp
Giấy phép AGPL của ZITADEL có ảnh hưởng tới SaaS của tôi không?
Thường là không, với một bản triển khai không sửa đổi và tích hợp riêng biệt, nhưng đây không phải tư vấn pháp lý. Nghĩa vụ AGPL của ZITADEL áp dụng cho chính ZITADEL. Nếu bạn sửa đổi ZITADEL và vận hành bản đã sửa đó như một dịch vụ mạng, giấy phép có thể buộc bạn cung cấp mã nguồn tương ứng theo AGPL. Quan điểm công khai của ZITADEL là việc chỉ dùng một instance không sửa đổi làm dịch vụ danh tính cho SaaS của bạn, tự nó, không buộc bạn phải cấp phép ứng dụng riêng của mình theo AGPL. Hãy đọc thông báo về giấy phép của ZITADEL và hãy xin tư vấn pháp lý nếu bạn sửa đổi, phân phối lại, nhúng hoặc cung cấp phần mềm cho bên thứ ba. Cũng có giấy phép thương mại.
Vì sao Keycloak hay Authentik không có trong danh sách này?
Keycloak và Authentik là những công cụ danh tính tự lưu trữ rất tốt (tôi có dùng chúng), nhưng loại Keycloak vì cho rằng nó thiếu tổ chức B2B thì nay đã sai: các bản phát hành Keycloak hiện tại đã có Organizations, nhóm tổ chức và cơ chế quản trị ủy quyền. Tôi để nó ra ngoài vì bài so sánh này tập trung vào bốn lựa chọn có con đường trực tiếp hơn cho một SaaS B2B nhóm nhỏ; Keycloak xứng đáng có một bài đánh giá riêng khi việc vận hành JVM, chiều sâu hệ sinh thái và độ linh hoạt ở cấp realm là quan trọng. Authentik vẫn phù hợp hơn với SSO nội bộ và ứng dụng nội bộ, chứ không phải mô hình hóa tenant gắn liền với sản phẩm.
Tự lưu trữ có rẻ hơn Auth0 không?
Với lượng MAU thấp thì thường là không. Giờ kỹ sư của bạn đắt hơn hóa đơn Auth0 ở bậc startup giai đoạn đầu. Tự lưu trữ thắng về kinh tế ở quy mô mà giá theo MAU của CIAM được quản lý vượt qua tổng chi phí một VPS nhỏ cộng với vài giờ kỹ thuật mỗi tháng bạn bỏ ra cho nó. Điểm hòa vốn chính xác phụ thuộc vào chi phí theo giờ của đội bạn, đường cong tăng trưởng MAU, và việc sản phẩm có cần những tính năng doanh nghiệp đẩy bạn lên các bậc giá cao hơn của Auth0 hay không. Hãy xem khoản tiết kiệm là có thật nhưng không tức thì.
Kích thước VPS tối thiểu cho CIAM chạy thật là bao nhiêu?
Với một bản thử nghiệm nhỏ trên một node, 4 GB RAM, 2 vCPU và lưu trữ NVMe là điểm khởi đầu hợp lý, không phải một bảo đảm cho môi trường thật. Hãy định cỡ từ dung lượng cơ sở dữ liệu, tải đăng nhập đồng thời, chi phí băm mật khẩu và mục tiêu thời gian hoạt động của bạn. Chính hướng dẫn cho môi trường thật của ZITADEL khuyến nghị có sẵn bốn nhân CPU cho các đợt băm cao điểm; các công cụ khác và mô hình lưu lượng khác cần bài kiểm tra tải riêng.
Sau này tôi có thể chuyển từ CIAM được quản lý sang tự lưu trữ không?
Được, nhưng hãy lên kế hoạch như một dự án thực thụ. Việc đặt lại mật khẩu không phải là điều tất yếu: khả năng xuất dữ liệu và các định dạng băm được hỗ trợ khác nhau, và một số hệ đích hỗ trợ di chuyển người dùng hàng loạt hoặc theo kiểu just-in-time , trong khi những hệ khác bắt buộc phải đặt lại. Các yếu tố MFA, client OAuth, phiên đang hoạt động, trạng thái xác minh email và ánh xạ tenant hay vai trò đều cần xử lý riêng. Nếu bạn đã ngờ rằng sau này sẽ tự lưu trữ, hãy ghi lại những ràng buộc về xuất dữ liệu và di chuyển đó trước khi chọn nhà cung cấp được quản lý.
