IRCV3BEARER SASL mechanism for bearer tokens

[slingamn]

This replaces #534, incorporating feedback received there:

1. Defining a new mechanism IRCV3BEARER instead of reusing PLAIN
2. IRCV3BEARER still overlaps with OAUTHBEARER, but it's more general, since it supports arbitrary bearer token types including JWTs

[KlaasT]

Out of curiosity and because I have a project running, which could really benefit from this:

What would be needed to get this through?

[SadieCat]

Suggested change

[SASL](sasl-3.1.html) is the standard authentication protocol used in IRC; it offers different mechanisms corresponding to different methods of authentication. Although some bearer tokens have associated SASL mechanisms (for example, OAuth2 has [RFC 7628](https://www.rfc-editor.org/rfc/rfc7628.html)), there is no general mechanism associated with the concept of bearer tokens. This specification defines a new mechanism `IRCV3BEARER` for processing bearer tokens in the context of IRCv3.

[SASL](sasl-3.1.html) is the standard authentication protocol used in IRC; it offers different mechanisms corresponding to different methods of authentication. Although some bearer tokens have associated SASL mechanisms (for example, OAuth2 has [RFC 7628](https://www.rfc-editor.org/rfc/rfc7628.html)), there is no general mechanism associated with the concept of bearer tokens. This specification defines a new mechanism `TOKENBEARER` for processing bearer tokens in the context of IRCv3.

Suggestion: SASL mechanisms are supposed to be protocol agnostic so a more generic name like this might be better?

[KlaasT]

Would be all for it. Either "TOKEN" or "BEARER". When considering HTTP it would be just "BEARER" under the Authorisation header. Maybe it would be an idea to align with something existing?

[DarthGandalf]

Whatever the name is, it should be sent to http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

[KlaasT]

I'm not an expert in the RFC process but I did some further reading today and I think RFC7628 might be doing on what was intended with JWT.

The RFC handles the authentication using bearer tokens which are being issued primarily by the OAUTH framework. JWT is one token format which is valid inside the OAUTH framework.

Given the examples and under further considerations it is pointed out that JWT is a SASL compatible container format for such a token and can be used for the authentication process.

[slingamn]

@KlaasT not sure if I understood you, but if you're suggesting that arbitrary tokens can be sent via the existing OAUTHBEARER mechanism defined by RFC 7628, I don't think that makes sense. And this specification effort is intended to support arbitrary tokens.

If you're saying that OAUTHBEARER is adequate for your intended use case, there is indeed prior art for integrating OAUTHBEARER into IRCv3: https://emersion.fr/blog/2022/irc-and-oauth2/

[KlaasT]

Hi @slingamn

my intent is not to send arbitrary tokens through the OAUTHBEARER mechanics of RFC7628. My intent is to stay within the definition of the RFC. Maybe we just have a misunderstanding here :)

JWTs are a standardised format (RFC 7519) and commonly used as bearer tokens in OAuth 2.0 ecosystem.

From my understanding the OAUTHBEARER mechanism doesn’t impose strict constraints on the token’s internal structure beyond being a valid OAuth 2.0 token, which JWTs satisfy when issued by a trusted authority.

According to the RFC, OAUTHBEARER already supports JWTs as is, provided of course the server can validate them.

Furthermore a server is not forced to contact an OAUTH server for JWT validation as they are signed and self contained. The use of external resources for JWTs, even in the OAUTH process, is optional (correct me if I'm wrong), as they are able to hold all information needed for verification.

That blog post you linked is very interesting. Thanks for that one. I see it though trying to lean into the full OAUTH 2.0 handshake, while we could have it simpler, without the need to implement the entire stack.

Maybe I have missed something entirely and I am happy to discuss. But from what I see we could use this mechanism to accept JWTs as a RFC compliant token type, verify and validate them. Keeping it open for later implementations of further compatible mechanisms and protocols.

Just to add I found this over at Kafka which basically does the same thing, if I understood it right: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75968876

So to close this wall of text (sorry for that), I don't want to invalidate your work on this extension. I think it is great and we do align in many things in that extension. Only thing I am concerned is that the mechanism we are searching for is in fact already present and called OAUTHBEARER.

Introducing a new mechanism and going through IANA, as proposed earlier, would probably take a long time.

[slingamn]

@KlaasT I think maybe we should talk out of band, would you like to email me?

[slingamn]

Upon further consideration this restriction doesn't seem very useful. Thoughts on either (a) allowing NUL (b) requiring non-NUL UTF8 (c) requiring printable ASCII (0x20 through 0x7e inclusive), as OAuth does?