Elk sociaal platform heeft zijn eigen OAuth-implementatie, en ze zijn het ongeveer eens over de vorm en verder over niets. Dit is waar je je op inschrijft, en wat je kunt overslaan.
Wat per platform verschilt
Scopes. Andere namen, andere granulariteit, andere vereisten. Te veel vragen zorgt dat je app wordt afgewezen bij review. Te weinig vragen betekent dat een functie stilletjes niet werkt.
Levensduur van tokens. Sommige tokens gaan lang mee. Sommige verlopen in weken. Sommige zijn inwisselbaar voor langer geldige via een aparte call die je moet kennen.
Verversingsgedrag. Sommige geven refresh tokens uit, sommige vereisen herautorisatie, sommige roteren het refresh token elke keer, waardoor het oude opslaan de volgende verversing breekt.
Review. Verschillende platforms verlenen geen publicatiescopes voordat ze je app hebben beoordeeld, wat een privacybeleid, een demovideo en wachttijd kan inhouden. Dat is kalendertijd die je niet in de hand hebt, en het kan worden geweigerd.
Het accountmodel. Een persoonlijk profiel, een pagina, een zakelijk account en een kanaal zijn verschillende objecten met verschillende rechten. Een token krijgen is niet hetzelfde als weten naar welk account je daadwerkelijk kunt posten.
Het onderdeel dat echt breekt: verversing
Niet de initiële flow. De initiële flow is een dag werk en dan is het klaar.
Wat in productie breekt, is verversing, en het breekt stilletjes:
- Een token verloopt en de verversingstaak faalde drie dagen geleden
- Er verschijnt geen zichtbare fout, want er is tot nu toe niets gepubliceerd
- Een geplande post mislukt
- De gebruiker komt er eerder achter dan jij
Elke echte implementatie heeft een geplande verversingstaak nodig, monitoring op verversingsfouten, een manier om een verbinding als kapot te markeren, en een herverbindingsprompt in je interface. Dat is meer werk dan de OAuth-flow zelf en het is het onderdeel dat schattingen weglaten.
Als je het zelf bouwt
Dingen die het waard zijn om vanaf het begin te doen:
Sla tokens versleuteld op en log ze nooit. Het zijn credentials voor het account van iemand anders.
Sla de vervaldatum op en vernieuw vooraf, niet pas bij falen.
Handel rotatie af. Als een platform refresh tokens roteert, schrijf het nieuwe weg voordat je het gebruikt, niet erna.
Modelleer een kapotte verbinding als een echte status. Geen fout die je opvangt, een status die een gebruiker kan zien en oplossen.
Verwacht herautorisatie. Rechtenwijzigingen en beleidsupdates betekenen dat gebruikers af en toe opnieuw moeten verbinden, wat je ook doet.
Het grootste deel vermijden
Als publiceren een functie van je product is in plaats van het product zelf, is het alternatief één integratie waarbij de platform-OAuth het probleem van iemand anders is.
Twee auth-modellen, en de juiste kiezen doet ertoe:
API-key, voor handelen op je eigen account. Server-naar-server, geen toestemmingsflow voor gebruikers, het simpelste dat werkt.
OAuth, voor handelen namens je gebruikers. Zij keuren jouw app goed en jij krijgt een scoped token gebonden aan de workspace die zij kozen, in plaats van hen te vragen een credential in je product te plakken.
Als je product multi-user is, gebruik dan OAuth vanaf het begin. Gebruikers vragen een API-key te plakken, is een migratie die je later alsnog moet doen, en het leert ze een gewoonte die je niet wilt.
Hoe de OAuth van BulkPublish werkt
- Autorisatie-endpoint:
https://app.bulkpublish.com/oauth/authorize - Token-endpoint:
https://app.bulkpublish.com/api/oauth/token - PKCE (S256) verplicht voor elke client
scopeis verplicht, zonder impliciete standaard- Autorisatiecodes zijn eenmalig te gebruiken en refresh tokens roteren
- Tokens worden meegegeven als
Bearer bpat_...
Scopes zijn granulair: posts:read, posts:write, media:read, media:write, analytics:read, channels:read, of full.
Eén bewuste grens die de moeite waard is om te kennen: OAuth-tokens reiken tot posts, schedules, labels, media, analytics, quotagebruik en alleen-lezen kanaaldata, en verder niets. Accountbeheer, oftewel team, organisaties, facturering, creditaankopen, API-keys en OAuth-appbeheer, geeft 403 voor elk OAuth-token inclusief full. Die acties zouden het loskoppelen van je app door een gebruiker overleven, dus daarvoor is een API-key vereist.
Dat is het soort grens dat het waard is er vroeg omheen te ontwerpen in plaats van te ontdekken wanneer een 403 in productie opduikt.
De korte versie
De OAuth-flow is een dag per platform. Tokenverversing is voor altijd, en het faalt stilletjes, waarom het het onderdeel is dat echt pijn doet. Als publiceren een functie is in plaats van je product, verwijdert één integratie met een provider vijftien van deze. Gebruik OAuth in plaats van geplakte API-keys zodra andermans accounts erbij betrokken raken.