How to Enable Authentication and Password Protection in Jitsi Meet

Jitsi Meet has two separate protection controls: server authentication decides who may create a meeting, while a room password blocks people who do not know the password from joining that room. They solve different problems. On a self-hosted server, the older Prosody “secure domain” setup can require a username and password to create rooms while still allowing guests to join. Jitsi’s current handbook now marks that method deprecated for new installations and recommends token-based authentication instead. Existing administrators can use the procedure below as a compatibility guide, but should plan new deployments around a supported token or identity-provider setup.

Room passwords are a separate, in-meeting feature and remain useful alongside server authentication. Set a password after the room has started, share it through a private channel, and test the join flow from a second browser before inviting participants.

Which kind of protection do you need?

For a small meeting, a unique room name plus a room password may be enough. For an organization that needs account-based room creation, configure server authentication as well. For new self-hosted deployments, review Jitsi’s current authentication guide and the relevant token-authentication setup before choosing an implementation.

How do you password-protect one Jitsi room?

Start the meeting, open the security or meeting-options menu in the toolbar, choose the password action, and enter a strong room password. The menu label and icon can vary by client version. If the meeting is already underway, setting a password affects future joins; people who have already entered are not automatically removed. Send the password separately from the meeting link when confidentiality matters.

Jitsi’s FAQ explains that a room password is removed when the meeting ends, so recurring meetings should not be assumed to retain it. Set it again for each new meeting and verify the behavior in your own deployment. Anyone who receives or is forwarded the password may be able to enter, so a password is not the same as a named-user access list. See the official Jitsi FAQ on meeting protection.

What does server authentication change?

In the classic “secure domain” design, Prosody authenticates room creators against local accounts. Jitsi then allows unauthenticated participants to connect through a guest domain. This is useful when only staff should start rooms but attendees should not need accounts. It does not make every participant sign in. If every user must authenticate, guest access needs to be disabled or replaced by the identity and access policy used by your current authentication design.

Jitsi’s documentation labels this older secure-domain method deprecated for new installations. Continue only if you understand that limitation and are maintaining a compatible existing server. Before editing, identify how Jitsi was installed, note your Jitsi Meet hostname, back up the Prosody, Jicofo, and web configuration files, and keep an active administrator session or console available in case a syntax error interrupts service.

How do you enable the legacy secure-domain setup on a Debian or Ubuntu package install?

1. Change the Prosody virtual hosts

Open the Prosody file for your Jitsi hostname, normally /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Replace the sample hostname below with the real domain. In the main virtual host, change the authentication mode to hashed internal passwords. Add the guest virtual host after it:

VirtualHost "jitsi.example.com"
    authentication = "internal_hashed"

VirtualHost "guest.jitsi.example.com"
    authentication = "jitsi-anonymous"
    c2s_require_encryption = false

Preserve other existing options and modules. Do not create DNS records or a public certificate for guest.jitsi.example.com; in this configuration it is an internal Jitsi domain.

2. Tell the web client about the guest domain

Open /etc/jitsi/meet/jitsi.example.com-config.js and add anonymousdomain inside the existing hosts object. Keep the existing domain and other entries, and check commas carefully:

hosts: {
    domain: 'jitsi.example.com',
    anonymousdomain: 'guest.jitsi.example.com'
},

3. Enable authentication in Jicofo

Edit /etc/jitsi/jicofo/jicofo.conf. Add the authentication settings inside its existing jicofo block; do not create a duplicate top-level block:

jicofo {
  authentication {
    enabled = true
    type = XMPP
    login-url = "jitsi.example.com"
  }
}

If the file already has a jicofo section, merge these properties into it. Configuration syntax and generated files can differ by package version, so compare the result with the current handbook page for your installation before restarting services.

4. Restart services and create an account

After checking the edits, restart the services as an administrator:

sudo systemctl restart prosody
sudo systemctl restart jicofo
sudo systemctl restart jitsi-videobridge2

Register a room-creator account in Prosody. Replace the placeholders; never use the example domain or a weak password on a live server:

sudo prosodyctl register <username> jitsi.example.com <strong-password>

Each account is associated with the Jitsi hostname. Create individual accounts rather than sharing one administrator credential if you need to revoke access later. Jitsi’s secure-domain documentation lists the package-specific configuration paths and registration command. It also explicitly states that the method is deprecated.

How does the setup differ in Docker?

Do not edit files inside running containers or copy the Debian package paths into a Docker deployment. In the official Docker Compose setup, authentication is configured through the deployment’s environment file. The handbook documents these relevant values for internal account authentication:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Keep guest access enabled if attendees should be able to join without their own accounts. With guests enabled, unauthenticated users can join according to the configured guest behavior; they do not become authenticated room creators. Apply environment changes using the Compose workflow for your deployment and inspect the logs if the services do not come up cleanly.

Create an internal user through the Prosody service rather than changing generated container configuration. The official handbook shows opening a shell in the Prosody container and registering a user with prosodyctl. The configuration path and XMPP domain depend on the Compose release; in the documented Docker image, the Prosody config is under /config/prosody.cfg.lua, and the example XMPP domain is meet.jitsi. Use the exact command and values documented for your checked-out release. See the official Docker self-hosting guide for environment variables, account creation, and generated configuration behavior.

How can you confirm the protection works?

• Open a private browser window and try to create a new room. The classic setup should prompt for the account credentials.
• Sign in with the new account and create a room. Confirm the meeting loads and the host has the expected moderator controls.
• From another browser, join as a guest. If guests are enabled, joining should work without a creator account; add the room password or lobby when you need an extra admission check.
• Set a room password, then try joining from a fresh private window without it and with it. Confirm that a participant already inside remains connected when the password is set.
• Start a new room after ending the test meeting and check whether the password must be set again, as described in Jitsi’s FAQ.

If the sign-in prompt never appears, inspect the Prosody host names, Jicofo block, client anonymousdomain value, and service logs. A common configuration error is using a guest domain that does not match between Prosody and config.js, or adding a second Jicofo block instead of extending the existing one. If guests cannot join, verify that guest access was intentionally enabled and that the configured guest domain matches the main hostname.

What should you choose for a new installation?

Do not begin a new deployment with the deprecated secure-domain recipe unless you have a specific compatibility reason. Jitsi’s current self-hosting material recommends token authentication for new installations, while its broader authentication guide documents newer identity-provider integration. These approaches require additional issuer, signing, or identity-provider configuration; they are not interchangeable with a Prosody room password. Choose the model that matches your requirements, then use room passwords or a lobby as separate meeting-level controls where appropriate.

In short: use account or token authentication to control who can create rooms, and set a room password to restrict later joins to people who know the secret. Test both paths independently, because enabling one does not automatically enable the other.

Official references

• Jitsi Meet: Authentication
• Jitsi Meet: Secure Domain Setup (deprecated)
• Jitsi Meet: Token Authentication
• Jitsi Meet: Docker self-hosting guide
• Jitsi Meet: FAQ and meeting protection