Authentik com Docker: SSO para seus aplicativos

Um login para todos os aplicativos hospedados

Authentik é um servidor SSO (single sign-on) auto-hospedado: os usuários fazem login uma vez, e todos os aplicativos protegidos por ele aceitam essa sessão em vez de solicitar uma senha própria. A instalação usa um arquivo oficial do Docker Compose e dois segredos gerados. A parte que exige mais atenção vem depois: apontar um proxy reverso para ele e colocar um aplicativo existente atrás da autenticação encaminhada.

O Authentik é executado como três serviços nesse arquivo do Compose: um banco de dados PostgreSQL, um processo server e um processo worker. O contêiner do servidor também executa o outpost integrado, que é o componente responsável por responder "esta solicitação está autenticada?" para cada aplicativo protegido. A versão 2026.5 é a versão atual em julho de 2026, e o projeto recomenda um host com pelo menos 2 núcleos de CPU e 2 GB de RAM. Considere isso o mínimo. O PostgreSQL e o worker mantêm memória alocada depois que o servidor permanece em execução por um dia.

O que você precisa antes de começar

Você precisa do Docker Engine com o plugin Compose v2, o que pode ser confirmado com docker compose version. Se esse comando exibir um erro em vez de uma versão, instale o plugin antes de continuar; os conceitos básicos estão descritos em executando aplicações com Docker Compose em um VPS. Você também precisa de um registro DNS A apontando para o servidor, auth.example.com nos exemplos abaixo, porque o Authentik cria os URLs de redirecionamento com base no hostname usado pelo navegador.

Execute a stack como um usuário comum no grupo docker, e não como root. A associação a esse grupo equivale a root no host. Portanto, atribua esse acesso a uma única conta de implantação e a mais ninguém, conforme descrito em contas de usuário com privilégio mínimo em um VPS.

Instalar com o arquivo oficial do Compose

sudo install -d -o "$USER" -g "$USER" /opt/authentik
cd /opt/authentik
wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

docker compose ps deve listar três contêineres. postgresql deve informar healthy, e server deve informar worker e running. A primeira inicialização executa as migrações do banco de dados. Aguarde um minuto antes de acessar a interface web.

Os dois valores gerados são importantes, por motivos diferentes. PG_PASS é a senha do PostgreSQL e tem um limite máximo de 99 caracteres. AUTHENTIK_SECRET_KEY assina sessões e tokens. Alterá-lo depois desconecta todos os usuários e invalida todos os tokens de API emitidos. Mantenha .env com o modo 600 e guarde uma cópia em um local seguro. Um banco de dados restaurado sem a chave secreta correspondente é um banco de dados no qual ninguém consegue fazer login.

O arquivo do Compose lê os dois valores usando o formato ${PG_PASS:?database password required}. Por isso, o Compose recusa a inicialização quando o arquivo está ausente. Executar docker compose up -d no diretório errado exibe required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required e encerra. Essa mensagem indica um problema de caminho, não de configuração.

Os valores do ambiente que importam

Todo o restante fica no mesmo arquivo .env. O Authentik mapeia dois sublinhados para uma chave de configuração aninhada, portanto AUTHENTIK_EMAIL__HOST define email.host. Um único sublinhado é ignorado sem aviso. Essa é a causa mais comum de uma configuração parecer não fazer nada.

• AUTHENTIK_BOOTSTRAP_PASSWORD define a senha do usuário akadmin integrado na primeira inicialização. Assim, você nunca precisa digitá-la em um formulário web público. AUTHENTIK_BOOTSTRAP_EMAIL e AUTHENTIK_BOOTSTRAP_TOKEN definem, da mesma forma, o endereço desse usuário e um token de API.
• COMPOSE_PORT_HTTP e COMPOSE_PORT_HTTPS transferem as portas publicadas para fora dos valores padrão 9000 e 9443.
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS e AUTHENTIK_EMAIL__FROM configuram o envio de e-mail. Sem essas variáveis, o Authentik tenta usar localhost na porta 25. Por isso, os e-mails de redefinição de senha terminam com um erro de conexão no log do worker.
• AUTHENTIK_LOG_LEVEL=debug ativa os detalhes necessários enquanto um fluxo de login apresenta problemas. Depois, reverta para info.
• AUTHENTIK_ERROR_REPORTING__ENABLED é false por padrão. Defina como true somente se você aceitar enviar relatórios de falhas ao projeto upstream.

Esses são segredos armazenados em um arquivo de texto simples. Trate o diretório como qualquer outro armazenamento de credenciais. Um gerenciador de senhas, como uma instância auto-hospedada do Vaultwarden, é um local melhor para guardar a cópia de recuperação do que uma nota no seu laptop.

Primeiro login e a conta de administrador

Abra http://SERVER_IP:9000 em um navegador. O Authentik exibe o fluxo de configuração inicial e solicita que você defina uma senha para o usuário akadmin padrão. Se você já definiu AUTHENTIK_BOOTSTRAP_PASSWORD, essa etapa foi concluída e você vai diretamente para a página de login.

Crie um usuário administrador normal para você em Directory e depois em Users, adicione-o ao grupo authentik Admins e faça login com essa conta. Mantenha akadmin como uma conta de emergência, com uma senha longa armazenada offline. O trabalho diário com uma conta integrada compartilhada destrói o log de auditoria, porque todos os eventos mostram akadmin e não indicam quem realizou a ação.

Coloque o Authentik atrás do seu proxy reverso

Publicar a porta 9000 na internet funciona, mas você quer TLS (segurança da camada de transporte) e um nome de host real. Se você já usa a configuração de Traefik como proxy reverso para vários aplicativos Compose, conecte o Authentik à mesma rede externa proxy com um arquivo de substituição. Crie docker-compose.override.yml ao lado de compose.yml:

services:
  server:
    networks:
      - default
      - proxy
    labels:
      traefik.enable: "true"
      traefik.docker.network: proxy
      traefik.http.routers.authentik.rule: Host(`auth.example.com`)
      traefik.http.routers.authentik.entrypoints: websecure
      traefik.http.routers.authentik.tls.certresolver: le
      traefik.http.services.authentik.loadbalancer.server.port: "9000"

networks:
  proxy:
    external: true

Aplique com docker compose up -d. O Compose mescla a substituição automaticamente, portanto o serviço server mantém tudo do arquivo oficial e recebe os labels. Verifique com curl -I https://auth.example.com/if/user/, que deve responder HTTP/2 200. Um 404 page not found do Traefik significa que o contêiner não está na rede proxy, e o Traefik não pode encaminhar tráfego para um contêiner que não consegue alcançar.

Depois que o nome de host funcionar, associe as portas publicadas a 127.0.0.1 na substituição, para que a única forma de acesso seja pelo proxy.

Proteja um aplicativo com autenticação encaminhada

O proxy provider do Authentik tem três modos, e escolher o modo errado pode custar uma hora. Proxy significa que o próprio outpost encaminha o tráfego para o aplicativo upstream. Forward auth (single application) significa que seu próprio proxy reverso continua encaminhando o tráfego e apenas pergunta ao Authentik se a sessão está autenticada. Forward auth (domain level) protege todos os aplicativos sob um domínio pai usando um único provider, mas exige regras de autorização por aplicativo. Com o Traefik na frente, use forward auth (single application).

Na interface web, abra Applications e depois Providers, crie um Proxy Provider, escolha o modo forward auth single application e defina o host externo como https://app.example.com. Crie uma Application que aponte para esse provider. Depois abra Outposts, edite o authentik Embedded Outpost e mova o novo aplicativo para a lista de aplicativos selecionados. O outpost só responde pelos aplicativos atribuídos a ele. Por isso, se essa última etapa for ignorada, um provider configurado corretamente ainda não retornará nada.

Defina o middleware uma única vez, no container do Authentik, e referencie-o em todos os aplicativos protegidos:

      traefik.http.middlewares.authentik.forwardauth.address: http://server:9000/outpost.goauthentik.io/auth/traefik
      traefik.http.middlewares.authentik.forwardauth.trustForwardHeader: "true"
      traefik.http.middlewares.authentik.forwardauth.authResponseHeaders: X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid,X-authentik-jwt,X-authentik-meta-jwks,X-authentik-meta-outpost,X-authentik-meta-provider,X-authentik-meta-app,X-authentik-meta-version

authResponseHeaders é a lista de cabeçalhos que o Traefik copia da resposta do Authentik para a requisição enviada ao upstream. Se você omitir essa lista, o aplicativo continuará protegido, mas não saberá quem é o usuário. Assim, qualquer componente que leia X-authentik-username para fazer login automático continuará tratando o usuário como desconectado.

O próprio aplicativo protegido precisa de dois routers, não de um:

    labels:
      traefik.enable: "true"
      traefik.http.routers.myapp.rule: Host(`app.example.com`)
      traefik.http.routers.myapp.entrypoints: websecure
      traefik.http.routers.myapp.tls.certresolver: le
      traefik.http.routers.myapp.middlewares: authentik@docker
      traefik.http.routers.myapp-auth.rule: Host(`app.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)
      traefik.http.routers.myapp-auth.entrypoints: websecure
      traefik.http.routers.myapp-auth.tls.certresolver: le
      traefik.http.routers.myapp-auth.priority: "15"
      traefik.http.routers.myapp-auth.service: authentik

O segundo router é a parte que todos deixam de configurar. Depois do login, o Authentik envia o navegador de volta para um caminho sob /outpost.goauthentik.io/ no hostname do aplicativo, não sob auth.example.com. Sem um router que encaminhe esse prefixo de caminho para o serviço do Authentik, a requisição chega ao aplicativo, que responde com 404, e o login nunca é concluído. O valor maior de priority faz a regra de caminho específica vencer a regra simples Host() no mesmo domínio.

Teste em uma janela privada do navegador. Você deverá ser enviado para auth.example.com, fazer login e retornar ao aplicativo. docker compose logs -f server no lado do Authentik imprime um evento de autorização para cada tentativa, indicando se a requisição chegou ao Authentik.

As falhas que você realmente encontrará

Loop infinito de redirecionamento entre o aplicativo e a página de login. O host externo no provedor não corresponde ao host usado pelo navegador, geralmente http:// no provedor e https:// na barra de endereço. O cookie de sessão é definido para uma origem diferente. Por isso, cada retorno é interpretado como uma nova solicitação anônima. Corrija o host externo e limpe os cookies dos dois domínios antes de testar novamente.

404 em /outpost.goauthentik.io/start. O roteador do outpost está ausente ou tem prioridade menor que o roteador abrangente desse host.

O aplicativo carrega sem nunca solicitar login. O rótulo middlewares referencia um middleware inexistente. O Traefik não emite um aviso nesse caso. Portanto, um erro de digitação em authentik@docker simplesmente faz com que nenhum middleware seja executado. Abra o painel do Traefik e confirme se o roteador lista o middleware.

403 do Authentik após um login bem-sucedido. O usuário foi autenticado, mas não está autorizado. O aplicativo tem uma associação de política ou um requisito de grupo que esse usuário não atende. O log Events na interface administrativa identifica a política que negou o acesso.

Quando o Keycloak é a opção mais adequada

O Keycloak é o projeto mais antigo, conta com o suporte da Red Hat e é a opção mais forte para casos clássicos de identidade empresarial: federação SAML de alta complexidade, intermediação de logins de vários provedores de identidade externos ao mesmo tempo e exportação e importação de realms como um caminho de migração documentado. Para algumas organizações, o suporte comercial também é importante. A desvantagem é que o Keycloak não tem um proxy próprio. Portanto, para proteger um aplicativo que não fala OIDC (OpenID Connect), é necessário executar algo como oauth2-proxy ao lado dele. O provedor de proxy integrado do Authentik já oferece essa função, com integração nativa. Por isso, a maioria dos administradores que mantêm vários aplicativos diferentes escolhe o Authentik.

Backups e atualizações

Três itens tornam uma restauração possível: o banco de dados PostgreSQL, o diretório ./data e .env.

cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > authentik-$(date +%F).sql.gz

Armazene esse dump junto com .env. O dump sozinho não é suficiente, porque a chave secreta que protege os dados de sessão e de token fica em .env.

As atualizações consistem em alterar uma tag. Defina AUTHENTIK_TAG em .env para a release desejada e execute docker compose pull seguido de docker compose up -d. Leia primeiro as notas da release, porque o Authentik usa versões baseadas em data e algumas releases incluem migrações que esperam que você esteja vindo da versão anterior. Faça o dump do banco de dados antes do pull, não depois.

FAQ

O Authentik é gratuito para hospedagem própria?

A edição de código aberto é gratuita e inclui tudo o que foi descrito acima: o provedor de proxy, forward auth, OIDC (OpenID Connect), SAML e o mecanismo de fluxos. Um nível empresarial pago adiciona suporte e alguns recursos empresariais, mas nada neste tutorial exige uma licença.

Preciso do Traefik para usar o Authentik?

Não. O forward auth funciona com nginx por meio de auth_request e com Caddy por meio de forward_auth. O padrão é o mesmo em todos os casos: o proxy reverso consulta o Authentik sobre cada solicitação, e o prefixo de caminho /outpost.goauthentik.io/ no host protegido deve encaminhar para o Authentik, e não para o aplicativo.

Por que meu aplicativo protegido alterna indefinidamente entre a tela de login e o erro?

O host externo configurado no provedor de proxy não corresponde à URL usada pelo navegador, geralmente http em vez de https. O cookie de sessão é emitido para uma origem e lido em outra, então o Authentik considera cada solicitação anônima. Corrija o host externo e limpe os cookies dos dois nomes de host antes de testar novamente.

De quanta RAM o Authentik precisa?

O mínimo documentado é de 2 núcleos de CPU e 2 GB de RAM em julho de 2026. Esse valor contempla o PostgreSQL, o servidor e o worker juntos. Em uma máquina com 2 GB, o worker é o primeiro processo encerrado pelo kernel sob pressão de memória. O sintoma é a interrupção das tarefas em segundo plano e do email de saída, enquanto a página de login continua funcionando. Aloque 4 GB se o mesmo servidor também executar os aplicativos que você está protegendo.