Intent to deprecate and remove: external auth mechanisms

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

Regards,
Damien.

1 Like

Hello,

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.

Blockquote
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 https://example.com/angrywhalesgrowhigh?jwt=eyJhbR...ga5W4 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
Host: server.example.com
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.

2 Likes

@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

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.

E.g
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.