Summary: invalid_client on a Services ID whose portal configuration is complete and correct, AND the same team's native App ID cannot be revoked from the iOS Settings UI ("Stop authorisation has failed - Invalid client"). Both started on 17 July 2026. Sign in with Apple on this App ID worked normally earlier the same day.
Team ID: 8ASV5HF9RR Primary App ID: co.uk.2point45.calendarapp Services ID: co.uk.2point45.web
Issue 1 (web): a request to the authorize endpoint with client_id set to the Services ID and redirect_uri set to a registered Return URL returns invalid_client. This reproduces with plain curl - no browser, no JS SDK, no popup, no scope, no nonce. The minimal request (response_type=code, response_mode=query) fails identically, so no application code is involved.
Issue 2 (native): Settings > Apple Account > Sign in with Apple > [the app] > Stop using Apple ID returns "Stop authorisation has failed - Invalid client". This is the Settings app failing against the Sign in with Apple backend for the native App ID, with no third-party code in the path. sysdiagnose attached to the Feedback, captured with the Accounts/AuthKit profile installed.
Already verified, so please don't return these as the cause:
App ID has Sign in with Apple enabled and is set to "Enable as a primary App ID" Services ID has Sign in with Apple enabled, grouped to that primary App ID, with 6 Website URLs attached client_id is the Services ID, not the App ID redirect_uri is a character-for-character match of a registered Return URL Domains registered without a scheme; Return URLs registered with https TLS 1.2+ on all domains No domain association file uploaded, per the documentation ("You don't need to upload a file on your server to complete the registration process for domains and subdomains") Not applicable: no client secret JWT, refresh token or access token can be supplied, because this integration never calls the token endpoint. It uses Sign in with Apple JS with response_type=code id_token and verifies the returned id_token against the published JWKS. The failure is at the authorize endpoint, before any token exchange.
The only portal changes between working and failing were: (1) creating the Services ID and selecting the App ID above as its Primary App ID, and (2) renaming the App ID's Description from the Xcode-generated default. No capabilities were changed.