OAuth account-token delegation: five groups non-selectable despite explicit first-party CLI consent
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
- Lĩnh vực
- authentication
Hướng nghiên cứu
The report names no repository files or tests and says the issue concerns OAuth account-token authorization, not a claimed cf command bug. Start by checking whether this repository owns the first-party CLI OAuth scopes or permission-group behavior, then trace any relevant scope mapping and authorization path. Done means identifying the responsible behavior and explaining the required scopes, any mapping discrepancy, and the safe reconciliation path for the unavailable rejection details.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary of the issue
Could you clarify the account-token delegation requirements for the first-party Cloudflare CLI OAuth client?
An accepted account membership has Super Administrator - All Privileges. Connected Applications independently shows all nine requested CLI permissions, including Account API Token Provisioning. The OAuth token returns this exact scope set:
offline_access
memberships.read
account_api_tokens:create
workers-scripts.write
query-cache.read
access.read
access-acct.read
zone.read
dns.read
workers-routes.read
The first-party client ID is cbca97e7-c331-4cdd-8fd8-e25a451b98bf. An authenticated GET /accounts/{account_id}/tokens/permission_groups still returned:
| Permission group | Resource | is_selectable |
|---|---|---|
| Workers Scripts Write | account | false |
| Hyperdrive Read | account | false |
| Access: Apps and Policies Read | account | false |
| Access: Organizations, Identity Providers, and Groups Read | account | false |
| DNS Read | zone | false |
| Zone Read | zone | true |
| Workers Routes Read | zone | true |
These observations were refreshed on 2026-10-27 at 11:57:44 UTC. The actual profile is explicitly selected; source inspection ruled out an environment/default-token fallback. Read-only API/native preflight with that issuer succeeds for the corresponding resources.
The authenticated owner dashboard allows all seven exact groups. Its official JSON Payload matches the reviewed account/zone resource bounds, permission-group IDs and expiry. One separately approved owner-dashboard creation with those policies succeeded. Its replacement token is operational and will not be changed for this investigation.
Expected behaviour
Cloudflare's October 1 announcement says account-token permissions are bounded by both the creator's membership and OAuth scopes. Could the authorization team explain:
- Which additional underlying scope(s), if any, are required for the five groups above?
- If the listed scopes should suffice, is there a scope-to-permission mapping discrepancy?
- What is the safe authoritative reconciliation path for an earlier failed creation whose complete rejection details are unavailable?
The permission-group documentation correctly says creation is authoritative. One earlier exact-policy POST, at 2026-10-27T10:28:30.735Z, returned HTTP 400 / error code 400. Our previous adapter unfortunately discarded the detailed rejection envelope and original request correlation ID. We therefore do not claim that the catalog flags caused the POST failure. That attempt remains quarantined and has never been retried. Empty inventories and absent accessible audit entries were not treated as proof of non-issuance.
Version of cf used
The cf binary was not invoked. This is an API/OAuth delegation clarification using the published first-party CLI client through @alchemy.run/[email protected] and direct bounded REST reads. Please route to the account-token/OAuth authorization owners if this is outside this repository's scope; this report does not assert a cf command implementation bug.
System information and package versions
macOS; Bun 1.4.3; Alchemy core and Cloudflare provider beta.84; Effect 4.0.6. Only read-only follow-up diagnostics were performed.
Reproduction (optional)
With the explicitly consented first-party CLI OAuth principal, read GET /accounts/{account_id}/tokens/permission_groups and compare the seven rows above. No further token creation was attempted. The successful owner-dashboard creation used the same exact seven policies and expiry; that operational token is preserved.
Relevant error logs (optional)
A step-up for an older Cloudflare MCP connection initially requested account-api-tokens.write together with its existing scope set. The authorization page refused the whole request with:
Invalid Scope
Unknown OAuth scope: workers-scripts.bind
Error code: invalid_scope
Comparison of the actual requested list (385 scopes including protocol scopes) against the live public catalog (401 entries) found only workers-scripts.bind unsupported. Removing only that unsupported entry allowed a fresh OAuth login to complete. A newly connected official Cloudflare plugin can now read the permission-group endpoint with HTTP 200; its separate grant reports the Access/DNS groups selectable, but Workers Scripts Write and Hyperdrive Read still non-selectable. These are different OAuth grants, not proof of the first-party CLI failure's cause.
No token values, account/zone IDs, callback codes, private application code or private screenshots are included in this public request. No additional token issuance, permission mutation or production change is requested.
- Ngôn ngữ chính
- TypeScript
- Star
- 960
- Fork
- 62
- Merge trung bình
- 23 giờ 46 phút
- Pull request đã merge (30 ngày)
- 217
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của cloudflare/cf
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
cloudflare/cf#344 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
upstream
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
cloudflare/cf#262 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
`cf dev` rejects `--port` and `--host` for Vite projects, including the `cf init` templateCó thể đã có người làm @jamesopstad đã nhận 17 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
cloudflare/cf#223 · 2 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
upstream
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
cloudflare/cf#179 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
cloudflare/cf#438 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của cloudflare/cf
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
area:desktop area:ui bug platform:macos
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
anthropics/claude-code#106183 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
reproduced
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
anomalyco/opencode#60558 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày