OAuth là gì?

Bạn đang thiết kế một ứng dụng, service hoặc API, vậy một trong những vấn đề bạn quan tâm là giao thức authorization (ủy quyền) mà người dùng sẽ tương tác và khả năng "truy cập ủy quyền an toàn" phía máy chủ.

Trước khi vào bài viết chúng ta sẽ bắt đầu bằng cách định nghĩa một vài thuật ngữ:

Authentication (xác thực): quá trình hoặc hành hành động xác minh danh tính của một người dùng hoặc tiến trình. Authorization (ủy quyền): chức năng chỉ định quyền truy cập hoặc đặc quyền đối với tài nguyên. Resource (tài nguyên): một bản ghi, tài liệu, tập tin hoặc thực thể kỹ thuật số khác.

Sự khác biệt giữa authentication và authorization là rất quan trọng.

Authentication chỉ đơn giản là cung cấp một bộ thông tin đăng nhập để máy chủ có thể kiểm tra để xác nhận bạn là người bạn nói và bạn thực sự có thông tin xác thực hợp lệ.

Authorization tuân theo quy trình authentication và đảm bảo sau khi xác định thông tin xác thực của người dùng là chính xác thì có thể xác định và thực thi quyền kiểm soát truy cập và các quyền khác đối với resource được lưu.

OAuth là gì?

OAuth là một token-based authorization framework (khung ủy quyền dựa trên token), được thiết kế đặc biệt để hoạt động với HTTP. Bản thân nó không phải là API, service hay package. OAuth thường được sử dụng bởi các công ty như Google, Facebook, Twitter, Amazon, Microsoft, v.v. như một cách để cho phép người dùng của họ cấp cho các trang web hoặc dịch vụ khác quyền truy cập vào thông tin của họ mà không cần cung cấp mật khẩu.

OAuth cho phép các nhà phát triển bên thứ 3 chỉ định thông tin nào người dùng có thể được yêu cầu chia sẻ để sử dụng dịch vụ và thông tin nào có thể là tùy chọn để chia sẻ. Ví dụ, sau đó người dùng có thể tùy chọn có hay không chia sẻ ngày sinh của họ được liên kết với tài khoản Twitter. Nếu bạn sử dụng bất kỳ trang web hoặc dịch vụ nào trong số này, có lẽ bạn đã thấy một dấu nhắc xác nhận tương tự như những gì tôi đề cập đến.

Có hai phiên bản OAuth: OAuth 1.0a và OAuth 2.0, nhưng những thông số kỹ thuật và cách thực hiện của chúng hoàn toàn khác nhau. May mắn là việc lựa chọn lại rất dễ dàng, OAuth 2.0 là hình thức sử dụng rộng rãi nhất của OAuth.

Dưới đây là ví dụ từ Google:

Trong ảnh chụp màn hình ở trên, bạn có thể thấy hộp thoại xác nhận với Google sau khi được chuyển hướng từ ứng dụng bên thứ 3 (có thể là một số ứng dụng lịch trong trường hợp này) đến các máy chủ của Google, yêu cầu quyền truy cập vào tài khoản Google của người dùng (tên, email , lịch, vv) thay mặt cho người dùng. Sau khi được chuyển hướng đến Google (hoặc bất kỳ máy chủ OAuth nào) nếu bạn chưa đăng nhập, bạn sẽ được nhắc làm như vậy, sau khi chấp nhận quyền truy cập được yêu cầu bạn sẽ được chuyển hướng trở lại ứng dụng của bên thứ 3. Sau đó ứng dụng này có thể truy cập các tài nguyên được phép từ tài khoản Google của bạn bằng cách sử dụng access token.

Vai trò của OAuth

Resource Server: REST API là một ví dụ, một máy chủ HTTP nơi người dùng có thể tạo, sửa đổi hoặc xóa các bản ghi, tài liệu hoặc tệp.

Resource Owner: Duy trì quyền sở hữu tài nguyên mà người dùng đã tạo hoặc sửa đổi trên máy chủ và người ủy quyền cho ứng dụng bên thứ 3 truy cập vào tài khoản của họ. Ứng dụng của bên thứ 3 có quyền truy cập hạn chế vào tài khoản của người dùng, dựa trên phạm vi của phạm vi của ủy quyền được cấp.

Client: Ứng dụng bên thứ 3 muốn truy cập vào tài khoản người dùng. Trước khi nó có thể làm như vậy, máy chủ resource/authorization và chủ sở hữu tài nguyên phải ủy quyền cho yêu cầu đó. Mọi khách hàng phải được đăng ký với máy chủ authorization và sẽ được cung cấp cho nó thông tin xác thực duy nhất của riêng mình (client_id và client_secret) để xác thực riêng.

Authorization Server (thường là giống Resource Server): Đôi khi, bạn có thể muốn rút ra khỏi máy chủ authorization từ máy chủ resource và triển khai nó như một phiên bản chuyên dụng, đặc biệt là trong các môi trường phân tán.

1. Ứng dụng bên thứ 3 yêu cầu ủy quyền từ service và người dùng để truy cập tài nguyên do người dùng sở hữu hoặc có khả năng truy cập.
2. Giả sử người dùng cho phép yêu cầu, ứng dụng bên thứ 3 nhận được một authorization grant (chứng nhận được ủy quyền).
3. Sau khi ứng dụng của bên thứ 3 đã được cấp phép, nó có thể yêu cầu access token từ máy chủ authorization bằng cách xuất trình authorization grant hiện có được cung cấp bởi người dùng, cũng như thông tin xác thực của chính họ với tư cách là client.
4. Nếu ứng dụng của bên thứ 3 có thể xác thực và authorization grant là hợp lệ, máy chủ ủy quyền sẽ tạo một access token duy nhất, được liên kết với quyền authorization grant và chủ sở hữu tài nguyên để sử dụng và xác thực trong tương lai.
5. Bây giờ, ứng dụng có thể yêu cầu tài nguyên từ máy chủ tài nguyên sử dụng access token trong các yêu cầu.
6. Với access token hợp lệ, máy chủ tài nguyên sẽ cung cấp các tài nguyên được bảo vệ, các tài nguyên này hiện đã được người dùng và máy chủ ủy quyền hoàn toàn để truy cập.

Ngoài authorization, có một số loại grant khác có thể được sử dụng tùy thuộc vào các trường hợp sử dụng. Nhìn chung, authorization grant là loại OAuth grant được sử dụng phổ biến nhất, đặc biệt là cho public services và API.

Tại sao sử dụng giao thức ủy quyền như OAuth lại quan trọng.

Người dùng muốn và xứng đáng có khả năng cung cấp quyền truy cập chi tiết, nhưng cũng nên bị thu hồi mọi quyền truy cập trái phép ở tương lai và họ không cần cung cấp mật khẩu của họ. Các nhà phát triển muốn cung cấp khả năng này cho người dùng của họ và cung cấp quyền truy cập vào/từ nhiều nền tảng và dịch vụ web phổ biến khác nhau, nhưng nó trở nên thách thức khi có rất nhiều giao thức xác thực và ủy quyền khác nhau. OAuth mang đến một giải pháp dựa trên tiêu chuẩn cho bảng, điều mà tất cả các nhà phát triển trong cộng đồng có thể và đã xoay quanh. Đây là bước đầu tiên hướng tới một đặc điểm kỹ thuật hợp nhất, được tiêu chuẩn hóa để cấp phép không cần mật khẩu cho các ứng dụng web, máy tính để bàn và thiết bị di động.