Chaque intégration de notification push iOS commence à la même porte : prouver au service de notification push Apple que vous êtes autorisé à envoyer des messages aux utilisateurs de votre application. Apple vous offre deux moyens de le faire — une clé d'authentification APNs (.p8) ou un certificat APNs (.p12) — et la différence entre les deux est la différence entre une identification que vous configurez une fois et une autre que vous devrez renouveler chaque année, souvent au pire moment possible.
Ce guide explique comment fonctionne réellement l'authentification APNs, quand utiliser une clé .p8 par rapport à un certificat .p12, et la poignée d'erreurs qui remontent à une mauvaise configuration.
Comment fonctionne l'authentification APNs
Lorsque votre fournisseur de notifications push — PushEngage, ou votre propre serveur — envoie une notification, il se connecte à l'API du fournisseur APNs d'Apple et doit prouver deux choses : qu'il est autorisé à envoyer en votre nom, et qu'il est autorisé à cibler l'identifiant de regroupement de votre application (le « sujet » en termes APNs). La clé .p8 et le certificat .p12 ne sont que deux manières différentes de le prouver.
Le côté appareil est séparé. Votre application s'enregistre auprès d'APNs et reçoit un jeton d'appareil — cette partie ne change jamais, quel que soit le certificat utilisé par votre fournisseur. L'authentification est purement une préoccupation serveur-à-Apple, c'est pourquoi vous pouvez changer de méthode sans toucher au binaire de votre application.
La clé d'authentification .p8 (utilisez celle-ci)
Le .p8 est une clé de signature de jeton. Votre fournisseur l'utilise pour générer des jetons Web JSON de courte durée qui authentifient chaque connexion à APNs. Ses propriétés en font le choix par défaut pour presque tout le monde :
- Elle n'expire jamais. Pas de renouvellement annuel, pas d'interruption des notifications à une date oubliée.
- Une clé couvre toutes les applications de votre compte développeur. Lancez une deuxième application et la même clé l'authentifiera.
- Elle fonctionne pour les environnements de développement et de production — pas de paires de certificats sandbox/production.
- Elle se compose de trois valeurs : le fichier .p8 lui-même, l'ID de clé de 10 caractères, et votre ID d'équipe.
Deux choses à savoir avant d'en créer une. Apple vous limite à deux clés APNs actives par compte, donc les grandes organisations devraient considérer la création de clés comme un acte délibéré, et non une habitude par projet. Et le fichier .p8 ne peut être téléchargé qu'une seule fois, au moment de sa création — stockez-le dans un endroit où votre équipe pourra le trouver, car Apple ne vous le donnera plus.
Le certificat .p12 (le chemin hérité)
Le .p12 est un certificat client TLS, exporté de Trousseau d'accès après qu'Apple l'ait émis. Il authentifie la connexion elle-même plutôt que de signer des jetons. Il fonctionne toujours, et certaines politiques de sécurité d'entreprise l'exigent encore, mais ses contraintes sont la raison pour laquelle Apple oriente les nouvelles intégrations vers la clé :
- Il expire chaque année. La cause la plus fréquente d'échec soudain et total des notifications push est un certificat APNs qui a discrètement expiré.
- Il est limité à une seule application. Chaque ID de bundle nécessite son propre certificat, et chaque certificat nécessite son propre calendrier de renouvellement.
- Il nécessite un Mac. La procédure d'exportation de la demande de signature et du trousseau n'a pas de chemin d'accès uniquement via le navigateur.
Lequel devriez-vous utiliser ?
| Clé d'authentification .p8 | Certificat .p12 | |
|---|---|---|
| Expire | Jamais | Tous les 12 mois |
| Portée | Toutes les applications du compte | Un ID de bundle |
| Environnements | Développement + production | Séparé ou combiné par certificat |
| Créé à partir de | N'importe quel navigateur | Mac avec Trousseau d'accès |
| Limite du compte | 2 clés actives | Paires par application |
| Utiliser quand | Presque toujours | La politique exige des certificats |
La réponse honnête : utilisez la clé .p8 à moins qu'une politique de sécurité ne force le chemin du certificat. Moins de pièces mobiles, rien à renouveler, une seule identification pour l'ensemble de votre portefeuille.
Créer une clé .p8 en trois minutes
- Dans votre compte Apple Developer, allez dans Certificats, Identifiants et Profils → Clés et enregistrez une nouvelle clé.
- Nommez-la, cochez la case Apple Push Notifications service (APNs), et continuez.
- Téléchargez le fichier .p8 (rappelez-vous : une seule chance), et notez l'ID de clé affiché sur l'écran de confirmation et votre ID d'équipe depuis la page d'adhésion au compte.
- Téléchargez les trois valeurs auprès de votre fournisseur de push. Dans PushEngage, il s'agit d'un seul écran dans les paramètres de votre application — le guide des identifiants APNs vous accompagne avec des captures d'écran.
Les erreurs que cela explique
Une part surprenante des tickets « push est cassé » concerne des problèmes d'identification déguisés. Les coupables habituels :
- BadDeviceToken — vous envoyez le token d'une application créée en sandbox via l'environnement de production, ou vice versa. Les builds de débogage d'Xcode communiquent avec la sandbox ; les builds TestFlight et App Store communiquent avec la production.
- TopicDisallowed — l'identification ne couvre pas l'ID de bundle que vous ciblez. Typique avec les certificats .p12 par application et une configuration copiée-collée.
- Échec soudain de livraison à 100 % — un .p12 expiré. Vérifiez la date d'expiration du certificat avant de vérifier quoi que ce soit d'autre.
- InvalidProviderToken — une clé .p8 révoquée, ou la mauvaise paire Key ID/Team ID associée à un fichier valide.
Où cela s'intègre dans votre intégration
L'identification APNs est la première étape d'une seule session de configuration. Téléchargez le .p8 sur PushEngage une fois, et tout ce qui suit — l'intégration iOS SDK 1.0, les médias riches via votre extension de notification, les campagnes déclenchées, et la livraison elle-même — s'exécute sans autre cérémonie. Si vous venez de Firebase, la même clé que vous avez donnée à FCM fonctionne ici, ce qui explique en partie pourquoi migrer de FCM sur iOS est un projet d'après-midi.
Pour la couche stratégie qui suit la configuration, commencez par le guide de marketing push pour applications. Et lorsque vous êtes prêt à envoyer, le guide de configuration complet pour iOS vous accompagne de l'identification à la première campagne en moins d'une heure.
