I have an issue with JWT tokens. With my current setup users with the same jwt tokens can join in the conference and also can create new rooms with old urls with JWT token.
My question: Is it possible to use reservation system (Reservation System setup | Jitsi Meet) and use it to send JWT payload to my backend? If no - what else I can do to solve this issue?
The easy way to deal with this is to be more prescriptive with your token and only make it valid for a specific room (using the “room” claim) and time period (by setting “nbf” and “exp”). That way, someone with an old token cannot rejoin, or use it to create other rooms.
If users share their token with others, there’s really not a lot you can do technically without introducing other downsides. It’s akin to users sharing other kinds of auth details e.g. passwords and session tokens.
There are some posts in this forum where users are attempting to block concurrent joins using the same JWT token, but this could be inconvenient for users if they get abruptly disconnected and need to rejoin. The orphaned session from before the disconnect will hang around for a short period (60s?) before it times out, during which any extra logic you put in place to stop concurrent session from same JWT will stop the user from rejoining the meeting.
Not really. The reservation module only kicks in on first user join to decide if a new room is allowed to be created. It does not come into play at all once the room is running. And injecting JWT details in the reservation payload has its own set of issues.
The reservation system could however be beneficial if you need to issue tokens that have long validity periods (e.g. if meetings might overrun and people should still be able to join if meeting is still running) but restrict the re-creation of a meeting outside of a certain period once the meeting is over.
Very clear. Thank’s a lot for your response.