What's the current state of XMPP and OpenID Connect?

[fluchtkapsel@nerdculture.de]

What's the current state of XMPP and OpenID Connect? My web search returned that ejabberd is still considering if and how to implement and Prosody has experimental alpha-stage support via a module. I couldn't find anything conclusive in regards to XMPP clients. What's with Gajim(?) and Conversations? Or other clients? Are there any web clients supporting OIDC?

#jabber #xmpp #oidc #openidconnect

[daniel@gultsch.social]

@fluchtkapsel the answer depends a bit on what you are trying to achieve. Authenticate against a third party? Throw the password away and log in with a session cookie? Give access to third parties to data on the XMPP server?

We do the session tokens with FAST.
Prosody has some support for giving third parties access to (scoped) data on the XMPP server and clients (Conversations and Gajim) aren't involved here.

[fluchtkapsel@nerdculture.de]

@daniel I have Keycloak running and ponder if I want to go for Prosody again but authenticating against Keycloak this time. This means, users are created and managed in Keycloak. My previous projects with Keycloak used OIDC for authentication. But the clients should be able to authenticate via OIDC otherwise this would be futile 🙂.

[daniel@gultsch.social]

@fluchtkapsel Authenticating with oauth with a third party is not currently available. @mattj probably has the most insights into what steps we made into that direction yet.

Part of the problem is that we loose nice security features like channel binding by using web stuff.

[muppeth@fe.disroot.org]

@daniel@gultsch.social @fluchtkapsel@nerdculture.de @mattj@floss.social Sure but if someone already uses external auth, being able to add xmpp to the stack would bring extra security features like global 2FA.

Here is my use case. I use LDAP for authentication and currently in the process of adding keycloak for oidc. XMPP at this point needs to stay with LDAP only, while it would be an added feature for me if it would support openid

[daniel@gultsch.social]

@muppeth @mattj @fluchtkapsel Sticking with LDAP would at least on paper leave the door open for channel binding.

2FA could be added to XMPP w/o involving web stack stuff.

I'm not fundamentally opposed to oauth. I'm just pointing out that the use case of oauth is convenience rather than added security. If we implement it wrong me might even loose security (channel binding).

[fluchtkapsel@nerdculture.de]

@daniel @mattj I tried reading the XEP re channel binding but I don't understand what it's supposed to achieve. If you could explain it in a sentence or two I'd be grateful. If it's too complicated, that's fine, though.

[daniel@gultsch.social]

@fluchtkapsel @mattj Channel Binding ensures that client and server are in the same TLS session by mixing in unique stuff from the session into the password handshake. This is basically MITM protection for the TLS layer.

For more information the search keywords would be: SASL, SCRAM and Channel binding. The XEP is just negotiation and boring wrt the security aspects.

[daniel@gultsch.social]

@fluchtkapsel @mattj there is also this talk in German that explains my motivation behind my push towards channel binding:

https://gultsch.video/w/qzRh2nLk7EXdmqDxRmDuZW