OCIS + Authelia

would you share your config?

sure here is my compose file:

version: "3.7"


    container_name: "ocis_owncloud"
    image: owncloud/ocis:${OCIS_DOCKER_TAG:-latest}
      - 9300:9200
      - proxy
      - /bin/sh
    # run ocis init to initialize a configuration file with random secrets
    # it will fail on subsequent runs, because the config file already exists
    # therefore we ignore the error and then start the ocis server
    command: ["-c", "ocis init || true; ocis server"]
      OCIS_OIDC_ISSUER: "https://auth.<mydomain.tld>"
      PROXY_OIDC_ISSUER: "https://auth.<mydomain.tld>"
      PROXY_OIDC_INSECURE: "false"
      PROXY_USER_OIDC_CLAIM: "preferred_username"
      WEB_OIDC_SCOPE: "openid profile email groups"
      WEB_OIDC_CLIENT_ID: "cloud.<mydomain.tld>"
      WEB_OIDC_METADATA_URL: "https://auth.<mydomain.tld>"  
      WEB_OIDC_AUTHORITY: "https://auth.<mydomain.tld>"    
      OCIS_OIDC_CLIENT_ID: "cloud.<mydomain.tld>"

      # Without this, I got the following errors in the ownCloud log:
      # Authentik: failed to verify access token: the JWT has an invalid kid: could not find kid in JWT header
      # Authelia: failed to verify access token: token contains an invalid number of segments

      # general config
      DEMO_USERS: "false"
      OCIS_URL: "https://cloud.<mydomain.tld>"
      PROXY_HTTP_ADDR: ""   # listen on all available interfaces
      OCIS_LOG_COLOR: "${OCIS_LOG_COLOR:-false}"
      PROXY_TLS: "false" # do not use SSL between Traefik and oCIS
      PROXY_USER_CS3_CLAIM: "username"
      # INSECURE: needed if oCIS / Traefik is using self-generated certificates
      OCIS_INSECURE: "false"
      OCIS_ADMIN_USER_ID: "<MyUserName>"
      SETTINGS_ADMIN_USER_ID: "<MyUserName>"
      IDM_ADMIN_USER_ID: "<MyUserName>"
      # Storage
      STORAGE_OIDC_ISSUER: https://auth.<mydomain.tld>
      - /owncloud/ocis/ocis-config:/etc/ocis
      - /mnt/nas/owncloud/ocis-data:/var/lib/ocis
      driver: ${LOG_DRIVER:-local}
    restart: always

      name: proxy

On authelia the config section for OCIS looks like this:

      - id: cloud.<mydomain.tld>
        description: ownCloud web client
        public: true
        authorization_policy: two_factor
          - openid
          - email
          - profile
          - groups
          - https://cloud.<mydomain.tld>/
          - https://<mydomain.tld>/oidc-callback.html
          - https://<mydomain.tld>/oidc-silent-redirect.html
          - code

Hi, did you manage to solve the issue of the logout ?

No unfortunately i still have the same issues.

No admin rigths and logout does not work.

For the admin rigths I manage to remove Authelia, then connect with the admin using the default authentification method, and change the admin email with my Authelia user email.

And unfortunately for the logout it is an issue between Authelia and OCIS.

1 Like

Please check our authelia efforts in the other topic Try to ship Authelia as the default IdP in the ocis binary

Logout is still missing in upstream authelia.

i was not able to remove authelia

once i remove the OIDC env variables from the container the webpage does not load anymore.

I tried to get rid of any OIDC again now it wants to authenticate via LDAP the whole time no matter what i do.

i would actually love a guide on how to get authelia working with OCIS properly. Right now it is unusable for me because logout is not working and i do not have admin rights.

oCIS cannot work without an OIDC Provider.

Okay, so, Authelia doesn’t work with OCIS because Authelia doesn’t support the RP-initiated logout extension to OIDC yet hxxps://www.authelia.com/roadmap/active/openid-connect/

Authelia does have a nonstandard logout endpoint, which could optionally be called with a redirect parameter (but, in my experience, the redirect doesn’t actually work): hxxps://authelia.example.com/logout?rd=hxxps://owncloud.example.com

So… as a stopgap measure, would it be possible to specify a nonstandard logout endpoint for OCIS to call (or redirect the user to) after logging out? This would support the use of Authelia as it is today (barring other issues), as well as other IdP’s that only implement the core specification.

1 Like

Hello the Team,
I have a proxmox server with containers Authelia / OCIS / Portainer / Jellyfin …
I don’t use proxy because I use Cloudflare Tunnels.
If i don’t use Authelia, OCIS work perfect via web - Desktop sync and IOS.
When I use authelia, juste web acces is ok, I can’t connect Ocis Desktop client and IOS.
If you can help me, I will appreciated.
Thanks Fred

Got it working somewhat with Authelia, though only with PROXY_ROLE_ASSIGNMENT_DRIVER: default
but then my role would be user.

if i set it to PROXY_ROLE_ASSIGNMENT_DRIVER: oidc i cannot login and get
**ERR** Error mapping role names to role ids error="no roles in user claims"
in the logs.

I am not sure how to claim a certain role, i guess this has to be done in authelia’s config? But i am not sure how.

Hi, been bashing my head against this wall for a few days now
I believe that this is down to authelia not sending or ocis not receiving the groups scope/claim
On the OCIS side, my .well-known/openid-configuration says it supports groups in both scopes_supported and claims_supported
Authelia side, I’ve set the scopes to openid, groups, profile, email and offline_access
OCIS debug shows me that it’s only recieved openid, profile and email claims

DBG extracted claims | service=proxy claims={
  # profile

Since its not recieving the proper claims it can’t extract role mappings, even default ones

I’ve no idea where to go from here however

@mxmeeple did you follow ownCloud Infinite Scale With OpenID Connect Authentication for Home Networks • Helge Klein? What does your ocis and authelia config look like?

OCIS needs to look up a user in the backend with one of the claims given in the userinfo / access token.

  • PROXY_USER_OIDC_CLAIM=preferred_username configures which claim to read from oidc, here the preferred_username.
  • PROXY_USER_CS3_CLAIM=username configures which user property to use.
  • You could also use PROXY_USER_OIDC_CLAIM=email and PROXY_USER_CS3_CLAIM=mail

Since Authelia has no LDAP api ocis has to maintain its own userdatabase and create accounts on the fly with PROXY_AUTOPROVISION_ACCOUNTS=true.

After logging in once you can use the generated UUID of that user to set OCIS_ADMIN_USER_ID to make him an admin account. If you want to manage the roles from authelia you have to configure it to send a claim to ocis and then look into the PROXY_ROLE_ASSIGNMENT_DRIVER env var.

But first try to make OCIS_ADMIN_USER_ID work. :wink:

Ocis hosted on files.domain.tld
Authelia on login.domain.tld, and uses a file backend

Ideally I would like a solution where I dont have to change the compose file each time

OCIS_URL: https://files.domain.tld
PROXY_TLS: "false"

APP_PROVIDER_SERVICE_NAME: app-provider-onlyoffice
APP_PROVIDER_EXTERNAL_ADDR: com.owncloud.api.app-provider-onlyoffice
APP_PROVIDER_WOPI_APP_ICON_URI: https://office.domain.tld/web-apps/apps/documenteditor/main/resources/img/favicon.ico
APP_PROVIDER_WOPI_APP_URL: https://office.domain.tld
APP_PROVIDER_WOPI_FOLDER_URL_BASE_URL: https://files.domain.tld

OCIS_OIDC_ISSUER: https://login.domain.tld
PROXY_ROLE_ASSIGNMENT_DRIVER: default #openid does not work at the moment, groups are not sent and cannot login
  - domain: login.domain.tld
    policy: bypass
  - domain: files.domain.tld
    policy: bypass
    - authorization_policy: one_factor
      description: ownCloud Infinite Scale Web Client
      id: ocis_web
      public: 'true'
      - https://files.domain.tld/
      - https://files.domain.tld/oidc-callback.html
      - https://files.domain.tld/oidc-silent-redirect.html
      - openid
      - groups
      - profile
      - email
      - offline_access
    - authorization_policy: one_factor
      description: ownCloud Infinite Scale Android Client
      id: ocis_android
      - oc://android.owncloud.com
      - openid
      - groups
      - profile
      - email
      - offline_access
      secret: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    - authorization_policy: one_factor
      description: ownCloud Infinite Scale Desktop Client
      id: ocis_desktop
      - http://localhost
      - openid
      - groups
      - profile
      - email
      - offline_access
      secret: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    - authorization_policy: one_factor
      description: ownCloud Infinite Scale iOS client
      id: ocis_ios
      - oc://ios.owncloud.com
      - oc.ios://ios.owncloud.com
      - openid
      - groups
      - profile
      - email
      - offline_access
      secret: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
      - '*'
      allowed_origins_from_client_redirect_uris: 'false'
      - authorization
      - token
      - revocation
      - introspection
      - userinfo
    disabled: false
    displayname: "admin"
    password: "REDACTED"
    email: REDACTED
      - admin
      - ocisAdmin
    disabled: false
    displayname: "test"
    password: "REDACTED"
    email: REDACTED
      - user

I double checked the auth code. We really log all claims that are minted in the token. If you take the JWT from the browser and decode it manually you should find the same claims (if authelia sends a JWT and not a opaque access token). In any case, we can’t map what isn’t there. I do wonder why your JWT contains the aud twice but has no exp. That smells fishy. Technically, oCIS will accept the token but as you said: the groups claim is missing.

Your authelia config does not use the correct id and secret for the desktop, android and iOS clients. You neet to use the default ones as in IDP Service Configuration unless you compile your own clients. Only the ocis web client id can be configured, as oCIS serves it itself.

Can you login in the web ui?


oCIS web only requests openid profile email scopes by default. You can tell oCIS web to also request groups by setting WEB_OIDC_SCOPE="openid profile email groups". But the desktop and mobile clients don’t do that. In Keycloak you can configure to always senda certain claim. In any case using oCIS web to log in will case the users to get the correct role based on the groups claim.

Let us know if this helps!

1 Like

WEB_OIDC_SCOPE="openid profile email groups" solved it for me
I will set the clients correctly now, thanks
I’d just been testing with web for now, I hadn’t even looked at the other clients yet


So this works for the WEB authentication, however it seems that the desktop client (and therefor I assume the mobile apps too) do not request groups, or any other scope. They are hardcoded for openid offline_access email profile only (lacking groups or any other scope to use for a role provider).
I found a git issue for this: owncloud/ocis/issues/6814
The provided example for Keycloak includes providing scopes that Authelia does not support (Authelia only supports openid, groups, profile, email).
With my limited understanding I am unsure how oCIS gets the roles from Keycloak since it is not requested by the clients, and AFAICT I have setup Authelia to provide the roles (via groups).
I do not understand how roles is assigned or provided, and to be quite frank, I don’t understand the entire example.
But my take away from it seems to be that it leaves me with the following options of:

  • build your own clients (not viable, I’m not in a position to build apps)
  • not use mobile/desktop clients (not ideal)
  • just cant use PROXY_ROLE_ASSIGNMENT_DRIVER: oidc (also not ideal)

Am I just doing something wrong or is it not feasible at the moment?

1 Like

I’ve tried everything to make this work, unfortunately it doesn’t.
The only solution to create an admin and have all 3 clients working (web, desktop, android) was to install ocis without authelia, create the admin user and password same as your authelia user, then add authelia.

After you login with the admin, one can add PROXY_AUTOPROVISION_ACCOUNTS: "true" and future clients can be added in authelia and will be provisioned in ocis (as normal users naturally).

There was a bug in ocis with the admin user id provisioning. We fixed that in ocis 5.0.3. Can you confirm that?