Jitsi Meet OAuth Authentication

Hi everyone.
I need to use an oauth based external authentication service in the main jitsi meet domain. This service requires a client id, client secret and redirect url. Then when requested it returns a code that needs to be exchanged for a token in a new request.
I have all parameters to setup but don’t know how to implement it in prosody/jicofo.

If anyone has already a solution I’ll be thankfull.



Interested in this as well.

1 Like

Check this https://github.com/jitsi/jicofo/blob/master/doc/shibboleth.md

Thanks for answer. Instead of using shibboleth, I already have a service provider which gives authenticates the user and gives me the token.
What I need is the following:

  1. A user creates a meeting room
  2. As user needs to login, I need Jitsi redirects to oauth server.
  3. User approves the app’s request
  4. User is redirected back to Jitsi with an access token in the URL fragment

All i need is that instead of jitsi validating the user, it is done by an oauth server.

Hope you understand.


My authentication server is using OpenId Connect instead of pure OAuth. Its possible that jitsi authenticates using an openid connect client?


Like to have this too!

For getting oauth to work you need 2 things :

I have been struggling with it alot, and finally ( like an hour ago ) got it to work.

For me to get it successfully running with my Microfocus AccesManager i had to make some alterations in mod_auth_oauthbearer.

Still playing with the authorisation mechanism, as its not ‘working as expected’ as of yet, but making (slow) progress…whilst looking at the oauthbearer auth module i am enriching/changing it for the use i am after.

hope this helps …

Using OpenID (Apache or Nginx) worked

@namtel would you share the Apache / nginx OpenID config? Did you manage that guests get served a “waiting” page and are not required to log in?

It seems people have been able to get oauth authentication to work with some alterations and/or extra webserver config, but nobody has shared what sort of alterations are necessary.

Would somebody be willing to help me get this feature working? Eventually I want to integrate it with my own website, but first I’m just trying to make it work with github, since that’s what the mod_auth_oauthbearer docs use as an example.

So far, I’ve set up an app on github and configured oauth_client_id and oauth_secret in my VirtualHost. Pretty sure that much is right, but I have a few issues after that:

  1. The mod_auth_oauthbearer example auth_url = "https://api.github.com/applications/{{oauth_client_id}}/tokens/{{password}}" seems to be outdated…
    github’s docs suggest https://github.com/login/oauth/authorize?client_id={{oauth_client_id}}&redirect_uri={{see issue 2}}, but no matter what I enter, I always just get the normal login form in jitsi-meet, rather than being forwarded to an oauth login page.

  2. I don’t know what to enter for the callback url in the github app setup. I just entered the same as the homepage (e.g. https://jitsi.mysite.com), but I doubt that’s right… It would make sense for the callback url to be the actual meeting room page, but there’s no way to know that in advance when I set up the github app.

  3. I guess this is actually the same as issue 2… there doesn’t seem to be any code for an oauth callback endpoint handler anywhere in either mod_auth_oauthbearer or mod_sasl_oauthbearer to verify the oauth callback response and set the user identity in jitsi.
    So I guess I am supposed to write this functionality myself? I could write an endpoint handler externally, but then how would I integrate it back into the jitsi-meet client?

Hmm… actually, looking through the code some more, the plugin doesn’t seem to be using any oauth flow I recognize. There’s no redirect to the provider’s login page, just a server-initiated https request…I think it’s trying to get a password grant after getting the user’s login info. Maybe these plugins don’t even do what I want at all?

What I’m looking for is more like how Jitsi-meet handles youtube integration… I guess this is something I’d need to actually code into the jitsi-meet frontend(?)

…and then somehow convert that into a valid moderator authorization on the backend, based on user scope, maybe. This seems a lot more like development work, rather than simple mod configuration…

@mhonkoop, @namtel: What did you end up doing to make these mods work for you?


Looking through the jitsi-meet code, it looks like the oauth redirect login code I want is already there.
In /modules/UI/authentication/AuthHandler.js it looks like it will open an external auth url in a window to retrieve a token.
So it looks like I’ve been barking up the wrong tree…I guess I should be using the jitsi-meet-tokens package instead.

Is there any documentation on how to set this up? I’ve seen the docs that specify how to configure the back end to use tokens, but I haven’t seen anything about configuring the front end to retrieve a token using external auth.

i.e., how do I configure jitsi-meet to use doExternalAuth()? And what does my external auth endpoint need to look like? What parameters does it need to accept? What does it need to return? Does it return json data, or just redirect to the room url directly?

@damencho, is this something you could help me with?

@partap i had to abandon the oauth for a bit due to other obligations … will be picking up again

Your ‘endpoint-definition’ will depend on where your authorisation endpoint is.
In my case ( as described previously i am using a Microfocus AccessManager) , so the endpoint info i got from : https://www.netiq.com/documentation/access-manager-45-developer-documentation/oauth-application-developer-guide/data/metadata-endpoint-details.html

The issue i am/was facing before is that i could not get a/the redirect, so i fiddled around in the code of the oauth_bearer module to see if i could make the oauth ‘device-based’ … which works.

Downside is that no matter what you then use as user/password to create a conference it then gets authorised over oauth, as the device ( in our case the jitsi server itself) authenticates successfully.

So on the one hand i did get oauth to work, on the other hand i broke user-authentication completely.

Under normal circumstances ( depending on your IDP configuration) :

  1. you ‘hit’ the application, which will trigger the authentication process.
  2. this will trigger a/the redirect to your IDP for true authentication.
  3. now heres the tricky part in regard of what grants are configured on the IDP end, you can ask for just the authorisation code, or authcode + id_token and even a refresh-token, so dependant on whats configured you get bak ‘something’
  4. if your idp is only configured to give an authorisation code you will need to exchange this for a token, by talking to the ‘token’ endpoint.
  5. after having received the token, you can then talk to the ‘userinfo’ endpoint to retrieve your scopes, and thus the values you want to use within the application.
    => if you were to configure (on the IDP side) grants for both code and id_token (and possibly refresh_token) you can then skip the “token” endpoint and go directly talk to the ‘userinfo’ as you already have obtained the token needed to talk to it.

So there are different routes that need to be taken ( and ofc handled by the module as such)

Also what @namtel seems to have done is to not put the authentication in jitsi/prosogy , but rather in the above platform, which is NGNIX , and then handling the authentication on that level and passing it down to Jitsi.

I will need to investigate his approach on it ( did solve it on Apache webserver with a module for a customer i had)

Having issues quoting you on a previous post but …

  1. The mod_auth_oauthbearer example auth_url = "https://api.github.com/applications/{{oauth_client_id}}/tokens/{{password}}" seems to be outdated…
    github’s docs suggest https://github.com/login/oauth/authorize?client_id={{oauth_client_id}}&redirect_uri={{see issue 2}} , but no matter what I enter, I always just get the normal login form in jitsi-meet, rather than being forwarded to an oauth login page.

Defining the redirect-uri on the client-side is a security-mechanism, if you dont send it ( atleast for me) the IDP will send the responce to the uri entered on the IDP side … if you do send it it will be regarded as an additional validity check for your oauth request … so they MUST align !