Jitsi SSO and identity integration guide

Why Jitsi SSO needs a plan before the first login

Tying meeting creation to corporate identity is a design decision you make before the first login, and it is costly to change later. In a self-hosted Jitsi Meet deployment, anyone with a room link can join a room by default, so the question is which identity source decides who may start a meeting and how that decision reaches the server. Jitsi sets authentication per deployment and per domain, and the mode you choose determines the guest model, the party that issues tokens and the amount of work needed to move existing users onto the new path.

The Jitsi Docker guide lists five options: internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode. The Docker setup configures these through the .env file, so the choice sits alongside your other deployment settings and should be recorded with them. Internal XMPP accounts keep user records inside the Prosody server. JWT tokens move the decision to your identity system, which signs a token that Jitsi checks when a user creates or enters a room. LDAP and Matrix verification connect Jitsi to a directory or account system you already run. Each option implies a different token issuer or user store, and that difference shapes the cutover work.

The part that is easy to miss is what authentication covers. It decides who can open a room. It does not, by itself, decide who can join a room that someone else already opened. Guest access therefore has to be designed alongside authentication, not added after it. The Jitsi handbook recommends a separate anonymous domain for guests, which keeps authenticated hosts and unauthenticated invitees on different paths. Decide early whether external partners will be guests, how they will be invited and who may convert a guest meeting into a managed one.

Before installation, write down four things: the identity system that will issue tokens, the staff who may host meetings, the guests who will join and how they will arrive, and the existing meeting links that must keep working during cutover. Ask your identity team which claims the token issuer can supply and how signing keys will be stored and rotated, since that work sits on your side of the integration. Also confirm which Jitsi release and Docker image tag you will pin, because configuration keys can change between releases. The plan takes little effort to write, but it is expensive to reverse once users have bookmarked links.

Which Jitsi components carry the authentication decision

Login and room creation pass through several parts of a Jitsi deployment, and each one holds a piece of the access decision. Map these components before choosing an authentication mode so you know which team owns each setting and which test proves it works.

Web app served by nginx or Apache

The web app is the JavaScript and HTML that a browser loads from nginx or Apache. It shows the join page and the sign-in prompt, then passes the room name and any JWT token to the XMPP side. The web server does not decide who may create a room, so access rules belong in Prosody and Jicofo. Check that the site is served over HTTPS with a certificate your browsers trust, and confirm the file layout for your install method in the official docs.

Prosody holds accounts and guest domain

Prosody is the XMPP server where internal accounts live when you use internal authentication, and where the token authentication module checks JWT tokens presented at connection. Guest access runs on a separate anonymous domain, which is configured as its own virtual host in Prosody so guests authenticate differently from members. Confirm the virtual host and module layout for your chosen install method in the official Jitsi docs before you change it, because that layout depends on the install method.

Jicofo creates conference rooms

Jicofo is the conference focus. When a participant opens a room, Jicofo asks Prosody to create or join the room and allocates a videobridge to carry the media. Room creation therefore depends on the authentication result from Prosody, and a rejected login should never reach a room. Test denied users as well as allowed ones, including a guest on the anonymous domain and a member with an expired token, to confirm the decision holds at each step.

Identity provider or JWT issuer

Your identity provider, or a service your team controls, signs JWT tokens that carry the user's identity, room permissions and an expiry time. Jitsi trusts the signing secret and the application ID configured on its side, so the issuer name, audience and key must match between your system and Jitsi. Decide who may start meetings, how guests receive tokens, and how long a token stays valid. The token authentication guide lists the claims to set, and you should confirm them against your release.

Settings in the Docker .env file

In the official Docker setup, the .env file selects the authentication mode and holds the related values, including the JWT application ID and secret, the XMPP domain names and the anonymous domain name. Keep the file under version control with secrets stored separately from it. Confirm the exact variable names for your release in the Docker guide, and confirm whether a change needs a container restart or a full recreation before you apply it in production.

Matrix homeserver for verification

If you choose Matrix user verification or the hybrid Matrix plus JWT mode, your Matrix homeserver confirms who is signed in and whether that user may start meetings. The Docker setup needs the homeserver address and the settings that let Prosody check identities with it. Confirm which homeserver version and access settings your chosen mode requires, and name the team that operates the homeserver, because an outage there may block room creation for every user.

Choosing an authentication model for Jitsi

This table compares the five authentication options listed in the Jitsi Docker guide, plus leaving meetings open, against the situations where each fits and the operational work each adds. Read each row for the option you are weighing, then check the operating cost column against the team that will own signing keys, directories or Matrix servers. The main takeaway is that JWT token authentication with a separate anonymous guest domain is the approach the Jitsi handbook recommends.

Option	When it fits	Operational cost
Internal XMPP accounts	Small teams that can accept a separate Jitsi user list and have few people creating rooms	Accounts are created and removed inside Prosody, so every joiner or leaver needs a manual change that is not tied to your directory
JWT tokens	A web app or portal that can issue signed meeting tokens, which is the handbook's recommended option	Signing key storage, key rotation on the Jitsi side and token expiry settings must be maintained by the team that issues tokens
LDAP	An existing corporate directory that should decide who can log in and create meetings	A directory service account must be provisioned and its credentials protected, and directory changes and Jitsi access must be tested together
Matrix user verification	An existing Matrix estate where users already sign in to a homeserver	Every meeting start depends on the Matrix homeserver being available, and the homeserver's own administration becomes part of Jitsi operations
Hybrid Matrix plus JWT	Organizations running Matrix that also want a web app to issue meeting tokens for specific flows	Two trust paths must be configured, monitored and kept in step, which raises testing and troubleshooting effort
Leaving meetings open	Short-lived internal pilots on an isolated network with no sensitive content, where access control is deferred	Anyone who finds a room link can join, so the risk grows with the link's lifetime and sharing, and this option usually needs a documented exception

Replacing the deprecated secure domain setup

Replacing the secure domain setup changes who can start a meeting, so it belongs in the identity plan before any production change. The secure domain method required a username and password to create rooms, with those accounts held on the XMPP side of the deployment. The Jitsi handbook marks this method as deprecated for new installations and recommends JWT token authentication instead. Existing deployments that still run it are not broken, but they rely on a method the project no longer recommends for fresh builds. Read the secure domain page of the handbook first and confirm its current deprecation status and any migration notes, because the guidance can change and your steps must match the release you run. Record which configuration settings and components the secure domain setup touches in your environment before you schedule the change.

The first mapping task is identity. Each account that currently creates rooms needs a counterpart in the system that will issue JWT tokens, or in the LDAP directory if you choose that option through the Docker .env file. Decide which system is authoritative for names and group membership, then map each existing XMPP account to one identity so that moderators keep the rights they need. Room naming needs the same attention. Links already shared with staff, calendar invitations and bookmarks depend on room names, so list which rooms are persistent and which are created per meeting. Ask the owners of those links whether a naming convention change will break them. Confirm the token claim names, audience and room fields in the token authentication page of the handbook, because those exact fields decide who can join which room.

Guest access is the part most often left unfinished. It needs its own design, so the guest path depends on the anonymous domain being configured correctly. The handbook recommends a separate anonymous domain for guests, which lets people join without a token while room creation stays tied to authenticated users. Decide which rooms guests may enter, whether a moderator must admit them, and how guest display names appear to the host. Test the guest path from an outside network and from a mobile client, since the handbook warns that self-signed or improper certificates cause audio and video problems, especially on mobile. Confirm the anonymous domain settings and any guest-specific notes in the handbook before you publish guest links.

The most serious risk is a half-migrated state, where some rooms still accept the old username and password method while others require tokens. Staff may not know which path a given room uses, and a single room left on the old method becomes the weak point of the design. Before cutover, inventory every room, account and link, and set a date after which the old method is switched off for all rooms. Run tests that confirm an old-style login fails after the change, that a token-bearing user reaches the intended room, and that an anonymous guest reaches only the rooms you opened to guests. Keep a rollback plan that restores the previous configuration if meetings fail. Confirm the deprecation status and migration notes in the secure domain page of the handbook before changing a production system, because they set the supported order of steps for your release.

How to build Jitsi SSO in order

This sequence moves a self-hosted Jitsi Meet deployment from open access to controlled meetings, where only users your identity system vouches for can start rooms and guests enter through a separate domain. Each step ends with a check, so you confirm one change works before the next depends on it.

Confirm HTTPS with a proper domain certificate
Before any authentication work, the platform team serves the site over HTTPS on a domain name with a certificate from a trusted authority, following the Jitsi handbook. The handbook states that HTTPS with a proper domain certificate is necessary for working audio and video and warns that self-signed certificates cause problems, especially on mobile clients. Confirm with your infrastructure team which certificate source you use and who handles renewal. Check: load the site in a desktop browser and on a phone on the corporate network without certificate warnings, then place a test call with audio and video between two devices.
Choose the authentication model
Decide who may start meetings before changing any configuration. The Docker guide lists internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode. The handbook recommends JWT token authentication, where your system issues a signed token that carries the user's identity and moderator status. Record the chosen model, the identity source that feeds it, the group that gets moderator rights, and the owner who signs off. Check: a written decision record exists that names the identity source, the claims the system will trust, and the team that controls the signing key.
Decide the anonymous guest domain and rules
Guests need a route into meetings that does not require a token. The handbook recommends a separate anonymous domain for guests, which keeps the authenticated domain closed to unauthenticated room creation. Agree who may invite guests, how guests enter a room before a moderator arrives, and how guest access is logged. Confirm the guest domain name resolves the way your internal and external users need it to. Check: a written guest policy lists the domain, the entry rules and the approver, and a reviewer confirms each rule maps to a setting you can point to in the configuration.
Configure the chosen option in the environment file
For the Docker setup, make the authentication and guest changes in the .env file using the variable names in the official Docker guide for the release you deploy, then restart the affected containers. On a Debian or Ubuntu install, make the equivalent changes in the Prosody and Jitsi Meet configuration files, following the handbook's quick start and token authentication pages. Keep every change in version control and do not edit generated files by hand. Confirm each variable name against your release, because names can change between releases. Check: the web, Prosody and Jicofo services start cleanly and the logs show the authentication module loading without errors.
Create the token issuer and test on a non-production host
Build the component that signs tokens. This is either a token service in your identity platform or a small service that maps directory group membership to Jitsi claims. Agree the claim set, including the issuer, audience, subject, room and moderator flag, along with how the signing key is stored and rotated. Run the full chain on a non-production host first so any mismatch between issuer, audience and room settings appears away from users. Check: a token signed with the test key is accepted on the test host, while a token signed with an unknown key or a wrong room claim is rejected.
Issue test tokens for moderator and guest roles
Using the agreed claims, issue one token for a moderator and one for a standard authenticated user, then attempt to join the authenticated domain with each. Test the guest path separately on the anonymous domain to confirm a guest cannot gain moderator controls. Have a second person run the same checks, since they often notice behavior the person who built the tokens overlooks. Check: the moderator can start and manage the room, the standard user joins without moderator controls, the guest joins only through the guest domain, and a join attempt with no token on the authenticated domain fails.
Retire the secure domain method on a set date
If an existing deployment still uses the secure domain method (username and password room creation), plan its removal. The handbook marks this method as deprecated for new installations. Identify which room links, accounts and integrations depend on it, notify those users and owners, and agree the cutover date with the business owner. On that date, disable the method in configuration, restart the services and keep a documented rollback path. Check: the old method no longer creates or admits rooms, token-protected room links behave as intended, and the guest domain still works.

What drives the effort of a Jitsi SSO project

This table lists the factors that change how much work a Jitsi SSO project takes, what each one means for your team, and how to keep it contained. Read it before asking for a quote, because the effort depends on the scope agreed in writing.

Driver	Why it changes effort	How to keep it down
Identity sources to bind	Each directory or login source needs its own mapping of users, groups and claims into Jitsi authentication, plus testing for each.	Start with one identity source and add others only after the first is in production.
Existing token issuer	If your identity provider can already issue Jitsi-compatible JWT tokens, the work is configuration. If not, a token service must be designed, built, secured and operated.	Reuse an existing token issuer where one can meet the required claims and signing setup.
Matrix estate size	A Matrix-based option ties sign-in to the Matrix user verification setup, so the number of homeservers, users and rooms to validate grows the test scope.	Confirm the Matrix setup is in scope only if your organization already runs it, and limit the first rollout to the homeserver that matters most.
Guest volume and invitations	Guests need access through the anonymous domain, and the way invitations are issued (links, calendar, external users) affects room rules and support questions.	Define a small set of guest invitation methods and document them before testing begins.
Existing secure domain users	Users who currently create rooms through the deprecated secure domain method need a new sign-in path, communication and a cutover plan.	Migrate users in waves by group, with a fallback date agreed in advance.
Number of environments	Test, staging and production each need their own identity configuration, certificates, secrets and sign-in checks, so every environment multiplies the verification work.	Keep environments as close to each other as possible and promote the same configuration through each stage.
Internal security review	Your security, identity and compliance teams need time to review token claims, signing keys, room access rules and guest handling before approval.	Share the design and the claim list early, and agree the review criteria in writing before build starts.

How the SSO setup differs by install method

Docker installs keep most SSO settings in the .env file alongside the compose configuration. The official Docker setup runs the web, prosody, jicofo, jvb, jigasi and jibri components as separate containers. From stable-11146 onward, the containers run rootless with read-only filesystems, so any file the authentication setup must write, such as a generated key, cache or log, needs a defined writable location that the container can reach. Plan those locations before you change authentication, and do not assume a container can write to its image layer.

Authentication mode: set the chosen method (JWT, LDAP, Matrix or the hybrid Matrix plus JWT mode) in .env, then recreate the affected containers.
Secrets: keep the JWT secret and LDAP bind credentials out of shared files, with restricted permissions on the host copy of .env.
Writable paths: mount host directories for any file the setup writes, because the root filesystem is read-only.
Ownership: confirm the UID and GID the containers run as can read the mounted files.
Image tags: pin every container to the same release so the components agree on authentication behavior.

Confirm the exact variable names, mount paths and mode values against the Docker guide for the release you run, because they can change between releases.

Protecting tokens, secrets and guest access

Identity settings decide who can start a meeting and what a token is allowed to do, so they need the same care as the servers themselves. The cards cover the signing secret, token settings, directory and verification sources, guest separation and certificates. Identity controls do not change what Jitsi encryption covers: end-to-end encryption applies to audio, video and screen sharing only, not chat or polls.

Keep the JWT signing secret out of source control

The shared secret that signs JWT tokens lets anyone who holds it mint a valid meeting token. Store it in your secrets manager or deployment vault, inject it into the .env file at deploy time, and keep it out of Git repositories, container images and CI logs. Set a rotation schedule that your security policy defines, and confirm that your identity system can roll to the new secret without a gap in meeting access.

Short token lifetimes and minimal claims

A token that lives longer than a meeting gives a leaked link more time to be reused. Ask your team to set a short expiry in the token issuer and to confirm the Jitsi token authentication handbook settings they use. Include only the claims the room needs, such as user name, room and moderator flag, and leave out profile data that Jitsi does not use. Test an expired token and a token for the wrong room before go-live.

Least-privilege LDAP bind account

When Jitsi authenticates users against LDAP, it uses a bind account to search the directory. Create a dedicated, read-only service account with access only to the user objects and attributes the login check requires. Do not reuse a domain administrator or an engineer's personal account. Document the account owner, store its password in your vault, and plan a review each time directory groups or access policies change.

Restrict Matrix verification to a trusted homeserver

The Matrix user verification option accepts accounts that a Matrix homeserver vouches for, so the homeserver you name becomes part of your trust boundary. Limit verification to the homeserver your organization operates or formally trusts, and confirm the setting in the Docker .env file. In hybrid Matrix plus JWT mode, check which path grants moderator rights. Ask your identity team to review account creation rules on that homeserver, since Jitsi inherits them.

Separate guest rooms from authenticated rooms

The Jitsi handbook recommends a separate anonymous domain for guests, which lets people join without a login while authenticated rooms stay on the main domain. Confirm that guests reach only the anonymous domain and cannot reach rooms that require tokens. Review which rooms can be opened to guests, and treat the guest domain as a public entry point in your access reviews and monitoring plans.

Keep TLS certificates valid

The Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video, and it warns that self-signed certificates cause problems, especially with mobile clients. Use a certificate issued for the meeting domain and the anonymous guest domain, and record each expiry date in your renewal calendar. Confirm that the identity provider's redirect and callback URLs also use valid HTTPS certificates, since a broken chain blocks sign-in.

How to test that only the right people can start a meeting

Run a short set of tests that show the system admits the right people and refuses everyone else, and run each one from a desktop browser and from a mobile client. The Jitsi handbook warns that self-signed certificates cause problems, especially with mobile clients. A test that passes in a browser with a trusted certificate can still fail on a phone that does not accept the certificate chain. If your users will join from iOS or Android, repeat every case on those platforms, and record the app version and certificate details for each run. Treat a certificate failure on mobile as a blocking defect, because users will report it as a login failure.

The core tests cover the token path. A valid JWT issued by your identity system should let an authorized user create a room, or join an existing one, from both browser and mobile. Then present an expired token, a token signed with the wrong key, and a token whose room or audience claim does not match the meeting. Each attempt should be refused, and the user should never reach the conference. Next, sign in as a person who exists in your identity system but is not in the LDAP group or Matrix space that grants meeting access, and confirm they are refused. Finally, remove a test user from that group and confirm that access ends at the next attempt.

Guest and legacy paths need their own cases. Open the authenticated domain as an anonymous visitor and try to start a room, including a room name you guess or copy from a previous meeting. The visitor should not be able to create it. Then confirm the separate anonymous guest domain works as your design intends: guests should join only rooms that an authorized host has opened. Last, test the former secure domain path after cutover. Attempts to log in with the old username and password room creation method should fail. Confirm the exact steps against your own configuration, since the removal work depends on how your deployment was installed and configured.

Refused attempts must leave a trace. For each negative test, find the matching entry in the Prosody log and the Jicofo log, and confirm the entry states the reason for refusal rather than a generic error. Confirm that these entries reach your central log store and that a security analyst can search them by user, room or source address. Then add a monitoring rule that alerts when failed logins from one account or source repeat within a window your security team sets. Test the alert in staging by repeating failed attempts and confirming that it fires. Keep the test results, timestamps, client versions and log excerpts together so an auditor or internal reviewer can check them later.

Questions buyers ask about Jitsi SSO and identity integration

Can our own team set up Jitsi SSO without a partner?

Yes, if your team already runs Jitsi Meet and owns the identity system that signs users in. The effort depends mainly on how many identity sources you connect, such as a directory plus a single sign-on provider, and how many environments need their own configuration, such as test, staging and production. Teams that have not worked with JWT signing keys or LDAP bind accounts usually spend most of their time learning the options and testing edge cases. Ask whether someone on your team can own the token signing keys, test sign-in from every browser and client you support, and sign off the change before users see it. If the answer is no for any of these, a partner can cover the gap, and the written scope will show which tasks stay with your staff.

How long does Jitsi SSO integration take to complete?

The duration depends on the scope agreed in writing, not on a fixed figure. The main drivers are the identity sources involved, whether you use JWT tokens, LDAP, Matrix verification or the hybrid Matrix plus JWT mode, the number of environments, how many browsers and clients must be tested, and how quickly your approvers review test results. A narrow change, such as one JWT integration in a single environment, takes far less time than a directory-backed rollout with guest access on a separate anonymous domain and a staged cutover. Ask any provider to list each phase, the dependencies it waits on, and which of your teams must be available for each one.

What does Jitsi SSO integration cost, and what is included?

The cost follows from the written scope. No price list applies. The components are discovery (reviewing identity sources, sign-in flows and existing room links), configuration (the Jitsi side, set in the .env file for Docker deployments), token or directory work (JWT claims and signing, or LDAP connection and user mapping), testing and handover (sign-in from each supported client and runbooks for your team), and recurring support for changes, upgrades and key rotation. Discovery, configuration and testing are normally one-time work. Support recurs. Costs rise with more identity sources, more environments and more client types to test. In a quote, ask for each component on its own line, which items are one-time and which recur, and which tasks your own staff perform.

What do we need to provide for a Jitsi SSO project?

Four things, before work starts: access, an owner, a test environment and a named approver. Access means working credentials or a supervised session with the identity provider or directory, including rights to create a test client or bind account. An owner must control the token signing keys: where they are stored, who can rotate them and how the Jitsi side receives the verification key. The test environment should match production closely enough to check sign-in, guest access and room creation. Name one approver for cutover who can accept the test results and set the go-live date. Also name who answers user account questions and who staffs the help desk during the switch. Ask the provider to confirm each item in the scope document.

Is JWT or LDAP the better choice for Jitsi authentication?

It depends on where your users and their identities live. JWT token authentication fits when your applications or identity system already sign users in and can issue a token that names the user and room permissions. The Jitsi handbook recommends JWT over the deprecated secure domain method. LDAP fits when your users are maintained in a directory and you want Jitsi to check usernames and passwords against it. Matrix verification, or the hybrid Matrix plus JWT mode, suits organizations that already run Matrix. To choose, ask where the authoritative user record lives, who can change it, and whether meeting hosts should use the same sign-in as your other applications. Then test the chosen option against your hardest case, such as a contractor who needs guest access through the anonymous domain.

Will Jitsi sign users in on its own, without an identity system?

It depends on the option you choose. With internal XMPP accounts, Jitsi manages its own user accounts and sign-in. With JWT tokens, your identity system performs the sign-in and passes a signed token that Jitsi trusts. With LDAP, Jitsi checks credentials against your directory. With Matrix verification, Jitsi relies on Matrix user verification. Jitsi does not replace your identity provider, so the question is which of these options your provider can reach. Confirm the supported integration path for your specific identity system before you commit to a design, and confirm how guests are handled, since the handbook recommends a separate anonymous domain for them.

What usually breaks in a Jitsi SSO setup after go-live?

Most failures come from token settings, clocks, certificates and guest paths. Common problems include tokens that expire too soon or are rejected because the server clocks disagree, claims that do not match the room or audience a user is trying to join, and signing keys that were rotated on one side but not the other. Certificates are another frequent cause: the Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video, and warns that self-signed certificates cause problems, especially on mobile clients. Guests who land on the authenticated domain may be turned away. Before cutover, test expired tokens, wrong claims, a rotated key, and a guest joining from a phone.

How DeployOpen scopes, builds and hands over Jitsi SSO work

DeployOpen plans, implements, documents and supports self-hosted Jitsi Meet inside your own infrastructure, including the authentication path that decides who can start a meeting. Work starts from a written scope, and the identity method, token issuer, guest handling and test evidence are agreed before any configuration changes reach production.

How we scope

Confirm which identity system will issue JWT tokens and which claims identify a user and their moderator rights.
Decide whether authentication uses internal XMPP accounts, JWT, LDAP, Matrix verification or the hybrid Matrix plus JWT mode.
Define guest access on a separate anonymous domain and document who may create rooms and how that is limited.

How we build

Configure the Jitsi Docker or Debian deployment with authentication settings in the .env file or server configuration.
Set up token signing, expiry and room claims, then test valid, expired and mismatched tokens against each path.
Retire any legacy secure domain setup on new installations and verify that unauthenticated users cannot start restricted rooms.

How we hand over

Deliver the written configuration, token contract and identity mapping with the rationale for each decision.
Provide a test record showing which accounts, tokens and guest flows were checked and the results observed.
Walk your operations and identity teams through token rotation, adding new domains and troubleshooting failed logins.

How we support

Offer ongoing support as a retainer covering authentication changes, identity system updates and Jitsi release upgrades.
Review token and access configuration whenever the identity provider, certificates or Jitsi release changes.
Confirm the support scope, response expectations and included upgrade testing in the written agreement before work begins.

Jitsi SSO and identity integration