[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?