Jitsi SSO with Okta: SAML Single Sign-On for Jitsi Meet

Our old blog split this setup into three articles: one for Okta, one for Jitsi's JWT and guest settings, and one for the middleware. You needed all three open in tabs to get anywhere. This guide puts the whole thing on one page and updates the parts that have changed since 2023, most importantly how Jitsi's token authentication is configured.

The goal: people in your organization click "I am the host", sign in with their Okta account, and the meeting starts. Guests join without any account.

How Jitsi SSO works with Okta

Jitsi Meet has no SAML support, and it doesn't need any. It trusts signed JSON Web Tokens. So the job is to turn an Okta SAML login into a JWT that Jitsi accepts, and a small middleware does exactly that:

1. A host opens a meeting on meet.example.com and clicks to log in.
2. Jitsi sends the browser to the middleware at sso.example.com, with the room name in the URL.
3. The middleware, a Shibboleth service provider, sends the browser to Okta.
4. The user signs in to Okta, which posts a SAML assertion back to the middleware.
5. The middleware creates a JWT signed with the secret Jitsi knows, and redirects the browser back to the room with the token.
6. Prosody validates the token, and the host is in.

The middleware in this guide is Jitsi-SAML2JWT by Renater, the French research and education network. It is open source, still maintained, and runs in Docker. You will need three names: meet.example.com for Jitsi, sso.example.com for the middleware on its own server, and your Okta organization.

Jitsi OAuth2 and OIDC options

Jitsi has no OAuth2 or OpenID Connect support of its own either, so those routes have the same shape: an adapter finishes the login with your provider and issues the JWT. Which protocol you use is decided by that provider, not by Jitsi. Okta speaks both, and SAML is the choice here because Jitsi-SAML2JWT is maintained and has the fewest moving parts. Starting from Keycloak, Authentik or another OIDC-first provider, take the OIDC route instead.

Step 1: Turn on token auth for Jitsi Meet SSO

Start from a working Jitsi Meet install (see installing Jitsi Meet on Ubuntu). Install the token package:

sudo apt install -y jitsi-meet-tokens

It asks for an application ID and an application secret. Pick an ID such as jitsi-okta and generate a long secret with openssl rand -hex 32. Write both down; the middleware needs them in step 3. The package switches Prosody to token authentication for you. Open /etc/prosody/conf.avail/meet.example.com.cfg.lua and check the main VirtualHost looks like this:

VirtualHost "meet.example.com"
    authentication = "token"
    app_id = "jitsi-okta"
    app_secret = "YOUR_LONG_SECRET"
    allow_empty_token = true

allow_empty_token = true is what lets guests in without a token. Add the guest domain after it:

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

In /etc/jitsi/meet/meet.example.com-config.js, set the guest domain and point the login button at the middleware:

var config = {
    hosts: {
        domain: 'meet.example.com',
        anonymousdomain: 'guest.meet.example.com',
        // ...
    },
    tokenAuthUrl: 'https://sso.example.com/redirectWithToken?room={room}',
    // ...
};

Jitsi replaces {room} with the meeting name, so the user returns to the right room after signing in.

sudo systemctl restart prosody jicofo jitsi-videobridge2

Step 2: The Okta SAML app

In the Okta Admin Console (Okta's SAML app setup guide documents the same screens, if one of these fields has moved since):

1. Go to Applications, then Create App Integration, and choose SAML 2.0.
2. Name it, for example "Jitsi Meet", and click Next.
3. Set Single sign-on URL to https://sso.example.com/Shibboleth.sso/SAML2/POST.
4. Set Audience URI (SP Entity ID) to a unique identifier, for example https://sso.example.com/shibboleth. You reuse this exact string in step 3.
5. Under Attribute Statements, add urn:mace:dir:attribute-def:mail mapped to user.email and urn:mace:dir:attribute-def:displayName mapped to user.firstName (or a full-name expression).
6. Finish. On the app's Sign On tab, copy the Metadata URL and note the Okta issuer / entity ID shown in the IdP metadata.
7. On Assignments, assign the people or groups allowed to host meetings.

That last step doubles as access control. Anyone not assigned to the app never gets a token, so it is the simplest place to limit hosting to one department.

Step 3: The SAML-to-JWT middleware

On a separate server with Docker installed, and with sso.example.com pointing at it:

git clone https://github.com/Renater/Jitsi-SAML2JWT.git
cd Jitsi-SAML2JWT
cp .env_ref .env

Edit .env. The reference file documents every variable; these are the ones this setup depends on:

Generate the certificates the service provider needs, then build and start it:

cd tools
bash init_certificates.sh
cd ..
docker image build -t jitsisaml2jwt .
docker compose up -d

The self-signed certificate is fine for signing SAML messages. For the HTTPS site users actually visit, put a trusted certificate in place, or run it behind a reverse proxy with Let's Encrypt, so people don't see a browser warning halfway through signing in.

Step 4: Test the whole flow

1. Open https://meet.example.com/okta-test in a private browser window.
2. Click I am the host (or the login button).
3. You should land on Okta, sign in, and return to okta-test with the meeting started.
4. Join the same room from another browser without logging in. That participant should get in as a guest.

If step 3 bounces you around without returning, the problem is between the middleware and Okta. If you return to the room but Jitsi still asks you to log in, the problem is between the middleware and Prosody. That split halves the debugging.

When it doesn't work

Once SSO works, don't stop at authentication. Room creation is only one control; lobby, end-to-end encryption and exposed ports are covered in Jitsi Meet security best practices. And if you want to understand exactly what goes into the token, JWT integration with Jitsi and creating a JWT token explain the claims.

Related Articles

Jitsi Meet SSO with Keycloak: OIDC Setup Guide

Jitsi Keycloak SSO, the actual setup: since Jitsi has no native OIDC support, this covers the adapter that bridges Keycloak login to the JWT Prosody expects.

By Binuka Ranatunga • Meetrix.io

Jitsi Authentication Methods: Secure Domain, JWT, LDAP, and SSO

How Jitsi Meet authentication works: JWT token authentication (the current default), the deprecated Secure Domain method, LDAP, and SSO/OIDC through an identity provider like Keycloak.

By Hiruna Kumara • Meetrix.io

Integration of JWT with Jitsi

Learn how to integrate JSON Web Tokens (JWT) with Jitsi Meet for enhanced security, authentication, and access control in your video conferencing platform.

By Hiruna Kumara • Meetrix.io

Jitsi LDAP Authentication: OpenLDAP and Active Directory

Set up Jitsi LDAP authentication with Prosody and saslauthd for OpenLDAP or Active Directory: how the LDAP login flow works, LDAPS, guests and group filters.

By Hiruna Kumara • Meetrix.io