Hiểu Đúng Bản Chất Của Authentication: Khác Biệt Giữa JWT, OAuth2 và SSO
Chào anh em Viblo,
Nếu bạn đang chuẩn bị cho một cuộc phỏng vấn vị trí Backend Developer, Fullstack hay Software Architecture, chắc chắn bạn sẽ không ít lần đụng độ câu hỏi "kinh điển" này:
"Bạn có thể giải thích sự khác nhau giữa JWT, OAuth 2.0 / Auth0 và SSO được không? Khi nào thì hệ thống nên dùng cái nào?"
Đây là một câu hỏi rất hay vì nó không chỉ kiểm tra lý thuyết mạng, mà còn đánh giá tư duy thiết kế hệ thống (System Design) và kiến thức về bảo mật của ứng dụng. Tuy nhiên, rất nhiều bạn thường bị "loạn chưởng" và đánh đồng cả 3 khái niệm này làm một.
Trong bài viết này, chúng ta hãy cùng nhau "mổ xẻ" bản chất, cách hoạt động, use-cases thực tế, và cuối cùng là một bảng phân biệt cực sắc bén để bạn tự tin ăn liền điểm tuyệt đối khi đi phỏng vấn nhé!
1. JWT (JSON Web Token) - "Tấm Vé Thông Hành"
Bản chất JWT là gì?
JWT không phải là một giao thức hay một quy trình đăng nhập. Nó đơn thuần là một định dạng chuỗi Token (được chuẩn hóa theo RFC 7519) dùng để truyền tải thông tin an toàn giữa Client và Server.
Cấu trúc của nó gồm 3 phần được phân tách bằng dấu chấm .:
Header.Payload.Signature
Cách thức hoạt động:
- Login: Người dùng gửi
username/passwordlên Server. - Tạo Token: Server xác thực thông tin hợp lệ -> Sử dụng một
Secret Keyđể ký (sign) ra một chuỗi JWT chứa thông tin nhanh (ví dụ:user_id,role). - Trả về Client: Client sẽ cất chuỗi JWT này (thường lưu ở LocalStorage, SessionStorage hoặc Cookie).
- Sử dụng: Cho mọi request tiếp theo, Client đính kèm JWT vào
AuthorizationHeader (định dạngBearer Token). - Xác thực: Server nhận được request, KHÔNG CẦN CHỌC VÀO DATABASE, chỉ dùng thuật toán và
Secret Keyđể verify lại chữ ký (Signature) xem token có bị làm giả hay hết hạn không.
Khi nào nên dùng?
- Phát triển RESTful APIs hoặc Single Page Applications (React, Vue, Angular).
- Hệ thống Microservices: Các service nội bộ có thể "tin tưởng" nhau và tự verify token của nhau nhờ chung Secret Key/Public Key.
- Khi cần một cơ chế bảo mật Stateless (Không lưu trạng thái): Giúp Server tiết kiệm RAM và Redis vì không phải lưu trữ
Session IDcủa hàng triệu users.
2. OAuth 2.0 & Auth0 - "Chiếc Chìa Khóa Nhà Hàng Xóm"
Bản chất là gì?
Đây là nhóm thường bị nhầm lẫn nhất.
- OAuth 2.0: Đây là một Giao thức phân quyền (Authorization Protocol Framework). Nó sinh ra để cho phép ứng dụng A (ví dụ web tìm việc) truy cập vào dữ liệu của bạn trên ứng dụng B (LinkedIn) MÀ KHÔNG CẦN bạn phải đưa mật khẩu cho ứng dụng A. Khi kết hợp với OpenID Connect (OIDC), nó trở thành lớp Xác thực (Authentication).
- Auth0 / AWS Cognito / Firebase: Là các nhà cung cấp dịch vụ (Identity-as-a-Service) xây dựng sẵn dựa trên OAuth2/OIDC. Bạn trả tiền để họ làm "bảo vệ" giữ mật khẩu, bạn không tự lưu mật khẩu trong DB của mình nữa.
Cách thức hoạt động (Ví dụ: Nút Đăng nhập bằng Google):
- User click "Login with Google". Ứng dụng gốc lập tức đá (Redirect) user sang trang đăng nhập của Google.
- User nhập mật khẩu ở domain
google.com. (Ứng dụng gốc hoàn toàn mù tịt về mật khẩu này). - Đăng nhập đúng, Google trả user về lại ứng dụng gốc, kèm theo một đoạn mã tạm (gọi là
Authorization Code). - Server của ứng dụng gốc lấy Code này, gửi gọi API "kín" lên Server Google để đổi lấy Access Token (Thường chính là dạng JWT) và ID Token.
- Giao dịch thành công, Server ứng dụng gốc cấp kẹo (session) cho User truy cập hệ thống.
Khi nào nên dùng?
- Social Login: Khi hệ thống yêu cầu "Đăng nhập bằng Google / Facebook / Github".
- Bảo mật tối đa, rảnh tay cho Dev: Khi dự án lớn, không muốn hệ thống phải tự gồng gánh khâu băm mật khẩu, mã hóa, quên mật khẩu, rule đổi mật khẩu, MFA... mà muốn Outsource/Ủy thác toàn bộ cho dịch vụ chuyên nghiệp bên thứ 3.
3. SSO (Single Sign-On - Đăng Nhập Một Lần) - "Chìa Khóa Vạn Năng"
Bản chất SSO là gì?
SSO không phải là một công nghệ hay thư viện cụ thể. Nó là một Mô hình Kiến trúc Hệ thống / Trải nghiệm người dùng (UX).
Nó cho phép người dùng chỉ cần đăng nhập một lần duy nhất, sau đó có thể đi lại tự do trong Nhiều ứng dụng khác nhau thuộc cùng một hệ sinh thái mà không cần đăng nhập lại. (Ví dụ thực tiễn: Bạn đăng nhập Gmail, sau đó mở Youtube, Google Drive - bạn đã tự động được đăng nhập thành công).
Cách thức hoạt động:
SSO thường được bộ phận IT vận hành bên dưới gốc rễ bằng các giao thức như (SAML 2.0 hoặc OAuth2.0/OIDC).
Sẽ có 3 thực thể tham gia: App A, App B và Identity Provider (IdP - Máy chủ xác thực trung tâm).
- Truy cập App A: Chưa đăng nhập -> Trỏ sang trang của IdP.
- Đăng nhập tại IdP: Nhập user/pass thành công -> IdP lưu Session Cookie dùng chung trên trình duyệt -> Trỏ lại App A kèm token để kích hoạt App A.
- Truy cập App B: Chưa đăng nhập -> Trỏ sang trang của IdP.
- TỰ ĐỘNG ĐĂNG NHẬP: Vì lúc nãy IdP đã lưu Cookie trên trình duyệt rồi -> Nó lập tức nhận diện được bạn -> Bỏ qua bước điền mật khẩu -> Trỏ ngay bạn lại App B kèm theo Token. Bạn thấy màn hình chuyển chớp nhoáng 1 cái là đã vào được App B.
Khi nào nên dùng?
- Môi trường doanh nghiệp (Enterprise/Corporate): Công ty có hệ thống Quản lý nhân sự, Jira, Tool nội bộ. Nhân viên đi làm chỉ login vào server của công ty 1 lần để dùng cả 3 (Thường dùng Microsoft Entra ID hoặc Okta).
- Hệ sinh thái sản phẩm khổng lồ của cùng một công ty chia làm nhiều Sub-domain.
"Chốt Hạ": Bảng Phân Biệt Sống Còn Đi Phỏng Vấn
Bí quyết để nhà tuyển dụng "gật gù" chính là bạn chỉ ra được bản chất về sự chênh lệch tầng (Category) của 3 khái niệm này. Chúng không chạy song song, mà chúng hỗ trợ lẫn nhau.
| Tiêu chí | JWT | OAuth 2.0 / Auth0 | SSO |
|---|---|---|---|
| Bản chất cốt lõi | Là một Định dạng (Format) chuỗi token. | Là một Giao thức (Protocol) / Dịch vụ ủy quyền. | Là một Kiến trúc hệ thống / Trải nghiệm (UX). |
| Mục đích chính | Đóng gói và truyền tải dữ liệu (claim) một cách bảo mật giữa Client và Server. | Ủy quyền (Delegate) việc xác thực/truy cập cho 1 bên thứ 3 xử lý. | Chia sẻ phiên đăng nhập (Session) giữa hàng loạt hệ thống độc lập. |
| Sự liên kết với nhau | Thường được dùng làm Access Token sinh ra ở bước cuối cùng của OAuth2 hoặc SSO. | Thường sử dụng JWT để format token trả về. Nó hoàn toàn có thể được dùng làm xương sống để dựng lên hệ thống SSO. | SSO ở dưới đáy là một máy chủ Identity Provider (IdP), nó thường chạy bằng SAML, hoặc chạy bằng OAuth 2.0 + (và trả về JWT). |
| Lưu trạng thái? | Stateless (Server không lưu). | Stateful hoặc Stateless tùy cài đặt. | Stateful (Máy chủ IdP phải nhớ phiên Cookie của user để auto-login cho web B). |
| Sự phụ thuộc | Code backend của bạn tự quản lý và Sign token. | Chạy dựa trên hạ tầng của nhà cung cấp khác (Google, Auth0...). | Bắt buộc phải dựng một máy chủ Identity (IdP) trung tâm đóng vai trò làm điểm kiểm soát. |
"3 khái niệm này luôn xuất hiện cạnh nhau nhưng chúng đóng vai trò ở các tầng hoàn toàn khác nhau. SSO là bài toán về kiến trúc trải nghiệm người dùng (login 1 lần dùng nhiều nơi), để xây dựng được SSO thực tế thì chúng ta cần sử dụng năng lực của các giao thức ủy quyền như OAuth2 / OIDC (Auth0 là hãng cung cấp dịch vụ mảng này), và khi quá trình giao thức chạy xong, kết quả phiên làm việc trả về cho các Client thường được đóng gói dưới định dạng chuỗi là JWT."
Chúc các bạn có thêm tự tin trong các buổi phỏng vấn Backend tới nhé! Hãy chia sẻ ý kiến dưới phần bình luận để chúng ta cùng thảo luận sâu hơn. Nguồn: https://dev.to/paudang/stop-confusing-authentication-the-ultimate-guide-to-jwt-vs-oauth2-vs-sso-567h
*Nếu các bạn quan tâm đến việc cấu trúc 1 dự án Node.js tối ưu và gọn lẹ cho cả REST API, đừng quên checkout công cụ CLI nodejs-quickstart-structure của mình nhé.
All rights reserved