OAuth, SASL and IRC: a new way to authenticate on SimosNap
On SimosNap, there have long been several ways to authenticate to your IRC account. You can do it in the most traditional way, by identifying with NickServ after connecting, or use SASL PLAIN to authenticate directly while joining the network.
These are standard systems, they work, and of course they will continue to remain available.
But there is one situation where entering your IRC account password again starts to feel unnatural: when the user has already authenticated on a website or service through SimosNap.
If SimosNap already knows who you are, why should it ask for your NickServ password again just to join chat?
That question led to the new IRC authentication system we have been working on over the past few weeks.
From website login straight to IRC
SimosNap already has an OAuth 2.0/OpenID Connect system that allows authorized websites and applications to use a SimosNap account to identify a user.
The next step was to connect that identity to the IRC network as well.
A website or application that integrates the new system can authenticate the user through OAuth and then let them open KiwiIRC already identified with their IRC account, without having to type their NickServ password again.
From the user's point of view, the result is very simple: log in on the website, open the chat, and join already authenticated.
Behind an operation that seems so straightforward, however, there is an important issue. We did not want the OAuth token used by the website to also become the credential used by the browser to access IRC.
That is why we kept the two systems clearly separate.
The OAuth token remains on the application's server. The backend uses it to request from SimosNap a credential created exclusively for IRC access: a temporary token that is then used by KiwiIRC through SASL.
In other words, the website gives the webchat neither the NickServ password nor its own OAuth token. It gives it a kind of temporary pass, created specifically for that IRC authentication.
A new SASL mechanism: SIMOSNAP
SASL is not new on our network. SASL PLAIN has been available for a long time and already allows an account to be authenticated during the IRC connection using normal credentials.
The new part is that we have added another mechanism, called SIMOSNAP, designed specifically for this new SSO system.
The flow can be summarized like this:
website or application → SimosNap OAuth → temporary IRC token → KiwiIRC → SASL SIMOSNAP → InspIRCd → Anope
KiwiIRC presents the token during the connection using SASL. InspIRCd continues to perform its normal role in transporting authentication to the services, while Anope verifies which account that credential belongs to and decides whether the user can be authenticated.
This was an important requirement for us.
We did not want to build a second account system running in parallel with NickServ, nor did we want to change the fundamental behavior of the network. IRC accounts continue to be the ones managed by Anope, and SASL continues to be the mechanism used during connection.
We have added a new way to securely prove that the user joining the chat corresponds to that account.
A token that does not become a new password
The token used by SASL SIMOSNAP was also deliberately designed with a very limited purpose.
It is not an alternative password for the IRC account.
It is a random 256-bit credential, has a maximum lifetime of five minutes, and can be used only once.
The server also does not store the token in plain text, only its hash. When it is presented and is valid, verification and consumption happen in the same operation: after that authentication, the token can no longer be used.
We also verified this behavior during development: trying to present the same token again does not allow a second authentication.
The difference compared to a permanent password is therefore substantial. If the token is not used, it still expires after a few minutes. If it is used, it immediately stops being valid.
Most importantly, the NickServ password does not have to be provided to the website or the webchat to perform this type of access.
OAuth and IRC remain two different things
One of the aspects we wanted to keep clear in the architecture as well is the separation between OAuth and IRC.
The OAuth token is used for the relationship between the application and SimosNap. It can have a completely different purpose and lifecycle from what is needed for a single IRC connection.
For this reason, it is not simply passed to KiwiIRC.
The application's backend uses it to request from SimosNap a new, much more limited credential intended exclusively for IRC authentication.
This means KiwiIRC does not need to know the OAuth token used by the website, and Anope does not need to become an OAuth server.
Each component continues to do its own job.
OAuth identifies the user in the relationship between the website and SimosNap. The SSO token creates the temporary link with IRC. SASL authenticates the connection, and Anope remains the final authority over the IRC account.
And when KiwiIRC reconnects?
During development, we came across another interesting problem.
A webchat must be able to handle a connection loss normally and try to reconnect. But a one-time SASL token, by definition, cannot be used a second time.
The simplest solution would have been to make it reusable for a certain period of time. However, that would have meant losing one of the security properties we wanted to achieve.
So we separated authentication from the ability to reconnect.
The system uses a reconnect token that is not presented to Anope as a SASL credential. When KiwiIRC needs to make a new connection, it is used to ask SimosNap for a new temporary, single-use IRC token.
The new connection then performs a new SASL SIMOSNAP authentication with a new credential.
The token used in the previous connection remains unusable.
For the user, all of this is transparent: KiwiIRC can continue to handle reconnections automatically without asking for the password again.
Accounts and nicknames are not necessarily the same thing
IRC also has a characteristic that a normal Web login system often does not have: a single account can have multiple associated nicknames.
This aspect was taken into account as well.
An application can retrieve the aliases belonging to the authenticated account and allow the user to choose which nickname to use when joining chat. It is also possible to check whether they are present on the network, in order to know which identities are already connected.
Authentication still refers to the IRC account.
The nickname used in the session and the account verified by Anope therefore remain two distinct concepts, exactly as they normally are on the network.
What really changes for the user
Fortunately, almost nothing.
In fact, that is exactly the goal.
A user logs in to a website through SimosNap, opens the chat, and joins already authenticated with their IRC account. They do not need to remember or re-enter their NickServ password, and the website integrating the system has no reason to ask for it.
If the connection drops, the webchat can obtain a new temporary credential and authenticate again during reconnection.
All token management stays behind the scenes.
At the same time, we have not removed any of the existing systems.
Traditional identification through NickServ continues to work. SASL PLAIN remains available for authentication during connection using an account and password. And when the new SSO system is not available, KiwiIRC can continue to use normal SASL authentication.
SIMOSNAP is therefore an additional option, not a new requirement for connecting to the network.
A bridge between Web and IRC, not a replacement for IRC
Perhaps this is the aspect of the project that interested us most.
Over the years, we have built several services around IRC, but the goal has never been to replace the protocol or unnecessarily duplicate its features.
This time too, we tried to follow the same principle.
OAuth continues to handle identity between SimosNap and Web applications. SASL continues to handle authentication during the IRC connection. InspIRCd continues to manage the IRC server, and Anope continues to be the authority for the network's accounts.
The new system simply builds a secure bridge between these elements.
To do this, we developed the SIMOSNAP SASL mechanism, temporary token management, the required integration in KiwiIRC, and a dedicated module for Anope, without modifying the core of InspIRCd or Anope and without turning OAuth into something it is not.
And in the end, all of this serves to achieve an extremely simple result:
if you have already authenticated with SimosNap, we can recognize you when you join IRC too.
Technical documentation is coming soon
The system is already operational, but the work is not yet complete from the documentation point of view.
We are preparing the technical documentation needed to allow websites and applications to correctly integrate the new OAuth/SSO system and IRC access through SASL SIMOSNAP. We will publish it soon on the SimosNap website.
We will also take the opportunity to update the documentation for our IRC infrastructure, which currently does not yet fully reflect the recent migration to InspIRCd 4 and the new features introduced with the new version.
The goal is to have up-to-date documentation not only on the new authentication system, but more generally on the tools and possibilities currently available for anyone who wants to integrate their services with the SimosNap network.