Chaque plateforme sociale a sa propre implémentation OAuth, et elles s’accordent à peu près sur la forme générale et sur rien d’autre. Voici ce à quoi vous vous engagez, et ce que vous pouvez éviter.
Ce qui diffère selon la plateforme
Les scopes. Des noms différents, une granularité différente, des exigences différentes. En demander trop fait rejeter votre application en revue. En demander trop peu fait qu’une fonctionnalité ne marche silencieusement pas.
La durée de vie du jeton. Certains jetons durent longtemps. Certains expirent en quelques semaines. Certains peuvent être échangés contre des jetons de plus longue durée via un appel séparé qu’il faut connaître.
Le comportement de rafraîchissement. Certaines plateformes délivrent des refresh tokens, certaines exigent une nouvelle autorisation, certaines font tourner le refresh token à chaque fois, si bien que conserver l’ancien casse le prochain rafraîchissement.
La revue. Plusieurs plateformes n’accordent les scopes de publication qu’après avoir passé en revue votre application, ce qui peut impliquer une politique de confidentialité, une vidéo de démonstration et une attente. C’est du temps calendaire que vous ne contrôlez pas, et cela peut être refusé.
Le modèle de compte. Un profil personnel, une page, un compte professionnel et une chaîne sont des objets différents avec des permissions différentes. Obtenir un jeton n’équivaut pas à savoir sur quel compte vous pouvez réellement publier.
Ce qui casse vraiment : le rafraîchissement
Pas le flux initial. Le flux initial représente une journée de travail, puis c’est terminé.
Ce qui casse en production, c’est le rafraîchissement, et cela casse silencieusement :
- Un jeton expire et le job de rafraîchissement a échoué il y a trois jours
- Rien n’affiche d’erreur visible, parce que rien n’a essayé de publier jusqu’à maintenant
- Une publication programmée échoue
- L’utilisateur le découvre avant vous
Toute implémentation sérieuse a besoin d’un job de rafraîchissement programmé, d’une surveillance des échecs de rafraîchissement, d’un moyen de marquer une connexion comme rompue, et d’une invite de reconnexion dans votre interface. C’est plus de travail que le flux OAuth lui-même, et c’est la partie que les estimations oublient.
Si vous le construisez vous-même
Ce qui vaut la peine d’être fait dès le départ :
Stockez les jetons chiffrés, et ne les journalisez jamais. Ce sont des identifiants vers le compte de quelqu’un d’autre.
Stockez l’expiration et rafraîchissez en amont, pas après l’échec.
Gérez la rotation. Si une plateforme fait tourner les refresh tokens, écrivez le nouveau avant de l’utiliser, pas après.
Modélisez une connexion rompue comme un vrai état. Pas une erreur que vous rattrapez, un état que l’utilisateur peut voir et corriger.
Attendez-vous à une nouvelle autorisation. Les changements de permissions et les mises à jour de politique feront que les utilisateurs devront occasionnellement se reconnecter, quoi que vous fassiez.
Éviter la majeure partie de tout cela
Si la publication est une fonctionnalité de votre produit plutôt que le produit lui-même, l’alternative est une seule intégration où l’OAuth des plateformes devient le problème de quelqu’un d’autre.
Deux modèles d’authentification, et bien choisir compte :
Clé API, pour agir sur votre propre compte. Serveur à serveur, aucun flux de consentement utilisateur, la chose la plus simple qui fonctionne.
OAuth, pour agir au nom de vos utilisateurs. Ils approuvent votre application et vous obtenez un jeton limité en portée lié à l’espace de travail qu’ils ont choisi, plutôt que de leur demander de coller un identifiant dans votre produit.
Si votre produit est multi-utilisateur, utilisez OAuth dès le départ. Demander aux utilisateurs de coller une clé API est une migration que vous devrez faire plus tard, et cela leur apprend une habitude que vous ne voulez pas.
Comment fonctionne l’OAuth de BulkPublish
- Point de terminaison d’autorisation :
https://app.bulkpublish.com/oauth/authorize - Point de terminaison de jeton :
https://app.bulkpublish.com/api/oauth/token - PKCE (S256) requis pour chaque client
scopeest requis, sans valeur par défaut implicite- Les codes d’autorisation sont à usage unique et les refresh tokens tournent
- Les jetons sont transmis sous la forme
Bearer bpat_...
Les scopes sont granulaires : posts:read, posts:write, media:read, media:write, analytics:read, channels:read, ou full.
Une limite délibérée à connaître : les jetons OAuth accèdent aux publications, aux plannings, aux labels, aux médias, aux analyses, à l’usage du quota et aux données de canal en lecture seule, et à rien d’autre. L’administration du compte, c’est-à-dire l’équipe, les organisations, la facturation, les achats de crédits, les clés API et la gestion des applications OAuth, renvoie 403 pour tout jeton OAuth, y compris full. Ces actions survivraient à la déconnexion de votre application par un utilisateur, elles exigent donc une clé API à la place.
C’est le genre de limite qu’il vaut mieux concevoir tôt plutôt que découvrir quand un 403 apparaît en production.
En résumé
Le flux OAuth représente une journée par plateforme. Le rafraîchissement de jeton, lui, dure éternellement, et il échoue silencieusement, ce qui en fait la partie qui fait vraiment mal. Si la publication est une fonctionnalité plutôt que votre produit, une seule intégration avec un fournisseur en supprime quinze. Utilisez OAuth plutôt que des clés API collées dès que les comptes d’autres personnes entrent en jeu.