Cada plataforma social tiene su propia implementación de OAuth, y coinciden más o menos en la forma general y en nada más. Esto es a lo que te apuntas, y lo que puedes evitar.
Lo que difiere por plataforma
Scopes. Nombres distintos, granularidad distinta, requisitos distintos. Pedir demasiados hace que tu aplicación sea rechazada en la revisión. Pedir demasiado pocos hace que una función deje de funcionar sin avisar.
Duración del token. Algunos tokens duran mucho tiempo. Algunos caducan en semanas. Algunos se pueden intercambiar por otros de mayor duración mediante una llamada aparte que tienes que conocer.
Comportamiento de renovación. Algunas emiten tokens de renovación, algunas exigen volver a autorizar, algunas rotan el token de renovación cada vez, así que guardar el antiguo rompe la siguiente renovación.
Revisión. Varias plataformas no conceden scopes de publicación hasta que han revisado tu aplicación, lo que puede implicar una política de privacidad, un vídeo de demostración y una espera. Ese es un tiempo de calendario que no controlas, y puede denegarse.
El modelo de cuenta. Un perfil personal, una página, una cuenta de empresa y un canal son objetos distintos con permisos distintos. Obtener un token no es lo mismo que saber a qué cuenta puedes realmente publicar.
La parte que realmente falla: la renovación
No el flujo inicial. El flujo inicial es un día de trabajo y ya está hecho.
Lo que falla en producción es la renovación, y falla en silencio:
- Un token caduca y la tarea de renovación falló hace tres días
- Nada muestra un error visible, porque nada intentó publicar hasta ahora
- Una publicación programada falla
- El usuario se entera antes que tú
Cualquier implementación real necesita una tarea de renovación programada, monitorización de fallos de renovación, una forma de marcar una conexión como rota y un aviso de reconexión en tu interfaz. Eso es más trabajo que el propio flujo de OAuth, y es la parte que las estimaciones dejan fuera.
Si lo construyes tú mismo
Cosas que merece la pena hacer desde el principio:
Guarda los tokens cifrados, y nunca los registres en logs. Son credenciales de la cuenta de otra persona.
Guarda la fecha de caducidad y renueva antes de que llegue, no cuando falle.
Gestiona la rotación. Si una plataforma rota los tokens de renovación, escribe el nuevo antes de usarlo, no después.
Modela una conexión rota como un estado real. No un error que capturas, sino un estado que el usuario puede ver y arreglar.
Espera tener que volver a autorizar. Los cambios de permisos y de política hacen que los usuarios tengan que reconectarse de vez en cuando, hagas lo que hagas.
Evitar la mayor parte
Si publicar es una función de tu producto y no el producto en sí, la alternativa es una sola integración donde el OAuth de la plataforma es problema de otro.
Dos modelos de autenticación, y elegir el correcto importa:
Clave de API, para actuar sobre tu propia cuenta. Servidor a servidor, sin flujo de consentimiento del usuario, lo más simple que funciona.
OAuth, para actuar en nombre de tus usuarios. Ellos aprueban tu aplicación y obtienes un token con scope limitado vinculado al espacio de trabajo que eligieron, en lugar de pedirles que peguen una credencial en tu producto.
Si tu producto es multiusuario, usa OAuth desde el principio. Pedir a los usuarios que peguen una clave de API es una migración que tendrás que hacer más adelante, y les enseña un hábito que no quieres.
Cómo funciona el OAuth de BulkPublish
- Endpoint de autorización:
https://app.bulkpublish.com/oauth/authorize - Endpoint de token:
https://app.bulkpublish.com/api/oauth/token - PKCE (S256) obligatorio para todos los clientes
scopees obligatorio, sin valor implícito por defecto- Los códigos de autorización son de un solo uso y los tokens de renovación rotan
- Los tokens se pasan como
Bearer bpat_...
Los scopes son granulares: posts:read, posts:write, media:read, media:write, analytics:read, channels:read, o full.
Un límite deliberado que conviene conocer: los tokens de OAuth llegan a posts, programaciones, etiquetas, medios, analíticas, uso de cuota y datos de canal de solo lectura, y nada más. La administración de la cuenta, es decir equipo, organizaciones, facturación, compras de créditos, claves de API y gestión de aplicaciones OAuth, devuelve 403 para cualquier token de OAuth incluido full. Esas acciones sobrevivirían a que un usuario desconecte tu aplicación, así que requieren una clave de API en su lugar.
Ese es el tipo de límite que conviene diseñar desde el principio en lugar de descubrirlo cuando aparece un 403 en producción.
La versión corta
El flujo de OAuth es un día por plataforma. La renovación de tokens es para siempre, y falla en silencio, por eso es la parte que realmente duele. Si publicar es una función y no tu producto, una integración con un proveedor elimina quince de estas. Usa OAuth en lugar de claves de API pegadas en cuanto entren en juego las cuentas de otras personas.