@ghostklart would you mind sharing the bits of your config you needed to put in to get as far as you have with Authentik? I can't get past the spinning wheel during login. I'm not sure if it makes a difference, but my Authentik installation is on a different host entirely (not a docker container local to opencloud). I can't make heads or tails of the opencloud documentation.

@patchmonkey I have managed to make it complete almost the full authentication using Authentik. I was stuck on the spinning wheel because of my use of confidential instead of public client type.

This fixed my CORS Issues from the Authentik side, but I still had to fix the CSP headers from the OpenCloud side (I have not managed to make the csp.yaml work for some reason, so I set it on my reverse proxy).

As you can see in my first screenshot, I had also to use an RSA signed JWT, as it did not accept HS256 JWT tokens (it complained of a missing kid).

This is also required, as by default it uses "web" as CLIENT_ID. If you plan to use other clients you will probably have to set other CLIENT_ID environment variables. I set account autoprovisioning to false, as I am using it with authentik's LDAP with provisioning disabled as I only plan to use it with existing users in Authentik anyways.

I am, though, still stuck on this message:

This is most probably due to a lack of mapping definitions between my Authentik group definitions and OpenCloud roles, but I am not sure how to set that up. I am planning to try to finish setting that up this weekend, but if you figure something out it would be great!

Actually, commenting out the LDAP configuration and enabling autoprovisioning seems to have worked somehow?

I also added a proxy.yaml as a config, but have not checked if it is required or if this is actually how it should be done.

Still, I would think you would like to map your roles properly anyway, so here it is.

It at least seems to map the roles correctly:

tried what you did, but get an issue with saying:

{
    "error": "invalid_client",
    "error_description": "Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method)"
}

And the following on the web GUI

I have set the following VARs:

WEB_OIDC_CLIENT_ID
OC_OIDC_CLIENT_ID

Seems, like either the installation does not read the vars or something...

@ghostklart

tried what you did, but get an issue with saying:

{
    "error": "invalid_client",
    "error_description": "Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method)"
}

Where is this issue displayed? Have you setup your Authentik correctly? What have you set as environment variables?

These are my only manual configuration files:

# .env.opencloud
OC_URL=https://opencloud.example.com
PROXY_TLS=false
OC_INSECURE=false

PROXY_AUTOPROVISION_ACCOUNTS=true
PROXY_ROLE_ASSIGNMENT_DRIVER="oidc"
OC_OIDC_ISSUER=https://auth.example.com/application/o/opencloud/
PROXY_OIDC_REWRITE_WELLKNOWN: "true"
WEB_OIDC_CLIENT_ID=CLIENT_ID_HERE_XXXXXXXXXXXXXXXXXXXXXX
WEB_OIDC_SCOPE=openid profile email groups
PROXY_USER_OIDC_CLAIM="preferred_username"

ONLYOFFICE_DOMAIN=onlyoffice.example.com

OC_JWT_SECRET=XXXXXXXXXXXXXXXXXXXXXX # Generated Random String
OC_TRANSFER_SECRET=XXXXXXXXXXXXXXXXXXXXXX  # Generated Random String
OC_MACHINE_AUTH_API_KEY=XXXXXXXXXXXXXXXXXXXXXX  # Generated Random String

START_ADDITIONAL_SERVICES="notifications"

# docker-compose.yml
name: opencloud

services:
  opencloud:
    container_name: opencloud
    image: opencloudeu/opencloud-rolling:${OPENCLOUD_VERSION:-latest}
    restart: always
    volumes:
      - ${APPDIR}/opencloud-config:/etc/opencloud
      - /data/test:/var/lib/opencloud
    env_file:
      - .env.opencloud
    networks:
      web_access:
    entrypoint:
      - /bin/sh
    command: ["-c", "opencloud init || true; opencloud server"]

# ${APPDIR}/opencloud-config/proxy.yaml
role_assignment:
  driver: oidc
  oidc_role_mapper:
    role_claim: groups
    role_mapping:
      - role_name: admin    # Opencloud role name
        claim_value: ADMINGROUP_XXXX # Authelia group name
      - role_name: user
        claim_value: USERGROUP_XXXX

And the reverse proxy configuration. Provider configuration is as shown on my screenshot from before. Oh, another thing is that on any change to the ENV vars I had to delete the generated configuration file. If not, changes were NOT applied correctly.

So in my case, I had to delete the ${APPDIR}/opencloud-config/opencloud.yaml and it would initialize opencloud (due to my command in the docker-compose file) again after every change I made to .env. It may be that you have not deleted this file and it is using an outdated configuration.

@scetu

Maybe you need to pass another environment variable to your compose such as OC_EXCLUDE_RUN_SERVICES: idm

Well, I replaced idp with idm, but that didn't seem to do the trick. I also tried with both: idp, idm.

@scetu With your configuration examaple i got the Login via WebUi to work, I have a very similar setup to yours. But the Login via Desktop App (im on MacOS) doesn't work, nor the Login via iOS app.
Dis you manage to get this to work?

I get the error "ERR Error mapping role names to role ids error="no roles in user claims"

This happens only for OpenCloudDesktop and OpenCloudIOS (I added this public client also with the variables from OpenCloud Documentation)

@zkvvoob my best bet is to start from scratch with opencloud_full folder, and enable (setup) only services what you need.

Also I have just realized you are missing radicale in your compose:
https://github.com/opencloud-eu/opencloud/blob/main/deployments/examples/opencloud_full/radicale.yml

Without this, my mappings were not working. Radicale is using the proxy.yaml

@michaelalbertshofer I have just downloaded Linux Desktop client and it also does not work. Seems like the client issue, see opencloud-eu/desktop#217 (comment)

I have updated the guide with fixes to consent_mode, which is now auto, directives in csp.yml now includes frame-src: for Authelia domain.
Without these fixes, Opencloud WebUI is unable to obtain refreshed token from Authelia and Opencloud will logout user after specified lifespans.

I have the feeling we are mixing up different IdPs and issues here.

1. That Discussion started in the context of Authelia, IMHO Authentik should not be discussed here.
2. CORS and Routing issues are independent of OIDC

@patchmonkey

We added large amounts of docs about general OIDC here https://docs.opencloud.eu/docs/admin/configuration/authentication-and-user-management/

There is also a deep explanation about Keycloak and OpenCloud.
There is a reason, why we are supporting that scenario: It is proven and can be used in Enterprise Scenarios.

The general issue is, that every OIDC provides is doing things "a little bit different". So it is hard to maintain docs about all the "specialties" and different approaches.

From my POV, it would be a quick win to put all the learnings in this thread together for a "OpenCloud & Authelia" documentation.

Thanks, @micbar. I think that's fair given the OP's question was about Authelia, but (selfishly as an Authentik user) I would point out that there are several people in this thread who are using/mentioned Authenik, and I don't think That should be eschewed just because the main discussion started with Authelia. Maybe a secondary document for Authentik integration can be added? I'd be willing to help contribute.

Additionally, I think it's fair to say every IdP does OIDC slightly differently, that's certainly the case...as someone whose used several (keycloak, zitadel, authentik), I've noticed that as well, however, I would argue that the primary differences between IdPs are terminology and how thinks are accomplished/configured in the IdP. To clarify the point I was trying to make is that both the required Environment variables and the current documentation about OIDC integration is inconsistent or not posted. Here's a few examples of what I mean:

1. The variables required to be set to get OIDC working with an external IdP are not consistent; some start with "OC_", some start with "PROXY_", some start with "WEB_". I realize renaming these is not always the easiest thing to do, but having a consistent prefix for variables required for OIDC connectivity would be ideal. There are also some keycloak specific variables, which makes its seem like other OIDC providers may eschewed, but admittedly that may be just me reading into it a bit too much.
2. The docs you mentioned about OIDC focus primarily on Keycloak and clients, and they don't really mention generic OIDC, and they're unclear about the requirements/how-to's. For example:
   • The doc doesn't to mention whether or not the OIDC client should be private or public
   • The doc doesn't to mention it expects the encryption certificate to be RSA (which has been mentioned by some users above)
   • The doc doesn't mention the variable for "Client ID", which is a main component for many OIDC integrations
   • The doc mentions LDAP is recommended via keycloak, but is LDAP required for OIDC in general? Is it required in Keycloak?

I don't mean any of this to come off as overly critical, The project in general looks amazing and I'm excited for where it's headed, I just think/hope there are still some backlog tasks to further improve documentation and configuration interface for non-keycloak OIDC.

First of all, thank you. Your above explanation cleared up a LOT for me. I appreciate you taking the time.

In OpenCloud we always prefix the env variables with the name of the service. That has been a design decision and is not so easy to change.

Unfortunate from an end user perspective imo, but understandable. Is there a full list of available variables somewhere with explanations of what each does? I wasn't able to find one. That would be extremely helpful.

https://docs.opencloud.eu/docs/admin/configuration/authentication-and-user-management/external-idp#client-configuration explains that all clients need to be public clients.

The first few times I read this section I completely missed that it mentions these need to be public. To be honest, I completely misunderstood what this section was for. I at first took "Client Configuration" to mean configuration settings on the desktop and mobile applications, and it wasn't until I re-read the single sentence under this header that I realized my misunderstanding.

I didn't get that comment. OpenCloud uses https via TLS. Where does RSA come into place?

This was something mentioned by @seijihariki above in one of his posts. I didn't run into this personally so I can't ellaborate. I think it has to do with the encryption algorithm used within Authentik, but I'm not certain.

The client ID is set on the IdP. https://docs.opencloud.eu/docs/admin/configuration/authentication-and-user-management/external-idp#client-configuration lists all openCloud client IDs. They are fixed in the OpenCloud clients. There is nothing to configure on the OpenCloud side

I did not understand that the administrator must change the Client ID to match what is listed in this document, and these Client IDs are hardcoded in OpenCloud and not reconfigurable from reading this document. I think the document should be a bit more explicit about that, as the user experience here diverges from many common OIDC/IdP integrations. I've integrated over 20 separate applications with my IdP, This is the first I've personally come across where this would seem to be the case. When creating new clients within the IdP, the IdP generates a unique Client ID which usually gets configured on the application side.

OpenCloud has no database, therefore it stores the users in LDAP. There are two scenarios, one with an external and one with an Internal LDAP server. ("Shared Directory mode" and "Autoprovisioning mode"). Both scenarios are explained step by step with diagrams and all needed Configuration and a pointer to a real world example in docker compose. What is missing? We are always happy to improve.

Thanks, this helps explain the role of LDAP a little better, and why it's required. There are a couple of pieces about this quote I want to comment on. Your explanation makes sense While the lack of databases is definitely mentioned, it was not immediately apparent to me that LDAP would be required for this because of the design decision not to use databases. I think it would be really helpful to mention what you've said here explicitly in the documentation, because it helps prospective users understand the basic requirements (and why they're required). Part of the confusion around the document explaining Shared Directory vs Autoprovisioning is that the doc specifies that's for Keycloak, and as someone who is not using keycloak and doesn't have all of the required information to make a non-keycloak IdP work, I was sure how much of the "Keycloak" specific documents and sections I needed to delve into and distill out to use in my setup.

Additionally, the documents have a wealth of information, but there are parts of them are sparse, and they are not optimized to help an administrator walk through process of enabling OIDC Sequentially: (e.g. First set these variables, then create a provider in your IdP, then create several clients in your IdP, then restart your containers, etc.)

What is missing? We are always happy to improve.

tl;dr

• A list of all possible ENV variables with explanation for what they do in a single place
• Documents that reflect required information/steps for all/generic OIDC/IdPs, with IdP-specific implementation steps/consideration/requirements in a separate document
• Documents that provide a specific sequential set of operations to enable external OIDC (more like the document found here

Thanks again for your explanation and patience.

I didn't get that comment. OpenCloud uses https via TLS. Where does RSA come into place?

This was something mentioned by @seijihariki above in one of his posts. I didn't run into this personally so I can't ellaborate. I think it has to do with the encryption algorithm used within Authentik, but I'm not certain.

It is more about the specific signing algorithm used for signing the JWT tokens. I was not able to make it work while using HS256, but it worked with no problems when using an RSA key (RS256 as the signing algorithm). I guess it makes sense, considering HS256 is a symmetrical algorithm, but I noted it above because I was having problems with a missing kid in the crypto header in the JWT before the change to RS256.

@patchmonkey

Here are my final configurations on Authentik:

If your problems are with CSP, here are my configurations as I set them in my nginx:

# strip any upstream CSP
proxy_hide_header Content-Security-Policy;

# now inject your full, single-line policy
add_header Content-Security-Policy
  "default-src 'none'; child-src 'self'; connect-src 'self' blob: https://opencloud.example.com https://auth.example.com wss://opencloud.example.com https://raw.githubusercontent.com/opencloud-eu/awesome-apps/; font-src 'self'; frame-ancestors 'self'; frame-src 'self' blob: https://embed.diagrams.net https://onlyoffice.example.com https://collabora.example.com https://docs.opencloud.eu; img-src 'self' data: blob: https://raw.githubusercontent.com/opencloud-eu/awesome-apps/ https://onlyoffice.example.com https://collabora.example.com; manifest-src 'self'; media-src 'self'; object-src 'self' blob:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"
  always;

auth.example.com being the host of my Authentik instance.

@seijihariki Can u make resume of configuration (Authentik configs, .env of opencloud (OpenID), etc.). Because I try to configurated like OwnCloud (https://helgeklein.com/blog/owncloud-infinite-scale-with-openid-connect-authentication-for-home-networks/), I had infinit loading in login.

Last time as i checked, there was no logout implemented in authelia.

There is a logout button in the Authelia web interface, but you can also send a redirect to https://authelia.domain.com/logout which I use for other services to log out. The issue here is that I cannot find a working way to get opencloud to redirect to that page.

I think there is an option in web.

@kulmann can you help?

Just a note: I have tried WEB_OIDC_POST_LOGOUT_REDIRECT_URI: 'https://authelia.domain.se/logout' but does not seem to work.

Client IDs can now be set freely in the opencloud rolling release. Android adapted already, there is a prerelease build which is capable of dynamic webfinger discovery. iOS and Desktop are still pending, but planned.

Maybe im blind, but im not finding the do about that, could you point me to it?

Yes i was blind: https://docs.opencloud.eu/docs/next/dev/server/services/webfinger/environment-variables#environment-variables-for-the-webfinger-service

webfinger worked for the ltest QA build of the android app, but the auth failed with an unknown error

okay, looks like the latest stable fdroid build (1.2.4) also supports the webfinger, but I get the same "unknown error" after OIDC auth

@snoweuph Please create an issue in the Android repo, also including client side and server side logs. Also screenshot of the "unknown error" so we understand where the error is from.
https://github.com/opencloud-eu/android/issues

you shouldn't set a access_token to live that long...
the refresh_token is supposed to be the long living token, and to get use it, an application requests the offline_access scope

opened an issue:
"NullPointerException in ConnectionValidator after successful OAuth token exchange"
opencloud-eu/android#172

@guruz can we try to reproduce that?

@micbar Already solved by config fix, @hobasp2 just needs to double check if the crash fix also helps (in addition) :)

I tested the fix and the NPE itself is resolved — but login still fails without PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none on the server side. The app behavior (login loop) looks the same from the outside, but the root cause is different.

Please see:
opencloud-eu/android#172 (comment)