Permitir que una persona gestione tareas en nombre de otra puede resolver una necesidad real de negocio, pero no debería implicar compartir contraseñas ni conceder acceso general a la cuenta. En una aplicación PHP, una delegación segura tiene que dejar claro quién actúa, a quién representa, sobre qué recursos puede intervenir y durante cuánto tiempo. También debe poder revocarse y auditarse.
El objetivo es autorizar una acción concreta conservando la identidad de ambas personas. Esto exige algo más que una pantalla para conceder permisos: afecta al modelo de datos, a cada punto de autorización, a las operaciones asíncronas y a las pruebas. Diseñar estos elementos juntos reduce el riesgo de que una delegación válida en una pantalla se convierta, por una ruta alternativa, en acceso excesivo.
Diferenciar delegación, suplantación y acceso compartido
En una delegación, quien inicia la operación sigue siendo la identidad autenticada. La aplicación registra, además, que actúa en representación de otra persona bajo una autorización limitada. La persona representada no ha iniciado sesión y no debe aparecer como autora directa de la petición.
La suplantación cambia la identidad efectiva con la que el sistema trata una petición, y puede ocultar quién realizó la acción si no se implementa con controles específicos. El acceso compartido, como entregar credenciales, elimina la separación entre usuarios y dificulta revocar o atribuir actividades. Para un flujo ordinario de delegación, ninguno de estos enfoques sustituye a un contexto explícito de actor y principal representado.
Conviene nombrar ambos roles en el código y en los registros. Por ejemplo, actor_id identifica a quien ejecutó la operación y principal_id a la persona en cuyo nombre se realizó. Evita nombres ambiguos como user_id en registros donde podría referirse a cualquiera de los dos.
Definir alcance, recursos y vigencia antes de implementar
Una delegación útil describe con precisión qué autoriza. «Gestionar la cuenta» suele ser demasiado amplio. En cambio, se puede limitar a acciones como revisar tareas, actualizar su estado o responder a una solicitud. Si las acciones tienen consecuencias distintas, modela permisos separados en lugar de agrupar lectura, edición, aprobación y eliminación en una capacidad genérica.
Define también el ámbito de los recursos: una organización, un proyecto, una bandeja de tareas o un conjunto concreto de registros. El permiso para editar tareas de un proyecto no debería habilitar la lectura de datos de otro proyecto por el solo hecho de que el mismo usuario delegado pueda acceder a ambos en otra función.
La vigencia debe tener un inicio y un fin claros, además de un estado que permita revocar la delegación antes del vencimiento. Decide qué zona horaria se usa para presentar fechas y mantén las comparaciones internas coherentes. Si la política requiere aprobación o impide delegaciones encadenadas, conviértelo en una regla explícita y comprobable; no lo dejes como una convención de interfaz.
Modelar la autorización y comprobarla en cada operación
Un esquema relacional puede representar una delegación con campos como identificador, actor autorizado, principal representado, ámbito, acciones, fecha de inicio, fecha de expiración, estado, creador y fecha de revocación. La estructura exacta depende del dominio: las acciones pueden guardarse en una tabla relacionada o en otro formato validado, pero deben poder consultarse y comprobarse sin interpretaciones ambiguas.
La autorización debe separar la autoridad del principal de la autorización delegada al actor. Para la operación solicitada, comprueba que el principal representado tendría acceso ordinario al recurso y que las reglas de negocio aplicables lo permiten. Después, verifica que el actor autenticado es el destinatario de una delegación vigente y no revocada, y que esta concede esa acción sobre ese recurso. El permiso efectivo queda limitado por el acceso del principal y por el alcance de la delegación: esta no puede conceder al actor más acciones o recursos de los que el principal puede autorizar ni más de los que constan en la propia delegación. No exijas que el actor tenga también acceso propio al recurso; precisamente puede actuar gracias a la delegación. Sí aplica las restricciones que correspondan a la identidad del actor, como autenticación, pertenencia al contexto requerido o controles de seguridad de la operación.
En la práctica, la comprobación debería incluir:
- Que el actor esté autenticado y la delegación le corresponda.
- Que el principal representado sea válido en ese contexto y tenga acceso ordinario al recurso solicitado.
- Que la delegación esté activa en el momento de la operación, no revocada y dentro de su vigencia.
- Que la acción solicitada y el recurso estén dentro del alcance concedido, sin exceder la autoridad del principal.
- Que se cumplan las restricciones de negocio y seguridad aplicables al actor y a la operación.
Centraliza esta decisión en un servicio de autorización o una política reutilizable, en vez de repetir condiciones parciales en controladores. Aun así, invócala en cada operación relevante: una vista protegida no protege automáticamente una API, una descarga, una acción masiva ni una ruta de administración. En PHP, el controlador puede obtener el actor autenticado, resolver el contexto de delegación y pedir al servicio que autorice la acción sobre el recurso específico. La capa de dominio también puede imponer invariantes críticas cuando una operación tenga consecuencias importantes.
No confíes en un principal_id enviado por el navegador como prueba de autorización. El servidor debe verificar la relación entre actor, principal, delegación, recurso y acción usando datos de confianza. Tampoco asumas que ocultar un botón en la interfaz impide invocar directamente el endpoint.
Conservar la atribución en auditoría y operaciones asíncronas
Un registro útil permite reconstruir qué ocurrió sin confundir identidades. Para cada evento relevante, conserva actor, principal representado, acción, tipo e identificador del recurso, fecha, resultado y referencia a la delegación aplicada. Según el riesgo, registra también el motivo de la operación o el identificador de correlación. Evita guardar secretos o datos personales innecesarios en el historial.
La atribución debe sobrevivir a colas y trabajos en segundo plano. Si una solicitud delegada programa una tarea, el mensaje debería transportar un contexto verificable con actor, principal y referencia de autorización, no depender de la sesión web, que ya no estará disponible. Al ejecutar el trabajo, decide si se vuelve a comprobar que la delegación sigue activa. Para una acción que todavía puede cancelarse, una comprobación en el momento de ejecución suele evitar que una revocación deje una tarea pendiente con permiso obsoleto. Si la operación ya quedó comprometida de forma irreversible, documenta esa frontera y registra el momento de autorización.
Protege los registros frente a modificaciones no autorizadas y limita quién puede consultarlos. La auditoría debe apoyar investigación y rendición de cuentas, pero no convertirse en una copia indiscriminada de los datos operativos.
Diseñar expiración y revocación como parte del flujo
La expiración y la revocación no son únicamente cambios de estado en una pantalla. Una sesión que conserva un contexto de delegación puede seguir mostrando opciones antiguas; por eso, la autorización del servidor debe comprobar el estado vigente en cada petición, aunque la interfaz también se actualice. Si se cachean permisos, define cómo se invalidan y qué demora máxima se acepta antes de que una revocación sea efectiva.
Al revocar, registra quién lo hizo y cuándo. Evalúa de forma explícita las sesiones activas, tokens emitidos, trabajos en cola y enlaces temporales asociados. No supongas que cerrar una sesión o cambiar un dato de base de datos invalida automáticamente todos esos elementos. La respuesta adecuada depende del diseño, pero debe estar definida antes de publicar el flujo.
Probar límites y casos que suelen pasar inadvertidos
Las pruebas deben verificar tanto las acciones permitidas como las denegadas. Incluye, como mínimo, delegación aún no vigente, vencida o revocada; actor distinto del autorizado; recurso fuera del ámbito; acción no concedida; principal incorrecto o sin acceso ordinario al recurso; y acceso directo a endpoints que la interfaz no muestra. Incluye también un caso positivo en el que el actor carece de acceso propio al recurso, pero el principal sí tiene acceso y la delegación cubre la acción y el recurso. Así se comprueba que el sistema no confunde los permisos propios del actor con la autoridad delegada.
Añade pruebas de límites temporales, cambios concurrentes y efectos indirectos. Por ejemplo, confirma qué ocurre si una delegación se revoca mientras hay una operación en curso o un trabajo pendiente, y si una acción sobre una tarea desencadena notificaciones, exportaciones o cambios secundarios. Comprueba que esos efectos conservan la atribución correcta y no amplían el alcance.
Separa las pruebas unitarias de la política de autorización de las pruebas de integración que recorren rutas, persistencia y colas. Una prueba que comprueba solo el método de decisión no demuestra que todas las rutas lo invoquen; una prueba de interfaz tampoco acredita la protección del servidor.
Lista de comprobación antes de publicar
- ¿Se distinguen claramente actor y principal representado en código, interfaz y auditoría?
- ¿Cada delegación limita acciones, recursos y vigencia, y se impiden combinaciones no válidas?
- ¿La política comprueba el acceso del principal y limita al actor al alcance delegado, sin exigirle acceso propio al recurso?
- ¿Cada operación del servidor comprueba identidad, estado, tiempo, alcance y acción?
- ¿La revocación afecta a sesiones, tokens, cachés y trabajos pendientes según una política definida?
- ¿Los registros permiten atribuir acciones sin almacenar información innecesaria?
- ¿Las pruebas cubren denegaciones, límites temporales, delegaciones válidas sin acceso propio del actor y efectos indirectos?
Una delegación es segura cuando no se confunde con acceso a la cuenta ajena y cuando cada acción puede justificarse con la autoridad del principal y una delegación vigente y limitada. Si el equipo no puede responder con precisión quién actuó, en nombre de quién, sobre qué recurso y bajo qué permiso, el flujo todavía necesita más diseño antes de llegar a producción.
