Để giới thiệu và mô tả một cách chi tiết và đầy đủ, khung ủy quyền sẽ được chia làm 2 phần xuyên suốt tiến trình từ cội nguồn phát triển đến chi tiết các cấu thành. Các phần của khung này được viết theo tài liệu theo dõi tiêu chuẩn Internet đã được đánh mã số tiêu chuẩn quốc tế (ISSN) 2070 - 1721 và được công bố vào tháng 10 năm 2012. Đặc điểm kĩ thuật này được nghiên cứu và hoàn thiện chỉnh sửa thay thế cho giao thức OAuth 1.0.

Đặc tả khung kết nối ủy quyền OAuth 2.0 là văn bản hướng dẫn và xác định vai trò cũng như các bước trong quá trình chứng thực mà khung đã xây dựng. Đây cũng là văn bản làm căn cứ để xây dựng nhiều khung, giao thức và các triển khai công nghệ quan trọng hiện tại như OpenID 1.0.

Lịch sử phát triển

Về cơ bản, OAuth là một phương thức mà từ một phía máy chủ hay một bên thứ 3 có thể đại diện cho người dùng khai báo cũng như chứng thực người dùng để truy cập vào tài nguyên người dùng nằm trong một dịch vụ của một ứng dụng nào đó. OAuth cũng phát triển đồng hành với sự phát triển của các dịch vụ mạng xã hội như Facebook, Twitter, Instagram. Đặc biệt là khi các công ty như Twitter cung cấp API để bên thứ 3 có thể truy cập vào tài nguyên của người dùng, một thị trường đầy tiềm năng và mới mẻ mới đã mở ra. Đó là thị trường ứng dụng chia sẻ từ bên thứ 3.

Năm 2006 đón nhận sự xuất hiện của OAuth khi mà Twitter phát triển hệ thống OpenID của họ. Để thuận tiện cho việc chia sẻ một lượng lớn người dùng của các gã khổng lồ thời điểm bấy giờ bao gồm Facebook và Google, Twitter đã đề xuất một “chuẩn” nhằm hỗ trợ cho ứng dụng của các bên thứ 3 có thể truy cập vào API của họ một cách thuận tiện dễ dàng nhất. Đến năm 2008, sự bùng nổ của các ứng dụng mạng xã hội đã được khẳng định và là nền tảng cho nhiều sự phát triển sau này, tổ chức chuyên ra các tiêu chuẩn của Internet (IETF) đã hỗ trợ xây dựng cho “chuẩn” kể trên với mục tiêu đưa ra một quy chuẩn thống nhất toàn cầu. Sau 2 năm xây dựng, bản RFC (Văn bản ghi nhớ về đổi mới trong ứng dụng cho công nghệ Internet) chính thức đầu tiên của OAuth ra đời mang tên giao thức OAuth 1.0.

Sau một thời gian được hiện hành trên Internet, các hacker đã tìm ra lỗ hổng bảo mật khá nghiêm trọng xảy ra trên OAuth 1.0, đó là tấn công “session fixation”. Tấn công “session fixation” là lợi dụng việc xử lý session ID không an toàn giữa ứng dụng và trình duyệt giao tiếp thiếu tính bảo mật. Lỗi này gây ra một “trick” khiến cho ứng dụng thuộc bên thứ 3 trao cho hacker quyền truy cập vào tài nguyên người dùng chẳng hạn như thông tin cá nhân, các thông tin đăng tải trên mạng xã hội, ảnh và các thông tin ngân hàng hay ghi nợ đi kèm. Điều này dẫn đến việc hàng loạt tài khoản facebook bị tấn công mà không hề hay biết.

Sự kiện này dẫn đến việc ra đời của OAuth 2.0. Phiên bản đầu tiên được công bố vào tháng 10 năm 2012 và phiên bản tại thời điểm còn tương đối nhiều lỗi bảo mật. Sau một thời gian nâng cấp và cải thiện, khung OAuth 2.0 vẫn được sử dụng rộng rãi dù vẫn còn các khe hở bảo mật. Đến thời điểm hiện tại, OAuth 2.0 không chỉ đơn thuần là một giao thức như thời điểm đầu hình thành mà trở thành một “nền tảng” mà đồng thời triển khai cả phía máy chủ và các bên ứng dụng.

Nội dung chi tiết

1. Một số khái niệm cơ bản cần nắm trong OAuth

Bốn khái niệm sau được OAuth xác định và đưa vào chi tiết trong từng tiến trình của khung khái niệm của mình.

“Resource Owner”: Một thực thể có khả năng cấp quyền truy cập vào tài nguyên được bảo vệ. Thực thể ở đây có thể là một cá nhân, một công ty, hay chủ quản của ứng dụng. Khi chủ sở hữu tài nguyên là một người, nó được gọi là người dùng cuối (end user).

“Resource Sever”: Máy chủ lưu trữ các tài nguyên được bảo vệ cũng đồng thời bảo quản các tài nguyên này, có khả năng chấp nhận và phản hồi các yêu cầu sử dụng hay truy cập vào tài nguyên được bảo vệ bằng cách sử dụng mã thông báo truy cập (token).

“Client”: Một ứng dụng thực hiện các yêu cầu tài nguyên được bảo vệ thay mặt cho chủ sở hữu tài nguyên và với sự cho phép của nó. Thuật ngữ "Client" không ngụ ý bất kỳ đặc điểm triển khai cụ thể nào (ví dụ: cho dù ứng dụng thực thi trên máy chủ, máy tính để bàn hay các thiết bị khác). Hiểu một cách đơn giản, nó là các chương trình, ứng dụng mà mọi người thấy hầu hết trên các trang mạng.

“Authorization Server”: Máy chủ cấp mã thông báo truy cập cho các ứng dụng sau khi xác thực thành công chủ sở hữu tài nguyên cho phép và nhận được ủy quyền đăng nhập từ chủ sở hữu này.

Sự tương tác giữa máy chủ ủy quyền và máy chủ tài nguyên nằm ngoài phạm vi của đặc điểm kỹ thuật OAuth 2.0 này. Máy chủ ủy quyền có thể là cùng một máy chủ với máy chủ tài nguyên hoặc một thực thể riêng biệt. Một máy chủ ủy quyền duy nhất có thể cấp mã thông báo truy cập được chấp nhận bởi nhiều máy chủ tài nguyên.

2. Tổng quan về giao thức làm việc của OAuth

Về cơ bản, tiến trình về giao thức OAuth được mô tả chi tiết theo sơ đồ sau:

Hình 1: Tổng quan giao thức OAuth 2.0

Như sơ đồ trên, tiến trình OAuth được mô tả thông qua bốn khái niệm được nêu ở phần trên và được tổng hợp thành các bước như hình vẽ:

(A) Ứng dụng (client) yêu cầu ủy quyền từ chủ sở hữu tài nguyên. Yêu cầu ủy quyền có thể được thực hiện trực tiếp đến chủ sở hữu tài nguyên (như hình minh họa), hoặc tốt nhất là gián tiếp thông qua máy chủ ủy quyền với tư cách là người trung gian.

(B) Ứng dụng nhận sẽ được quyền cấp phép truy cập dữ liệu, là thông tin xác thực đại diện cho quyền của chủ sở hữu tài nguyên, được thể hiện bằng cách sử dụng một trong bốn loại cấp được xác định trong đặc điểm kỹ thuật khung OAuth 2.0 này hoặc sử dụng loại cấp mở rộng. Loại cấp ủy quyền phụ thuộc vào phương thức được phía ứng dụng sử dụng để yêu cầu ủy quyền và các loại được hỗ trợ bởi máy chủ ủy quyền.

(C) Ứng dụng yêu cầu mã thông báo truy cập bằng cách xác thực với máy chủ ủy quyền và xuất trình khoản cấp phép.

(D) Máy chủ ủy quyền xác thực ứng dụng và xác thực việc cấp ủy quyền, và nếu hợp lệ sẽ cấp mã thông báo truy cập cho ứng dụng.

(E) Ứng dụng yêu cầu tài nguyên được bảo vệ từ máy chủ tài nguyên và xác thực bằng cách xuất trình mã thông báo truy cập.

(F) Máy chủ tài nguyên xác thực mã thông báo truy cập mà ứng dụng cung cấp và nếu hợp lệ, sẽ phục vụ yêu cầu truy cập dữ liệu.

Về cơ bản, sơ đồ mô tải một cách chi tiết và nguyên bản nhất của tiến trình OAuth, tuy nhiên để thuận lợi về việc truy vấn giữa các luồng thông tin và luồng mã bảo mật, sẽ có nhiều sơ đồ thay đổi. Việc này sẽ được mô tả sau.

3. Cấp phép ủy quyền của OAuth vận hành như thế nào

Từ sơ đồ, dễ dàng hiểu được luồng truy vấn và cấp phép sử dụng dữ liệu theo OAuth. Tuy nhiên để hiểu sâu và rõ về OAuth mục này sẽ đi vào chi tiết của tiến trình cấp phép truy cập (Authorization Request & Grant).

“Authorization Grant” là một cấp phép xác thực đại diện cho quyền của chủ sở hữu tài nguyên (để truy cập tài nguyên được bảo vệ), nó phải được phía ứng dụng sử dụng để lấy mã thông báo truy cập.

Để hiểu sâu về cấp phép này thì khung kết nối ủy quyền xác định chi tiết và mạch lạc bốn loại cấp phép (grant) sau đây:

“Authorization Code”: Mã ủy quyền có được bằng cách sử dụng máy chủ ủy quyền làm trung gian giữa ứng dụng và chủ sở hữu tài nguyên. Thay vì yêu cầu ủy quyền trực tiếp từ chủ sở hữu tài nguyên, ứng dụng hướng chủ sở hữu tài nguyên đến máy chủ ủy quyền (thông qua tác nhân người dùng của nó như được định nghĩa trong [RFC2616]), ứng dụng này sẽ chuyển hướng chủ sở hữu tài nguyên trở lại ứng dụng bằng mã ủy quyền.

Trước khi chuyển hướng chủ sở hữu tài nguyên trở lại ứng dụng bằng mã ủy quyền, máy chủ ủy quyền xác thực chủ sở hữu tài nguyên và nhận ủy quyền. Vì chủ sở hữu tài nguyên chỉ xác thực với máy chủ ủy quyền, thông tin đăng nhập của chủ sở hữu tài nguyên không bao giờ được chia sẻ với ứng dụng.

Mã ủy quyền cung cấp một số lợi ích bảo mật quan trọng, chẳng hạn như khả năng xác thực cho ứng dụng, cũng như truyền trực tiếp mã thông báo truy cập đến ứng dụng mà không cần chuyển nó qua tác nhân người dùng của chủ sở hữu tài nguyên và có khả năng để lộ nó cho người khác, bao gồm chủ sở hữu tài nguyên.

Loại cấp phép này thường được sử dụng với các ứng dụng độc lập.

“Implicit grant”: Là một mã sau khi đơn giản hóa mã ủy quyền, thường được dùng cho một số ứng dụng không có hoặc yếu khả năng bảo mật tiến trình cấp phép ủy quyền. Trong quá trình cấp phép này, thay vì tạo ra một “authorization code” thì ứng dụng được nhận trực tiếp mã thông báo truy cập (access token) do ủy quyền của chủ sở hữu tài nguyên. Loại cấp phép này là ẩn vì không có thông tin xác thực trung gian (chẳng hạn như mã ủy quyền) được cấp (và sau đó được sử dụng để lấy mã thông báo truy cập).

Khi phát hành mã thông báo truy cập trong luồng này, máy chủ ủy quyền không xác thực ứng dụng khách. Trong một số trường hợp, danh tính ứng dụng có thể được xác minh thông qua URI chuyển hướng mà được sử dụng để cung cấp mã thông báo truy cập cho ứng dụng. Mã thông báo truy cập có thể được hiển thị cho chủ sở hữu tài nguyên hoặc các ứng dụng khác có quyền truy cập vào tác nhân người dùng của chủ sở hữu tài nguyên.

Loại mã này cải thiện khả năng phản hồi và hiệu quả của một số ứng dụng (chẳng hạn như ứng dụng được triển khai dưới dạng ứng dụng trong trình duyệt). Nó giảm số lượng lượt truy hồi cần thiết trong tiến trình cấp phép. Nhưng cũng vì sự tiện lợi và rút ngắn các bước mà khiến nó mắc nhiều lỗ hổng bảo mật.

Loại cấp phép này thường được sử dụng với các ứng dụng trên thiết bị di dộng của người dùng.

“Resource Owner Password Credential”: là kiểu cấp phép mà thông tin đăng nhập mật khẩu của chủ sở hữu tài nguyên thông tin (tức là tên người dùng và mật khẩu) có thể được sử dụng trực tiếp như một khoản cấp phép để lấy mã thông báo truy cập. Thông tin xác thực chỉ nên được sử dụng khi có mức độ tin cậy cao giữa chủ sở hữu tài nguyên và ứng dụng (ví dụ: ứng dụng là một phần của hệ điều hành thiết bị hoặc ứng dụng có đặc quyền cao) và khi các loại cấp phép khác không khả dụng (chẳng hạn như mã ủy quyền).

Mặc dù loại tài trợ này yêu cầu ứng dụng truy cập trực tiếp vào thông tin đăng nhập của chủ sở hữu tài nguyên, nhưng thông tin đăng nhập của chủ sở hữu tài nguyên được sử dụng cho một yêu cầu duy nhất và được trao đổi để lấy mã thông báo truy cập. Loại tài trợ này có thể loại bỏ nhu cầu ứng dụng phải lưu trữ thông tin đăng nhập của chủ sở hữu tài nguyên để sử dụng trong tương lai, bằng cách trao đổi thông tin đăng nhập với mã thông báo truy cập tồn tại lâu dài hoặc mã thông báo làm mới.

Loại cấp phép này chỉ được sử dụng với các ứng dụng có độ tin cậy cao, có độ bảo mật tuyệt đối.

“Client credential”: là kiểu cấp phép mà thông tin xác thực ứng dụng (hoặc các hình thức xác thực ứng dụng khách khác) có thể được sử dụng như một sự cấp phép khi phạm vi ủy quyền bị giới hạn trong các tài nguyên được bảo vệ dưới sự kiểm soát của ứng dụng hoặc các tài nguyên được bảo vệ đã được sắp xếp trước đó với máy chủ ủy quyền. Thông tin đăng nhập của ứng dụng được sử dụng như một cấp ủy quyền thường khi ứng dụng nhân danh chính mình (ứng dụng cũng là chủ sở hữu tài nguyên) hoặc đang yêu cầu quyền truy cập vào các tài nguyên được bảo vệ dựa trên ủy quyền đã được sắp xếp trước đó với máy chủ ủy quyền.

Loại cấp phép này được sử dụng với các ứng dụng truy cập thông qua API.

4. Mã thông báo truy cập

Mã thông báo truy cập (Access tokens) là thông tin xác thực được sử dụng để truy cập các tài nguyên được bảo vệ. Mã thông báo truy cập là một chuỗi đại diện cho một ủy quyền được cấp cho ứng dụng. Chuỗi thường không rõ ràng đối với khách hàng. Mã thông báo đại diện cho phạm vi và thời lượng truy cập cụ thể, được cấp bởi chủ sở hữu tài nguyên và được thực thi bởi máy chủ tài nguyên và máy chủ ủy quyền.

Hình 2: Vị trí của Mã thông báo truy cập trong chu trình

Mã thông báo có thể biểu thị một số nhận dạng được sử dụng để truy xuất thông tin ủy quyền hoặc có thể tự chứa thông tin ủy quyền theo cách có thể xác minh được (tức là chuỗi mã thông báo bao gồm một số dữ liệu và chữ ký). Các thông tin xác thực bổ sung, nằm ngoài phạm vi của đặc điểm kỹ thuật này, có thể được yêu cầu để khách hàng sử dụng mã thông báo.

Mã thông báo truy cập cung cấp một lớp trừu tượng, thay thế các cấu trúc ủy quyền khác nhau (ví dụ: tên người dùng và mật khẩu) bằng một mã thông báo duy nhất được máy chủ tài nguyên hiểu. Sự trừu tượng này cho phép phát hành mã thông báo truy cập hạn chế hơn so với cấp ủy quyền được sử dụng để lấy chúng, cũng như loại bỏ nhu cầu của máy chủ tài nguyên để hiểu nhiều phương pháp xác thực.

Mã thông báo truy cập có thể có các định dạng, cấu trúc và phương pháp sử dụng khác nhau (ví dụ: thuộc tính mật mã) dựa trên các yêu cầu bảo mật của máy chủ tài nguyên. Thuộc tính mã thông báo truy cập và các phương pháp được sử dụng để truy cập tài nguyên được bảo vệ nằm ngoài phạm vi của đặc điểm kỹ thuật này và được xác định bởi thông số kỹ thuật đồng hành như [RFC6750].

5. Mã thông báo cấp mới mã truy cập

“Refresh tokens” hay mã thông báo cấp mới mã truy cập là một loại mã có tác dụng là cấp thông tin xác thực được sử dụng để lấy một mã thông báo truy cập mới. Máy chủ xác thực cấp phát một mã xác thông báo truy cập cho phía ứng dụng nhưng khi mã này không tồn tại hay đơn giản bị sai sót hoặc hết thời hạn thì cần một mã mới. để cấp phép quá trình này thì cần đến mã thông báo cấp mới mã truy cập.

Về cơ bản, “Refresh token” và “Access token” giống nhau đều là mã thông báo. Tuy nhiên mã thông báo cấp mới truy cập thì chỉ có một nhiệm vụ duy nhất đó là đề xuất lấy một token mới. Mã thông báo này thì được cấp cho người dùng hay phía ứng dụng cùng với mã thông báo truy cập nhưng thời gian tồn tại thì khác nhau. Với mã thông báo xác thực có thể là 1 giờ đồng hồ nhưng mã thông báo cấp mới có khi tồn tại lên tới 10 ngày.

Việc cấp mã thông báo làm mới là tùy chọn theo quyết định của máy chủ ủy quyền. Nếu máy chủ ủy quyền phát hành mã thông báo làm mới, nó sẽ được bao gồm khi phát hành mã thông báo truy cập. Mã thông báo làm mới là một chuỗi đại diện cho ủy quyền được cấp bởi chủ sở hữu tài nguyên. Chuỗi thường không rõ ràng đối với ứng dụng. Mã thông báo này biểu thị một số nhận dạng được sử dụng để truy xuất thông tin ủy quyền. Không giống như mã thông báo truy cập, mã thông báo cấp mới chỉ được sử dụng với máy chủ ủy quyền và không bao giờ được gửi đến máy chủ tài nguyên.

Trong khi các mã thông báo JWT được lưu trữ ở Coockies của trình duyệt, Session, hay bộ nhớ cục bộ thì mã thông báo cấp mới mã truy cập được lưu ở bộ nhớ của ứng dụng vì mã này sẽ không sử dụng cho việc khi ứng dụng yêu cầu trên giao diện và nó chỉ được sử dụng khi một mã thông báo hết hạn. Nó không gây ảnh hưởng đến hiệu suất của bộ nhớ hay liên quan đến các phản hồi của ứng dụng.

Sơ đồ dưới đây mô tả một cách dễ hiểu quá trình sử dụng đối với mã thông báo cấp mới mã truy cập.

Hình 3: Tiến trình của mã thông báo truy cập

6. Giao thức TLS

Giao thức TLS (Transport layer security) giao thức bảo mật tầng giao vận là một giao thức bảo mật được phát triển dựa trên tiêu chuẩn SSL v3.0 (Secure Sokcet Layer). Phiên bản 1.2 trên RFC 5246 là phiên bản mới nhất nhưng có sơ sở triển khai rất hạn chế và có thể không sẵn sàng để triển khai. TLS phiên bản 1.0 [RFC2246] là phiên bản được triển khai rộng rãi nhất và sẽ cung cấp khả năng tương tác rộng nhất.

Giao thức này cũng được xây dựng theo mô hình “ứng dụng – máy chủ” và mục đích chính là cung cấp sự riêng tư và toàn vẹn dữ liệu giữa hai ứng dụng trên không gian mạng. Đây là giao thức bảo mật mà OAuth 2.0 sử dụng, nhưng cũng chính đây là yếu tố gây ra một số lỗ hổng cho kẻ xấu tấn công. Các lô hổng này sẽ được nêu ra trong phần sau.

7. Đăng ký ứng dụng

Trước khi bắt đầu giao thức, các ứng dụng đăng ký với máy chủ ủy quyền. Các phương tiện mà ứng dụng đăng ký với máy chủ ủy quyền nằm ngoài phạm vi của đặc tả này nhưng thường liên quan đến tương tác của người dùng cuối với biểu mẫu đăng ký HTML.

Đăng ký của ứng dụng không yêu cầu tương tác trực tiếp giữa ứng dụng và máy chủ ủy quyền. Khi được hỗ trợ bởi máy chủ ủy quyền, việc đăng ký có thể dựa vào các phương thức khác để thiết lập sự tin cậy và có được các thuộc tính ứng dụng khách cần thiết (ví dụ: URI chuyển hướng, loại ứng dụng khách). Ví dụ: việc đăng ký có thể được thực hiện bằng cách sử dụng xác nhận do bên thứ ba tự cấp hoặc do bên thứ ba cấp hoặc bằng cách máy chủ ủy quyền thực hiện khám phá máy khách bằng kênh đáng tin cậy.

Khi đăng ký một ứng dụng, nhà phát triển của ứng dụng phải tuân theo:

- Chỉ định loại ứng dụng

- Cung cấp các URI chuyển hướng ứng dụng của nó;

- Bao gồm bất kỳ thông tin nào khác được yêu cầu bởi máy chủ ủy quyền (ví dụ: tên ứng dụng, trang web, mô tả, hình ảnh biểu trưng, ​​việc chấp nhận các điều khoản pháp lý).

8. Các loại ứng dụng

OAuth xác định hai loại ứng dụng, dựa trên khả năng xác thực an toàn của chúng với máy chủ ủy quyền (tức là khả năng duy trì tính bảo mật của thông tin đăng nhập ứng dụng của họ):

Việc chỉ định loại ứng dụng dựa trên định nghĩa của máy chủ ủy quyền về xác thực an toàn và mức độ hiển thị thông tin xác thực ứng dụng là có thể chấp nhận được. Tuy nhiên, máy chủ ủy quyền KHÔNG NÊN đưa ra các giả định về loại ứng dụng, hay hiểu đơn giản là ứng dụng khách có thể được triển khai dưới dạng một tập hợp các thành phần phân tán, mỗi thành phần có một loại ứng dụng và ngữ cảnh bảo mật khác nhau (ví dụ: một ứng dụng phân tán có cả thành phần dựa trên máy chủ bí mật và thành phần dựa trên trình duyệt công khai). Nếu máy chủ ủy quyền không cung cấp hỗ trợ cho các ứng dụng đó hoặc không cung cấp hướng dẫn liên quan đến đăng ký của họ, ứng dụng NÊN đăng ký từng thành phần như một ứng dụng hay phần riêng biệt.

Đặc điểm kỹ thuật này đã được thiết kế xung quanh các kiểu ứng dụng mô tả như sau:

9. Các ứng dụng chưa được đăng ký

Khung kết nối ủy quyền không loại trừ việc sử dụng các ứng dụng mà chưa được đăng ký hay định danh với máy chủ ủy quyền. Tuy nhiên điều này đồng nghĩa các ứng dụng này tiềm ẩn nguy cơ tấn công cao và có thể không an toàn cho người dùng.

10. Ứng dụng phát triển riêng cho nền tảng

Ứng dụng “native” là những ứng dụng được cài đặt và thực thi trên thiết bị được chủ sở hữu tài nguyên sử dụng (tức là ứng dụng dành cho máy tính để bàn, ứng dụng dành cho thiết bị di động “native”). Các ứng dụng này yêu cầu xem xét đặc biệt liên quan đến bảo mật, khả năng nền tảng và trải nghiệm người dùng cuối tổng thể.

Điểm cuối ủy quyền yêu cầu tương tác giữa ứng dụng và tài nguyên của phần mềm hoạt động thay cho người dùng. Ứng dụng “native” có thể gọi các phần mềm từ phía bên ngoài nền tảng hoặc tích hợp các phần mềm đại diện cho người dùng truy cập trong ứng dụng. Ví dụ:

- Các phần mềm từ phía bên ngoài có thể nắm bắt phản hồi từ máy chủ ủy quyền bằng cách sử dụng URI chuyển hướng với kế hoạch được đăng ký với hệ điều hành để gọi các ứng dụng làm trình xử lý, sao chép và dán thủ công thông tin đăng nhập, chạy web cục bộ máy chủ, cài đặt tiện ích mở rộng tác nhân người dùng hoặc bằng cách cung cấp URI chuyển hướng xác định tài nguyên do máy chủ lưu trữ dưới sự kiểm soát của ứng dụng, từ đó cung cấp phản hồi cho ứng dụng “native”

- Các phần mềm đại diện được tích hợp với ứng dụng gốc sẽ nhận được phản hồi bằng cách giao tiếp trực tiếp với người dùng bằng cách giám sát các thay đổi trạng thái phát ra trong quá trình tải tài nguyên hoặc truy cập vào bộ lưu trữ cookie của tác nhân người dùng.

Khi lựa chọn giữa tác nhân người dùng bên ngoài hoặc được tích hợp, các nhà phát triển nên cân nhắc những điều sau:

- Các phần mềm từ bên ngoài có thể cải thiện tỷ lệ hoàn thành, vì chủ sở hữu tài nguyên có thể đã có một phiên hoạt động với máy chủ ủy quyền, loại bỏ nhu cầu xác thực lại. Nó cung cấp trải nghiệm và chức năng quen thuộc cho người dùng cuối. Chủ sở hữu tài nguyên cũng có thể dựa vào các tính năng hoặc tiện ích mở rộng của tác nhân người dùng để hỗ trợ xác thực (ví dụ: trình quản lý mật khẩu, trình đọc thiết bị 2 yếu tố).

- Các phần mềm được tích hợp có thể cung cấp khả năng sử dụng tự được cải thiện, vì nó loại bỏ nhu cầu chuyển đổi ngữ cảnh và mở các cửa sổ mới.

- Các phần mềm được tích hợp đặt ra một thách thức bảo mật vì chủ sở hữu tài nguyên đang xác thực trong một cửa sổ không xác định mà không có quyền truy cập vào các biện pháp bảo vệ trực quan được tìm thấy trong hầu hết các phần mềm từ bên ngoài. Các phần mềm được tích hợp hướng dẫn người dùng cuối tin tưởng vào các yêu cầu xác thực không xác định (làm cho các cuộc tấn công lừa đảo dễ thực hiện hơn).

Tạm kết

Như vậy, thông qua bài viết, một góc nhìn tường tận và chi tiết về lịch sử hình thành và những khái niệm cơ bản của khung kết nối ủy quyền OAuth 2.0. Từ các thông tin của phần này, phần sau sẽ đi sâu vào yếu tố bảo mật, một trong những yếu tố quan trọng cũng là yếu điểm của khung kết nối này, đồng thời có hình dung cơ bản trong sự phát triển từ khung kết nối xây dựng sang các tiêu chuẩn mang yếu tố nền tảng khác.

Vũ Cao Minh Đức

Tài liệu tham khảo

1. Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT).

2. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. và T. Berners-Lee, "Hypertext Transfer Protocol - HTTP / 1.1", RFC 2616, June 1999.