ownCloud Infinite Scale With OpenID Connect Authentication for Home Networks
This article explains how to set up ownCloud Infinity Scale with OpenID Connect authentication to Authelia or authentik. This post is part of my series on home automation, networking & self-hosting that shows how to install, configure, and run a home server with (dockerized or virtualized) services such as Home Assistant and ownCloud.
Why ownCloud?
Motivation to Move Away From Tresorit
Before setting up ownCloud on my new home server, I used Tresorit for our family’s data. Tresorit is an end-to-end encrypted cloud-based file sync and share service. While I’m generally happy with Tresorit’s core functionality, there are multiple reasons to move away from it:
- Price: replace an expensive cloud service with a self-hosted application.
- Restore: Tresorit’s restore functionality for deleted files sucks.
- Setup: the installer doesn’t work well if the Windows user doesn’t have admin rights.
- Functionality: there haven’t been any significant new features in years (hint: ACLs).
ownCloud vs. Nextcloud
ownCloud and Nextcloud originally were one company before the 2016 fork that created Nextcloud. Since then, both companies have developed independent products that slowly diverged due to different focus areas.
Stability vs. Functionality
ownCloud seems to be more focused on stability and the core file-sharing functionality. Nextcloud, on the other hand, is trying to offer a jack-of-all-trades kind of product with conferencing, calendar, contacts, mail, office, and, of course, file sharing.
ownCloud Infinite Scale (oCIS)
Just in time for my project, ownCloud completed a complete rewrite of the entire product. The new ownCloud Infinite Scale (oCIS) replaced the dated PHP codebase that ownCloud shared with Nextcloud with a modern microservices architecture for higher speed and scalability. oCIS only needs a single container and doesn’t use a database. Metadata is stored in the filesystem instead.
Mobile Apps
Last, but not least, the ownCloud Android app is rated much better than Nextcloud’s.
Preparation
I’m assuming that you’ve set up Docker, the Caddy container, and either Authelia or authentik as described in the previous articles in this series.
ownCloud oCIS Installation in Docker Container
Directory Structure
This is what the directory structure will look like when we’re done:
rpool/
└── encrypted/
└── docker/
└── ownCloud/
├── config/
├── data/
├── container-vars.env
└── docker-compose.yml
We’re placing the configuration on the encrypted ZFS dataset (rpool/encrypted
).
Create the directories and set their owners to user/group ID 1000, which are used by dockerized ownCloud (docs):
mkdir -p /rpool/encrypted/docker/ownCloud/config
mkdir -p /rpool/encrypted/docker/ownCloud/data
chown -Rfv 1000:1000 /rpool/encrypted/docker/ownCloud/config
chown -Rfv 1000:1000 /rpool/encrypted/docker/ownCloud/data
Docker Compose File
Create docker-compose.yml
with the following content:
services:
owncloud:
container_name: owncloud
hostname: owncloud
image: owncloud/ocis:latest
restart: unless-stopped
networks:
- caddy_caddynet
entrypoint:
- /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"]
expose:
- 9200
env_file:
- container-vars.env
volumes:
- ./config:/etc/ocis
- ./data:/var/lib/ocis
networks:
caddy_caddynet:
external: true
container-vars.env File
Create container-vars.env
with the following content:
DEMO_USERS=false # do not create demo users
PROXY_TLS=false # use the HTTP server instead of the HTTPS server.
OCIS_INSECURE=true # generate self-signed certificates
OCIS_URL=https://owncloud.home.yourdomain.com # replace with your domain
PROXY_HTTP_ADDR=0.0.0.0:9200 # listen on all available interfaces
OCIS_LOG_LEVEL=info
OCIS_LOG_COLOR=true
OCIS_LOG_PRETTY=true
Start the Container
Navigate into the directory with docker-compose.yml
and run:
docker compose up -d
Print the container’s output by running docker compose logs --tail 30 --timestamps
. You should see something similar to the following:
owncloud | 2022-12-18T22:39:03.042863506Z
owncloud | 2022-12-18T22:39:03.042886195Z =========================================
owncloud | 2022-12-18T22:39:03.042889056Z generated OCIS Config
owncloud | 2022-12-18T22:39:03.042891413Z =========================================
owncloud | 2022-12-18T22:39:03.042893508Z configpath : /etc/ocis/ocis.yaml
owncloud | 2022-12-18T22:39:03.042895498Z user : admin
owncloud | 2022-12-18T22:39:03.042899121Z password : 1234123412341234123412412341
owncloud | 2022-12-18T22:39:03.042901222Z
Store the admin user’s password safely.
Let’s Encrypt Certificate via Caddy
Caddyfile
Add the following to Caddyfile
(details):
owncloud.{$MY_DOMAIN} {
reverse_proxy owncloud:9200
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
DNS A Record
Add the following A record to your DNS domain:
owncloud.home.yourdomain.com 192.168.0.4 # replace with your Docker host's IP address
Try to resolve the name on a machine in your network (e.g., nslookup owncloud.home.yourdomain.com
). If that fails, you might need to work around DNS rebind protection in your router.
Reload Caddy’s Configuration
Instruct Caddy to reload its configuration by running:
docker exec -w /etc/caddy caddy caddy reload
You should now be able to log into ownCloud’s web interface at https://owncloud.home.yourdomain.com
with the user admin
and the password displayed on the console after the first start of the ownCloud container (see above).
Create Your ownCloud User Account
While ownCloud supports single sign-on via OpenID Connect, it currently doesn’t seem to support auto-provisioning via the environment variable PROXY_AUTOPROVISION_ACCOUNTS
in the scenario presented here. That might not be a bad thing since I don’t want every user defined in Authelia to automatically have access to ownCloud, too.
We, therefore, need to create users manually. Navigate to Application switcher > User management > Users and create a new user for yourself. Assign a complex password – just in case. You shouldn’t need it. When the user is created, edit it and assign the Admin
role.
SSO via Authelia: ownCloud OpenID Connect Authentication
This section describes how to set up single sign-on to ownCloud via OpenID Connect authentication to Authelia. If you prefer to use authentik, you can skip this section and move on to the alternative configuration below.
Authelia: Configure OpenID Connect IdP
Secrets
Add the following to Authelia’s container-vars.env
file (details):
AUTHELIA_IDENTITY_PROVIDERS_OIDC_HMAC_SECRET_FILE=/secrets/IDENTITY_PROVIDERS_OIDC_HMAC_SECRET
# Enable the template filter to reference file secrets in the configuration
X_AUTHELIA_CONFIG_FILTERS=template
Generate random alphanumeric strings and store them in individual files in the secrets
directory:
cd /rpool/encrypted/docker/authelia/
tr -cd '[:alnum:]' < /dev/urandom | fold -w "64" | head -n 1 > ./secrets/IDENTITY_PROVIDERS_OIDC_HMAC_SECRET
Generate an RSA keypair:
cd /rpool/encrypted/docker/authelia/secrets/
openssl genrsa -out IDENTITY_PROVIDERS_OIDC_JWKS 4096
YAML Configuration File
Add the following to Authelia’s configuration file config/configuration.yml
(details):
identity_providers:
oidc:
# Extend the access and refresh token lifespan from the default 30m to work around ownCloud client re-authentication prompts every few hours.
# It should be possible to remove this once Authelia supports dynamic client registration (DCR).
# Note: ownCloud's built-in IDP uses a value of 30d.
lifespans:
access_token: 30d
refresh_token: 30d
jwks:
- key: {{ secret "/secrets/IDENTITY_PROVIDERS_OIDC_JWKS" | mindent 10 "|" | msquote }}
cors:
endpoints:
- authorization
- token
- revocation
- introspection
- userinfo
clients:
## Source: https://doc.owncloud.com/ocis/next/deployment/services/s-list/idp.html
- client_id: ownCloud-web
client_name: ownCloud web client
public: true
redirect_uris:
- https://owncloud.home.yourdomain.com/
- https://owncloud.home.yourdomain.com/oidc-callback.html
- https://owncloud.home.yourdomain.com/oidc-silent-redirect.html
- client_id: xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69
client_name: ownCloud desktop client
# Well-known secret as plaintext
# client_secret: 'UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh'
# Well-known secret hashed
client_secret: '$pbkdf2-sha512$310000$.z/6sV7qQSx1.5zPetVVCQ$JIEPOTFTSokJjDNVhlMLq7tYnHd/E17wSHW.GYXQA0QjfTPqTosyRr7qSHxSiPmXympfTbGF6FmnnX9on.uQng'
scopes:
- openid
- groups
- profile
- email
- offline_access
redirect_uris:
- http://127.0.0.1
- http://localhost
allow_multiple_auth_methods: true
grant_types:
- refresh_token
- authorization_code
response_types:
- code
- client_id: e4rAsNUSIUs0lF4nbv9FmCeUkTlV9GdgTLDH1b5uie7syb90SzEVrbN7HIpmWJeD
client_name: ownCloud Android app
# Well-known secret as plaintext
# client_secret: 'dInFYGV33xKzhbRmpqQltYNdfLdJIfJ9L5ISoKhNoT9qZftpdWSP71VrpGR9pmoD'
# Well-known secret hashed
client_secret: '$pbkdf2-sha512$310000$Grnc1pW0blLl.2B1aEfEvg$JWW3s83SXkgSvoykJ5yD4i11gfrxBOEEGrKXjbyAh.PmVc14FDwSAzxVn7JFXjvO0B0V2RxFsrUT4RZoBK93ug'
scopes:
- openid
- groups
- profile
- email
- offline_access
redirect_uris:
- oc://android.owncloud.com
allow_multiple_auth_methods: true
grant_types:
- refresh_token
- authorization_code
response_types:
- code
- client_id: mxd5OQDk6es5LzOzRvidJNfXLUZS2oN3oUFeXPP8LpPrhx3UroJFduGEYIBOxkY1
client_name: ownCloud iOS app
# Well-known secret as plaintext
# client_secret: 'KFeFWWEZO9TkisIQzR3fo7hfiMXlOpaqP8CFuTbSHzV1TUuGECglPxpiVKJfOXIx'
# Well-known secret hashed
client_secret: '$pbkdf2-sha512$310000$O1agtCxk9EGgvVLZBJumVQ$4UmQmefvIe5jQx1iJDN5pFIuu6CG.v.59wK7xCk3KU6pGbtxGrO0OYtQ/m/TPzE1xZnxgO12.ujXN20sCr/LkQ'
scopes:
- openid
- groups
- profile
- email
- offline_access
redirect_uris:
- oc://ios.owncloud.com
- oc.ios://ios.owncloud.com
allow_multiple_auth_methods: true
grant_types:
- refresh_token
- authorization_code
response_types:
- code
Restart Authelia
We changed the container’s environment, which makes it necessary to recreate the container (stopping and starting is not enough). Navigate into the authelia
directory and run:
docker compose down
docker compose up -d
Inspect the container logs for errors with the command docker compose logs --tail 30 --timestamps
.
ownCloud: Enable OpenID Connect Authentication
container-vars.env File
Add the following to ownCloud’s container-vars.env
:
OCIS_OIDC_ISSUER=https://auth.home.yourdomain.com # replace with your domain (no slash at end of domain!)
WEB_OIDC_CLIENT_ID=ownCloud-web # replace with your client ID
PROXY_OIDC_REWRITE_WELLKNOWN=true
# 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
PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none
Restart ownCloud
We changed the container’s environment, which makes it necessary to recreate the container (stopping and starting is not enough). Navigate into the owncloud
directory and run:
docker compose down
docker compose up -d
Inspect the container logs for errors with the command docker compose logs --tail 30 --timestamps
.
Caddy: Remove ownCloud’s OIDC Prompt Parameter for Authelia
When authenticating via OpenID Connect in the browser, ownCloud’s desktop client sends a prompt
parameter that Authelia doesn’t yet know how to handle (it’s planned for OIDC beta 7). To work around this temporary limitation, I removed the offending parameter with a uri replace
Caddy command. The complete Caddyfile
now looks like this:
auth.{$MY_DOMAIN} {
# This is necessary until Authelia learns prompt handling. It's planned for beta 7 (https://www.authelia.com/roadmap/active/openid-connect/#beta-7).
# Without this, the ownCloud desktop client cannot authenticate.
uri /api/oidc/authorization replace &prompt=select_account%20consent ""
reverse_proxy authelia:9091
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
Reload Caddy’s Configuration
Instruct Caddy to reload its configuration by running:
docker exec -w /etc/caddy caddy caddy reload
You should now be able to log into ownCloud’s web interface at https://owncloud.home.yourdomain.com
with the user defined in Authelia.
SSO via authentik: ownCloud OpenID Connect Authentication
This section describes how to set up single sign-on to ownCloud via OpenID Connect authentication to authentik. If prefer to use Authelia, you can ignore this section and use the alternative configuration above.
authentik: Configure Domain-Level Proxy Provider
Every domain protected by authentik needs a proxy definition so that authentik knows what to do with requests to the domain’s URL. This also enables us to define exclusions for paths that must be accessible without authentication.
Modify the domain-level proxy provider we created in the last article by adding unauthenticated paths. Navigate to Applications > Providers. Edit the Home forward auth
provider and add the following to Unauthenticated paths:
https://owncloud.home.yourdomain.com/*
The reasoning behind this: we don’t need authentik to enforce ownCloud authentication; ownCloud does that on its own. Certain ownCloud paths must be accessible without authentication, e.g., /default.php
.
authentik: Configure OpenID Connect IdP
Create OIDC Providers
We need to create OIDC client configurations for ownCloud’s four different apps: web, desktop, Android, and iOS. The required settings are documented here and are also part of the Keycloak configuration example. In authentik, OIDC clients are configured as providers.
Prepare creating providers by navigating to Admin Interface > Applications > Providers.
OIDC Provider for the ownCloud Web Client
Create a new OAuth2/OpenID Provider with the following settings:
- Name: ownCloud-Web-OIDC
- Authorization flow: default-provider-authorization-explicit-consent
- Client type: Public
- Client ID: [use the autogenerated value]
- Redirect URIs:
https://owncloud.home.yourdomain.com/
https://owncloud.home.yourdomain.com/oidc-callback.html
https://owncloud.home.yourdomain.com/oidc-silent-redirect.html
OIDC Provider for the ownCloud Desktop Client
Create a new OAuth2/OpenID Provider with the following settings:
- Name: ownCloud-Desktop-OIDC
- Authorization flow: default-provider-authorization-explicit-consent
- Client type: Confidential
- Client ID: xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69
- Client secret: UBntmLjC2yYCeHwsyj73Uwo9TAaecAetRwMw0xYcvNL9yRdLSUi0hUAHfvCHFeFh
- Redirect URIs:
http://127.0.0.1(:.*)?
http://localhost(:.*)?
OIDC Provider for the ownCloud Android App
Create a new OAuth2/OpenID Provider with the following settings:
- Name: ownCloud-Android-OIDC
- Authorization flow: default-provider-authorization-explicit-consent
- Client type: Confidential
- Client ID: e4rAsNUSIUs0lF4nbv9FmCeUkTlV9GdgTLDH1b5uie7syb90SzEVrbN7HIpmWJeD
- Client secret: dInFYGV33xKzhbRmpqQltYNdfLdJIfJ9L5ISoKhNoT9qZftpdWSP71VrpGR9pmoD
- Redirect URIs:
oc://android.owncloud.com
OIDC Provider for the ownCloud iOS App
Create a new OAuth2/OpenID Provider with the following settings:
- Name: ownCloud-iOS-OIDC
- Authorization flow: default-provider-authorization-explicit-consent
- Client type: Confidential
- Client ID: mxd5OQDk6es5LzOzRvidJNfXLUZS2oN3oUFeXPP8LpPrhx3UroJFduGEYIBOxkY1
- Client secret: KFeFWWEZO9TkisIQzR3fo7hfiMXlOpaqP8CFuTbSHzV1TUuGECglPxpiVKJfOXIx
- Redirect URIs:
oc://ios.owncloud.com
oc.ios://ios.owncloud.com
Create Applications
In authentik, providers have a 1:1 relationship with applications. Every provider needs an application that specifies the appearance of and controls who has access to the provider.
Prepare creating applications by navigating to Admin Interface > Applications > Applications.
Application for the ownCloud Web Client
Create a new Application using the following settings:
- Name: ownCloud web client
- Provider: ownCloud-Web-OIDC
- Launch URL:
https://owncloud.home.yourdomain.com
- Icon: upload a square icon that is displayed on the library page (“my applications”). I used this one.
Application for the ownCloud Desktop Client
Create a new Application using the following settings:
- Name: ownCloud desktop client
- Provider: ownCloud-Desktop-OIDC
- Launch URL:
blank://blank
(this hides the application in the library page (“my applications”))
Application for the ownCloud Android App
Create a new Application using the following settings:
- Name: ownCloud Android app
- Provider: ownCloud-Android-OIDC
- Launch URL:
blank://blank
Application for the ownCloud iOS App
Create a new Application using the following settings:
- Name: ownCloud iOS app
- Provider: ownCloud-iOS-OIDC
- Launch URL:
blank://blank
ownCloud: Enable OpenID Connect Authentication
container-vars.env File
Still in authentik’s admin interface, navigate to Applications > Providers > ownCloud-Web-OIDC. From the values displayed here, you need the following in your ownCloud configuration:
- OpenID Configuration Issuer
- Client ID
Add the following to ownCloud’s container-vars.env
, filling in the values above:
OCIS_OIDC_ISSUER=https://auth.home.yourdomain.com/application/o/owncloud-web-client/ # replace with your domain
WEB_OIDC_CLIENT_ID=YOUR_CLIENT_ID # replace with your client ID
PROXY_OIDC_REWRITE_WELLKNOWN=true
# Without this I got the following error in the ownCloud log: failed to verify access token: the JWT has an invalid kid: could not find kid in JWT header
PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none
Restart ownCloud
We changed the container’s environment, which makes it necessary to recreate the container (stopping and starting is not enough). Navigate into the owncloud
directory and run:
docker compose down
docker compose up -d
Inspect the container logs for errors with the command docker compose logs --tail 30 --timestamps
.
Caddy: Enable Forward Authentication via authentik
Caddyfile
Add the import authentik
directive to the ownCloud section of your Caddyfile
(details). It should now look as follows:
owncloud.{$MY_DOMAIN} {
import authentik
reverse_proxy owncloud:9200
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
Reload Caddy’s Configuration
Instruct Caddy to reload its configuration by running:
docker exec -w /etc/caddy caddy caddy reload
You should now be able to log into ownCloud’s web interface at https://owncloud.home.yourdomain.com
with the user-defined in authentik.
Create Spaces
Spaces are a new and very useful feature of ownCloud. Think of a space as a data container that can be shared with others. Spaces can be synchronized independently of each other, so you can choose which spaces you need on any given device.
Examples of the spaces that I’m using:
- My data
- Pictures
- Videos
- Music
When you create a space you may want to remove the default 1 GB quota.
Install ownCloud Client Apps
Windows Desktop Client
Download the desktop app for Windows. You’ll find the current version here, older versions, as well as daily builds, betas, etc., are available here.
When you launch the app after the installation, the connection wizard comes up. Enter the server address https://owncloud.home.yourdomain.com
and click Next. Authenticate in the browser. After that, the ownCloud client should tell you that you’re all set. If you close the wizard, it’ll sync your personal folder as well as your spaces to subfolders of %USERPROFILE%\ownCloud
.
Different Sync Target Directories per Space
You may want to click Advanced configuration instead and select Configure synchronization manually. Now you can configure spaces individually and sync them to different directories on your machine. To configure synchronization of a space (or your personal folder), click Add a space (which is incorrectly labeled Add folder sync connection in version 3.0 of the desktop client).
Desktop Client Settings
In the client’s settings, I de-selected Ask for confirmation before synchronizing folders larger than 499 MB.
Sync Errors (Access Denied)
If you get access denied errors while synchronizing (Error updating metadata: WindowsError: ffffffff80070005
), take a look at this issue. It’ll hopefully be fixed in a future version of the client (I’m using 3.0).
To work around the errors, you have two options:
- disable virtual file support
- assign
full control
file system permissions on the synchronized files and folders
Notes
Applications/Extensions
- oCIS cannot use the applications from the ownCloud Marketplace. Due to its new architecture, it requires new types of add-ons called extensions (docs).
Add CORS Support for Caddy (Not Required)
Note: This was part of my original configuration. As I found out, CORS handling can be configured much more elegantly in Authelia. I’m leaving this description here in case someone may need it in the future.
Caddy doesn’t come with support for CORS (cross-origin resource sharing), which means that ownCloud’s JavaScript code cannot access Authelia’s resources for authentication. We’ll fix that by defining a generic snippet that can be used with any application to be protected by Authelia. Add the following to Caddyfile
(details):
#
# CORS handling
# This is a modified version of: https://kalnytskyi.com/posts/setup-cors-caddy-2/
#
(cors) {
@cors_preflight method OPTIONS
@cors header Origin {args[0]}
handle @cors_preflight {
header {
Access-Control-Allow-Origin "{args[0]}"
Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE, OPTIONS"
Access-Control-Allow-Headers *
Access-Control-Max-Age "3600"
defer
}
respond "" 204
}
handle @cors {
header {
Access-Control-Allow-Origin "{args[0]}"
Access-Control-Expose-Headers *
defer
}
}
}
Add the directive import cors ownCloud-URL
to the Authelia section of your Caddyfile
. It should now look as follows:
auth.{$MY_DOMAIN} {
import cors https://owncloud.{$MY_DOMAIN}
reverse_proxy authelia:9091
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
Changelog
2024-10-13
- Switched from the deprecated
identity_providers.oidc.issuer_private_key
toidentity_providers.oidc.jwks
.
2024-04-14
- Removed the
version
fromdocker-compose.yml
; a warning mentions that it’s obsolete.
2024-03-17
Updated Configuration for Authelia 4.38 & ownCloud 5
The following Authelia settings need to be changed or updated (see also Authelia issue #6904):
- Migrate
oidc.access_token_lifespan
andoidc.refresh_token_lifespan
tolifespans.*
. - Add
oidc.clients.id.allow_multiple_auth_methods
. - Add
oidc.clients.id.grant_types
. - Add
oidc.clients.id.response_types
. - Rename
oidc.clients.id
tooidc.clients.client_id
. - Rename
oidc.clients.description
tooidc.clients.client_name
. - Rename
oidc.clients.secret
tooidc.clients.client_secret
.
Unresolved warnings:
configuration key 'identity_providers.oidc.issuer_private_key' is deprecated in 4.38.0 and has been replaced by 'identity_providers.oidc.jwks'
. However, when renamingAUTHELIA_IDENTITY_PROVIDERS_OIDC_ISSUER_PRIVATE_KEY_FILE
toAUTHELIA_IDENTITY_PROVIDERS_OIDC_JWKS_FILE
Authelia won’t start.session: option 'domain' is deprecated in v4.38.0 and has been replaced by a multi-domain configuration
. Apparently, the cookie session domain now cannot be specified as an environment variable anymore (source).
2023-11-22
Moved CORS Handling from Caddy to Authelia
CORS can be handled much more elegantly by making adding the cors
setting to Authelia’s configuration than by fiddling around with requests in Caddy.
Troubleshooting Attempts
I fruitlessly experiemented with the Authelia configuration, trying to get rid of a nasty bug affecting the ownCloud Android app: after filling out the server URL in the ownCloud app and successfully authenticating with Authelia, the user is redirected to the server address screen, but now the URL empty. I also tried to get rid of the frequent prompts for reauthentication – again, fruitlessly.
I tried the following changes to Authelia’s oidc
configuration:
- Setting
public
totrue
, commenting out the secret (which isn’t secret anyway) and adding the client’sid
asaudience
. - Setting
consent_mode
topre-configured
andpre_configured_consent_duration
to1m
.
It seems the frequent reauthentications are a refresh token issue which will be fixed in Authelia’s next version 4.38.0, hopefully to be released soon (source).
2023-10-14
Caddyfile:
- Replaced
{args.0}
with{args[0]}
for compatibility with Caddy 2.7.x.
2023-06-17
Added the following to Authelia’s configuration file:
- Missing lines containing
identity_providers:
andoidc:
. access_token_lifespan: 2d
andrefresh_token_lifespan: 3d
to work around frequent prompts to re-authenticate in the ownCloud (desktop and Android) apps.
35 Comments
Amazing blog and thank your for your detailed description of your home automation series.
I’ve managed to follow you to the letter and all services are up (internal).
My question is, how would we go about for external ones (say plex etc).
If currently say plex.home.domain.com is lan only, adding a CNAME for plex.domain.com with my IP ddns break the internal one?
What is your approach to external services? Do you use a different domain altogether? Or 2 instances of caddy?
Thanks!
Happy you like the series! It’s far from being completed, by the way. I’ll write more articles as I add more services to my server.
To answer your question: it depends on what you want to achieve. If you want to be able to access internal resources while away from home, consider setting up a VPN with Wireguard. This is what I’m planning to do.
If you want to make a service available publicly, you need to point the service’s public DNS record to your router’s IP address and forward a port from the router to your home server. You also need to think about how to access the service when you are on the internal network. The easiest solution would be to do nothing and use the public DNS record internally, too. In that case, however, your internal traffic would flow to your router (because of the public IP) and back via port forwarding. Not too elegant. Alternatively, you could set up an internal DNS server (or use your router’s). On the internal DNS server, you’d configure an A record with the internal IP address of your service. On the public DNS server, you configure an A record (for the same name!) with the public address of your service.
I did setup wireguard for mobile connection to access home when needed but for example I wanted gotify pushes and forgot all the time to connect to wireguard.
The solution for home was the split DNS (https://virtualize.link/split-dns/)
And I setup my domains like this service1,2,3,etc.domain.com (for all services) and pointed the one private to A 192.168.x.x and those public (plex, OCIS, outline, immich – these 3 with oidc in authelia) and some headers of gotify to CNAME – to my personal ISP assigned DDNS.
Works brilliantly.
One issue Im having is with the desktop app in windows of owncloud, it asks for re-verification every time I quit the app or restart pc.
Error is: Requested audience ‘xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69’ has not been whitelisted by the OAuth 2.0 Client
Need some more debugging.
Thanks again, looking forward to seeing your next parts of this amazing series
Fixed it: Added this to the desktop client and now it automatically logins:
consent_mode: pre-configured
pre_configured_consent_duration: 2M
audience: [xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69]
I recently discovered Netbird, an Open Source VPN Solution, which from what I’ve seen so far looks great.
Hey there! Did you test this with the android app? After adding Authentik in front of OCIS the android app gives me “malformed server configuration.” Authentik works great for the browser….really sucks I can’t get android live with it.
I’m not sure I tested the Android app with authentik because I’m using the alternative setup with Authelia (which works with the Android app).
Thank you :) I switched to the Authelia Setup and I couldn’t be happier. Very cool.
Hey!
I am having an issue with Cross-Origin (although I use traefik) with Authentik + Traefik + Ocis:
“`[Error] Origin https://ocis.domain.com is not allowed by Access-Control-Allow-Origin. Status code: 200
[Error] Fetch API cannot load https://auth.domain.com/application/o/owncloud-web-client/.well-known/openid-configuration due to access control checks.
[Error] Failed to load resource: Origin https://ocis.domain.com is not allowed by Access-Control-Allow-Origin. Status code: 200 (openid-configuration, line 0)
[Error] [JsonService] getJson: – “Network Error”
error (vendor-5db2b8b4.mjs:2:68952)
(anonymous function) (vendor-5db2b8b4.mjs:2:76653)
asyncFunctionResume
(anonymous function)
promiseReactionJobWithoutPromise
promiseReactionJob
[Error] Unhandled Promise Rejection: TypeError: Load failed
(anonymous function) (vendor-5db2b8b4.mjs:2:113317)
asyncFunctionResume
(anonymous function)
promiseReactionJobWithoutPromise
promiseReactionJob
“`
I am having a problem accessing ownCloud web client after setting it up with authentik. After logging in with my credentials in authentik I am redirected to the ownCloud callback url. However, ownCloud redirects me directly to authentik which already is authenticated and therefore redirects me back to ownCloud. This results in an infinite loop.
Do you have any idea what could cause this?
Hi Christopher. I had the same issue with Authenik and ownCloud ocis (the loop). The loop is related to a problem with the certificate used in authenik. I switched to a letsencrypt certificate and the loop was removed at once.
also paste the
identity_providers:
oidc:
above the clients part
Thanks, I added the two missing lines to Authelia’s configuration file.
If someone else has issues with OwnCloud (ocis) together with Authelia and Nginx Proxy Manager and iOS (or macOS):
https://github.com/owncloud/ios-app/issues/1219
https://github.com/authelia/authelia/issues/5566#issuecomment-1594590065
(workes fine now)
Did you do any changes besides the Nginx Proxy Manager addition? I can’t seem to log into either the app, and the web version also has issues redirecting after the oidc callback.
The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. Used unknown value ‘[select_account consent]’ for prompt parameter&state=xxxxx
If anybody is trying to get this to work with traefik and authelia, please apply the following middlewares to your owncloud ocis and authelia routers. Tested with desktop and android app.
middlewares:
drop-prompt-parameter:
redirectRegex:
regex: “^(.*)&prompt=select_account%20consent(.*)”
replacement: “${1}${2}”
owncloud-cors-headers:
headers:
accessControlAllowCredentials: true
accessControlExposeHeaders: “*”
accessControlAllowHeaders: “*”
accessControlAllowMethods: “*”
accessControlAllowOriginList:
– https://owncloud.{{env “DOMAINNAME”}} # replace with your owncloud url
– https://authelia.{{env “DOMAINNAME”}} # replace with your authelia url
accessControlMaxAge: “3600”
addVaryHeader: true
I’ve pasted the middlewares in a gist for better copi- and readability:
https://gist.github.com/maxbrueckl/bbe8e94324fcc7b2bf452680551b17a6
Is it possible to post a tutorial with Traefik as proxy instead of Caddy? I’ve got “Please wait, you are being redirected.” Bit it wont work. Authentik is working.
Any help
Thanks for this – I’m so close! I’m getting this though on ownCloud after being redirected to Authelia and back to OCIS:
Not logged in
This could be because of a routine safety log out, or because your account is either inactive or not yet authorized for use. Please try logging in after a while or seek help from your Administrator.
In the logs I’m getting this:
ocis-server | 2023-09-01T10:01:06Z ERR failed to authenticate the request error=”failed to verify access token: 403 Forbidden: \r\n403 Forbidden\r\n\r\n403 Forbidden\r\nnginx\r\n\r\n\r\n” authenticator=oidc line=github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/oidc_auth.go:165 path=/ocs/v1.php/cloud/user service=proxy
Any clues? I have a user created with the same email address in OCIS and Admin rights. Authelia is working beautifully with 2FA etc. Can’t figure it out!
I had commented out PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD – however adding it back still gives an error:
ocis-server | 2023-09-01T10:48:31Z ERR failed to authenticate the request error=”failed to get userinfo: 403 Forbidden: \r\n403 Forbidden\r\n\r\n403 Forbidden\r\nnginx\r\n\r\n\r\n” authenticator=oidc line=github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/oidc_auth.go:165 path=/ocs/v1.php/cloud/user service=proxy
Thank you for the great article! The
PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none
setup helped me a lot.With regard to the Authelia CORS part, it can also be configured at the oidc section of Authelia’s configuration file. In this way CORS is only applied to OIDC endpoints instead of all APIs.
So will this match the usernames created in ocis against authelia? If I create exampleuser1 in Ocis and have the same user created in owncloud .. or is this only compatible with a single user in ocis?
The setup described in this article works with multiple users, of course.
Hey, and thanks for the reply.
I followed this guide to the point and and it gets stuck on the redirecting page when it’s supposed to be logged in.
Do you know if it’s still up2date?
I run the latest caddy, ocis, and have setup authelia with ldap.. everything works. But this I just cant seem to get to work.
My struggle is i can’t get OCIS running even on the lan ip. 192.168.X.X:9200
It will either show a blue screen with a logo, or give me error 400, and same if i use my reverse proxy with https domain.
Im using the same exact settings as you do down to “Start the Container”
I will get the user/pass if i first run: “docker run –rm -it –mount type=bind,source=$PWD/config,target=/etc/ocis owncloud/ocis init”
then docker-compose up, but never manage to login, can you login at that stage?
To my understanding OCIS has some internal OpenID if none is set.
Thank you for the informative guide!
I found a solution to the owncloud client forcing reauthentication each time the access_token expires. It is failing to use it’s refresh tokens as authelia is saying the audience was not whitelisted.
Also – technically an installed native client with a hardcoded client ID (such as owncloud) is a “public” client as per RC8252.4 when it is not using DCR – which is still unsupported in authelia.
In the clients: section for the ownCloud desktop client, do the following in authelia’s configuration.yaml, client config section for the owncloud desktop client:
– set public: true
– comment out the secret (as it is not used for public clients) – this has the added benefit of forcing PKCE with authelia’s defaults.
– add an audience claim with the ownCloud as follows:
audience: [‘xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69’]
I’m not sure if this is due to an ownCloud bug, or an Authelia one – ownCloud is not specifying an audience when it attempts to renew, and Authelia is stating that the requested audience is not whitelisted. Wherever the bug lies – this appears to workaround it without needing to set the access_token_lifespan to a very long period.
Excellent guide!! My only problem right now is that the web client keep logging out and we have to log in all the time. Can’t find out how to force the web client to stay logged
Hello,
Great job, well done! I conducted some tests on my Proxmox server and successfully ran OCIS on an LXC Alpine container in “https//localip:9200” mode. I’m using a Cloudflare tunnel where I configured in the application section of the Cloudflare tunnel ocis.mydomaine.com => https://localip:9200, but I still encounter a “host error” when trying to connect.
I use the same method for other apps like Jellyfin, Portainer, etc. Do you have any ideas? When I searched the web, I couldn’t find any documentation.
Many thanks,
Fred
Hello I progress, now the web connection is ok but no connection via desktop and ios… If you can share your configuration. Thanks
Hello,
I’m using NPM and Authentik, but every time when I’m trying to login to the Desktop Client I’m receiving an Error 403 in the browser from my Authentik.
Has anyone encountered the same issue?
If you are using Authentik 2024.2 they implemented the following change:
– Required offline_access scope for Refresh tokens
Unsure how to configure owncloud to require the offline_access scope.
Go to Applications > Providers > oCIS Provider (that requires the offline_access scope) > edit > Advanced Protocolsettings > in scopes enable “authentik default OAuth Mapping: OpenID ‘offline_access'”.
This fixed it for me
Same issue here, having OCIS + NPM + Authentik 2024.2
Having Error 403 when trying to log in with Desktop Client.
I enabled authentik default OAuth Mapping: OpenID ‘offline_access’ to all my Owncloud Providers. And it is still showing the same error.
Thanks for the help
Anyone have a working advanced config to rewrite the URL for NGINX Proxy Manger i have it working but getting stuck on logging in please wait because for the life of me cant figure out how to rewrite the url for nginx any help welcome.
Thank you for your work mate, very nice and easy configuration.