Configurar SSO com Auth0¶

Auth0 é compatível com OIDC e expõe um endpoint de discovery por tenant. O principal a acertar é o domínio do tenant, que aparece na URL de discovery e muda se você ativar um domínio personalizado.

Este guia cobre o lado do Auth0: criar a aplicação e recolher os valores que o digna precisa. O lado do digna — dashboard_config.toml, testes e resolução de problemas — é o mesmo para todos os provedores e está descrito na Visão Geral do Single Sign-On.

Antes de Começar¶

Requisito	Observações
Função no Auth0	Administrador no tenant
Domínio do tenant	ex.: `yourcompany.eu.auth0.com` — o segmento de região é importante
URI de redirect do digna	A URL para onde os usuários retornam após o login, ex.: `https://digna.yourdomain.com/oidc/callback`

Passo 1: Criar a Aplicação¶

Faça login no Painel do Auth0
Vá para Applications → Applications
Clique em Create Application
Nomeie como digna e escolha Regular Web Applications
Clique em Create

Escolha 'Regular Web Applications'

Single Page Application e Native criam clientes públicos sem secret. O digna realiza a troca de código a partir do seu backend e precisa de um cliente confidencial, então Regular Web Applications é o tipo correto. Ao contrário de alguns provedores, o Auth0 permite alterar o tipo depois em Settings → Application Type.

Passo 2: Adicionar a URL de Callback¶

Na aba Settings da aplicação:

Encontre Allowed Callback URLs
Insira sua URL de callback do digna:

https://digna.yourdomain.com/oidc/callback

Opcionalmente defina Allowed Logout URLs para a URL do seu dashboard
Role até o final e clique em Save Changes

Separadas por vírgulas, não por novas linhas

O Auth0 aceita várias URLs de callback neste campo, separadas por vírgulas. Uma lista separada apenas por quebras de linha é interpretada como uma única URL malformada e não corresponde silenciosamente a nada.

Passo 3: Recolher as Credenciais¶

Ainda em Settings, no painel Basic Information:

Domain → entra na URL de discovery
Client ID → torna-se DIGNA_OIDC_CLIENT_ID
Client Secret → torna-se DIGNA_OIDC_CLIENT_SECRET (clique para revelar)

Passo 4: Confirmar o Grant Type¶

Vá para Settings → Advanced Settings → Grant Types
Confirme que Authorization Code está marcado

Ele vem habilitado por padrão para Regular Web Applications. Se estiver desmarcado, o login do digna falha com unauthorized_client.

Passo 5: Construir a URL de Discovery¶

Substitua o Domain do Passo 3:

https://<your_tenant_domain>/.well-known/openid-configuration

Por exemplo:

https://yourcompany.eu.auth0.com/.well-known/openid-configuration

Domínios Personalizados Alteram o Issuer

Se o seu tenant usa um domínio personalizado como login.yourcompany.com, use esse domínio na URL de discovery. Misturar os dois — o domínio canônico na URL de discovery e o personalizado no navegador — produz uma incompatibilidade de issuer, e o token é rejeitado após um login que, por outro lado, foi bem-sucedido.

Passo 6: Configurar o digna¶

`dashboard/dashboard_config.toml`¶

[login]
usePassword = true

[[login.oidc]]
key = "auth0"
label = "Login with Auth0"

`config.toml`¶

[oidc.auth0]
DIGNA_OIDC_CLIENT_ID = "aBcDeFgHiJkLmNoPqRsTuVwXyZ123456"
DIGNA_OIDC_CLIENT_SECRET = "<the client secret copied in Step 3>"
DIGNA_OIDC_REDIRECT_URI = "https://digna.yourdomain.com/oidc/callback"
DIGNA_OIDC_CONFIGURATION_URL = "https://yourcompany.eu.auth0.com/.well-known/openid-configuration"

A key em ambos os arquivos deve coincidir — auth0 aqui.

Passo 7: Testar¶

Reinicie o backend e o servidor web, depois abra o dashboard. Veja Teste de Login para a lista completa de verificação.

Resolução de Problemas do Auth0¶

URL de Callback incompatível¶

A página de erro do Auth0 indica a URL que recebeu. Adicione-a em Allowed Callback URLs, verificando se as entradas estão separadas por vírgulas.

unauthorized_client¶

Authorization Code não está habilitado em Advanced Settings → Grant Types, ou o tipo de aplicação não é Regular Web Applications.

Uma Rule, Action ou trigger pós-login no tenant está rejeitando o usuário. Verifique Actions → Flows → Login e os logs do tenant em Monitoring → Logs, que mostram o motivo exato.

Incompatibilidade do Issuer¶

A URL de discovery e o domínio para o qual o navegador foi enviado diferem — geralmente o domínio canônico do tenant versus um domínio personalizado. Use um de forma consistente.

Veja Também¶

Visão Geral do Single Sign-On — referência de configuração, testes e resolução geral de problemas
Auth0: OpenID Connect Discovery