sasl: add a command to log out

[emersion]

The sasl extension defines the AUTHENTICATE command to log in (or re-authenticate), but doesn't provide any way to log out.

[slingamn]

What's the intended use case?

[emersion]

Add a logout button in my client UI.

[slingamn]

I mean, why would an end user want to log out?

[emersion]

The original use-case is adding a way for clients to clear credentials on soju. Ref https://todo.sr.ht/~emersion/soju/198

Note, some services support this via a logout command in NickServ.

[emersion]

<grawity> since SASL reauth is now a thing, I just had a completely stupid idea of reusing `AUTHENTICATE ANONYMOUS` for logging out

[ValwareIRC]

I know this may sound a little convoluted but, on an old network I was staff on, the server admin asked that before we detached from our bouncer, we should log out of nickserv and deoper in case your bouncer got compromised. still to this day I have never seen a bouncer get hijacked (maybe someone else has, idk). paranoia use-case I guess.

other use-cases I can think of:

• when in a busy environment like a coffee shop or even at home and you need the loo and someone else sees and knows about IRC and messes with stuff.
• when allowing someone else to control your desktop
• when testing or implementing something which only gets executed when you go from no-account to account or the other way round. (maybe a client-side script) (user may want a quick way to remove all metadata associated with their account or something)

I'm sure there are more use-cases though

[slingamn]

These seem to me to be use cases either for a screen lock, or for /QUIT.

In general there seem to be multiple overlapping, but distinct, ideas of what this feature would do:

1. Deauthenticate the C2S connection without tearing it down (without affecting presence / channel membership?)
2. Delete remote credentials (SASL username and password) held by a bouncer
3. Delete local credentials held by the local client

[ValwareIRC]

Bumping because I still think this is a good idea. Deauthing is already a case of doing /msg NickServ logout, I think the idea to move these already-existing features to a more flush methodology which doesn't require messaging a service bot is a good idea. This motivation already gave birth to account-registration and SASL, albeit they are more for stopping passwords/credentials being sent by PRIVMSG, it still makes sense to continue with moving all of the account-related features to the same realm instead of having the client methodology kept as wildly different throughout those features.

Edit: No IRC didn't think of SASL but it sure as hell implemented it =]

[ValwareIRC]

I think a LOGOUT or DEAUTH command should be like this:

• Server checks first if there is a server providing SASL
• If so, sends S2S command instead of a PRIVMSG, like :client LOGOUT account to the server providing SASL, requesting for services to log them out
• Else, services is temporarily offline so as a fail-safe the server can just take the initiative and log out the user - services will know they're not logged in when they reconnect.

As the popular services packages don't support incoming login information except for during a burst, it's not possible for the server to log the user out and let services know about it.

Note: Race conditions may have an effect here, as something to consider if implementing

[SadieCat]

What the command does internally is outside of the scope of IRCv3.

[vanosg]

What the command does internally is outside of the scope of IRCv3.

Agree. This feels totally ircd-specific. I'm not sure why this is getting tied to SASL. SASL is a mechanism to decouple authentication from the application protocol (here, before the IRC session is finalized). Once everything is registered with IRC, I don't see why this wouldn't be handled a) through the application protocol and b) up to the server to figure out how it wants to handle something like this

[emersion]

before the IRC session is finalized

Nah, SASL can be performed after connection registration too. Even if it wasn't, no reason why one couldn't come up with a pre-registration LOGIN <username> <password> command.

The reason why SASL is used is to allow for multiple auth mechanisms.

[emersion]

soju now supports AUTHENTICATE ANONYMOUS as a way to logout.

[nektro]

isn't closing the connection/client/app easier?

[emersion]

Depends if the user wishes to continue interacting with the IRC server after being de-authenticated. Besides, this approach doesn't work with bouncers.

In general there seem to be multiple overlapping, but distinct, ideas of what this feature would do: 2. Delete remote credentials (SASL username and password) held by a bouncer

The bouncer already implicitly saves credentials during regular authentication. It's only natural to clear credentials on de-authentication.

[GIJack]

I kinda think that we should implement OAUTH2 for IRC.