Plataforma de autenticação corporativa
Entregue autenticação,
não infraestrutura
OAuth2, OpenID Connect, passkeys e identidade multi-tenant para o seu produto e para os agentes de IA que o usam. Primeiro token em minutos.
Toda conta começa com um teste grátis. Sem cartão de crédito, e você entra no console na hora.
Bem-vindo de volta!
Acompanhe a atividade dos seus realms, clientes e usuários de relance.
Distribuição por realm
- vertexa-prod: 12
- vertexa-staging: 9
- partner-hub: 7
- mobile-apps: 5
- internal: 3
- vertexa-prod: 128
- vertexa-staging: 86
- partner-hub: 64
- mobile-apps: 41
- internal: 18
Status dos realms
- Ativo: 9 (75%)
- Inativo: 3 (25%)
Realms recentes
- Ativo
vertexa-prod
12 clientes · 128 usuários · criado há 2 meses
- Ativo
partner-hub
7 clientes · 64 usuários · criado há 3 semanas
- Inativo
mobile-apps
5 clientes · 41 usuários · criado há 5 dias
Padrões que o Auth.io implementa
Construído sobre especificações públicas
OAuth 2.0
RFC 6749
OpenID Connect
Core 1.0
JSON Web Token
RFC 7519
PKCE
RFC 7636
JSON Web Key Set
RFC 7517
Server Metadata
RFC 8414
Introspection
RFC 7662
Revocation
RFC 7009
Device Authorization
RFC 8628
Token Exchange
RFC 8693
Resource Indicators
RFC 8707
Passkeys
WebAuthn L2
Cada endpoint segue a especificação publicada. Você pode conferir tudo contra a RFC antes de criar uma conta.
Um portal feito para times de identidade
Seis telas, uma olhada. Cada card abaixo é montado com os componentes reais do produto, renderizados com dados representativos.
Gráficos que respondem perguntas de segurança
Atividade de acesso ao longo do tempo, distribuição de grant types e recortes de ambiente por realm: dispositivos, navegadores e principais IPs.
Análise de acessos
Tráfego, grant types e recortes de ambiente para cada realm.
Atividade de acesso
- 08: 42
- 09: 88
- 10: 134
- 11: 121
- 12: 96
- 13: 84
- 14: 128
- 15: 156
- 16: 148
- 17: 117
- 18: 74
- 19: 51
- Sucesso: 1.239 (96%)
- Falhou: 48 (4%)
Grant types
- Password Login1.289
- Token Refresh704
- Authorization Code458
- Client Credentials261
- API Key135
Dispositivos
- Desktop1.892
- Mobile743
- Tablet212
Navegadores
- Chrome1.521
- Safari634
- Firefox388
- Edge304
Principais IPs
- 187.44.120.8402
- 34.201.10.77288
- 52.67.190.14173
- 191.36.8.20196
Toda tentativa de acesso, registrada
Todo token emitido, e todo token bloqueado, vira um evento de auditoria com o contexto completo: quem, de onde e por que falhou.
Auditoria e inteligência de acesso
4.531 eventos registrados
Eventos de acesso recentes
Password Login
há 2 min
187.44.120.8Chrome 126Windows 11Client Credentials
há 8 min
34.201.10.77Token Refresh
há 15 min
52.67.190.14Safari 17macOS 15Password Login
há 23 min
191.36.8.201Firefox 128Ubuntu 24.04Credenciais inválidas, conta bloqueada após 5 tentativas
Tudo de relance
Realms, clientes, usuários e cobrança em um único centro de comando, atualizado em tempo real.
Bem-vindo de volta!
Acompanhe a atividade dos seus realms, clientes e usuários de relance.
Distribuição por realm
- vertexa-prod: 12
- vertexa-staging: 9
- partner-hub: 7
- mobile-apps: 5
- internal: 3
- vertexa-prod: 128
- vertexa-staging: 86
- partner-hub: 64
- mobile-apps: 41
- internal: 18
Status dos realms
- Ativo: 9 (75%)
- Inativo: 3 (25%)
Realms recentes
- Ativo
vertexa-prod
12 clientes · 128 usuários · criado há 2 meses
- Ativo
partner-hub
7 clientes · 64 usuários · criado há 3 semanas
- Inativo
mobile-apps
5 clientes · 41 usuários · criado há 5 dias
Detalhes de identidade com contexto
Veja informações de usuário, realm e papel com sinais de segurança em um só lugar.
Gestão de usuários
Busque, inspecione e gerencie identidades em todos os realms.
Usuários
Sofia Almeida
sofia@vertexa.io
vertexa-prod3 papéisAtivoúltimo acesso há 2 minMarcos Ribeiro
marcos@vertexa.io
vertexa-prod2 papéisAtivoúltimo acesso há 15 minJulia Castro
julia@partner.co
partner-hub1 papelPendenteúltimo acesso nuncaDaniel Souza
daniel@vertexa.io
vertexa-staging4 papéisAtivoúltimo acesso há 1 hora
Ciclo de vida das chaves em escala
Inventário de chaves ativas e revogadas com rotação, pronto para auditoria.
Chaves de segurança
Material de assinatura e criptografia por cliente, com rotação.
RS256
AtualChave RSA · SIG
8f2c1a9e-77b4-4f10-9d3a-2b6f0c4e8a51Criada em 12 de jun. de 2026
ES256
Chave EC · SIG
c41d7b02-3e88-45c6-b7f9-91a2d5e6c3f0Criada em 30 de mai. de 2026
RS256
Chave RSA · ENC
a93f5e17-6c02-49d8-8b41-f07c3a9d2e64Criada em 2 de mai. de 2026
RS256
Chave RSA · SIG
5d80b6c3-19af-4e72-a0c5-84e1f2b7d9a3Criada em 18 de fev. de 2026
Controles de segurança onde eles importam
Centralize segredos de API, exigências de autenticação e configuração de token em um único fluxo para cada cliente.
- Segredos com escopo, expiração e acompanhamento de uso
- Exigência de PKCE e de autenticação do cliente
- Ajustes de emissor, audiência e TTL do token
Segredos de API
Credenciais de máquina com escopo, expiração e acompanhamento de uso.
Segredos ativos
production-api
sk_live_9f2a••••••••••••api:readapi:writeExpira em 1 de dez. de 2026usado há 4 minci-pipeline
sk_live_c7d1••••••••••••api:readExpira em 1 de out. de 2026usado há 1 horalegacy-integration
sk_live_04be••••••••••••api:readusers:readExpira em 12 diasusado há 2 dias
Autenticação do cliente
Configuração de token
Emissor
https://auth.authio.com/realms/vertexa-prodAudiência
api://vertexa-platformUm realm é uma parede, não um filtro.
Usuários, clientes e chaves de assinatura pertencem a exatamente um realm. Um token emitido em um realm não é validado em outro.
Chaves de assinatura separadas
Cada realm publica o próprio JWKS. É aí que o limite é aplicado, em todo token que você valida.
Clientes separados
IDs de cliente, segredos e URIs de redirecionamento pertencem ao realm que os criou.
Uma conta, uma fatura
Realms não compartilham nada além da conta que recebe a fatura.
Como um token é emitido e como ele continua válido.
Três momentos: o desafio, a troca e a chave que sobrevive à própria rotação.
O verificador nunca sai do seu app
Seu app envia um desafio e guarda o verificador. Um código interceptado na volta não vale nada sem ele.
- 4 grant types OAuth2
- Suporte a PKCE (S256, Plain)
- Discovery OIDC & JWKS
Uma troca, um token assinado
O código e o verificador voltam juntos. O Auth.io assina o token, registra o evento e entrega.
- Assinado com RS256
- Toda emissão é auditada
- Seu app envia o usuário ao Auth.io com um code challenge e guarda o verificador.
- O Auth.io devolve um código de vida curta.
- Seu app troca o código junto com o verificador.
- O Auth.io devolve um access token assinado, válido por 3600 segundos.
- Seu app chama sua API com o token como credencial Bearer.
- Sua API valida a assinatura contra as chaves públicas do realm em cache, sem chamar o Auth.io de volta.
A rotação não quebra tokens em circulação
A chave que sai de uso continua publicada no JWKS até o último token que ela assinou expirar. Sua API continua validando localmente o tempo todo.
- Validado contra o JWKS
- Sem chamada de volta ao Auth.io
fora de escala
- kid 8f2c1a9e: publicada, não assina mais
- kid c41d7b02: assinando
- kid 5d80b6c3: publicada
- Seu app envia o usuário ao Auth.io com um code challenge e guarda o verificador.
- O Auth.io devolve um código de vida curta.
- Seu app troca o código junto com o verificador.
- O Auth.io devolve um access token assinado, válido por 3600 segundos.
- Seu app chama sua API com o token como credencial Bearer.
- Sua API valida a assinatura contra as chaves públicas do realm em cache, sem chamar o Auth.io de volta.
fora de escala
- kid 8f2c1a9e: publicada, não assina mais
- kid c41d7b02: assinando
- kid 5d80b6c3: publicada
Dê acesso aos agentes de IA, não às suas senhas.
O Auth.io é o servidor de autorização dos seus servidores MCP. Os agentes o encontram sozinhos, fazem o login da pessoa e recebem um token que só vale onde foi pedido.
- 1Agente de IA → Servidor MCPPOST /mcp, sem token
- 2Servidor MCP → Agente de IA401 · resource_metadata
- 3Agente de IA → Auth.iologin com PKCE + resource
- 4Auth.io → Agente de IAtoken, aud = o servidor MCP
- 5Agente de IA → Servidor MCPchamada com Bearer
- 6Servidor MCP → Auth.iointrospecção: ainda ativo?
- 7Servidor MCP → Auth.iotoken exchange para github
- 8Auth.io → Servidor MCPo token do GitHub da pessoa
- 9Servidor MCP → GitHubGET /user/repos
- 10Servidor MCP → Agente de IAresultado da ferramenta
- POST /mcp, sem token
- 401 · resource_metadata
- login com PKCE + resource
- token, aud = o servidor MCP
- chamada com Bearer
- introspecção: ainda ativo?
- token exchange para github
- o token do GitHub da pessoa
- GET /user/repos
- resultado da ferramenta
RFC 9728 · RFC 8414
Descoberta sem configuração
Os metadados do recurso levam o agente aos metadados do servidor do seu realm. Nada para configurar no cliente.
RFC 8707
Tokens com endereço
A audiência do token é o servidor MCP para o qual ele foi pedido. Qualquer outro servidor recusa.
RFC 7662
Revogação que chega aos agentes
A introspecção diz se o token ainda está ativo, então encerrar uma sessão para as ferramentas, não só os navegadores.
RFC 8693
Contas conectadas
GitHub e outros provedores são conectados uma vez por pessoa. Os servidores trocam por um token de vida curta e nunca veem um refresh token.
Conecte qualquer cliente MCP que fale OAuth
Cadastre o servidor MCP como resource server, libere o client do agente e conecte. O uso é auditado por servidor, por pessoa e por client, e licenciado por plano.
claude mcp add --transport http \
--client-id your-mcp-client \
my-tools https://mcp.example.com/mcpFeito para todos os casos de uso
Filtre por área para ver como o Auth.io se encaixa na sua arquitetura.
Autorização para MCP
Proteja servidores MCP como resource servers: descoberta, tokens com audiência e introspecção, por realm.
Contas conectadas
Um cofre para os tokens do GitHub e de outros provedores de cada pessoa, trocados sob demanda pelo servidor MCP que precisa deles.
OAuth2 & OIDC
Grants Authorization Code, Password, Refresh Token e Client Credentials.
Passkeys
Login com WebAuthn resistente a phishing, como segundo fator ou sem senha nenhuma.
Segundo fator
Códigos de autenticador e aprovação por push num dispositivo cadastrado, configurados por client.
Isolamento de realms
Separação total entre tenants, com realms independentes para dados e configuração.
Federação de identidade
Google, Entra ID, GitHub ou qualquer provedor OIDC, com papéis mapeados a partir das claims que eles enviam.
Organizações
Clientes B2B dentro de um realm, roteados pelo domínio de e-mail reivindicado e levados no token.
Chaves de token personalizadas
Chaves de assinatura e criptografia por cliente, com controle total da configuração.
Device flow
Login em TVs, ferramentas de linha de comando e quiosques com um código curto digitado em outro dispositivo.
Delegação e impersonação
Concessões em nome de alguém sempre mais estreitas, e sessões de suporte como o usuário com auditoria.
Mapeadores de claims
Defina o que os tokens de cada client carregam, com rascunho escrito pelo consultor a partir de uma frase e revisão em diff.
Gestão de usuários
Controle de acesso por papel para cada usuário, cliente e realm, com permissões detalhadas.
Gestão de sessões
Acompanhe e gerencie sessões e tokens ativos pelo portal.
Política de rede
Listas de IPs permitidos por client e por usuário, com aprovação para logins vindos de um lugar novo.
Consultor de IA
Revisa a configuração de cada client, explica logins que falharam e propõe mudanças que você aprova.
Webhooks
Eventos assinados por realm e por client, com registro de entregas, novas tentativas e reenvio.
Migração
Importe usuários do Keycloak, Auth0, Cognito e Okta, com uma checagem prévia antes de gravar qualquer coisa.
Tela de login personalizada
Aplique a sua marca às telas de autenticação hospedadas.
Integração com NextAuth
Integração OIDC direta com o NextAuth para aplicações modernas.
Gestão de clientes
Ciclo de vida completo do cliente, com configuração independente por aplicação.
Logs de auditoria
Toda tentativa de acesso registrada com dispositivo, navegador, IP e contexto da falha.
Análise de acessos
Linhas do tempo de atividade, distribuição de grant types e recortes de ambiente por realm.
Inspetor de tokens
Decodifique e verifique um JWT no portal, sem sair do realm que o emitiu.
Preço por uso
Pague apenas por logins bem-sucedidos e sessões ativas, cobrados via Stripe.
Mostrando 25 capacidades
Cada fluxo, desenhado antes de você criar a conta.
As perguntas que times de identidade fazem na primeira conversa, respondidas com desenhos do que o Auth.io faz de verdade.
Login com os provedores de identidade dos seus clientes
Google, Entra ID, GitHub ou qualquer provedor OIDC, por realm. Você decide em qual conta a pessoa entra, e um e-mail só vincula contas enquanto o provedor for confiável para tê-lo verificado.
- O provedor responde com um identificador de sujeito e um endereço de e-mail.
- O modo de vínculo decide em qual conta essa chegada cai.
- Vincular por endereço verificado depende de este provedor ser confiável para ele; sem essa confiança nada é vinculado, e a chegada é tratada como criação de conta.
- As regras de papel rodam depois, e decidem só o que a conta resolvida pode fazer.
Integre em minutos
Trechos prontos para copiar e colar nos fluxos de autenticação mais comuns.
import NextAuth from "next-auth"
export const { handlers, signIn, signOut, auth } = NextAuth({
providers: [
{
id: "authio",
name: "Auth.io",
type: "oidc",
issuer: process.env.AUTHIO_ISSUER,
clientId: process.env.AUTHIO_CLIENT_ID,
clientSecret: process.env.AUTHIO_CLIENT_SECRET,
authorization: {
params: { scope: "openid profile email" }
}
}
]
}){ "exp": 1774170000, "iat": 1774166400, "auth_time": 1774166400, "jti": "0b9d3a5e-1c48-4f27-9a63-84e0d7f2b615", "iss": "https://auth.authio.com/realms/vertexa-prod", "aud": "vertexa-web", "sub": "9c4f2b71-0d3a-4f88-b0d2-5a1e7c6d4e10", "typ": "ID", "azp": "vertexa-web", "sid": "6f1b0c4d-2e77-4a91-8f30-c25d9b3a7e02", "acr": "1", "email_verified": true, "scope": "openid profile email"}- iss
- O realm de onde este token veio. Confira em toda requisição.
- sub
- O id estável da pessoa que entrou.
Substitua {realm}, YOUR_CLIENT_ID e YOUR_CLIENT_SECRET pelos valores do seu painel.
O consultor de IA propõe. Você aplica.
O Auth.io lê como um client está configurado e como andam as autenticações dele, e então diz o que mudar. Ele não lê nenhuma configuração sua até você ligar, não altera nada em que você não tenha clicado em Aplicar, e não fica em lugar nenhum do caminho de login.
O que ele devolve
Uma revisão lê a configuração de um client e a atividade de autenticação dele num período que você escolhe — trinta dias, a menos que você diga outra coisa, e no máximo noventa — e volta com achados: o que ele notou, por que aquilo importa e o que mudar. O que chega é um parágrafo para você ler, não uma ação já tomada.
- Achados
- O que a revisão de um client encontrou, do pior para o menos grave, cada um citando a configuração de que trata.
- Mudanças propostas
- Valor atual ao lado do valor proposto, sobre dezesseis configurações, com Aplicar e Desfazer nas suas mãos.
- Destaques
- Uma leitura sobre os realms para os quais você ligou, e que diz quantos ela não teve permissão de ler.
- Causas
- Por que as autenticações deste client estão falhando, com os motivos de falha contados logo abaixo, para você conferir a resposta.
Quatro das treze. As outras nove respondem dentro da tela onde a pergunta aparece: uma frase digitada no lugar de um filtro de auditoria, um questionário de segurança respondido a partir da sua configuração real, um token lido contra o caso de uso que você descrever, um guia de integração para uma stack para a qual não publicamos guia.
Os access tokens duram mais que a sessão que os emitiu
Na sua configuração
Os access tokens deste client duram 720 minutos. A sessão a que eles pertencem dura 60. De 39.004 tentativas de autenticação nos últimos 30 dias, 38.412 usaram o grant de refresh token.
Por que isso importa
Um token que continua válido por doze horas não pode ser revogado por doze horas. Encerrar a sessão de alguém deixa todos os access tokens já emitidos para essa pessoa funcionando até expirarem sozinhos.
O que mudar
Reduza a vida do access token para 15 minutos e deixe o refresh token sustentar a sessão. Este client já faz refresh, então ninguém precisa entrar de novo.
Antes de ligar
- O que sai daqui
- O retrato é montado um campo por vez, então uma configuração só chega ao consultor porque alguém a colocou lá pelo nome. Onde um valor não pode ser mostrado, o que se mostra é o que dá para concluir sobre ele: uma chave de assinatura contribui com a idade que tem e se já passou da hora de rotacionar, nunca com o material dela.
Sai para análise
- As configurações de protocolo, de token e de senha deste client
- A idade das chaves e dos secrets dele
- Os sucessos e as falhas de autenticação, somados
Nunca sai
- Secrets de client
- Senhas e hashes de senha
- Material de chave privada
- Credenciais de máquina e API keys
- Qualquer coisa que identifique um usuário seu
Nada disso é retirado do que é enviado. Nada disso chega a ser colocado. Os números de autenticação são contagens que o próprio banco calculou, e nenhuma linha do log de acesso é lida em momento algum, então um endereço, um nome de usuário ou uma mensagem de erro não têm de onde ser removidos.
- Para onde vaiclaude-haiku-4-5
- Um provedor, o Claude da Anthropic, alcançado a partir de um único arquivo. Toda capacidade roda no modelo abaixo, a menos que uma instalação nomeie outro. A instrução fixa é byte a byte a mesma para todas as contas, porque o que é da sua conta viaja no pedido e nunca na parte que fica em cache.
- O que ele pode alterar
- Uma capacidade entre as treze que chamam um modelo consegue escrever num client, e só quando você clica em Aplicar numa proposta que leu — não existe caminho no produto que aplique uma proposta sozinho. A escrita passa pela mesma rota validada e auditada que a sua própria edição usa, sobre uma lista fixa de dezesseis configurações que não inclui secrets de client nem redirect URIs, e o valor que cada configuração tinha antes fica registrado para poder voltar. Se o client mudou enquanto a proposta estava parada, Aplicar é recusado em vez de resolvido por você.
Três das dezesseis
- Protocol.PkceRequired
- TokenPolicy.AccessTokenLifetimeMinutes
- Lockout.MaxFailedAccessAttempts
- Quem liga isso
- Ler a configuração de um client fica desligado até alguém da sua conta ligar, por realm ou por client. A decisão do próprio client vence nas duas direções: ele pode ser lido dentro de um realm que recusou, e ficar de fora de um que aceitou. Quatro coisas ficam fora dessa chave, e estão nomeadas aqui porque você acabaria descobrindo. Transformar uma frase digitada em filtro de auditoria envia os nomes dos seus realms e clients, para que a frase tenha contra o que ser casada. Uma resposta da documentação envia apenas os trechos que o console já tinha. Uma leitura de token envia o formato ao qual o seu navegador reduziu o token, e o servidor recusa o pedido inteiro se alguma coisa nele ainda parecer um token. Uma conferência de importação envia contagens. Nenhuma das quatro envia configuração.
- O que uma execução custa
- Isto é limitado duas vezes: uma cota de execuções no seu plano, contada por mês do calendário em UTC e não por ciclo de cobrança, e um limite de requisições por minuto abaixo dela. Uma revisão de client, uma proposta de configuração e uma leitura do painel gastam uma execução dessa cota cada. O console lê o número que mostra do mesmo lugar de onde a plataforma lê quando recusa uma execução, então o número que você vê e o número ao qual você está preso não podem discordar. Um plano que não nomeia teto não tem teto.
- Desligando
- Retirar o consentimento é registrado, não apagado, então “nunca foi perguntado” e “foi perguntado e recusado” continuam sendo respostas diferentes. Desfazer uma proposta que foi aplicada, de propósito, não depende de o consentimento continuar ligado, para que desligar o consultor não deixe você preso a uma alteração que ele fez. E onde uma instalação não configurou credencial nenhuma de provedor, cada um destes endpoints recusa na hora de pedir, em vez de aceitar um trabalho que nunca vai fazer.
Nada disso fica no caminho do login. Cada um destes endpoints vive sob a API de administração: não no endpoint de token, não na tela de login, e não em nada que os seus usuários toquem.
Como se entra, e como se sai.
As duas perguntas que ninguém faz antes de já estar preso a um fornecedor.
- Migração de entrada
- Importe um export do Keycloak, do Auth0, do Cognito ou do Okta. Realms do Keycloak com hash PBKDF2 ou Argon2id trazem as senhas junto, verificadas como estão, e essas pessoas nem percebem a mudança. O mesmo vale para um export do Auth0 que traga os hashes bcrypt. Cognito e Okta não liberam material de credencial nenhum, então esses chegam exigindo redefinição de senha.
- Levando o registro com você
- Filtre as trilhas de acesso e de alterações por data, realm, client ou resultado, e exporte exatamente esse recorte em CSV. É a mesma trilha que um auditor pede.
O seu próprio Authio, em infraestrutura só dele
No plano Dedicado, o Authio provisiona um ambiente completo só para a sua conta — API, console, banco de dados e cache próprios — e o seu console passa a ser o lugar de acompanhar e operar esse ambiente.
- Criar o projeto
- Criar o banco de dados
- Criar o cache
- Criar a API
- Criar o console
- Atribuir os endereços
- Configurar as variáveis
- Fazer o deploy
- Esperar até responder
- Enviar o e-mail de boas-vindas
- Nada compartilhado
- API, console, PostgreSQL e Redis próprios, em um projeto em que nenhum outro cliente roda.
- Provisionado quando você paga
- O pagamento dá início à montagem. O seu console mostra cada etapa conforme ela termina, e você recebe um e-mail quando o ambiente fica pronto.
- No seu domínio
- Acesse-o pelos endereços próprios dele desde o início e leve-o para um domínio seu com poucos registros de DNS.
- Acompanhado e operado pelo seu console
- CPU, memória, rede e disco por serviço, uso e logs — e reinicie, reimplante ou pare qualquer serviço quando precisar.
- Refeito em um passo
- Remova um ambiente ou recrie-o do zero, mesmo um que travou ou falhou.
- Preservado quando o pagamento falha
- Uma assinatura vencida suspende o ambiente e guarda os dados dele por 30 dias, com um lembrete uma semana antes de qualquer exclusão.
Preço que cresce com você
A cobrança é uma vez por autenticação bem-sucedida. Renovações de token e tentativas que falharam dentro de uma sessão não são cobradas.
O que conta como um evento cobrado
Uma autenticação bem-sucedida abre uma sessão e é contada uma vez. Tudo o que acontece dentro dessa sessão é gratuito.
- login bem-sucedido: contado uma vez
- client credentials: contado uma vez
- renovação de token: não contado
- tentativa que falhou: nunca contado
Carregando os planos...
Perguntas frequentes
Tudo o que você precisa saber sobre o Auth.io.
O Auth.io suporta 4 grant types OAuth2: Authorization Code, Password, Refresh Token e Client Credentials. Também oferecemos suporte completo a OIDC com integração ao NextAuth.js.
Cada realm oferece isolamento total entre tenants, com configurações, usuários e clientes independentes. Você pode criar vários realms para separar ambientes ou clientes diferentes, cada um com as próprias regras de autenticação.
Sim! Cada cliente pode ter as próprias chaves de assinatura e criptografia. Você tem controle total sobre o tempo de vida dos tokens, as políticas de refresh token e as claims personalizadas pelo painel.
Você paga apenas por logins bem-sucedidos e sessões ativas. A cobrança é calculada por evento de autenticação (login com senha ou grant client_credentials). Tentativas que falham e refreshes de token não são cobrados.
Um ambiente do Authio só para a sua conta: API, console, PostgreSQL e Redis próprios, provisionados automaticamente assim que você paga. Ele não tem trial — o pagamento vem antes do primeiro login — e o seu console passa a ser o lugar de acompanhar e operar o ambiente: métricas, logs, implantações e o domínio dele.
Sim. Ele começa em endereços próprios, e você pode apontar um domínio seu para ele nas configurações de domínio do ambiente, adicionando os registros de DNS que o console mostra.
Sim. Nos planos que incluem a personalização do login, a tela de login de cada client recebe o seu layout, cores, logotipo e fundo; os planos na página de preços dizem quais incluem.
Os usuários são isolados por realm. Cada usuário pertence a um realm específico, usa as mesmas credenciais em todo ele, e só entra pelos clientes desse realm que o deixam entrar.
O portal traz interfaces completas de gestão para realms, clientes, usuários, sessões, tokens e cobrança. Você pode ver análises em tempo real, gerenciar papéis, configurar fluxos de autenticação e acompanhar sessões ativas.
Comece a construir com o Auth.io
Crie o seu realm, registre um cliente e emita o primeiro token hoje. Toda conta começa com um teste grátis, e nenhum cartão é pedido.
- Configuração em minutos
- Preço por uso
- Cancele quando quiser