Ce qu'est un token d'accès de Page Facebook, et pourquoi tout part d'une personne

Qu'est-ce qu'un token d'accès de Page Facebook ?

Meta définit le token d'accès de Page Facebook comme l'identifiant qui permet à une app d'agir en tant que Page plutôt qu'en tant que personne. Le guide des tokens d'accès le résume en une ligne : « Page access tokens let you read, write, and modify data belonging to a Facebook Page. » Publier sur le fil d'une Page, répondre aux commentaires au nom de la Page et lire les Page Insights reposent tous sur ce token.

Meta liste cinq types de tokens sur la même page, et le token de Page est le seul lié à une Page unique :

Le token de Page est aussi celui que la Pages API réclame nommément. La présentation de la Pages API par Meta indique « Most endpoints require Page access tokens », et le tableau des erreurs de la Pages API prévoit un code pour l'appel de l'un de ces endpoints avec autre chose : 190 avec le sous-code 2069032, « A Page access token is required for this call. »

Comment obtenir un token d'accès de Page ?

On obtient un token d'accès de Page en échange d'un token d'accès utilisateur. L'instruction de Meta tient en deux étapes : « To obtain one, first get a user access token, then exchange it for a Page access token via the Graph API. » Aucun endpoint ne délivre de token de Page à une app qui n'a pas d'abord fait se connecter une personne.

L'échange consiste en un seul GET sur l'edge accounts de la personne :

curl -i -X GET "https://graph.facebook.com/{your-user-id}/accounts?access_token={user-access-token}"

Meta indique que l'appel « returns a list of Pages you have a role on, including the Page category, your permissions on each Page, and the Page access token. » Chaque objet du tableau data contient access_token, category, category_list, name, id et un tableau tasks :

{
  "data": [
    {
      "access_token": "EAACEdE...",
      "category": "Brand",
      "name": "Ash Cat Page",
      "id": "1353269864728879",
      "tasks": ["ANALYZE", "ADVERTISE", "MODERATE", "CREATE_CONTENT", "MANAGE"]
    }
  ]
}

La présentation de la Pages API décrit le même flux en quatre étapes : obtenir un token d'accès utilisateur « through Facebook Login for Business », interroger /me/accounts, récupérer l'ID de Page et le token renvoyés, puis « use the ID and token to query the Page node ». Une seule connexion peut renvoyer plusieurs Pages. Meta demande alors aux développeurs de « capture each Page ID and its respective token », car chaque Page reçoit sa propre chaîne.

Pourquoi publier sur une Page d'entreprise exige-t-il une connexion Facebook personnelle ?

Publier sur une Page d'entreprise exige une connexion personnelle parce que le token de Page tient son autorité d'une personne. La présentation de Meta pose la condition : « In order to get a token from an app User, the app User must own or be able to perform a Task on the Page. » La Page elle-même ne se connecte jamais nulle part. C'est une personne ayant un rôle sur la Page qui se connecte, et le token garde la trace de cette personne.

Meta décrit ce lien de deux façons légèrement différentes sur deux pages en ligne. Le guide des tokens d'accès dit que les tokens de Page « are unique to each Page, admin, and app combination. » La présentation de la Pages API dit qu'ils sont « unique to each Page, app User, and app. » La lecture pratique reste la même dans les deux cas. Changez de Page, de personne ou d'app, et vous détenez un autre token. Si la personne qui a connecté la Page perd son rôle, les appels passés avec son token ne franchissent plus la vérification de tâche qui les laissait passer, l'une des causes détaillées dans pourquoi un outil de planification des réseaux sociaux se déconnecte sans cesse.

La seule voie qui évite une connexion personnelle est l'utilisateur système. La configuration Facebook Login for Business de Meta permet à une app de demander « a User access token or System-user access token ». Choisissez le token utilisateur et « your app users will log in using their personal Facebook account ». Choisissez le token d'utilisateur système et ils « will be required to log in using a business portfolio », ce qui, selon Meta, « is only required if this configuration needs continuous access to business assets, such as Facebook Pages ». Les tokens d'utilisateur système supposent que le portefeuille business possède la Page ou y ait un accès partagé. Ils conviennent donc aux agences et aux équipes internes équipées de Business Manager, et ne servent à rien à un créateur solo dont la Page dépend d'un profil personnel.

Quelles permissions un token d'accès de Page nécessite-t-il ?

Pour publier, un token d'accès de Page nécessite deux autorisations distinctes : des permissions que la personne approuve pour l'app, et une tâche que la personne détient sur la Page. Meta vérifie les deux. La présentation explique la seconde vérification : « we will first check if the User has been approved for a task that permits that type of action. »

Voici les permissions de Page qu'une intégration de publication demande, avec les descriptions de Meta tirées de la référence des permissions :

Les tâches renvoyées dans le tableau tasks correspondent à des actions. CREATE_CONTENT permet à une personne de « Publish content as the Page on the Page ». MODERATE couvre les réponses aux commentaires et leur suppression. ANALYZE couvre les Insights. MANAGE permet à une personne de « Assign and manage Page tasks ». Meta ajoute que « If a person is given Admin access to a Page in the UI, that person is able to perform all tasks on that Page. » Si l'app dispose de pages_manage_posts mais que la personne n'a pas CREATE_CONTENT, la Pages API renvoie 1 avec le sous-code 2853006, « Viewer doesn't have permission to perform this action. »

Les guides de Meta divergent sur un nom. Le guide Get Started de la Pages API liste quatre permissions pour une première publication : pages_manage_metadata, pages_manage_posts, pages_manage_read_engagement et pages_show_list. La référence des permissions ne contient aucune entrée nommée pages_manage_read_engagement. Le guide Manage a Page liste pages_read_engagement à la place, qui est aussi la dépendance que la référence indique pour pages_manage_posts. Demandez pages_read_engagement.

L'App Review vient s'ajouter à tout cela. La présentation indique : « All Page-related Permissions and Features require approval through the App Review process before your app can use them when your app goes live. » Les apps en mode développement peuvent demander n'importe quelle permission, mais uniquement auprès de personnes ayant un rôle sur l'app.

Un token d'accès de Page Facebook expire-t-il ?

Un token d'accès de Page Facebook expire au même rythme que le token utilisateur dont il est issu, jusqu'à ce que vous utilisiez un token utilisateur de longue durée. À partir de là, le token de Page n'a plus de date d'expiration. Les deux moitiés de cette règle viennent de Meta, sur des pages différentes.

La présentation de la Pages API ajoute une troisième affirmation qui n'entre pas dans le tableau. Elle dit que les tokens d'accès de Page « have an expiration time », sans réserve pour le cas longue durée. La page sur les tokens de longue durée dit l'inverse pour les tokens dérivés d'un token utilisateur de longue durée. Lisez la ligne de la présentation comme décrivant le token de courte durée par défaut, et vérifiez un vrai token avec debug_token avant de vous fier à l'une ou l'autre page. L'appel d'échange, la valeur expires_in de 5183944 et les champs de debug_token sont traités dans la note sur le token d'accès longue durée de Facebook et son compte à rebours de 60 jours.

L'absence de date d'expiration ne veut pas dire que le token est permanent. La mise en garde générale de Meta sur la durée de vie des tokens s'applique ici aussi. Elle dit « Do not depend on these lifetimes remaining the same », car « they may change without warning or expire early ». Le guide de débogage de Meta nomme les déclencheurs qu'il documente. Une personne qui « logged out of your app or changed their password » entraîne le code 190, sous-code 460, et une app que la personne a désautorisée entraîne le sous-code 458. L'un comme l'autre met fin à un token de Page qui n'a jamais eu de date.

Un token d'accès de Page change-t-il le fonctionnement des limites de débit ?

Oui. Les appels passés avec un token d'accès de Page sont décomptés sur une autre limite que ceux passés avec un token utilisateur. Meta mesure les requêtes de la Pages API faites avec un token de Page ou d'utilisateur système selon sa limite de débit business use case, Calls within 24 hours = 4800 * Number of Engaged Users, où les utilisateurs engagés sont les personnes « who engaged with the Page per 24 hours ». Les requêtes faites avec des tokens utilisateur ou d'app relèvent à la place de l'ancienne limite de débit de la plateforme. La formule et l'en-tête X-Business-Use-Case-Usage sont expliqués dans la note sur la limite de débit business use case de Meta pour les Pages.

Questions fréquentes

Quel endpoint renvoie un token d'accès de Page ?

GET /{user-id}/accounts, ou GET /me/accounts, appelé avec un token d'accès utilisateur. La réponse contient un objet par Page avec un access_token, name, id, category et les tasks que la personne peut effectuer sur cette Page.

Peut-on obtenir un token d'accès de Page sans compte Facebook personnel ?

Uniquement via un utilisateur système. Les configurations Facebook Login for Business de Meta peuvent demander un token d'utilisateur système, qui oblige les personnes à se connecter avec un portefeuille business. Ce portefeuille doit posséder la Page ou y avoir accès pour que cela fonctionne.

Le token d'accès de Page est-il le même pour tous les admins d'une Page ?

Non. Meta dit que les tokens d'accès de Page « are unique to each Page, admin, and app combination ». Deux admins qui connectent la même app à la même Page produisent deux tokens différents.

Pourquoi mon token de Page indique-t-il qu'il n'expire jamais alors qu'il a cessé de fonctionner ?

Meta dit que les tokens de Page de longue durée « only expire or are invalidated under certain conditions ». Son guide de débogage associe le sous-code 460 à une personne qui « logged out of your app or changed their password » et le sous-code 458 à une app que la personne n'autorise plus. Les deux mettent fin au token sans qu'aucune date ne soit atteinte.

Quelle permission permet à une app de publier sur une Page ?

pages_manage_posts, qui selon Meta permet à une app de « create, edit and delete your Page posts ». Elle dépend de pages_read_engagement et pages_show_list, et la personne a aussi besoin de la tâche CREATE_CONTENT sur la Page.

Quelle erreur obtient-on en appelant un endpoint de Page avec un token utilisateur ?

La Pages API renvoie le code 190 avec le sous-code 2069032 et le message « A Page access token is required for this call. » Remplacez-le par le token de Page issu de la réponse /accounts et relancez l'appel.

Quelle est la différence entre un token d'accès utilisateur et un token d'accès de Page ?

Un token d'accès utilisateur lit ou écrit « a person's Facebook data on their behalf », tandis qu'un token d'accès de Page lit, écrit et modifie « data belonging to a Facebook Page ». Vous obtenez le token utilisateur via une boîte de dialogue de connexion, et vous l'échangez contre le token de Page via /accounts. La plupart des endpoints de la Pages API exigent le token de Page.

Un token d'accès de Page nécessite-t-il l'App Review ?

Oui, avant que votre app soit mise en ligne. Meta indique que toutes les permissions et fonctionnalités liées aux Pages demandent alors une approbation via l'App Review. En mode développement, une app peut demander n'importe quelle permission, mais seulement auprès de personnes qui ont un rôle sur l'app.

Que devient un token de Page quand l'admin qui l'a connecté perd son rôle ?

Les appels de ce token ne passent plus la vérification des tâches qui les laissait passer. Les tokens de Page sont uniques pour chaque combinaison de Page, d'admin et d'app, donc le token appartient à cette personne. Si vous vous reconnectez avec quelqu'un qui a encore la bonne tâche, vous obtenez un autre token.

Comment vérifier qu'un token d'accès de Page est toujours valide ?

Passez-le dans debug_token et lisez le résultat, plutôt que de croire l'une ou l'autre des déclarations de Meta sur l'expiration. Cela vaut aussi pour les tokens sans date d'expiration, car une déconnexion, un changement de mot de passe ou une désautorisation peut y mettre fin.