Tin tức

Cloudflare OAuth hỗ trợ đồng ý theo tác vụ: Người dùng có thể từ chối các phạm vi tùy chọn

Cloudflare giới thiệu tùy chỉnh phạm vi OAuth, cho phép người dùng cấp quyền truy cập hẹp hơn tại thời điểm ủy quyền. Nhà phát triển đánh dấu các phạm vi là tùy chọn, và màn hình đồng ý thích ứng — một bước đi thực tế hướng tới đặc quyền tối thiểu cho agent và máy chủ MCP.

August 21, 2026· 4 min read· Nguồn: Cloudflare Blog
Cloudflare OAuth hỗ trợ đồng ý theo tác vụ: Người dùng có thể từ chối các phạm vi tùy chọn

Cloudflare đang triển khai tùy chỉnh phạm vi OAuth, một tính năng cho phép người dùng bỏ chọn các phạm vi tùy chọn trên màn hình đồng ý trước khi ủy quyền cho ứng dụng bên thứ ba. Cho đến nay, màn hình đồng ý là tất cả hoặc không: bạn hoặc chấp thuận toàn bộ tập phạm vi được yêu cầu hoặc từ chối toàn bộ. Điều đó không phù hợp với các khối lượng công việc hiện đại như máy chủ MCP và agent AI, vốn thường yêu cầu quyền rộng vì chúng có thể cần — không phải vì chúng luôn cần.

Thay đổi này được xây dựng dựa trên tính linh hoạt đã có trong đặc tả OAuth: máy chủ ủy quyền có thể cấp một tập phạm vi hẹp hơn so với yêu cầu. Cloudflare chỉ đơn giản là phơi bày khả năng đó cho nhà phát triển và người dùng.

Cách hoạt động

Khi cấu hình một ứng dụng OAuth, nhà phát triển có thể đánh dấu các phạm vi cụ thể là optional_scopes. Tại thời điểm ủy quyền, người dùng thấy các phạm vi được yêu cầu và có thể bỏ chọn các phạm vi tùy chọn. Các phạm vi bắt buộc vẫn bị khóa. Nếu không có phạm vi tùy chọn nào được yêu cầu, màn hình đồng ý hoạt động chính xác như trước — không có hồi quy cho các ứng dụng hiện có.

Một sắc thái quan trọng: các phạm vi tùy chọn và bắt buộc được đánh giá dựa trên các phạm vi được yêu cầu trong một luồng ủy quyền cụ thể, không phải toàn bộ tập phạm vi cấu hình của ứng dụng. Nếu một ứng dụng chỉ yêu cầu một tập con, chỉ tập con đó được hiển thị và thực thi. Điều này giữ cho màn hình đồng ý tập trung vào tác vụ đang thực hiện thay vì mọi khả năng mà ứng dụng có thể sử dụng về mặt lý thuyết.

Nhà phát triển cần làm gì

Nếu bạn đang xây dựng một ứng dụng OAuth trên Cloudflare, bạn cần xử lý các cấp quyền một phần. Sau khi trao đổi mã ủy quyền, hãy kiểm tra tập phạm vi thực tế được cấp thay vì giả định toàn bộ yêu cầu đã được chấp thuận. Các ứng dụng hoạt động linh hoạt trong một tập quyền hẹp hơn sẽ giành được nhiều lòng tin hơn từ người dùng — và nhiều sự ủy quyền hơn.

Đây là ví dụ về cấu hình một ứng dụng với các phạm vi tùy chọn qua API:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/oauth_clients" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "client_name": "ACME Corp",
    "redirect_uris": ["https://acme.org/oauth/callback"],
    "grant_types": ["authorization_code"],
    "response_types": ["code"],
    "token_endpoint_auth_method": "client_secret_basic",
    "scopes": ["user-details.read", "workers-scripts.write", "workers-kv-storage.write", "zone.read"],
    "optional_scopes": ["workers-kv-storage.write", "zone.read"]
  }'

Trong ví dụ này, user-details.readworkers-scripts.write vẫn là bắt buộc, trong khi người dùng có thể từ chối hai phạm vi còn lại.

Tại sao điều này quan trọng với agent

Đây là phản hồi trực tiếp cho sự trỗi dậy của agent AI và máy chủ MCP. Một máy chủ MCP có thể yêu cầu một tập quyền rộng vì một agent có thể sử dụng tất cả — nhưng hầu hết người dùng không muốn trao nhiều quyền truy cập như vậy. Trước đây, giải pháp duy nhất là nhà phát triển ứng dụng phải xây dựng một màn hình chọn phạm vi tùy chỉnh trước khi chuyển hướng đến luồng đồng ý của Cloudflare. Giờ đây, nó đã được tích hợp sẵn.

Cloudflare cũng lưu ý rằng họ đang mở rộng bề mặt vai trò cấp tài khoản và vùng để bao phủ gần như mọi sản phẩm, nghĩa là các phạm vi OAuth chi tiết hơn và vai trò token API đang trên đường đến.

Tính năng này đã hoạt động. Các ứng dụng hiện có giữ nguyên hành vi hiện tại theo mặc định; chọn tham gia là một thay đổi cấu hình, không phải di chuyển.

Màn hình đồng ý là tất cả hoặc không: chấp thuận toàn bộ yêu cầu hoặc từ chối hoàn toàn. Giờ đây người dùng có thể cấp một tập con hẹp hơn của quyền truy cập được yêu cầu của ứng dụng tại thời điểm ủy quyền.
Ban biên tập Manul X