Histórico de versões
Cada versão, com o que mudou e por quê. O Kotauth segue o versionamento semântico.
Grade de Metodos de Login substitui o painel de dois cartoes na pagina de Politica de Seguranca: uma linha por metodo (Senha, Passkey, Magic link, Email OTP, Google, GitHub)
password_login_disabled consolidado em security_config.passwordLoginEnabled (migracao V55 preenche automaticamente)
Rail de Seguranca do admin reestruturado: Politica de Seguranca, MFA, Passkeys, Sessoes. O portal ganha um grupo pai de Seguranca
A pagina de alteracao de senha agora ativa corretamente o grupo de navegacao de Seguranca
Passkeys / WebAuthn: login sem senha via biometria do dispositivo (Face ID, Windows Hello) ou chaves de hardware (YubiKey). Cadastre no portal, faca login com um toque ou preenchimento automático condicional
Toggle passkeys_enabled por tenant e modo somente-sem-senha (oculta o campo de senha, mostra apenas passkey + magic link)
Gerenciamento de passkeys por usuario no admin: listar credenciais com nomes de dispositivo (busca AAGUID), revogar individualmente, redefinir todas. Novo comando CLI reset-admin-passkeys
Passkey com verificacao de usuario satisfaz MFA: usuarios pulam TOTP ao fazer login com uma passkey
Defesa contra replay por credencial via contador de assinatura WebAuthn; autenticadores clonados sao revogados automaticamente com evento de auditoria PASSKEY_REPLAY_REJECTED
Gate duro de SMTP impede habilitar o modo somente-sem-senha sem entrega de email configurada
Rate limiting no endpoint de autenticacao por passkey: 10 tentativas por 60s por IP, fail-closed em queda do Redis
Indicador de recurso RFC 8707 no grant authorization_code: parametros de recurso vinculados ao codigo emitido e propagados para o claim aud do access token
Estreitamento de escopo RFC 9068: solicitacoes de token direcionadas a APIs sao estreitadas para a intersecao dos escopos solicitados e dos escopos declarados das APIs
Editor de escopos no Admin UI: cada API no registro do workspace pode declarar escopos aceitos, exibidos como badges inline
Pagina de Brand Identity do admin reestruturada em cartao Brand Identity + cartao Visual Theme
Dependencias atualizadas: JUnit 6.1.0, Exposed 1.3.0, imagem base JRE 25
Dois arquivos compose na raiz (docker-compose.yml + docker-compose.prod.yml) substituem seis que ficavam em docker/
Overlay de DB externo substituído por DB_URL no .env; overlay de demo substituído por KAUTH_DEMO_MODE=true no .env
Toda a orientação de deploy movida para a documentação; comentários removidos do Dockerfile, do Caddyfile e dos arquivos compose
Injeção de segredos baseada em arquivo (convenção *_FILE) para KAUTH_SECRET_KEY, DB_PASSWORD, KAUTH_REDIS_PASSWORD, KAUTH_BOOTSTRAP_ADMIN_PASSWORD e KAUTH_BOOTSTRAP_API_KEYS
Lock de dependências do Gradle: o gradle.lockfile fixa o grafo de dependências resolvido, e o CI verifica a cada PR
Dependabot habilitado para alertas semanais sobre dependências do Gradle, GitHub Actions e imagens base do Docker
Cadeia HMAC sobre o log de auditoria: cada linha carrega prev_hash e row_hash via HMAC-SHA256 com chave KAUTH_SECRET_KEY; adulteração ou reordenação quebra a cadeia
Novo comando CLI verify-audit-chain detecta linhas de auditoria adulteradas ou reordenadas
Os detalhes do log de auditoria agora usam kotlinx.serialization, corrigindo a corrupção silenciosa de JSON causada por strings concatenadas manualmente
Introspecção de token com múltiplas audiências: AccessTokenClaims.aud ampliado para suportar o formato de array
Resource Indicators da RFC 8707 para o grant client_credentials: tokens M2M direcionados por audiência com aud vinculado ao recurso solicitado
Registro de APIs (admin: /settings/apis): CRUD com escopo de workspace para identificadores de audiência
Tela "Authorized APIs" por cliente com autorização via checkbox e metadados de Discovery anunciando resource_indicators_supported: true
Recursos desconhecidos ou não autorizados retornam invalid_target 400 da RFC 8707 em vez de um token silenciosamente abrangente
Todos os 8 tipos de email transacional localizados: verificação, magic link, redefinição de senha, conta bloqueada, convite, senha alterada, teste de SMTP e OTP
Os templates de email são renderizados no defaultLocale do workspace com fallback para o inglês por chave
Opt-in de proxy confiável (KAUTH_TRUSTED_PROXY): impede a evasão do rate limit por meio de spoofing de header
Imposição do issuer no JWT: tokens emitidos por um tenant são rejeitados por outro
Prevenção de open redirect: o redirect_uri pós-login é validado contra os valores registrados
A comparação do code verifier PKCE S256 usa igualdade em tempo constante
Header de resposta Server suprimido das respostas HTTP
Normalização de erros de login com equalização de tempo impede a enumeração de usuários
O contêiner roda sem root (UID 10001) com no-new-privileges, cap_drop: ALL e sistema de arquivos somente leitura
Proteção contra replay de TOTP: cada código é de uso único por enrollment; bloqueio após um número configurável de tentativas falhas
A validação das variáveis CSS de tema impede a injeção de valores arbitrários por meio das configurações do workspace
Tempo de erro de login equalizado entre os caminhos de verificação de senha e de TOTP
AdminService dividido em AuthManagementService, UserAdminService e WorkspaceAdminService
UserSelfServiceService dividido em UserProfileService e UserSecurityService
Ratchet do Detekt reforçado: regras de complexidade e acoplamento impostas no CI
BREAKING: Credencial de admin padrão removida. Uma senha aleatória é gerada no primeiro boot e registrada uma única vez no stdout.
BREAKING: O endpoint de refresh token agora exige autenticação do cliente (client_id + client_secret para clientes confidenciais)
BREAKING: Os endpoints de introspecção e revogação exigem autenticação do cliente conforme a RFC 7662 / RFC 7009
Detecção de replay de refresh-token com revogação completa da família de sessões em caso de reutilização
Bloqueio de conta com limite configurável e UI de desbloqueio para admin
Login hospedado com Email OTP: autenticação sem senha em duas etapas no navegador (digite o email, receba um código de 6 dígitos, entre)
Alternância por tenant para o Email OTP via configurações do workspace
Primitivas de API de admin send-otp / verify-otp para onboarding programático sem senha
Defesa de bloqueio entre desafios: limite de tentativas de OTP por tenant com postura de resposta em tempo constante
Incompatibilidade no prefixo da chave de API de bootstrap: kauth_{slug}_ agora é aplicado de forma consistente na geração e na validação
Validação de redirect-URI reforçada: correspondência exata exigida, variantes com barra final rejeitadas
Especificação OpenAPI atualizada com os endpoints de envio/verificação de OTP e a documentação dos filtros do log de auditoria
Grupos de filtro do log de auditoria exibidos na UI de admin para uma navegação mais limpa por categoria de evento
Papéis padrão do cliente: papéis por aplicação atribuídos automaticamente a usuários que se autorregistram por meio de uma aplicação OAuth
Card de Registration Defaults no console de admin com dropdown e tabela de gerenciamento de papéis
Proteção contra escalada de privilégios entre clientes: papéis de outras aplicações não podem ser atribuídos como padrão
Branding de email transacional: nome da marca, cor, URL do logo, email de suporte e nome de exibição do remetente, por tenant
Todos os 8 templates de email transacional herdam o branding do workspace automaticamente
Card de editor de branding nas configurações do workspace com preview ao vivo
Personificação de admin: aja como qualquer usuário sem conhecer a senha dele, com o claim act da RFC 8693 no token de sessão
Modelo de sessão dupla: a sessão de admin permanece ativa por baixo da sessão personificada
Revogação em cascata: revogar a sessão de admin também encerra a sessão personificada
Servidor MCP nativo de IA (@kotauth/mcp): 33 ferramentas em 8 domínios expostas via Model Context Protocol
Controle de acesso baseado em escopo em cada ferramenta MCP: a chave de API concede apenas as permissões que você escolher
Conexão com um único comando: npx @kotauth/mcp