autocreated OAUTHBEARER accounts aren't accessible via conventional clients

[slingamn]

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:

ergo/irc/accounts.go

Lines 562 to 564 in 6326982

	if !hasPrivs && creds.Empty() {
	return errCredsExternallyManaged
	}

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]

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]

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

[poVoq]

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]

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:

ergo/default.yaml

Lines 581 to 585 in 6326982

	# pluggable authentication mechanism, via subprocess invocation
	# see the manual for details on how to write an authentication plugin script
	auth-script:
	enabled: false
	command: "/usr/local/bin/authenticate-irc-user"

and the two will coexist.

[slingamn]

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]

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]

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.