61 lines
3.0 KiB
Plaintext
61 lines
3.0 KiB
Plaintext
MBOX-Line: From Pidgeot18 at verizon.net Thu May 1 06:43:45 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: <5361A492.27040.8E4360E0@David.Harris.pmail.gen.nz>
|
|
References: <53608FE7.8090909@verizon.net>,
|
|
<CABa8R6sJQ0SV5O_udOusA983vE5NNbuRt27VthkCPuMbAge2yA@mail.gmail.com>,
|
|
<53611968.6010707@verizon.net>
|
|
<5361A492.27040.8E4360E0@David.Harris.pmail.gen.nz>
|
|
Message-ID: <53624F91.8080801@verizon.net>
|
|
|
|
On 4/30/2014 8:34 PM, David Harris wrote:
|
|
> Could you explain what "IMAP ID" you're talking about here? Is this
|
|
> something specific to the OAUTH2 specification, or has some kind of ID
|
|
> been added to post-RFC3501 IMAP while I was asleep?
|
|
Bron Gondwana already explained this.
|
|
|
|
> Secondly, could someone send me a link showing the intended use of
|
|
> OAUTH in an IMAP implementation? Am I correct in assuming that you are
|
|
> intended to submit a user's GMail short-term token to login to GMail instead
|
|
> of using a username/password or other SASL mechanism?
|
|
|
|
The IETF group that maintains SASL is developing a specification for a
|
|
SASL OAUTHBEARER mechanism, which is what Google's (and Microsoft's)
|
|
AUTH=XOAUTH2 is based on (different name because the RFC is still in
|
|
flux and could (and has) change from the current implementation). The
|
|
purpose of this specification is to use an OAuth 2.0 Bearer token (a
|
|
short term token that appears to last ~1 hour?) instead of other SASL
|
|
mechanisms. Attempting to read between the lines, it looks like the
|
|
intent is to move away from storing username/passwords in the local
|
|
password store but rather to store long-lived limited-access tokens, but
|
|
the documentation on how clients should be handling the password store
|
|
is completely nonexistent.
|
|
|
|
> Finally, could someone comment on how real any of this is? The Wikipedia
|
|
> article on OAUTH (I know, I know - Wikipedia is Wikipedia, but it's useful
|
|
> despite all its shortcomings) paints a picture of a vague, fractured,
|
|
> poorly-designed mechanism being torn apart by internal bickering and
|
|
> infighting.
|
|
>
|
|
> http://en.wikipedia.org/wiki/OAuth
|
|
|
|
The former editor of OAuth 2.0 resigned in the middle of the process and
|
|
became very bitter, and most of the OAuth 2.0 page seems to rely pretty
|
|
one-sidedly on his comments. I spent some time attempting to dig up less
|
|
biased and more recent security analyses of OAuth 2.0. The only one I've
|
|
found I can recommend bothering to look at is
|
|
<http://security-architect.blogspot.com/2013/06/rest-uneasy-do-we-need-to-worry-about.html>.
|
|
|
|
The best way to summarize the security of OAuth 2.0 is that "it's not
|
|
impossible to secure, but it's not required to be secure": the RFC is
|
|
extremely light on describing anything useful for building a client. If
|
|
I had a choice, I'd rather use, say, SCRAM over OAuth 2.0, but this
|
|
isn't exactly a choice I can make.
|
|
|
|
--
|
|
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
|
|
|
|
|