Bỏ qua đến nội dung

authentik giải thích: IdP, SSO, SAML, OAuth2/OIDC, Okta, Auth0 là gì?

Một bài dẫn nhập mạch lạc về authentik, IdP, SSO và các giao thức đăng nhập để bạn thấy identity management bớt mù mờ.

15 phút đọcEnglish
authentik giải thích: IdP, SSO, SAML, OAuth2/OIDC, Okta, Auth0 là gì?

Có những README chỉ mất 30 giây để đọc, nhưng lại mở ra cả một mê cung khái niệm.

README của goauthentik/authentik là một ví dụ như vậy. Ngay phần giới thiệu, bạn gặp câu này:

authentik is an open-source Identity Provider (IdP) for modern SSO. It supports SAML, OAuth2/OIDC, LDAP, RADIUS, and more…

Nghe có vẻ gọn, nhưng gần như từ nào cũng là một cánh cửa: IdP là gì, SSO khác login thường ở đâu, tại sao lúc thì SAML, lúc thì OAuth2/OIDC, rồi Okta/Auth0/Entra/Ping là giao thức hay sản phẩm?

Bài này không cố biến bạn thành chuyên gia identity trong 10 phút. Nó chỉ làm một việc thực tế hơn: dựng cho bạn một bản đồ đủ rõ để đọc README, xem docs, hoặc nghe đồng nghiệp nói về SSO mà không bị trôi khỏi cuộc trò chuyện.

Repository: goauthentik/authentik


TL;DR

  • IdP (Identity Provider) là “phòng bảo vệ trung tâm” biết bạn là ai.
  • SSO (Single Sign-On) là đăng nhập một lần rồi đi vào nhiều ứng dụng.
  • SAML, OAuth2/OIDC, LDAP, RADIUS là các “ngôn ngữ” khác nhau để app nói chuyện với hệ thống định danh.
  • Okta, Auth0, Microsoft Entra ID, Ping Identity là các sản phẩm IdP thương mại.
  • authentik là một IdP mã nguồn mở, tự host được, dùng để gom login, MFA, user/group, policy và app portal vào một chỗ.

Hãy tưởng tượng công ty có 20 ứng dụng nội bộ: GitLab, Grafana, Nextcloud, VPN, Wi-Fi, dashboard tài chính. Nếu mỗi app tự giữ user/password riêng, bạn sẽ có 20 nơi để quên mật khẩu, 20 nơi phải disable khi nhân viên nghỉ việc, và 20 kiểu phân quyền khác nhau.

Trước khi nói authentik giải quyết gì, hãy nhìn vào bức tranh không có authentik trước. Scene dưới đây cố tình không vẽ một “luồng đăng nhập đẹp”; nó vẽ sự phân mảnh: mỗi app có database user riêng, rule riêng, và đường offboarding riêng.

Điểm đau không nằm ở việc user phải nhập mật khẩu nhiều lần. Đó chỉ là phần dễ thấy. Điểm đau thật là không có một nơi duy nhất để trả lời: user này là ai, thuộc nhóm nào, còn được quyền vào app nào không?

authentik đổi cách nghĩ đó thành một câu gọn hơn nhiều: một nơi quản lý danh tính, nhiều app tin vào nơi đó.

Scene tiếp theo chính là phiên bản “dọn lại dây điện”: app không tự ôm password nữa; app nói bằng một protocol chuẩn; authentik kiểm tra user/group/policy; rồi trả về token hoặc assertion để app tin.

Từ đây trở đi, hãy giữ cặp hình này trong đầu. Không có authentik nghĩa là mỗi app tự xử lý danh tính. Có authentik nghĩa là danh tính trở thành một lớp hạ tầng chung. Mọi thuật ngữ phức tạp phía sau chỉ đang trả lời ba câu: ai đăng nhập, được vào đâu, và app nhận bằng chứng bằng cách nào.


Beginner Map

Để bài này dễ thấm hơn, đừng đọc như học thuộc bảng thuật ngữ. Hãy đọc như đang so sánh hai sơ đồ ở trên: trước đây mỗi app tự giữ danh tính; sau đó authentik đứng giữa để gom danh tính lại một nơi.

  1. Lượt 1: hiểu vì sao mô hình “mỗi app tự login” nhanh chóng trở nên rối.
  2. Lượt 2: hiểu câu “IdP là nơi các app hỏi: người này là ai?”
  3. Lượt 3: phân biệt SAML, OAuth2/OIDC, LDAP, RADIUS bằng ngữ cảnh dùng.
  4. Lượt 4: quay lại README authentik và đọc lại câu khó ban đầu.

Trọng tâm là vai trò, không phải tên chuẩn. Khi vai trò đã rõ, tên chuẩn tự nhiên sẽ bớt đáng sợ:

Từ khóa Câu hỏi nó trả lời
Identity Provider Ai là người xác nhận danh tính?
SSO Làm sao đăng nhập một lần dùng nhiều app?
Protocol App và IdP nói chuyện bằng chuẩn nào?
Directory Danh sách user/group nằm ở đâu?
Policy Luật cho phép hoặc từ chối là gì?

Thực hành đầu tiên

Lấy một app bạn biết, ví dụ GitLab. Tự vẽ 5 ô: User -> GitLab -> authentik -> Users/Groups -> GitLab. Sau đó trả lời:

  • User nhập mật khẩu ở GitLab hay authentik?
  • GitLab có cần lưu password của user không?
  • Nếu user nghỉ việc, bạn disable ở GitLab hay authentik?

Nếu trả lời được 3 câu này, phần còn lại của bài sẽ rất nhẹ: bạn chỉ đang đặt tên chính xác cho những gì sơ đồ đó đã thể hiện.


Phần 1: Nền tảng - IdP và SSO là gì?

Nếu nhìn lại scene with authentik, node quan trọng nhất không phải GitLab, Grafana hay VPN. Node quan trọng nhất là authentik IdP, vì nó trở thành nơi các app cùng hỏi một câu: “người này là ai, và có được vào không?”

IdP: phòng bảo vệ trung tâm, nhưng cho phần mềm

Identity Provider (IdP) là hệ thống chịu trách nhiệm trả lời câu hỏi:

“Người này có đúng là người họ nói không?”

Trong ví dụ công ty, IdP giống phòng bảo vệ trung tâm:

  • Nhân viên đưa thẻ hoặc vân tay.
  • Bảo vệ kiểm tra hồ sơ.
  • Nếu hợp lệ, bảo vệ xác nhận: “Đúng, đây là Hoàng, thuộc team Engineering.”
  • Các phòng ban khác không cần tự kiểm tra giấy tờ từ đầu.

Trong phần mềm, câu chuyện diễn ra tương tự nhưng nhanh hơn và chặt chẽ hơn:

  • User không nhất thiết nhập password vào từng app.
  • App chuyển user sang IdP.
  • IdP xác thực bằng password, passkey, TOTP, WebAuthn, email, hoặc MFA.
  • IdP gửi bằng chứng cho app.
  • App tin bằng chứng đó và cho user vào.

SSO: một lần xác minh, nhiều cánh cửa mở ra

Single Sign-On (SSO) là trải nghiệm: bạn đăng nhập một lần, sau đó mở app khác không phải nhập lại mật khẩu.

Ví dụ:

  1. Bạn mở GitLab.
  2. GitLab chuyển bạn sang authentik.
  3. Bạn đăng nhập ở authentik.
  4. GitLab cho vào.
  5. Bạn mở Grafana.
  6. Grafana cũng hỏi authentik.
  7. authentik thấy bạn còn phiên đăng nhập hợp lệ, nên cho Grafana vào luôn.

Điểm quan trọng: SSO không có nghĩa là bỏ bớt bảo mật để tiện hơn. Nó gom bảo mật vào một nơi để việc bật MFA, khóa user, xem audit log, và áp policy trở nên nhất quán hơn. Tiện lợi chỉ là bề mặt; kiểm soát tập trung mới là giá trị thật.


Phần 2: Cuộc điều tra - authentik làm gì trong một lần login?

Giờ hãy zoom vào phần giữa của scene with authentik. Một lần login nhìn bên ngoài rất đơn giản, nhưng bên trong là nhiều mảnh nhỏ phối hợp với nhau:

  • User: tài khoản người dùng.
  • Group: nhóm như engineering, finance, admin.
  • Application: app được hiện trên dashboard, ví dụ GitLab hoặc Grafana.
  • Provider: cấu hình kỹ thuật để app nói chuyện với authentik bằng SAML, OAuth2/OIDC, proxy, LDAP…
  • Flow: chuỗi bước đăng nhập, ví dụ nhập username, nhập password, xác thực MFA, login.
  • Stage: một bước nhỏ trong Flow.
  • Policy: luật kiểm tra, ví dụ “chỉ group engineering được vào Grafana” hoặc “IP lạ thì bắt MFA”.

Khi những mảnh này ghép lại, một lần login điển hình sẽ chạy như sau:

  1. User mở app.
  2. App nói: “Tôi không tự login, đi hỏi authentik.”
  3. authentik chạy Flow: nhận diện user, kiểm tra password, yêu cầu MFA nếu cần.
  4. authentik chạy Policy: user này có thuộc nhóm được phép vào app không?
  5. Nếu pass, authentik gửi lại token hoặc assertion.
  6. App đọc bằng chứng đó và tạo phiên đăng nhập riêng của app.

Từ góc nhìn user, họ chỉ thấy một màn hình đăng nhập. Từ góc nhìn hệ thống, đó là một dây chuyền nhỏ: xác thực danh tính, kiểm tra quyền, rồi phát hành bằng chứng để app có thể tin.


Phần 3: Chẩn đoán - SAML, OAuth2/OIDC, LDAP, RADIUS khác nhau thế nào?

Đây là đoạn dễ làm người đọc rối nhất, vì tên giao thức thường nghe giống nhau. Cách đơn giản là đừng hỏi “định nghĩa chuẩn là gì?” trước. Hãy hỏi: app đang cần kiểu nói chuyện nào?

Thuật ngữ Cách hiểu nhanh Ngữ cảnh thường gặp
SAML Chuẩn SSO phổ biến trong enterprise, hay dùng XML assertion. “Nhân viên này là Hoàng, thuộc group Engineering, cho vào Salesforce.”
OAuth2 Chuẩn ủy quyền: app A được làm việc X thay user. “Cho app lịch đọc calendar của tôi, nhưng không được đọc email.”
OIDC Lớp đăng nhập nằm trên OAuth2, trả về thông tin danh tính. “Login with Google” theo kiểu hiện đại.
LDAP Cách truy vấn thư mục user/group kiểu cũ nhưng vẫn rất sống. NAS, Jenkins, VPN hỏi “user này thuộc group nào?”
RADIUS Chuẩn hay gặp trong network login. Wi-Fi/VPN hỏi server: “tài khoản này được vào mạng không?”

OAuth2 không đồng nghĩa với đăng nhập

OAuth2 gốc là authorization: cấp quyền cho app làm gì đó. OIDC thêm lớp identity để biến nó thành đăng nhập chuẩn hơn.

Nếu kéo tất cả về hình ảnh “chìa khóa và giấy xác nhận”, ta có:

  • OAuth2: “App này được cầm chìa khóa nào?”
  • OIDC: “Người đang cầm chìa này là ai?”
  • SAML: “Đây là giấy xác nhận danh tính có chữ ký.”
  • LDAP: “Tra danh bạ user/group giúp tôi.”
  • RADIUS: “Thiết bị mạng này có cho user vào không?”

Phần 4: Cách triển khai - authentik so với Okta, Auth0, Entra ID, Ping Identity

Sau khi hiểu giao thức, phần tên hãng sẽ dễ hơn nhiều. Okta, Auth0, Microsoft Entra ID và Ping Identity không phải là các chuẩn kiểu SAML hay OIDC. Chúng là sản phẩm IdP/identity platform.

So sánh rất thực dụng:

Sản phẩm Cách nghĩ nhanh
Okta IdP enterprise SaaS rất phổ biến cho công ty lớn.
Auth0 Nền tảng login cho ứng dụng, mạnh cho developer và customer identity.
Microsoft Entra ID IdP gắn chặt với hệ sinh thái Microsoft 365/Azure, trước đây quen gọi là Azure AD.
Ping Identity Identity platform lâu đời cho enterprise phức tạp.
authentik IdP mã nguồn mở, tự host được, linh hoạt cho homelab, startup, nội bộ công ty, hoặc môi trường muốn kiểm soát hạ tầng.

Để so sánh công bằng, đừng đọc scene dưới đây theo kiểu “authentik thắng tất cả”. Các đối thủ SaaS rất mạnh ở vận hành, hệ sinh thái enterprise, support và compliance. Điểm mạnh riêng của authentik nằm ở phía khác: kiểm soát, tự host, nhìn được bên trong, custom flow/policy, và nối được nhiều loại app cũ mới.

Điểm làm authentik thú vị là nó mang nhiều mảnh ghép enterprise về một hình thức có thể tự host và tự học:

  • App dashboard cho user.
  • Admin UI để quản lý user, group, provider, flow, event.
  • Flow/stage để custom quy trình login.
  • Policy để gắn luật vào flow, app hoặc source.
  • Nhiều protocol để nối với nhiều loại app.
  • Self-host bằng Docker Compose cho lab nhỏ hoặc Kubernetes cho cụm lớn hơn.

Nhưng sự tự do đó đi kèm trách nhiệm vận hành thật:

  • Bạn phải backup database.
  • Bạn phải bảo vệ secret và TLS.
  • Bạn phải update phiên bản.
  • Bạn phải thiết kế recovery khi IdP down, vì IdP down thì nhiều app cũng không login được.

Khi nào nên dùng authentik?

Nên cân nhắc nếu bạn:

  • Có nhiều app nội bộ và muốn một cổng login chung.
  • Muốn hiểu identity management qua vận hành thực tế, không chỉ qua định nghĩa.
  • Muốn self-host, kiểm soát dữ liệu, hoặc tránh phụ thuộc hoàn toàn vào SaaS.
  • Cần nối app cũ lẫn app mới bằng nhiều protocol khác nhau.

Ngược lại, nếu bạn chỉ có một app nhỏ, một database user đơn giản, và chưa có nhu cầu SSO/MFA/audit tập trung, thì authentik có thể là quá sớm. Công cụ tốt không phải lúc nào cũng là công cụ cần dùng ngay.


Final Take

Đến cuối bài, ta có thể thu gọn toàn bộ mê cung ban đầu thành một câu:

authentik là trạm kiểm soát danh tính đứng giữa user và các ứng dụng.

Nó không chỉ là màn hình login đẹp hơn. Nó là lớp điều phối nơi bạn gom:

  • ai là user,
  • user thuộc group nào,
  • app nào được phép dùng,
  • login cần những bước nào,
  • policy nào được áp dụng,
  • app sẽ nhận bằng chứng qua giao thức nào.

Khi README nói “open-source Identity Provider for modern SSO”, hãy dịch trong đầu thành:

“Một hệ thống mã nguồn mở để các app hỏi chung một nơi: người này là ai, có được vào không, và bằng chứng đăng nhập sẽ gửi bằng chuẩn nào?”

Khi nhìn theo cách đó, README không còn là một chuỗi acronym nữa. Nó trở thành một bản mô tả khá chính xác: authentik là nơi biến identity management từ nhiều mảnh rời rạc thành một điểm kiểm soát có thể hiểu, cấu hình, và vận hành.

Bài viết liên quan

Bạn vừa tìm thấy một trứng phục sinh nhỏ. Cứ tiếp tục khám phá!