158 lines
8.1 KiB
Plaintext
158 lines
8.1 KiB
Plaintext
MBOX-Line: From jjmckay at comaxis.com Wed Apr 30 06:50:05 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: <CABa8R6sJQ0SV5O_udOusA983vE5NNbuRt27VthkCPuMbAge2yA@mail.gmail.com>
|
|
References: <53608FE7.8090909@verizon.net>
|
|
<CABa8R6sJQ0SV5O_udOusA983vE5NNbuRt27VthkCPuMbAge2yA@mail.gmail.com>
|
|
Message-ID: <5360FF8D.9000201@comaxis.com>
|
|
|
|
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
|
|
> <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.
|
|
>
|
|
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140430/91cff5b1/attachment.html>
|