Cómo restringir la creación de salas de Jitsi a usuarios autenticados específicos

A fecha de 6 de octubre de 2026, el manual de Jitsi para autoalojamiento sigue respaldando la idea de que solo los usuarios autenticados puedan crear salas de conferencias, permitiendo a los invitados unirse posteriormente. Sin embargo, el manual ahora marca su antiguo procedimiento de "Dominio seguro" como obsoleto para nuevas instalaciones y recomienda la autenticación basada en tokens. La configuración correcta depende de cómo haya instalado Jitsi: esta guía proporciona una ruta de autenticación interna directa para implementaciones de Docker y explica la dirección actual para nuevas instalaciones de Debian o Ubuntu.

Estos controles regulan quién puede crear una sala. No hacen que todas las salas sean privadas automáticamente. Las contraseñas de las salas, el vestíbulo y el proceso de invitación son controles independientes.

Elija una ruta de autenticación

La guía de autenticación actual de Jitsi describe la creación de salas autenticadas con invitados anónimos, y la página anterior de Secure Domain indica explícitamente que ese método está obsoleto para las nuevas instalaciones. Evite copiar configuraciones antiguas de Prosody o Jicofo en una implementación más reciente sin consultar la guía correspondiente a su método de instalación.

Docker: permitir que solo los usuarios autorizados inicien salas

Este procedimiento presupone que ya ejecuta Jitsi Meet desde el proyecto oficial de Docker Compose y que puede editar su .envarchivo. El ejemplo que se muestra a continuación utiliza el modo de autenticación integrado internal. No añade una página de registro pública: un administrador crea y elimina las cuentas permitidas.

1. Habilitar la autenticación en el archivo de entorno.

Abra el .envarchivo utilizado por su implementación de Jitsi Compose. Configure las variables de autenticación de esta manera:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Asegúrese de que las líneas sean configuraciones activas en lugar de comentarios que comiencen con #. Con ENABLE_GUESTS=1, las personas que no hayan iniciado sesión podrán unirse como invitados después de que un usuario autenticado haya abierto la conferencia. Si desea que todos los participantes se autentiquen, configure ENABLE_GUESTS=0; esto cambia quién puede unirse, no solo quién puede crear salas.

La guía de Docker documenta estas variables y el flujo de trabajo de cuentas integrado. Consulta la sección de Autenticación de Docker para obtener la lista actual de tipos y opciones de autenticación compatibles.

2. Aplicar la configuración

Desde el directorio que contiene su archivo Compose, aplique el entorno actualizado. Compose recreará los servicios cuya configuración haya cambiado:

docker compose up -d

Verifique que los contenedores estén en funcionamiento antes de crear cuentas. Si utiliza un proyecto Compose personalizado, un nombre de proyecto diferente o una capa de orquestación, ejecute la actualización equivalente para esa implementación en lugar de iniciar una segunda pila de Jitsi.

3. Crea una cuenta para cada anfitrión de sala aprobado.

Abra una consola en el contenedor Prosody:

docker compose exec prosody /bin/bash

A continuación, registre un usuario de Jitsi en el dominio XMPP predeterminado de Docker:

prosodyctl --config /run/prosody/config/prosody.cfg.lua register <username> meet.jitsi <strong-password>

Sustituya ambos marcadores de posición por el nombre de usuario y una contraseña única para esa persona. No incluya los corchetes angulares. Para un segundo host autorizado, ejecute el comando nuevamente con un nombre de usuario diferente. El comando mostrado utiliza el dominio predeterminado de Docker meet.jitsi; si lo modificó XMPP_DOMAIN, siga el dominio configurado en su implementación. La guía actual de Docker documenta el comando del contenedor Prosody y el comando de eliminación correspondiente.

Para revocar un usuario, ingrese al contenedor Prosody y ejecute:

prosodyctl --config /run/prosody/config/prosody.cfg.lua unregister <username> meet.jitsi

Limita la lista de cuentas a las personas que deban poder iniciar conferencias. El nombre de la sala no es un mecanismo de control de acceso, y este debe eliminarse cuando el anfitrión ya no lo necesite.

4. Pruebe las rutas del anfitrión y del invitado por separado.

Utilice una ventana de navegación privada o un perfil de navegador independiente para que una sesión de Jitsi existente no oculte el resultado. Abra la URL pública de Jitsi e intente iniciar una nueva sala sin autenticarse. La instancia debería requerir autenticación antes de asignar la nueva conferencia. Inicie sesión con una de las cuentas que creó e inicie una sala; luego verifique que la sala se abra.

A continuación, abre el enlace de la sala en una sesión de navegador independiente sin autenticación. Con el acceso de invitado habilitado, el invitado debería poder unirse a la conferencia después de que el anfitrión autenticado la inicie. La guía de Docker de Jitsi indica que los usuarios no autenticados deben esperar a que un usuario se autentique cuando el acceso de invitado está habilitado.

Para nuevas instalaciones de Debian o Ubuntu, utilice la guía de autenticación de tokens actual.

El manual de autoalojamiento actual de Jitsi proporciona una ruta de autenticación más reciente mediante autenticación por token. Su ejemplo documentado conecta Jitsi con Keycloak, configura el host de Prosody para que requiera un token y agrega un dominio de invitado anónimo cuando se deba permitir el acceso a invitados. En la configuración de Jitsi, la configuración documentada utiliza authentication = "token"y allow_empty_token = falsepara el host principal, y luego asigna el dominio de invitado como . Siga la guíajitsi-anonymous completa de autenticación para el reino de Keycloak, las URL de redirección del cliente, el enrutamiento del proxy inverso, Prosody y la configuración del cliente web de Jitsi. Reemplace cada nombre de host de ejemplo con el suyo propio y mantenga el punto final del proveedor de identidad protegido por HTTPS.

La autenticación mediante tokens es útil cuando las cuentas deben ser gestionadas por un proveedor de identidad o cuando su aplicación emite tokens de acceso específicos para cada sala. Requiere un emisor y una validación de tokens correctamente configurados; simplemente activar una opción en el navegador no restringe la creación de salas de forma segura. Si necesita cuentas respaldadas por LDAP con Docker, la guía de Docker también documenta un modo LDAP, pero la conexión LDAP, el certificado y la configuración de filtros deben coincidir con su directorio.

La creación de habitaciones es independiente de la privacidad de las mismas.

La autenticación responde a la pregunta "¿quién puede iniciar una conferencia?", pero no a la pregunta "¿quién puede entrar en esta sala?". Si se permite el acceso a invitados, cualquiera que obtenga la URL de la sala podría intentar unirse. Añada una contraseña a la sala o configure el vestíbulo para reuniones que solo admitan a participantes invitados. La guía de autoalojamiento de Jitsi distingue entre la capacidad del servidor para iniciar conferencias y los controles de acceso gestionados en una sala individual.

Problemas comunes que se deben revisar

• La creación de salas sigue funcionando de forma anónima: confirme ENABLE_AUTH=1que está activa en el archivo de entorno utilizado por el proyecto Compose en ejecución y, a continuación, vuelva a aplicar la configuración.
• Cada participante recibe una solicitud de inicio de sesión: compruebe si ENABLE_GUESTSestá desactivada. Esta configuración requiere que los participantes se autentiquen; no es necesaria si su objetivo es que los anfitriones estén autenticados y los asistentes invitados participen.
• No se puede iniciar sesión con una cuenta nueva: verifique que la haya registrado en el dominio configurado para su implementación. El comando predeterminado de Docker utiliza meet.jitsi; los dominios XMPP personalizados necesitan valores correspondientes.
• Los invitados no pueden entrar antes que el anfitrión: esto es coherente con el comportamiento de acceso de los invitados. El anfitrión autenticado debe iniciar la sala primero y luego pedir a los invitados que utilicen el enlace de la sala.
• Siguiendo un tutorial de otro tipo de instalación: no combine rutas de paquetes Debian, configuraciones generadas por Docker ni fragmentos de código antiguos de secure-domain. Consulte la sección del manual correspondiente a su instalación y revise las notas sobre la obsolescencia.

Lista de verificación

1. Un navegador no autenticado no puede crear una nueva sala.
2. Un usuario autorizado puede iniciar sesión y crear una sala.
3. Una cuenta eliminada ya no puede autenticarse.
4. La función de invitados se comporta según lo previsto para su ENABLE_GUESTSconfiguración.
5. Las reuniones privadas también utilizan una contraseña de sala o una política de acceso al vestíbulo cuando es necesario.

La decisión clave es si tu instancia de Jitsi debe usar cuentas internas aprovisionadas individualmente o tokens emitidos a través de un proveedor de identidad. Para una implementación existente de Docker Compose, la autenticación interna es una forma directa de restringir la creación de salas al pequeño grupo de usuarios que registres. Para una instalación nueva, comienza con la guía actual de autenticación por token y mantén los controles de admisión a nivel de sala configurados por separado.

Referencias oficiales

• Jitsi Meet: Autenticación (guía actual; última actualización: 5 de octubre de 2026)
• Jitsi Meet: Guía de autoalojamiento — Docker
• Jitsi Meet: Configuración segura del dominio (marcado como obsoleto para nuevas instalaciones)
• Jitsi Meet: Guía de autoalojamiento — Debian/Ubuntu