ergochat / ergo

A modern IRC server (daemon/ircd) written in Go.
https://ergo.chat/
MIT License
2.28k stars 181 forks source link

autocreated OAUTHBEARER accounts aren't accessible via conventional clients #2166

Open slingamn opened 5 months ago

slingamn commented 5 months ago

Talked to kris123 in #ergo about this: if someone autocreates an account by logging in with OAUTHBEARER (e.g. through Gamja), they won't be allowed to set their own password:

https://github.com/ergochat/ergo/blob/63269827679a26577b3f45b0916edb325db2bac0/irc/accounts.go#L562-L564

This is intentional (it prevents users creating "backdoor" credentials that they can use even if the external authentication system locks them out), but it's particularly problematic with OAUTHBEARER (relative to auth-script) because conventional clients can only send PLAIN.

poVoq commented 5 months ago

An idea that would solve this partially is that on first Oauth2 login when the IRC side account gets created the first time, Nickserv also sends out an welcome email (to the email address taken from the Oauth2 scope) similar to normal Nickserv registrations that includes a secret code to optionally allow setting a password manually.

Of course that wouldn't solve the issue that the Oauth2 account could be later removed.

slingamn commented 5 months ago

If we ignore the security concern about backdoor credentials, then we could solve this just by allowing NS PASSWD in-band.

poVoq commented 5 months ago

Can this:

oauth2:
        # enable this to use auth-script for validation:
        auth-script: false

be used with the LDAP auth script for example to enable both Oauth2 and LDAP logins the same time?

slingamn commented 5 months ago

Yep, OAuth2 can coexist with LDAP. Actually, you don't even have to enable that flag. That flag is for deferring OAUTHBEARER/IRCV3BEARER specifically to an external script, but if you're using auth-script to validate PLAIN (as opposed to OAUTHBEARER/IRCV3BEARER) credentials via an external LDAP server, then you can just enable that normally here:

https://github.com/ergochat/ergo/blob/63269827679a26577b3f45b0916edb325db2bac0/default.yaml#L581-L585

and the two will coexist.

slingamn commented 5 months ago

So I guess this technique is applicable to any SSO system that can mint revocable, long-lived static access tokens? You can have users mint the token through the SSO portal, then it can be validated via an auth-script that queries the SSO system's API.

poVoq commented 5 months ago

Coexist, yes, but will it allow the same account to use both Oauth2 (in gamja) and LDAP or similar auth script via regular clients?

slingamn commented 5 months ago

Yes. Gamja can be configured to use either PLAIN or OAUTHBEARER. Normal clients can be configured to use PLAIN. When Ergo receives a PLAIN attempt, it will pass it to the auth-script, which will validate it using the LDAP interface of the SSO provider. When it receives an OAUTHBEARER attempt, it will validate it using the OAuth2 introspection endpoint of the SSO provider. If the SSO provider is working correctly, any given user will be valid in one scenario if and only if it is valid in the other.