Add draft/extoidc and draft/OBJECTSTORAGE

[reesericci]

This pull request provides a secure and standardized flow for authenticating external services using OpenID Connect over an IRC backchannel (no web redirects!), as well as secure object storage provider discovery and authentication using extoidc, as well as resumable uploads using tus.io.

Stemmed from:

#562
#562 (comment)
#562 (comment)

[ValwareIRC]

Just curious, how comes you didn't go with a SASL mechanism? (I just woke up, sorry if dumb question)

[reesericci]

Just curious, how comes you didn't go with a SASL mechanism? (I just woke up, sorry if dumb question)

It implicitly uses SASL because the authentication backchannel is over a (presumably SASL-authenticated) IRC connection

[ValwareIRC]

it would be really nice if you could include some normative examples of how the flow might look to the client and server and third-party

[anotherdoesnm]

well i think extoidc can be replaced with just SASL OAUTHBEARER?
more: https://emersion.fr/blog/2022/irc-and-oauth2/
and storage is... draft/FILEHOST?

[reesericci]

it would be really nice if you could include some normative examples of how the flow might look to the client and server and third-party

Can do, I'll make some diagrams.

well i think extoidc can be replaced with just SASL OAUTHBEARER?

No, that standard is to allow for logging into an IRC server with OAuth, not for the IRC server to expose an OIDC directory. This is for logging into external services (ie a file host) securely with your IRC connection, not for establishing that IRC connection.

and storage is... draft/FILEHOST?

Please read before commenting. This was created explicitly to address security issues in FILEHOST.

[reesericci]

Ok I added some normative diagrams that should clear up the flow for folks. Let me know what you think.

[emersion]

I've written my thoughts about this PR here: #562 (comment)

[Celelibi]

I could get behind this if I get convinced it's the minimum complexity for the client protocol.
I'm not well versed in OAuth/OIDC and I'm not sure I understand the purpose of the whole dance to confirm the usage of the token.
Couldn't we at least send all the information to the client at once when asking for a confirmation? At best, could we remove this confirmation entirely? Why do we need to confirm on something we explicitly asked anyway?

Also, why does it need to be OIDC explicitly on the client side? Couldn't it be an opaque token?
I know you mentioned token signature to check for non-modification here: #562 (comment)
But does the client need to do that? It's very likely that the connection uses TLS anyway. So this seem to add very little security. And if it's not on TLS... well, you're probably already screwed anyway.

I see no mention of the service to request a token for. This information could allow the server to generate tokens differently depending on the external service. Even assuming every external service uses OIDC, bugs and implementation subtleties always come up.