Jitsi meet JWT Authentication - Questions about re stricting other room creation / destroying room when moderator leave


My company is currently using Jitsi Meet on a customized virtualhost, with JWT Authentication enabled.

For people trying to create rooms without token, it correctly prompts for password or to wait for the host to create it, whereas people with token can create them.

Currently we are trying to solve two problems:

1) Users with JWT token can create other rooms

Case: With the JWT token, I am able to create a room.

Problem: if I open another tab in my browser, pointing to a nonexistent jitsi room and thus without
providing the JWT token, I am still able to create it.

Question: Shouldn’t the token be valid only that one room I’m creating with it, and prohibiting me for creating other rooms? If not, Is it possible to enforce that and how?

2) Destroying a room after the moderator/owner exits:

Case: With the JWT token, I am able to create a room.After that, I give the link to other people so that they can join as guests.

Problem: If I or other people with the JWT token leave, the room is not destroyed since the guests are still inside.

Question: is it possible to destroy the room when the last moderator/owner leaves, even if there are guests inside? If so, how?

Here’s the config (I did put * to cover passwords etc)

-- Plugins path gets uncommented during jitsi-meet-tokens package install - that's where token plugin is located
plugin_paths = { "/usr/share/jitsi-meet/prosody-plugins/" }
allow_registration = true
VirtualHost "test.myhost.it"
        allow_registration = true
        -- enabled = false -- Remove this line to enable this host
        authentication = "token"
        -- Properties below are modified by jitsi-meet-tokens package config
        -- and authentication above is switched to "token"
        -- Assign this host a certificate for TLS, otherwise it would use the one
        -- set in the global section (if any).
        -- Note that old-style SSL on port 5223 only supports one certificate, and will always
        -- use the global one.
        ssl = {
                key = "/etc/prosody/certs/test.myhost.it.key";
                certificate = "/etc/prosody/certs/test.myhost.it.crt";
        -- we need bosh
        modules_enabled = {
            "ping"; -- Enable mod_ping

        c2s_require_encryption = false

VirtualHost "guest.test.myhost.it"
authentication = "token"
app_id = "******"
app_secret = "*******"
allow_empty_token = true
c2s_require_encryption = false

Component "conference.test.myhost.it" "muc"
    storage = "internal"
    muc_room_cache_size = 100
    modules_enabled = { "token_verification" }
    restrict_room_creation = true
admins = { "focus@auth.test.myhost.it" }

Component "jitsi-videobridge.test.myhost.it"
    component_secret = "******"

VirtualHost "auth.test.myhost.it"
    ssl = {
        key = "/etc/prosody/certs/auth.test.myhost.it.key";
        certificate = "/etc/prosody/certs/auth.test.myhost.it.crt";
    authentication = "internal_plain"

Component "focus.test.myhost.it"
    component_secret = "*******"

Thanks everyone for the help.

1 Like


This should be the case. I don’t understand the guest.test.myhost.it virtualhost. This is something that is bringing you the trouble I think, using both docs for secure domain and jwt.

Not even by writing custom logics / modules?

I’ve created that guest virtualhost in that way so that guests without JWT token could access only on already created rooms, which actually does work thus prohibiting them from creating other rooms. Should it be configured in a different way?

Well, you can create custom lua modules doing that. But this is kind of risky, as what if moderator network is spotty, the room will be drop
ping all the time.

We have not intentionally added that functionality, if it works good, if not there is nothing we can do. You also may update to latest unstable as someone was trying maybe the same and sent a PR for fixing an issue in the auth token module. But other than that, I cannot give you any advice I’m not sure how that work and had never tested it.

1 Like

Thanks for the info. Yeah, I did not think about that case.

Anyway, since I’m expecting there will be a fix for this problem in a future stable release, since it’s a clear bug of the solution and people with a JWT token for a specific room shouldn’t be allowed to open new rooms, right?
As for the possible fix in a unstable release, you are referring to which component/package? Prosody, Jitsi-meet or jitsi-meet-token?
Where should I go check the changelogs to find which unstable version merged the fix for this problem?


1 Like

You have added that possibility by adding the guest domain is what I say.

@JohnLukeP Can you please provide the way you generated your token at https://jwt.io/ using the following config?


Hi @damencho,
I am also having a similar problem as the case 1 with my setup. here is my prosody guest configuration:

VirtualHost “guest...com”
authentication = “anonymous”;
–app_id = “";
–app_secret = "
c2s_require_encryption = false;
–allow_empty_token = true;