MBOX-Line: From nicolson at google.com  Thu May  1 12:22:27 2014
To: imap-protocol@u.washington.edu
From: =?UTF-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= <nicolson@google.com>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] OAUTH and IMAP
In-Reply-To: <53611C4E.7030904@comaxis.com>
References: <53608FE7.8090909@verizon.net>
	<CABa8R6sJQ0SV5O_udOusA983vE5NNbuRt27VthkCPuMbAge2yA@mail.gmail.com>
	<5360FF8D.9000201@comaxis.com>
	<20140430143517.743B37306E@mailwash38.pair.com>
	<53611C4E.7030904@comaxis.com>
Message-ID: <CACU8CfSWORaqU=NG6DrxTXFoam3N0BHFdngb91HZgJrBtTFj+Q@mail.gmail.com>

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='349847762461@developer.gserviceaccount.com',
   private_key=pkey,
   scope='https://mail.google.com/',
   prn='foo@bar.com')

creds.refresh(httplib2.Http())

print creds.access_token


This prints an access token that can login to foo@bar.com, 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 <jjmckay@comaxis.com> 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 <Pidgeot18@verizon.net>
> 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
> Imap-protocol@u.washington.edu
>  http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140501/d6098d85/attachment.html>
