Re: [Imap-protocol] OAUTH and IMAP

Of course, 2-legged OAuth 1.0 has been "deprecated" for several years 
now.  I think I heard Brandon mention once
that it would not be killed until there is a replacement, since a lot of 
applications depend on it.  I have experimented
also with everything I can find on OAuth 2.0 and nothing works for admin 
access, or the documentation is insufficient
for me to do it correctly.

On 4/30/2014 7:34 AM, Pete Maclean wrote:
> Jeff,
>
> I find your post very interesting because I have been trying on and 
> off for months to get OAuth 2 to work for Gmail for Google Apps users 
> via admin credentials -- without success.  I do not have the luxury of 
> using OAuth 1 because I started only recently and choose not to go to 
> the trouble of implementing something that is deprecated and likely to 
> quickly become obsolete.  I have found the matter frustrating because 
> of the lack of documentation and because the problem is never a 
> failure to obtain a token but the failure of the token I get to work 
> for IMAP authentication.  (Making OAuth 2 work for individual Gmail 
> users was, by comparison, a piece of cake.)
>
> I am gratified in particular to hear your call for detailed 
> documentation on the topic because it tends to confirm that I have not 
> simply missed something.
>
> Pete Maclean
>
> At 09:50 AM 4/30/2014, Jeff McKay wrote:
>> 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 
>>> <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

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