Weave Code
Laravel Sign In With Apple Laravel Package
genealabs/laravel-sign-in-with-apple
Add Sign In With Apple to your Laravel app. This package integrates Apple's OAuth flow with Laravel Socialite, handles the Apple developer configuration, and provides a ready-made button and controller. Requires PHP 8.2+, Laravel 10+, and an Apple Developer subscription.
Add Apple's new single-signon feature to your site with ease.
Frequently asked questions about Laravel Sign In With Apple
- How do I install laravel-sign-in-with-apple in a Laravel application?
- Install it with composer require genealabs/laravel-sign-in-with-apple, publish the package config, and set the Apple credentials (team ID, key ID, private key, service ID, and return URL) in your environment file. The package registers its Socialite driver automatically, so no manual provider wiring is needed. You need PHP 8.2 or newer, Laravel 10 or newer, Socialite 5 or newer, and an Apple Developer subscription.
- Which Laravel and PHP versions does this package support?
- Version 5.x supports Laravel 10, 11, 12, and 13, running on PHP 8.2 and above, with Laravel 13 requiring PHP 8.3 and above. It also requires Laravel Socialite 5.0 or newer. Check the version support table in the README before upgrading Laravel or PHP.
- How does the package generate the Apple client secret?
- The bundled ClientSecretGenerator builds the ES256 JWT client secret in PHP, signing it with your Apple private key and the team ID, key ID, and service ID from your config. This replaces the external Ruby and jwt gem toolchain that most Apple sign-in guides use, so rotation can live in a scheduled Artisan command. Apple caps client secret lifetime at 180 days, so schedule rotation and alerting or new sign-ins will fail silently while existing sessions keep working.
- Do I need an Apple Developer account, and what configuration is required?
- Yes, you need an active Apple Developer subscription. You create an App ID with Sign in with Apple enabled, create a Service ID for the web with the primary App ID selected, register the exact HTTPS return URL, generate a private key, and verify your domain by hosting the apple-developer-domain-association.txt file. This portal work is access-controlled and often depends on who holds Account Holder or Admin roles in your Apple organization, which is frequently the real schedule risk.
- Why do I get a 419 error on the Sign in with Apple callback route?
- Apple posts the authorization response back as form_post, so the callback must be a POST route and must be exempt from CSRF verification. The package automatically excludes the configured callback from CSRF, but that creates an implicit coupling between your route definition and the package config, so verify the route name and path match exactly. Any mismatch, proxy rewrite, or trailing-slash difference will surface as a 419 or a redirect URL error.
- Do I have to use geneaLabs/laravel-socialiter with this package?
- No, laravel-socialiter is an optional convenience for automatic user resolution and persistence. You can handle the Socialite callback yourself, match or create a user, and store the Apple subject identifier alongside email and password logins and other providers. Apple only returns name and email on first authorization, so capture and persist them during that initial callback before they disappear.
- How should I handle Apple private relay email addresses?
- Apple may return an @privaterelay.appleid.com address instead of the user's real email, which breaks naive email deduplication, verification mail flows, and marketing sync. Treat the Apple subject identifier as the primary key rather than the email, and allow a user to attach or update a real email later. Plan for the possibility that the subject may change after consent revocation, so reconciliation logic is your responsibility, not the package's.
- How do I handle Apple server notifications such as consent revocation and account deletion?
- The package ships a notification webhook controller that verifies Apple's signed payload JWT against Apple's public keys with a one-hour cache. What it does not do is the business response: deactivating, anonymizing, or deleting users when AppleAccessRevoked arrives is your application logic. Because App Store rules and privacy regulations make that response non-optional, wire it into your account lifecycle before launch.
- How can I test Sign in with Apple locally without a full Apple setup?
- You cannot complete a real Apple flow against localhost over HTTP, because Apple requires an exact registered HTTPS return URL with no query string or fragment, and the package throws InvalidRedirectUrlException on mismatches. Use a registered HTTPS tunnel or a staging Service ID for end-to-end checks, and fake the Socialite user or mock the driver in feature tests. Also add tests for the notification endpoint's JWT verification and for your user reconciliation logic.
- Is this package production-ready, actively maintained, and what alternatives exist?
- Adoption signal is thin: roughly 484 GitHub stars but no dependents, so you would be an early production integrator. It is single-maintainer and MIT licensed with a small surface area, so budget for the possibility of maintaining a fork. Alternatives include the community socialiteproviders/apple package with your own JWT client secret generation, or hand-rolling the OAuth flow; this package's main differentiator is generating and rotating the client secret inside PHP.
Weaver
How can I help you explore Laravel packages today?