Intent to deprecate and remove: external auth mechanisms

Hey all!

We’ve been reviewing our auth code while chasing some bugs and it’s… quite messy. We currently support a number of external auth mechanisms that we never use ourselves and are very poorly maintained as a result. They never even got mobile support or are usable in the Docker setup.

In order to simplify the auth flows supported in Jitsi going forward we intend to deprecate and remove the following external auth mechanisms:

  • external JWT in Jicofo
  • tokenAuthUrl based in Jitsi Meet
  • shibboleth

Once these are removed the supported auth mechanisms would be:

  • XMPP (internal, ldap, …)
  • JWT

In our experience (through JaaS for example) keeping JWT on the edge of auth has been sufficient for all scenarios. Users can generate a JWT and then launch Jitsi Meet with it. These tokens can be generated from a custom backend, Firebase, etc.

Before moving forward, we’d like to hear from those of you who might be using any of these today. Would you be ok migrating away from them? What would a reasonable timeline look like?


PS: Ping @Damien_FETIS (you are the only one we know using shibboleth).

1 Like

From what I understand from some posts, some users use “external JWT” with “guest virtualhost” to get “wait for host” message on UI.

Good point, thanks for raising it.

For a deployment that support only JWT auth only (no guest users, and no XMPP auth), what would a user journey look like if they land on the site without a token?

I believe at present the login dialog is show, which we found to be confusing to users.

For now we abuse the tokenAuthUrl option to redirect them to a static auth error page. Would be good to have a proper solution if we plan to drop tokenAuthUrl.

Good point. We have been thinking about passing some metadata so we know the auth type and can better react to it.

1 Like

Hi @saghul,

You’re right, we’re still using the Shibboleth in Jicofo Auth mechanism and I think there is also one or two other members of this forum that always use this configuration to secure their Jitsi-Meet.
I perfectly understand that we have to move to JWT mechanism. And we already start to work on a configuration with a JWT generator behind a Shibboleth Service Provider.

When do you think, you’ll remove these old auth mechanisms ?

Good to hear!

We haven’t talked about when to do it yet. How would in 2 stable releases sound? We’d deprécate it in the next and remove it in next-next. Thoughts?