Authentik

Solução completa de autenticação e autorização de acessos.

Instalação e Configurações do Authentik


Instalação e Configurações do Authentik

Instalação Authentik em docker compose

Link: https://docs.goauthentik.io/install-config/install/docker-compose/

em 10/04/2026

Docker Compose installation

This installation method is for test setups and small-scale production setups.

Requirements

Video

View our video about installing authentik on Docker.

Download the Compose file

To download the latest compose.yml open your terminal, navigate to the directory of your choice, and then run the following command:

  • Linux
  • macOS
wget https://docs.goauthentik.io/compose.yml

Generate PostgreSQL password and secret key

If this is a fresh authentik installation, you need to generate a PostgreSQL password and a secret key. Use a secure password generator of your choice such as pwgen, or you can use openssl as below.

Run the following commands to generate a PostgreSQL password and secret key and write them to your .env file:

echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
INFO

Because of a PostgreSQL limitation, only passwords up to 99 chars are supported. See: https://www.postgresql.org/message-id/09512C4F-8CB9-4021-B455-EF4C4F0D55A0@amazon.com

To enable error reporting, run the following command:

echo "AUTHENTIK_ERROR_REPORTING__ENABLED=true" >> .env

For an explanation about what each service in the Docker Compose file does, see Architecture.

Configure custom ports

By default, authentik listens internally on port 9000 for HTTP and 9443 for HTTPS. To use different exposed ports such as 80 and 443, you can set the following variables in .env:

COMPOSE_PORT_HTTP=80
COMPOSE_PORT_HTTPS=443

See Configuration to change the internal ports. Be sure to run docker compose up -d to rebuild with the new port numbers.

Docker socket

By default, the authentik Docker Compose file mounts the Docker socket to the authentik worker container:

- /var/run/docker.sock:/var/run/docker.sock

This is used for automatic deployment and management of authentik Outposts.

Mounting the Docker socket to a container comes with some inherent security risks. To reduce these risks, you can utilize a Docker Socket Proxy as an additional layer of protection.

Alternatively, you can remove this mount and instead manually deploy and manage outposts.

Email configuration (optional but recommended)

It is also recommended to configure global email settings. These are used by authentik to notify administrators about alerts, configuration issues and new releases. They can also be used by Email stages to send verification/recovery emails.

For more information, refer to our Email configuration documentation.

Install and start authentik

WARNING

All internal operations use UTC. Times displayed in the UI are automatically localized for the user. Do not update or mount /etc/timezone or /etc/localtime in the authentik containers; it will cause problems with OAuth and SAML authentication, as seen this GitHub issue.

After you have downloaded the docker-compose.yml file, generated a password and a secret key, and optionally configured your global email, run these commands to retrieve and install the current version of authentik:

docker compose pull
docker compose up -d

The compose.yml file statically references the latest version available at the time of downloading the compose file. Each time you upgrade to a newer version of authentik, you download a new compose.yml file, which points to the latest available version. For more information, refer to the Upgrading section in the Release Notes.

Access authentik

To start the initial setup, navigate to http://<your server's IP or hostname>:9000/if/flow/initial-setup/.

Initial setup in browser

You will get a Not Found error if initial setup URL doesn't include the trailing forward slash /. Also verify that the authentik server, worker, and PostgreSQL database are running and healthy. Review additional tips in our troubleshooting docs.

There you are prompted to set a password for the akadmin user (the default user).

First steps in authentik

You are now ready to add your first application and its provider. Then you'll want to add a new user.

To view a typical workflow for adding applications and users, with helpful context and explanations for each step, refer to the First Steps tutorial.

📄️ First steps

Add an application and provider, then create a user.

Help us improve this content

We welcome your knowledge and expertise. If you see areas of the documentation that you can improve (fix a typo, correct a technical detail, add additional context, etc.) we would really appreciate your contribution.


Instalação e Configurações do Authentik

Integração do Nextcloud com Authentik OIDC

Link: https://integrations.goauthentik.io/chat-communication-collaboration/nextcloud/

Em 09/04/2026

What is Nextcloud

Nextcloud is a suite of client-server software for creating and using file hosting services. Nextcloud is free and open-source, which means that anyone is allowed to install and operate it on their own private server devices.

-- https://nextcloud.com/arning


WARNING
If you require server side encryption, you must use LDAP. OpenID and SAML will cause irrevocable data loss. Nextcloud server side encryption requires access to the user's cleartext password, which Nextcloud has access to only when using LDAP because the user enters their password directly into Nextcloud.aution

This setup only works when Nextcloud is running with HTTPS enabled. See here on how to configure this.nfo

If there’s an issue with the configuration, you can log in using the built-in authentication by
visiting http://nextcloud.company/login?direct=1.

Configuration methods

It is possible to configure Nextcloud to use OIDC, SAML, or LDAP for authentication. Below are the steps to configure each method.

  • OIDC
  • SAML
  • LDAP

OIDC

Preparation

The following placeholders are used in this guide:

  • nextcloud.company is the FQDN of the Nextcloud installation.
  • authentik.company is the FQDN of the authentik installation.
Info

This documentation lists only the settings that you need to change from their default values. Be aware that any changes other than those explicitly mentioned in this guide could cause issues accessing your application.

WARNING

If you require server side encryption, you must use LDAP. OpenID and SAML will cause irrevocable data loss.

Let's start by considering which user attributes need to be available in Nextcloud:

  • name
  • email
  • unique user ID
  • storage quota (optional)
  • groups (optional)

authentik already provides some default scopes with claims, such as:

  • email scope: includes email and email_verified
  • profile scope: includes name, given_name, preferred_username, nickname, groups
  • openid scope: a default required by the OpenID spec (contains no claims)

Create property mapping (optional)

If you do not need storage quota, group information, or to manage already existing users in Nextcloud, skip to the next section.
If you want to control user storage and designate Nextcloud administrators, you will need to create a property mapping.

  1. Log in to authentik as an administrator and open the authentik Admin interface.

  2. Navigate to Customization > Property mappings and click Create.

    • Select type: select Scope mapping.
    • Create Scope Mapping:

      • Name: Nextcloud Profile

      • Scope name: nextcloud

      • Expression:

        # Extract all groups the user is a member of
        groups = [group.name for group in user.groups.all()]

        # In Nextcloud, administrators must be members of a fixed group called "admin".

        # If a user is an admin in authentik, ensure that "admin" is appended to their group list.
        if user.is_superuser and "admin" not in groups:
            groups.append("admin")

        return {
            "name": request.user.name,
            "groups": groups,
            # Set a quota by using the "nextcloud_quota" property in the user's attributes
            "quota": user.group_attributes().get("nextcloud_quota", None),
            # To connect an existing Nextcloud user, set "nextcloud_user_id" to the Nextcloud username.
            "user_id": user.attributes.get("nextcloud_user_id", str(user.uuid)),
        }

  3. Click Finish.

Info

To set a quota, define the nextcloud_quota attribute for individual users or groups. For example, setting it to 1 GB will restrict the user to 1GB of storage. If not set, storage is unlimited.



To connect to an existing Nextcloud user, set the nextcloud_user_id attribute to match the Nextcloud username (found under the user's Display name in Nextcloud).

Create an application and provider in authentik

  1. Log in to authentik as an administrator and open the authentik Admin interface.

  2. Navigate to Applications > Applications and click Create with Provider to create an application and provider pair. (Alternatively you can first create a provider separately, then create the application and connect it with the provider.)

    • Application: provide a descriptive name, an optional group for the type of application, the policy engine mode, and optional UI settings.
    • Choose a Provider type: select OAuth2/OpenID Connect as the provider type.
    • Configure the Provider: provide a name (or accept the auto-provided name), the authorization flow to use for this provider, and the following required configurations.
      • Note the Client ID and slug values because they will be required later.
      • Set a Strict redirect URI to https://nextcloud.company/apps/user_oidc/code.
      • Select any available signing key.
      • Under Advanced protocol settings:
        • (optional) If you created the Nextcloud Profile scope mapping, add it to Selected Scopes.
        • Subject Mode: Based on the User's UUID
    • Configure Bindings (optional): you can create a binding (policy, group, or user) to manage the listing and access to applications on a user's My applications page.

  3. Click Submit to save the new application and provider.


Info

Depending on your Nextcloud configuration, you may need to use https://nextcloud.company/index.php/ instead of https://nextcloud.company/.

Nextcloud configuration

  1. In Nextcloud, ensure that the OpenID Connect user backend app is installed.

  2. Log in to Nextcloud as an administrator and navigate to Settings > OpenID Connect.

  3. Click the + button and enter the following settings:

    • Identifier: authentik

    • Client ID: Client ID from authentik

    • Client secret: Client secret from authentik

    • Discovery endpoint: https://authentik.company/application/o/<application_slug>/.well-known/openid-configuration

    • Scope: email profile nextcloud openid

    • Under Attribute mappings:

      • User ID mapping: sub (or user_id for existing users)

      • Display name mapping: name

      • Email mapping: email

      • Quota mapping: quota (leave blank if the Nextcloud Profile property mapping was skipped)

      • Groups mapping: groups (leave blank if the Nextcloud Profile property mapping was skipped)
        Tip: Enable Use group provisioning to allow writing to this field.

    • Use unique user ID: If this option is disabled, Nextcloud will use the mapped user ID as the Federated Cloud ID.

    Info

    If authentik and Nextcloud are running on the same host, you will need to add 'allow_local_remote_servers' => true to your nextcloud config.php file. This setting allows remote servers with local addresses.

    Info

    To avoid a hashed Federated Cloud ID, deselect Use unique user ID and use user_id for the User ID mapping.

    Danger

    If you're using the Nextcloud Profile property mapping and want administrators to retain their ability to log in, make sure that Use unique user ID is disabled. If this setting is enabled, it will remove administrator users from the internal admin group and replace them with a hashed group ID named "admin," which does not have real administrative privileges.

Enabling OIDC back-channel logout

To automatically log users out of their Nextcloud sessions when they log out of authentik, enable back-channel logout.

  1. Log in to Nextcloud as an administrator and navigate to Settings > OpenID Connect.
  2. Under Registered Providers, locate the provider with the identifier used earlier.
  3. Copy the back-channel-logout-URL value for that provider.
    For example: https://nextcloud.company/apps/user_oidc/backchannel-logout/<identifier>
  4. In authentik, navigate to Applications > Providers and edit the Nextcloud provider.
  5. Under Protocol Settings, set the Logout URI to the copied back-channel logout URL.
  6. Set the Logout Method to Back-channel.

Making OIDC the default login method

Automatically redirect users to authentik when they access Nextcloud by running the following command on your Nextcloud docker host:

Opção 1 - (Tela de Login Authentik direto)
sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ config:app:set --value=0 user_oidc allow_multiple_user_backends. 

Opção 2 - (Tela de Login Authentik e Nextcloud)
sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ config:app:set --value=1 user_oidc allow_multiple_user_backends. 

Configuration verification

To confirm that authentik is correctly configured with Nextcloud, log out and then log back in by clicking OpenID Connect. You'll then be redirected to authentik to log in, and once authentication is successful, you'll reach the Nextcloud dashboard.

Resources

Instalação e Configurações do Authentik

Integração do Nextcloud com Authentik LDAP

Link: https://integrations.goauthentik.io/chat-communication-collaboration/nextcloud/

Em 09/04/2026

What is Nextcloud

Nextcloud is a suite of client-server software for creating and using file hosting services. Nextcloud is free and open-source, which means that anyone is allowed to install and operate it on their own private server devices.

-- https://nextcloud.com/

WARNING

If you require server side encryption, you must use LDAP. OpenID and SAML will cause irrevocable data loss. Nextcloud server side encryption requires access to the user's cleartext password, which Nextcloud has access to only when using LDAP because the user enters their password directly into Nextcloud.

CAUTION

This setup only works when Nextcloud is running with HTTPS enabled. See here on how to configure this.

INFO

If there’s an issue with the configuration, you can log in using the built-in authentication by visiting http://nextcloud.company/login?direct=1.

Configuration methods

It is possible to configure Nextcloud to use OIDC, SAML, or LDAP for authentication. Below are the steps to configure each method.

  • OIDC
  • SAML
  • LDAP

 

LDAP Configuration

Preparation

The following placeholders are used in this guide:

  • nextcloud.company is the FQDN of the Nextcloud installation.
  • authentik.company is the FQDN of the authentik installation.
INFO

This documentation lists only the settings that you need to change from their default values. Be aware that any changes other than those explicitly mentioned in this guide could cause issues accessing your application.

Create an application and provider in authentik

  1. Log in to authentik as an administrator and open the authentik Admin interface.

  2. Navigate to Applications > Applications and click Create with Provider to create an application and provider pair. (Alternatively you can first create a provider separately, then create the application and connect it with the provider.)

    • Application: provide a descriptive name, an optional group for the type of application, the policy engine mode, and optional UI settings.
    • Choose a Provider type: select LDAP as the provider type.
    • Configure the Provider: provide a name (or accept the auto-provided name) and the bind flow to use for this provider
    • Configure Bindings (optional): you can create a binding (policy, group, or user) to manage the listing and access to applications on a user's My applications page.

  3. Click Submit to save the new application and provider.

Create an LDAP outpost

  1. Log in to authentik as an admin, and open the authentik Admin interface.

  2. Navigate to Applications > Outposts and click Create.

    • Name: provide a suitable name for the outpost.
    • Type: LDAP
    • Under applications, add the newly created Nextcloud application to Selected Applications.

  3. Click Create.


Nextcloud configuration

  1. In Nextcloud, ensure that the LDAP user and group backend app is installed.

  2. Log in to Nextcloud as an administrator.

  3. Navigate to Settings > LDAP user and group backend and configure the following settings:

    • On the Server tab:

      • Click the + icon and enter the following settings:
        • Host: enter the hostname/IP address of the authentik LDAP outpost preceded by ldap:// or ldaps://. If using LDAPS you will also need to specify the certificate that is being used.
        • Port: 389 or 636 for secure LDAP.
        • Under Credentials, enter the Bind DN of the authentik LDAP provider and the associated user password.
        • Under Base DN, enter the Search base of the authentik LDAP provider.

    • On the Users tab:

      • Set Only these object classes to Users.

    • On the LDAP/AD integration tab:

      • Uncheck LDAP/AD Username.
      • Set Other Attributes to cn.
      • Click Expert in the top right corner and enter these settings:
        • Internal Username Attribute: uid
        • UUID Attribute for Users: uid
        • UUID Attribute for Groups: gidNumber
      • Click Advanced in the top right corner and enter these settings:
        • Under Connection Settings:
          • Configuration Active: checked
        • Under Directory Settings:
          • User Display Name Field: name
          • Base User Tree: enter the Search base of the authentik LDAP provider.
          • Group Display Name Field: cn
          • Base Group Tree: enter the Search base of the authentik LDAP provider.
          • Group-Member Association: gidNumber
        • Under Special Attributes:
          • Email Field: mailPrimaryAddress

    • On the Groups tab:

      • Set Only these object classes to groups.
      • Select the authentik groups that require Nextcloud access.
    INFO

    If Nextcloud is behind a reverse proxy, force HTTPS by adding 'overwriteprotocol' => 'https' to the Nextcloud config/config.php file. See the Nextcloud admin manual for more details.

Configuration verification

To confirm that authentik is properly configured with Nextcloud, log out and log back in using LDAP credentials. If successful you will then be redirected to the Nextcloud dashboard.

Resources
Instalação e Configurações do Authentik

Configurações iniciais do Authentik

Link: https://docs.goauthentik.io/install-config/first-steps/

First steps

After you have installed and started authentik, you are now ready to add your first application and provider, add some users, and get started with using authentik as your Identity provider.

image.png

Where are we now, and what's next?

The following tutorial assumes that you have already:

  1. Installed authentik on either Docker Compose, Kubernetes, or AWS CloudFormation and confirmed that the server, worker, and the PostgreSQL database are started and running.

  2. Opened authentik in your browser to the initial-setup flow and added credentials for a default Admin account. (Docker, Kubernetes), or AWS CloudFormation.

Initial setup in browser

You will get a Not Found error if the initial setup URL doesn't include the forward slash / at the very end of the URL. Also verify that the authentik server, worker, and PostgreSQL database are running and healthy. Review additional tips in our troubleshooting docs.

Other optional pre-installation configurations that you might have already completed include:

Install your first application and provider

Now that you have your authentik instance installed and configured with the required settings, you can add your first application and provider. After that, we'll walk through how to add your first user.

Security Best Practice

In a production environment, best practice is to first create a group, then create the user(s), and then add the application. Then you can configure the application to have a binding to a specific group or user. The binding controls the access to the application (whether or not it is displayed on a user's My Applications page).

authentik supports integration with any application; refer to our Integrations documentation to view integrations guides for over 180 of the most common ones.

In this guide we'll be setting up Grafana as an example application.

Why Grafana?  

1. Log in to authentik as an administrator and open the authentik Admin interface.

A. In the Admin interface, navigate to Applications > Applications and click Create with Provider to create an application and provider pair.

About application and provider pairs

Every application that you add to authentik requires a provider, which is used to configure the specific protocol between the application and authentik, for example OAuth2/OIDC, SAML, LDAP, or others.

B. Provide the details for the application (Grafana) and provider (OAuth2/OIDC).

C. Click Submit to save the new application and provider.

2. Configure Grafana to use authentik as its IdP

For some applications, you log into the application and configure settings there; with Grafana you simply edit your Grafana Docker Compose file. Here you add basic configuration settings as well as the Client ID, Client Secret, and the Slug values that you obtained when you configured the application and provider in authentik in Step 1. above.

A. In the Grafana Docker Compose file, set the following environment variables:

Tips

These values below are for a Grafana instance running in Docker; for standalone or Helm Chart instances refer to our Grafana integration guide.

Note that authentik.company is a placeholder that we use in our example settings; replace this with the domain that authentik is running on in your environment.


environment:
    GF_AUTH_GENERIC_OAUTH_ENABLED: "true"
    GF_AUTH_GENERIC_OAUTH_NAME: "authentik"
    GF_AUTH_GENERIC_OAUTH_CLIENT_ID: "<Client ID from above>"
    GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET: "<Client Secret from above>"
    GF_AUTH_GENERIC_OAUTH_SCOPES: "openid profile email"
    GF_AUTH_GENERIC_OAUTH_AUTH_URL: "https://authentik.company/application/o/authorize/"
    GF_AUTH_GENERIC_OAUTH_TOKEN_URL: "https://authentik.company/application/o/token/"
    GF_AUTH_GENERIC_OAUTH_API_URL: "https://authentik.company/application/o/userinfo/"
    GF_AUTH_SIGNOUT_REDIRECT_URL: "https://authentik.company/application/o/<application_slug>/end-session/"
    # Optionally enable auto-login (bypasses Grafana login screen)
    GF_AUTH_OAUTH_AUTO_LOGIN: "true"
    # Optionally map user groups to Grafana roles
    GF_AUTH_GENERIC_OAUTH_ROLE_ATTRIBUTE_PATH: "contains(groups[*], 'Grafana Admins') && 'Admin' || contains(groups[*], 'Grafana Editors') && 'Editor' || 'Viewer'"
    # Required if Grafana is running behind a reverse proxy
    GF_SERVER_ROOT_URL: "https://grafana.company"

B. Save your Grafana Docker Compose file, and then launch the stack and access Grafana via your browser at the configured URL.

C. To confirm that authentik is properly configured with the new application, log out of Grafana and then log back in using the Sign in with authentik button. You should be redirected to authentik to provide credentials.

Add your first user

Now that you can access the authentik Admin interface, and you have added an application and provider, let's add a new user.

1. Log in to authentik as an administrator and open the authentik Admin interface.

A. Navigate to Directory > Users, and click New User.

B. Fill in the required fields:

For information about the optional fields below, refer to our documentation on managing users.

C. Click Create.

2. Verify that the new user was created

What's next?

Now that you have added your first application, and a new user, here are some typical next steps:

Things to know and troubleshooting tips

Review the following information to learn more about the basics of setting up authentik and for troubleshooting tips.

Modifying the Docker Compose file

Especially when you are just starting out with authentik, we recommend that you use the default docker-compose.yml file that comes with the download, instead of trying to write the file from scratch. After you have successfully installed, configured, and accessed authentik, you can edit the file to do more advanced configurations, as documented in the Configuration section.

Reverse proxy

Typically authentik is set up with a reverse proxy in front of it. If you already have a reverse proxy that you are using to handle your incoming network traffic, you can simply use that same reverse proxy for authentik, by adding a few configuration values. For more details see the Reverse proxy guide.

The latest tag is deprecated

The :latest tag has been deprecated and will never be updated from the 2025.2 release. Instead, use a specific version tag for authentik instances' container images, such as :2025.12.

Using bindings to allow or restrict access to applications

Note that if you do not define any bindings, then all users have access to the application. To control access, you can create a binding. For more information about user access, refer to our documentation about authorization and hiding an application.

Upgrades

When you are ready to upgrade to the latest version, be sure to read our Upgrade documentation and refer to the Release Notes for the specific version.

Instalação e Configurações do Authentik

Tradução de mensagens no Authentik

Procedimentos necessários

1) Acessar o container do authentik server e instalar o pacote gettext
docker container exec -ti authentik-server bash
apt update; apt upgrade; apt install gettext
2) Acessar o diretório com arquivo para tradução de português brasileiro:
locale/pt_BR/LC_MESSAGES/django.po
Para facilitar as traduções e poder usar o vim para edição do arquivo, fazer o mapeamento persistente no docker-compose.
volumes:
    - ./volumes/locale/LC_MESSAGES:/locale/pt_BR/LC_MESSAGES

3) Após alterar o arquivo django.po deve ser compilado no container:
python manage.py compilemessages
Este comando deve ser executado no diretório raiz onde está o arquivo manage.py

4) Após finalizar os processos no container, regerar as configurações authentik com os comandos:
docker compose build, e depois reiniciar com docker compose up e down.


Aplicações do Authentik

Modelos de aplicação do Authentik

Aplicações do Authentik

Authentik com Nextcloud

Link: 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) 👇

🧠 Arquitetura segura (recomendada)

🔐 Autenticação

  • Authentik → OpenID Connect (OIDC)
  • Nextcloud → login via SSO

🔒 Criptografia (IMPORTANTE)

❌ NÃO usar:

  • criptografia do lado do servidor do Nextcloud

✅ Usar no lugar:

  • criptografia de disco:
    • LUKS (Linux)
    • ZFS encryption
  • ou criptografia no storage (cloud, NAS, etc.)

🧩 Componentes

  • Nextcloud
  • Authentik (IdP)
  • PostgreSQL (recomendado para ambos)
  • Redis (performance)
  • Reverse proxy (Traefik ou Nginx)

🔐 Fluxo de login

  1. Usuário acessa Nextcloud
  2. Redireciona para Authentik
  3. Login no Authentik
  4. Volta autenticado via token (OIDC)

👉 senha nunca passa pelo Nextcloud (isso é bom)

⚙️ Configuração resumida

1. No Authentik

Criar:

  • Application
  • Provider → OpenID Connect

Configurar:

  • Redirect URI:
https://cloud.seudominio.com/apps/user_oidc/code

Scopes:

openid profile email

2. No Nextcloud

Instalar app:

  • "OpenID Connect Login"

Configurar algo assim:

'oidc_login_provider_url' => 'https://auth.seudominio.com/application/o/',
'oidc_login_client_id' => 'nextcloud',
'oidc_login_client_secret' => 'SECRET',
'oidc_login_auto_redirect' => true,
'oidc_login_end_session_redirect' => true,
'oidc_login_button_text' => 'Login com SSO',
'oidc_login_attributes' => [
'id' => 'sub',
'name' => 'name',
'mail' => 'email',
],

🛡️ Hardening (segurança de verdade)

✅ No Authentik

  • ativar MFA (2FA)
  • políticas de senha forte
  • limitar tentativas de login

✅ No Nextcloud

  • HTTPS obrigatório
  • headers de segurança
  • usar Redis para cache
  • usar PostgreSQL (evitar SQLite)

✅ Infraestrutura

  • backup frequente
  • snapshots
  • firewall (ex: só portas 80/443 abertas)

⚠️ Coisas que você NÃO deve fazer

❌ Ativar:

  • Server-Side Encryption do Nextcloud

❌ Misturar:

  • LDAP + OIDC ao mesmo tempo (gera conflito)

🚀 Extras (opcional, mas top)

  • 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

Aplicações do Authentik

Authentik com SAML - Youtube

Link: https://www.youtube.com/watch?v=BHtL3Gvn31o

Aplicações do Authentik

Authentik LDAP Provider

LDAP Provider: Link: 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/

Outposts: Link: https://docs.goauthentik.io/add-secure-apps/outposts/

Outposts Compose: link: 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)
  2. Create an LDAP application and provider
  3. Create a service account and assign the LDAP search permission
  4. 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 section.

Refer to 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.

  1. 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.
  2. Click Finish

Identification Stage

Next, you'll need to create an Identification Stage.

  1. On the Stages page, click Create.
  2. 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)
  3. Click Finish

User Login Stage

Finally, you'll need to create a User Login Stage.

  1. On the Stages page, click Create.
  2. 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).
  3. 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 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.

  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 or Kubernetes. For more information, refer to the Outpost documentation.
    • 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

  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:

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:

ldapsearch \
  -x \
  -H ldap://<LDAP outpost IP address>:389 \
  -D 'cn=ldapservice,ou=users,DC=ldap,DC=goauthentik,DC=io' \
  -w '<ldapuserpassword>' \
  -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.

LDAPS

In production it is recommended to use LDAPS, which requires ldaps:// as the protocol, and port number 636 rather than 389. See LDAPS for more information.

Aplicações do Authentik

Complete guide to Nextcloud OIDC authentication with Authentik

Link: https://blog.cubieserver.de/2022/complete-guide-to-nextcloud-oidc-authentication-with-authentik/

Posted on 
#nextcloud #authentik #authz #oidc

After migrating my user accounts from OpenLDAP to Authentik, I still need to switch the Nextcloud authentication to a modern protocol, instead of relying on Authentik’s built-in LDAP outpost (which emulates an LDAP server). In a previous post a couple of months ago I explored how to connect the Nextcloud file-hosting suite to the Authentik identity provider 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 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:

#  OIDC

OpenID Connect (or OIDC for short) is an identity layer based on the more extensive OAuth2 authorization framework. 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 (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:

If you want to learn more about it, I recommend looking into this excellent quickstart guide to OIDC.

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/…").

#  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:

#  user_oidc

Out of the three options presented above, I decided to give 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.

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 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.

#  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

Authentik &lsquo;Application&rsquo; Creation Menu

Click on the Create Provider button and fill the menu (shown below) with following settings:

Authentik ‘Provider’ Creation Menu

Authentik &lsquo;Provider&rsquo; Creation Menu

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://<AUTHENTIK-HOSTNAME>/application/o/nextcloud/.well-known/openid-configuration.

#  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:

Nextcloud OIDC provider configuration

Nextcloud OIDC provider configuration

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

# 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="<CLIENT-ID>" \
    --clientsecret="<CLIENT-SECRET>" \
    --discoveryuri="<AUTHENTIK-OPENID-CONFIGURATION-URL>" \
    --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

A long federated cloud ID caused by the &lsquo;Use unique user ID&rsquo; setting

#  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.

#  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:

Nextcloud with disabled login form

Nextcloud with disabled login form
1

php ./occ config:app:set user_oidc allow_multiple_user_backends --value=1

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.

#  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.

Single logout is enabled, but Authentik still asks if the user want to end all SSO sessions

Single logout is enabled, but Authentik still asks if the user want to end all SSO sessions

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 (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.

#  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. 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.

Aplicações do Authentik

Migrating users from LDAP to Authentik

Link: https://blog.cubieserver.de/2022/migrating-users-from-ldap-to-authentik/

Posted on 
#ldap #authentik #authz

For several years (the earliest timestamp I could find is from 2016), I have been using OpenLDAP (a.k.a 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, 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, 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 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.

#  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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

authentik:
  secret_key: "ThisIsNotASecretKey"
  error_reporting:
    enabled: false
  postgresql:
    password: "ThisIsNotASecurePassword"

ingress:
  enabled: true
  hosts:
    - host: auth.example.com
      paths:
        - path: "/"
          pathType: Prefix


postgresql:
  enabled: true
  postgresqlPassword: "ThisIsNotASecurePassword"
redis:
  enabled: true

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.

#  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

Authentik Dashboard Overview

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

Authentik LDAP Source configuration

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. 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.

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:

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:

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

Successful LDAP Synchronization

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

Users after import into Authentik

#  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.