Xác thực Client trong OAuth 2.0

Xác thực Client trong OAuth 2.0
OAuth 2.0 là một giao thức ủy quyền phổ biến, giúp các ứng dụng truy cập tài nguyên của người dùng một cách an toàn mà không cần chia sẻ thông tin đăng nhập. Một phần quan trọng trong OAuth 2.0 là xác thực client, đảm bảo rằng chỉ các ứng dụng đáng tin cậy mới có thể truy cập vào hệ thống.
Xác thực Client là gì?
Xác thực client là quá trình máy chủ ủy quyền (Authorization Server) xác minh danh tính của client (ứng dụng) trước khi cấp quyền truy cập hoặc token. Điều này giúp bảo vệ hệ thống khỏi các ứng dụng giả mạo hoặc không được phép.
Các phương thức xác thực Client phổ biến
Client ID và Client Secret
Client ID: Một định danh công khai để nhận diện ứng dụng.
Client Secret: Một chuỗi bí mật chỉ được chia sẻ giữa client và máy chủ ủy quyền.
Cách hoạt động: Client gửi Client ID và Client Secret trong yêu cầu đến máy chủ ủy quyền (thường qua header Authorization hoặc body của yêu cầu POST).
Ví dụ: Trong luồng Authorization Code, client gửi thông tin này để lấy access token.
Lưu ý: Client Secret chỉ phù hợp với các ứng dụng server-side có thể lưu trữ bí mật an toàn (ví dụ: web app). Ứng dụng public như ứng dụng di động không nên sử dụng Client Secret.
Private Key JWT
Client sử dụng một khóa riêng (private key) để ký một JSON Web Token (JWT).
Máy chủ ủy quyền xác minh JWT bằng khóa công khai (public key) tương ứng.
Ưu điểm: An toàn hơn vì không cần truyền Client Secret qua mạng. Phù hợp với các hệ thống phức tạp hoặc ứng dụng không lưu trữ bí mật.
Nhược điểm: Cần quản lý cặp khóa public/private phức tạp hơn.
Mutual TLS (mTLS)
Client và máy chủ ủy quyền sử dụng chứng chỉ SSL/TLS để xác thực lẫn nhau.
Client gửi chứng chỉ của mình trong quá trình bắt tay TLS.
Ưu điểm: Mức độ bảo mật cao, phù hợp với các ứng dụng yêu cầu bảo mật nghiêm ngặt.
Nhược điểm: Quản lý chứng chỉ phức tạp và tốn tài nguyên.
Khi nào sử dụng phương thức nào?
Client ID và Client Secret: Phù hợp với các ứng dụng web server-side đơn giản.
Private Key JWT: Lý tưởng cho các hệ thống phân tán hoặc ứng dụng không thể lưu trữ Client Secret an toàn.
mTLS: Dành cho các ứng dụng yêu cầu bảo mật cao, như trong ngành tài chính.
Lưu ý bảo mật
Lưu trữ Client Secret an toàn: Không để lộ Client Secret trong mã nguồn hoặc truyền qua kênh không mã hóa.
Sử dụng HTTPS: Tất cả các yêu cầu OAuth 2.0 phải được gửi qua HTTPS để tránh bị chặn hoặc giả mạo.
Xác minh định kỳ: Kiểm tra và cập nhật khóa, chứng chỉ để đảm bảo an toàn lâu dài.
+-------------------+ +-------------------+ +-------------------+
| Client | | Authorization | | Resource Server |
| (Ứng dụng) | | Server | | (API/Dữ liệu) |
+-------------------+ +-------------------+ +-------------------+
| | |
| 1. Yêu cầu xác thực | |
| (Client ID + Secret, | |
| JWT, hoặc mTLS) --------->| |
| | 2. Kiểm tra danh tính |
| | (So sánh Secret, |
| | Xác minh JWT, hoặc mTLS) |
| |<---------------------------|
| | 3. Trả về Access Token |
|<--------------------------| |
| 4. Sử dụng Access Token | |
|-------------------------->| |
| | 5. Truy cập tài nguyên |
| |--------------------------->|
| | 6. Trả về dữ liệu |
| |<---------------------------|
| 7. Nhận dữ liệu | |
|<--------------------------| |
Client gửi yêu cầu xác thực đến Authorization Server, sử dụng một trong các phương thức (Client ID + Secret, JWT, hoặc mTLS).
Authorization Server kiểm tra danh tính client dựa trên thông tin nhận được.
Nếu xác thực thành công, máy chủ trả về Access Token.
Client sử dụng Access Token để yêu cầu tài nguyên từ Resource Server.
Resource Server kiểm tra token và cấp quyền truy cập tài nguyên.
Dữ liệu được trả về cho client qua Authorization Server hoặc trực tiếp.
Subscribe to my newsletter
Read articles from Kilo directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
