Como restringir a criação de salas no Jitsi a usuários autenticados específicos

Em 6 de outubro de 2026, o manual de auto-hospedagem do Jitsi ainda suportava o objetivo de permitir que apenas usuários autenticados criassem salas de conferência, permitindo que convidados entrassem posteriormente. No entanto, o manual agora marcava o antigo procedimento de "Domínio Seguro" como obsoleto para novas instalações e recomendava a autenticação baseada em token. A configuração correta depende de como você instalou o Jitsi: este guia fornece um caminho direto para autenticação interna em implantações do Docker e explica a direção atual para novas instalações do Debian ou Ubuntu.

Esses controles determinam quem pode iniciar uma sala. Eles não tornam automaticamente todas as salas privadas. As senhas das salas, o lobby e o processo de convite são controles separados.

Escolha um caminho de autenticação

O guia de autenticação atual do Jitsi descreve a criação de salas autenticadas com convidados anônimos, e a página antiga de Domínio Seguro afirma explicitamente que esse método está obsoleto para novas instalações. Evite copiar configurações antigas do Prosody ou Jicofo para uma implantação mais recente sem consultar o guia correspondente ao seu método de instalação.

Docker: permitir que apenas usuários provisionados iniciem salas.

Este procedimento pressupõe que você já execute o Jitsi Meet a partir do projeto oficial do Docker Compose e possa editar seu .envarquivo. O exemplo abaixo usa o modo de autenticação integrado internal. Ele não adiciona uma página de cadastro público: um administrador cria e remove as contas permitidas.

1. Habilite a autenticação no arquivo de ambiente.

Abra o .envarquivo usado pela sua implantação do Jitsi Compose. Defina as variáveis ​​de autenticação da seguinte forma:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Certifique-se de que as linhas sejam configurações ativas e não comentários que começam com ` #. Com ` ENABLE_GUESTS=1, pessoas que não estão conectadas podem participar como convidadas depois que um usuário autenticado abrir a conferência. Se você quiser que todos os participantes se autentiquem, defina ` ENABLE_GUESTS=0; isso altera quem pode participar, não apenas quem pode criar salas.

O guia do Docker documenta essas variáveis ​​e o fluxo de trabalho de conta integrado. Consulte a seção Autenticação do Docker para obter a lista atual de tipos e opções de autenticação compatíveis.

2. Aplique a configuração

A partir do diretório que contém seu arquivo Compose, aplique o ambiente atualizado. O Compose recriará os serviços cuja configuração foi alterada.

docker compose up -d

Verifique se os contêineres estão em execução antes de criar contas. Se você usar um projeto Compose personalizado, um nome de projeto diferente ou uma camada de orquestração, execute a atualização equivalente para essa implantação em vez de iniciar uma segunda pilha Jitsi.

3. Crie uma conta para cada anfitrião de sala aprovado.

Abra uma janela no contêiner Prosody:

docker compose exec prosody /bin/bash

Em seguida, registre um usuário Jitsi no domínio XMPP padrão do Docker:

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

Substitua ambos os espaços reservados pelo nome de usuário e uma senha exclusiva para essa pessoa. Não inclua os colchetes angulares. Para um segundo host autorizado, execute o comando novamente com um nome de usuário diferente. O comando mostrado usa o domínio padrão do Docker meet.jitsi; se você alterou o domínio XMPP_DOMAIN, siga o domínio configurado pela sua implantação. O guia atual do Docker documenta o comando do contêiner Prosody e o comando de remoção relacionado.

Para revogar a conta de um usuário, acesse o contêiner Prosody e execute o seguinte comando:

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

Mantenha a lista de contas limitada às pessoas que devem poder iniciar conferências. O nome da sala não é um mecanismo de controle de acesso e o acesso à conta deve ser removido quando o anfitrião não precisar mais dela.

4. Teste os caminhos do host e do convidado separadamente.

Use uma janela anônima do navegador ou um perfil de navegador separado para que uma sessão de login existente do Jitsi não oculte o resultado. Abra o URL público do Jitsi e tente iniciar uma nova sala sem autenticação. A instância deverá exigir autenticação antes de alocar a nova conferência. Faça login com uma das contas que você criou e inicie uma sala; em seguida, verifique se a sala abre.

Em seguida, abra o link da sala em uma sessão de navegador separada e não autenticada. Com o acesso de convidado ativado, o convidado deverá conseguir entrar na conferência depois que o anfitrião autenticado a iniciar. O guia do Jitsi para Docker indica que usuários não autenticados precisam esperar até que um usuário se autentique quando o acesso de convidado estiver ativado.

Para novas instalações do Debian ou Ubuntu, utilize o guia de autenticação por token atual.

O manual de auto-hospedagem atual do Jitsi oferece um caminho de autenticação mais recente usando autenticação por token. O exemplo documentado conecta o Jitsi ao Keycloak, configura o host Prosody para exigir um token e adiciona um domínio convidado anônimo quando os convidados devem ser permitidos. Na configuração do Jitsi, a configuração documentada usa `<hostname>` authentication = "token"e `<hostname> allow_empty_token = false` para o host principal e, em seguida, mapeia o domínio convidado como ` <hostname>`. Siga o guiajitsi-anonymous completo de autenticação para o realm do Keycloak, URLs de redirecionamento do cliente, roteamento de proxy reverso, Prosody e configurações do cliente web do Jitsi. Substitua todos os nomes de host de exemplo pelos seus próprios e mantenha o endpoint do provedor de identidade protegido por HTTPS.

A autenticação por token é útil quando as contas devem ser gerenciadas por um provedor de identidade ou quando seu aplicativo emite tokens de acesso específicos para salas. Ela requer um emissor configurado corretamente e a validação do token; simplesmente ativar uma configuração no navegador não restringe a criação de salas de forma segura. Se você precisar de contas com suporte a LDAP no Docker, o guia do Docker também documenta um modo LDAP, mas a conexão LDAP, o certificado e as configurações de filtro devem corresponder ao seu diretório.

A criação de um quarto é um processo independente da privacidade do quarto.

A autenticação responde à pergunta “quem pode iniciar uma conferência?”. Ela, por si só, não responde à pergunta “quem pode entrar nesta sala?”. Se convidados forem permitidos, qualquer pessoa que obtiver o URL da sala poderá tentar entrar. Adicione uma senha à sala ou configure o lobby para reuniões que admitam apenas participantes convidados. O guia de hospedagem própria do Jitsi distingue a capacidade do servidor de iniciar conferências dos controles de acesso gerenciados em uma sala individual.

Problemas comuns a verificar

• A criação de salas ainda funciona anonimamente: confirme ENABLE_AUTH=1se a opção está ativa no arquivo de ambiente usado pelo projeto Compose em execução e, em seguida, reaplique a configuração.
• Todos os participantes recebem uma solicitação de login: verifique se ENABLE_GUESTSestá desativada. Essa configuração exige que os participantes se autentiquem; ela não é necessária quando seu objetivo é ter anfitriões autenticados com participantes convidados.
• Uma nova conta não pode fazer login: verifique se você a registrou no domínio configurado para sua implantação. O comando padrão do Docker usa meet.jitsi; domínios XMPP personalizados precisam de valores correspondentes.
• Os convidados não podem entrar antes do anfitrião: isso está de acordo com o comportamento de acesso de convidados. Peça ao anfitrião autenticado que inicie a sala primeiro e, em seguida, solicite aos convidados que usem o link da sala.
• Seguindo um tutorial de outro tipo de instalação: não misture caminhos de pacotes Debian, configuração gerada pelo Docker e trechos de código antigos do secure-domain. Use a seção do manual para sua instalação e revise as notas de descontinuação.

Lista de verificação

1. Um navegador não autenticado não pode criar uma nova sala.
2. Um usuário com acesso autorizado pode fazer login e iniciar uma sala.
3. Uma conta removida não pode mais ser autenticada.
4. A entrada de convidados funciona conforme o esperado para a sua ENABLE_GUESTSconfiguração.
5. Reuniões privadas também utilizam senha de sala ou política de acesso ao saguão, quando necessário.

A decisão crucial é se sua instância do Jitsi deve usar contas internas provisionadas individualmente ou tokens emitidos por um provedor de identidade. Para uma implantação existente do Docker Compose, a autenticação interna é uma maneira direta de restringir a criação de salas ao pequeno conjunto de usuários que você registra. Para uma nova instalação, comece com o guia de autenticação por token atual e mantenha os controles de admissão em nível de sala configurados separadamente.

Referências oficiais

• Jitsi Meet: Autenticação (guia atual; última atualização em 5 de outubro de 2026)
• Jitsi Meet: Guia de Auto-hospedagem — Docker
• Jitsi Meet: Configuração de domínio seguro (marcado como obsoleto para novas instalações)
• Jitsi Meet: Guia de Auto-Hospedagem — Debian/Ubuntu