search

ircv3 / ircv3-ideas

46 stars 3 forks source link

OAUTH2 support? #74

Open GIJack opened 3 years ago

GIJack commented 3 years ago

I didn't see this here, and I thought it'd be a given.

Expected for IRCv3 to either support OAUTH2 or some other authentication token. Clients should NOT be storing passwords. Authenticated sessions should be revokable and have per-session limitations on what they can do.

When a user logs in via IRC using a password, with the option to save session, the token is stored on the device and NOT the password. If a user saves a password, the password is deleted and replaced with an oauth2 token first login.

nickserv keeps a list of active tokens that can be given names, deleted, and restricted as far as what they can do with the account.

In case of device compromise

  1. no password or other re-usable authentication mechanism is given to the attacker
  2. access can be revoked quite easily
  3. access can be restricted, per token, so devices like phones can be used to chat, but can't change account info, so can't be used in a permanent takeover. Account admin can further require 2FA if need be.
progval commented 3 years ago

What are the improvements compared to client certificates?

grawity commented 3 years ago

Well, I like the idea of separate auth tokens but the description doesn’t sound like OAuth2, if you just get the token from the same server you’re authenticating to.

(But at least its probably simpler to implement and so more likely to be adopted.)

the token is stored on the device and NOT the password. If a user saves a password, the password is deleted and replaced with an oauth2 token first login.

I’d actually like to see any client implement this with SCRAM first, it’s kind of part of the design... Sure, the “token” in SCRAM is your password hash (or a hmac thereof) and therefore the same for all devices, but it’s still a bit better than storing the actual password.

What are the improvements compared to client certificates?

Sounds like UX/automation is a big part. Client certificates are completely manually generated and manually enrolled, I suspect everyone just scp’s the same cert around.

Otherwise it indeed sounds fairly similar and could be implemented by services on top of existing certfp...

I guess there’s an advantage for in-browser clients where TLS certificates are out of reach?

ailin-nemui commented 3 years ago

they might have been thinking of Google's XOAUTH2. https://developers.google.com/gmail/imap/xoauth2-protocol#the_sasl_xoauth2_mechanism

However, this protocol is only half of OAuth2 -- the actual obtaining of the OAuth2 access token is done via an HTTP Endpoint and Web-browser form

grawity commented 3 years ago

they might have been thinking of Google's XOAUTH2. https://developers.google.com/gmail/imap/xoauth2-protocol#the_sasl_xoauth2_mechanism

However, this protocol is only half of OAuth2 -- the actual obtaining of the OAuth2 access token is done via an HTTP Endpoint and Web-browser form

Yeah that's my point, XOAUTH2 (or the standard OAUTHBEARER) don't have a mechanism to actually grant the token.

And overall the point of OAuth2 is that there's a separate entity that receives your password and dispenses tokens, and the application server only ever sees the short-lived access token...

If the IRC server itself gets the password and gives out tokens for itself, that's definitely useful but it's not OAuth2, is it.

I'm kind of thinking doesn't Matrix do the exact same thing when you log in? The same homeserver checks your password and issues a long-lived token that's then used everywhere, and it's a custom protocol (with no "access/refresh token" distinction either, AFAIK).

ailin-nemui commented 3 years ago

you could make the IRC server print a NOTICE * :Log in on http://network/oauth2.php?uid=0AB1345, then on that page you would offer the regular oauth/openid provider choice (Facebook, Google, ..) and once the log-in is confirmed, dispense the bearer token which the client should then cache somehow...

Note, the bearer tokens (jwt etc.) are always dispensed by the network itself (because they need to be validated by nickserv), not a 3rd party (as far as I understand anyway) after validating the identity, possibly through a 3rd party

SadieCat commented 3 years ago

I've been looking into OpenID Connect for Anope which might tie into this?

ailin-nemui commented 3 years ago

I don't really see how to apply OAUTHBEARER or what advantage it has over password authentication, at least since we don't have any standardised/specified way for the client to refresh the bearer token (which is often required where these tokens are short-lived, but would be awkward to have to do manually with a web browser on automated reconnects due to network conditions)

emersion commented 2 years ago

Today I've been working on OAuth 2.0 support in soju/gamja/goguma. My goal is to improve the user experience when connecting to chat.sr.ht via standard RFCs (no proprietary API). I have a prototype working where:

The following RFCs are used:

Note, SASL OAUTHBEARER is used to ensure the server accepts OAuth 2.0 token, and to send it without a username (at that point, the client is not aware of the account username, and SASL PLAIN requires a non-empty username).

Also relevant:

Future improvements:

emersion commented 2 years ago

Blog post about the above: https://emersion.fr/blog/2022/irc-and-oauth2/

nektro commented 1 year ago

twitch does bot identity through oauth https://dev.twitch.tv/docs/irc/authenticate-bot