Hôm nay, chúng ta sẽ cùng mổ xẻ cách hoạt động của luồng OAuth 2.0 ba chân – điều bắt buộc phải hiểu nếu bạn là DevOps, DevNet, hay bất kỳ kỹ sư Automation nào đang làm việc với API, CI/CD hoặc các ứng dụng tích hợp dịch vụ ngoài như Google, Facebook, GitHub...
OAuth 2.0 – Ủy quyền 3 chân là gì?
Khác với luồng 2 chân – nơi ứng dụng trực tiếp “nói chuyện” với API server, thì luồng 3 chân đưa người dùng (resource owner) vào cuộc.
Thành phần tham gia:
Chủ sở hữu tài nguyên: người dùng (như bạn!)
Ứng dụng khách: nơi bạn đăng nhập (website, app…)
Máy chủ ủy quyền (Authorization Server): xác thực và cấp mã truy cập
Máy chủ tài nguyên (Resource Server): chứa dữ liệu (Google Drive, Facebook profile, v.v.)
Luồng OAuth 2.0 ba chân hoạt động ra sao?
Bước 1: Người dùng ủy quyền (Get Authorization Code)
Ứng dụng hiển thị nút “Đăng nhập bằng Google”.
Người dùng được chuyển hướng đến máy chủ xác thực (Google OAuth).
Hệ thống xác minh, người dùng chấp thuận quyền truy cập.
Google trả lại cho ứng dụng một mã ủy quyền (Authorization Code).
Ví dụ thực tế: Khi bạn đăng nhập LinkedIn qua Google, bạn được hỏi có cho phép ứng dụng đọc email không – đó là lúc bạn cấp quyền.
Bước 2: Đổi mã ủy quyền lấy mã truy cập (Get Access Token)
Ứng dụng dùng mã ủy quyền gửi đến máy chủ OAuth.
Máy chủ trả lại:
Access Token: dùng để gọi API lấy dữ liệu người dùng.
Refresh Token (nếu có): để làm mới access token khi hết hạn.
Bước 3: Gọi API bằng Access Token
Ứng dụng gọi đến API (ví dụ: Google Calendar API) kèm theo access token.
Dữ liệu được trả về – ứng dụng xử lý và hiển thị cho người dùng.
Ví dụ thực tế: Google Calendar tích hợp vào ứng dụng tổ chức cuộc họp của công ty bạn – không ai cần nhập lại mật khẩu.
Tùy chọn: Làm mới mã truy cập
Khi access token hết hạn, ứng dụng dùng refresh token để lấy token mới – không cần người dùng đăng nhập lại.
Lợi ích siêu thiết thực
Không phải truyền hay lưu mật khẩu người dùng.
Có thể giới hạn quyền truy cập: chỉ đọc profile, không xóa dữ liệu.
Token có thể hết hạn – hạn chế rủi ro nếu bị lộ.
Một chuẩn mở, phổ biến toàn cầu – ai cũng dùng được!
So sánh nhanh với OAuth 2.0 hai chân:
| Luồng hai chân | Luồng ba chân |
|---|---|
| Ứng dụng truy cập trực tiếp API | Có người dùng tham gia xác thực |
| Không có giao diện cấp quyền | Có trang đồng ý (consent screen) |
| Phù hợp cho server-to-server | Phù hợp với app người dùng |
Khi nào nên dùng luồng ba chân?
Khi ứng dụng cần quyền truy cập dữ liệu người dùng (email, lịch, hình ảnh, v.v.).
Khi bạn không thể tin tưởng hoặc lưu trữ mật khẩu người dùng.
Khi muốn ứng dụng hoạt động linh hoạt, bảo mật, chuẩn quốc tế.
Bạn là DevOps/DevNet? Bạn đang tích hợp API? Vậy thì hiểu rõ luồng OAuth ba chân là bước không thể thiếu để làm chủ các ứng dụng hiện đại!
Bạn đã từng gặp lỗi 401 khi gọi API chưa? Hãy thử kiểm tra lại token nhé.
