AUTH4D-334 device authorization budgets

The device flow endpoints spend a per-IP budget first, so one caller cannot use up the budget of a whole application or of a player’s code. Client-wide and tenant-wide budgets remain as backstops sized for real traffic. The routes, request shapes and success responses are unchanged.

Budgets

Budgets are spent in the order listed. The first one that is exhausted refuses the request.

• IP addresses come from CF-Connecting-IP and are HMAC-pseudonymised before they reach the Durable Object, like every other per-IP budget. A request with no resolved address shares one bucket instead of skipping the limit.
• The application poll budget is spent only after the device code has been found, belongs to this tenant and application, and has not expired. Polls with unknown or expired codes never count towards it, so they cannot cause slow_down for real codes.
• The application start budget is a backstop for many addresses at once. About 1,000 codes an hour, each live for up to 10 minutes and polled 12 times a minute, stays under the poll backstop.

Responses

A refused request returns the same error as before:

HTTP/1.1 429 Too Many Requests
Cache-Control: no-store, max-age=0
Content-Type: application/json

{ "error": "slow_down" }

When the application poll backstop refuses a poll, the device code is left exactly as it was, so the next poll after the window resets continues normally.

RFC 8628 slow_down for real codes is unchanged: a poll before the current interval has passed returns 400 slow_down and adds 5 seconds to the code’s interval.

Configuration

The defaults are DEVICE_ABUSE_BUDGETS in apps/api/src/modules/device/index.ts. DeviceFeatureOptions.budgets overrides any of them, for deployments that need different limits and for tests.

Tests: tests/integration/auth4d-334.device-budgets.test.ts.