OAuth hoạt động như thế nào?

Trình duyệt Tác nhân Scrapeless cung cấp các phiên duyệt web trên đám mây cho việc tương tác với các trang web được ủy quyền, trong khi ứng dụng của bạn vẫn chịu trách nhiệm về các quyền và token OAuth được sử dụng bởi các tích hợp của nó.

OAuth hoạt động như thế nào?

OAuth cho phép một ứng dụng nhận quyền truy cập hạn chế vào một tài nguyên được bảo vệ thông qua một máy chủ ủy quyền, mà không cần yêu cầu ứng dụng thu thập mật khẩu của chủ sở hữu tài nguyên. Ứng dụng nhận một mã thông báo truy cập (access token) đại diện cho một quyền cấp đã được phê duyệt và trình bày mã thông báo đó cho máy chủ tài nguyên. Máy chủ tài nguyên quyết định liệu mã thông báo có ủy quyền cho thao tác được yêu cầu hay không.

OAuth là một khuôn khổ ủy quyền. Một nút đăng nhập quen thuộc có thể liên quan đến OAuth, nhưng việc chứng minh ai đã đăng nhập cần một giao thức định danh và các quy tắc xác thực của nó. Việc tách biệt quyền truy cập và định danh giúp ngăn ứng dụng coi bất kỳ lần trao đổi token thành công nào là bằng chứng đầy đủ về danh tính của người dùng.

Ai tham gia vào một luồng OAuth?

Một luồng OAuth bao gồm chủ sở hữu tài nguyên, máy khách, máy chủ ủy quyền và máy chủ tài nguyên. Chủ sở hữu tài nguyên có thể cấp quyền truy cập. Máy khách là ứng dụng yêu cầu quyền truy cập đó. Máy chủ ủy quyền đánh giá yêu cầu và cấp mã thông báo. Máy chủ tài nguyên lưu trữ dữ liệu hoặc thao tác được bảo vệ.

The Khung ủy quyền OAuth định nghĩa các vai trò này. Một tổ chức đơn lẻ có thể vận hành cả hai vai trò máy chủ, nhưng trách nhiệm vẫn khác nhau. Việc xác thực thành công tại máy chủ ủy quyền không tự động cho phép mọi thao tác tại máy chủ tài nguyên.

Một phạm vi (scope) đặt tên cho một quyền được yêu cầu trong bộ từ vựng của một dịch vụ. Một tích hợp lịch có thể yêu cầu quyền đọc các sự kiện thay vì sửa đổi chúng. Nhà cung cấp định nghĩa những tên đó có ý nghĩa gì và liệu người dùng, quản trị viên hoặc một chính sách khác phải phê duyệt chúng. Ứng dụng khách nên chỉ yêu cầu quyền truy cập mà mục đích của nó thực sự cần.

Loại client là quan trọng. Một ứng dụng máy chủ thường có thể bảo vệ thông tin xác thực trong backend được kiểm soát. Mã được gửi tới trình duyệt hoặc thiết bị di động không thể coi một client secret nhúng là thông tin mật. Việc đăng ký client và luồng được chọn phải phản ánh ranh giới đó.

Điều Gì Xảy Ra Trong Authorization Code Với PKCE?

Luồng mã ủy quyền chuyển hướng người dùng đến máy chủ ủy quyền, trả về một mã đến vị trí chuyển hướng đã đăng ký của client, và trao đổi mã đó để lấy token. PKCE thêm một verifier và một challenge dẫn xuất để liên kết yêu cầu ủy quyền với lần trao đổi sau đó.

1. Máy khách tạo một giao dịch ủy quyền mới, bao gồm một bộ kiểm chứng và thử thách được dẫn xuất từ nó, và ghi lại trạng thái cần thiết để xác thực phản hồi.
2. Máy khách gửi trình duyệt đến máy chủ ủy quyền kèm theo danh tính máy khách đã đăng ký, địa chỉ chuyển hướng, các quyền được yêu cầu và chuỗi thử thách.
3. Máy chủ ủy quyền xác thực người dùng khi cần và đánh giá sự đồng ý cũng như chính sách.
4. Máy chủ ủy quyền trả về một mã ủy quyền đến địa chỉ chuyển hướng được phép của máy khách.
5. Client xác thực mã phản hồi và trao đổi mã đó cùng với trình xác minh tại token endpoint, sử dụng cơ chế xác thực client bắt buộc khi áp dụng.
6. Máy khách gửi mã thông báo truy cập đến máy chủ tài nguyên dự định để thực hiện các thao tác trong phạm vi quyền cấp.

Việc Cơ chế thử thách và trình xác minh PKCE ngăn việc chỉ sở hữu một mã bị đánh chặn thôi là đủ để hoàn tất quá trình trao đổi khi máy chủ thực thi ràng buộc một cách đúng đắn. Bộ xác minh là dành riêng cho từng giao dịch. Nó không được trở thành một hằng số dùng chung cho toàn bộ ứng dụng.

PKCE không khiến mọi kiểm tra khác trở thành tùy chọn. Client vẫn phải sử dụng đúng máy chủ, xác thực phản hồi nhận được, bảo vệ trạng thái giao dịch của nó và tuân thủ các quy tắc chuyển hướng. Hãy sử dụng một triển khai OAuth được duy trì phù hợp với nhà cung cấp thay vì ghép một luồng từ các đoạn mã rời rạc.

Mã thông báo Truy cập, Làm mới và ID Có Ý nghĩa Gì?

Mã thông báo truy cập (access token) cho phép truy cập tài nguyên, mã thông báo làm mới (refresh token) có thể lấy các mã thông báo truy cập thay thế theo chính sách của máy chủ, và mã thông báo ID (ID token) truyền tải thông tin xác thực trong OpenID Connect. Các mã thông báo này có đối tượng sử dụng và yêu cầu xác thực khác nhau. Việc thay thế mã thông báo này cho mã thông báo khác có thể tạo ra lỗi ủy quyền hoặc lỗ hổng bảo mật.

Mã thông báo truy cập có thể ở dạng mờ hoặc sử dụng một định dạng có cấu trúc. Đừng cho rằng mọi mã thông báo OAuth đều là JWT hoặc rằng việc giải mã một mã thông báo chứng minh nó hợp lệ. Hợp đồng của máy chủ tài nguyên quyết định cách các thuộc tính như nhà phát hành, đối tượng, thời hạn, chữ ký hoặc trạng thái mã thông báo phía máy chủ phải được kiểm tra.

Refresh token là tùy chọn. Việc phát hành, yêu cầu lưu trữ, hành vi xoay vòng và việc thu hồi của nó phụ thuộc vào từng nhà cung cấp. Một client không nên cho rằng sẽ có quyền truy cập vô thời hạn chỉ vì grant ban đầu đã thành công. Thay đổi về scope và chính sách tài khoản có thể làm thay đổi những thao tác được phép thực hiện về sau.

Lớp danh tính của OpenID Connect định nghĩa các mã thông báo ID và các claim xác thực dựa trên OAuth. Một client sử dụng đăng nhập phải xác thực phản hồi nhận dạng theo đúng giao thức đó và cấu hình nhà cung cấp của nó.

Những Ranh Giới Nào Khách Hàng Phải Bảo Vệ?

Client phải bảo vệ việc xử lý chuyển hướng, liên kết giao dịch, thông tin xác thực và đích đến của mọi token. Một tích hợp OAuth là một chuỗi các quyết định tin cậy, không chỉ đơn thuần là một chuỗi các yêu cầu HTTP. Một token dành cho một API không nên được chuyển tiếp đến một dịch vụ không liên quan chỉ vì cả hai đều chấp nhận một header ủy quyền.

Khách hàng thực tiễn tốt nhất hiện tại về bảo mật OAuth cung cấp tiêu chuẩn bảo mật hiện tại cho việc lựa chọn luồng và phòng chống tấn công. Public client phải sử dụng PKCE; cũng khuyến nghị sử dụng PKCE cho confidential client. Việc khớp chuyển hướng và bảo vệ chống tiêm phản hồi ủy quyền vẫn là những phần cần thiết trong thiết kế.

Lưu giữ các bí mật phía server trong kho bí mật được phê duyệt của môi trường triển khai. Hạn chế truy cập vào refresh token và tránh đặt giá trị token trong URL, log, analytics hoặc ảnh chụp màn hình hỗ trợ. Authorization code cũng có thể nhạy cảm trong khi nó vẫn còn sử dụng được, do đó cấu hình log callback cần được xem xét cẩn thận.

Không chọn resource owner password grant như một lối tắt để thu thập thông tin đăng nhập của người dùng. Hướng dẫn bảo mật hiện tại loại bỏ grant đó. Sự đồng ý của người dùng và chính sách của quản trị viên nên được xử lý thông qua trải nghiệm được hỗ trợ bởi authorization server.

OAuth Khác Gì Với Đăng Nhập Trình Duyệt Và API Key?

Một phiên đăng nhập trình duyệt duy trì trạng thái website, một API key xác định quyền truy cập theo chính sách khóa của dịch vụ, và OAuth thể hiện một authorization grant. Các cơ chế này có thể xuất hiện trong một quy trình làm việc mà không thể thay thế cho nhau. Cookie website không tự động trở thành thông tin xác thực API được ủy quyền.

Scrapeless Agent Browser cung cấp môi trường trình duyệt cho các tương tác mà ứng dụng của bạn được ủy quyền thực hiện. Nó không phải là authorization server cho mọi website mà trình duyệt truy cập. Mở một trang đồng ý không cho phép một hệ thống tự động phê duyệt quyền vượt quá chỉ dẫn của người dùng.

Các yêu cầu xử lý API key của Scrapeless mô tả cách thông tin xác thực dịch vụ Scrapeless được sử dụng và bảo vệ. Hãy tuân theo hợp đồng khóa đã được ghi lại đó thay vì thêm tiền tố OAuth bearer hoặc coi một khóa Scrapeless như một token do một nhà cung cấp không liên quan phát hành.

Mẫu triển khai bounded collection worker có liên quan khi tách biệt bí mật khỏi mã ứng dụng có thể tái sử dụng. Một tích hợp OAuth tương tự cũng cần xử lý thông tin xác thực trong thời gian chạy, kiểm soát truy cập và một ranh giới rõ ràng giữa mục đích của worker và các quyền được cấp cho nó.

Một Tích Hợp Được Ủy Quyền Sẽ Được Thiết Kế Như Thế Nào?

Một tích hợp được ủy quyền bắt đầu với một hành động người dùng được xác định và bộ quyền nhỏ nhất nhưng hữu ích. Hãy xem xét một ứng dụng báo cáo minh họa đọc trạng thái rảnh/bận trên lịch của người dùng. Ứng dụng đăng ký callback được phép của mình, chọn luồng ủy quyền được nhà cung cấp hỗ trợ và yêu cầu quyền cần thiết cho trạng thái rảnh/bận thay vì quản trị tài khoản rộng.

Sau callback, backend xác thực giao dịch và lưu trữ an toàn thông tin xác thực được cho phép. Một yêu cầu đến tài nguyên nhắm tới API dự định và được đánh giá theo scope đã được cấp. Ứng dụng ghi nhận trạng thái kết nối mà không để lộ token trong log hiển thị cho người dùng.

Ngắt kết nối cần một thiết kế rõ ràng. Xóa thông tin xác thực được lưu trữ cục bộ và sử dụng các cơ chế thu hồi (revocation) được nhà cung cấp hỗ trợ khi phù hợp. Giải thích cho người dùng liệu việc ngắt kết nối ứng dụng có đồng thời thu hồi quyền phía server hay không. Những hành động đó có liên quan nhưng không phải lúc nào cũng có tác dụng giống hệt nhau.

Hãy kiểm thử trường hợp bị từ chối đồng ý, callback không khớp, trạng thái giao dịch hết hạn và scope không đủ song song với đường dẫn thành công. Một môi trường thử nghiệm nhà cung cấp được kiểm soát có thể xác minh hành vi mà không coi một chuỗi minh họa là một lần ủy quyền thực. Không có grant tài khoản thật nào được khẳng định bởi ví dụ khái niệm này.

Kết luận

Theo dõi OAuth bằng cách lần theo grant quyền: ai đã phê duyệt nó, client nào nhận được nó, tài nguyên nào chấp nhận nó và nó hữu ích trong bao lâu. Giữ phiên trình duyệt và API key dịch vụ tách biệt. Đối với một quy trình dựa trên trình duyệt, hãy xem lại Scrapeless pricing một cách độc lập với quyền của nhà cung cấp đích và chính sách API của họ.