Authentication Failed

Hello! I’m quite aware that there’s already been asked a lot of questions of the same sort, but none of them helped me to solve an issue I’m facing right now. The question concerns an authentication part of jitsi integration. I think that it’s worthwhile to list all of the things I tried so far:

  1. I’ve already checked signature validity in debugger and it turns out that token is valid
  2. I have uncommented ENABLE_AUTH and JWT_APP_SECRET options in .env file
  3. I set values of ‘sub’ and ‘aud’ to localhost, inasmuch as the whole process of jitsi integration happens on localhost(I actually have no idea why would that ever work, but I noticed that people solve this issue by employing this pretty bizarre method)

But still, I see this irritating “Authentication Failed” message.

I should point out that jitsi itself runs in dockerized environment. So, what would help me in this particular situation? What should i attempt? Thanks in advance

Open the developer console the network tab before loading the page, load it and check the authentication error message in the bosh response or in the websockets messages (depends on what you use). There should be more information what’s wrong with the token.

@damencho, thanks for reply. Well, it turns out that password is required. I guess that i should change authentication type from password to jwt. Is it done in .env file? By the way, is it true that re-running of docker jitsi images is required in order to apply changes made in .env file? I know that question is somewhat silly, but it would be good to know anyway.

Well, i managed to fix this issue, but when i share conference with other people they need to provide authentication credentials such as username and password.

I completely forgot to write how I actually solved it. So, the problem was related to AUTH_TYPE option in .env file – in case of token authentication, it must be assigned to jwt. Do not forget to uncomment ENABLE_AUTH option. Then i checked the prosody logs and it turned out that issuer value was erroneous. At the end of the day, the solution turned out to be extremely simple – the value of issuer must match JWT_APP_ID value in .env.