294 lines
14 KiB
Plaintext
294 lines
14 KiB
Plaintext
MBOX-Line: From jjmckay at comaxis.com Thu May 1 13:10:25 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Jeff McKay <jjmckay@comaxis.com>
|
|
Date: Fri Jun 8 12:34:52 2018
|
|
Subject: [Imap-protocol] OAUTH and IMAP
|
|
In-Reply-To: <CACU8CfSWORaqU=NG6DrxTXFoam3N0BHFdngb91HZgJrBtTFj+Q@mail.gmail.com>
|
|
References: <53608FE7.8090909@verizon.net>
|
|
<CABa8R6sJQ0SV5O_udOusA983vE5NNbuRt27VthkCPuMbAge2yA@mail.gmail.com>
|
|
<5360FF8D.9000201@comaxis.com>
|
|
<20140430143517.743B37306E@mailwash38.pair.com>
|
|
<53611C4E.7030904@comaxis.com>
|
|
<CACU8CfSWORaqU=NG6DrxTXFoam3N0BHFdngb91HZgJrBtTFj+Q@mail.gmail.com>
|
|
Message-ID: <5362AA31.2060606@comaxis.com>
|
|
|
|
Thanks for this. I will work on it over the next few weeks when I have
|
|
some time. I think I tried a service account before
|
|
but got hung up on the issue of generating an access token with the
|
|
private key. I am writing in C for Windows and Linux,
|
|
and when I looked at it, there were no C libraries. But now I see that
|
|
you have Objective C with source code, so that should
|
|
help. What would be particularly useful is, as with some of your other
|
|
APIs, you provide examples of what a generated token
|
|
should be, given specific inputs.
|
|
|
|
On 5/1/2014 12:22 PM, Jamie Nicolson (???) 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
|
|
> <http://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
|
|
> <mailto:349847762461@developer.gserviceaccount.com>',
|
|
> private_key=pkey,
|
|
> scope='https://mail.google.com/',
|
|
> prn='foo@bar.com <mailto:foo@bar.com>')
|
|
>
|
|
> creds.refresh(httplib2.Http())
|
|
>
|
|
> print creds.access_token
|
|
>
|
|
>
|
|
> This prints an access token that can login to foo@bar.com
|
|
> <mailto: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
|
|
> <mailto: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
|
|
>>>> <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 <mailto: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
|
|
>>> <mailto:Imap-protocol@u.washington.edu>
|
|
>>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu <mailto: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/c0568ed1/attachment.html>
|