Cómo probar invitaciones, vencimientos y bajas en un portal

El ciclo de acceso de un portal comienza antes del primer inicio de sesión y continúa cuando alguien deja la organización de un cliente. Probar solo una invitación aceptada correctamente deja fuera enlaces vencidos, cuentas equivocadas, cambios de rol y sesiones que siguen abiertas después de retirar la membresía.

Prepara una prueba con una organización ficticia y varios usuarios de prueba. El objetivo es demostrar quién puede entrar, qué puede consultar y qué ocurre cuando el permiso original deja de estar vigente.

Define las condiciones de la invitación

Especifica quién puede invitar, a qué organización se incorpora la persona, el rol permitido, la identidad destinataria y la vigencia. Aclara si aceptar crea la membresía inmediatamente o requiere otra aprobación. El correo y el portal deben explicar el mismo proceso.

La documentación de invitaciones de Auth0 muestra que estas pueden incluir organización, destinatario, aplicación, roles y vencimiento. Son preguntas útiles de revisión aunque el portal utilice otro proveedor; sus capacidades concretas deben comprobarse por separado.

Elige la vigencia según el proceso y la revisión de riesgos. No conviertas el valor predeterminado del proveedor en una regla universal del negocio. Documenta qué verá la persona al vencer el enlace y cómo podrá un administrador autorizado emitir otro.

Prueba las alternativas a la aceptación correcta

Utiliza un documento inofensivo que pertenezca únicamente a la organización ficticia. Ejecuta estos escenarios y comprueba el acceso real después de cada uno:

• Acepta una invitación vigente con la identidad destinataria y confirma el rol acordado.
• Abre el enlace después de vencer. Verifica que no conceda una membresía nueva y que se entienda cómo solicitar otro.
• Cancela una invitación pendiente y después intenta utilizar el enlace anterior.
• Emite una sustitución y comprueba qué ocurre con ambos enlaces.
• Abre la invitación mientras hay una sesión de otro usuario de prueba. Verifica que la membresía no se asigne silenciosamente a la identidad equivocada.
• Utiliza una segunda organización ficticia para comprobar que el enlace no conceda acceso entre clientes.

Si el producto exige invitaciones de un solo uso, añade un segundo intento de aceptación como caso explícito. Contrasta el requisito con el comportamiento implementado: la palabra “invitación” no demuestra por sí sola todas esas protecciones.

Comprueba los roles después de incorporarse

En un portal hipotético, un usuario de consulta puede leer novedades del servicio, pero no invitar compañeros ni aprobar solicitudes. Prueba esos límites desde la interfaz y mediante peticiones o enlaces directos, con ayuda del equipo de desarrollo.

Ocultar un botón administrativo no demuestra que se deniegue la operación correspondiente. Pide evidencia de que el servidor aplica las comprobaciones previstas de organización y rol. Utiliza una referencia de prueba conocida para verificar que modificar la URL no permita leer un documento de otra organización.

Cambia también el rol mientras permanece abierta una pestaña. La siguiente acción restringida debe seguir la política nueva. Decide qué mensaje explica el cambio y cómo puede el usuario volver a una tarea permitida sin perder trabajo ajeno a esa acción.

Ensaya la baja con sesiones activas

Abre el portal en dos sesiones de prueba antes de retirar la membresía. Después, intenta cargar una actualización, abrir un documento y realizar una acción antes permitida desde ambas sesiones. Incluye un enlace directo guardado antes de la baja.

La guía de sesiones de OWASP explica por qué el vencimiento y la invalidación necesitan controles del servidor. Cerrar una pestaña o borrar un valor del navegador no demuestra que haya terminado el acceso.

Acuerda cuánto puede tardar en hacerse efectiva la baja y cómo la aplicación la aplica entre sus capas de identidad y autorización. Comprueba los tiempos y el comportamiento real de los tokens. No prometas revocación inmediata si la implementación no puede demostrarla.

Separa la baja de la eliminación del historial. Quizá sea necesario conservar quién aprobó una operación aunque esa persona ya no pueda entrar. Documenta quién asumirá aprobaciones pendientes y si los enlaces compartidos o avisos programados necesitan una acción adicional.

Conserva una ficha del ciclo de acceso

Por escenario, anota la membresía inicial, la invitación o cambio de rol, la acción intentada, la decisión esperada, la observada y la hora. Referencia los registros de invitación sin copiar enlaces utilizables ni secretos en capturas o notas de soporte.

Pide al administrador que complete los recorridos de vencimiento y baja con los controles previstos. Una modificación de base de datos puede ayudar a investigar, pero no demuestra que el administrador habitual pueda gestionar el acceso.

Son escenarios propuestos, no resultados de una auditoría ni garantías sobre un proveedor. Contacta con Dynelink para definir los casos de aceptación de invitaciones, cambios de rol y bajas de tu portal.