Cómo distinguir permisos delegados y de aplicación en una integración
La diferencia está en la identidad con la que se accede: un permiso delegado se usa en nombre de una persona autenticada; un permiso de aplicación permite actuar sin ella. Para evaluar una integración, comprueba el tipo real concedido y el recurso al que se aplica.
La diferencia está en la identidad con la que se accede: un permiso delegado se usa en nombre de una persona autenticada; un permiso de aplicación permite actuar sin ella. Para evaluar una integración, comprueba el tipo real concedido y el recurso al que se aplica.
Pregunta quién está presente cuando se ejecuta
Describe una operación concreta: consultar un documento al pulsar un botón o procesar registros durante la noche. Pregunta al proveedor qué identidad realiza esa llamada y cómo obtiene autorización. La interfaz no basta para saberlo: una aplicación con pantalla puede incluir también procesos de fondo.
Con acceso delegado deben estar autorizados tanto la aplicación como el usuario. El permiso concedido no permite superar el acceso que tiene esa persona. Con acceso de aplicación no hay un usuario conectado que aporte ese límite personal; el alcance lo determinan el permiso y los controles aplicables al recurso. Por eso debes revisar cada operación por separado.
No confundas consentimiento con tipo de permiso
Que un administrador haya aprobado una solicitud no la convierte en permiso de aplicación. También puede aprobar permisos delegados para la organización. Revisa el tipo, la API y el nombre exacto de cada concesión en lugar de deducirlo del mensaje de aprobación.
Tampoco equipares leer con modificar o enviar. Una integración puede tener permisos distintos para cada operación. Si el proveedor pide más de lo necesario, solicita que relacione cada permiso con una función y explique la alternativa más limitada. No propongas una cuenta con privilegios generales como sustituto de diseñar correctamente el acceso.
Valida el modelo con dos pruebas diferentes
Para un flujo delegado, prueba con una persona que tenga acceso al recurso y otra que no lo tenga. El segundo caso debe fallar como corresponde al diseño. Incluye recursos compartidos: el alcance de un usuario puede ser mayor que sus documentos personales.
Para un flujo de aplicación, verifica el recurso autorizado y otro excluido cuando exista una delimitación configurada. Identifica quién mantiene la identidad y cómo retirarás su autorización al terminar el servicio. Documenta resultados sin guardar tokens ni secretos. Una integración puede combinar ambos modelos; el inventario debe reflejarlo y el responsable de negocio debe aprobar el alcance de datos, aunque la prueba técnica sea correcta.
Comprobaciones para cerrar la tarea
- ✓ Anotar identidad, API y tipo para cada operación.
- ✓ Separar aprobación administrativa de acceso de aplicación.
- ✓ Probar usuarios con acceso diferente en flujos delegados.
- ✓ Verificar límites del recurso y retirada en flujos de aplicación.
Fuentes y documentación
- Permisos y consentimiento en la plataforma de identidad — Diferencia entre acceso delegado y acceso de aplicación.
- Escenario de acceso delegado — Aplicación que actúa en nombre de una persona autenticada.
- Escenario de acceso solo de aplicación — Identidad de aplicación sin usuario conectado.
Aplicarlo en tu empresa
Podemos revisar el entorno y acordar qué actuaciones, validaciones y mantenimiento necesitas.
Conocer el servicio relacionado →