Support for user-specified OAuth providers

[nick-oconnor]

I would like to use Thunderbird with my own OAuth provider. There doesn't currently seem to be a way to specify OAuth providers outside of the ones in OAuth2Providers.jsm. Minimally accepting a config file of some kind would be fine.

[EdouardVanbelle]

Hello @nick-oconnor , I have exactly the same need, I will appreciate if we can join our effort and found a solution
I also requested it on the forum: https://support.mozilla.org/en-US/questions/1432754#

A way to improve this could be to add functions to append on OAuth2Providers.jsm so either a plugin or via options we could add our own provider

[oculos]

+1. But one thing I wonder here: on the mentioned file (https://github.com/mozilla/releases-comm-central/blob/master/mailnews/base/src/OAuth2.sys.mjs), it is mentioned that Thunderbird will migrate to dynamic client registration. Is it the way to go? Won't that result in millions of clients on an idp?

And talking about the present situation: is there a security risk by having client_id's and secrets exposed in the source code?

[nick-oconnor]

@oculos great questions!

1. Seems like that's the case. I would expect that this isn't a big problem for providers though. I never run into client quotas.

2. Having client secrets exposed allows stolen refresh or authorization codes to be replayed by an attacker. PKCE is supposed to be used in place of client secrets in situations like this where the client secret cannot be protected. My guess (hope) is that this implementation pre-dated PKCE. As for how much of a risk that is depends on the security of your client and transport layer.

DCR does not replace PKCE. It just replaces the manual configuration of client IDs which I don't think is necessary here as using Thunderbird's IDs with client secret-less PKCE should be fine. Maybe the goal is decentralization? I'm unaware of any end-user clients which use DCR.

[oculos]

@nick-oconnor thanks a lot for the reply. Mind if I take it a bit further?

1. When it comes to DCR, at least with keycloak, you need to provide an initial access token. That secret would have to be distributed anyway, so we might be back to the issue of having the secrets exposed. But the PkCE solution you mention might do the trick.

2. Another concern I have is that the client you configure for Thunderbird must be the same client the backend will use, right? I wonder if this is the best practices. Or will local introspection removes the need for the backend (in this case Dovecot) to have client credentials?

3. would token-exchange help here? Like having a distributable client for the endpoint applications, and another client for the backend?

[EdouardVanbelle]

That is one of the biggest issue: DCR will create tons of new clients, which is not convenient for IDP, or the IDP will need to garbage collect unused clients

Currently without DCR as the clientSecret is exposed in source code, it is recommended to declare your client as a public client https://oauth.net/2/client-types/ (because secret is a non sense here and PKCR protects you as said @nick-oconnor )

I saw this brilliant initiative: https://indieauth.spec.indieweb.org/#oauth-2-0-extension where there is no need to register a client, they just ensure that clientId is an URL matching the callback URL, which will unfortunately not work with rich/fat client because they only accept http/https scheme. and this initiative is not a standard.

Regarding your questions:

• if I do remember you can permit DCR without authentification on Keycloak, but I am not fan of this solution

• I am using different client for Thunderbird and Dovecot, there is no issue for Dovecot to introspect the token created from my Thunderbird or my Roundcube

A possible solution: Thunderbird could use a shared database to register it's client for each new IDP/domain, for example one client per thunderbird's version. Doing this will reduce the amount of clientId created
You just have shifted the issue on the access to the shared database :)
is it what you imagined for your question 3 ?

[oculos]

Thanks a lot for your thorough answer @EdouardVanbelle. Some comments:

That is one of the biggest issue: DCR will create tons of new clients, which is not convenient for IDP, or the IDP will need to garbage collect unused clients

Exactly. Makes no sense from an endpoint perspective.

Regarding your questions:

• if I do remember you can permit DCR without authentification on Keycloak, but I am not fan of this solution
• I am using different client for Thunderbird and Dovecot, there is no issue for Dovecot to introspect the token created from my Thunderbird or my Roundcube

Really? I remember I had problems when using different clients for Roundcube and Dovecot. And when I see the documentation for token exchange on Keycloak (https://www.keycloak.org/docs/latest/securing_apps/#_token-exchange), I got the feeling that a token for a client can't be used on another client.

Do you use local introspection? And, by the way, would you mind sharing how you got your configuration on Thunderbird, and how you configured dovecot for oauth? I have it working with my setup, but maybe there's something I was missing that prevented me to use an own client for dovecot.

A possible solution: Thunderbird could use a shared database to register it's client for each new IDP/domain, for example one client per thunderbird's version. Doing this will reduce the amount of clientId created You just have shifted the issue on the access to the shared database :) is it what you imagined for your question 3 ?

Not really. I was thinking more of creating a public client for Thunderbird on Keycloak and use token exchange, so that the applications could fetch a token for that public client (which I thought couldn't be used with my confidential client used by roundcube and dovecot), and, using that token, request another one for my internal client, without having its credentials.

[oculos]

Regarding your questions:

• if I do remember you can permit DCR without authentification on Keycloak, but I am not fan of this solution
• I am using different client for Thunderbird and Dovecot, there is no issue for Dovecot to introspect the token created from my Thunderbird or my Roundcube

I guess you do offline introspection here, no? I don't think it would work if you have Keycloak to do the introspection since they use different clients, unless if using token exchange...

[oculos]

Regarding your questions:

• if I do remember you can permit DCR without authentification on Keycloak, but I am not fan of this solution
• I am using different client for Thunderbird and Dovecot, there is no issue for Dovecot to introspect the token created from my Thunderbird or my Roundcube

I guess you do offline introspection here, no? I don't think it would work if you have Keycloak to do the introspection since they use different clients, unless if using token exchange...

Nope, I realized it works with a different client. I have no idea why it works - I thought that a token obtained on one client only worked there - that's why token_exchange exists, no?

[oculos]

Everyone, I did a lot of thinking about this, and tested building with my own oauth2 provider (keycloak based). It just worked.

Now, I don't think dynamic client registration is a good idea, or not a good idea for everyone. Having an idp with thousands of clients for just one application doesn't scale well for everyone. Applying policies for each client could be cumbersome.

I think the ideal way to handle this was simply adding more settings when oauth2 is chosen as authentication. Settings like this:

• public or private client
• client id (mandatory)
• client secret (for private clients)
• token introspect url
• token url
• authorization url
• (eventually, the settings above could be obtained by using a discovery endpoint, like .well-known/openid-configuration
• adding auto configuration possibility (https://wiki.mozilla.org/Thunderbird:Autoconfiguration), so that institutions and companies could easily configure their clients.

This would make Thunderbird the first e-mail client that fully support modern authentication in a non-proprietary way.