JWT / token mode¶
If you deploy mod_jitsi in production, you will usually want a Jitsi Meet server running in token-based mode (JWT authentication). This configuration gives you extra control over moderation privileges.
Why token mode is recommended for moderation¶
With token configuration, the plugin sends users who hold the mod/jitsi:moderation
capability as moderators in the Jitsi session — only they are allowed to mute
participants, disable cameras or remove participants. A moderator indicator is displayed
next to their name.
Without token configuration, some moderator buttons and features (such as mute everyone or kick out participant) are merely hidden from non-moderator users in the interface. That is cosmetic: experienced users may be able to bypass these restrictions. Token mode enforces moderation on the server side instead of hiding buttons in the browser.
Deploying a token-based server
Setting up a self-hosted Jitsi Meet server is beyond the scope of this guide. You can also buy Jitsi Meet as a service from a provider such as JaaS (8x8), which offers a discount for Moodle users. Many governmental education institutions run their own Jitsi servers — you can ask them whether they provide Jitsi token credentials for this configuration.
Required Prosody plugin for self-hosted servers¶
If you use a self-hosted Jitsi server with JWT authentication (server type 1), you must install the jitsi-token-moderation-plugin on your Jitsi server for moderator roles to work correctly.
Without this plugin, everyone becomes a moderator
Without it, the moderator field in the JWT token is ignored by Jitsi and all users
join as moderators, regardless of their Moodle role.
This plugin is not required for:
- 8x8 JaaS (server type 2) — moderation is handled natively by the service.
- GCP auto-managed (server type 3) — the plugin provisions the server already configured for JWT moderation.
See Self-hosted setup for how to configure a self-hosted server with JWT.