Para colocar autenticação multifator na frente de uma VPN com RADIUS, o gateway da VPN envia o nome de usuário e a senha para o servidor RADIUS usando PAP, o servidor verifica a senha e responde com um Access-Challenge, o cliente exibe um prompt e o usuário digita o código 2FA de um aplicativo autenticador em uma segunda solicitação. O Casdoor inclui um servidor RADIUS que faz exatamente isso para usuários que configuraram TOTP, então um gateway capaz de exibir um prompt Access-Challenge (o FortiGate SSL VPN é um cujo fabricante documenta isso) obtém uma senha mais um código 2FA sem nenhum software adicional. Wi-Fi com WPA2/WPA3-Enterprise é diferente: 802.1X roda sobre EAP, que não tem lugar para um código digitado, então o Casdoor tem uma opção para pular o código para esses clientes.

Para adicionar single sign-on ao Spring Boot, registre cada aplicativo como uma aplicação em um provedor OpenID Connect, como o Casdoor, aponte o Spring Security para a URL do emissor do provedor e escolha o módulo Spring que corresponde ao aplicativo: oauth2Login() para um aplicativo web renderizado no servidor, oauth2ResourceServer().jwt() para uma API REST que recebe tokens bearer e Spring Cloud Gateway com o filtro TokenRelay quando um gateway autentica usuários para um conjunto de microsserviços. Os usuários obtêm SSO porque todos os aplicativos os enviam para o mesmo Casdoor, que lembra a sessão: o segundo aplicativo redireciona, o Casdoor já conhece o usuário e eles retornam diretamente sem um formulário de login. Este post configura as três formas contra um único Casdoor, cada uma com um application.yml funcional e um SecurityFilterChain personalizado.

Vários projetos de dados e middleware Apache incluem seu próprio login Casdoor: o Apache DolphinScheduler tem um tipo de autenticação chamado CASDOOR_SSO (desde a 3.2.0) e um modo OIDC genérico (desde a 3.4.0), o Apache ShenYu tem um plugin Casdoor (desde a 2.5.1), o Apache Pulsar Manager tem um botão "Log in with Casdoor" (desde a 0.3.0) e o Apache APISIX tem o plugin authz-casdoor (desde a 2.14.0). O Apache IoTDB é a exceção: o banco de dados em si autentica com seus próprios usuários e senhas, e apenas o agora arquivado IoTDB Web Workbench se comunica com o Casdoor. A tabela abaixo lista cada projeto, a versão e onde ficam as configurações; a segunda metade do post configura a autenticação de usuários no IoTDB passo a passo.

Não existe "Steam OAuth": o Steam autentica usuários com OpenID 2.0 e fornece um SteamID de 64 bits, nada além disso. O Login Widget clássico do Telegram também não é OAuth: ele entrega à sua página um conjunto de campos de usuário mais um hash HMAC-SHA256 que você verifica com o token do seu bot. O Telegram agora também executa um provedor real de OpenID Connect em oauth.telegram.org. Se você colocar o Casdoor entre sua aplicação e esses provedores, o Casdoor faz as verificações específicas do protocolo e sua aplicação só conversa com o Casdoor usando OpenID Connect, da mesma forma que faria com Google ou GitHub.

Um gateway de pagamento fictício é um provedor de pagamento que aceita todos os checkouts como pagos sem contatar um banco ou rede de cartões, permitindo testar pedidos, assinaturas e entrega sem dinheiro e sem conta no gateway. O Casdoor inclui um: o provedor de pagamento Dummy. Adicione-o a um produto, compre o produto, e o Casdoor registra o pagamento e o pedido como Paid, inicia a assinatura e escreve a transação, tudo sem sair do seu servidor. Use Dummy no desenvolvimento, e alterne para um sandbox de fornecedor (modo de teste Stripe, sandbox PayPal, sandbox Paddle) no staging, onde você também precisa de cartões recusados, 3-D Secure e redirecionamentos reais.

O Casdoor v4.0 foi lançado em 1º de setembro. Dois meses e 25 releases depois, estamos na v4.25, então este é um bom momento para revisar o que mudou. Em resumo: o console administrativo foi reconstruído, a auto-hospedagem ficou muito menos complicada, agora existe um Marketplace para integrações e temas de login, e o Casdoor pode atuar como servidor de autorização para servidores MCP e agentes de IA.

Se você ainda não usou: o Casdoor é uma plataforma open-source de gestão de identidade e acesso (IAM) escrita em Go. É um provedor de identidade completo, não uma biblioteca ou um proxy de login. Os usuários residem no Casdoor, o Casdoor emite os tokens e seus aplicativos se comunicam com ele via OAuth 2.0, OpenID Connect, SAML 2.0, CAS, LDAP ou SCIM. A autorização é tratada pelo Apache Casbin, portanto modelos ACL, RBAC e ABAC funcionam. Ele é licenciado sob Apache-2.0 e está listado no CNCF Landscape.

O Casdoor possui um Helm chart oficial. Ele reside no repositório principal em manifests/casdoor, é publicado a cada lançamento do Casdoor no GHCR e está listado no Artifact Hub. Começando com o Casdoor v4.18.0, o chart também pode manter suas organizações, aplicações, usuários e provedores como configuração declarativa: altere-os no arquivo values, execute helm upgrade, e os pods em execução aplicam a mudança sem reiniciar.

Este post percorre uma implantação no Kubernetes desde o primeiro helm install até uma configuração que você pode manter no Git.

Em 22 de fevereiro de 2026, o Casdoor entrou no CNCF Cloud Native Landscape, na categoria Security & Compliance dentro de Provisioning. O Landscape reúne projetos e produtos cloud-native amplamente utilizados; a inclusão ajuda usuários e empresas a descobrirem e avaliarem soluções para construir sistemas cloud-native.

https://landscape.cncf.io/?item=provisioning--security-compliance--casdoor

Em uma era onde a gestão de identidade digital é crucial, soluções de Single Sign-On (SSO) como o Casdoor estão revolucionando a maneira como os usuários interagem com múltiplos aplicativos. O SSO do Casdoor simplifica o processo de login permitindo que os usuários se autentiquem apenas uma vez para acessar múltiplos serviços. Isso não apenas aumenta a conveniência do usuário, mas também impulsiona o engajamento e a satisfação.

Bem-vindo ao site oficial do Casdoor!👋