OpenID Connect authentication backend

[azmeuk]

I suggest implementing an OIDC authentication backend that would deal with bearer tokens.

Should this belong in the main repository, or in a dedicated plugin elsewhere?
What do you think?

[MatthewHana]

The practice with Radicale appears to be that auth mechanisms are separate plugins (have a look at Arvedui/radicale-dovecot-auth for example).

Also there is a long backlog of pull requests, so it might be faster to implement it as a plugin.

[sphakka]

Interested in this, available for help/test. Maybe as a starting point, Modoboa provides a simple token-based mechanism.

[pbiering]

Addtional possible option: handover user authentication to a reverse proxy in front of "radicale"

[pbiering]

Sophisticated user authentication should be handover'ed to reverse proxy, as they have a bunch of authentication options already build-in or available via plug-in modules.

[brumik]

How would you then connect to it from a mobile app? (Like DAVx5) I would love this option to work but I fear it is impossible.

[pbiering]

You're right, as long as all potential clients are not supporting "sophisticated" user authentication, fallback to username+password must be supported. But even that can be done on reverse proxy already and radicale is simply trusting the provided username.

[brumik]

I do not think I understand you. So let's say we do not have OIDC in radicale. Then I have authentication on my reverse proxy. This method works only if I access radicale from the browser since it is working on a basis of redirect which (as far as I know) no application can handle currently on the market.

I know that oidc works similarly but there are libraries for every possible language to handle it, making it much more viable alternative.

To be clear, I am not asking you here to implement SSO, just want to understand the options as you seem to know way more about this and there is not much information about this on the internet.

Thank you!

[pbiering]

OIDC can be handled by reverse proxy (for Apache e.g. using mod_auth_openidc) and there is no need to implement OIDC in radicale so far but simply trust the authenticated user provided by the reverse proxy.

One can think about in a later step to implement OIDC directly in radicale on server side if it's proven, that all currently maintained CDAV clients out in the world are able to handle OIDC at all.

The WebUI is anyhow only for administrative collection management, only using internally CDAV protocol towards the server and can be also disabled btw.

[benbucksch]

https://gitlab.mim-libre.fr/alphabet/radicale_oauth/-/blob/dev/oauth2/README.md?ref_type=heads

[pbiering]

Thank you for the URL, will try to migrate to upstream

[benbucksch]

Note: I have not tried it myself, but just found it. Let us know how well it works.

[pbiering]

#1689 merged, please give a try and file additional PRs if required to upstream now.

One can also inform maintainers of https://gitlab.mim-libre.fr/alphabet/radicale_oauth/-/blob/dev/oauth2/ that their module is now available in upstream from 3.4.2 onwards.

[benbucksch]

Unfortunately, upon reviewing the source code, this module sends the password to the OAuth2 server. That usually will not work. It needs to accept an access token instead and check that. See my PR comment.

Sorry for having turned the attention to this module and therefore misleading you.

[pbiering]

I would assume one can extend this new module now with required variants by suppling PRs