MBOX-Line: From jjmckay at comaxis.com Wed Apr 30 06:50:05 2014 To: imap-protocol@u.washington.edu From: Jeff McKay Date: Fri Jun 8 12:34:52 2018 Subject: [Imap-protocol] OAUTH and IMAP In-Reply-To: References: <53608FE7.8090909@verizon.net> Message-ID: <5360FF8D.9000201@comaxis.com> 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 > > 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 > () > 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 > (), > 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 > (), > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: