OAuth 2.0 là gì? Cách hoạt động, ứng dụng và các luồng ủy quyền phổ biến

OAuth 2.0 là framework ủy quyền giúp ứng dụng truy cập tài nguyên của người dùng mà không cần chia sẻ thông tin đăng nhập. Khác với Authentication, OAuth 2.0 tập trung vào việc cấp quyền truy cập an toàn cho API và các hệ thống. Trong bài viết này, FPT.AI sẽ giúp bạn hiểu rõ cơ chế hoạt động, các OAuth Flow phổ biến và những lưu ý quan trọng khi triển khai.

OAuth 2.0 là gì?

OAuth 2.0 (Open Authorization 2.0) là một khung ủy quyền tiêu chuẩn cho phép ứng dụng bên thứ ba truy cập tài nguyên của người dùng trên một dịch vụ khác mà không cần chia sẻ mật khẩu. Thay vì cung cấp thông tin đăng nhập, hệ thống sẽ cấp Access Token để ứng dụng chỉ có thể sử dụng các tài nguyên trong phạm vi quyền (scope) đã được người dùng cho phép.

Ví dụ, khi bạn cho phép một ứng dụng truy cập Google Drive, OAuth 2.0 sẽ cấp token tương ứng với các quyền đã chấp thuận, chẳng hạn chỉ xem hoặc chỉnh sửa tệp. Nhờ đó, việc kết nối giữa ứng dụng và API trở nên an toàn và dễ kiểm soát hơn.

OAuth 2.0 thường được dùng để triển khai Authorization (ủy quyền), tức xác định ứng dụng được phép truy cập tài nguyên nào và ở mức độ nào.

>>> Đọc thêm: API Authentication là gì?

Các giai đoạn phát triển của OAuth 

OAuth được phát triển nhằm giải quyết bài toán cho phép ứng dụng bên thứ ba truy cập tài nguyên của người dùng mà không cần chia sẻ trực tiếp thông tin đăng nhập. Trải qua nhiều lần cải tiến, tiêu chuẩn này ngày càng được hoàn thiện để đáp ứng yêu cầu về bảo mật, khả năng mở rộng và tích hợp với các hệ thống hiện đại.

• OAuth 1.0 (2007): Phiên bản đầu tiên tập trung vào việc bảo vệ thông tin đăng nhập bằng cơ chế chữ ký số (signature) cho mỗi yêu cầu. Mặc dù có độ bảo mật cao, OAuth 1.0 khá phức tạp trong quá trình triển khai và yêu cầu nhiều bước cấu hình.
• OAuth 2.0 (chuẩn hóa năm 2012): Được thiết kế lại nhằm đơn giản hóa việc triển khai và mở rộng khả năng ứng dụng trên web, thiết bị di động và API. Thay vì sử dụng chữ ký số cho mỗi yêu cầu, OAuth 2.0 sử dụng Access Token để cấp quyền truy cập và có thể phát hành Refresh Token nhằm gia hạn quyền truy cập khi cần. Đồng thời, framework này cung cấp nhiều luồng ủy quyền (OAuth Flow) phù hợp với từng loại ứng dụng.
• OAuth 2.1: Đây là phiên bản đang được hoàn thiện, kế thừa OAuth 2.0 và tích hợp các thực hành bảo mật tốt nhất. OAuth 2.1 loại bỏ một số luồng đã lỗi thời như Implicit Flow và Resource Owner Password Credentials (ROPC) Flow, đồng thời khuyến nghị sử dụng Authorization Code Flow kết hợp PKCE để tăng cường bảo mật cho các ứng dụng hiện đại.

Các thành phần chính trong OAuth 2.0 hiện nay

Để triển khai cơ chế ủy quyền, OAuth 2.0 định nghĩa bốn thành phần chính. Mỗi thành phần đảm nhận một vai trò riêng trong quá trình cấp quyền và truy cập tài nguyên.

• Resource Owner (Chủ sở hữu tài nguyên): Là cá nhân hoặc tổ chức sở hữu dữ liệu và có quyền quyết định cấp hoặc từ chối quyền truy cập cho ứng dụng.
• Client (Ứng dụng khách): Là ứng dụng hoặc dịch vụ muốn truy cập tài nguyên của người dùng sau khi được cấp quyền. Client có thể là ứng dụng web, ứng dụng di động, ứng dụng desktop hoặc hệ thống của bên thứ ba.
• Authorization Server (Máy chủ ủy quyền): Chịu trách nhiệm xác thực người dùng (khi cần), xử lý việc cấp quyền và phát hành Access Token (hoặc Refresh Token nếu được hỗ trợ) cho Client.
• Resource Server (Máy chủ tài nguyên): Là nơi lưu trữ dữ liệu hoặc cung cấp API mà Client muốn truy cập. Resource Server sẽ kiểm tra tính hợp lệ và phạm vi quyền (scope) của Access Token trước khi cho phép truy cập tài nguyên hoặc trả về dữ liệu tương ứng.

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

OAuth 2.0 cho phép một ứng dụng truy cập tài nguyên của người dùng thông qua cơ chế cấp quyền bằng token, thay vì yêu cầu ứng dụng trực tiếp lưu hoặc sử dụng mật khẩu.

• Bước 1: Người dùng chọn đăng nhập hoặc cho phép ứng dụng truy cập một số dữ liệu nhất định.
• Bước 2: Ứng dụng chuyển yêu cầu đến Authorization Server để người dùng xác thực và xác nhận quyền truy cập.
• Bước 3: Sau khi được chấp thuận, ứng dụng nhận authorization code và dùng mã này để xin access token.
• Bước 4: Ứng dụng gửi access token đến Resource Server để yêu cầu dữ liệu.
• Bước 5: Resource Server kiểm tra token và trả dữ liệu nếu token còn hiệu lực và đúng phạm vi được cấp.

Có thể hình dung luồng chính như sau:

Người dùng → Ứng dụng → Authorization Server → Resource Server

Cách triển khai này giúp tách biệt thông tin đăng nhập và quyền truy cập tài nguyên, từ đó hạn chế việc chia sẻ mật khẩu trực tiếp cho ứng dụng bên thứ ba.

Những ứng dụng của OAuth 2.0 trong thực tế

OAuth 2.0 được sử dụng rộng rãi trong các hệ thống web, mobile và API nhằm cấp quyền truy cập tài nguyên mà không cần chia sẻ trực tiếp mật khẩu người dùng. Một số ứng dụng phổ biến gồm:

• Đăng nhập qua tài khoản bên thứ ba: Hỗ trợ người dùng truy cập ứng dụng bằng tài khoản Google, Facebook hoặc các nền tảng khác; trong thực tế thường kết hợp thêm OpenID Connect để xác thực danh tính.
• Cấp quyền truy cập dữ liệu: Cho phép ứng dụng chỉ sử dụng những tài nguyên nằm trong phạm vi người dùng đã đồng ý, chẳng hạn danh bạ, lịch hoặc tệp.
• Kết nối dịch vụ và API: Hỗ trợ các hệ thống trao đổi dữ liệu thông qua access token thay vì truyền trực tiếp thông tin đăng nhập.
• Ứng dụng đa nền tảng: Phù hợp với website, ứng dụng di động, phần mềm desktop và các dịch vụ hoạt động trên môi trường cloud.
• Kiểm soát quyền của ứng dụng bên thứ ba: Người dùng hoặc hệ thống có thể giới hạn phạm vi truy cập và thu hồi quyền khi không còn cần thiết.
• Tích hợp hệ sinh thái số: Giúp nhiều ứng dụng, nền tảng và dịch vụ kết nối với nhau theo cơ chế cấp quyền thống nhất, thuận tiện hơn cho việc mở rộng hệ thống.

OAuth 2.0 và OAuth 2.1 khác nhau như thế nào?

OAuth 2.1 được phát triển theo hướng đơn giản hóa cách triển khai OAuth và tăng mức độ an toàn mặc định. So với OAuth 2.0, phiên bản này loại bỏ một số flow cũ, đồng thời đưa các biện pháp bảo mật hiện đại vào quy trình tiêu chuẩn.

Giải đáp các câu hỏi thường gặp về OAuth 2.0

OAuth 2.0 có an toàn không?

Có. OAuth 2.0 là framework ủy quyền an toàn khi được triển khai đúng cách. Để giảm thiểu rủi ro, doanh nghiệp nên sử dụng Authorization Code Flow with PKCE, truyền token qua HTTPS, giới hạn Scope phù hợp và bảo vệ Access Token, Refresh Token khỏi nguy cơ bị rò rỉ hoặc đánh cắp. 

Khi nào nên sử dụng OAuth 2.0?

OAuth 2.0 nên được sử dụng khi ứng dụng cần truy cập API hoặc tài nguyên trên một hệ thống khác thay mặt người dùng mà không cần chia sẻ thông tin đăng nhập. Framework này đặc biệt phù hợp khi tích hợp dịch vụ bên thứ ba, bảo vệ API, triển khai SSO hoặc kết nối giữa các hệ thống và ứng dụng.

OAuth 2.0 có thay thế JWT không?

Không. OAuth 2.0 và JWT phục vụ các mục đích khác nhau. OAuth 2.0 là framework ủy quyền (authorization), còn JWT là định dạng token dùng để truyền thông tin một cách an toàn. Trong thực tế, Access Token của OAuth 2.0 có thể được phát hành dưới dạng JWT, nhưng cũng có thể sử dụng các định dạng khác.

OAuth 2.0 có bắt buộc phải sử dụng OpenID Connect không?

Không. OAuth 2.0 không bắt buộc phải sử dụng OpenID Connect (OIDC). Nếu chỉ cần ủy quyền truy cập tài nguyên hoặc API, OAuth 2.0 là đủ. OIDC chỉ được sử dụng khi ứng dụng cần xác thực người dùng và lấy thông tin danh tính dựa trên OAuth 2.0.

Kết luận

OAuth 2.0 là framework ủy quyền giúp kiểm soát quyền truy cập vào API và tài nguyên giữa các ứng dụng một cách an toàn mà không cần chia sẻ thông tin đăng nhập. Việc lựa chọn OAuth Flow phù hợp, kết hợp PKCE, HTTPS, quản lý Scope và bảo vệ token sẽ giúp giảm thiểu rủi ro khi tích hợp dữ liệu giữa các hệ thống.

Trong quá trình triển khai chatbot AI, AI Agent hoặc các giải pháp AI doanh nghiệp, việc tích hợp an toàn với API, CRM, ERP và các hệ thống nội bộ là yếu tố quan trọng. FPT.AI hỗ trợ doanh nghiệp xây dựng và triển khai các giải pháp AI có khả năng kết nối linh hoạt với hạ tầng hiện có, đáp ứng yêu cầu về bảo mật và vận hành. Liên hệ FPT.AI để được tư vấn giải pháp phù hợp với nhu cầu của doanh nghiệp qua hotline 1900 638 399.