62 lines
6.7 KiB
Plaintext
62 lines
6.7 KiB
Plaintext
MBOX-Line: From andris.reinman at gmail.com Wed Apr 30 00:53:03 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Andris Reinman <andris.reinman@gmail.com>
|
|
Date: Fri Jun 8 12:34:52 2018
|
|
Subject: [Imap-protocol] OAUTH and IMAP
|
|
In-Reply-To: <53608FE7.8090909@verizon.net>
|
|
References: <53608FE7.8090909@verizon.net>
|
|
Message-ID: <58DD71AD-BA0F-43AD-BEC7-19C658060275@gmail.com>
|
|
|
|
Hi,
|
|
|
|
> This is a message mostly directed to our fine Gmail server maintainers who happen to be listening on this list, but I think the issues here are relevant to other people who would read this list and I value the feedback of others, so I'm posting this publicly.
|
|
|
|
|
|
The Oauth2.0 issue is beginning to be more important as Gmail is not the only large IMAP server supporting AUTH=XOAUTH2 by now, notable others would be Outlook.com/Hotmail and Mail.ru.
|
|
|
|
I found this when I created a simple script to fetch IMAP capabilities from a list of "well known? services which can be found here: http://capa.kreata.ee/
|
|
|
|
Best regards,
|
|
Andris Reinman
|
|
|
|
|
|
On 30.04.2014, at 8:53, Joshua Cranmer <Pidgeot18@verizon.net> wrote:
|
|
|
|
> Hello,
|
|
>
|
|
> This is a message mostly directed to our fine Gmail server maintainers who happen to be listening on this list, but I think the issues here are relevant to other people who would read this list and I value the feedback of others, so I'm posting this publicly.
|
|
>
|
|
> Google's recent announcement (<http://googleonlinesecurity.blogspot.co.uk/2014/04/new-security-measures-will-affect-older.html>) about its authentication polices, I have been led to believe, is in part a plea for clients to implement OAuth2.0-based authentication, and an intent to degrade experience of users for clients that remain authenticating based on common IMAP authentication passwords. I believe that I have a duty to the users of Thunderbird to provide them the best experience I can, but I believe that I also have the responsibility to help ensure that this experience can be easily had by both users of other email services and other email clients; the OAuth 2.0 requirements as I have found them put these responsibilities in conflict, and I do not want to be in the position of having to choose which is the more important one.
|
|
>
|
|
> So far, I've read the OAuth 2.0 RFC (6749), Google's documentation on its OAuth 2.0 implementation [1], and even the most recent draft of integrating OAuth into SASL (<http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14>), which is what I view AUTH=XOAUTH2 in GMail's support as being analogous to. I have not yet had time to fully digest all the related emails about OAuth and SASL on the kitten working group. There has also been a discussion on this on Thunderbird's development mailing list (<https://mail.mozilla.org/pipermail/tb-planning/2014-April/003236.html>), if you're interested in seeing some of the discussion that has already been brought up and my or others' personal views on the quality of OAuth 2.0.
|
|
>
|
|
>
|
|
> Pieces of information:
|
|
> * Client Identifier: This is required in the RFC, and it is emphatic that this is neither secret nor is it to be used alone for client authentication. The problem I have here is the registration requirement: not that it is hard, but rather that it introduces a discrimination on the part of less common mail services that might wish to use this mechanism, if clients have to register a separate identifier for every such server. Given that such data will evidently be public (e.g., checked into Thunderbird's source code; even were it not, it's still a simple matter to intercept all outgoing http/https requests and obtain the id from that), and given that IMAP already defines an ID call that is used by Thunderbird and other clients, if the call is merely to indicate to the user the name of the program wishing to obtain authorization, it seems to me that deriving the client identifier from the ID call somehow ought to be sufficient.
|
|
>
|
|
> * Authorization endpoint: Arguably the biggest flaw in the entire process is that I see no way to build the HTTPS request to an OAuth authorization endpoint without hardcoding specific values.
|
|
>
|
|
> * Token endpoint: Similar to the authorization endpoint, the location of this is also left indeterminable.
|
|
>
|
|
> * Scope: It seems to me that this part, though technically optional in the OAuth specification, is meant to basically be required. For a single standardized name, it seems to me that, given that SASL mandates that applications using it describe a service name (cf. RFC 4422, section 4), it makes sense to use this parameter (or some simple derivation thereof) to use as the scope parameter. [2]
|
|
>
|
|
> * Refresh tokens: Google's documentation on this is vague. At times, it implies that these last essentially forever unless the user revokes access. At other times (and apparently in experiments), it seems that these last only for long-ish terms (e.g., a few weeks). This need to "refresh" the refresh tokens would be troubling to me, since it implies that I should be attempting to do more things in my power to autofill the server's authentication mechanisms without the user knowing, in accordance with the user's wish to not have to retype passwords implied by saving these credentials in our password manager. This sort of action appears to be contrary to the goals of OAuth 2.0, though.
|
|
>
|
|
> Providing this information via some sort of autoconfigurable, autodiscoverable mechanism given only the user's email and/or server name is, in my mind, absolutely necessary before any attempt to implement this in Thunderbird is started. While tying the records to DNS is theoretically better since a chain of trust can be followed with DANE, many clients may find it easier to look it up at some well-known URL similar to how Thunderbird's autoconfiguration mechanism already works.
|
|
>
|
|
> [1] Which is rather infuriating and confusing if all you're trying to do is figure out how to use AUTH=XOAUTH2, as most of the documentation is clearly geared towards usecases specific to other APIs and not IMAP or SMTP access.
|
|
>
|
|
> [2] On careful rereading of the SASL OAUTHBEARER draft it seems that it is possible to automatically infer the desired scope... but only by executing a AUTHENTICATE command that fails, which is rather suboptimal workflow for trying to develop client behavior in this regard. It means, e.g., I can't wrap the OAUTH support in a generic SASL provider mechanism and expect to have it pick up the desired scope information. It's also suboptimal that the information about scope is revealed but not any other hints about how to go about requesting authorization.
|
|
>
|
|
> --
|
|
> Joshua Cranmer
|
|
> Thunderbird contributor
|
|
> DXR coauthor
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
|
|
|