Cada rede social tem sua própria implementação de OAuth, e elas concordam mais ou menos no formato e em nada além disso. É nisso que você está se metendo, e é isso que dá para pular.
O que difere por plataforma
Escopos. Nomes diferentes, granularidade diferente, exigências diferentes. Pedir demais faz seu app ser rejeitado na revisão. Pedir de menos faz uma funcionalidade simplesmente não funcionar, em silêncio.
Duração do token. Alguns tokens duram bastante. Alguns expiram em semanas. Alguns podem ser trocados por outros de vida mais longa através de uma chamada separada que você precisa conhecer.
Comportamento de renovação. Algumas emitem tokens de renovação, algumas exigem reautorização, algumas rotacionam o token de renovação a cada uso, de modo que guardar o antigo quebra a próxima renovação.
Revisão. Várias plataformas não concedem escopos de publicação até revisar seu app, o que pode envolver uma política de privacidade, um vídeo de demonstração e uma espera. É tempo de calendário que você não controla, e pode ser recusado.
O modelo de conta. Um perfil pessoal, uma página, uma conta empresarial e um canal são objetos diferentes com permissões diferentes. Obter um token não é o mesmo que saber em qual conta você realmente pode publicar.
A parte que realmente quebra: a renovação
Não o fluxo inicial. O fluxo inicial é um dia de trabalho e depois está pronto.
O que quebra em produção é a renovação, e ela quebra em silêncio:
- Um token expira e o job de renovação falhou há três dias
- Nada gera erro visível, porque nada tentou publicar até agora
- Uma publicação agendada falha
- O usuário descobre antes de você
Qualquer implementação séria precisa de um job de renovação agendado, monitoramento de falhas de renovação, uma forma de marcar uma conexão como quebrada e um aviso de reconexão na sua interface. Isso é mais trabalho do que o próprio fluxo de OAuth, e é a parte que as estimativas deixam de fora.
Se você mesmo for construir
Coisas que vale a pena fazer desde o início:
Armazene os tokens criptografados, e nunca os registre em log. São credenciais para a conta de outra pessoa.
Armazene o vencimento e renove antes dele, não depois da falha.
Trate a rotação. Se uma plataforma rotaciona tokens de renovação, grave o novo antes de usá-lo, não depois.
Modele uma conexão quebrada como um estado real. Não um erro que você captura, um estado que o usuário pode ver e corrigir.
Espere a reautorização. Mudanças de permissão e atualizações de política significam que os usuários eventualmente vão precisar reconectar, independente do que você fizer.
Como evitar a maior parte disso
Se publicar é uma funcionalidade do seu produto, e não o produto em si, a alternativa é uma única integração em que o OAuth de cada plataforma é problema de outra pessoa.
Dois modelos de autenticação, e escolher o certo importa:
Chave de API, para agir na sua própria conta. Servidor para servidor, sem fluxo de consentimento do usuário, a coisa mais simples que funciona.
OAuth, para agir em nome dos seus usuários. Eles aprovam seu app e você recebe um token com escopo vinculado ao espaço de trabalho que eles escolheram, em vez de pedir que colem uma credencial no seu produto.
Se o seu produto é multiusuário, use OAuth desde o início. Pedir que os usuários colem uma chave de API é uma migração que você vai ter que fazer depois, e ensina um hábito que você não quer.
Como funciona o OAuth do BulkPublish
- Endpoint de autorização:
https://app.bulkpublish.com/oauth/authorize - Endpoint de token:
https://app.bulkpublish.com/api/oauth/token - PKCE (S256) obrigatório para todo cliente
scopeé obrigatório, sem padrão implícito- Códigos de autorização são de uso único e os tokens de renovação rotacionam
- Tokens são enviados como
Bearer bpat_...
Os escopos são granulares: posts:read, posts:write, media:read, media:write, analytics:read, channels:read, ou full.
Um limite deliberado que vale a pena conhecer: tokens OAuth alcançam publicações, agendamentos, etiquetas, mídia, análises, uso de cota e dados de canal somente leitura, e nada além disso. Administração de conta, ou seja, equipe, organizações, faturamento, compra de créditos, chaves de API e gestão de apps OAuth, retorna 403 para qualquer token OAuth, incluindo full. Essas ações sobreviveriam a um usuário desconectando seu app, então exigem uma chave de API em vez disso.
Esse é o tipo de limite que vale a pena projetar com antecedência, em vez de descobrir quando um 403 aparece em produção.
O resumo
O fluxo de OAuth é um dia por plataforma. A renovação de token é para sempre, e falha em silêncio, o que é por que é a parte que realmente dói. Se publicar é uma funcionalidade e não o seu produto, uma integração com um provedor elimina quinze dessas. Use OAuth em vez de chaves de API coladas no momento em que contas de outras pessoas entram em jogo.