Aeion Auth + Sign in with Apple
Privacy-first consumer SSO for native iOS apps. Your app runs Apple's native `ASAuthorizationAppleIDProvider` flow and hands the resulting identity token to Aeion, which verifies it server-side against Apple's JWKS (issuer + audience checked, email must be verified) and creates the session. Required for App Store apps that ship competing OAuth providers under guideline 4.8.
When This Integration Matters
Two reasons to add Sign in with Apple:
Step 1 — Apple Developer Setup
Aeion's Apple integration verifies the identity token your native iOS app already receives from Apple — it does not run a server-to-server OAuth exchange with Apple. Setup on Apple's side:
Step 2 — Send the Identity Token to Aeion
From your native app, call Aeion's social-login endpoint with the identity token Apple gave you:
The id_token-Only Flow
Apple's identity token is a signed JWT with no companion /userinfo endpoint — all Aeion needs is already in the token:
The First-Time-Only Name Quirk
Apple's native SDK gives your app the user's fullName ONCE — on the very first authorization. ASAuthorizationAppleIDCredential.fullName is nil on every subsequent sign-in; Apple doesn't return it again.
Private Email Relay
When the user chooses "Hide my email" on the Apple consent screen, Apple's identity token carries a private-relay address like abc123def@privaterelay.appleid.com instead of the user's real email, and Apple forwards emails sent to it to the user's real Apple ID email.
Common Gotchas
- Verification returns null with no error detail —
verifyAppleIdentityTokenfails closed on any problem (bad signature, wrong issuer, audience mismatch, expired token, unverified email) and just returnsnull; the endpoint responds with a generic "Could not verify your account" error. Check thatclientIdin your request exactly matches your app's bundle ID (it must equal the token'saudclaim).
FAQ
No — those are only needed for Apple's server-to-server OAuth token exchange, which Aeion doesn't implement. Aeion verifies the identity token your native app already has, using Apple's public JWKS.
Yes — emails sent to `abc@privaterelay.appleid.com` reach the user's real Apple ID inbox. Register your sending domain at developer.apple.com → "Sign in with Apple for Email Communication" to avoid bouncing. Aeion doesn't flag which emails are relay addresses versus real ones.
Aeion logs them straight into the existing account matched by email — there's no separate account-linking confirmation step today. If that's a concern for your tenant's threat model, gate `/social-login` accordingly at your app layer.
No stored Apple token or connection is tied to the session — Aeion verifies the identity token once at login and then issues its own refresh token. Revoking on Apple's side doesn't affect an already-issued Aeion session; it only blocks future identity-token issuance from Apple.
Yes — this is the only flow Aeion supports for Apple. Your iOS app runs `ASAuthorizationAppleIDProvider` natively and posts the resulting `identityToken` to `POST /api/auth/social-login`. There's currently no web-redirect ("Sign in with Apple" button on a web page) flow.