oauth2 not working. Missing docu about oauth config, missing python package requests

[SnoopAir]

The Radicale documentation does mention the ability to use OAuth2 for authentication, but it does not provide detailed information on the configuration options.

The documentation claims, that one type of authentication is "oauth". The config file mentions it as well:

# Value: none | htpasswd | remote_user | http_x_remote_user | dovecot | ldap | oauth2 | pam | denyall #type = denyall

But unfortunately there is not more information about how to configure it. Simply setting it to oauth and providing the oauth2_token_endpoint is not enough to work - as far as I can tell.

First thing is, that the latest image 3.5.1.0 is missing the python module "requests" necessary for oauth; at least judging from the log error.

After installing the missing python module, simply adding something like oauth2_client_id and oauth2_client_secret does not do the job. It's not expected as config:

radicale | [2025-03-24 13:31:04 +0000] [7] [CRITICAL] Invalid configuration: Invalid option 'oauth2_client_id' in section 'auth' in config file '/config/config'

I'm trying to use authentik to protect access to radicale. Anybody having any similar experience? Or even better: Found a solution to do so?

[pbiering]

Code was overtaken https://gitlab.mim-libre.fr/alphabet/radicale_oauth/-/blob/dev/oauth2/radicale_auth_oauth2/__init__.py

According to radicale/auth/oauth2.py the client_id is currently hardcoded to "radicale", to make this configurable related option needs to be added.

I cannot test this particular authentication module, potentially check here for more #1359

"requests" added as dependency by e0a24b1

[SnoopAir]

@pbiering : The added "requests" module looks good.

About auth overall I have to say I'm just trying to apply the little knowledge I obtained when setting up other services with traefik and authentik. Which every time I have a new one I realized I don't know was much as I would like to/should.

So if anybody with more experience in how to protect radicale behind authentik could give a hand that would be great.
Unfortunately the documentation about the authentication methods is a little spares.
Obviously "none" and denyall" are not an option ;)
Using htpasswd or pam seems also not the right thing.

What I'm looking for is a way to provide the username and password (maybe username alone would be even good enough as long as authentik has authenticated the user beforehand) to the request. So maybe "none" in fact is a viable option - if I could find out how to provide the username alongside the request to the server.

[pbiering]

another user is using "Authentic" via LDAP which needed an extension, see e.g. here

• added configuration to enable radicale LDAP with Authentik #1740
• Update ldap.py #1742

Potentially try this and others would be potentially glad if Wiki would be extended if needed:

• https://github.com/Kozea/Radicale/wiki/LDAP-authentication

[BastelBaus]

Hi @SnoopAir,

I am using Authentik and radicale via tomsquest docker container.
Following the Authentik LDAP guides carefully, applying the fixes from links above locally and adding a static timestamp to the users*, it seams to work for me. Extensive testing by letting my family use it still pending ;-)

Let me know if I can support you on this.

BR, BastelBaus

P.S.: @pbiering, the radicale ldap docu worked nice for me. Thanks for processing the PR so fast and being patient with me ;-)

*) might not be needed after the radicale fixes, I will check later

[SnoopAir]

Thanks @BastelBaus

I was using tomsquest/docker-radicale:3.5.0.1 until I manually added the "request" python package to build my own image.

About LDAP I was actually still am pretty confused. It seems I looked at it the wrong way. I thought I need a LDAP server to provide this service. Looking at it now from a new perspective my understanding seems to shift. Can you confirm my new point of view?

Authentik provides login with username and password (for example), and a LDAP provider uses additional data to pretend it's LDAP server and send the combined/creatd data to the application, thus radicale as a LDAP login? Hmmm still confused.

[BastelBaus]

Yes, you are right, I am using your option 1) (behind dockerized cloudflare daemon and nginx proxy manager).
3 should also work I assueme but I am not at all experienced here.
Just for curiosity, why is 1) not acceptable for you?
BR, BastelBaus

[nettnikl]

Hi @BastelBaus! Im in the same situation, and can maybe help explain why i dont like option 1 - it boils down to security considerations that are less than critical but more than nice-to-have for a home-lab. See #1749

[nettnikl]

Hey @SnoopAir in this thread pbiering suggests Apache+mod_auth_openidc as a solution for a problem similar to yours - maybe you can take a look. I myself am probably going to use Authentiks Reverse Proxy solution (which does the same essentially, but is already set up here), but still experimenting for now.

[pbiering]

Hey @SnoopAir in this thread pbiering suggests Apache+mod_auth_openidc as a solution for a problem similar to yours - maybe you can take a look.

If one run tests which client is supporting SSO please extend the Wiki with new rows (for still not mentioned clients) and a column about the SSO support - thank you!
https://github.com/Kozea/Radicale/wiki/Client-Status

[SnoopAir]

Thank you very much @pbiering for commenting on that and @nettnikl for the additional request #1749 . My level of understanding of authentication is still rather limited. But that's why I'm here to understand and to configure it correctly.
The list you mention for clients is basically what I will use (Thunderbird and DAVx5).

@BastelBaus : I don't want solution 1 because it does NOT hide radical behind authentik, it does NOT hide the entry page which might be vulnerable but DOES expose yet another authentication implementation which is not the main expertise of radicale development (which I'M not saying they are doing anything wrong) while authentiks purpose is ONLY about security - which I believe is better (at least I want to believe so).

But currently as mentioned earlier I don't understand the overall flow. I understand, that the reverse proxy (in my case traefik) is forwarding the request when attempting to access radical to authentik first. And authentik is suppose to verify if the user will get access or not. And so far I think I mange to configure everything.

What comes next... I don't understand. Now authentik has to reach back to either traefik and/or radicale. It needs to provide information about "who" get's access, if he is authorized and to where.

Who? well it should be the username or email, but how?
Authorized? Already don't know how
How to get this information to radicale? No idea.

I would be grateful if somebody having already a better understanding of these topics could comment. Currently I'm trying to "debug" this topics also with other services.

[pbiering]

it does NOT hide the entry page

which entry page? The WebUIs (Management and Infcloud) are only Javascript based CDAV clients running in the browser and connecting the same way as every other CDAV client is doing.

[SnoopAir]

I mean the webinterface ... how ever it works. the container allows some basic config (create/delete calanders) via a webinterface. This page should IMHO NOT be accessible from the outside.

[pbiering]

I mean the webinterface ... how ever it works. the container allows some basic config (create/delete calanders) via a webinterface. This page should IMHO NOT be accessible from the outside.

This webinterface does nothing secret...every action the webinterface is doing one can do via the same C*DAV API exposed to clients anyhow.

[nettnikl]

This is nothing a user of the web interface can control and or should trust.

[pbiering]

See also: https://github.com/Kozea/Radicale/wiki/Radicale-Custom-DAV-protocol-extensions