143 lines
7.1 KiB
Plaintext
143 lines
7.1 KiB
Plaintext
MBOX-Line: From blong at google.com Tue Apr 29 23:55:20 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.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: <CABa8R6sJQ0SV5O_udOusA983vE5NNbuRt27VthkCPuMbAge2yA@mail.gmail.com>
|
|
|
|
I'm not our expert on oauth, he's welcome to pipe up here in a bit.
|
|
|
|
I'd also point you to our documentation here,
|
|
https://developers.google.com/gmail/oauth_overview which at the least has
|
|
working examples.
|
|
|
|
|
|
|
|
On Tue, Apr 29, 2014 at 10:53 PM, 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.
|
|
>
|
|
|
|
The client identifier here, from my understanding, is different in that its
|
|
an actual registered ID, not just some string. Re-using the ID isn't going
|
|
to work, plus, as a SASL mechanism, its supposed to be contained and
|
|
generic for use in multiple protocols, so relying on a protocol specific
|
|
passing of that information was probably considered non-ideal.
|
|
|
|
|
|
> * 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.
|
|
>
|
|
|
|
Yes, as far as I know, there is no discoverability mechanism as of yet.
|
|
|
|
|
|
> [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.
|
|
>
|
|
|
|
Ah, is this the documentation I pointed out above? Happy to pass on any
|
|
feedback to the docs folks.
|
|
|
|
[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
|
|
>
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140429/70cce914/attachment.html>
|