Re: [Imap-protocol] OAUTH and IMAP

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

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