Ogni piattaforma social ha la propria implementazione OAuth, e concordano più o meno sulla forma e su nient’altro. Ecco a che cosa ti stai iscrivendo, e che cosa puoi saltare.
Che cosa cambia per piattaforma
Scope. Nomi diversi, granularità diversa, requisiti diversi. Chiederne troppi fa respingere la tua app in fase di revisione. Chiederne troppo pochi fa sì che una funzione non funzioni silenziosamente.
Durata del token. Alcuni token durano a lungo. Alcuni scadono in poche settimane. Alcuni possono essere scambiati con token più duraturi tramite una chiamata separata che devi conoscere.
Comportamento del refresh. Alcune piattaforme emettono refresh token, alcune richiedono una nuova autorizzazione, alcune ruotano il refresh token a ogni utilizzo, per cui conservare quello vecchio rompe il refresh successivo.
Revisione. Diverse piattaforme non concedono gli scope di pubblicazione finché non hanno revisionato la tua app, il che può richiedere un’informativa sulla privacy, un video dimostrativo e un’attesa. È tempo di calendario che non controlli, e può anche essere rifiutata.
Il modello di account. Un profilo personale, una pagina, un account business e un canale sono oggetti diversi con permessi diversi. Ottenere un token non equivale a sapere su quale account puoi effettivamente pubblicare.
La parte che si rompe davvero: il refresh
Non il flusso iniziale. Il flusso iniziale è una giornata di lavoro e poi è fatto.
Quello che si rompe in produzione è il refresh, e si rompe silenziosamente:
- Un token scade e il job di refresh è fallito tre giorni fa
- Non compare nessun errore visibile, perché nessuno ha provato a pubblicare fino a ora
- Un post programmato fallisce
- L’utente lo scopre prima di te
Qualsiasi implementazione seria richiede un job di refresh programmato, un monitoraggio dei fallimenti di refresh, un modo per segnare una connessione come interrotta e un prompt di riconnessione nella tua interfaccia. È più lavoro del flusso OAuth stesso, ed è la parte che le stime lasciano fuori.
Se lo costruisci da solo
Cose che vale la pena fare fin dall’inizio:
Conserva i token cifrati, e non registrarli mai nei log. Sono credenziali dell’account di qualcun altro.
Conserva la scadenza e fai il refresh in anticipo, non dopo un fallimento.
Gestisci la rotazione. Se una piattaforma ruota i refresh token, scrivi quello nuovo prima di usarlo, non dopo.
Modella una connessione interrotta come uno stato reale. Non un errore che intercetti, ma uno stato che un utente può vedere e correggere.
Aspettati la nuova autorizzazione. Cambi di permessi e aggiornamenti delle policy fanno sì che gli utenti debbano occasionalmente riconnettersi, a prescindere da quello che fai.
Come evitarne la maggior parte
Se la pubblicazione è una funzione del tuo prodotto e non il prodotto stesso, l’alternativa è un’unica integrazione in cui l’OAuth delle piattaforme diventa un problema di qualcun altro.
Due modelli di autenticazione, e scegliere quello giusto conta:
Chiave API, per agire sul proprio account. Server-to-server, nessun flusso di consenso dell’utente, la cosa più semplice che funzioni.
OAuth, per agire per conto dei tuoi utenti. Approvano la tua app e ottieni un token con scope limitato legato allo spazio di lavoro che hanno scelto, invece di chiedere loro di incollare una credenziale nel tuo prodotto.
Se il tuo prodotto è multiutente, usa OAuth fin dall’inizio. Chiedere agli utenti di incollare una chiave API è una migrazione che dovrai fare più avanti, e insegna loro un’abitudine che non vuoi.
Come funziona l’OAuth di BulkPublish
- Endpoint di autorizzazione:
https://app.bulkpublish.com/oauth/authorize - Endpoint del token:
https://app.bulkpublish.com/api/oauth/token - PKCE (S256) obbligatorio per ogni client
scopeè obbligatorio, senza alcun valore predefinito implicito- I codici di autorizzazione sono monouso e i refresh token ruotano
- I token vengono passati come
Bearer bpat_...
Gli scope sono granulari: posts:read, posts:write, media:read, media:write, analytics:read, channels:read, oppure full.
Un confine deliberato che vale la pena conoscere: i token OAuth arrivano a post, programmazioni, etichette, materiale multimediale, analitiche, utilizzo della quota e dati di canale in sola lettura, e a nient’altro. L’amministrazione dell’account, cioè team, organizzazioni, fatturazione, acquisto di crediti, chiavi API e gestione delle app OAuth, restituisce 403 per qualsiasi token OAuth, incluso full. Queste azioni sopravviverebbero alla disconnessione della tua app da parte di un utente, quindi richiedono invece una chiave API.
È il genere di limite che vale la pena progettare in anticipo, invece di scoprirlo quando un 403 compare in produzione.
In sintesi
Il flusso OAuth è una giornata per piattaforma. Il refresh dei token è per sempre, e fallisce silenziosamente, ed è per questo che è la parte che fa davvero male. Se la pubblicazione è una funzione e non il tuo prodotto, un’unica integrazione con un fornitore ne elimina quindici. Usa OAuth invece delle chiavi API incollate nel momento in cui sono coinvolti account di altre persone.