Failed Jitsi Authentication after Token Plugin

Hi All,

We recently added the jitsi token authentication token to our Jitsi, because we wanted to introduce jwt authentication. I’m not sure if the problem is due to the plugin configuration, because trying to call the jitsi room with an apparently valid token I’m getting a red alert “Auhtentication Failed”. So could please some one help me ? The token is signed with the same app_secret used in prosody.cfg.lua and contains the needed properties. How can I ensure that it’s not related or it’s related to the token ? I expected that when I try to access a room without the token i should an alert or something like that (as i have seen in some tutorials, but from the console i see this :

“2021-04-09T16:16:26.743Z [modules/xmpp/strophe.util.js] <Object.r.Strophe.log>: Strophe: Server did not yet offer a supported authentication mechanism. Sending a blank poll request.”

And i see a black window with no camera and no video. Is that normal that I get this if i try to access a room without token or should it behave differently ? This makes me unsure when i try to access a room with an apparently correct token, i’m not sure if the problem is related to the token itself or the plugin installation (which might be wrong due to that message).

Thanks in advance


Check prosody logs for errors.

Hi , thanks for your fast response.

I checked both by accessing it via token and without token and it actually get updated the prosody log with the following error only if i access the room without token

Apr 09 16:55:01 mod_bosh info New BOSH session, assigned it sid ‘12d7f0c9-404d-4921-98cd-9d6a4b108132’
Apr 09 16:55:01 bosh12d7f0c9-404d-4921-98cd-9d6a4b108132 warn No available SASL mechanisms, verify that the configured authentication module is working

But with the token, it’s not getting update the log, so I suppose it’s not about the token validity but the configuration or installation of that plugin , correct ? Could please help me in that direction ?

Thanks in advance

But do you see any errors when you restart prosody?
Sometimes it cannot load and same error is seen …

from the logs by restarting prosody there is no such error,

Apr 09 18:57:30 c2s55900f692110 info Client connected
Apr 09 18:57:30 c2s55900f692110 info Stream encrypted (TLSv1.3 with TLS_AES_256_GCM_SHA384)
Apr 09 18:57:30 c2s55900f692110 info Authenticated as
Apr 09 18:57:30 jcp55900f717940 info Incoming Jabber component connection
Apr 09 18:57:30 info External component successfully authenticate

Is there any missing parameter in the prosody config file to be set in order to make working this token plugin and more specifically related to that error that i reported form the logs ?
I followed the guide lines provided here, regarding the parameter to se on the prosody config file:

i actually get also some logs when trying to access with a token as well:

Apr 09 19:17:48 mod_bosh info New BOSH session, assigned it sid ‘6c5afbb9-66ee-4fb6-820e-d9a3ea42731a’
Apr 09 19:17:48 bosh6c5afbb9-66ee-4fb6-820e-d9a3ea42731a info BOSH client disconnected: session close

This is what i get instead from the brwoser console,

2021-04-09T19:17:48.562Z [connection.js] <a.d>: CONNECTION FAILED: connection.passwordRequired
Logger.js:154 2021-04-09T19:17:48.596Z [features/base/connection] connection.passwordRequired

You can open the developer console and look at the response with the error in the Network tab, normally the error contains more information, if the jwt token has problems …

Already checked, no request failed on the network tab , all successful response code but still the “Authentication failed” on the jitsi window and those errors in the developer console.

Can be these parameter useful consider_bosh_secure c2s_require_encryption in regards to the error " No available SASL mechanisms, verify that the configured authentication module is working" ??

Thank you again for your support

No not a failed request, the xmpp error response in the bosh messages will contain some info, to look it up.

I don’t clearly remember what was the error when this was not set …

But normally you will see no sasl mech error message if the auth mechanism that is configured is somehow not loading.


sorry I’m very new to Jitsi, did you mean as “bosh messages” in the network tab, those tracked as “http-bind…”, because I don’t see otherwise where i can find these on the network tab. Btw clicking on one of them I get this:

body wait=‘60’ authid=‘cd8912bc-f12e-4343-b316-bb53616d5b5b’ hold=‘1’ xmlns:xmpp=‘urn:xmpp:xbosh’ secure=‘true’ xmpp:version=‘1.0’ from=‘’ polling=‘5’ inactivity=‘60’ xmlns=‘’ ver=‘1.6’ requests=‘2’ xmlns:stream=‘’ sid=‘cd8912bc-f12e-4343-b316-bb53616d5b5b’><stream:features xmlns=‘jabber:client’>PLAINSCRAM-SHA-1</stream:features>

I can forward you in case the Token Schema/Structure and Prosody Configuration, thank you

Should I enable any additional module ? This “bosh” module is actually commented on the HTTP Module section, need to be decommented in order to make working the JWT Auth ?

---------- Server-wide settings ----------
– Settings in this section apply to the whole server and are the default settings
– for any virtual hosts

– This is a (by default, empty) list of accounts that are admins
– for the server. Note that you must create the accounts separately
– (see Creating accounts – Prosody IM for info)
– Example: admins = { “”, “” }
admins = { }

– Enable use of libevent for better performance under high load
– For more information see: libevent – Prosody IM
–use_libevent = true

– Prosody will always look in its source directory for modules, but
– this option allows you to specify additional locations where Prosody
– will look for modules first. For community modules, see
– For a local administrator it’s common to place local modifications
– under /usr/local/ hierarchy:
– plugin_paths = { “/usr/local/lib/prosody/modules” }
plugin_paths = { “/usr/share/jitsi-meet/prosody-plugins/” }

– This is the list of modules Prosody will load on startup.
– It looks for mod_modulename.lua in the plugins folder, so make sure that exists too.
– Documentation for bundled modules can be found at: Prosody Modules – Prosody IM
modules_enabled = {

-- Generally required
	"roster"; -- Allow users to have a roster. Recommended ;)
	"saslauth"; -- Authentication for clients and servers. Recommended if you want to log in.
	"tls"; -- Add support for secure TLS on c2s/s2s connections
	"dialback"; -- s2s dialback support
	"disco"; -- Service discovery

-- Not essential, but recommended
	"carbons"; -- Keep multiple clients in sync
	"pep"; -- Enables users to publish their avatar, mood, activity, playing music and more
	"private"; -- Private XML storage (for room bookmarks, etc.)
	"blocklist"; -- Allow users to block communications with other users
	"vcard4"; -- User profiles (stored in PEP)
	"vcard_legacy"; -- Conversion between legacy vCard and PEP Avatar, vcard

-- Nice to have
	"version"; -- Replies to server version requests
	"uptime"; -- Report how long server has been running
	"time"; -- Let others know the time here on this server
	"ping"; -- Replies to XMPP pings with pongs
	"register"; -- Allow users to register on this server using a client and change passwords
	--"mam"; -- Store messages in an archive and allow users to access it
	--"csi_simple"; -- Simple Mobile optimizations

-- Admin interfaces
	"admin_adhoc"; -- Allows administration via an XMPP client that supports ad-hoc commands
	--"admin_telnet"; -- Opens telnet console interface on localhost port 5582

-- HTTP modules
	--"bosh"; -- Enable BOSH clients, aka "Jabber over HTTP"
	--"websocket"; -- XMPP over WebSockets
	--"http_files"; -- Serve static files from a directory over HTTP

-- Other specific functionality
	"posix"; -- POSIX functionality, sends server to background, enables syslog, etc.
	--"limits"; -- Enable bandwidth limiting for XMPP connections
	--"groups"; -- Shared roster support
	--"server_contact_info"; -- Publish contact information for this service
	--"announce"; -- Send announcement to all online users
	--"welcome"; -- Welcome users who register accounts
	--"watchregistrations"; -- Alert admins of registrations
	--"motd"; -- Send a message to users when they log in
	--"legacyauth"; -- Legacy authentication. Only used by some old clients and bots.
	--"proxy65"; -- Enables a file transfer proxy service which clients behind NAT can use


– These modules are auto-loaded, but should you want
– to disable them then uncomment them here:
modules_disabled = {
– “offline”; – Store offline messages
– “c2s”; – Handle client connections
– “s2s”; – Handle server-to-server connections

– Disable account creation by default, for security
– For more information see Creating accounts – Prosody IM
allow_registration = false

– Debian:
– Do not send the server to background, either systemd or start-stop-daemon take care of that.

daemonize = false;

– Debian:
– Please, don’t change this option since /run/prosody/
– is one of the few directories Prosody is allowed to write to

pidfile = “/run/prosody/”;

– Force clients to use encrypted connections? This option will
– prevent clients from authenticating unless they are using encryption.

c2s_require_encryption = false

– Force servers to use encrypted connections? This option will
– prevent servers from authenticating unless they are using encryption.

s2s_require_encryption = true

– Force certificate authentication for server-to-server connections?

s2s_secure_auth = false

– Some servers have invalid or self-signed certificates. You can list
– remote domains here that will not be required to authenticate using
– certificates. They will be authenticated using DNS instead, even
– when s2s_secure_auth is enabled.

–s2s_insecure_domains = { “insecure.example” }

– Even if you disable s2s_secure_auth, you can still require valid
– certificates for some domains by specifying a list here.

–s2s_secure_domains = { “” }

– Select the authentication backend to use. The ‘internal’ providers
– use Prosody’s configured data storage to store the authentication data.

– authentication = “internal_hashed”
authentication = “token”

This is a sample token

“room”: “*”,
“sub”: “”,
“nbf”: 1617919200,
“exp”: 1649541263,
“iat”: 1618005263,
“iss”: “”,
“aud”: “jitsi”

Which signed with the same key which is set on the app_Secret field, and app_id is equal to my iss property.

I noticed just another thing, not sure it can imply something, The Server where the Jitsi Istance has a different time in regard to the application which is trying to access the jitsi room, maybe it’s not related, but just noticed

Yes, http-bind find which one is the error, one of the last messages and you will see in it what is the problem. The issuer looks suspicious to me, but it is ok if you had set it as accepted issuer.
The prosody config you pasted is the general one, not the one that jitsi-meet created.


that prosody configuration is from my prosody.cfg.lua config file within our server, so what do you mean is the general one (i just did not copied the section about the virtualhost ,app_Secret ect…)? this is from our server, are the modules ok? or should be enabled some additional ones and then restart the service (as i noticed this bosh module is commented, should it be acitvated for this mechanism to work) ?
About the http-bind/bosh response i copied it in the previous thread, i’m getting some html within a body tag in the Response (see above for the entire html piece). I notice this piece especially:

…mechanism>PLAIN</mechanism… …mechanism>SCRAM-SHA-1 </mechanisms…

I just inserted some dots to make it readable. Is this mechanism related to the authentication method ? Because I see it twice, like PLAIN should be without authentication and the second one should be related to jwt token ? Is that normal having two entries under that tag? Not sure why there are two mechanism, can they disturb each other ?


No, these are normal. Well the config as pasted is not readable and to be able to tell something the whole file is needed … mask any password and domain for privacy … But check the last http-bind messages …


i’m not sure from where you deduce that these are “general”, as i said this config file is form our server, unless you re referring to another file. I’m acutally talking about prosody.cfg.lua. Btw i have attached it, with masked info in order to chek the settings. And in the previous messages i also mentioned the responses which refers to http-bind… they are also attached, i attached in some notepads the html which i get as response (that one that you can see on the screenshoots)…thank you again for your support prosody.cfg - Copy.lua.txt (9.8 KB)

ResponseHttpBind1.txt (587 Bytes) ResponseHttpBinnd2.txt (116 Bytes)

This is the main prosody config, show your jitsi-meet one with your virtual hosts and token config

prosody.cfg - Copy.lua.txt (9.8 KB)

The info about the Virtual Host and token config was on the bottom of the file just masked with some ****…, i reattached it with only the app_secret masked, so i think everything which is needed (http-bind responses are attached in the previous threads…) Thanks

I don’t understand this is totally wrong … how did you install jitsi-meet?
The template we use is this:

Your prosody config should look like this.

i’m developer, that was done by other persons, It’s not “totally wrong” as you say :wink: …because Jitsi was perfectly working before this plugin, we’re just trying to make it work as this guide line here with this plugin:

(and you can see clearly the parameter involved for the token authentication on our file)…