Google OAuth for DAV

[untitaker]

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]

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]

That library probably should be an optional dependency

[geier]

Indeed.

[untitaker]

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

[untitaker]

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]

OTOH i don't see a better way.

[geier]

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

[untitaker]

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]

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]

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

[muggenhor]

@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]

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

[muggenhor]

@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]

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

[untitaker]

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]

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]

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]

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]

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

[vonpupp]

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]

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

[untitaker]

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

[geier]

but only in read-only mode

[ghost]

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]

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

[untitaker]

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.