Hello,
I am investigating a persistent CloudKit Web Services authentication failure that occurs in both Production and Development for the same container. I filed Feedback Assistant report FB24212003 with the full private configuration and timestamps.
Configuration
- The site is served over HTTPS. Its allowed origin and web authentication return URL exactly match the CloudKit Dashboard configuration.
- The Web Services API token is origin-restricted. No token, Apple Account, container identifier, or user data is included here.
Minimal reproduction
- Configure CloudKit JS with apiTokenAuth for the target environment.
- Begin CloudKit web authorization and complete Apple Account authorization successfully.
- The browser returns with a one-time ckWebAuthToken/ckSession callback parameter.
- On that callback page, make exactly one GET request to /database/1/[container]/[environment]/public/users/current, passing only ckAPIToken and the one-time ckWebAuthToken. The request uses credentials: omit, cache: no-store, and no referrer.
Actual result
The first request immediately returns HTTP 421 with serverErrorCode AUTHENTICATION_REQUIRED and reason "request needs authorization".
Production request UUID: 19e12af3-4cc1-474f-910e-cc98a18a6637 Development request UUID: 2ebabb8d-efba-41c5-8268-69123e056fd6
Controls completed
- A direct one-time REST probe on the callback page reproduces the failure while bypassing CloudKit JS entirely.
- CloudKit JS default Cookie store and a custom same-origin authTokenStore both reproduce it.
- Fresh authorization reproduces in Edge and in an independent Safari profile.
- Native iOS CloudKit synchronization for this container and Apple Account succeeds, including an explicit web-sync upload.
- The Production schema is deployed. A previous query-index issue was resolved separately; this failure occurs at users/current before any record read.
Questions
Could a container-level or team-level CloudKit Web Services authorization/provisioning state cause callback tokens to be rejected by users/current in both environments? Is there a server-side configuration or remediation that should be checked?
I can provide the container identifier, exact endpoint timestamps, and additional redacted diagnostics privately through FB24212003. I will not post credentials or user data publicly.