search

mozilla / releases-comm-central

EXPERIMENTAL - copy of comm-central for forking on github
162 stars 96 forks source link

Support for user-specified OAuth providers #52

Open nick-oconnor opened 2 years ago

nick-oconnor commented 2 years ago

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 commented 9 months ago

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 commented 5 months ago

+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 commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

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:

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 commented 4 months ago

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 commented 4 months ago

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:

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

oculos commented 1 week ago

Any progress here?