Socialite Apple Sign In Laravel Package

Product Decisions This Supports

• App Store compliance / iOS launch: Apple requires "Sign in with Apple" (App Store Guideline 4.8) whenever an app offers third-party social login. If our roadmap includes Google/Facebook login in an iOS build or web view, this package is the shortest path to satisfying that requirement on the Laravel backend.
• Build vs. buy for auth: The alternative is hand-rolling Apple's OAuth2 flow — generating the ES256-signed client-secret JWT from a .p8 key, POSTing to Apple's token endpoint, validating the id_token, and handling the "user data returned only on first consent" quirk. This package collapses that into Socialite configuration. The build option only wins if we have requirements it can't meet (see below).
• Feature/roadmap unblocking: Enables consumer-facing sign-in parity work, account linking between existing email accounts and Apple IDs, and mobile-backend auth stories currently gated on "we support Apple."
• Data-model decisions it forces early: Apple returns name and email only on the very first authorization, and email may be an @privaterelay.appleid.com relay address. This drives schema and onboarding decisions (nullable display name, prompt-for-profile fallback, treating relay addresses as deliverable mail).
• Release 2.2.2 relevance: A patch fix for a header-by-reference error in the request path. Low risk, no API surface change — it removes a potential hard failure during the authorize/token exchange, which matters because an Apple sign-in failure is launch-blocking on iOS rather than a degraded experience. This is the kind of quiet patch that argues for pinning versions and having an integration test around the callback.

When to Consider This Package

Adopt when:

• We're already on Laravel + Socialite and want Apple as just another driver.
• Scope is a single Apple Developer account with one or a few Service IDs (web + mobile backend).
• The team doesn't want to own JWT signing, key rotation, and Apple's token-endpoint quirks.
• We need standard authorization-code flow with server-side callback handling.

Look elsewhere / build or wrap when:

• Multi-tenant or multi-brand: per-tenant Service IDs and separate .p8 keys usually exceed what a thin driver exposes.
• We need first-class token revocation and refresh-token lifecycle management against Apple's /auth/revoke and /auth/token endpoints — verify support before committing; a driver that only does login may leave account-deletion compliance (another App Store requirement) to us.
• Native-only iOS (ASAuthorizationController) or Sign in with Apple JS in a SPA with several client IDs.
• Security posture requires vendor SLAs, active security review, or a large maintainer base. This is a small, single-maintainer package — treat it as a dependency to pin, monitor, and be able to fork.
• We'd rather depend on Socialite's own upstream providers or a maintained auth service.

Mitigation regardless: wrap the provider behind our own auth adapter interface so swapping to custom code is a contained change, pin to ~2.2, and cover the callback plus private-relay-email path with tests.

How to Pitch It (Stakeholders)

For executives: Shipping social login on iOS without "Sign in with Apple" risks App Store rejection, and this package is the small, low-cost way to close that gap on our Laravel backend instead of spending engineering weeks implementing Apple's cryptographic token flow ourselves. It's a maintenance-sized dependency, not a platform commitment. The trade-off is one more third-party package to track, mitigated by pinning the version and keeping our integration thin enough to replace.

For engineering: It's a Socialite driver for Apple — config plus a callback route, no bespoke crypto. The 2.2.2 release is a low-risk patch (fixes headers being passed by reference) with no breaking changes or config changes, so upgrading from 2.2.1 is safe. Adopt it behind our own auth adapter, pin ~2.2, and add integration coverage for the callback and the first-consent-only profile/relay-email behavior, since that's where the real integration risk sits — not in this patch.