Sign in with Apple Shows the Wrong App Name

Your web login says a different app's name. Here's why, the exact fix in the Apple Developer portal, and the caveat that can silently lock out your users.

A abc @a · · 11 views · 6 min read
#sign in with apple #authentication #apple developer #oauth #debugging

When your web app kicks off Sign in with Apple, all it sends Apple is a client_id (your Services ID) and a redirect URL. Here is the actual authorization request my Express app builds:

const authUrl = `https://appleid.apple.com/auth/authorize?` +
  `client_id=${clientId}` +                       // e.g. gg.articles.web.auth
  `&redirect_uri=${encodeURIComponent(callbackUrl)}` +
  `&response_type=code id_token` +
  `&response_mode=form_post` +
  `&scope=name email` +
  `&state=${state}`;

There is no app name anywhere in that request. The name on the consent screen is rendered entirely by Apple's servers, based on how your identifiers are configured in the developer portal. So no code change or redeploy will ever fix it. It is 100% a console-config problem — which is good news, because it means you can fix it in about ninety seconds once you know where to look.

Let me back up. Last week I opened my own site, clicked "Sign in with Apple," and the Apple popup greeted me with: "Sign into Tail!" Tail is an app I built months ago. This was a completely different project on the same Apple Developer account — and yet Apple was confidently telling my users to sign into the wrong app.

App ID vs Services ID (the part everyone conflates)

Apple has two different identifier types, and mixing them up is the root of this whole mess:

  • An App ID identifies a native app (iOS/macOS). For Sign in with Apple it also acts as a primary App ID — a grouping anchor.
  • A Services ID identifies a website. This is the client_id your server sends.

When you enable Sign in with Apple on a Services ID, Apple forces you to pick a primary App ID to group it under. And here is the rule that explains everything:

The name on the web consent screen comes from the primary App ID your Services ID is grouped under — not from the Services ID itself.

So what happened to me is obvious in hindsight: months ago, when I set up the Services ID for the new site, I grouped it under the existing "Tail" App ID instead of creating a fresh one. Apple faithfully showed "Tail!" ever since. My identifier naming was fine; the grouping pointed at the wrong app.

Step 0: find out which Services ID your site actually uses

Before you change anything, confirm which Services ID is live in production. This matters more than it sounds — many setups have two (say, one ending in .staging and one in .web.auth), and editing the wrong one's grouping changes nothing while you slowly lose your mind.

You do not have to trust the dashboard. Ask the running app. Your sign-in endpoint issues a 302 to Apple, and the client_id in that redirect is the ground truth:

curl -sS -o /dev/null -D - --max-redirs 0 "https://YOURSITE/auth/apple" \
  | grep -i "^location:"
# location: https://appleid.apple.com/auth/authorize?client_id=gg.articles.web.auth&...

There it is: the exact Services ID whose grouping I needed to fix. When a third-party console will not tell you which credential is in use, the app that is already using it will.

The fix (and the two ways to miss it)

At developer.apple.com → Certificates, Identifiers & Profiles:

  1. Identifiers → App IDs → + — create a dedicated App ID for this project and enable Sign in with Apple on it, as a primary App ID. This only makes it available as a grouping target.
  2. Identifiers → switch the top-right filter from App IDs to Services IDs → open the Services ID from Step 0.
  3. Next to Sign In with Apple, click Configure.
  4. Change the Primary App ID dropdown from the old app to your new one → Continue → Save.

Two ways I personally managed to not fix it on my first attempts:

  • I edited the App ID screen and thought I was done. Enabling your new App ID as a primary does nothing on its own — it only makes it selectable. The actual pointer lives on the Services ID.
  • I forgot to click Save. The Configure dialog silently discards your change unless you go all the way through Continue → Save. I changed the dropdown, closed the modal, and wondered why nothing happened. Classic.

The caveat that can strand your users

This is the part worth slowing down for. Apple's own portal text, right there on the App ID configuration screen, says grouping ensures "users only need to provide consent to share their information with you once for each group of apps and websites."

Read that carefully: the app group is the unit of user identity. Sign in with Apple hands your server a stable user identifier — the sub claim — that you store to recognize returning users. That identifier is scoped to the group. Move your Services ID to a different primary App ID, and returning users can come back with a different identifier — so your app treats them as brand-new people and silently locks them out of their existing accounts.

If you are pre-launch, this is a non-event: do it now. I made the change while the site had roughly zero real users, so it cost nothing — which is exactly why I fixed it before sending a single invite. If you already have users who signed in via Apple, treat a primary-App-ID change as an identity migration: you would need to re-link accounts by email (Apple returns the email on first consent), and you should rehearse the whole flow on a throwaway account first. Do not casually flip this on a live product.

"I saved it and it still shows the old name"

Give it time. Apple edge-caches the consent-screen name aggressively — anywhere from a few minutes to a few hours. If you have confirmed the Services ID's primary App ID is correct and saved, the config is right; the cache just has not caught up. Test in a fresh private/incognito window to rule out local caching, and check back later.

The 60-second checklist

  • The name is Apple-rendered — not in your code. Do not hunt for it there.
  • Confirm your production Services ID by reading the client_id in your /auth/apple redirect.
  • Create a dedicated App ID, Sign in with Apple enabled as primary.
  • On the Services ID (not the App ID): Configure → Primary App ID → your app → Continue → Save.
  • Do it before you have users, or plan an email-keyed account migration.
  • Still stale? It is Apple's cache. Wait and retest in a private window.

The whole thing is a five-minute fix once you know the model — but "the consent-screen name is the Services ID's primary App ID grouping, and it stays broken until you click Save" is the sentence I wish I had had an hour earlier.

Related reading

More from abc