Skip to content
Get a quote

Sign in with Apple errorWhy does Sign in with Apple return invalid_client?

Apple sign-in worked, or works in the iOS app, but the web flow stops with invalid_client. Apple returns it for a few different problems, mainly that it can’t find the client ID you sent, or it rejects the client secret. Here’s how to tell which and what to change, or hand it over at a fixed price.

Short answer

invalid_client means Apple couldn’t find the client ID you sent, or the client secret is invalid or expired. On the web, the client ID must be your Services ID, exactly as registered. In Supabase, list the Services ID first under Client IDs. The secret key for the OAuth flow has to be regenerated every 6 months from your .p8 signing key; an expired one fails with invalid_client too.

Which part Apple rejects, and the fix

  1. 01

    Apple can’t find the client ID

    “The authorization request is invalid because the primary app or web service with the provided client_id could not be found.” Apple, TN3107: Resolving Sign in with Apple response errors

    For web sign-in, the client ID is the Services ID you created in the Apple Developer Console, not the native App ID. Copy it again from Identifiers and compare it character for character; Apple matches it case-sensitively.

  2. 02

    In Supabase, the App ID is listed before the Services ID

    “If a native App ID comes before the Services ID, native sign-in keeps working but web sign-in is rejected by Apple.” Supabase, Login with Apple

    If the project also has native sign-in on iOS, Expo or Flutter, the Client IDs field holds both. Supabase uses the first one for the web flow, so the Services ID has to come first. The native flow accepts any ID in the list.

  3. 03

    The secret key expired after 6 months

    “Apple requires you to generate a new secret key every 6 months using the signing key ( .p8 file).” Supabase, Login with Apple

    The web OAuth flow uses a secret key generated from your .p8 signing key, and Apple requires a new one every 6 months. If it worked and then stopped about 6 months after setup, generate a new secret, update it in Supabase (or your server), and set a reminder for the next one. Native-only setups don’t need this.

  4. 04

    Your own server builds the client secret wrong

    “The client_secret has a sub claim that is not identical to the value registered to your developer account.” Apple, TN3107: Resolving Sign in with Apple response errors

    If your backend creates the client secret JWT itself, Apple lists the usual faults: form data that isn’t percent-encoded, missing headers or claims, a sub claim that isn’t identical to the value registered to your developer account, an expired secret, or an invalid signature. A JWT library has to support E256 signatures.

  5. 05

    Related: the redirect URL isn’t registered

    “Make sure the provided redirect_uri is valid, publicly accessible, and is identical to the value registered for the service.” Apple, TN3107: Resolving Sign in with Apple response errors

    A wrong or missing redirect URL gives unauthorized_client rather than invalid_client. In Supabase, the Services ID’s redirect URL is your project’s /auth/v1/callback address.

    https://<project-id>.supabase.co/auth/v1/callback

Checked against the vendor’s docs on : Apple: TN3107, Resolving Sign in with Apple response errors; Supabase docs: Login with Apple.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: App Store Guideline 4.8 (login services) · Google OAuth redirect_uri_mismatch · Supabase auth emails link to localhost · Supabase public storage bucket

Questions

More on this error

Why does Apple sign-in work in the iOS app but not on the web?

Native sign-in and the web OAuth flow use different client IDs. Supabase says native sign-in accepts any client ID in its list, while the web flow uses the first one, which must be the Services ID.

Do I need to rotate the key if I only use native sign-in?

No. Supabase says the 6-month secret key rotation only applies when you configure the OAuth settings (Services ID, signing key and so on); native-only setups don’t need it.

What’s the difference between invalid_client and unauthorized_client?

Apple uses invalid_client when it can’t find the client ID or rejects the client secret, and unauthorized_client when the redirect URL is incorrect or missing.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; we reply by email, usually within one business day.

Describe your problem All fixes