# Aplicações do Authentik
Modelos de aplicação do Authentik
# Authentik com Nextcloud
Link: [https://integrations.goauthentik.io/chat-communication-collaboration/nextcloud/](https://integrations.goauthentik.io/chat-communication-collaboration/nextcloud/)
O que significa o texto abaixo referente ao Nextcloud e o Authentik: aviso Se você precisa de criptografia do lado do servidor, deve usar LDAP. OpenID e SAML causarão perda irrevogável de dados. A criptografia do lado do servidor Nextcloud requer acesso à senha em texto claro do usuário, à qual o Nextcloud só tem acesso quando usa LDAP porque o usuário insere sua senha diretamente no Nextcloud.
Esse aviso é **muito importante** — ele fala de uma limitação séria entre o Nextcloud e provedores de identidade como o Authentik.
Vamos traduzir e explicar de forma clara 👇
---
#### 🧠 💡 Ideia central
O problema é a **criptografia do lado do servidor (Server-Side Encryption)** do Nextcloud.
👉 Esse tipo de criptografia **precisa da senha do usuário em texto claro**.
---
#### 🔐 O que o aviso quer dizer
#### ✔️ Com LDAP (funciona)
Quando você usa LDAP:
- O usuário digita a senha **direto no Nextcloud**
- O Nextcloud recebe a senha em texto claro
- Ele usa essa senha para:
- gerar chaves
- descriptografar arquivos
👉 Exemplo:
- LDAP ou Active Directory
---
#### ❌ Com OpenID / SAML (problema)
Quando você usa:
- OpenID Connect (OIDC)
- SAML
👉 O que acontece:
- O login é redirecionado para o Authentik
- O Nextcloud **NUNCA vê a senha**
- Ele só recebe um **token de autenticação**
---
#### 💣 Consequência grave
Sem a senha:
- o Nextcloud **não consegue descriptografar os dados**
- arquivos podem ficar inacessíveis
👉 Daí o aviso:
> **“perda irrevogável de dados”**
Ou seja:
- você pode perder acesso aos arquivos criptografados
- mesmo sendo o administrador
---
#### 📊 Resumo simples
Método
Nextcloud vê a senha?
Criptografia funciona?
LDAP
✅ Sim
✅ Sim
SAML
❌ Não
❌ Não
OpenID (Authentik)
❌ Não
❌ Não
---
#### ⚠️ Importante (muita gente ignora isso)
Esse problema não é bug:
👉 é **limitação de design** do Nextcloud
---
#### 🚀 O que você deve fazer
#### ✔️ Opção 1 — Usar Authentik + Nextcloud (sem criptografia)
- Pode usar OIDC/SAML normalmente
- **NÃO ativar Server-Side Encryption**
👉 recomendado na maioria dos casos
---
#### ✔️ Opção 2 — Usar criptografia
- Usar LDAP/AD direto no Nextcloud
- Não usar SSO via OIDC/SAML
---
#### ✔️ Opção 3 — Alternativa moderna
- Não usar criptografia do Nextcloud
- Usar:
- criptografia no disco (LUKS, ZFS, etc.)
- criptografia no storage
👉 mais seguro e sem esse problema
---
#### 🧠 Insight importante
A criptografia do Nextcloud:
- é considerada **limitada**
- não é “zero-knowledge”
- depende da senha do usuário
---
#### 🔚 Conclusão
O aviso basicamente diz:
👉 **Se você usar Authentik com OpenID ou SAML, NÃO ative a criptografia do Nextcloud, ou você pode perder seus dados.**
---
Se quiser, posso te orientar na melhor arquitetura:
- Authentik + Nextcloud seguro ✅
- com SSO funcionando
- sem risco de perda de dados
Só me diz como você pretende usar 👍
Authentik com Nextcloud seguro
Perfeito — dá pra montar uma integração **segura e moderna** entre Authentik e Nextcloud sem cair naquele problema da criptografia.
Vou te passar o **modelo recomendado hoje (produção)** 👇
- Provisionamento automático de usuários via Authentik
- Grupos → roles no Nextcloud
- Logout único (Single Logout)
---
#### 📊 Resumo final
✔️ Authentik + OIDC = melhor UX
✔️ Sem criptografia interna do Nextcloud
✔️ Segurança via infra (disco + rede)
✔️ Escalável e moderno
# Authentik com SAML - Youtube
Link: [https://www.youtube.com/watch?v=BHtL3Gvn31o](https://www.youtube.com/watch?v=BHtL3Gvn31o)
# Authentik LDAP Provider
**LDAP Provider:** Link: [https://docs.goauthentik.io/add-secure-apps/providers/ldap/](https://docs.goauthentik.io/add-secure-apps/providers/ldap/)
**Create LDAP Provider:** Link: [https://docs.goauthentik.io/add-secure-apps/providers/ldap/create-ldap-provider/](https://docs.goauthentik.io/add-secure-apps/providers/ldap/create-ldap-provider/)
**Outposts:** Link: [https://docs.goauthentik.io/add-secure-apps/outposts/](https://docs.goauthentik.io/add-secure-apps/outposts/)
**Outposts Compose:** link: [https://docs.goauthentik.io/add-secure-apps/outposts/](https://docs.goauthentik.io/add-secure-apps/outposts/)
### Create an LDAP provider
Creating an authentik LDAP provider requires the following steps:
1. [Create an LDAP authentication flow *(optional)*](https://docs.goauthentik.io/add-secure-apps/providers/ldap/create-ldap-provider/#create-an-ldap-authentication-flow-optional)
2. [Create an LDAP application and provider](https://docs.goauthentik.io/add-secure-apps/providers/ldap/create-ldap-provider/#create-an-ldap-application-and-provider)
3. [Create a service account and assign the LDAP search permission](https://docs.goauthentik.io/add-secure-apps/providers/ldap/create-ldap-provider/#create-a-service-account)
4. [Create an LDAP Outpost](https://docs.goauthentik.io/add-secure-apps/providers/ldap/create-ldap-provider/#create-an-ldap-outpost)
### Create an LDAP authentication flow *(optional)*
The `default-authentication-flow` validates MFA by default. Duo, TOTP, and static authenticators are supported by the LDAP provider. WebAuthn and SMS are not supported.
If you plan to use only dedicated service accounts to bind to LDAP, or only use LDAP supported MFA authenticators, then you can use the default authentication flow and skip this section and continue with the [Create an LDAP application and provider](https://docs.goauthentik.io/add-secure-apps/providers/ldap/create-ldap-provider/#create-an-ldap-application-and-provider) section.
Refer to [Code-Based MFA support](https://docs.goauthentik.io/add-secure-apps/providers/ldap/#code-based-mfa-support) for more information on LDAP and MFA.
### Create custom stages
You'll need to create the stages that make up the flow.
1. Log in to authentik as an administrator and open the authentik Admin interface.
2. Navigate to **Flows and Stages** > **Stages**, and click **Create**.
#### Password Stage
First, you'll need to create a Password Stage.
3. Select **Password Stage** as the stage type, click **Next**, and set the following required configurations:
- Provide a **Name** for the stage (e.g. `ldap-authentication-password-stage`).
- For **Backends**, leave the default settings.
4. Click **Finish**
#### Identification Stage
Next, you'll need to create an Identification Stage.
5. On the **Stages** page, click **Create**.
6. Select **Identification Stage** as the stage type, click **Next**, and set the following required configurations:
- Provide a **Name** for the stage (e.g. `ldap-identification-stage`).
- For **User fields**, select `Username` and `Email` (and UPN if it is relevant to your setup).
- Set **Password stage** to the Password Stage created in the previous section (e.g. `ldap-authentication-password-stage`)
7. Click **Finish**
#### User Login Stage
Finally, you'll need to create a User Login Stage.
8. On the **Stages** page, click **Create**.
9. Select **User Login Stage** as the stage type, click **Next**, and set the following required configurations:
- Provide a **Name** for the stage (e.g. `ldap-authentication-login-stage`).
10. Click **Finish**
### Create an LDAP authentication flow
Now you'll need to create the LDAP authentication flow and bind the previously created stages.
1. Log in to authentik as an administrator and open the authentik Admin interface.
2. Navigate to **Flows and Stages** > **Flows**, click **Create**, and set the following required configurations:
- Provide a **Name**, **Title** and **Slug** for the flow (e.g. `ldap-authentication-flow`).
- Set **Designation** to `Authentication`.
3. Click **Create**.
4. Click the name of the newly created flow, open the **Stage Bindings** tab, and click **Bind existing stage**.
5. Select the previously created LDAP Identification Stage (e.g.`ldap-identification-stage`), set the order to `10`, and click **Create**.
6. Click **Bind existing stage**.
7. Select the previously created LDAP User Login Stage (e.g.`ldap-authentication-login-stage`), set the order to `30`, and click **Create**.
## Create an LDAP application and provider
The LDAP application and provider can now be created.
1. Log in to authentik as an administrator and open the authentik Admin interface.
2. Navigate to **Applications** > **Applications**, click **Create with Provider** to create an application and provider pair.
3. On the **New application** page, define the application details, and then click **Next**.
4. Select **LDAP Provider** as the **Provider Type**, and then click **Next**.
5. On the **Configure LDAP Provider** page, provide the configuration settings and then click **Submit** to create both the application and the provider.
**INFO**
If you followed the optional [Create an LDAP authentication flow](https://docs.goauthentik.io/add-secure-apps/providers/ldap/create-ldap-provider/#create-an-ldap-authentication-flow-optional) section, ensure that you set **Bind flow** to newly created authentication flow (e.g. `ldap-authentication-flow`).
## Create a service account
Create a service account to bind to LDAP with.
1. Log in to authentik as an administrator and open the authentik Admin interface.
2. Navigate to **Directory** > **Users** and click **New User**.
3. Provide a name for the service account (e.g. `ldapservice`) and click **Create**.
4. Click the name of the newly created service account.
5. Under **Recovery**, click **Set password**, provide a secure password for the account, and click **Update password**.
**Default DN of service account**
The default DN of this user will be `cn=ldapservice,ou=users,dc=ldap,dc=goauthentik,dc=io`
### Assign the LDAP search permission to the service account
The service account needs permissions to search the LDAP directory. You'll need to create a role with the permission and assign the service account to that role.
1. Log in to authentik as an administrator and open the authentik Admin interface.
2. Navigate to **Directory** > **Roles** and click **Create**.
3. Provide a name for the role (e.g. `LDAP search`) and then click **Create**.
4. Click on the newly created role and open the **Users** tab.
5. Click **Add existing user**, select the service account, and then click **Assign**.
6. Navigate to **Applications** > **Providers**.
7. Click on the name of the newly created LDAP provider and open the **Permissions** tab.
8. Click **Assign Object Permissions**.
9. Select the role that you created (e.g. `LDAP search`), enable the **Search full LDAP directory** permission, and then click **Assign**.
## Create an LDAP Outpost
The LDAP provider requires the deployment of an LDAP [Outpost](https://docs.goauthentik.io/add-secure-apps/outposts/).
1. Log in to authentik as an administrator and open the authentik Admin interface.
2. Navigate to **Applications** > **Outposts**, click **Create** and set the following required configurations:
- Provide a **Name** for the outpost (e.g. `LDAP Outpost').
- Set the **Type** as `LDAP`.
- Set **Integration** to match your deployment method or manually deploy an outpost via [Docker-Compose](https://docs.goauthentik.io/add-secure-apps/outposts/manual-deploy-docker-compose/) or [Kubernetes](https://docs.goauthentik.io/add-secure-apps/outposts/manual-deploy-kubernetes/). For more information, refer to the [Outpost documentation](https://docs.goauthentik.io/add-secure-apps/outposts/).
- Under **Applications**, select the LDAP application created in the previous section.
- Under **Advanced settings**, set the required outpost configurations. For more information, refer to [Outpost Configuration](https://docs.goauthentik.io/add-secure-apps/outposts/#configuration)
3. Click **Create**.
**Multiple LDAP providers**
The LDAP Outpost selects different providers based on their Base DN. Adding multiple providers with the same Base DN will result in inconsistent access.
## Configuration verification
You can test the LDAP provider by using the `ldapsearch` tool on Linux and macOS, or the `dsquery` tool on Windows.
- ldapsearch
- dsquery
To install the `ldapsearch` tool, use one of the following commands:
```shell
sudo apt-get install ldap-utils -y # Debian-based systems
sudo yum install openldap-clients -y # CentOS-based systems
brew install openldap #macOS based systems (requires Homebrew to be installed)
```
To search the LDAP directory using the previously created `ldapservice` service account, use the following command:
```shell
ldapsearch \
-x \
-H ldap://:389 \
-D 'cn=ldapservice,ou=users,DC=ldap,DC=goauthentik,DC=io' \
-w '' \
-b 'DC=ldap,DC=goauthentik,DC=io' \
'(objectClass=user)'
```
This example query will return all users and log the first successful attempt in an event in **Events** > **Logs**. Subsequent successful logins from the same user are not logged by default, as they are cached in the outpost. For more details see [Bind modes](https://docs.goauthentik.io/add-secure-apps/providers/ldap/#bind-modes).
**LDAPS**
In production it is recommended to use LDAPS, which requires `ldaps://` as the protocol, and port number `636` rather than `389`. See [LDAPS](https://docs.goauthentik.io/add-secure-apps/providers/ldap/#ldaps-via-ssl-or-starttls) for more information.
# Complete guide to Nextcloud OIDC authentication with Authentik
Link: [https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/)
After [migrating my user accounts from OpenLDAP to Authentik](https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/), I still need to switch the Nextcloud authentication to a modern protocol, instead of relying on [Authentik’s built-in LDAP outpost](https://goauthentik.io/docs/providers/ldap) (which emulates an LDAP server). In [a previous post a couple of months ago](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-saml-authentication-with-authentik/) I explored how to connect [the Nextcloud file-hosting suite](https://github.com/nextcloud/server) to [the Authentik identity provider](https://github.com/goauthentik/authentik) with SAML. I managed to get the setup working, but in the end I was neither satisfied with the solution nor convinced by its long-term maintenance. For reference, at this point I have been running Nextcloud with the [LDAP user backend](https://docs.nextcloud.com/server/stable/admin_manual/configuration_user/user_auth_ldap.html) for six years, and it want any solution that is going to replace this setup to last at least that long, too.
Hence, in this post I am going through the setup of Nextcloud with OIDC to connect to Authentik. Specifically, I will go over the following aspects:
- [What is OIDC?](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#oidc)
- [Which options are available for using OIDC with Nextcloud?](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#options)
- [Authentik setup](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#authentik)
- [Nextcloud setup](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#nextcloud)
- [Advanced login and logout behavior](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#auto-login-redirect)
- [Conclusion](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#conclusion)
### [\# ](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#oidc) OIDC
[*OpenID Connect*](https://openid.net/connect/) (or *OIDC* for short) is an identity layer based on the more extensive [OAuth2 authorization framework](https://oauth.net/2/). Whereas OAuth2 can handle many different authentication and authorization functions, OIDC is a trimmed down version that focuses on one aspect: user identification. Applications can use OIDC to authenticate a user (i.e. verify the identity of a user) and retrieve metadata about the user (name, email address etc.), but at the same time can use their own internal authorization mechanisms (i.e. what the user has access to). [JSON Web Tokens](https://jwt.io/) (*JWT*) are most commonly used to exchange *authentic* (meaning: *signed* and *verified*) information about a user.
In an OIDC authentication flow, there are generally three parties:
- the **subject** (the end user)
- the **identity provider** or **token issuer** (in my case this will be Authentik)
- the **relying party** (the secure application, here: Nextcloud)
If you want to learn more about it, I recommend looking into [this excellent quickstart guide to OIDC](https://frontegg.com/guides/oidc-authentication).
OIDC is seeing widespread adoption these days by many different types of applications. In fact, OIDC is what most of the popular “Social Login” methods are based on (e.g. *“Login with Google/Apple/…"*).
### [\# ](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#options) Options
After establishing that OIDC looks like a solid and future proof authentication protocol, let’s take a look at the options we have for integrating it with Nextcloud.
There are no less than three plugins for Nextcloud that provide some sort of OIDC integration:
- [Social Login](https://github.com/zorn-v/nextcloud-social-login): focuses mainly on Google/Amazon/… identity providers, but since all of these are based OIDC internally, also custom providers can be used. The plugin is actively maintained, but unfortunately just by a single developer.
- [Nextcloud OIDC Login](https://github.com/pulsejet/nextcloud-oidc-login): a polished and well-documented plugin that [unfortunately is in maintenance-only mode](https://github.com/pulsejet/nextcloud-oidc-login/issues/182) due to lack of developers.
- [user\_oidc](https://github.com/nextcloud/user_oidc): least polished, but located under the `github.com/nextcloud` organization and seemingly maintained by Nextcloud developers.
### [\# ](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#user_oidc) user\_oidc
Out of the three options presented above, I decided to give [user\_oidc](https://apps.nextcloud.com/apps/user_oidc) a try, simply because I’m hoping that it’s used by many enterprises and will therefore be supported for a long time by the Nextcloud developers (*we’ll see how this bet turns out in a couple of years - fingers crossed*). If it wasn’t for the state of maintenance, I would have opted for [Nextcloud OIDC Login](https://github.com/pulsejet/nextcloud-oidc-login).
Before we get to deep into the technical details, I should mention that `user_oidc` currently does not support group provisioning for users - if this is something that is required for your setup, you should check out one of the alternatives. However, [work is in progress](https://github.com/nextcloud/user_oidc/pull/502) to address this shortcoming.
Another (slightly) negative aspect about `user_oidc` is the confusing configuration: as the following sections will show, some settings are configured via the Web UI, some via the `occ` CLI, others via Nextcloud’s `config.php`. In the end it works, but this aspect is handled much more consistently in the other plugins mentioned before.
In the next sections, we’ll first look at the configuration required on the Authentik side and then on the Nextcloud side.
### [\# ](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#authentik) Authentik
Since OIDC describes a trust relationship between the *identity provider* (Authentik) and the *relying party* (Nextcloud), we need to let Authentik know about the new application it should handle authentication for. To do this, log into your Authentik instance as an administrator and switch to the “Admin interface” (the button in the top-right corner). Go to the `Applications` menu and click on `Create`:
Authentik ‘Application’ Creation Menu
[](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/authentik-create-application.png)Click on the `Create Provider` button and fill the menu (shown below) with following settings:
- *Type*: Oauth2/OIDC Provider
- *Authorization flow*: implicit consent (otherwise your users need to confirm each login explicitly!)
- *Client type*: Confidential
- *Client ID*: (leave auto-generated value as-is)
- => copy this value for later use
- *Client Secret*: **\[IMPORTANT\]** trim the auto-generated value to 64 characters - there is currently [a bug in user\_oidc that prevents longer client secrets](https://github.com/nextcloud/user_oidc/issues/405). A client secret of 64 chars is still sufficient from a security perspective.
- => copy this value for later use
- *Redirect URIs*: `https:///apps/user_oidc/code`
- *Advanced protocol settings* > *Subject mode*: based on the username
- this setting should be used to ensure Nextcloud’s federated cloud ID will have a human-readable value, like `username@nextcloud-hostname.com`.
- Click on *Finish*
Authentik ‘Provider’ Creation Menu
[](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/authentik-create-provider.png)Back in the **application creation menu**, click on `Create`.
Now switch to the “Providers” section, click on the newly created provider and copy the `OpenID Configuration URL` - it should look like `https:///application/o/nextcloud/.well-known/openid-configuration`.
### [\# ](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#nextcloud) Nextcloud
Now we can switch to the Nextcloud instance. To get started, simply log in to your Nextcloud instance as an administrator, navigate to the “Apps” section and search for `OpenID Connect user backend`, then click on `Download and enable`. I’m using Nextcloud version 24 and `user_oidc` 1.2.1 at the time of writing.
Open the Admin Settings of Nextcloud (top-right behind the profile picture) and locate the `OpenID Connect` section (bottom-left corner). Click on the small `+` button next to “Registered Providers” and fill the following fields with the data obtained on the Authentik admin interface:
- *Identifier*: `Authentik` (you may choose any value here, but it will be shown to your users in the form of a `Login with ` button)
- *Client ID*: (value copied from Authentik)
- *Client Secret*: (value copied from Authentik)
- *Discovery endpoint*: (OpenID Configuration URL copied from Authentik, should end with `.well-known/openid-configuration`)
- *Attribute mappings*: unless you have a non-standard identity provider setup (with custom fields / attributes), the placeholder values should work and can be left as-is.
- Uncheck `Use unique user ID` - when this option is enabled, Nextcloud will use the hash (checksum) of the provider identifier + user identifier as the internal user ID. Unfortunately, this creates rather ugly and long [federated cloud IDs](https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/federated_cloud_sharing_configuration.html). Unless you are using multiple OIDC providers or multiple Nextcloud user backends, I believe it’s safe to disable (untick) this option, since there can be no name collision within a single OIDC provider.
- Click on *Submit*
Nextcloud OIDC provider configuration
[](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/nextcloud-register-oidc-provider.png)Note that the same setup as described above can be achieved on the CLI with the following commands. This may be useful in case you want to automate the setup and avoid going through the manual steps in the web interface.
```
1
2
3
4
5
6
7
8
9
10
11
12
```
```sh
# assuming that your are in the root nextcloud folder and running this as the `www-data` user
php ./occ app:install user_oidc
php ./occ user_oidc:provider "Authentik" \
--clientid="" \
--clientsecret="" \
--discoveryuri="" \
--unique-uid=0
# for help, refer to:
php ./occ user_oidc:provider -h
php ./occ user_oidc:provider:delete -h
php ./occ app -h
```
A long federated cloud ID caused by the ‘Use unique user ID’ setting
[](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/nextcloud-hashed-federated-id.png)### [\# ](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#first-try) First try
Since all the configuration settings are in place now, it’s time for a first test. Open a new browser session / private window and navigate to your Nextcloud instance.
The short video shows that I am not able to use my credentials to log in as a regular (local) user to Nextcloud (in the same way as I could previously with the LDAP backend). That is actually desirable, because this way the authentication provider (in this case: Authentik) can take care of the entire authentication flow, including any possible password, 2-FA or MFA prompts. In addition, if the user is already logged in, there is no need to re-enter the credentials - hence this is proper *Single Sign-On* (not just *Single-password*).
When clicking on the `Login with Authentik` button, I get redirected to Authentik, where I can log in. Finally, Authentik redirects me to Nextcloud (including an authentication token in the URL) and I get automatically logged in to Nextcloud. If the `Redirect URIs` setting was not configured properly, an error will occur during this last step.
### [\# ](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#auto-login--redirect) Auto-login / redirect
At this point the setup is working – *yay!* – but still a bit confusing for users. How are the users supposed to know that they need to click on `Login with X` instead of using the built-in username and password fields (especially because these seem much more inviting)?
There are two ways this can be addressed:
- 1: disabling the built-in login form by setting `'hide_login_form' => false` in the `config.php` (see [Nextcloud documentation](https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/config_sample_php_parameters.html#default-parameters)). This will show a slightly ugly warning message on the login page, but at least it’s clear for users that they need to click on the `Login with X` button. The login form is just *hidden*, because it can still be accessed at `https:///login?direct=1` - this is required when you want to access Nextcloud with your local admin account.
Nextcloud with disabled login form
[](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/nextcloud-disable-login-form.png)- 2: Making OIDC the default login method. This only works if you have *just a single* OIDC provider configured and no other login methods in Nextcloud (no SAML, external users etc.). With this option, any unauthenticated request to the Nextcloud instance immediately gets redirect to the authentication provider (with an HTTP Status Code `302 Found` and an appropriate `Location` header). Like in the previous case, admins can still use the regular login by appending `?direct=1` to the login URL. At the time of writing, this setting can only be enabled from the command line:
For now, I’m sticking with the `hide_login_form` method, even though it requires an additional click from the user, because it’s less “automagic”. I might switch to the automatic redirect in the future once I’m more comfortable with the setup.
### [\# ](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#advanced-logout) Advanced logout
The `user_oidc` plugin provides two options for customizing how the logout is handled.
The first one is *single logout*: if this option is enabled (which it is by default), the user is also logged out of the entire SSO session (instead of *just* Nextcloud). However, Authentik will still ask the user if they want to log out of their SSO session, therefore we can [leave this setting as-is](https://github.com/nextcloud/user_oidc#single-logout).
Single logout is enabled, but Authentik still asks if the user want to end all SSO sessions
[](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/single-signout.png)The second one is *backchannel logout*: if a user signs out of their SSO session at the identity provider level (instead of just a single application), the identity provider can notify all other applications that the user should be logged out now (so they can invalidate their sessions, too). Unfortunately, this feature is [currently not supported in Authentik](https://github.com/goauthentik/authentik/issues/2023) (as far as I can tell), but you can use it if you have a different identity provider (e.g. Keycloak). Note that this feature requires that the identity provider can make a direct POST request to the applications (e.g. Nextcloud instance), which may not always be the case depending on your firewall settings or network topology.
Learn more about [OIDC Single Logout](https://curity.io/resources/learn/openid-connect-logout/).
### [\# ](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/#conclusion) Conclusion
While this blog post turned out much longer than I initially expected, I would still say that overall this setup was much simpler than the [Nextcloud SAML integration I wrote about previously](https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-saml-authentication-with-authentik/). Even though the documentation of the “official” OIDC app (official as-in provided by the core maintainers) is quite sparse, with a bit of experience in the OpenID Connect realm it is pretty straightforward. (The lack of official documentation is also the reason I made sure to describe all the details in this post.)
I’m relatively confident that this setup will be stable over the next couple of years and will put me in a good position to roll out 2FA in [my homelab](https://blog.cubieserver.de/tags/homelab/).
# Migrating users from LDAP to Authentik
Link: [https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/](https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/)
For several years (*the earliest timestamp I could find is from 2016*), I have been using [OpenLDAP](https://www.openldap.org/) (a.k.a [slapd](https://www.openldap.org/software/man.cgi?query=slapd)) as the source of truth for user accounts in my homelab. The initial setup was tricky – especially figuring out the “memberOf” overlay to get group memberships – but once I had it nailed down and [put it into Puppet manifests](https://git.cubieserver.de/Cubieserver/puppet-control/src/branch/master/site/profile/manifests/openldap.pp), it was rock solid. The setup is still rock solid, but definitely starts showing its age: friendly user-interfaces for self-service are rare (I’ve been using [LTB’s *Self Service Password*](https://github.com/ltb-project/self-service-password), but it only allows users to change their password, not email address etc.), and modern features like multi-factor authentication need to be re-implemented by each application, instead of being centrally managed by the authentication source.
Thus, in 2022 it was time to look for something new. There are lots of choices available in this space, but [Authentik](https://goauthentik.io/) in particular struck me as simple to set up and use. For this reason it seems that in recent months Authentik has become a bit of a “secret tip” in self-hosting circles.
Despite the small number of users of my homelab, I was reluctant to start from scratch with my authentication source. I was looking for a way to automatically import the user accounts from OpenLDAP into Authentik – and it turns out that Authentik makes this super easy, if you know what to look for. The following guide shows how to set up and use an *LDAP Source* in Authentik, and that it can simply be removed again without deleting the user accounts, thereby acting as an import functionality.
## [\# ](https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/#setup) Setup
My (old) setup consists of an OpenLDAP server (`slapd 2.4.47` on Debian 10 Buster) with TLS encryption (i.e. `ldaps` instead of StartTLS).
Authentik is version `2021.12.5` and installed with their official Helm chart `5.2.1`:
After adding the Helm repository , run `helm install authentik authentik/authentik` and then open `https://auth.example.com/if/flow/initial-setup/` to set a password for the admin user.
## [\# ](https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/#syncing-with-openldap) Syncing with OpenLDAP
After logging in as the admin user, you should be greeted with the following dashboard. Navigate to the “Directory” section in the left sidebar and choose “Federation & Social Login”. Then, click the blue “Create” button and select “LDAP Source”.
Authentik Dashboard Overview
[](https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/authentik-default-dashboard.png)Give your LDAP Source a human-friendly *name* and a unique identifier (*slug*). Then, scroll down to the *Connection settings* section.
Here is the full configuration I used. Below you will find detailed explanations for each field.
Authentik LDAP Source configuration
[](https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/ldap-source.png)For the *Server URI* you can either use `ldap://1.2.3.4` or `ldap://example.com` if your server is un-encrypted *OR* uses StartTLS (in this case tick the checkbox below), or `ldaps://example.com` if your [server uses regular TLS encryption](https://blog.cubieserver.de/2019/openldap-implementation-specific-error-80-when-adding-tls-certificate/). Optionally, you can specify a port if your server uses a non-default port (add `:386` for regular connections or `:686` for TLS-encrypted connections at the end).
If your server uses the encrypted LDAP protocol and does not use a publicly trusted (*self-signed*) TLS certificate, then you first need to import this certificate into Authentik and then select it in *TLS Verification Certificate*. Otherwise, you can leave this field empty.
Enter the *CN* and *Password* of a user account that can [bind to the LDAP server](https://ldap.com/the-ldap-bind-operation/).
Enter the *Base DN* for your LDAP directory – this can be used to only import part of your user tree.
Next, we configure the *LDAP Attribute Mapping* section. To do this correctly, you should first take a look at your LDAP schema to figure out which attributes are present for your users and groups.
If your are running OpenLDAP (like me), one excellent way to do this is simply dumping the entire LDAP database with [slapcat](https://manpages.debian.org/buster/slapd/slapd.8.en.html):
```
slapcat -b "$BASE_DN"
...
dn: cn=Git,ou=Groups,dc=cubieserver,dc=de
cn: Git
objectClass: groupOfNames
objectClass: top
owner: cn=admin,dc=cubieserver,dc=de
structuralObjectClass: groupOfNames
entryUUID: 55e6b8f6-7370-1035-8c1d-b5b0eb6b5c72
creatorsName: cn=admin,dc=cubieserver,dc=de
createTimestamp: 20160229203955Z
member: cn=Mr Cubie,ou=People,dc=cubieserver,dc=de
modifiersName: cn=admin,dc=cubieserver,dc=de
modifyTimestamp: 20170506200330Z
...
dn: cn=Mr Cubie,ou=People,dc=cubieserver,dc=de
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
uid: cubie
cn: Mr Cubie
structuralObjectClass: inetOrgPerson
entryUUID: f05f8080-7752-1035-8092-8fc71d8bef3a
creatorsName: cn=admin,dc=cubieserver,dc=de
createTimestamp: 20160305191934Z
mail: cubie@example.com
memberOf: cn=Git,ou=Groups,dc=cubieserver,dc=de
userPassword:: XXXXXXXXXXXXXXXXXXXXXXXXXXXFpHSmg=
modifiersName: cn=admin,dc=cubieserver,dc=de
modifyTimestamp: 20190723062033Z
```
In the example above I have included one user and one group of my schema. Among all the noise, there are a couple of important fields to note here:
- users have `cn`, `uid` and `mail` attributes ⟶ select these fields in *User Property Mappings*.
- groups have just the `cn` attribute ⟶ select this field in *Group Property Mappings*.
- groups have `objectClass: groupOfNames` ⟶ use *Group object filter* `(objectClass=groupOfNames)`.
- users have `objectClass: posixAccount` ⟶ use *User object filter* `(objectClass=posixAccount)`.
- group membership is indicated by the `member` attribute ⟶ use *Group membership field* `member`.
- users are uniquely identified by the `uid` attribute, but groups don’t have that. However, both have the `cn` (*Common Name*) attribute ⟶ use as the *Object uniqueness field*.
Finally, after you filled in all those fields, click the blue *Create* button at the bottom.
Choose the newly created authentication source and click the blue *Run Sync* button. Depending on the size of your LDAP database, this might take a while (in my case it’s pretty insignificant). Authentik will helpfully display the number of synced users, groups and group memberships. If there are any errors, it will also report them here. In that case, you need to go back to edit your LDAP source and fiddle with the attributes and mappings.
Successful LDAP Synchronization
[](https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/successful-sync.png)After a successful synchronization, you should see the users and groups by clicking on *Users* under *Directory* in the left sidebar. Here you should check that the user attributes have been imported fully and mapped correctly.
Users after import into Authentik
[](https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/imported-users.png)## [\# ](https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/#removing-the-sync) Removing the Sync
After you verified all users, groups and membership have been imported correctly, you can return to the *Federation & Social Login* and simply remove the LDAP Source created previously.
*Yes, that’s it.* I’m not sure if its a feature or a bug (because the first time I did this I was expecting all the LDAP users to be deleted from the database again, since the process is called *Synchronization* and not *Import* or *Migration*), but I’m really happy about this behavior. Now I can simply turn off my OpenLDAP server after 6 years of service – it has served me well and I hope Authentik will serve me just as long.