Re: [Imap-protocol] OAUTH and IMAP

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 which at the least
has working examples.

On Tue, Apr 29, 2014 at 10:53 PM, Joshua Cranmer
<[email protected] >
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

[email protected]

http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

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