Intent to deprecate and remove: external auth mechanisms

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?

1 Like

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.


@jbg I appreciate this is the way Jitsi is designed today, I am sure for good reasons in the past.

Many web applications accept HTTP header as authentication which results in the user being prompted with authentication before they even get access to the actual web application, the token is passed on to the application through the HTTP header.

See this as a feature request/suggestion to design changes going forward. We strongly believe that this will increase the security level of the authenication process for the product. E.g one could limit the exposure of your Jitsi-service to the internet to prevent/limit attack surface.

This would require a redesign, fully understand this, and might take time to implement. But please put some consideration in to this as we are not the only company out there with these requirements :slight_smile:

let me know if I should post an issue on this

1 Like

If you decide to post an issue, ensure first that you clearly understand the use-cases I described in my previous post, which should help you to understand the motivations for the ability to pass the JWT in the URL. You should also learn about the architecture of Jitsi Meet and how (and more importantly, why) it differs from the “web applications” that you may be used to.

The goal with JWT in the query string is to make it possible to provide a link to a user which contains the authentication token. If you remove it from the query string, you need to provide the authentication token to them another way. Saying “in the Authorization header” isn’t an answer, because for example this URL could be (often is) being passed to the user over an email.

Actually, within the Jitsi Meet application, the authorization is being sent to the backend through an equivalent of the Authorization header, it’s just that the backend protocol isn’t HTTP, it’s XMPP, so it uses XMPP’s mechanism for authentication.

About your company’s requirements, you could consider passing the JWT a different way than the URL. When you’re embedding Jitsi into another application, you can consider JWT as being the way you pass the knowledge about the user that your application has from its own authentication to Jitsi, which means you can do your own authentication of the user via whatever mechanism you want, and then your application backend signs a JWT for Jitsi, and delivers it to your frontend which passes it through the iFrame API to Jitsi, or passes it directly to lib-jitsi-meet. It never needs to appear in a URL when you’re doing your own integration like this; you’re free to authenticate the user however you see fit.

Regarding attack surface, do note that there is not really any meaningful difference in attack surface when you just move something between HTTP query string and HTTP header. They are both in the HTTP request separated by a few newlines, and both protected by TLS if you’re using it. The main attack surface difference is around shoulder-surfing, which would be quite challenging to achieve with a JWT, even if recording the screen, considering that the entire JWT doesn’t fit in the visible portion of the address bar. The presence of the JWT in browser history is ameliorated by Jitsi by replacing the history entry on load to remove the JWT. You can eliminate that shoulder-surfing/history risk entirely in your integration by the approach described in the previous paragraph.

There is no method in the JavaScript WebSockets API for specifying additional headers for the client/browser to send.

@jbg @damencho Really appreciate you taking the time to explain the current layout and limitations!

We now understand that what we are looking for cannot be provided by Jitsi in near future. Just for future reference we´d like to describe our usecase, hopefully this will give some insights for the roadmap ahead!

Our use case might be uncommon in the sense that we want all users to be authenticated before you are even allowed to access any of the Jitsi components. An attendee that gets a meeting link sent to them will first be required to authenticate themselves before they get access.

Client → meeting URL → redirect to external IdP → log in → generate jwt → pass jwt in authorization header → access to jitsi web or directly to the /meetingname

In regards to attack surface HTTP query vs HTTP header RFC6750, section 2.3 raises some security concerns regarding URI query method.

We also want to limit unauthenticated trafic to Jitsi as much as possible. This way we can get the tools to e.g steer of ddos attacks, block hacker attacks or malicious code before it hits the application and infrastructure around it.

TURN is required for all meetings and jvbs are not exposed to the internet.

From what I can tell from @jbg the only way to reach parts of this goal with the current architecture of Jitsi is to build your own “frontend” and then pass on jwt etc to the iFrame API to Jitsi, or pass it directly to lib-jitsi-meet

You need to make sure first that browsers implement setting headers to websocket connections. This is the first limitation you are facing and that needs changes in the spec of websockets The WebSocket API (WebSockets) - Web APIs | MDN and then being implemented and released by the major browsers.
After this step is done, you can proceed to changing the app and the code.

Note to myself and @saghul. We may drop the way we do currently waiting for host to join and use lobby for that.


Oh, me likey!

This is pretty much what the current tokenAuthUrl config option does. Redirects the user to a service capable of generating a token. As others have mentioned passing the token in the auth header is not going to work though, it would go on the URL.

While that is valid, the solution is simple: to use a hash parameter instead of a query parameter, since those are not sent to the server.

In practice, however, we have not had any problems with out current setup.

The above already takes care of it. If no token is provided the user is redirected away.

Out of curiosity: why are you doing this? the TURN servers do need access to the JVBs still.

Is tokenAuthUrl safe to use or will it be deprecated in the future? From what I can tell this is an undocumentet feature, is there any unofficial documentation available :slight_smile:

Its connected to our requirement of minimizing exposure of the Jitsi application and infrastructure components. TURN will act as a “reverse proxy” in this case. Only authenticated trafic(valid token) will pass from TURN to jvb. Unauthenticated trafic gets dropped at TURN server

As I mentioned in Intent to deprecate and remove: external auth mechanisms - #16 by saghul we’ll likely make that work for SSO kind of scenarios.

I see. Note that since users don’t talk to the JVB directly but via Jicofo, it would not be possible to create a new session without a valid token.

@saghul @jbg we failed with plan a(automating injecting ?jwt= before the meeting). Moving to plan b, is there any documentation or guides available for tokenAuthUrl that you can point us to?