Novidades

Cada item diz o que mudou e leva até onde isso é explicado. As mudanças chegam primeiro à plataforma compartilhada; as bibliotecas têm versão própria, e cada item cita a versão que trouxe a mudança.

19 de outubro de 2026

• Telas de erro com a cara do login. A tela de erro de um client segue a disposição escolhida para o login (painel ao lado, centralizado ou cobrindo), com o mesmo painel da marca e o erro no cartão onde ficaria o formulário. Dali, Voltar para o login retoma o acesso de onde parou, e um segundo botão leva de volta à aplicação. Um pedido de autorização recusado, como um endereço de retorno (redirect_uri) não cadastrado, passa a ser explicado no idioma da tela. Veja marca.
• Login com GitHub chega à conta que já existe. Quando a conta do GitHub deixa o e-mail público, o Authio passa a conferir a verificação dele na API de e-mails do GitHub. Com Vincular por e-mail verificado e a confiança na claim ligados, a pessoa entra na conta do realm que já tem esse e-mail, em vez de o login ser recusado por e-mail duplicado. Veja vínculo de contas.
• Provedores reconhecíveis nas opções de login. Na aba Opções de login de um client, na visualização e na edição, cada provedor aparece com a própria marca (Google, Microsoft, GitHub, Apple), e a edição mostra a posição de cada um ao lado dela. Veja adicionar um provedor.
• Claims herdadas mais compactas. No passo Permissões da edição do usuário, as claims que vêm dos papéis aparecem agrupadas por tipo, com os valores lado a lado, em vez de uma linha para cada par. Veja atribua papéis.

18 de outubro de 2026

• Telas que carregam no lugar. Enquanto os dados chegam, as telas do console já desenham a forma que vão ter: todas as seções do painel, as listas, as abas de um registro e os passos de uma edição. Nada empurra o que você está lendo quando os números chegam, e um valor que ainda está carregando não aparece mais como zero, estado vazio ou identificador cru. Veja o painel.
• Verificação humana no login. O login hospedado (a etapa de senha e o pedido de código por e-mail), o Esqueceu a senha? e a criação de conta no console passam a pedir a verificação do Cloudflare Turnstile quando a implantação tem as chaves. No login ela é quase sempre invisível e, se a Cloudflare estiver fora do ar, o login segue protegido pela proteção contra ataques; no Esqueceu a senha? e na criação de conta, sem a resposta da Cloudflare a tela recusa. Veja verificação humana.

17 de outubro de 2026

• Cadastro pelo próprio usuário. Um client pode deixar as pessoas criarem a própria conta na tela de login: qualquer pessoa, ou só e-mails dos domínios que você listar. A conta é confirmada por e-mail antes de abrir, a tela nunca diz se um e-mail já tem conta e uma verificação do Cloudflare Turnstile segura scripts. Veja cadastro pelo próprio usuário.
• Entrar com código por e-mail. Um client pode deixar as pessoas entrarem sem senha: elas digitam o nome e o código de 6 dígitos enviado ao e-mail da conta, que vale 10 minutos e abre um único login. Pode ficar ao lado da senha, e o aplicativo autenticador, a aprovação no celular ou uma passkey podem vir depois. Veja entrar com código por e-mail.
• Seus dados, no portal da conta. As pessoas baixam uma cópia de tudo o que o realm guarda sobre elas em um arquivo JSON e, quando o realm liga a opção, excluem a própria conta depois de um login recente. Veja seus dados.
• Atividade no portal da conta. A aba Atividade lista os logins da própria pessoa, lidos pela pessoa e pelo realm que a sessão comprova. Veja as páginas da conta.

16 de outubro de 2026

• Bibliotecas 0.9.0. Os pacotes Node.js em @hyper.authio e os pacotes .NET só aceitam um access token com o tipo at+jwt da RFC 9068, e ganham um backend para single-page apps (BFF) em Express e em ASP.NET Core, que guarda os tokens no servidor. Veja Node.js e .NET.
• Provider Next.js 4.1.0. @hyper.authio/provider-nextauth decifra sozinho os tokens criptografados, no Auth.js v5 e no NextAuth v4. Veja Next.js e criptografia de tokens.
• MCP 0.5.0. @hyper.authio/mcp e Authio.Mcp.AspNetCore recebem as configurações do client pelos nomes do protocolo (tokenEndpointAuthMethod, accessTokenSignedResponseAlg), verificam tokens assinados com HS usando o client secret e deixam de supor um escopo ou uma introspecção que o servidor não declarou. Veja atualizar a partir da 0.3.
• Um console interligado. As telas que citam um realm, client, usuário ou chave levam até ele, e as listas abrem agrupadas pelo que mais importa nos registros, como os clients por postura. Veja trabalhar com registros.
• Guias de integração no console. Os guias de Clients e de cada realm mostram cada biblioteca passo a passo, e o Guia de cada client monta as receitas a partir das configurações do próprio client, agora também para um BFF, um worker .NET e um servidor MCP.
• Ambientes dedicados. A API de um ambiente dedicado alcança a plataforma compartilhada, inclusive os access tokens at+jwt que as bibliotecas 0.9 exigem. Veja Ambiente dedicado.

15 de outubro de 2026

• Todos os realms, em todo lugar. Com Todos os realms no seletor de realm, cada lista lê e conta os registros de todos os realms que você administra, e o painel, o suporte e as notificações acompanham o realm escolhido. Veja o tour pelo console.

14 de outubro de 2026

• Registro dinâmico de clients (RFC 7591). Um realm pode deixar clients se registrarem sozinhos, desligado por padrão, para clientes MCP que não podem ser cadastrados por você nem publicar um documento de metadados. Veja MCP e o endpoint de registro.
• Access tokens do tipo `at+jwt`. Os access tokens levam typ at+jwt no cabeçalho, como pede a RFC 9068, e um ID token ou refresh token assinado pelas mesmas chaves nunca passa por um. Veja validar tokens.
• Mensalidade, franquia e excedente. Cada plano é uma mensalidade fixa que inclui usuários ativos no mês e tokens de máquina, e cada unidade além da franquia é cobrada pelo preço de excedente do plano. Veja planos e cobrança.
• Segredos de assinatura dos webhooks. Ao girar um segredo, o anterior pode continuar valendo por um tempo, e os endpoints de um realm também recebem os eventos user_* de todas as pessoas do realm. Veja girar o segredo de assinatura e endpoints de client e de realm.
• Notificações no seu idioma. Cada notificação aparece no idioma de quem a lê, o e-mail dela sai no idioma do dono da conta, e o webhook de notificações ganha key e arguments. Veja notificações e webhooks de notificações.
• Códigos de erro. Cada regra de validação da API administrativa responde com um errorCode próprio. Veja códigos de erro.

13 de outubro de 2026

• Aplicativo autenticador como etapa do login. Os seus usuários podem responder ao segundo fator com um código do Google Authenticator, do Microsoft Authenticator ou de qualquer app TOTP, com códigos de recuperação. Veja aplicativo autenticador.
• Escopos que exigem atribuição. Um escopo pode ficar restrito às pessoas e aos grupos a quem foi atribuído, como acontece com um papel. Veja escopos que exigem atribuição.
• Duas configurações de assinatura. O access token tem um algoritmo de assinatura próprio, separado do ID token, e HS256, HS384 e HS512 são assinados com o client secret, como pede o OpenID Connect. Veja assinatura de tokens.
• `RSA-OAEP-256` por padrão. Tokens criptografados usam RSA-OAEP-256 como algoritmo de cifra da chave, a menos que o client escolha outro. Veja criptografia de tokens.
• Um envelope de resposta só. Toda resposta da API administrativa, de sucesso ou de erro, vem no mesmo envelope. Veja a API administrativa.

12 de outubro de 2026

• Portal de suporte. Abra um chamado sobre qualquer coisa que o console mostra, inclusive um request que falhou, e acompanhe a resposta pelo console. Veja suporte.
• Avaliação no plano escolhido. O período de avaliação é uma assinatura de verdade do plano escolhido no cadastro, sem pedir cartão, e cada plano define a duração da própria avaliação. Veja o período de avaliação.
• A introspecção devolve todas as claims. A introspecção de um token ativo traz todas as claims que o access token carrega, inclusive o nome e o e-mail da pessoa e o que os mapeadores de claims acrescentaram. Veja introspecção.

11 de outubro de 2026

• Proteção contra ataques. Todo realm detecta credential stuffing, password spraying, força bruta, push bombing e abuso da recuperação de senha e reage sozinho, e um analista de IA lê cada incidente nos planos com o assistente de IA. Veja proteção contra ataques.
• Entrar com nome de usuário, e-mail ou os dois. Um realm decide o que as pessoas digitam para entrar. Veja nomes de usuário.
• Um código no e-mail de redefinição. O e-mail de redefinição de senha também traz um código de 6 dígitos, que continua a redefinição na aba em que ela foi pedida. Veja redefinição de senha.
• Sem crédito de boas-vindas. Contas novas começam no período de avaliação e não recebem crédito. Veja crédito de boas-vindas.

9 de outubro de 2026

• Tokens criptografados com a chave do próprio client. Um client pode ter os tokens criptografados com uma chave só dele. Veja criptografia de tokens.
• UserInfo como JWT. O endpoint de UserInfo pode responder com um JWT assinado ou criptografado quando o client registra isso. Veja UserInfo como JWT.

Próximos passos