draft/bearer: bearer tokens for IRC authentication, tunnelled in PLAIN

[slingamn]

This is a specification to allow authentication to IRC via bearer tokens. It's similar to OAUTHBEARER, with two main differences:

1. It is tunnelled in PLAIN, removing the need for a separate OAUTHBEARER implementation
2. It allows for token types other than OAuth 2.0 (e.g. JWTs that can be validated locally by the ircd)

[grawity]

I'm not really sure I see what makes point 1 useful – instead of needing a separate OAUTHBEARER implementation, you now need a separate PLAIN implementation that special-cases the magic *bearer* prefix, so... what's the goal?

Yeah, OAUTHBEARER has a bit of unnecessary complexity, but it would seem better to copy-paste PLAIN into its own mechanism name, e.g. IRCV3-BEARER, instead of "PLAIN with magic indicators" – the mechanism name is what's supposed to be that indicator. (Practically all IRC clients roll their own SASL implementations anyway, so there will be no issue with waiting on gsasl or cyrus to pick up the new mechanism.)

(The structure could stay simple, like authzid\0tokentype\0token, without OAUTHBEARER's "GS2 header" stuff – e.g. Atheme already had this in the form of "AUTHCOOKIE".)

Is the goal to allow existing clients to work with OAuth? But if that's the case, how does the client obtain the OAuth access token if it doesn't have OAuth support; how does it keep the token refreshed?

The client MUST either omit the optional authorization identity (authzid), or use the authcid again as the authzid.

If the client doesn't want to use a specific authzid, empty string is the correct value to send (regardless of mechanism), but I believe that should be a SHOULD, rather than a MUST, because the mechanism shouldn't enforce a particular authzid – it rather defeats the point of that field being present. (Conceptually authorization is checked not as part of authn, but after authn happens, in a mechanism-independent way.)

I realize that literally nobody will want to combine OAuth tokens with authzids, probably for more than one reason, but it's the principle of not hardcoding magic values that should not be hardcoded.

[emersion]

Yeah, -1 from me: there is an existing standard for passing tokens, even if the standard isn't exactly what you want it to be, it's not a good enough justification to NIH a workaround which abuses another mechanism.

[slingamn]

Yeah, -1 from me: there is an existing standard for passing tokens, even if the standard isn't exactly what you want it to be, it's not a good enough justification to NIH a workaround which abuses another mechanism.

In your view, is OAUTHBEARER adequate for transmitting JWTs?

[emersion]

In your view, is OAUTHBEARER adequate for transmitting JWTs?

How are the JWTs obtained? If obtained via OAuth, then yes. Many OAuth servers use JWTs.

[grawity]

In your view, is OAUTHBEARER adequate for transmitting JWTs?

How are the JWTs obtained? If obtained via OAuth, then yes. Many OAuth servers use JWTs.

Even if it's not obtained via OAuth, as long as it functions practically the same way, it still feels to me a little less odd to use OAUTHBEARER to send a non-OAuth bearer token (after all, the mechanism doesn't deal with the acquisition, it just carries a token) than to hack PLAIN to do the same.

(my thinking is that bodging special cases (oauth tokens, OTPs, etc.) into password fields is something that happens due to lack of standards that would permit something better; but if we're defining standards anyway, might as well go all the way and define a whole new mechanism – unless there's a really good use case that only "tunneling in PLAIN" could serve, but even then it should probably be a fallback method from something more appropriate.)

[slingamn]

I'm interested in accepting JWTs (or indeed arbitrary bearer tokens) whether or not OIDC is involved. (For example, in a walled-garden website with authentication, the client could get a token from a custom XHR endpoint using its existing authentication cookie, then pass that to the ircd over a websocket.)

It sounds like we're more or less in agreement on the legitimacy of this goal? If so, I'd be open to redesigning this to use a new SASL mechanism (along the lines of the authzid\0tokentype\0token suggestion above), if that would be more likely to gain consensus. (I think the criticism that reusing PLAIN isn't actually a big savings is basically right. Stuffing non-OIDC tokens in OAUTHBEARER seems incorrect to me.)

[slingamn]

Withdrawing this in favor of #545