112 lines
5.7 KiB
Plaintext
112 lines
5.7 KiB
Plaintext
MBOX-Line: From Pidgeot18 at verizon.net Tue Apr 29 22:53:43 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Joshua Cranmer <Pidgeot18@verizon.net>
|
|
Date: Fri Jun 8 12:34:52 2018
|
|
Subject: [Imap-protocol] OAUTH and IMAP
|
|
Message-ID: <53608FE7.8090909@verizon.net>
|
|
|
|
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
|
|
|
|
|