Skip to content

Conversation

@ItsOnlyBinary
Copy link

@prawnsalad
This spec provides a way for web services hosted externally to an IRC server to authenticate users that are connected to the IRC server by making use of the standard JWT tokens (https://jwt.io/).

This allows a web service to do things such as:

* Granting admin access to a networks wiki page if a user has +o on the network

* Granting write access to a channels wiki page if the user has +o in the channel

* Automatically creating a user account if the user is logged into the IRC server and has an account name

For a more indepth example we could use the free audio/video conference service - Jitsi Meet. This service has built in JWT verification in that an application can send a user to a URL that contains a JWT token, and if the Jitsi Meet server verifies this token successfully, the user is granted access to that conference room. When an IRC client wants to join a conference room, it would first call EXTJWT #testchannel to receive a JWT token from the IRCd. The client would then open a browser window navigating to the Jitsi Meet URL while passing that token. It is up to the client to decide how and where to use this token, eg. via a "Jitsi Call" button for example.

As prawnsalad has stepped back from IRC development and I have taken over Kiwi IRC development. I cannot allow this ircv3 specification to be abandoned as Kiwi IRC uses it for quite a few plugins. (jitsi conferencing, file uploads, account avatar uploads)

So I have also forked #341 and updated based on comments from within the previous pull-request.

@ItsOnlyBinary
Copy link
Author

ItsOnlyBinary commented Jul 1, 2024

Reasoning behind removing the vfy claim:

Having the verify url within the token would encourage implementations to use the url without verifying its trusted, allowing the spoofing of tokens.

The verify url should be a pre-shared component for trust, just like the key would be pre-shared.

With the url having the advantage of not actually sharing the key, so that the host of the third party service could not actually generated trusted tokens.

@SadieCat
Copy link
Contributor

SadieCat commented Jul 1, 2024

Our implementation is updated to match the new pull request.

https://github.com/inspircd/inspircd-contrib/blob/master/4/m_ircv3_extjwt.cpp

@jwheare
Copy link
Member

jwheare commented Apr 3, 2025

Can we get an audit on implementations for this. Those I'm aware of:

Anyone else? Particularly would be nice to see clients, with examples of it being used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants