Sign in with Apple

Sign in with Apple is App Store policy. If your iOS app already supports any third-party sign-in (Google, Facebook, GitHub), Apple requires you to support Apple too, with equal prominence. Web and Android apps are not subject to the policy, but the user demand is real either way.

Apple's flavour of OIDC is mostly standard with a few quirks that bite if you don't know them. The big ones: email-relay addresses, single-event name claims, key rotation.

Before you start

You need:

An Apple Developer Program membership. (As of 2026, $99/year — Apple adjusts this periodically.)
A primary app identifier registered in the Apple Developer portal.
A "Sign in with Apple" capability enabled on that identifier.
A Service ID configured for web sign-in.
A signing key (.p8 file) for the Sign in with Apple capability.

The Apple side of setup is the longest of any social connection in this section. Set aside 30 minutes the first time.

Step 1 — configure on the Apple side

Identifiers → App IDs → create a new App ID for your app. Enable the Sign in with Apple capability.
Identifiers → Services IDs → create a new Service ID. This is the "client id" Apple will use to identify your web app. Configure the domain (<your-tenant-url>) and the return URL:

https://<your-tenant-url>/auth/callback/apple

Keys → create a new key, enable Sign in with Apple, associate it with the Primary App ID. Download the .p8 file when offered — you can only download it once.
Note the Team ID (top right of the Apple Developer portal), the Service ID (the one you created above), and the Key ID (visible after the key is created).

Step 2 — configure on the IntelliAuth side

Tenant admin console → Authentication → Social providers → Apple. Fill in:

Service ID (the one Apple gave you — this is the "client id").
Team ID.
Key ID.
Private key — paste the contents of the downloaded .p8 file.

IntelliAuth uses these to sign the JWT client-assertion Apple requires (Apple does not use a static client secret; the secret is a short-lived JWT signed with your private key, regenerated on every token request).

Step 3 — add the button in your app

<button onClick={() => loginWithRedirect({ connection: 'apple' })}>
  Sign in with Apple
</button>

Apple has strict requirements for the button's visual treatment — see Apple's Human Interface Guidelines. Use Apple's stock button styles; matching the guidelines is non-negotiable for App Store review.

The three Apple quirks

Quirk 1: email relay addresses

When a user signs in with Apple, they choose between "Share my email" and "Hide my email". If they hide it, Apple gives you a relay address like abc123@privaterelay.appleid.com. Mail sent to that address is forwarded to the user's real email.

Implications:

The email you see is valid — Apple will forward your verification emails.
The relay address is stable for the lifetime of the user's Sign in with Apple grant. If the user revokes the grant, the relay stops forwarding.
The relay is unique per app + user. The same user signing in to two different apps gets two different relay addresses.

Design your code on the assumption that an email could be a relay. Don't show it back to other users as "the user's email" — show their name or chosen username instead.

Quirk 2: name is only sent once

Apple sends the user's name claim only on the first sign-in. On subsequent sign-ins, the name field is absent. If your code does not capture it on the first sign-in and store it, you never get it again.

IntelliAuth handles this for you: the first sign-in populates the user record's name field; subsequent sign-ins do not overwrite it. If the user changes their name in Apple's account settings, your record will become stale — surface a profile edit screen so users can update it themselves.

Quirk 3: key rotation

Apple rotates the signing keys used for id tokens. The keys are exposed at https://appleid.apple.com/auth/keys. IntelliAuth refreshes its cached copy on kid miss, so this is invisible to you in practice — but it matters if you ever implement Apple sign-in by hand.

The most common failures:

Service ID mismatch — Apple is strict about the Service ID, Team ID, and return URL matching exactly.
Expired key — Apple's signing keys do not expire, but your .p8 key can be revoked. If revoked, regenerate and update IntelliAuth.
Return URL not configured — Apple's "Return URLs" list in the Service ID configuration must include the IntelliAuth callback URL.

The audit log records every failed Apple sign-in with Apple's error code. That code, plus Apple's documentation, will tell you which configuration field is off.