Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Google OAuth for DAV #8

Closed
untitaker opened this issue Mar 6, 2014 · 26 comments
Closed

Google OAuth for DAV #8

untitaker opened this issue Mar 6, 2014 · 26 comments

Comments

@untitaker
Copy link
Member

https://developers.google.com/google-apps/calendar/auth

Apparently we have to register the client at Google, not sure how we would keep the keys secret (if any) in an opensource project.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@geier
Copy link
Member

geier commented Mar 6, 2014

gcalcli uses the Google API Client, while that isn't CalDAV it's probably good enough to sync with. And if I got it right, the let every user generate his/her own secret token.

@untitaker
Copy link
Member Author

That library probably should be an optional dependency

@geier
Copy link
Member

geier commented Mar 6, 2014

Indeed.

@untitaker untitaker changed the title Support OAuth2 Support Google Calendar and Contacts Apr 5, 2014
@untitaker
Copy link
Member Author

Renamed from "Support OAuth" to "Support Google Calendar and Contacts" as using the Google API client doesn't really mean support for OAuth.

@untitaker untitaker added this to the 0.2.0 milestone Apr 5, 2014
@untitaker
Copy link
Member Author

gcalcli seems to have hardcoded credentials inside the code https://github.com/insanum/gcalcli/blob/master/gcalcli#L163 I am not sure if that's the way to go.

@untitaker
Copy link
Member Author

OTOH i don't see a better way.

@geier
Copy link
Member

geier commented May 1, 2014

The user could still get personalized credentials that would go in the config file.

@untitaker
Copy link
Member Author

Also events and tasks don't seem to be based on ICALENDAR. We could use the icalendar library to convert the items, but i don't see a solution for contacts contacts can be handled with the Collection baseclass of icalendar.

@untitaker
Copy link
Member Author

While it was already clear that Google Calendar also provides a CalDAV interface, there doesn't seem to be a mention that it is read-only, as was assumed by me all the time

@geier
Copy link
Member

geier commented Jun 2, 2014

While I didn't check either, I somehow always assumed it would be read & write.

@untitaker untitaker removed this from the 0.2.0 milestone Jun 12, 2014
@muggenhor
Copy link

@untitaker I've been using Lightning/Iceowl for a while now with Google's CalDAV and VEVENT creation/modification/deletion works just fine. Can't say I've ever tried VTODO with Google though.

@untitaker
Copy link
Member Author

@muggenhor Interesting... do you have to provide username and password in Lightning, or does it support OAuth?

@muggenhor
Copy link

@untitaker you don't provide a password, instead it opens an in-process browser window where you can log in to your Google account and authorize Lightning for access to your calendar.

I'm not sure whether that was OpenID or OAuth (or maybe both look similar?) but it should be either one of them.

@untitaker
Copy link
Member Author

Yes, that was OAuth. We currently don't support that.

@untitaker untitaker changed the title Support Google Calendar and Contacts Support OAuth (Google services) Sep 4, 2014
@untitaker
Copy link
Member Author

For the record:

  • The most popular OAuth library to use seems to be oauthlib. Since we use requests, requests-oauthlib would be sensible to use.
  • There's no way to safely store OAuth credentials in the application, which is why i think the user should set it themselves.

The implementation should be straightforward, but i don't want to have to support this myself. I'd be glad if somebody volunteers to take this over, implement it and maintain it.

@fungs
Copy link

fungs commented Oct 14, 2014

As I understand correctly, Google would work with CalDAV + OAuth and vdirsyncer speaks CalDAV but not OAuth. So the only thing that keep vdirsyncer to be used to bidirectionally sync a Google with an OwnCloud calender is the implementation of OAuth? While I cannot contribute this functionality, I'm waiting for this to be implemented in oder to migrate from our Google to our OwnCloud calenders. Last time I was looking here was version 0.1.5. Sorry I can't help but I just wanted to say that there is practical relevance to this issue. Thanks for writing vdirsyncer, this is really good software.

@untitaker
Copy link
Member Author

As I understand correctly, Google would work with CalDAV + OAuth and vdirsyncer speaks CalDAV but not OAuth.

That's correct.

So the only thing that keep vdirsyncer to be used to bidirectionally sync a Google with an OwnCloud calender is the implementation of OAuth?

I assume so. I think the user would have to use Google Developer services to register the application themselves because otherwise somebody else may use my registered app for malicious purposes.

@fungs If you just want to copy the calendar data from Google Calendar to ownCloud, i think you can export a .ics file from Google Calendar. ownCloud might support import of that file, otherwise you can use vdirsyncer's singlefile-storage to import that file.

@untitaker
Copy link
Member Author

Well, at least OAuth is the main part that's missing from compatibility with Google. You might want to take a look at https://twitter.com/evertp/status/520618656942673920 for problems that could arise.

@untitaker
Copy link
Member Author

Follow-up blog post from that guy: http://evertpot.com/google-carddav-issues/

@vonpupp
Copy link

vonpupp commented Nov 28, 2014

Hello,

I have a suggestion for OAuth token handling: what if vdirsyncer has a default token (similar to gcalcli) but those tokens can be override by the user using OS environments vars. In that way the app could be loaded using python's envdir package or similar.

@untitaker
Copy link
Member Author

The idea of a default token seems good, but I'd rather keep it in the config file. envdir seems interesting though.

@untitaker
Copy link
Member Author

It seems khal already used to work with Google: pimutils/khal#18

@geier
Copy link
Member

geier commented Dec 1, 2014

but only in read-only mode

@ghost
Copy link

ghost commented Mar 23, 2015

Is the default token really needed? Looking at https://github.com/insanum/gcalcli/blob/master/gcalcli#L642, you just need to call OAuth2WebServerFlow from oauth2client.client to do the browser dance.

@untitaker
Copy link
Member Author

Yes, one has to call it with client-id and -secret. I myself don't have any incentive to work on this though.

@untitaker untitaker changed the title Support OAuth (Google services) Google OAuth for DAV Nov 23, 2015
@untitaker
Copy link
Member Author

Somebody mailed me in private and hinted that adding OAuth support to this is now easier since remoteStorage support is now merged into master, which already uses OAuth.

  • First of all, OAuth can't even be described as a proper standard. Many things can be described "OAuth-compatible", and I suspect that Google's OAuth implementation is vastly more complex than the one remoteStorage prescribes.

    Concretely, remoteStorage requires us to implement what is called the "implicit grant". flow. Basically you acquire one access_token, and that token will be used for any further authentication at all times.

    However, other variants of OAuth may require us to acquire a token to request another token that may be rotated every n days. For reasons I haven't looked into, this enhances security in case any credentials are stolen, but it's obviously harder to implement.

    It also means that if we implement OAuth for Google, this form of OAuth probably can't be reused for other services that require OAuth too, since no two OAuth implementations look alike.

  • Google's CalDAV implementation is allegedly okay, while CardDAV seems to be abysmal. See http://evertpot.com/google-carddav-issues/ (already posted above).

  • As already outlined above, we'd have to register vdirsyncer as an application with Google, and then provide another token to Google to identify ourselves as that application. We have a problem here: Should we let the user "play developer" and register their own application, and then let vdirsyncer "impersonate" that application? Or should we ship with a default token?

    • If the user registers their own application, using vdirsyncer with Google becomes somewhat hard to use.
    • If we ship with default token, anybody can easily steal that token and use it in their own apps.

    I think we should ship with a default token registered by me or whoever would maintain Google OAuth support.

Personally I won't be implementing this. I really don't care about supporting vendor-specific auth flows this complex.

homu added a commit that referenced this issue Apr 2, 2016
Google contacts and calendar

- [x] Proper documentation
- [x] With the refactor, `get_storage_init_args` now misses a lot of arguments for all DAV and Google storage types

Fix #8
@homu homu closed this as completed in #399 Apr 2, 2016
@untitaker untitaker removed the planning label Apr 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants