Re: [Imap-protocol] OAUTH and IMAP

Jamie,

Thank you very much for this. My code is now working after months
of experimenting and venturing down blind alleys. I should note
perhaps that I am working in C# with Google's APIs for .Net. Jeff,
you may have a little more to do working in C but, with this
intelligence, the task should be straightforward.

I do still have one problem though. My code works only with the
" https://mail.google.com/ " scope. When I try using
" https://www.googleapis.com/auth/gmail.imap_admin ", I get an
error calling RequestAccessTokenAsync on the Service Account
credential:

"Requested scopes not allowed:
https://www.googleapis.com/auth/gmail.imap_admin ",
Uri:""

Pete Maclean

At 03:22 PM 5/1/2014, 倪志明 wrote:

Admin access (aka 2-legged
OAuth) should work with an OAuth 2 Service Account. Can you try this
procedure? I'll try to get it added to the documentation:

Follow the instructions atÂ
https://developers.google.com/accounts/docs/OAuth2ServiceAccount to
create a Service Account. You will download a private key in p12 format.
Also note the Client ID and Email Address for the service
account.

Next, go into the Google Apps control panel at
https://admin.google.com . Login as
a domain administrator. Go to Security -> Advanced Settings ->
Authentication -> Manage OAuth Client Access. You’re going to add an
authorized API client. For client name, use the client ID of the service
account client you created, e.g.
349847762461.apps.googleusercontent.com . For the scope, use
" https://mail.google.com/
" orÂ

" https://www.googleapis.com/auth/gmail.imap_admin " (more on this
scope below). Hit Authorize, and it should show up as authorized for
Email (Read/WriteSend).

Now download an oauth2client library from
https://developers.google.com/api-client-library/ .

Download the library and install it per the README (running
easy_install...).

The library knows how to generate an access token given your private key,
client ID, and the account you’re trying to access. For
service_account_name, you use the email address for your Service Account.
Here’s sample python code to do this.Â

#!/usr/bin/python

import httplib2

import oauth2client.client

pkey =
open('/tmp/0426b5132da841d6de81950d55b82fbd57858ca7-privatekey.p12').read()

creds = oauth2client.client.SignedJwtAssertionCredentials(

 Â
service_account_name='[email protected] ',

  private_key=pkey,

 Â
scope=' https://mail.google.com/
',

 Â
prn='[email protected] ')

creds.refresh(httplib2.Http())

print creds.access_token

This prints an access token that can login toÂ
[email protected] , following the instructions
for XOAUTH2 Gmail access atÂ
https://developers.google.com/gmail/xoauth2_protocol .Â

Scopes: The normal scope
https://mail.google.com/ will
work, but if you useÂ
https://www.googleapis.com/auth/gmail.imap_admin , your IMAP
connection will ignore user-specific settings, such as hiding folders
from IMAP.

On Wed, Apr 30, 2014 at 8:52 AM, Jeff McKay
<[email protected] >
wrote:

Of course, 2-legged OAuth 1.0 has been "deprecated" for
several years now. I think I heard Brandon mention once

that it would not be killed until there is a replacement, since a lot
of applications depend on it. I have experimented

also with everything I can find on OAuth 2.0 and nothing works for
admin access, or the documentation is insufficient

for me to do it correctly.

On 4/30/2014 7:34 AM, Pete Maclean wrote:

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

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