Cấu trúc khung ủy quyền OAuth 2.0 - 79king1

Ngày 10 tháng 2 năm 2020 - Công nghệ thông tin

OAuth 2.0 là một khung công tác cho phép ủy quyền linh hoạt và an toàn hơn trong việc truy cập tài nguyên từ các ứng dụng bên thứ ba.

Ví dụ, nếu một ứng dụng bên thứ ba muốn truy cập vào các tài nguyên của bạn trên một trang web nào đó, thay vì cung cấp tên đăng nhập và mật khẩu trực tiếp, bạn có thể sử dụng quy trình ủy quyền OAuth 2.0. Trong trường hợp này, trang web sẽ phát hành một mã token truy cập sau khi bạn đã đồng ý cho phép ứng dụng này truy cập vào tài nguyên của mình. Điều này giúp giảm thiểu rủi ro khi phải chia sẻ mật khẩu với các ứng dụng bên thứ ba, đồng thời cho phép kiểm soát chi tiết hơn về phạm vi truy cập cũng như thời gian hiệu lực của token.

Một ví dụ phổ biến về việc sử dụng OAuth 2.0 là khi bạn đăng nhập vào trang CSDN bằng tài khoản GitHub của mình. Ở đây, trang CSDN (ứng dụng bên thứ ba) muốn sử dụng khả năng xác thực từ GitHub để lấy một số thông tin cơ bản như ảnh đại diện hay tên người dùng của bạn, qua đó cho phép bạn đăng nhập nhanh chóng mà không cần nhập mật khẩu riêng lẻ.

Các vai trò chính trong khung OAuth 2.0:

Chủ sở hữu tài nguyên (Resource Owner): Đây là cá nhân hoặc hệ thống có thẩm quyền quyết định việc truy cập vào các tài nguyên được bảo vệ. Nếu chủ sở hữu tài nguyên là con người, thì đó chính là người dùng cuối cùng.
Máy chủ tài nguyên (Resource Server): Là hệ thống cung cấp các tài nguyên được bảo vệ, nhận yêu cầu kèm theo token truy cập và phản hồi dựa trên tính hợp lệ của token đó.
Khách hàng (Client): Là ứng dụng đại diện cho chủ sở hữu tài nguyên để gửi yêu cầu truy cập đến tài nguyên. Khách hàng có thể chạy trên máy tính bàn, máy chủ hoặc các thiết bị khác.
Máy chủ ủy quyền (Authorization Server): Sau khi xác thực thành công chủ sở hữu tài nguyên và nhận được sự chấp thuận của họ, máy chủ ủy quyền sẽ phát hành token truy cập cho khách hàng.

Máy chủ ủy quyền và máy chủ tài nguyên có thể là cùng một dịch vụ hoặc tách biệt thành hai dịch vụ khác nhau. Một máy chủ ủy quyền có thể phát hành token cho nhiều máy chủ tài nguyên khác nhau.

Như hình minh họa dưới đây, quy trình ủy quyền cơ bản của OAuth 2.0 diễn ra như sau:

![Hình 1: Quy trình ủy quyền cơ bản của OAuth 2.0]

(A) Khách hàng yêu cầu sự chấp thuận từ chủ sở hữu tài nguyên. Yêu cầu này có thể được gửi trực tiếp tới chủ sở hữu tài nguyên nhưng tốt nhất nên đi qua máy chủ 79king1 ủy quyền làm trung gian.

(B) Khách hàng nhận được sự chấp thuận từ chủ sở hữu tài nguyên. Loại sự chấp thuận này phụ thuộc vào phương thức yêu cầu của khách hàng và loại mà máy chủ ủy quyền hỗ trợ.

(D) Máy chủ ủy quyền xác thực khách hàng, bao gồm việc xác minh danh tính của khách hàng và kiểm tra tính hợp lệ của sự chấp thuận từ chủ sở hữu tài nguyên. Nếu tất cả đều đúng, máy chủ sẽ phát hành token truy cập.

(E) Khách hàng sử dụng token truy cập để yêu cầu truy ibet1668 game cập vào tài nguyên được bảo vệ trên máy chủ tài nguyên.

(F) Máy chủ tài nguyên kiểm tra token truy cập và cung cấp dịch vụ nếu token còn hợp lệ.

Về sự chấp thuận:

Sự chấp thuận là bằng chứng cho thấy chủ sở hữu tài nguyên đã đồng ý cho phép khách hàng truy cập vào tài nguyên được bảo vệ của họ. Đây cũng là nền tảng để khách hàng có thể đổi lấy token truy cập.

OAuth 2.0 định nghĩa bốn loại sự chấp thuận chính:

Mã ủy quyền (Authorization Code): Phương thức này sử dụng máy chủ ủy quyền làm trung gian giữa khách hàng và chủ sở hữu tài nguyên, tránh việc khách hàng trực tiếp yêu cầu sự chấp thuận từ chủ sở hữu tài nguyên. Mã ủy quyền sau đó sẽ được đổi lấy token truy cập.
Ủy quyền ngầm (Implicit): Đây là phiên bản đơn giản hóa của phương thức mã ủy quyền, thường được sử dụng cho các ứng dụng JavaScript chạy trên trình duyệt. Thay vì cấp mã ủy quyền, máy chủ ủy quyền sẽ trực tiếp phát hành token truy cập cho khách hàng. Tuy nhiên, cách này ít an toàn hơn do token có thể bị lộ ra ngoài.
Bằng chứng mật khẩu của chủ sở hữu tài nguyên (Resource Owner Password Credentials): Chủ sở hữu tài nguyên có thể cung cấp trực tiếp tên đăng nhập và mật khẩu để đổi lấy token truy cập. Phương thức này chỉ nên được sử dụng khi chủ sở hữu tài nguyên hoàn toàn tin tưởng vào khách hàng và không có lựa chọn nào khác phù hợp hơn.
Bằng chứng của khách hàng (Client Credentials): Được sử dụng khi phạm vi ủy quyền chỉ giới hạn trong các tài nguyên được bảo vệ bởi khách hàng hoặc khi tài nguyên đã được ủy quyền trước đó bởi máy chủ ủy quyền.

Token truy cập:

Token truy cập là chứng thư cho phép truy cập vào tài nguyên được bảo vệ. Nó là minh chứng cho phạm vi truy cập cũng như khoảng thời gian truy cập. Token truy cập có thể là một chuỗi ID đơn giản hoặc chứa thông tin xác thực tự động bên trong.

Token cập nhật:

Token cập nhật được sử dụng để đổi lấy token truy cập mới khi token hiện tại hết hạn. Khác với token truy cập, token cập nhật chỉ được gửi tới máy chủ ủy quyền và không tương tác trực tiếp với máy chủ tài nguyên.

Quy trình sử dụng token cập nhật được minh họa rõ ràng qua hình vẽ dưới đây:

![Hình 2: Cập nhật token truy cập đã hết hạn]

(A) Khách hàng gửi yêu cầu token truy cập kèm theo sự chấp thuận tới máy chủ ủy quyền.

(B) Máy chủ ủy quyền xác thực khách hàng và sự chấp thuận. Nếu mọi thứ đều hợp lệ, máy chủ sẽ phát hành cả token truy cập và token cập nhật.

(D) Máy chủ tài nguyên kiểm tra token truy cập và cung cấp dịch vụ nếu token vẫn còn hiệu lực.

(E) Lặp lại bước (C) và (D) cho đến khi token truy cập hết hạn. Nếu khách hàng biết rằng token đã hết hạn, hãy chuyển sang bước (G).

(F) Do token truy cập đã hết hạn, máy chủ tài nguyên sẽ trả về lỗi “token truy cập không hợp lệ”.

(G) Khách hàng gửi yêu cầu mới với token cập nhật tới máy chủ ủy quyền.

(H) Máy chủ ủy quyền xác thực khách hàng và token cập nhật. Nếu mọi thứ đều hợp lệ, máy chủ sẽ phát hành token truy cập và token cập nhật mới.