Apple Laravel Package

Product Decisions This Supports

• Auth roadmap sequencing — ship Apple sign-in this quarter, not next. For an existing Laravel product already on Socialite (Google, Facebook, GitHub), this package is the cheapest credible path to a "Sign in with Apple" button. The integration is a provider adapter, two routes, a config block, and a client-secret job. Framed correctly, it's a small scheduled story, not an epic — which is the single most useful thing a PM can do with this package.
• Build vs. buy, scoped honestly. The buy decision is narrow: you are purchasing the OAuth2 adapter only. Apple's ES256 client-secret JWT signing, JWKS signature verification for native-originated tokens, refresh-token capture, and token revocation remain your engineering work regardless of adoption. Budget the decision as "buy the adapter, build the lifecycle" — not "buy Apple auth." Note: the package description advertises "automatic ES256 client secret generation," but the implementation notes state the provider explicitly does not sign your secret. Verify against the Provider class before this claim reaches a roadmap slide.
• Platform parity and store-facing requirements. If the roadmap includes an iOS app, or if login parity across providers is a stated product expectation, Apple sign-in is table stakes that surfaces in design review and app review — not optional garnish. This package converts that parity item from an epic into a backlog story with a believable estimate.
• Account lifecycle and compliance scope. Apple requires token revocation when a user deletes their account for App Store apps. Because user() hides the raw token response, you must explicitly call getAccessTokenResponse() in the callback and encrypt the refresh_token at consent time — you cannot retroactively recover it. That is an architectural constraint, and it should be surfaced before committing to a deletion SLA or publishing a privacy policy that promises it.
• Identity data model decisions. Apple sends name and email only on first consent; email may be a @privaterelay.appleid.com relay address; email_verified can arrive as a string. These are product-visible facts. They determine whether onboarding needs a "confirm your name" step, whether email can be an account-linking key (it cannot — use the sub claim), and whether lifecycle/marketing messaging can rely on Apple-derived addresses. Decide these in design, not after launch.
• Multi-client roadmap, unlocked by 6.1.0. Multiple identity-token audience support means one backend can serve a web Services ID and a native bundle ID. Genuine roadmap unblocker for web-plus-iOS products — but it's a security-sensitive config change. Treat it as an enabler requiring security sign-off, not a free dependency bump.
• Vendor concentration risk as an explicit, priced trade-off. 58 stars, zero listed dependents, thin wrapper around a monorepo subtree split. Adopting this is a bet on upstream SocialiteProviders/Providers. Mitigate by wrapping the provider behind an internal SignInWithApple service interface (redirect(), userFromCallback(), revoke()) so an eventual exit is a one-file change and replacement cost stays low.

When to Consider This Package

Adopt when:

• You are on Laravel and already use Socialite for other providers — the marginal integration cost is genuinely small.
• You need web Sign in with Apple, or a backend that accepts an iOS-supplied id_token and maps it to a user.
• You have (or will staff) engineering capacity for the parts the package does not do: client-secret JWT generation and rotation, JWKS verification, refresh-token storage, revocation.
• You can accommodate the operational quirks: POST callback route, CSRF exclusion, SESSION_SAME_SITE=none over HTTPS, and a byte-exact Return URL in the Apple Developer console.
• You accept the upstream risk and are willing to pin a version, watch the monorepo changelog, and keep an internal abstraction.

Look elsewhere (or plan to build more) when:

• You need a fully managed auth product with revocation, refresh, JWKS verification, and secret rotation handled for you — evaluate a hosted IdP (Auth0, Cognito, WorkOS, Firebase Auth) instead. This package is a driver, not an auth platform.
• Your stack isn't Laravel/Socialite. There's no value here.
• You cannot invest in the security work around native token validation. Client-originated id_tokens require signature verification against Apple's JWKS plus iss/exp/aud checks — payload decoding alone is not authentication. stateless() disables the state check and must never be used for the browser flow.
• You need vendor SLAs, a security review trail, or a commercial support contract. Small-community package, no dependents, no support guarantee.
• You want Apple sign-in to also solve multi-provider account linking. Account linking by email is unsafe here because of relay addresses — that's a design problem the package doesn't address.

How to Pitch It (Stakeholders)

For executives — the one-liner: Adding Sign in with Apple to our Laravel product is a small, well-understood adapter integration, not a new auth system. It gets us platform parity and removes a predictable App Store review objection for roughly a story of engineering, plus a defined set of follow-on lifecycle work we'd need anyway.

Three points to land:

1. Scope and cost are legible. The adapter is thin — a handful of methods. The real estimate is "adapter + integration testing + secret-rotation job." Give that number, not the optimistic one.
2. The compliance tail is real and must be funded. Token revocation on account deletion is an Apple requirement. Because Apple only issues a refresh token at consent, we must capture and encrypt it at first login — this cannot be retrofitted. Fund it in the same phase or explicitly descope the deletion promise.
3. Risk is bounded by an internal wrapper. We're not exposing Socialite throughout the codebase. One service class owns the integration, which gives us test seams today and makes swapping the package a one-file change later.

For engineering — the framing they'll respect: this package is an OAuth2 adapter with a deliberately thin surface. Read Provider first. It does not sign secrets, verify JWKS, or revoke tokens — those are ours. The known sharp edges are the POST callback, CSRF exclusion, and SameSite cookie behavior; the known data edges are first-consent-only name/email and private relay addresses. Build against the sub claim, capture the refresh token in the callback, rotate the client secret on a schedule via cache rather than a static .env JWT, and pin the version while tracking the SocialiteProviders/Providers changelog — the 6.1.0 multi-audience change is exactly the kind of provider-behavior shift that warrants a config review, not a blind composer update.