Pular para o conteúdo

Autenticação multifator

Peça um segundo fator depois do primeiro: um código por e-mail, uma aprovação no app do Authio ou uma passkey, e faça step-up quando a aplicação precisar de mais.

No Authio, multifator não é um interruptor na conta: ele vem das etapas do login que cada client pede. Coloque uma etapa de segundo fator depois da primeira e o login hospedado a pede, pulando qualquer fator que o login já tenha apresentado.

Esta página explica os três segundos fatores, quando cada um é pedido, o app Authio Authenticator que responde às aprovações por push, o que fazer quando um celular se perde e como a sua aplicação pede um login mais forte.

Os segundos fatores

FatorEtapaO que a pessoa fazRegistrado em amr
Código de uso único por e-mailmfaDigita o código de 6 dígitos enviado ao e-mail da conta.otp
Aprovação por pushpushToca, no app do Authio, o número mostrado na tela de login.mca, mais user quando o celular verificou a pessoa
PasskeypasskeyDesbloqueia uma passkey com a digital, o rosto ou o bloqueio de tela do dispositivo.swk, mais user quando o dispositivo verificou a pessoa
Não existe etapa por SMS. O app do Authio também guarda códigos temporários (TOTP) de outros serviços, mas esses códigos não são uma etapa do login hospedado.

Quando o segundo fator é pedido

Quem decide são as etapas do client, na ordem em que estão listadas. A primeira etapa capaz de responder ao fator ainda devido é a que aparece:

EtapaPedida de
mfaTodo login que chega até ela. A etapa não pode ser Opcional: um código que pode ser pulado não é fator nenhum.
push, PreferencialContas com celular pareado. As demais recebem a oferta de parear um, a menos que o cadastro seja Nunca.
push, ObrigatóriaToda conta. Quem não tem celular precisa parear antes de continuar, então o cadastro precisa permitir isso.
passkey, PreferencialContas que já cadastraram uma passkey. Veja Passkeys.
passkey, ObrigatóriaToda conta.
Qualquer etapa, OpcionalNinguém, a menos que um pedido de autorização peça um nível maior com acr_values (veja step-up).

Um login por provedor de identidade conta como um fator, faça o provedor o que fizer do lado dele, e as etapas de segundo fator do client valem depois dele. O single sign-on para outro client só é oferecido quando não falta nada do que aquele client exige.

Código de uso único por e-mail

Depois do primeiro fator, o Authio envia um código de 6 dígitos ao e-mail da conta e a tela mostra seis caixas de dígito, preenchidas pelo preenchimento automático de códigos do navegador quando ele existe. Não recebeu o código? Reenviar envia um novo.

  • O mesmo código é entregue a todo celular pareado com a conta, onde o app do Authio o mostra como Seu código de acesso. O código nunca viaja na notificação: o app o busca por uma conexão autenticada enquanto ele vale.
  • Um código errado conta para o bloqueio do realm e fica registrado no log de acesso.
  • Depois do código certo, a conta é verificada de novo — situação, suspensão, acesso ao client, endereço de origem — antes de a sessão abrir.

Aprovação por push

A aprovação por push usa o app Authio Authenticator para iOS e Android, chamado de “app do Authio” nas telas de login. Ele se defende da fadiga de push — alguém que já tem a senha disparando pedidos até a vítima aprovar um só para o celular parar — com a correspondência de número:

  1. A tela mostra um número

    Depois do primeiro fator, a tela de login mostra Toque neste número no app do Authio com um número de dois dígitos e fica esperando.

  2. Todos os celulares pareados são perguntados

    Cada celular da conta recebe uma notificação. O app mostra a aplicação, o endereço IP e o navegador da tentativa, e três números.

  3. A pessoa toca no número igual

    Tocar no número é a aprovação. O app pede a biometria ou o bloqueio de tela, quando o celular tem um, e assina a resposta com uma chave criada no pareamento. Não fui eu recusa o pedido.

  4. O login segue sozinho

    A tela vê a resposta e continua. O Authio relê no servidor o pedido aprovado antes de concluir o login; nada que o navegador envie é tomado como prova.

RegraValor
Validade de um pedido2 minutos
Números oferecidos no celularTrês números distintos de 10 a 99
Tocar no número erradoRecusa o pedido, sem segunda tentativa
Pedidos por contaNo máximo 10 em 5 minutos, contados por conta e não por IP
Vários celulares pareadosTodos recebem o mesmo número; a primeira resposta decide
AprovaçãoAceita só com assinatura válida da chave do próprio celular

Enquanto espera, a tela oferece Perguntar de novo ao meu celular, que envia um pedido novo com número novo, e Usar outro jeito de entrar sempre que outra etapa do client puder responder, como o código por e-mail. Uma notificação que não chega não trava o login: o app também encontra os pedidos pendentes quando é aberto.

Parear um celular

O pareamento é sempre iniciado pelo titular da conta, em um destes dois lugares:

  • Durante o login, quando a etapa push oferece ou exige cadastro: a tela mostra Configure o seu celular com um QR code para ler no app, e Não consegue escanear? revela o mesmo conteúdo como uma linha para colar. Com o cadastro Oferecer, Configurar depois pula o pareamento.
  • Pelas páginas da conta, na aba App do Authio, com Mostrar o código de pareamento. Veja Autoatendimento da conta.

Um código de pareamento vale uma vez, por 5 minutos, e mostrar um novo aposenta o anterior. Uma conta pode ter até 5 celulares ativos.

Celular perdido ou sem acesso ao fator

  • Na tela de login, Usar outro jeito de entrar passa para o código por e-mail quando o client também tem a etapa mfa.
  • Quando uma passkey é devida e não está no dispositivo, a tela oferece enviar um código por e-mail no lugar. Veja Passkeys.
  • A pessoa remove um celular perdido na aba App do Authio das páginas da conta, ou por outro celular pareado. Um celular removido para de aprovar qualquer coisa na hora.
  • Um administrador o remove na aba Credenciais do usuário, em Usuários, ou em Autenticador push.

Celulares são revogados, nunca apagados, então o histórico do que cada um aprovou continua legível. Usar de novo um celular revogado exige parear outra vez.

Step-up pela sua aplicação

O ID token diz como a pessoa entrou: amr lista os métodos, acr resume tudo num nível e auth_time diz quando. Um single sign-on informa o login original, nunca um novo.

acrSignificadoExemplo
1Um fatorUma senha; um login pelo Google
2Mais de um fatorSenha e código por e-mail; Google e aprovação por push
3Multifator em que um dos fatores resiste a phishingUma passkey verificada pelo dispositivo, sozinha ou depois da senha

Quando uma ação precisa de mais do que a sessão atual prova, mande a pessoa de novo ao endpoint de autorização com o que você precisa:

  • acr_values=2 ou acr_values=3 pede um nível. Quando as etapas do próprio client não chegam lá, uma etapa Opcional de segundo fator que a conta consegue responder é pedida como se fosse Preferencial.
  • max_age=300 pede um login de no máximo cinco minutos atrás.
  • prompt=login pede as credenciais de novo, qualquer que seja a sessão.
Pedido de step-upTexto simples
https://authio.api.hyperio.tech/realms/acme/protocol/openid-connect/auth
  ?client_id=acme-web
  &response_type=code
  &redirect_uri=http://localhost:3000/api/auth/callback/authio
  &scope=openid profile email
  &state=STATE
  &code_challenge=CODE_CHALLENGE
  &code_challenge_method=S256
  &acr_values=2
  &max_age=300

acr_values nunca recusa um login

O pedido é de melhor esforço, como o OpenID Connect o define. Um nível que o client ou a conta não alcançam não é cobrado: o login termina com o que provou e o token diz o nível atingido. A conferência é sua.
step-up.tsTypeScript
interface SignInClaims {
  acr?: string
  auth_time?: number
}

export function isStrongEnough(
  claims: SignInClaims,
  minimumAcr: number,
  maxAgeSeconds: number,
): boolean {
  const level = Number(claims.acr ?? '0')
  const ageSeconds = Math.floor(Date.now() / 1000) - (claims.auth_time ?? 0)

  return level >= minimumAcr && ageSeconds <= maxAgeSeconds
}

Acompanhar a aprovação por push

Autenticador push, no console, mostra para um realm ou para todos cada pedido enviado a um celular e como ele terminou — aprovado, recusado, sem resposta ou nunca entregue —, com tempos de resposta, as aplicações mais ativas e os celulares pareados, inclusive os revogados e os que não podem ser notificados. Pedidos que nunca chegaram a um celular ganham destaque, porque nem a pessoa nem o administrador perceberiam de outra forma.

Próximos passos

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