90 lines
4.8 KiB
Plaintext
90 lines
4.8 KiB
Plaintext
MBOX-Line: From Pidgeot18 at verizon.net Wed Apr 30 08:40:24 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Joshua Cranmer <Pidgeot18@verizon.net>
|
|
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: <53611968.6010707@verizon.net>
|
|
|
|
On 4/30/2014 1:55 AM, Brandon Long wrote:
|
|
> On Tue, Apr 29, 2014 at 10:53 PM, Joshua Cranmer
|
|
> <Pidgeot18@verizon.net <mailto:Pidgeot18@verizon.net>> wrote:
|
|
>
|
|
> * 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.
|
|
|
|
The fact that a client ID needs to be pre-registered, and pre-registered
|
|
per site, would make it impossible to implement SASL OAuth in a
|
|
non-discriminatory manner: a client would only be able to connect to
|
|
those sites for which it knows what its client ID is, and only those for
|
|
which the developer(s) have the time to go register an ID. In a world
|
|
where many servers of disparate networks implement this (as other
|
|
servers are already starting to do, see Andris's email).
|
|
|
|
My suggestion, which I think got misunderstood, was that instead of
|
|
relying on a pre-registration mechanism for the client ID, IMAP clients
|
|
should be able to construct a client ID somehow from the IMAP ID that
|
|
they send out. I didn't intend to imply that the client ID should be
|
|
extracted by the server from observing an IMAP ID on the transaction.
|
|
|
|
> [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.
|
|
|
|
Well, if you're inviting me to complain about the documentation... :-)
|
|
|
|
* The scope for IMAP and SMTP is not linked to from the OAuth2
|
|
documentation itself (it is mentioned only the xoauth2 page).
|
|
* The meaning of the return result in the error response to SASL XOAUTH2
|
|
is not clear, since only an example is given. I had to read the draft
|
|
specification at IETF to make any sorts of heads or tails out of it.
|
|
* The same flowchart is used on the "Using OAuth 2.0 for Devices" and
|
|
"Using OAuth 2.0 for Installed Applications" pages. One of them is wrong.
|
|
* There's no documentation on how to handle the case where the client
|
|
application is capable of spawning a controlled browser application and
|
|
proceeding with minimal user interaction. Right now, I think our
|
|
OAuth.jsm code works by redirecting to http://localhost/, intercepting
|
|
the redirect at the http level, and stripping the URI information from that.
|
|
* Refresh token documentation is contradictory, as mentioned above.
|
|
* There's in general very little information on what responses actually
|
|
mean. For example, is the expiry timestamp measured in milliseconds,
|
|
seconds, hours, number of total eclipses viewable from Google's
|
|
headquarters? What values are reasonably expected by these timestamps?
|
|
[This is everything I can think of off the top of my head. I'm sure
|
|
there's much more.]
|
|
|
|
--
|
|
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
|
|
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140430/10182541/attachment.html>
|