Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn là BA cho một sản phẩm SaaS Việt Nam vừa ký được hợp đồng với một tập đoàn lớn. Buổi demo diễn ra suôn sẻ, khách hàng gật gù hài lòng. Đến phút cuối, anh trưởng phòng IT của khách hàng buông một câu: "Sản phẩm tốt đấy, nhưng có hỗ trợ đăng nhập bằng tài khoản Microsoft của công ty bọn anh không? Bên anh có 3.000 nhân viên, không thể bắt từng người tạo mật khẩu riêng được." Cả phòng im lặng nhìn về phía bạn.
Đây không phải tình huống hiếm. Trong các thương vụ B2B, đặc biệt khi bán cho doanh nghiệp lớn (enterprise), khả năng đăng nhập một lần — Single Sign-On (SSO) — gần như là điều kiện bắt buộc trên checklist mua hàng. Nếu sản phẩm của bạn không hỗ trợ, bạn có thể mất hợp đồng vào tay đối thủ ngay từ vòng đánh giá kỹ thuật.
Là BA, bạn không cần code phần SSO, nhưng bạn là người dịch nhu cầu "đăng nhập bằng Google/Microsoft" của khách hàng thành yêu cầu kỹ thuật rõ ràng cho đội dev. Bạn phải hiểu các luồng (flow), các vai trò, các thuật ngữ như IdP, SP, claim, redirect URI — để khi khách hàng hỏi, khi dev báo lỗi, hay khi viết user story, bạn không bị "đứng hình". Bài này tập trung riêng vào tích hợp SSO thực tế với Google và Microsoft — hai nhà cung cấp danh tính phổ biến nhất mà BA Việt Nam chắc chắn sẽ gặp.
Khái niệm cốt lõi
Single Sign-On là gì
SSO (Single Sign-On — đăng nhập một lần) là cơ chế cho phép người dùng đăng nhập một lần tại một nơi quản lý danh tính trung tâm, rồi từ đó truy cập nhiều ứng dụng khác nhau mà không phải nhập lại mật khẩu cho từng ứng dụng.
Ví dụ đời thường: khi bạn đăng nhập Gmail, sau đó mở YouTube, Google Drive, Google Photos — bạn không phải đăng nhập lại. Đó chính là SSO trong hệ sinh thái Google.
Hai vai trò chính: IdP và SP
Để hiểu SSO, bạn phải nắm chắc hai khái niệm này — chúng xuất hiện trong mọi cuộc họp về SSO:
- IdP (Identity Provider — nhà cung cấp danh tính): Là nơi lưu trữ và xác thực danh tính người dùng. IdP chịu trách nhiệm "bạn là ai". Ví dụ: Google, Microsoft Entra ID (tên cũ là Azure AD), Okta, Auth0, hay hệ thống nội bộ của doanh nghiệp.
- SP (Service Provider — nhà cung cấp dịch vụ): Là ứng dụng mà người dùng muốn truy cập. Chính là sản phẩm của bạn. SP tin tưởng IdP và nói: "Nếu Google/Microsoft xác nhận người này là thật, tôi cho họ vào."
Hai giao thức phổ biến: SAML và OIDC
Khi tích hợp SSO, đội dev sẽ chọn một trong hai giao thức. BA nên phân biệt được để biết khách hàng đang yêu cầu loại nào:
- SAML 2.0 (Security Assertion Markup Language): Giao thức cũ hơn, dùng định dạng XML, phổ biến trong môi trường enterprise truyền thống. Nhiều phòng IT doanh nghiệp lớn vẫn quen với SAML. Thông tin người dùng được gói trong một "assertion" (lời khẳng định) có chữ ký số.
- OIDC (OpenID Connect): Giao thức hiện đại hơn, xây dựng trên nền OAuth 2.0, dùng định dạng JSON và token. "Đăng nhập bằng Google" mà bạn thấy trên hầu hết web/app hiện nay đều dùng OIDC. Đây là lựa chọn mặc định cho ứng dụng mới, đặc biệt là web và mobile.
Các khái niệm BA cần thuộc lòng
- Claim: Một mẩu thông tin về người dùng do IdP cung cấp, ví dụ: email, họ tên, mã nhân viên, phòng ban. Khi viết yêu cầu, bạn cần liệt kê rõ "cần lấy những claim nào".
- Redirect URI (Callback URL): Địa chỉ mà IdP sẽ chuyển người dùng quay về sau khi xác thực thành công. Đây là chi tiết hay gây lỗi nhất trong tích hợp.
- Client ID và Client Secret: Cặp "tên đăng nhập và mật khẩu" của chính ứng dụng SP khi giao tiếp với IdP. Client Secret là bí mật, không bao giờ lộ ra phía trình duyệt.
- Provisioning: Việc tạo tài khoản người dùng trong hệ thống của bạn. "Just-in-time provisioning" nghĩa là tự tạo tài khoản ngay lần đầu người dùng đăng nhập SSO thành công.
Tình huống thực tế
Tình huống 1: SaaS HR bán cho ngân hàng — yêu cầu Microsoft Entra ID
Công ty khởi nghiệp "NhanSuViet" cung cấp phần mềm quản lý nhân sự, đang chốt hợp đồng với một ngân hàng có 4.500 nhân viên. Phòng IT ngân hàng yêu cầu: nhân viên phải đăng nhập bằng đúng tài khoản công ty (dạng nguyenvana@nganhang.com.vn) qua Microsoft Entra ID, không được tạo mật khẩu riêng.
Là BA, bạn làm việc với IT ngân hàng và phát hiện thêm ba yêu cầu ẩn: (1) khi một nhân viên nghỉ việc và bị khóa tài khoản Microsoft, họ phải mất quyền truy cập NhanSuViet ngay lập tức; (2) phải lấy được claim "phòng ban" để tự động phân quyền; (3) ngân hàng muốn dùng OIDC chứ không phải SAML vì đội IT mới của họ thích chuẩn hiện đại.
Diễn giải: Bạn ghi nhận thành ba yêu cầu kỹ thuật riêng. Yêu cầu (1) thực ra là một điểm mạnh tự nhiên của SSO: vì xác thực do Entra ID quản lý, khóa tài khoản ở IdP đồng nghĩa người dùng không thể đăng nhập SP nữa. Yêu cầu (2) buộc bạn phải làm việc với IT ngân hàng để cấu hình Entra ID trả về claim phòng ban — không phải claim nào cũng có sẵn mặc định. Yêu cầu (3) định hướng đội dev chọn OIDC.
Bài học: SSO không chỉ là "đăng nhập". Nó kéo theo các kịch bản về vòng đời tài khoản (nghỉ việc, đổi phòng ban) và dữ liệu (claim nào lấy được). BA giỏi là người khai thác được các yêu cầu ẩn này trước khi dev viết dòng code đầu tiên.
Tình huống 2: App giáo dục cho trường học — "Đăng nhập bằng Google"
Startup "EduBox" làm nền tảng học trực tuyến, bán cho các trường phổ thông dùng Google Workspace for Education. Học sinh và giáo viên đã có sẵn tài khoản dạng hocsinh@truongabc.edu.vn. Trường yêu cầu chỉ cần một nút "Đăng nhập bằng Google".
Trong buổi phân tích, bạn — BA — đặt câu hỏi tưởng đơn giản nhưng cực kỳ quan trọng: "Bất kỳ tài khoản Google nào cũng đăng nhập được, hay chỉ tài khoản thuộc tên miền của trường?" Hóa ra trường chỉ muốn cho phép tài khoản có đuôi @truongabc.edu.vn, để học sinh không dùng Gmail cá nhân lách vào.
Diễn giải: Đây là cấu hình "domain restriction" — giới hạn theo tên miền (tham số hd của Google). Bạn viết rõ trong user story: "Hệ thống chỉ chấp nhận đăng nhập Google với email thuộc tên miền đã được trường đăng ký; email ngoài tên miền bị từ chối với thông báo rõ ràng." Bạn cũng làm rõ kịch bản provisioning: lần đầu một giáo viên đăng nhập, hệ thống tự tạo tài khoản với vai trò mặc định là "Giáo viên" dựa trên một danh sách trường cung cấp.
Bài học: "Đăng nhập bằng Google" nghe có vẻ đơn giản nhưng giấu nhiều quyết định nghiệp vụ: ai được vào, vai trò gì, tạo tài khoản lúc nào. BA chính là người bóc tách những điều này — nếu bỏ sót, học sinh lớp này có thể vô tình xem được dữ liệu lớp khác.
Tình huống 3: Lỗi redirect URI làm chậm go-live
Sàn thương mại "ChợSố" tích hợp đăng nhập Google cho cổng đối tác bán hàng. Đội dev test trên môi trường staging chạy ngon lành, nhưng khi đẩy lên production thì mọi người bấm "Đăng nhập bằng Google" đều nhận lỗi redirect_uri_mismatch của Google. Go-live bị hoãn nửa ngày, các đối tác bắt đầu gọi điện phàn nàn.
Diễn giải: Nguyên nhân: trong Google Cloud Console, đội dev chỉ khai báo redirect URI cho staging (https://staging.choso.vn/auth/callback) mà quên thêm URI của production (https://choso.vn/auth/callback). Google chỉ cho phép chuyển hướng về đúng những URI đã đăng ký trước, nên production bị chặn. Là BA, bạn không sửa code, nhưng nếu trong checklist bàn giao có mục "đã đăng ký đầy đủ redirect URI cho mọi môi trường (dev, staging, production)?" thì sự cố đã không xảy ra.
Bài học: Nhiều lỗi SSO không phải lỗi logic mà là lỗi cấu hình giữa hai môi trường. BA có thể phòng ngừa bằng một checklist bàn giao rõ ràng, biến kiến thức kỹ thuật thành công cụ quản lý chất lượng.
Hướng dẫn từng bước
Dưới đây là quy trình BA nên đi qua khi sản phẩm cần tích hợp SSO với Google/Microsoft. Bạn không tự làm hết, nhưng bạn là người điều phối và đảm bảo không sót bước.
Bước 1 — Làm rõ IdP và giao thức. Hỏi khách hàng họ dùng nhà cung cấp danh tính nào (Google Workspace, Microsoft Entra ID, Okta...) và muốn giao thức nào (OIDC hay SAML). Đừng giả định — hãy hỏi thẳng phòng IT của khách hàng.
Bước 2 — Xác định claim cần lấy. Liệt kê những thông tin người dùng mà sản phẩm cần: email, họ tên, mã nhân viên, phòng ban, vai trò. Đối chiếu xem IdP của khách hàng có cung cấp đủ những claim đó không.
Bước 3 — Thiết kế luồng đăng nhập. Mô tả rõ: người dùng bấm nút "Đăng nhập bằng Microsoft" → được chuyển sang trang đăng nhập của IdP → nhập thông tin → IdP xác nhận và chuyển về redirect URI → SP tạo phiên đăng nhập. Vẽ thành sequence diagram đơn giản cho dev và khách hàng cùng hiểu.
Bước 4 — Làm rõ quy tắc provisioning và phân quyền. Lần đầu đăng nhập thì tạo tài khoản tự động hay phải được admin duyệt trước? Vai trò mặc định là gì? Có giới hạn theo tên miền email không?
Bước 5 — Xử lý vòng đời tài khoản. Khi nhân viên nghỉ việc và bị khóa ở IdP, điều gì xảy ra với dữ liệu của họ trong sản phẩm? Khi đổi phòng ban, quyền có cập nhật lại không?
Bước 6 — Lập checklist cấu hình và bàn giao. Đăng ký Client ID/Secret, khai báo đầy đủ redirect URI cho mọi môi trường, cấu hình claim mapping. Đây là nơi nhiều dự án vấp ngã, nên hãy viết thành danh sách kiểm tra.
Bước 7 — Định nghĩa các kịch bản lỗi và phương án dự phòng. Người dùng từ chối cấp quyền thì sao? Email không thuộc tên miền cho phép thì hiển thị thông báo gì? Có cần một lối đăng nhập dự phòng (ví dụ tài khoản admin nội bộ) phòng khi IdP gặp sự cố không?
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm lẫn giữa đăng nhập (authentication) và phân quyền (authorization). SSO trả lời câu hỏi "bạn là ai", không phải "bạn được làm gì". Việc một người đăng nhập thành công không có nghĩa họ được xem mọi thứ. BA phải tách bạch hai phần này trong yêu cầu, nếu không sẽ có lỗ hổng dữ liệu.
Lỗi 2 — Quên kịch bản tài khoản đã tồn tại trùng email. Nếu một người dùng đã đăng ký bằng email/mật khẩu, rồi sau đó đăng nhập SSO với cùng email đó, hệ thống nên gộp hay tạo tài khoản mới? Đây gọi là "account linking" và phải được quyết định rõ từ đầu.
Lỗi 3 — Bỏ qua môi trường khi đăng ký redirect URI. Như tình huống 3, mỗi môi trường (dev, staging, production) cần URI riêng được khai báo trong cấu hình IdP. Hãy đưa vào checklist bàn giao.
Lỗi 4 — Không lường trước IdP gặp sự cố. Nếu chỉ có một lối vào duy nhất qua SSO và IdP của khách hàng down, không ai đăng nhập được. Cân nhắc một lối đăng nhập dự phòng cho ít nhất tài khoản quản trị.
Mẹo: Khi viết user story SSO, luôn kèm tiêu chí chấp nhận cho cả ba nhánh: đăng nhập thành công, đăng nhập thất bại (sai tài khoản, từ chối quyền), và đăng nhập với email ngoài phạm vi cho phép. Ba nhánh này bao phủ hầu hết rủi ro.
Mẹo: Tận dụng điểm mạnh của SSO khi thuyết phục nội bộ: giảm gánh nặng quên mật khẩu cho người dùng, tập trung kiểm soát truy cập cho IT của khách hàng, và bảo mật tốt hơn vì mật khẩu không lưu ở sản phẩm của bạn. Đây là những lợi ích nghiệp vụ giúp justify chi phí làm tính năng.
Bài tập thực hành
- Viết user story. Sản phẩm SaaS của bạn cần thêm "Đăng nhập bằng Microsoft" cho một khách hàng doanh nghiệp 2.000 nhân viên dùng Entra ID. Viết một user story kèm ít nhất 5 tiêu chí chấp nhận, bao phủ: đăng nhập thành công, lấy claim email và phòng ban, tự tạo tài khoản lần đầu, từ chối email ngoài tên miền, và xử lý khi người dùng nghỉ việc.
- Phân biệt vai trò. Cho tình huống một app bán lẻ cho đăng nhập bằng Google: hãy chỉ ra ai là IdP, ai là SP, claim nào cần lấy, và redirect URI nên trỏ về đâu.
- Phân tích sự cố. Một đồng nghiệp báo: "Đăng nhập Google chạy được ở máy dev nhưng lên production thì báo
redirect_uri_mismatch." Viết ba câu hỏi bạn sẽ đặt ra để chẩn đoán, và đề xuất một mục bổ sung vào checklist bàn giao để tránh tái diễn.
- Quyết định nghiệp vụ. Khách hàng muốn cho phép cả đăng nhập SSO và đăng nhập bằng email/mật khẩu. Hãy mô tả quy tắc account linking khi một người dùng đã có tài khoản mật khẩu rồi đăng nhập SSO với cùng email.
Tóm tắt
SSO cho phép người dùng đăng nhập một lần tại IdP (Google, Microsoft Entra ID...) để truy cập nhiều ứng dụng, trong đó sản phẩm của bạn đóng vai trò SP — ủy thác việc xác thực cho IdP thay vì tự quản lý mật khẩu. Hai giao thức chính là SAML (cũ, XML, enterprise truyền thống) và OIDC (hiện đại, JSON, mặc định cho app mới và "đăng nhập bằng Google"). Là BA, công việc của bạn không phải code, mà là làm rõ giao thức, claim cần lấy, quy tắc provisioning, phân quyền, giới hạn tên miền và vòng đời tài khoản — đồng thời lập checklist cấu hình để tránh các lỗi kinh điển như thiếu redirect URI giữa các môi trường. Nắm vững những điều này, bạn sẽ tự tin đối thoại với phòng IT của khách hàng và biến yêu cầu "cho đăng nhập bằng Microsoft" thành đặc tả rõ ràng, đầy đủ — đúng vai trò cầu nối giữa nghiệp vụ và kỹ thuật.