OAuth là gì và Tại sao nên sử dụng nó

Bạn đang thiết kế một ứng dụng, service hoặc API và bạn tự hỏi nên làm gì để hỗ trợ xác thực người dùng. Ngày nay, chúng ta với tư cách là các nhà phát triển luôn cảnh giác khi bảo vệ các nền tảng và ứng dụng của mình. Sẽ không qua khó khăn nếu chỉ cần kiểm tra username và mật khẩu, tuy nhiên bạn cũng cần xác định những tính năng mà người dùng được phép truy cập tùy vào cấp độ của họ. Vậy thì bạn có thể cần quan tâm đến 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ủ. 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.

Cần hiểu rõ sự khác biệt giữa authenticationauthorization 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à 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. Ngoài ra, 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. 😂😂 OAuth 2.0 rõ ràng được xây dựng dựa trên những vấn đề gặp phải với 1.0.

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.

Diving in Deeper

OAuth bao gồm bốn vai trò khác nhau:

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ựcauthorization 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.

The Password Anti-Pattern

Vậy thì OAuth chắc chắn là một giải pháp thú vị. Hãy để hiểu thêm một chút về lý do tại sao sử dụng giao thức ủy quyền như OAuth lại quan trọng.

Như chúng ta đã thảo luận ở trên, Internet rất lớn và ngày càng mở rộng. Chúng ta sử dụng các dịch vụ và nền tảng hàng ngày. Và chúng ta cần được hỗ trợ cung cấp quyền truy cập giữa một số dịch vụ và nền tảng này để có thể kết nối và chuyển thông tin một cách an toàn giữa chúng. Với sự ra đời của API và SDK, việc phát triển các ứng dụng sẽ mở rộng nhanh chóng không chỉ trên web mà cả trên thiết bị di động và máy tính để bàn. Mặc dù các API này thực sự có giá trị và thuận tiện (đôi khi), nhưng nó có vẻ khó khăn trong việc cung cấp sự tương tác các dịch vụ này theo cách bảo vệ an ninh của người dùng. Các dịch vụ HTTP truyền thống sử dụng HTTP Basic Auth hoặc các quy trình ủy quyền liên quan đến phiên đăng nhập khác, nhưng chúng thường yêu cầu chuyển thông tin đăng nhập của bạn thông qua bên thứ 3 thay vì trực tiếp đến máy chủ authentication/resource. Dịch Services/APIs thường yêu cầu xác thực và ủy quyền cho các tính năng nhạy cảm hoặc dành riêng cho người dùng. Mặc dù xác thực dựa trên việc đăng nhập này rất dễ dàng, nhưng nó gây ra những lo ngại bảo mật nghiêm trọng.

Một trong những mối quan tâm bảo mật lớn nhất trong xác thực đơn giản với username/password là người dùng có thể bị thu hồi quyền truy cập hoặc các quyền khác từ ứng dụng bên thứ 3 một cách dễ dàng. Người dùng chỉ có một tùy chọn duy nhất: đặt lại mật khẩu của họ. Ngoài ra, nếu tìm thấy lỗ hổng hoặc lỗi bảo mật trong ứng dụng của bên thứ 3 và được biết đến, các nhà phát triển của nền tảng hoặc dịch vụ như Twitter có thể (tạm thời) tạm dừng/thu hồi/ vô hiệu hóa ứng dụng bên thứ 3 (OAuth Client) để bảo vệ tất cả người dùng của họ, những người có thể đang sử dụng nó cho đến khi bản vá bảo mật được triển khai. Một mối quan tâm bảo mật khác với xác thực đơn giản là thiếu khả năng kiểm soát truy cập vào tài nguyên và thông tin. Không có cách nào để kiểm soát lượng thông tin mà ứng dụng bên thứ 3 được phép truy cập. Nó có thể là tất cả hoặc không gì cả.

Người dùng nên được cung cấp quyền truy cập, 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.

Lời kết

Hy vọng rằng phần giới thiệu thông tin về đặc điểm kỹ thuật và tiêu chuẩn ủy quyền của OAuth đã giúp làm sáng tỏ những động lực đằng sau nó và lý do tại sao bạn nên xem xét sử dụng nó cho dự án tiếp theo của mình.

Tham khảo: https://medium.com/security-operations/what-is-oauth-and-why-should-i-use-it-5aa2f27ce387