For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/web/apple-sign-in.md (or send Accept: text/markdown).
Ajouter la connexion Apple
Enregistrez un App ID, un Services ID et une clé Sign in with Apple dans le portail Apple Developer, puis branchez la paire client dans l'app.
Parcours pas à pas pour débuter
Prérequis : l'app web qui tourne en local (En ligne en 5 minutes), une base de données migrée pour de vrais comptes (Configurer la base de données) et une adhésion au Apple Developer Program — le même compte à 99 $ par an que le guide des comptes mobiles fait ouvrir, donc terminez cette étape d'abord si ce n'est pas déjà fait. Tout ce qui se trouve dans le portail développeur ci-dessous ne coûte rien de plus.
Pourquoi c'est important : la révision de l'App Store exige Sign in with Apple dès qu'une app iOS propose une connexion sociale tierce comme Google ou GitHub — et c'est aussi un bouton solide et fluide sur le web : les utilisateurs Apple se connectent avec le compte déjà présent sur leurs appareils.
Quelques termes : un App ID est l'identifiant enregistré de votre app (com.yourcompany.yourapp). Un Services ID est un second identifiant qu'Apple délivre pour la connexion web et serveur — c'est lui qui devient votre client ID. Une return URL est l'adresse exacte vers laquelle Apple peut renvoyer un utilisateur connecté — le callback Better Auth du kit. Une secret key est le fichier .p8 qu'Apple vous donne une seule fois ; vous le transformez vous-même en client secret.
1. Enregistrez un App ID avec la capacité Sign in with Apple. 2. Enregistrez un Services ID qui pointe vers lui et qui contient votre domaine plus la return URL. 3. Créez une clé Sign in with Apple et téléchargez le fichier .p8. 4. Transformez la clé en JWT de client secret et renseignez les trois valeurs env.
Une limite honnête : les return URL d'Apple doivent être des adresses https:// absolues sur un domaine enregistré — localhost et le http simple sont rejetés, donc le bouton ne peut pas être testé à fond sur un serveur local nu. Vérifiez sur votre URL déployée, ou exposez le serveur local derrière un tunnel https (par exemple cloudflared tunnel ou ngrok) et enregistrez le domaine du tunnel plus son callback pendant vos tests.
Enregistrer l'App ID
1. Ouvrez developer.apple.com/account et connectez-vous avec le compte qui détient l'adhésion au Developer Program.
2. Ouvrez Certificates, Identifiers & Profiles → Identifiers et cliquez sur le bouton bleu +.
3. Sélectionnez App IDs → Continue, gardez le type App → Continue.
4. Description : le nom de votre produit. Bundle ID : choisissez Explicit et saisissez la forme en domaine inversé com.yourcompany.yourapp — si vous livrez l'app iOS, utilisez exactement le ios.bundleIdentifier de apps/mobile/app.json pour que les deux plateformes partagent un seul App ID.
5. Dans la liste des capacités, cochez Sign in with Apple → Continue → Register.
Attendu : l'identifiant apparaît dans la liste Identifiers avec la capacité Sign in with Apple activée. Réutilisez cet unique App ID — le Services ID et la clé s'y rattachent tous deux comme app principale.
Enregistrer le Services ID et la return URL
1. De retour dans Identifiers, cliquez à nouveau sur +, choisissez Services IDs → Continue.
2. Description : quelque chose comme yourapp web sign-in. Identifier : un autre nom en domaine inversé — la convention est com.yourcompany.yourapp.web — volontairement différent de l'App ID. Ce Services ID est le client ID que le serveur utilise pour la connexion web ; copiez-le exactement, puis Continue → Register.
3. Sélectionnez le nouveau Services ID dans la liste, cochez Sign in with Apple et cliquez sur Configure.
4. Dans la boîte de dialogue, réglez Primary App ID sur l'App ID de la section précédente. Sous Website URLs, ajoutez votre domaine (par exemple yourdomain.com), et sous Return URLs ajoutez https://yourdomain.com/api/auth/callback/apple — ce chemin est le callback Better Auth du kit, {APP_URL}/api/auth/callback/apple. Save → Continue → Save.
Chaque return URL doit être une adresse https:// absolue sur un domaine enregistré : localhost, les adresses IP nues et http sont rejetés. Pour le développement local, faites tourner l'app derrière un tunnel https, ajoutez le domaine du tunnel au Services ID, enregistrez https://<tunnel-domain>/api/auth/callback/apple et réglez APP_URL sur l'URL du tunnel pendant les tests.
Attendu : le Services ID affiche Sign in with Apple → Enabled. Si le portail rejette votre domaine, terminez d'abord la vérification de propriété du domaine sur la page du compte.
Créer la clé Sign in with Apple
1. Ouvrez Keys dans la barre latérale gauche → +. Nommez la clé (par exemple yourapp sign-in key), cochez Sign in with Apple, cliquez sur Configure, choisissez l'App ID comme Primary App ID → Save → Continue → Register.
2. Sur l'écran de confirmation, notez le Key ID, puis cliquez sur Download — le fichier .p8 n'est proposé qu'une seule fois. Si vous le perdez, révoquez la clé et créez-en une autre ; Apple n'en garde pas de copie.
3. Notez aussi votre Team ID — il est imprimé dans le coin supérieur droit des pages du compte développeur, à côté du nom de votre compte.
Attendu : vous détenez maintenant trois valeurs — le fichier .p8, un Key ID et votre Team ID. Gardez le fichier .p8 hors de Git : il signe en tant que votre compte développeur.
Ajouter les valeurs à l'app
Le kit attend exactement les trois lignes ci-dessous — la même paire clientId/clientSecret qu'utilise chaque fournisseur social. APPLE_CLIENT_ID est le Services ID (com.yourcompany.yourapp.web), pas l'App ID.
Apple ne délivre aucun client secret statique, donc APPLE_CLIENT_SECRET est un JWT que vous signez vous-même à partir du Team ID, du Key ID et de la clé privée .p8 — la documentation de Better Auth fournit le petit script générateur pour cela. Un secret signé reste valide au plus six mois : mettez un rappel pour le régénérer et mettre à jour la valeur env, car la connexion échoue dès qu'il expire. Ne collez jamais le contenu du fichier .p8 ni le Key ID brut dans l'env — seul le JWT généré y a sa place.
Le client secret et le fichier .p8 restent côté serveur : jamais dans des variables NEXT_PUBLIC_/EXPO_PUBLIC_ et jamais commités — en production, définissez-les via le coffre de secrets de votre hébergeur. Redémarrez le serveur de dev après modification ; les changements d'env ne sont lus qu'au démarrage.
# apps/web/.env.local
AUTH_APPLE_ENABLED=true
APPLE_CLIENT_ID=com.yourcompany.yourapp.web # the Services ID, not the App ID
APPLE_CLIENT_SECRET=<JWT signed with Team ID + Key ID + .p8>Vérifier et dépanner
Ouvrez votre APP_URL — une URL déployée ou le tunnel https — sur /auth, cliquez sur le bouton Apple, connectez-vous avec n'importe quel Apple ID (il n'est pas nécessaire que ce soit le compte développeur) et confirmez que vous revenez connecté.
La plupart des échecs tiennent à l'une de trois confusions : Services ID vs App ID — le client ID doit être le Services ID pour la connexion web ; une return URL qui ne correspond pas — le callback doit être exactement égal à une Return URL enregistrée, protocole, domaine et chemin compris ; ou un client secret expiré/invalide — régénérez le JWT, qui n'est qu'un jeton signé, pas le contenu du .p8.
Tant que AUTH_APPLE_ENABLED=true n'est pas défini, l'option Apple sur /auth reste désactivée — vérifiez les noms d'env et redémarrez. Activer le flag sans APPLE_CLIENT_ID et APPLE_CLIENT_SECRET fait échouer le démarrage et nomme la variable manquante.
L'app iOS atteint ce même backend — livrez-y Sign in with Apple pour que la révision de l'App Store accepte les autres boutons sociaux. Le guide des comptes mobiles explique ce que la révision recherche.
Pour poursuivre la configuration, consultez Ajouter les paiements Stripe.