Tổng quan

OAuth là gì?

OAuth (Open Authorization) là một giao thức ủy quyền tiêu chuẩn mở, cho phép một ứng dụng bên thứ ba truy cập vào tài nguyên của bạn trên một dịch vụ khác — nhưng không cần biết hoặc lưu trữ mật khẩu của bạn.

Để hiểu định nghĩa trên 1 cách đơn giản, chúng ta có ví dụ sau: Bạn đang muốn đăng nhập vào 1 ứng dụng có tên là A. Trong ứng dụng A bạn thấy có 1 nút Đăng nhập với Google

Trong ví dụ trên, ứng dụng A được gọi là ứng dụng bên thứ 3 hay là client, Google là Authorization và Resource Server.

Tại sao OAuth ngày càng trở nên phổ biến và không thể thiếu trong các ứng dụng

Để biết tại sao OAuth ngày càng trở nên phổ biến và không thể thiếu đối với ứng dụng web/app hiện nay, ta phải nhắc đến lợi ích của nó đem lại

Bạn cài ứng dụng chỉnh sửa ảnh và muốn nó lưu ảnh thẳng vào Google Drive? Bạn dùng công cụ học tập và muốn nó tự động đồng bộ với lịch Google? OAuth giúp ứng dụng đó truy cập đúng vào dữ liệu bạn cho phép, mà không cần mật khẩu, không cần tải file thủ công.

Còn rất nhiều lợi ích nữa mà OAuth mang đến, và chung quy lại mục đích của nó là tạo ra sự tiện lợi giữa người dùng và các dịch vụ.

Cấu trúc của OAuth

OAuth gồm các thành phần chính:

Thành phần	Vai trò
Resource Owner	Chủ sở hữu tài nguyên
Client	Ứng dụng bên thứ ba muốn truy cập tài nguyên
Authorization Server	Server xác thực và cấp token ủy quyền
Resource Server	Nơi chứa tài nguyên (API, dữ liệu), kiểm tra token để cấp tài nguyên

Trong đó:

1. Resource Owner – Chủ sở hữu tài nguyên có thể là:
   • Con người – khi OAuth được dùng để cho phép ứng dụng truy cập thay mặt cho người dùng.
   • Hệ thống – khi OAuth dùng trong môi trường máy nói chuyện với máy (server-to-server), không có con người tham gia
2. Client là ứng dụng mà chúng ta đang muốn đăng nhập, là ứng dụng sẽ gửi yêu cầu xin thông tin danh tính của bạn tới google.
3. Authorization Server – Máy chủ Ủy quyền: Là server chịu trách nhiệm xác thực Resource Owner và cấp Access Token cho Client khi được ủy quyền.
4. Resource Server – Máy chủ Tài nguyên: Là server chứa các tài nguyên được bảo vệ, chịu trách nhiệm xác nhận Access Token của client và trả về dữ liệu tương ứng.

OAuth hoạt động như thế nào?

Khi nắm rõ được 4 thành phần cốt lõi của OAuth được trình bày ở phần trên, chúng ta tiếp tục đi vào phần cơ chế hoạt động của OAuth.

Giai đoạn 1: Lấy giấy phép

(A) Gửi Authorization Request – Yêu cầu cấp quyền

Nguyên lý kỹ thuật	Thực tế phía người dùng
Client (ứng dụng) gửi yêu cầu đến Resource Owner (người dùng) để xin quyền truy cập dữ liệu.	Người dùng được đưa tới trang Google/Facebook… với câu hỏi: “App A muốn truy cập vào email và thông tin cá nhân của bạn. Bạn có đồng ý không?”

Ý chính: Client hỏi người dùng: “Tôi có thể truy cập dữ liệu của bạn không?”

(B) Nhận Authorization Grant – Mã ủy quyền

Sau khi người dùng đồng ý, Resource Owner đã cấp cho Client một Authorization Grant (mã ủy quyền). Mã này là bằng chứng rằng người dùng đã đồng ý cho phép Client truy cập.

Giai đoạn 2: Lấy Access Token

(C) Gửi Authorization Grant – Giấy phép ủy quyền

Sau khi nhận được “giấy phép tạm thời” (Authorization Grant) ở bước B, Client (Ứng dụng A) sẽ gửi “giấy phép” này đến Máy chủ Ủy quyền (Authorization Server) của Facebook/Google để chứng minh nó đã được bạn cho phép.

(D) Nhận Access Token – Mã truy cập

Sau khi nhận được “giấy phép tạm thời” từ Client (Ứng dụng A), Máy chủ Ủy quyền (Authorization Server) sẽ tiến hành kiểm tra “giấy phép” này. Nếu hợp lệ, nó sẽ cấp cho Client một thứ gọi là Access Token.

Access Token giống như một chiếc “chìa khóa” thực sự. Chiếc chìa khóa này có thời hạn và có phạm vi quyền hạn nhất định (ví dụ: chỉ được đọc ảnh, không được xóa).

Giai đoạn 3: Truy cập tài nguyên

(E) Sử dụng Access Token – Mã truy cập

Tại đây, Client (ứng dụng A) đã có “chìa khóa” (Access Token). Nó sẽ dùng “chìa khóa” này để gửi yêu cầu đến Máy chủ Tài nguyên (Resource Server), và nói: “Hãy cho tôi Tên, email, sđt của người dùng này, đây là chìa khóa chứng minh tôi được phép”.

(F) Nhận Protected Resource – Tài nguyên được bảo vệ

Máy chủ Facebook/Google (Resource Server) sẽ tiến hành kiểm tra “chìa khóa” (Access Token). Nếu “chìa khóa” hợp lệ, nó sẽ trả về dữ liệu được yêu cầu (các thông tin của bạn) cho ứng dụng A.

Các loại Authorization Grant trong OAuth

Có nhiều cách để triển khai luồng OAuth, trong đó sự khác biệt của các cách triển khai OAuth sẽ tập trung tại bước (B), (C), (D) liên quan đến khái niệm Authorization Grant:

Trong OAuth có 4 loại triển khai Authorization Grant đó là:

	Sử dụng khi nào?	Đặc điểm chính
Authorization Code	Ứng dụng web SSR/CSR, App mobile/desktop	Người dùng đăng nhập → Client Nhận Code → Client đổi Code lấy Token ở Backend
Implicit	Ứng dụng web SSR/CSR, App mobile/desktop	Người dùng đăng nhập → Nhận ngay Token trên trình duyệt
Resource Owner Password	Ứng dụng “chính chủ”	Ứng dụng lấy trực tiếp username & password của người dùng
Client Credentials	Machine-to-Machine (M2M)	Ứng dụng tự xác thực để lấy Token. Không có người dùng.

Authorization Code

Implicit

Resource Owner Password Credentials

Client Credentials

Kết luận

Qua bài viết này, chúng ta đã cùng nhau khám phá toàn bộ những kiến thức nền tảng của OAuth — từ khái niệm, lý do tại sao nó trở thành tiêu chuẩn bảo mật quan trọng trong thế giới số hiện đại, cho đến cách thức hoạt động chi tiết của giao thức này.

OAuth không chỉ giúp người dùng an toàn hơn khi sử dụng dịch vụ trực tuyến, mà còn mang lại khả năng kết nối, tích hợp và bảo mật cực kỳ mạnh mẽ giữa các ứng dụng và hệ thống.

Tuy nhiên, OAuth không chỉ đơn giản dừng lại ở cơ chế xin cấp quyền và cấp token. Để phù hợp với nhiều tình huống sử dụng khác nhau — từ ứng dụng web, mobile, API backend cho đến hệ thống server-to-server — OAuth thiết kế ra 4 loại Authorization Grant chính, mỗi loại có một luồng hoạt động riêng, ưu nhược điểm và kịch bản sử dụng khác nhau.

Ở bài blog tiếp theo, chúng ta sẽ đi sâu vào chi tiết 4 luồng hoạt động chính của OAuth bao gồm:

• Authorization Code Flow – Luồng mã ủy quyền, phổ biến nhất trong các ứng dụng
• Implicit Flow – Luồng ngầm, được thiết kế cho ứng dụng web thuần frontend nhưng hiện nay dần bị thay thế.
• Resource Owner Password Credentials Flow – Luồng dùng trực tiếp username/password, ít khuyến khích do rủi ro bảo mật cao.
• Client Credentials Flow – Luồng dành cho giao tiếp server-to-server, không có sự tham gia của người dùng.

---