[Feature request] OAuth support

[Eugene Budnikov]

Please add OAuth support.
This year Google will stop password auth method on CardDav/CalDav links.
And your app is the only way to sync pure AOSP devices without gapps.

[devvv4ever]

Thank you for the information. Google is the only service we know that uses OAuth. It’d be a lot of work for only one service provider, so we didn’t do that yet. Please consider migrating away from their CalDAV/CardDAV services if you can’t/don’t want to use gapps…

[tuxcoder]

I would like to add also, that there are a bunch of projects out now that implement Oauth2/OpenID for self-hosted identity providers (ory.sh / keycloak / nextcloud/gitea/gitlab/…).

This makes it possible to secure your services with a proper newer workflow to handle access of resources.

A solution to add first Google only or a static list is fine for me, only wanted to mention, that there is also need for a decentralizes solution.

I think currently there is no RFC how to get information about the responsible oauth provider in caldav/carddav, probably worth to think about a standard.

With google you have predefined information https://accounts.google.com/.well-known/openid-configuration
But there you need to registrar an app, before it can use the API, what is than shipped statically with the app, and not works for decentralized systems.

A solution would be a .well-known url for where to go to get a access token with a predefined API, this would make it flexibel for different use cases, not sure if this in the thinking of OAuth2 standard.

Normally OAuth2 wants a separate client_id for each “App” (Webservice, Phoneapp, Desktopapp, …), there is the workflow for a Mobile App what, is more or less, what google recommends.

for reference the corresponding RFC:

• https://tools.ietf.org/html/rfc6749

A solution would be “dynamic client registration management” mention here: https://tools.ietf.org/html/rfc7592
To create a new client_id on demand at the oauth2 server.

I started research not so long ago,
probably I can give you in the future some more feedback.

Implementation in the APP:

The implementation itself should be not so much, use a lib for OAuth2 add configs for provider (client_id,client_secret,authorization_endpoint,token_endpoint) create an request,
redirect use to a browser, a bit back and fore, in the and you get a access token, with what you can access the resources by adding the header Authorization: Bearer <token>. Normally the OAuth2 library does that for you, in this case need probably other adjustments in the app in the network API layer.

If you have any question I open yo help, also to test something except google services
For the test server I currently wait until some other project have more progress ( https://www.ory.sh/oathkeeper ).
Otherwise I could setup a quick and dirty setup for testing if needed.

[outsidethelight]

I downloaded DAVx5 yesterday and it worked very nicely with my Google Workspace (formerly G Suite) account, but I had completely forgotten about the fact that Google is (for better or worse) phasing out the app passwords (I do disagree with that).

Although I’m sure it is some amount of work, it is not exactly encouraging to read that the admin’s first response is to suggest moving away from Google apps, because it is just one service provider. Surely a not insignificant portion of your user base will be using Google apps? And what about future-proofing the app for other services?

[Till]

Hi,
not only Google uses OAuth, but also ownCloud does:
https://marketplace.owncloud.com/apps/oauth2
If I’m not mistaken, DAVx5 can currently not be used with ownCloud’s two-factor authentification turned on.

[devvv4ever]

@till said in [Feature request] OAuth support:

Hi,
not only Google uses OAuth, but also ownCloud does:
https://marketplace.owncloud.com/apps/oauth2
If I’m not mistaken, DAVx5 can currently not be used with ownCloud’s two-factor authentification turned on.

If there is an option to use app-specific passwords, you could use this, but I don’t know in detail. OAuth is not supported by DAVx5.

[outsidethelight]

@devvv4ever
I am slightly disappointed with what appears to be a very made up mind against implementing OAuth, especially considering it will likely be leveraged much more in the future.

In terms of work it appears that other apps such as FairEmail are managing it without problem, despite being developed by a single person. Looking at his support page he appears to be use the native Google account to uses OAuth in his app.

“OAuth for Gmail is supported via the quick setup wizard. The Android account manager will be used to fetch and refresh OAuth tokens for selected on-device accounts.”
Link: https://github.com/M66B/FairEmail/blob/master/FAQ.md#user-content-faq111

[rfc2822]

I am slightly disappointed with what appears to be a very made up mind against implementing OAuth, especially considering it will likely be leveraged much more in the future.

Personally, I don’t think so (rather like this). Many years ago, I have put much effort into OpenID (what I see as predecessor of OAuth, and what was supposed to “be the future”, too), and basically everything I did was just wasted life time. I won’t repeat that mistake. Many things are just hypes or have limited use-cases.

As soon as OAuth is actually adopted by major CalDAV/CardDAV services, implementing it in DAVx⁵ will get higher priority.

In terms of work it appears that other apps such as FairEmail are managing it without problem, despite being developed by a single person. Looking at his support page he appears to be use the native Google account to uses OAuth in his app.

Of course it can be done. It means development, testing, maintenance and support just for Google. At the moment, this has no priority for me, because

• Google has its own, better supported calendar/contacts sync. (See also https://evertpot.com/google-carddav-issues/, quite old, but I don’t think they have changed anything; why should they?)
• Google CalDAV/CardDAV works without OAuth.
• Nobody else has OAuth. I couldn’t find a single other CalDAV/CardDAV service. Do you know one?

[Till]

@rfc2822 said in [Feature request] OAuth support:

• Nobody else has OAuth. I couldn’t find a single other CalDAV/CardDAV service. Do you know one?

Hi,
Not only Google uses OAuth, but also ownCloud does:
https://marketplace.owncloud.com/apps/oauth2

[rfc2822]

@till Does owncloud’s OAuth actually work with CalDAV? This topic from 2019 doesn’t give a clear answer to me:

I’m not aware of WebDAV/CalDAV clients with oauth2 support. Users need to create app passwords / tokens for WebDAV/CalDAV clients.

[ https://github.com/owncloud/oauth2/issues/201 ]

But you can use it with app passwords anyway.

And as far as I know, owncloud doesn’t natively support CalDAV/CardDAV (just with not officially supported plugins).

[devvv4ever]

@till We’ve been at the owncloud conference in 2019 and had a lot of talks with the people there - also about caldav and carddav. We had a nice collaboration with their app developers regarding our open source webdav libraries and app integration.

However it turned out that they don’t (want to) put so much focus on calendar and contacts - it’s rather a side thing that should merely also work - but not as a main thing.

[Till]

@devvv4ever
@rfc2822 said in [Feature request] OAuth support:

And as far as I know, owncloud doesn’t natively support CalDAV/CardDAV (just with not officially supported plugins).

In ownCloud 10.6, calendar/contacts are installed by default as an official app, branded with ownCloud as the developer. They had an unofficial status before, so maybe they got an internal upgrade to an integrated/official “app”.
One can then, optionally, use the (also “official” but) optional OAuth app to turn on two-factor authentication. Calendar/Contacts sync work with a single password when the OAuth plugin is switched off. When switched on, this plugin generates app-specific passwords automatically. This works well for iOS/macOS calendar/contact sync but not for DAVx.
That said, I can live without Oauth, but I just wanted to point out that it’s not correct that no other provider besides Google supports OAuth.

[rfc2822]

@till said in [Feature request] OAuth support:

That said, I can live without Oauth, but I just wanted to point out that it’s not correct that no other provider besides Google supports OAuth.

Thanks for the update! So at the moment, it’s:

1. Google (works without OAuth, too, but cumbersome)
2. owncloud (works without OAuth without problems)

I’m curious whether the list will grow. If you find another service, please let us know.

[outsidethelight]

Thanks for all the responses and sharing your thoughts, I appreciate it.

My previous post was a bit too vague, as I wasn’t really referring to other providers/services - I was (admittedly very selfishly) referring to the fact that G Suite is going to stop with less secure apps and app passwords and move to OAuth. At least, that’s what they emailed me previously and they said this change would be implemented from 15 February 2021 onwards. As it stands, I’m still happily using DAVx5 with the current setup so in that sense I cannot be complaining. I guess it is my personal choice to think about what to do once it really stops.

In response to your question, my honest answer is I don’t know. I guess my thoughts were more like: how much of your users are G Suite users and how many of them will run into this problem-that-was-announced-but-apparently-is-not-a-problem-yet and admittedly I was simply assuming that you will have a lot of G Suite users, but perhaps this group isn’t as big as I assumed and therefore doesn’t require your priority. Perhaps it isn’t since you’re making it clear you’re not officially supporting Google with your app.

EDIT: I have re-read that email from Google about 5 times now without getting any wiser. Perhaps I was wrong - mea culpa in that case.

[rfc2822]

@outsidethelight said in [Feature request] OAuth support:

G Suite is going to stop with less secure apps and app passwords and move to OAuth. At least, that’s what they emailed me previously and they said this change would be implemented from 15 February 2021 onwards.

Oh, I didn’t know that. That’s bad news. However they announce that for years and until now it still seems to work. Maybe they just want to increase pressure again or find a reason why they can finally drop CalDAV/CardDAV (by enforcing a system which nobody can use, so that they can later say it was not used).

[outsidethelight]

@rfc2822 said in [Feature request] OAuth support:

@outsidethelight said in [Feature request] OAuth support:

G Suite is going to stop with less secure apps and app passwords and move to OAuth. At least, that’s what they emailed me previously and they said this change would be implemented from 15 February 2021 onwards.

Oh, I didn’t know that. That’s bad news. However they announce that for years and until now it still seems to work. Maybe they just want to increase pressure again or find a reason why they can finally drop CalDAV/CardDAV (by enforcing a system which nobody can use, so that they can later say it was not used).

I guess I shouldn’t be surprised if Google is up to nefariously trying to force something…

[devvv4ever]

@outsidethelight

I guess I shouldn’t be surprised if Google is up to nefariously trying to force something…

true

[j-ed]

@rfc2822 Originally it was planned to disable LSA (less secure access) on February 15th 2021. Due to COVID-19 Google has suspended the LSA turn-off until further notice.

https://workspaceupdates.googleblog.com/2020/03/less-secure-app-turn-off-suspended.html

BTW, it might be worth to check how the developer of the FairEmail app has implemented Google OAuth2 authentication. It works like a charme once activated

[eneko]

Hi, thank you very much for this useful app and for supporting F-Droid

Nextcloud also supports OAUTH2 (we use that in our community server), you can add to the list.

[rfc2822]

@eneko Thanks! Does using OAuth provide any advantages (compared to the current solution with app passwords)?