Comment ajouter Apple Sign-In à React Native sans perdre la raison

Si vous avez déjà déployé une application mobile avec Google ou une connexion sociale sur l'App Store, vous avez probablement rencontré la règle stricte des examinateurs : si vous ajoutez une connexion tierce, vous devez également inclure Sign In with Apple. Sinon, le rejet arrive plus vite qu'un build de release ne finit de compiler.

La tâche semble simple au départ. Mais une fois que vous commencez à creuser dans les appels natifs, les bizarreries du simulateur et les excentricités de l'API d'Apple, une multitude de pièges apparaissent. L'équipe d'Invertase (les mêmes personnes derrière React Native Firebase) a créé une bibliothèque appelée react-native-apple-authentication qui gère cela pour iOS et Android.

Ce qui se cache sous le capot et pourquoi vous en avez besoin

La bibliothèque offre un accès complet au mécanisme d'authentification d'Apple. Elle fonctionne sur React Native vanilla à partir de la version 0.60, s'intègre bien avec Expo (via prebuild et configuration des entitlements en app.json), prend en charge macOS, et peut même authentifier les utilisateurs Android via le flux du navigateur.

Le meilleur est que les définitions TypeScript prêtes à l'emploi et le composant de bouton natif tout fait AppleButton sont inclus. La conception du bouton est strictement réglementée par les directives d'Apple. Si vous le dessinez vous-même, les examinateurs rejetteront joyeusement votre application. Ici, les styles et la localisation sont tirés directement du système natif.

Comment fonctionne le flux iOS de base

L'installation est standard : installez le package via yarn ou npm, puis exécutez pod install dans le dossier ios. Le module prend en charge l'autolinking, donc vous n'aurez pas besoin de fouiller dans AppDelegate.

Pour le bouton et la logique de connexion, vous n'avez besoin que de quelques imports :

import React from 'react';
import { View } from 'react-native';
import { AppleButton, appleAuth } from '@invertase/react-native-apple-authentication';

export function LoginScreen() {
  async function handleAppleLogin() {
    // Запускаем нативный запрос авторизации
    const authResponse = await appleAuth.performRequest({
      requestedOperation: appleAuth.Operation.LOGIN,
      // Порядок скоупов имеет значение
      requestedScopes: [appleAuth.Scope.FULL_NAME, appleAuth.Scope.EMAIL],
    });

    // Проверяем статус пользователя
    const credentialState = await appleAuth.getCredentialStateForUser(authResponse.user);

    if (credentialState === appleAuth.State.AUTHORIZED) {
      // Пользователь подтвержден, отправляем токены на бэкенд
      console.log('User ID:', authResponse.user);
      console.log('Identity Token:', authResponse.identityToken);
    }
  }

  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <AppleButton
        buttonStyle={AppleButton.Style.BLACK}
        buttonType={AppleButton.Type.SIGN_IN}
        style={{ width: 200, height: 45 }}
        onPress={handleAppleLogin}
      />
    </View>
  );
}

Les pièges sur lesquels trébuchent tous les débutants

L'autorisation d'Apple présente des bizarreries non évidentes qu'il vaut mieux connaître avant de se retrouver à déboguer jusqu'à 3h du matin.

Le nom et l'email ne sont transmis qu'une seule fois

Apple est obsédée par la vie privée. Lors de la première connexion, l'utilisateur peut choisir de masquer son vrai email ou de le partager. Les données du profil (fullName fullName et email email) sont retournées par le framework natif exactement une fois — lors de la toute première autorisation réussie.

Lors des appels suivants, ces champs reviennent vides (null null). Si vous n'avez pas enregistré le nom et l'email dans votre base de données immédiatement, vous ne pouvez pas les récupérer à nouveau via l'API client.

Pour réinitialiser l'état de test sur un iPhone et recevoir à nouveau le profil, vous devez aller manuellement dans les paramètres système : Réglages → [Votre Nom] → Mot de passe et sécurité → Identifiants Apple ID 11, supprimer votre application de test ici, et vous reconnecter.

D'ailleurs, le repo du projet note spécifiquement un bug dans l'API elle-même d'Apple : les scopes doivent être passés dans un ordre précis 12. Si vous les inversez, le nom peut disparaître dès la première requête.

Simulateurs et erreur 1000

La méthode currentUser 13 vérifie l'authenticité de l'appareil. Sur les simulateurs iOS, elle plante régulièrement avec l'erreur 1000 14. Vous ne pouvez tester complètement la chaîne d'autorisation que sur un appareil physique.

Si le simulateur est complètement bloqué sur cette erreur, les développeurs recommandent d'aller sur le site web de gestion des identifiants Apple, de trouver la liste des appareils associés, et de supprimer le simulateur de votre compte.

La déconnexion est une illusion

Les enums du module incluent une opération de déconnexion 15, mais en pratique le SDK iOS natif n'en fait rien. Apple ne fournit pas de moyen pour forcer la déconnexion au niveau du système sur l'appareil. La déconnexion côté client signifie simplement effacer votre session locale, les jetons sauvegardés, et vider l'état de l'application.

Révoquer l'accès

Les utilisateurs peuvent à tout moment aller dans les paramètres iOS et révoquer la permission de votre application à se connecter. Pour réagir à temps et renvoyer l'utilisateur vers l'écran de connexion, la bibliothèque fournit un écouteur d'événements :

useEffect(() => {
  const unsubscribe = appleAuth.onCredentialRevoked(async () => {
    // Токены больше не валидны, сбрасываем локальное состояние
    console.warn('Доступ отозван пользователем в настройках Apple ID');
  });

  return () => unsubscribe();
}, []);

Et Android alors

Beaucoup sont surpris, mais vous pouvez également laisser les utilisateurs Android se connecter avec Apple ID. La mécanique est différente ici : au lieu d'un framework natif, une fenêtre de navigateur protégée s'ouvre via le flux Web OAuth 2.0.

La bibliothèque gère la routine via le module ASWebAuthenticationSession 16 :

import { appleAuthAndroid } from '@invertase/react-native-apple-authentication';
import 'react-native-get-random-values';
import { v4 as uuid } from 'uuid';

async function handleAndroidAppleLogin() {
  const rawNonce = uuid();
  const state = uuid();

  appleAuthAndroid.configure({
    clientId: 'com.example.client-android', // Service ID из консоли Apple Developer
    redirectUri: 'https://example.com/auth/callback',
    responseType: appleAuthAndroid.ResponseType.ALL,
    scope: appleAuthAndroid.Scope.ALL,
    nonce: rawNonce,
    state,
  });

  const response = await appleAuthAndroid.signIn();
  // Отправляем response.code и response.id_token на сервер
}

Pour Android, vous devrez configurer un Service ID dans Apple Developer Console et spécifier une URL de redirection. La règle principale : le lien de redirection doit correspondre caractère pour caractère à ce qui est entré dans la console développeur — aucun paramètre de requête n'est autorisé.

Validation côté serveur

Ne faites jamais confiance aveuglément au nonce côté client 17. Le client reçoit identityToken 18 (un JWT signé). Sur le serveur, vous le décodez, vérifiez la signature avec les clés publiques d'Apple, et vérifiez le nonce 19.

Le module calcule automatiquement le hash SHA256 du nonce passé 20 avant de l'envoyer à Apple (similaire à ce que fait Firebase Auth). Gardez cela à l'esprit côté backend : vous devez comparer la valeur hashée.

Si votre objectif est de satisfaire rapidement aux exigences de l'App Store Review ou de proposer aux utilisateurs une connexion en un tap via Face ID, la bibliothèque Invertase est le choix le plus fiable dans l'écosystème React Native. Elle vous évite d'écrire votre propre bridge natif en Swift/Objective-C, gère proprement le style des boutons, et est régulièrement mise à jour par les mainteneurs. Installez-la, configurez les certificats dans Apple Developer Console, paramétrez le gestionnaire — et votre release est prête à être soumise.