Re: [Imap-protocol] OAUTH and IMAP
Jeff McKay <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <[email protected]> |
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='[email protected]
> <mailto:[email protected]>',
> private_key=pkey,
> scope='https://mail.google.com/',
> prn='[email protected] <mailto:[email protected]>')
>
> creds.refresh(httplib2.Http())
>
> print creds.access_token
>
>
> This prints an access token that can login to [email protected]
> <mailto:[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]
> <mailto:[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
>>>> <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] <mailto:[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]
>>> <mailto:[email protected]>
>>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
> _______________________________________________
> Imap-protocol mailing list
> [email protected] <mailto:[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