Intent to deprecate and remove: external auth mechanisms

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?

Hi @saghul,
That’s a fine roadmap for the Big Auth Refactoring.

We’ve made some test to deploy a simple solution for the SAML to JWT part : GitHub - Renater/Jitsi-SAML2JWT: A projet to easily use SAML authentification with JItsi-Meet JWT authentification.
And with the tokenAuthUrl parameters it works fine.

We are ready to test the future release.


That is great news!

If you’d like, I think having it linked here would be useful to others: Third-Party Software | Jitsi Meet

1 Like

It’s a very good idea.
I have just created a PR for this.


1 Like


We also use the existing shibboleth auth mechanism and we study a migration to JWT auth based. In fact, we are not familiar with shibboleth auth and we just use it to its support of SSO SAML protocol. Our IDP provider also support some other SSO protocols and we choose to implement our own CAS to JWT auth provider for Jitsi Meet :

We successfully deployed it on our test infrastructure and successfully open a conference by manually provided a JWT in the room URL. However, we would like to make Jitsi Meet automatically redirect user to our auth provider when it want to authenticate a user (it’s actually the behavior with shibboleth).

We tried to use the undocumented tokenAuthUrl, but it seem to have no effect. I tried to read the Jitsi Meet code, but I can’t locate the JitsiMeetJS.util.AuthUtil.getTokenAuthUrl method (called in react/features/authentication/functions.js).

Could you give me some information on how automatic JWT auth redirection work ? In fact, it seem me important to well document this point (and all the JWT auth mechanism) before deprecate other external auth mechanisms.

PS: we are using the latest Jitsi Meet version (2.0.7648).

The plan is to NOT support this use case. Applications need to supply a token in the URL or depending on how the server is configured will get an error when trying to join.

This will cause a regression (at least) for shibboleth authentication users: Today, when a user creates a conference, he gets a popup telling him that the conference has not started yet and a button “I’m the host”. If he clicks on this button, he will be automatically redirected to the connection interface. It seems to me that this behavior is fine and it will be great if Jitsi Meet keep a solution to implement that.

Is it really not possible to persist the tokenAuthUrl parameter?

That has never worked on mobile, for instance. The sibboleth usage has been anecdotal at best, that’s why we are trying to simplify things here.

Now, one thing I realized is that, in an SSO scenario it’s true we need something like that.

It will likely not be there day one (we’ll do this in stages) but we’ll consider it.

It will likely not be there day one (we’ll do this in stages) but we’ll consider it.

Nice and you are right about SSO auth on mobile. Do you think that it’s possible to wait to have something like that (at least on workstation, not for mobile) before removing external auth mechanisms (like sibboleth) ? May be the tokenAuthUrl existing solution could be sufficient for now and we just have to add some doc about this existing solution (even if it should be replaced in the future, we just need to specify it).

I’m not sure, the reason for this discussion is for us to refactor and consolidate some connection related code, not sure we can keep this around while doing that, but I’ll try.

@saghul I appreciate the heads up on changes like this. We are using straight JWT as described here and even though we are not using it currently, fwiw I always found the tokenAuthUrl option useful.

I have 2 questions:

  1. Now that some time has passed since the original post, do have a (high-level) time line for when these changes may happen?

  2. Regarding JWT… When you say:

You’re talking about joining a meeting using as described here?

@saghul, what do you think about passing some data as querystrings to the authError page?

When user has not a valid token, she is redirected to authError.html. If some data (such as room, jwt, etc) can be accessible in authError page then it may be possible to add some custom logic.

This can be easily achieved with sessionstorage, we alread have similar thing for the close page.

Hey there @corby !

1- Not yet TBH. I think the scope is clearer now, which is at least some progress.

2- Yes and no :slight_smile: Yes, that’s what I was suggesting, but no, as I said on my next message that would work for SSO so tokenAuthUrl seems like a valid thing to do still, but in a simpler manner I hope.

Great that you are looking at improving the auth mechanisms, much appreciated!

From our perspective(enterprise) the best method of providing and consuming JWTs is via the HTTP header Authorization with the Bearer auth mechanism. This way there is no need to present the jwt in the URL with “?jwt=” which adds complexity.

GET /resource HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV…r7E20RMHrHDcEfxjoYZgeFONFh7HgQ

We recommend allowing this method as it is a common method of providing jwt tokens to web applications. Any plans on adding this to the roadmap?

How would a web application read the token from that header though? Note we need the token both in the frontend and backend.

@keda82 On the contrary, the Authorization header approach wouldn’t work at all. 99% of the time users are brought to a Jitsi Meet conference with a JWT in the URL one of these ways:

  • URL containing the JWT is shared directly via IM, email, etc
  • User is linked or redirected from another application or web page to the URL containing the JWT
  • <iframe> is presented to user embedded within another application, with the URL containing the JWT being the source of the iFrame

In each of these cases, the web browser is the one doing the GET request, with the only input being the URL.

The JWT is needed by the JS running in the browser, not by the HTTP server (which is just serving up the static HTML/CSS/JS that makes up the Jitsi Meet client). The JS running in the browser eventually sends the JWT as authentication when making the XMPP connection to Prosody on the backend.