250 lines
12 KiB
Plaintext
250 lines
12 KiB
Plaintext
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>
|