Pular para o conteúdo

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.

Realms
12
9 ativos · +3 esta semana
Clientes
38
34 ativos · 29 com PKCE
Usuários
8.4K
em todos os realms
Eventos faturados
126K
US$ 114 de custo estimado

Distribuição por realm

  • vertexa-prod: 12
  • vertexa-staging: 9
  • partner-hub: 7
  • mobile-apps: 5
  • internal: 3
Clientes
  • vertexa-prod: 128
  • vertexa-staging: 86
  • partner-hub: 64
  • mobile-apps: 41
  • internal: 18
Usuários

Status dos realms

  • Ativo: 9 (75%)
  • Inativo: 3 (25%)

Realms recentes

Ver todos
  • 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

Total de eventos
4.531
eventos de acesso registrados
Bem-sucedidos
4.369
autenticações aprovadas
Falharam
162
tentativas de acesso bloqueadas
Taxa de sucesso
96%
Excelente

Eventos de acesso recentes

vertexa-prod

Password Login

há 2 min

Sucesso
Sofia Almeida
187.44.120.8Chrome 126Windows 11
26 de jul. de 2026, 10:42Ver detalhes

Client Credentials

há 8 min

Sucesso
billing-service
34.201.10.77
26 de jul. de 2026, 10:36Ver detalhes

Token Refresh

há 15 min

Sucesso
Marcos Ribeiro
52.67.190.14Safari 17macOS 15
26 de jul. de 2026, 10:29Ver detalhes

Password Login

há 23 min

Falhou
unknown@mail.com
191.36.8.201Firefox 128Ubuntu 24.04

Credenciais inválidas, conta bloqueada após 5 tentativas

26 de jul. de 2026, 10:21Ver detalhes

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.

Realms
12
9 ativos · +3 esta semana
Clientes
38
34 ativos · 29 com PKCE
Usuários
8.4K
em todos os realms
Eventos faturados
126K
US$ 114 de custo estimado

Distribuição por realm

  • vertexa-prod: 12
  • vertexa-staging: 9
  • partner-hub: 7
  • mobile-apps: 5
  • internal: 3
Clientes
  • vertexa-prod: 128
  • vertexa-staging: 86
  • partner-hub: 64
  • mobile-apps: 41
  • internal: 18
Usuários

Status dos realms

  • Ativo: 9 (75%)
  • Inativo: 3 (25%)

Realms recentes

Ver todos
  • 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.

Adicionar usuário
Total de usuários
8,412
todos os realms
Ativo
8,020
95% verificados

Usuários

Ver todos
  • Sofia Almeida

    sofia@vertexa.io

    Ativoúltimo acesso há 2 min
  • Marcos Ribeiro

    marcos@vertexa.io

    Ativoúltimo acesso há 15 min
  • Julia Castro

    julia@partner.co

    Pendenteúltimo acesso nunca
  • Daniel Souza

    daniel@vertexa.io

    Ativoú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.

Rotacionar chaves
Chaves ativas
3
em rotação
Atual
1
assinando tokens agora

RS256

Atual

Chave RSA · SIG

Ativo
8f2c1a9e-77b4-4f10-9d3a-2b6f0c4e8a51

Criada em 12 de jun. de 2026

ES256

Chave EC · SIG

Ativo
c41d7b02-3e88-45c6-b7f9-91a2d5e6c3f0

Criada em 30 de mai. de 2026

RS256

Chave RSA · ENC

Ativo
a93f5e17-6c02-49d8-8b41-f07c3a9d2e64

Criada em 2 de mai. de 2026

RS256

Chave RSA · SIG

Revogado
5d80b6c3-19af-4e72-a0c5-84e1f2b7d9a3

Criada 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.

Novo segredo

Segredos ativos

3 segredos
  • production-api

    sk_live_9f2a••••••••••••
    Expira em 1 de dez. de 2026usado há 4 min
  • ci-pipeline

    sk_live_c7d1••••••••••••
    Expira em 1 de out. de 2026usado há 1 hora
  • legacy-integration

    sk_live_04be••••••••••••
    Expira em 12 diasusado há 2 dias

Autenticação do cliente

PKCE obrigatórioS256
Segredo do clienteExigido
Política de bloqueio5 tentativas / 15 min

Configuração de token

Emissor

https://auth.authio.com/realms/vertexa-prod

Audiência

api://vertexa-platform
TTL do access token3600s

Um 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.

vertexa-prod
usuários
clientes
chaves de assinatura kid 8f2c1a9e
partner-hubseus próprios usuários, clientes e chaves
mobile-appsseus próprios usuários, clientes e chaves
uma conta, uma fatura
Três realms, desenhados lado a lado. Nada atravessa o limite.Três realms. O primeiro tem os próprios usuários, clientes e chaves de assinatura. Uma requisição dele para um cliente de outro realm é barrada no limite e rejeitada, porque cada realm valida contra as próprias chaves.

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
Auth.io
valida o desafio
assina o token
registra o evento
authorize, com desafio
código
verificador, fica aqui
código e verificador
access token, 3600s
sua API
Bearer
JWKS, em cache
Um login, desenhado como as seis requisições que ele realmente é.Um diagrama de sequência com três partes lado a lado: seu app, o Auth.io e sua API. O Auth.io é desenhado quase duas vezes mais alto que os outros dois porque carrega as três tarefas que você nunca precisa construir: validar o desafio, assinar o token e registrar o evento. Seis requisições acontecem entre os três, e o verificador permanece no seu app durante as três primeiras.
  1. Seu app envia o usuário ao Auth.io com um code challenge e guarda o verificador.
  2. O Auth.io devolve um código de vida curta.
  3. Seu app troca o código junto com o verificador.
  4. O Auth.io devolve um access token assinado, válido por 3600 segundos.
  5. Seu app chama sua API com o token como credencial Bearer.
  6. 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
kid 8f2c1a9e
publicada, não assina mais
kid c41d7b02
assinando
kid 5d80b6c3
publicada
rotação
último token expira

fora de escala

JWKS
kid 8f2c1a9e
kid c41d7b02
kid 5d80b6c3
A rotação de uma chave de assinatura, desenhada na linha do tempo em que ela acontece.Uma rotacao de chave numa linha do tempo. A chave que sai para de assinar na rotacao, mas continua publicada no JWKS ate o ultimo token que ela assinou expirar, entao os tokens ja em transito continuam validando. A chave nova assina a partir da rotacao. As duas ficam publicadas ao mesmo tempo durante a sobreposicao.
  1. kid 8f2c1a9e: publicada, não assina mais
  2. kid c41d7b02: assinando
  3. 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.

  1. 1
    Agente de IA → Servidor MCP
    POST /mcp, sem token
  2. 2
    Servidor MCP → Agente de IA
    401 · resource_metadata
  3. 3
    Agente de IA → Auth.io
    login com PKCE + resource
  4. 4
    Auth.io → Agente de IA
    token, aud = o servidor MCP
  5. 5
    Agente de IA → Servidor MCP
    chamada com Bearer
  6. 6
    Servidor MCP → Auth.io
    introspecção: ainda ativo?
  7. 7
    Servidor MCP → Auth.io
    token exchange para github
  8. 8
    Auth.io → Servidor MCP
    o token do GitHub da pessoa
  9. 9
    Servidor MCP → GitHub
    GET /user/repos
  10. 10
    Servidor MCP → Agente de IA
    resultado da ferramenta
Um agente chega a um servidor MCP protegido: descobre o Auth.io, faz o login da pessoa, e o servidor troca por um token do GitHub só quando uma ferramenta precisa.Quatro participantes lado a lado: um agente de IA, um servidor MCP, o Auth.io e o GitHub. O agente chama o servidor MCP sem token e recebe um 401 com o endereço dos metadados do servidor, que o levam ao Auth.io. O agente faz o login da pessoa no Auth.io com PKCE, informando o servidor MCP como recurso, e recebe um token cuja audiência é esse servidor. Ele chama uma ferramenta com o token; o servidor MCP pergunta ao Auth.io se o token ainda está ativo. Para chegar ao GitHub, o servidor MCP troca no Auth.io o token da pessoa pelo token do GitHub dela, chama o GitHub e devolve o resultado da ferramenta ao agente.
  1. POST /mcp, sem token
  2. 401 · resource_metadata
  3. login com PKCE + resource
  4. token, aud = o servidor MCP
  5. chamada com Bearer
  6. introspecção: ainda ativo?
  7. token exchange para github
  8. o token do GitHub da pessoa
  9. GET /user/repos
  10. 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.

Conectar um agente de códigobash
claude mcp add --transport http \
  --client-id your-mcp-client \
  my-tools https://mcp.example.com/mcp

Feito 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.

Alguém chega pelo provedor
sub — o identificador que o provedor usa para a pessoa
email — o endereço que ele diz que ela tem
Criar uma conta
Uma conta nova, vinculada a este provedor
Vincular por endereço verificado
A conta existente que tem aquele endereço
enquanto este provedor for confiável para o endereçocaso contrário nada é vinculado, como se criasse uma conta
Somente contas vinculadas
Ninguém: só entram identidades já vinculadas
Com a conta resolvida, as regras de claim do provedor decidem o que ela pode fazer.
A única decisão que registrar um provedor realmente toma: em qual conta cai quem chega por ele.Uma chegada é desenhada uma vez no topo, com o identificador que o provedor deu e um endereço de e-mail. Três desfechos pendem dela, idênticos em tudo menos no modo de vínculo configurado. Criar conta faz a chegada cair numa conta nova; vincular por endereço verificado faz cair na conta existente que tem aquele endereço, mas só enquanto o provedor for confiável para verificá-lo, e sem essa confiança nunca é vinculado, caindo como se uma conta fosse criada; negar não faz ninguém cair em lugar nenhum, já que só entra uma identidade já vinculada a uma conta. As regras de papel rodam depois que a conta está resolvida, não antes.
  1. O provedor responde com um identificador de sujeito e um endereço de e-mail.
  2. O modo de vínculo decide em qual conta essa chegada cai.
  3. 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.
  4. 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.

requisição
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" }
      }
    }
  ]
})
resposta200
{  "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.
O corpo da resposta, com os campos que você realmente precisa marcados.Integração com NextAuth.js

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.

AltaPolítica de token

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.

Um achado, desenhado como o console o desenha. O client, os números e os tempos são ilustrativos; o formato da resposta não é. Uma revisão leva até um minuto, e você pode sair e voltar depois.

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.

Ambiente dedicadoPronto
  1. Criar o projeto
  2. Criar o banco de dados
  3. Criar o cache
  4. Criar a API
  5. Criar o console
  6. Atribuir os endereços
  7. Configurar as variáveis
  8. Fazer o deploy
  9. Esperar até responder
  10. 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
renovação de token
não contado
renovação de token
client credentials
renovação de token
renovação de token
fim da sessão
tentativa que falhoutentativa que falhou
nunca contado
Uma sessão, desenhada do primeiro login até a última renovação.Uma autenticação bem-sucedida abre uma sessão e é contada uma vez. Tudo o que acontece dentro dessa sessão é gratuito.
  1. login bem-sucedido: contado uma vez
  2. client credentials: contado uma vez
  3. renovação de token: não contado
  4. 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

Cookies de analytics

Gostaríamos de medir como o console é usado, com o Google Analytics, para enxergar em quais telas as pessoas travam. Isso grava um cookie que reconhece este navegador na sua próxima visita.

Recusar não muda mais nada. Os cookies que mantêm você conectado e lembram o seu idioma e o seu tema são necessários para o console funcionar, e ficam de qualquer forma. Ler a Política de Privacidade