Trong bài viết này, Sydexa sẽ hướng dẫn bạn hiểu rõ về luồng OAuth 2.0 thông qua các hình ảnh minh họa sinh động. OAuth 2.0 đang ngày càng trở nên quan trọng trong việc bảo mật thông tin người dùng trong các ứng dụng hiện đại. Hãy chia sẻ bài viết này với những người bạn đang tìm hiểu về thiết kế hệ thống chịu tải cao nhé! 😍
Chúng mình đã tạo một nhóm dành riêng cho những ai muốn chia sẻ và học hỏi về thiết kế hệ thống. Hãy tham gia để cùng nhau xây dựng Cộng đồng System Design Việt Nam mạnh mẽ! 😍
Cộng Đồng System Design Việt Nam: Nhấp vào đây để tham gia
Kênh TikTok của chúng tôi: Xem trang TikTok
Bạn có đang gặp khó khăn trong việc lấy danh sách bạn bè từ App B sang App A mà không muốn người dùng phải nhập thủ công? Hoặc App B không hỗ trợ xuất dữ liệu, khiến cho việc cập nhật danh bạ trở thành một vấn đề nan giải? Bạn cũng không muốn cung cấp thông tin đăng nhập của App B cho App A vì lí do bảo mật?
⇒ OAuth chính là "chìa khóa" giúp bạn giải quyết vấn đề này! OAuth cho phép App A truy cập an toàn vào danh sách bạn bè của App B mà không cần thu thập thông tin đăng nhập của người dùng.
OAuth là gì?
OAuth (Open Authorization) cho phép các ứng dụng bên thứ ba truy cập vào dữ liệu của người dùng mà không cần yêu cầu họ chia sẻ thông tin đăng nhập. Người dùng có quyền quyết định tài nguyên nào một ứng dụng có thể truy cập và hạn chế quyền truy cập phù hợp.
OAuth là từ viết tắt của O (Open) và Auth, tượng trưng cho:
- Authentication: xác thực người dùng.
- Authorization: cấp quyền truy cập đến tài nguyên mà người dùng đang nắm giữ. Ví dụ nổi bật là việc đăng nhập qua mạng xã hội sử dụng giao thức OAuth 2.0.
Các thuật ngữ chính trong OAuth
Trước khi khám phá các luồng OAuth, hãy cùng tìm hiểu một số thuật ngữ quan trọng:
| Thuật ngữ | Mô tả |
|---|---|
| Client 📦 | Ứng dụng bên thứ ba muốn truy cập tài nguyên. |
| Resource Owner 👤 | Người sở hữu tài nguyên cần truy cập, thường là người dùng cuối. |
| Resource 🖼 | Tài nguyên như ảnh, dữ liệu được truy cập qua API. |
| Resource Server 📚 | Máy chủ chứa tài nguyên được bảo vệ. |
| Authorization Server 🛡 | Máy chủ xử lý ủy quyền và cấp phát access token. |
| User-Agent 🌐 | Trình duyệt hoặc ứng dụng mà Resource Owner sử dụng để giao tiếp với Authorization Server. |
| Access Token 🔑 | Token được cấp phát sau khi ủy quyền thành công. |
| Refresh Token 🔄 | Token đặc biệt được sử dụng để làm mới Access Token. |
Ví dụ minh họa
Một end-user (Resource Owner 👤) cấp quyền truy cập cho một dịch vụ in ấn (Client 📦) vào ảnh của họ (Resource 🖼) được lưu trên một dịch vụ chia sẻ ảnh (Resource Server 📚) mà không cần chia sẻ username và password. Thay vào đó, họ xác thực với một hệ thống tin cậy (Authorization Server 🛡), hệ thống này sẽ cấp phát một access token trong thời gian hạn định.
Lưu ý: Client cần được đăng ký trong Authorization Server trước khi sử dụng. Một Client ID và có thể cả client secret sẽ được cấp tùy tình huống. Secret này chỉ được biết đến bởi Authorization Server và Ứng dụng.
Các luồng trong OAuth 2.0
- Authorization Code Grant
- Authorization Code Grant with PKCE
- Code Transformation Method (CM) - Meet SHA256
- Code Verifier (CV) & Code Challenge (CC)
- Client Credentials Grant
- Resource Owner Password Credentials Grant
- Implicit Grant
1. Luồng Authorization Code Grant
Luồng này rất phổ biến cho các ứng dụng web và di động. Quá trình bắt đầu bằng việc điều hướng người dùng từ Client tới trang đăng nhập. Quy trình này chủ yếu dành cho các confidential clients, những ứng dụng đã bảo đảm tính bảo mật cho client secret.
2. Luồng Authorization Code Grant với PKCE
Luồng này giải quyết các mối lo ngại về bảo mật cho các public clients, như các ứng dụng single-page JS hoặc native mobile. Quy trình này sử dụng Proof Key for Code Exchange (PKCE) để xác thực mà không cần client secret.
3. Luồng Client Credentials Grant
Trong luồng này, sự ủy quyền của người dùng không cần thiết. Client tự động thực hiện hành động ứng dụng mà không cần sự can thiệp của người dùng.
4. Luồng Resource Owner Password Credentials Grant
Luồng này chỉ nên áp dụng khi có sự tin cậy cao giữa Resource Owner và Client. Tuy nhiên, nó không được khuyến khích cho các ứng dụng hiện đại.
5. Luồng Implicit Grant
Luồng này không còn được khuyên dùng do dễ bị rò rỉ access token.
Lời khuyên: Sử dụng Authorization Code Grant hoặc các luồng an toàn khác thay cho Implicit Grant.
Hẹn gặp lại các bạn trong những bài viết thú vị tiếp theo từ Sydexa!
source: viblo
