search

ircv3 / ircv3-specifications

IRCv3 specifications | Roadmap: https://git.io/IRCv3-Roadmap | Code of conduct: http://ircv3.net/conduct.html
http://ircv3.net
785 stars 79 forks source link

EXTJWT command for integrating external web services #547

Open ItsOnlyBinary opened 4 months ago

ItsOnlyBinary commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

Our implementation is updated to match the new pull request.

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