lib-jitsi-meet

You can include an optional context object in the JWT payload to provide user display information. This data is not used for validation but can be used for reporting or UI display.

Context Fields:

• group: A string specifying the user's group.
• user: An object containing:
  • id: User identifier string.
  • name: Display name.
  • email: User email.
  • avatar: URL of the user's avatar.
• callee: (Optional) Object for 1-1 calls containing id, name, and avatar of the person being called.

Important: All fields in the user object must be valid strings, numbers, or null. Using other types will cause an exception.

Retrieving Data in lib-jitsi-meet: To access this data via the JitsiParticipant class, you must enable the presence_identity module in your Prosody configuration. You can then retrieve the identity by listening to the USER_JOINED event.

-- Enable in Prosody config to allow lib-jitsi-meet to see context data
VirtualHost "jitmeet.example.com"
    modules_enabled = { "presence_identity" }

To use JSON Web Token (JWT) authentication with lib-jitsi-meet, you must generate a JWT (following RFC7519) in your application and pass it to the JitsiConnection constructor. The token allows external authentication where the server (Prosody) verifies the client's connection based on the token's claims.

There are two validation methods supported by the Prosody plugin:

1. Shared Secret Validation: Uses an app_secret shared between your token generator and the Prosody server (HMAC).
2. Public Key Validation: Uses a private key to sign tokens and a public key server (asap_key_server) to verify them (RSXXX).

When using a tenant-based setup (e.g., TENANT/ROOM), you must specify the muc in the hosts section of the connection options.

const connection = new JitsiMeetJS.JitsiConnection(
    '${applicationId}',
    '${token}',
    {
        serviceUrl: 'wss://server.net/tenant/xmpp-websocket',
        hosts: {
            domain: 'muc.server.net',
            muc: 'conference1.tenant.muc.server.net',
        },
    },
);

If not using the automated Debian package, follow these three steps to configure Prosody:

1. Set Plugin Paths and Global Accept Lists

In your global configuration, set the plugin_paths to the location of the Jitsi Meet Prosody plugins and define which issuers/audiences are accepted.

plugin_paths = { "/usr/share/jitsi-meet/prosody-plugins/" }

asap_accepted_issuers = { "*" }
asap_accepted_audiences = { "*" }

2. Configure the VirtualHost

Change the authentication method to token and provide the app_id. Choose one of the following validation methods:

Option A: Shared Secret Validation

VirtualHost "jitmeet.example.com"
    authentication    = "token";
    app_id            = "example_app_id";
    app_secret        = "example_app_secret";
    allow_empty_token = false;

Option B: Public Key Validation

VirtualHost "jitmeet.example.com"
    authentication    = "token";
    app_id            = "example_app_id";
    asap_key_server   = "https://keyserver.example.com/asap";
    allow_empty_token = false;

3. Enable Room Name Verification

Enable the token_verification module in your MUC component configuration to prevent token abuse.

Component "conference.jitmeet.example.com" "muc"
    modules_enabled = { "token_verification" }

The following JWT claims are required or used for authorization by the Prosody plugin:

Note on Signature Algorithms:

• For Shared Secret (HSXXX): Uses an HMAC hash.
• For Public Key (RSXXX): The JWT header must include a kid (Key ID) which corresponds to the name of the public key on the key server.