Re: [Imap-protocol] OAUTH and IMAP

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

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol