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 là một Authorization Framework (framework ủy quyền) cho phép ứng dụng truy cập tài nguyên của người dùng trên hệ thống khác mà không cần chia sẻ thông tin đăng nhập. Thay vì sử dụng tên đăng nhập và mật khẩu, OAuth 2.0 cấp Access Token để ứng dụng chỉ được truy cập trong phạm vi quyền đã được người dùng cho phép, giúp quá trình kết nối giữa các ứng dụng và API an toàn, linh hoạt hơn. 

Nhiều người cũng dễ nhầm lẫn giữa OAuth và Authorization. Thực tế, Authorization là quá trình xác định người dùng hoặc ứng dụng được phép truy cập tài nguyên nào, còn OAuth 2.0 là framework phổ biến để triển khai cơ chế ủy quyền đó. Ví dụ, khi bạn cho phép một ứng dụng truy cập Google Drive, OAuth 2.0 sẽ cấp Access Token để ứng dụng chỉ sử dụng những quyền đã được cho phép mà không cần biết mật khẩu tài khoản.

>>> Tìm hiểu thêm: API 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.
• Xu hướ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 giúp ứng dụng truy cập tài nguyên mà không cần chia sẻ mật khẩu bằng cách sử dụng cơ chế ủy quyền dựa trên token (token-based authorization). Tuy nhiên, mức độ an toàn còn phụ thuộc vào việc lựa chọn OAuth Flow phù hợp và các biện pháp bảo mật đi kèm. Trong Authorization Code Flow – luồng ủy quyền được sử dụng phổ biến nhất hiện nay – quy trình thường diễn ra theo các bước sau:

• Người dùng cấp quyền truy cập cho ứng dụng: Khi muốn sử dụng một tính năng cần truy cập dữ liệu, người dùng sẽ được chuyển đến Authorization Server để đăng nhập và xác nhận cấp quyền cho ứng dụng.
• Authorization Server cấp Authorization Code: Sau khi người dùng đồng ý cấp quyền, Authorization Server sẽ tạo và gửi Authorization Code về cho ứng dụng. Đây là mã ủy quyền tạm thời, được sử dụng để đổi lấy Access Token.
• Ứng dụng đổi Authorization Code lấy Access Token: Client gửi Authorization Code đến Authorization Server để đổi lấy Access Token (và trong một số trường hợp có thể nhận thêm Refresh Token). Access Token cho phép Client truy cập tài nguyên trong phạm vi quyền đã được cấp.
• Client sử dụng Access Token để truy cập API: Sau khi nhận được Access Token, Client sẽ gửi token này trong các yêu cầu (request) đến API hoặc Resource Server để truy cập tài nguyên mà người dùng đã cho phép.
• Resource Server xác minh token và trả dữ liệu: Resource Server kiểm tra tính hợp lệ của Access Token, bao gồm thời hạn sử dụng và phạm vi quyền (scope). Nếu token hợp lệ, hệ thống sẽ xử lý yêu cầu và trả về dữ liệu tương ứng; ngược lại, yêu cầu sẽ bị từ chối.

Các OAuth 2.0 Flow phổ biến

OAuth 2.0 cung cấp nhiều luồng ủy quyền (OAuth Flow) phù hợp với từng loại ứng dụng và môi trường triển khai. Mỗi flow có cơ chế cấp quyền và mức độ bảo mật khác nhau, vì vậy doanh nghiệp cần lựa chọn flow phù hợp để đảm bảo an toàn và tối ưu hiệu quả tích hợp.

Authorization Code Flow

Đây là luồng ủy quyền được sử dụng phổ biến nhất cho các ứng dụng web có backend hoặc các ứng dụng có khả năng bảo mật thông tin xác thực của Client. Sau khi người dùng cấp quyền, Client sử dụng Authorization Code để đổi lấy Access Token, giúp tăng cường bảo mật vì Access Token không được trả trực tiếp qua trình duyệt.

Authorization Code Flow with PKCE

Đây là phiên bản mở rộng của Authorization Code Flow, được thiết kế ban đầu cho ứng dụng di động, desktop và Single Page Application (SPA). PKCE bổ sung cơ chế Code Verifier và Code Challenge để giảm nguy cơ đánh cắp Authorization Code. Hiện nay, PKCE được khuyến nghị sử dụng rộng rãi cùng Authorization Code Flow nhằm tăng cường bảo mật cho các ứng dụng hiện đại. 

Client Credentials Flow

Flow này được sử dụng khi ứng dụng cần truy cập API hoặc tài nguyên thuộc sở hữu của chính ứng dụng hoặc tổ chức mà không có sự tham gia của người dùng. Client Credentials Flow thường được áp dụng trong giao tiếp giữa các dịch vụ (Machine-to-Machine) hoặc kiến trúc Microservices.

Device Authorization Flow

Flow này phù hợp với các thiết bị có khả năng nhập liệu hạn chế như Smart TV, thiết bị IoT hoặc máy chơi game. Người dùng sẽ xác thực và cấp quyền trên một thiết bị khác, sau đó thiết bị ban đầu sẽ nhận Access Token để tiếp tục sử dụng dịch vụ.

Refresh Token Flow

Refresh Token Flow mà là cơ chế cho phép Client yêu cầu cấp Access Token mới khi Access Token hiện tại hết hạn mà không cần người dùng đăng nhập lại. Cơ chế này giúp duy trì phiên làm việc liên tục và thường được sử dụng cùng Authorization Code Flow hoặc Authorization Code Flow with PKCE.

Implicit Flow

Implicit Flow trước đây được sử dụng cho các ứng dụng chạy trên trình duyệt (browser-based application). Tuy nhiên, flow này hiện không còn được khuyến nghị vì Access Token có thể bị lộ trong quá trình truyền hoặc lưu trữ trên môi trường trình duyệt.

Lưu ý: Theo các khuyến nghị bảo mật mới và định hướng của OAuth 2.1, Implicit Flow không còn được khuyến nghị sử dụng do tồn tại nhiều rủi ro trong quá trình cấp phát và lưu trữ Access Token. Thay vào đó, Authorization Code Flow with PKCE là lựa chọn an toàn và phù hợp hơn.

Resource Owner Password Credentials Flow

Resource Owner Password Credentials (ROPC) Flow yêu cầu người dùng cung cấp trực tiếp tên đăng nhập và mật khẩu cho ứng dụng để đổi lấy Access Token. Cách tiếp cận này khiến ứng dụng phải xử lý thông tin đăng nhập của người dùng, làm tăng nguy cơ mất an toàn bảo mật.

Lưu ý: Do tiềm ẩn nhiều rủi ro bảo mật, ROPC Flow không còn được khuyến nghị trong OAuth 2.1. Thay vào đó, doanh nghiệp nên ưu tiên sử dụng Authorization Code Flow hoặc Authorization Code Flow with PKCE.

Những token và khái niệm liên quan trong OAuth 2.0

Trong OAuth 2.0, token đóng vai trò là “chìa khóa” cho phép ứng dụng truy cập tài nguyên của người dùng mà không cần sử dụng trực tiếp thông tin đăng nhập. Tùy vào mục đích sử dụng, hệ thống sẽ phát hành các loại token khác nhau để đảm bảo cả tính bảo mật và trải nghiệm người dùng.

Access Token

Access Token là token được cấp sau khi người dùng hoàn tất quá trình cấp quyền. Client sử dụng token này để truy cập Resource Server hoặc API trong phạm vi quyền (Scope) và thời gian hiệu lực đã được cấp. Vì cho phép truy cập trực tiếp vào tài nguyên, Access Token cần được bảo vệ và chỉ truyền qua kết nối HTTPS.

Refresh Token

Refresh Token giúp Client lấy Access Token mới khi token hiện tại hết hạn mà không yêu cầu người dùng đăng nhập lại. Cơ chế này giúp duy trì phiên làm việc liên tục, đồng thời vẫn đảm bảo tính bảo mật của hệ thống.

Bearer Token

Bearer Token là token type được sử dụng phổ biến nhất trong OAuth 2.0. Phần lớn Access Token hiện nay được phát hành dưới dạng Bearer Token. Khi gửi yêu cầu đến API, Client sẽ đính kèm token trong tiêu đề HTTP theo định dạng Authorization: Bearer <token>. Vì bất kỳ ai sở hữu token hợp lệ đều có thể sử dụng nó, Bearer Token cần được bảo vệ khỏi nguy cơ rò rỉ hoặc đánh cắp.

Token Expiration

Token Expiration là thời gian hiệu lực của Access Token. Khi token hết hạn, Client sẽ sử dụng Refresh Token (nếu có) để lấy Access Token mới. Việc giới hạn thời gian hiệu lực giúp giảm thiểu rủi ro khi token bị lộ và tăng cường bảo mật cho hệ thống.

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

Nhờ khả năng kiểm soát quyền truy cập an toàn, OAuth 2.0 được ứng dụng rộng rãi trong các hệ thống web, ứng dụng di động, nền tảng đám mây và dịch vụ API. Dưới đây là những ứng dụng phổ biến của OAuth 2.0:

• Đăng nhập một lần (Single Sign-On – SSO): Trong các hệ thống SSO hoặc đăng nhập liên kết (Social Login), OAuth 2.0 thường được kết hợp với OpenID Connect (OIDC) để vừa xác thực người dùng vừa cấp quyền truy cập an toàn.
• Bảo vệ API giữa các ứng dụng: Sử dụng Access Token để cấp quyền truy cập API thay cho thông tin đăng nhập, giúp tăng cường bảo mật khi trao đổi dữ liệu.
• Bảo mật ứng dụng Web và Mobile: Hỗ trợ quản lý quyền truy cập an toàn, đồng thời áp dụng các cơ chế bảo mật hiện đại như Authorization Code Flow with PKCE cho ứng dụng di động và Single Page Application (SPA).
• Ủy quyền truy cập trong hệ thống Microservices: Giúp các dịch vụ sử dụng Access Token để kiểm soát quyền truy cập, đảm bảo chỉ những dịch vụ được cấp quyền mới có thể truy cập tài nguyên.
• Kết nối các nền tảng SaaS và dịch vụ bên thứ ba: Hỗ trợ tích hợp CRM, ERP, hệ thống thanh toán, nền tảng lưu trữ đám mây và nhiều dịch vụ SaaS khác thông qua cơ chế cấp quyền an toàn.

Trong các hệ thống AI Agent hoặc chatbot doanh nghiệp có tích hợp API bên thứ ba, OAuth 2.0 giúp quản lý quyền truy cập tài nguyên và dữ liệu an toàn mà không cần chia sẻ thông tin đăng nhập. Các giải pháp AI của FPT.AI hỗ trợ kết nối với hệ thống nội bộ và dịch vụ bên ngoài thông qua các cơ chế tích hợp phù hợp, giúp doanh nghiệp triển khai AI và tự động hóa quy trình hiệu quả. Liên hệ hotline 1900 638 399 để được đội ngũ chuyên gia FPT.AI tư vấn giải pháp phù hợp ngay hôm nay.

Phân biệt OAuth 2.0, Authentication và OpenID Connect

OAuth 2.0, Authentication và OpenID Connect (OIDC) là những khái niệm thường xuất hiện cùng nhau trong các hệ thống quản lý danh tính và quyền truy cập. Tuy nhiên, mỗi khái niệm có mục đích và chức năng khác nhau, cụ thể:

Cần lưu ý gì khi triển khai OAuth 2.0?

Để phát huy tối đa hiệu quả của OAuth 2.0, doanh nghiệp cần áp dụng các thực hành bảo mật phù hợp trong quá trình triển khai. Dưới đây là một số lưu ý quan trọng giúp giảm thiểu rủi ro và bảo vệ hệ thống trước các mối đe dọa bảo mật.

• Ưu tiên sử dụng Authorization Code Flow with PKCE: Đây là phương pháp được khuyến nghị khi triển khai Authorization Code Flow trên các ứng dụng hiện đại. PKCE giúp ngăn chặn nguy cơ đánh cắp Authorization Code và tăng cường bảo mật trong quá trình trao đổi token.
• Luôn truyền token qua HTTPS: Access Token và Refresh Token phải được truyền qua kết nối HTTPS để đảm bảo dữ liệu được mã hóa, giảm nguy cơ bị nghe lén hoặc đánh cắp trong quá trình truyền tải.
• Quản lý Scope phù hợp: Chỉ cấp các quyền (Scope) cần thiết cho ứng dụng thay vì cấp quyền truy cập quá rộng. Nguyên tắc Least Privilege giúp giảm thiểu tác động nếu token bị lộ hoặc bị sử dụng trái phép.
• Thiết lập thời gian hết hạn và cơ chế làm mới token: Access Token nên có thời gian hiệu lực ngắn để hạn chế rủi ro khi bị lộ. Đối với các flow hỗ trợ Refresh Token, nên sử dụng cơ chế này để yêu cầu cấp Access Token mới mà không cần người dùng đăng nhập lại.
• Bảo vệ Access Token và Refresh Token: Không lưu trữ token trong mã nguồn hoặc các vị trí dễ bị truy cập. Doanh nghiệp cần áp dụng các biện pháp lưu trữ an toàn, thu hồi token khi cần thiết và theo dõi các hoạt động bất thường nhằm giảm thiểu nguy cơ lạm dụng quyền truy cập.

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.