199 lines
10 KiB
Plaintext
199 lines
10 KiB
Plaintext
MBOX-Line: From jjmckay at comaxis.com Wed Apr 30 08:52:46 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Jeff McKay <jjmckay@comaxis.com>
|
|
Date: Fri Jun 8 12:34:52 2018
|
|
Subject: [Imap-protocol] OAUTH and IMAP
|
|
In-Reply-To: <20140430143517.743B37306E@mailwash38.pair.com>
|
|
References: <53608FE7.8090909@verizon.net>
|
|
<CABa8R6sJQ0SV5O_udOusA983vE5NNbuRt27VthkCPuMbAge2yA@mail.gmail.com>
|
|
<5360FF8D.9000201@comaxis.com>
|
|
<20140430143517.743B37306E@mailwash38.pair.com>
|
|
Message-ID: <53611C4E.7030904@comaxis.com>
|
|
|
|
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
|
|
>>> <Pidgeot18@verizon.net <mailto:Pidgeot18@verizon.net>> 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
|
|
>> Imap-protocol@u.washington.edu
|
|
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140430/438070f7/attachment.html>
|