Re: [Imap-protocol] OAUTH and IMAP

I have used oauth 2 with Gmail and it works well for my purpose.  I have 
seen the refresh token work several months after
first obtaining it with no intervening use.  To change the subject just 
a it, I wonder if Google could comment on the continuing
use of oauth 1 with Gmail?  Currently that is the only method I know 
that will allow me to grab Google Apps email data using
only administrative credentials, i.e. the client secret.  If there is a 
way to do that with oauth 2 I would appreciate detailed
low level documentation (not a library function).  But I sure hope that 
oauth 1 support is not going away anytime soon.

On 4/29/2014 11:55 PM, Brandon Long wrote:
> 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] <mailto:[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.
>

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