~emersion/public-inbox

1

IRC + OAuth 2.0

Nikita Vilunov <nikitaoryol@gmail.com>
Details
Message ID
<CAMayzOBt7KNK608Yfe8QO7Qr89W6xnW4L6K41rnZStdym4v53Q@mail.gmail.com>
DKIM signature
missing
Download raw message
Hi! The idea seems cool and it would be great to have IRC
authentication via an external identity provider. I wanted to focus on
the "client_id" problem.

You're saying that it's needed to issue a client_id for each pair "IRC
Client Software" + "IRC Network". This however shouldn't be the case,
as a client in OAuth terminology is not the same as an IRC client. In
this case it would be more appropriate to make the IRC network an
oauth client and possibly even a confidential one, i.e. having a
client_secret. The IRC server software would then use its
client_id+client_secret to authenticate itself to the auth server in
order to verify access tokens and retrieve user information.

Going further, there is a more appropriate standard for that kind of
situation — OpenID Connect. With it, the IRC server will communicate
with the auth provider and issue an ID token, which will be used only
to authenticate the end user to the IRC server.

I'm not an expert in OAuth and OIDC, but I believe that's how it's
usually done in that kind of situation. For example, Matrix recently
adopted using OIDC as the primary means of authentication, that means
that a matrix homeserver will delegate the auth flow to an auth server
and will deal just with ID tokens.

Best regards,
Nikita VIlunov
Details
Message ID
<jvM8QG_zOH6vGhvs64kCjo47DLxqUv1FsiZgzAY3GDRVUt1xwr5wOAQYxhSxzOCp9QvW5GMnSAbvj0L-PAJue1CoFPNLeiWwCh1zRdrFWGA=@emersion.fr>
In-Reply-To
<CAMayzOBt7KNK608Yfe8QO7Qr89W6xnW4L6K41rnZStdym4v53Q@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
Hi,

On Friday, March 31st, 2023 at 17:50, Nikita Vilunov <nikitaoryol@gmail.com> wrote:

> Hi! The idea seems cool and it would be great to have IRC
> authentication via an external identity provider. I wanted to focus on
> the "client_id" problem.
> 
> You're saying that it's needed to issue a client_id for each pair "IRC
> Client Software" + "IRC Network". This however shouldn't be the case,
> as a client in OAuth terminology is not the same as an IRC client. In
> this case it would be more appropriate to make the IRC network an
> oauth client and possibly even a confidential one, i.e. having a
> client_secret. The IRC server software would then use its
> client_id+client_secret to authenticate itself to the auth server in
> order to verify access tokens and retrieve user information.

I've considered this, but it's impractical. The IRC client needs to
authenticate against the IRC server, the OAuth token is a good way to
achieve this. If the server itself is the OAuth client, the IRC client
doesn't have access to the token. It's unsafe to leak the server OAuth
token to IRC clients.

> Going further, there is a more appropriate standard for that kind of
> situation — OpenID Connect. With it, the IRC server will communicate
> with the auth provider and issue an ID token, which will be used only
> to authenticate the end user to the IRC server.

The OAuth RFCs linked in the article supersede most of OpenID Connect.

Simon
Reply to thread Export thread (mbox)