[Imap-protocol] OAUTH and IMAP

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
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol