feat(external-api): expose authentication

[Glaukom]

I do have a setup, where jitsi is used inside an iframe and I have different user roles, that are joining rooms. Whereas only users with the role "support" or "lecturer" can be moderators and they have to authenticate in order to "open up the room", like in real school, others shouldn't be able to.

To achieve a comfortable, but also secure auth process, I exposed the authentication from the LoginDialog Window, to login automatically via an external api command. So I can provide login credentials from a backend api or similiar and the user doesn't have to authenticate manually.

[jitsi-jenkins]

Hi, thanks for your contribution!
If you haven't already done so, could you please make sure you sign our CLA (https://jitsi.org/icla for individuals and https://jitsi.org/ccla for corporations)? We would unfortunately be unable to merge your patch unless we have that piece :(.

[damencho]

@saghul WDYT?

[saghul]

I feel strongly -1 on this.

We have a long term goal to drop all authentication mechanism except JWT: https://community.jitsi.org/t/intent-to-deprecate-and-remove-external-auth-mechanisms/115332 -- In that thread we first started with the idea of keeping XMPP internal auth and JWT, but then decided to just keep JWT and leave it up to auth systems such as Authelia or Keycloack to use whatever backend they want.

Exposing this goes in the opposite direction. Not to mention the potential for brute forcing passwords.

I think this can be accomplished with tokens. Perhaps what we need is a way to refresh the token, which I'd be fine with.

[Glaukom]

@saghul The only other way to authenticate without having to setup jwt/token whatever, is to use the xmpp_override_xyz feature, which is unreliable and also insecure

[saghul]

As I said, we are slowly moving towards a single mode for auth: JWT. I'm afraid that is not up for debate.

It's the most versatile since you can use any mechanism behind it, and generate a token for each user as necessary. Plus we actually use it, so it won't break every other release because we neglect it, as it happens with XMPP auth today.

I know this is not the answer you were looking for, I do however hope you understand we make these decisions with the broader project scope in mind.

[Glaukom]

@saghul Thank you. Indeed, not exactly what I hoped for. But I guess you've all been through the whole auth topic. 😉 Is there a place where you guys have something like a roadmap?

[saghul]

Alas we don't.

This is a long term goal and we have t been able to make much progress on it TBH.

We won't rip it out overnight, rest assured.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.