Consentimiento OAuth: cuenta, nivel y permisos que ya no se conceden

14 de octubre de 2026

Hemos cambiado la pantalla en la que una persona autoriza a una aplicación a trabajar con Factuarea por OAuth (la que se abre en /oauth/authorize). No cambia ninguna operación de la API ni ninguna tool del MCP; cambia lo que esa pantalla te deja conceder.

Eliges cuenta y empresa. La pantalla lista tus empresas y las de las cuentas de tus clientes, cada una con la cuenta a la que pertenece y tu nivel de acceso, Ver u Operar. El acceso que concedes queda ligado a esa única empresa, igual que antes.
Con nivel Ver, solo lectura. Si llegas a la empresa con nivel Ver, la pantalla solo ofrece permisos de lectura: los que terminan en .read y el macro factuarea.read. Si una aplicación intenta confirmar escritura de todos modos, la respuesta es 403 invalid_scope con read_only_restricted_scopes. Antes la aplicación obtenía esos permisos y era cada llamada de escritura la que se rechazaba; ahora no llega a tenerlos.
En Pruebas, sin los módulos que el sandbox no ofrece. Los permisos de VeriFactu, el asistente de WhatsApp, el Vault de documentos, las integraciones de Stripe, GoCardless, Monei, Slack y Teams, los webhooks y las integraciones de tareas no se conceden en el entorno Pruebas (test); la confirmación responde 403 con sandbox_restricted_scopes. El selector ahora dice Producción · Pruebas.
La solicitud caduca. Tienes 5 minutos desde que se abre la pantalla, y ella misma te dice cuántos quedan.

Los tokens que ya se emitieron no se tocan. Si una aplicación tuya pedía escritura sobre una empresa con nivel Ver, no pierde nada que pudiera usar de verdad: esas llamadas ya fallaban. Lo único que cambia es que ahora lo sabe en el consentimiento y no al primer intento de escribir.

Los detalles están en conectar un cliente y en qué concede la pantalla según el nivel y el entorno.

Plug

Conectar un cliente MCP

ShieldCheck

Scopes y permisos