Authentication with JWT only works when using "meet.jitsi" as "sub"

Install & Config
1

I have a jitsi instance that I would like to use exclusively from rocketchat using authentication with JWTs.

My jitsi instance is set up using docker-compose according to the documentation.

When I try to authenticate without rocketchat with a handgenerated token from jwt.io, this only works, when the component “sub” of the jwt is “meet.jitsi”. I am not able to use my real domain “mydomain.mytld”.

When I try to authenticate with rocketchat, prosody gives an error, saying
muc.meet.jitsi:token_verification error Token **** not allowed to join: 3e9f37643db79a029258710@muc.meet.jitsi/d6622762

In the client I see the error message “Sorry, you are not allowed to be here”.

When I decipher the jwt passed from rocketchat, I can see, that it uses the complete fqdn of the rocketchat instance as the “sub”, which is chat.mydomain.mytld.

Unfortunately there is no separate setting for the “sub” of the JWT in Rocketchat.

As far as I understand the jitsi documentation, it should be possible to use any “sub” in the JWT for jitsi.

If I set XMPP_MUC_DOMAIN to mydomain.mytld everything does work (both, rocketchat and jitsi use the same domain).

I would appreciate it, if somebody could clarify, if this actually is a solution or if I might have introduced other problems. Besides, it would be interesting to know, if this is an error in jitsi concerning the treatment of the “sub”. If not, the documentation should probably mention how to handle this situation. I imagine there are more applications like rocketchat, that generate JWTs based on some “sub” that is not easily configurable.

I have described this problem already in https://community.jitsi.org/t/jwt-tokens-install-guide, but did not get any reaction in the past 10 days, so I assumed it is not being monitored.

2

That is not true if subdomain verification is enabled.

3

Thank you very much for this hint. Setting JWT_ENABLE_DOMAIN_VERIFICATION=false solved the problem!

So I will keep this solution. Also I take from this that XMPP_MUC_DOMAIN (or XMPP_DOMAIN) should not be changed in cases like this one.

It would surely be very helpful to add this to the documentation in two places:

  • the env.example for the docker setup (by just adding JWT_ENABLE_DOMAIN_VERIFICATION=true, so this default becomes visible)
  • the deployment guide for docker; the fact that “meet.jitsi” is the default domain is mentioned but it is not clear, what that means
4

If it helps, as of the latest stable docker release (8252), JWT_ENABLE_DOMAIN_VERIFICATION now defaults to false.

It is however still enabled by default for non-docker installations.