Usuarios de aplicaciones y autenticación.

Dos tipos diferentes de cuenta

Su cuenta Amazi controla el acceso a los proyectos y características del producto Amazi. Los usuarios de una aplicación que usted crea tienen cualquier autenticación y permisos que implemente esa aplicación. Iniciar sesión en Amazi no crea automáticamente una cuenta en su aplicación.

Del mismo modo, invitar a un colaborador a un proyecto no lo convierte automáticamente en administrador de la aplicación publicada. Consulte Colaboración y acceso para conocer los roles del proyecto y Cuenta y seguridad para su identidad Amazi.

Describir el flujo de trabajo protegido

Al solicitar autenticación, especifique quién debe iniciar sesión, qué puede hacer cada rol y qué datos pertenecen a cada usuario u organización. Solicite verificaciones de acceso del lado del servidor, no solo botones de interfaz ocultos.

Por ejemplo:

Los miembros solo pueden ver sus propias reservas. El personal puede gestionar reservas para su ubicación asignada. Verifique que un miembro no pueda abrir la reserva de otro miembro cambiando su URL.

Los métodos de inicio de sesión disponibles dependen de la implementación de la aplicación y de los servicios conectados. No asuma que un correo electrónico, SMS o proveedor social en particular ya está configurado.

Cómo verifica Amazi el comportamiento de inicio de sesión

Cuando el cambio solicitado necesita pruebas autenticadas y no existe una cuenta de prueba adecuada, Amazi puede crear un usuario de verificación claramente identificado con el rol y los datos de prueba mínimos necesarios. Esto es parte de la verificación solicitada y no debería requerir su contraseña personal ni ninguna otra aprobación ceremonial.

La verificación debe utilizar el inicio de sesión real y las comprobaciones de permisos de la aplicación. Amazi no debe deshabilitar la autenticación, agregar una puerta trasera, restablecer la contraseña de un cliente real ni hacerse pasar por un usuario existente para obtener acceso.

Si la verificación externa o un proveedor no disponible impide el inicio de sesión, el resultado debería indicar qué escenario permanece sin verificar.

Los usuarios de prueba siguen siendo registros de bases de datos reales.

La base de datos administrada se comparte con producción. Por lo tanto, las identidades y elementos de verificación dedicados necesitan un alcance y un plan de limpieza claros. Las pruebas no deben enviar invitaciones, compras o notificaciones reales a personas no relacionadas.

Solicite evidencia del rol y la acción relevantes: navegación iniciada, comportamiento permitido exitoso, comportamiento prohibido denegado y resultados persistentes cuando sea necesario. Una página de inicio de sesión que se carga correctamente no prueba que el flujo de trabajo protegido funcione. Consulte Pruebas y verificación.