Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retriving OAuth2 configuration from Autoconfiguration #7466

Closed
3 tasks done
mimi89999 opened this issue Jan 1, 2024 · 3 comments
Closed
3 tasks done

Retriving OAuth2 configuration from Autoconfiguration #7466

mimi89999 opened this issue Jan 1, 2024 · 3 comments
Labels
type: enhancement New features or improvements to existing features. unconfirmed Newly reported issues awaiting triage or confirmation

Comments

@mimi89999
Copy link

Checklist

  • I have used the search function to see if someone else has already submitted the same feature request.
  • I will describe the problem with as much detail as possible.
  • This issue only contains a request for one single feature, not multiple (related) features.

App version

6.603

Problem you are trying to solve

I have a Dovecot IMAP server configured with OAuth2 with Authelia as OAuth2 backend. After adding an entry for my server to app/k9mail/src/main/java/com/fsck/k9/auth/AppOAuthConfigurationFactory.kt:

private fun createLebihanConfiguration(): Pair<List<String>, OAuthConfiguration> {
    return listOf(
        "lebihan.pl",
    ) to OAuthConfiguration(
        clientId = "myapp",
        scopes = listOf("openid", "profile", "email", "groups"),
        authorizationEndpoint = "https://auth.lebihan.pl/api/oidc/authorization",
        tokenEndpoint = "https://auth.lebihan.pl/api/oidc/token",
        redirectUri = "${BuildConfig.APPLICATION_ID}://oauth2redirect",
    )
}

I was able to successfully authenticate with my OAuth2 backend. Adding every email server configuration to that file however isn't very practical. K-9 should automatically retrieve that configuration.

Suggested solution

The Autoconfiguration format does specify a OAuth2 config node where the endpoints can be specified:
https://wiki.mozilla.org/index.php?title=Thunderbird:Autoconfiguration:ConfigFileFormat#OAuth2
https://www.bucksch.org/1/projects/thunderbird/autoconfiguration/config-file-format.html#OAuth2

K-9 should read the values from this file. The redirectUri could be universal and used for all OAuth2 servers. K-9 would also have a default clientId and server admins will just add the K-9 app.

Screenshots / Drawings / Technical details

No response

@mimi89999 mimi89999 added type: enhancement New features or improvements to existing features. unconfirmed Newly reported issues awaiting triage or confirmation labels Jan 1, 2024
mimi89999 added a commit to mimi89999/thunderbird-android that referenced this issue Jan 1, 2024
@cketti
Copy link
Member

cketti commented Jan 2, 2024

A group of us is currently working on a mechanism to allow email server operators to offer OAuth 2.0 without prior manual client registration. This will most likely end up being a couple of IETF RFCs. This needs to include a mechanism like Autoconfig. However, it's not clear yet whether it will be Thunderbird Autoconfig or a different format.
Before there's a standard, we're not going to add a home-grown solution that no other client intents to implement.

Until then, your best bet is working on #6152. You won't be able to automatically add the OAuth config to K-9 Mail, but at least you'll be able to do it manually.

If you intend to work on this, please don't go ahead and write code. Outline your proposed solution in a comment and wait for feedback from the team. Otherwise there's a high chance you'll create a patch we're not going to merge without major changes.

@lukaszszczesniak
Copy link

@cketti Is there any news about working on mechanisms to offer OAuth 2.0 without prior manual client registration? Maybe I can somehow support you in your work?

@kewisch
Copy link
Member

kewisch commented Jan 10, 2025

I believe this is related to https://datatracker.ietf.org/doc/draft-ietf-mailmaint-oauth-public/ which is slowly moving forward. I believe most of the conversation about this has happened at IETF events or Make Better Email, or the mailmaint list.

I'm not sure there is anything immediate that can be done here, aside from supporting the IETF discussions and the issue cketti mentioned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New features or improvements to existing features. unconfirmed Newly reported issues awaiting triage or confirmation
Projects
None yet
Development

No branches or pull requests

4 participants