Allow chat creation from API but not from the host webpage

sparviere · April 3, 2020, 12:50pm

Hi, I successfully installed Jitsi-meet and it’s running on our server. I had to create the host and now everyone can access our website and create a room. I’m using the API to create new rooms and to let users join them. I don’t want the website to be accessible.
I thought about securing the room creation using authentication, but I fear that then the users that want to create a new room through my application (thus using the API) would be prompt to insert username and password. Also, I didn’t quite get it to work.
Is there a way to block the jitsi-meet interface and just use the API to interact with the server?
Any help will be very appreciated.
Thanks!

sparviere · April 4, 2020, 7:09pm

If anybody is also looking into this, the answer, at least for me, was to use the JWT token.

github.com

jitsi/lib-jitsi-meet/blob/master/doc/tokens.md

JWT token authentication Prosody plugin
==================

This plugin implements Prosody authentication provider that verifies client connection based on JWT token described in [RFC7519].
It allows to use any external form of authentication with lib-jitsi-meet. Once your user authenticates you need to
generate the JWT token as described in the RFC and pass it to your client app. Once it connects with valid token is considered authenticated by jitsi-meet system.

During configuration you will need to provide the *application ID* that identifies the client and a *secret* shared by both server and JWT token generator. Like described in the RFC, secret is used to compute HMAC hash value which allows to authenticate generated token. There are many existing libraries which can be used to implement token generator. More info can be found here: [http://jwt.io/#libraries-io]

JWT token authentication currently works only with BOSH connections.

[RFC7519]: https://tools.ietf.org/html/rfc7519
[http://jwt.io/#libraries-io]: http://jwt.io/#libraries-io

### Token structure

The following JWT claims are used in authentication token:
- 'iss' specifies *application ID* which identifies the client app connecting to the server. It should be negotiated with the service provider before generating the token.
- 'room' contains the name of the room for which the token has been allocated. This is *NOT* full MUC room address. Example assuming that we have full MUC 'conference1@muc.server.net' then 'conference1' should be used here.  Alternately, a '*' may be provided, allowing access to all rooms within the domain.
- 'exp' token expiration timestamp as defined in the RFC

This file has been truncated. show original