Fallback e recuperação de chaves de acesso: Abordagem identifier-first

1. Introdução#

As chaves de acesso (passkeys) se tornaram uma alternativa real aos métodos tradicionais de autenticação, com quase 95% dos dispositivos prontos para chaves de acesso. No entanto, mesmo os sistemas mais avançados exigem estratégias eficazes de fallback e recuperação para lidar com cenários onde as chaves de acesso não estão acessíveis (Fallback) ou até mesmo são perdidas (Recuperação). Este guia tem como objetivo explorar os vários cenários onde fallbacks e recuperações são necessários e discutir como seriam as possíveis soluções.

Ao pensar em métodos de fallback e recuperação, é importante que a força deles corresponda à do método de autenticação principal. Este guia fará a distinção entre os diferentes usos das chaves de acesso, focando particularmente em contextos onde elas são usadas como MFA autossuficiente, para adequar os métodos de fallback e recuperação apropriadamente.

Perguntas principais:

• Quais cenários de fallback existem? Quais são os possíveis cenários de fallback que podem ocorrer com sistemas de chaves de acesso e como devem ser tratados para manter a segurança?
• Como a recuperação deve ser tratada? Dependendo dos padrões de uso das chaves de acesso, particularmente em ambientes que usam MFA, como os processos de recuperação devem ser projetados para garantir que sejam seguros?

Por meio da exploração dessas questões, este guia fornecerá a gerentes de produto e desenvolvedores os insights necessários para projetar, implementar e gerenciar sistemas de chaves de acesso de forma eficaz, garantindo que a segurança não prejudique a experiência do usuário.

2. Definições: Identificador, nível de segurança, fallback e recuperação#

Antes de mergulhar nas estratégias de fallback e recuperação, é importante estabelecer um entendimento claro de alguns termos fundamentais que usaremos.

2.1 Identificador: E-mail, número de telefone e nome de usuário#

Na maioria dos sistemas de consumo e corporativos, a autenticação depende de três identificadores principais: e-mail, número de telefone e nome de usuário.

A grande maioria dos sistemas usa o e-mail como o identificador principal, particularmente em aplicativos baseados na web. Plataformas mobile-first ou app-first, no entanto, frequentemente preferem usar o número de telefone como identificador devido à facilidade de preencher previamente um OTP (One-Time Passcode) baseado em SMS, que pode ser inserido automaticamente. Em alguns casos, os usuários também podem ser obrigados a configurar um nome de usuário além desses identificadores, principalmente para plataformas que exigem um nome de exibição exclusivo. Há também uma tendência crescente, especialmente em plataformas maiores, de permitir o uso de tanto e-mail quanto número de telefone para maior flexibilidade.

Durante a inscrição inicial, esses identificadores normalmente são verificados por meio de um link de confirmação / OTP (para e-mail) ou um OTP (para número de telefone), garantindo que o identificador pertença à pessoa correta. Caso o acesso seja perdido, provar o controle sobre o e-mail ou número de telefone previamente verificado geralmente é suficiente para restaurar o acesso à conta. Como esses identificadores são as formas mais confiáveis de comunicação com os usuários, os números de telefone frequentemente são coletados para fins de MFA (Multi-Factor Authentication - Autenticação Multifator), com o SMS sendo um segundo fator comumente usado.

Os nomes de usuário são frequentemente empregados para fornecer uma camada adicional de identidade do usuário em sistemas onde são necessários identificadores voltados para o público, como mídias sociais, fóruns ou certas plataformas profissionais. Embora não tenham a mesma função na autenticação que o e-mail ou os números de telefone, os nomes de usuário fornecem aos usuários uma identidade reconhecível em contextos públicos ou peer-to-peer. No entanto, eles introduzem uma complexidade adicional, pois os usuários costumam esquecê-los e, na maioria dos casos, outro identificador é necessário junto com o nome de usuário. Portanto, neste artigo, não focaremos em nomes de usuário.

Outras opções de 2FA, como aplicativos autenticadores (que geram códigos TOTP), não dependem de um identificador, mas costumam ser mais complexas de configurar para um usuário médio. As chaves de acesso também introduziram a possibilidade de trabalhar sem um identificador (autenticação sem nome de usuário / usernameless), um recurso cada vez mais popular no espaço cripto. No entanto, tanto para soluções de consumo quanto corporativas, a necessidade de se comunicar com os usuários (frequentemente via e-mail) para fins de fallback ou recuperação torna os sistemas sem nome de usuário menos práticos.

2.2 Nível de segurança: Autenticação de Fator Único (SFA) e Autenticação Multifator (MFA)#

Sistemas de Autenticação de Fator Único (SFA - Single Factor Authentication) são aqueles que dependem de uma forma de autenticação para verificar a identidade do usuário. Comumente, esse fator único é uma senha, mas também pode ser um login social, OTP por e-mail ou qualquer método que exija apenas um tipo de prova. A maioria dos sistemas na web hoje são sistemas SFA. No entanto, existe um trade-off bem conhecido em relação à segurança. Ao integrar chaves de acesso, estas tipicamente servem como um complemento ou substituição de senhas tradicionais, aumentando a conveniência do sistema. É comum que tais sistemas ainda permitam opções de fallback, como OTPs por e-mail ou logins sociais, o que melhora a experiência do usuário ao reduzir as senhas, mas não eleva a segurança do sistema além do SFA.

A Autenticação Multifator (MFA) envolve dois ou mais fatores independentes para verificar a identidade de um usuário; isso é o que a torna mais segura do que o SFA. Esses fatores podem incluir algo que o usuário sabe (senha ou PIN), algo que o usuário tem (um token de segurança ou um aplicativo de celular) e algo que o usuário é (verificação biométrica, como impressões digitais ou reconhecimento facial). Os sistemas MFA são projetados para proteger contra vulnerabilidades específicas das quais os sistemas SFA não conseguem se defender, como ataques de phishing ou violações de senha. Ao usar chaves de acesso em um sistema MFA, elas geralmente são utilizadas como uma opção MFA autossuficiente. Nesses casos, é crucial que quaisquer métodos de fallback ou recuperação mantenham o mesmo nível de segurança das chaves de acesso.

2.3 Fallback e recuperação#

Os fallbacks são usados em todos os sistemas onde múltiplos métodos de autenticação coexistem. Eles são usados quando os métodos principais estão indisponíveis – frequentemente o usuário tem uma escolha no início de como se inscrever (por exemplo, login social vs. senha). Um fallback pode envolver estratégias de autenticação alternativas, como OTPs via e-mail, senhas, logins sociais com e-mails correspondentes, notificações push de aplicativos nativos, códigos QR ou chaves de segurança (security keys). Cada um desses métodos de fallback varia em qualidade de segurança, e selecionar a opção de fallback apropriada é fundamental para equilibrar a conveniência do usuário com os requisitos de segurança.

Em ambientes que utilizam chaves de acesso como parte de um sistema de Autenticação Multifator (MFA), esses métodos de fallback devem ser cuidadosamente considerados para garantir que forneçam segurança multifator comparável às chaves de acesso. Os processos de recuperação tornam-se importantes quando os usuários perdem o acesso a todas as medidas de autenticação estabelecidas que atendem aos padrões de segurança exigidos (SFA ou MFA). Isso é menos crítico em sistemas de fator único, onde várias opções de recuperação podem estar disponíveis, como redefinir uma senha via OTP por e-mail, o que valida efetivamente o controle do usuário sobre um identificador associado. No entanto, a recuperação é particularmente desafiadora em sistemas 2FA/MFA porque esses sistemas dependem inerentemente de múltiplos fatores para verificação. Em cenários em que um usuário troca de sistema operacional móvel – por exemplo, do iPhone para um celular Android – e perde as chaves de acesso associadas e o número de telefone – os fatores restantes (por exemplo, apenas uma senha) não podem satisfazer os requisitos de 2FA. A recuperação nessas instâncias pode exigir a criação de novas provas de identidade, o que pode envolver solicitações de suporte manual ou soluções mais inovadoras que abordaremos mais adiante.

3. Fallback de login de chaves de acesso: Login manual vs. Login automático de chaves de acesso#

Ao implementar uma solução de chaves de acesso, uma das primeiras decisões a serem tomadas é a abordagem para o login com chaves de acesso. Dependendo do caso de uso, o login manual pode ser suficiente para plataformas menores, mas para empresas maiores orientadas para UX, recomenda-se uma abordagem identifier-first, que oferece o login por chave de acesso após a inserção do identificador primário (muito provavelmente o e-mail).

3.1 Login manual de chaves de acesso: Abordagem iniciada pelo usuário#

3.1.1 O que é a abordagem iniciada pelo usuário?#

Em plataformas menores ou plataformas que não focam em alta taxa de login de chaves de acesso, a abordagem iniciada pelo usuário envolve um botão separado de "Fazer login com chave de acesso". Nessa abordagem, a responsabilidade pelo uso das chaves de acesso é totalmente colocada no usuário. Após adicionar uma chave de acesso à sua conta, o usuário deve se lembrar de clicar em "Fazer login com chave de acesso" para acessá-la.

A captura de tela mostra a implementação de chaves de acesso do https://my.gov.au, que usa a abordagem de login manual. Embora essa abordagem seja mais fácil de implementar porque o back-end não precisa determinar se um login por chave de acesso é possível, ela normalmente leva a taxas muito menores de login com chaves de acesso. Isso ocorre porque ela depende muito da iniciativa do usuário, e os consumidores podem não se lembrar ou não ter certeza em qual plataforma ou armazenamento em nuvem suas chaves de acesso residem. Essa abordagem faz o usuário pensar. Vamos dar uma olhada nas possíveis oportunidades de fallback que existem com essa abordagem na próxima seção.

3.1.2 Fallbacks#

Os fallbacks são essenciais em qualquer sistema onde existam possibilidades de falha no acesso às chaves de acesso. Na abordagem de login manual de chaves de acesso, as caixas de diálogo e os fallbacks não podem ser gerenciados individualmente, pois todas as opções de login são exibidas ao mesmo tempo e as chaves de acesso são escolhidas a critério do usuário. Isso leva a vários desafios:

• Erros não intuitivos: As mensagens de erro que os usuários encontram quando as chaves de acesso não estão disponíveis ou estão configuradas incorretamente costumam ser pouco claras e podem causar confusão. Os usuários podem não entender por que não conseguem usar a chave de acesso ou o que deu errado, gerando frustração.
• Becos sem saída (Dead ends): Os usuários podem se encontrar em situações sem saída de onde não conseguem prosseguir. Se as chaves de acesso estiverem ausentes ou inacessíveis, os usuários podem não receber nenhuma orientação clara sobre como prosseguir ou recuperar o acesso, fazendo com que abandonem o processo de login.
• Falta de orientação: Nessas situações, o sistema não pode fornecer instruções úteis para guiar os usuários em direção a um método de autenticação alternativo. Os usuários ficam por conta própria para descobrir como resolver o problema, o que prejudica a experiência.

O exemplo acima mostra o quão confusas são as mensagens de erro do Windows 11 quando as chaves de acesso não são encontradas no autenticador da plataforma. O sistema pode assumir que a chave de acesso reside em uma chave de segurança ou em outro dispositivo. Esse processo pode ser confuso para usuários não familiarizados com tais fluxos de autenticação, particularmente se eles nunca usaram uma chave de segurança antes ou nunca criaram uma chave de acesso.

Se nenhuma chave de acesso for encontrada no autenticador da plataforma, o sistema operacional e o navegador assumem que elas devem existir em outro lugar, levando a mais confusão se o usuário ainda não tiver criado uma chave de acesso. A Conditional UI pode ajudar exibindo as chaves de acesso existentes, mas isso só é útil se as chaves de acesso realmente existirem. Para a melhor experiência de chave de acesso, o back-end deve decidir se um login por chave de acesso deve ser acionado após o usuário fornecer seu identificador principal.

3.2 Login automático de chaves de acesso: Abordagem Identifier-First#

3.2.1 O que é a abordagem Identifier-First?#

Na abordagem identifier-first, solicita-se aos usuários que forneçam seu identificador principal, como um e-mail ou número de telefone, antes que o sistema determine se um login por chave de acesso é possível. Depois que o identificador é verificado, o sistema sugere automaticamente o método de login mais adequado, incluindo chaves de acesso, caso estejam disponíveis e acessíveis. Essa abordagem é mais amigável ao usuário porque elimina a necessidade de que os usuários se lembrem de selecionar a opção "Fazer login com chave de acesso" e melhora a taxa de adoção otimizando o processo.

Login Identifier-First do Google

Login com chave de acesso do Google

As capturas de tela acima mostram o comportamento de um login do Google para uma conta em que uma chave de acesso está associada a um dispositivo macOS. O Google também segue a abordagem identifier-first e determinou que o login com chave de acesso provavelmente será possível:

1. Suporte da plataforma para chaves de acesso: A plataforma subjacente suporta um autenticador de plataforma, portanto, um login pode ser possível.
2. Chave de acesso está acessível: A chave de acesso provavelmente estará acessível neste cliente (macOS) porque foi criada em um sistema macOS.

Consequentemente, um login por chave de acesso é iniciado automaticamente, guiando o usuário para a melhor experiência possível. Isso segue a estratégia "don't make me think" (não me faça pensar).

3.2.2 Falta de suporte à plataforma de chaves de acesso ou acessibilidade das chaves de acesso#

O sistema determina se um login por chave de acesso é possível. Caso:

• Nenhuma chave de acesso exista: O usuário ainda não criou uma chave de acesso para sua conta.
• As chaves de acesso não estejam acessíveis: As chaves de acesso que o usuário criou provavelmente não estão disponíveis neste cliente (por exemplo, o usuário tem apenas uma chave de acesso no macOS e agora faz login no Windows).
• Autenticação por chave de acesso não seja suportada: O cliente atual não suporta autenticadores de plataforma e também é muito improvável que suporte Autenticação entre Dispositivos via código QR.

a decisão será que um login bem-sucedido com chave de acesso é improvável e, portanto, as opções de fallback serão fornecidas automaticamente sem acionar um login por chave de acesso. Essa abordagem é muito mais amigável porque elimina a necessidade de o usuário lembrar de selecionar a opção "Fazer login com chave de acesso", aumenta a taxa de adoção ao agilizar o processo e evita o pior cenário, onde um beco sem saída confuso é mostrado ao usuário.

No exemplo acima, o login faz o fallback para uma senha e continuará a solicitar fatores de autenticação adicionais com base no status e segurança da conta, pois o cliente é um dispositivo Windows 11, que dificilmente terá acesso às chaves de acesso do macOS. Dependendo dos requisitos de segurança do seu sistema de autenticação, você tem controle total sobre qual método de autenticação acionar em tal caso (por exemplo, a última opção de autenticação bem-sucedida sem chave de acesso).

3.2.3 Abortos da cerimônia da chave de acesso#

Quando um usuário se depara com uma tela de autenticação durante um login na web, ele pode ficar surpreso ou sobrecarregado, especialmente se for uma de suas primeiras vezes usando autenticação baseada em chave de acesso. Isso pode levar os usuários a abortarem o processo de autenticação, não devido a uma falha, mas simplesmente porque não têm certeza do que está acontecendo. É crucial planejar esse comportamento e tratar o primeiro aborto como um evento normal e não como um erro:

A tela do primeiro aborto deve explicar claramente o que está acontecendo de forma calma e tranquilizadora, recomendando que o usuário repita o processo (veja o exemplo do Google acima). Essa tela deve ser projetada para minimizar a ansiedade, tratando o aborto como uma parte regular e esperada da experiência do usuário. Muitos usuários podem abortar simplesmente porque não reconheceram a tela de autenticação ou não estavam familiarizados com o processo. Portanto, uma nova tentativa deve ser a sugestão padrão.

Se um segundo aborto ocorrer, no entanto, a situação deve ser tratada de forma diferente. O segundo aborto pode indicar que algo deu realmente errado - seja um problema com o autenticador da plataforma, a incapacidade do usuário de encontrar uma chave de acesso apropriada ou uma falha técnica na cerimônia WebAuthn. Neste ponto, o sistema deve apresentar uma tela diferente explicando que ocorreu um problema e sugerindo opções de fallback de forma mais incisiva:

A tela do segundo aborto deve incentivar o usuário a mudar para um método alternativo de autenticação. Isso deve garantir que o usuário ainda consiga fazer login com sucesso sem causar mais frustração. Como podemos ver na tela acima, o Google ainda sugere "Tentar novamente", mas, ao mesmo tempo, mostra ao usuário que algo provavelmente deu errado.

3.3 Comparação das abordagens de implementação de chaves de acesso#

A tabela a seguir ajuda a comparar as diferentes abordagens resumindo as características mais importantes:

As abordagens do tipo "faça você mesmo" (do-it-yourself) geralmente seguem a abordagem de Login manual de chaves de acesso e contam com a Conditional UI e o usuário para aceitar as chaves de acesso, o que resulta em taxas muito baixas de login com chaves de acesso e usuários frustrados. A abordagem Identifier-First requer o estabelecimento de uma lógica de dispositivo bem pensada em cima da Conditional UI, que é onde a Corbado pode ajudá-lo. Não recomendamos a criação da sua própria lógica de dispositivo e passkey intelligence, pois esse conjunto de regras exige ajustes e adaptações constantes a novos dispositivos, novas funcionalidades do WebAuthn e sincronização em nuvem (por exemplo, chaves de acesso GPM).

4. Recuperação de chaves de acesso#

A recuperação de chaves de acesso é um aspecto crucial para manter a segurança e a experiência do usuário quando os usuários perdem o acesso às suas chaves de acesso. Isso é particularmente importante em sistemas que dependem de MFA. Em casos de MFA, os processos de recuperação devem garantir a preservação da segurança, permitindo ao mesmo tempo que os usuários recuperem o acesso às suas contas. A abordagem de recuperação deve ser personalizada de acordo com o nível de autenticação usado no sistema.

4.1 Recuperação de fator único e recuperação multifator#

Para manter a segurança em sistemas SFA, a recuperação geralmente envolve provar o controle sobre um identificador, como um endereço de e-mail ou número de celular.

• OTP por e-mail: Um OTP é enviado ao endereço de e-mail registrado do usuário. Uma vez verificado, isso permite ao usuário recuperar o acesso e criar uma nova chave de acesso.
• OTP por SMS: Semelhante à recuperação por e-mail, um OTP é enviado ao número de celular registrado. O usuário pode usar esse OTP para recuperar o acesso à sua conta.

Embora esses métodos sejam simples, eles dependem de manter as informações de contato do usuário atualizadas. Portanto, é essencial solicitar regularmente aos usuários que verifiquem seu e-mail e número de telefone durante os logins de rotina.

Em sistemas de Autenticação Multifator (MFA), a recuperação se torna mais complexa. Como o MFA depende de vários fatores independentes (por exemplo, chaves de acesso, login social e OTPs), os usuários não devem perder o acesso só porque um fator (como uma chave de acesso) está indisponível.

• Uso de fatores alternativos: Se a chave de acesso for perdida, o usuário pode se autenticar usando dois outros fatores, como uma senha + OTP por SMS ou um aplicativo de autenticação. Uma vez autenticados, eles podem criar uma nova chave de acesso.
• Uso de outras chaves de acesso: Caso o usuário possua outros dispositivos com chaves de acesso, ele poderá usá-los para recuperar o acesso com avisos adequados (por exemplo, solicitando o uso de uma chave de acesso de um iPhone).
• Criação de novas chaves de acesso: Após autenticar-se com o método de recuperação, o usuário deve ser guiado para criar uma nova chave de acesso para garantir que a configuração de MFA permaneça intacta.

Tanto para sistemas SFA quanto MFA, o ponto principal é garantir que os processos de recuperação sejam robustos e seguros e, ao mesmo tempo, reduzam o atrito para o usuário.

4.2 Recuperação inteligente de MFA: Digitalização dos custos de recuperação de MFA#

Em sistemas que lidam com dados pessoais confidenciais, setores regulamentados ou serviços governamentais, o OTP padrão por e-mail e por número de celular podem nem sempre ser suficientes ou estar disponíveis para recuperação. Nesses casos, os mecanismos de recuperação inteligente de MFA oferecem métodos avançados de recuperação de conta que mantêm altos padrões de segurança e, ao mesmo tempo, oferecem aos usuários uma experiência sem atritos.

Um dos métodos mais eficazes é a identificação por selfie com uma verificação de vivacidade (liveness check). Esse processo envolve o usuário tirando fotos da sua identidade. Além disso, uma verificação de vivacidade na selfie garante que a selfie esteja sendo tirada em tempo real, confirmando que o usuário está fisicamente presente e corresponde à identidade fotografada, evitando fraudes no uso de imagens estáticas ou identidades roubadas. Dependendo da tecnologia usada, uma verificação de vivacidade é feita registrando um vídeo curto no qual a distância para a câmera é alterada ou a cabeça é virada em 180 graus (por exemplo, o Face ID da Apple).

Esse método pode ser particularmente útil quando os métodos tradicionais de recuperação, como OTPs por e-mail ou SMS, não estão disponíveis ou estão desatualizados. Por exemplo, aqui está um exemplo de tirar uma selfie, que é seguida por uma verificação de vivacidade da onfido:

Exemplo: Identificação por selfie com verificação de vivacidade da onfido

• Sistemas governamentais, indústrias regulamentadas ou grandes serviços comerciais têm dados pessoais disponíveis que podem ser usados para verificar informações constantes na identidade. Caso, por exemplo, a data de nascimento não esteja disponível, as informações coletadas por meio do documento de identidade podem ser usadas como um fator no processo de recuperação manual.

Além disso, outros métodos de recuperação inteligente podem incluir:

• Recuperação entre dispositivos: Se um usuário tiver um dispositivo secundário confiável, ele poderá recuperar sua conta lendo um código QR.
• Ambientes conhecidos: Usuários que ainda têm acesso ao mesmo dispositivo que usaram com sucesso no passado podem fornecer fatores de garantia adicionais usando esse dispositivo e, assim, provar que estão agindo a partir do mesmo dispositivo, provedor e localização para ajudar no processo de recuperação manual. Uma abordagem que o Google usa para a Recuperação de conta do Gmail.
• API Digital Credentials: Com a crescente adoção de carteiras de identidade, espera-se que a verificação direta por meio dessa API desempenhe um papel crescente na recuperação segura e amigável de contas.

Os métodos de recuperação inteligente de MFA buscam oferecer aos usuários formas seguras e intuitivas de recuperar o acesso a suas contas, especialmente ao lidar com informações altamente sensíveis ou regulamentadas. Essas abordagens garantem que, mesmo em casos em que métodos tradicionais, como e-mail ou telefone, não estão disponíveis, os usuários ainda consigam restaurar seu acesso com segurança e eficiência. A recuperação inteligente ajuda a reduzir os custos de recuperação de MFA.

4.3 Frequências de recuperação de MFA: Número de celular vs. Chave de acesso#

É importante ter em mente que, como as chaves de acesso são sincronizadas na nuvem, os custos de recuperação de MFA são muito menores ao longo de um período de 36 meses, uma vez que alterar o número de celular é muito mais frequente do que trocar de Apple para Android ou vice-versa. Em caso de mudança de aparelho de telefone celular, as chaves de acesso serão restauradas.

Portanto, a perda de acesso a chaves de acesso sincronizadas ocorrerá com muito menos frequência do que a perda de acesso ao número de celular, o que causa a maior parte da dor da recuperação em sistemas MFA tradicionais voltados para o consumidor.

No entanto, com o aumento da base de usuários, tais casos ainda geram custos significativos de suporte manual e devem ser tratados com uma solução digital, o que veremos na próxima seção.

5. Recomendações para gerentes de produto e desenvolvedores#

Ao integrar chaves de acesso em seu sistema de autenticação, é crucial planejar cuidadosamente tanto as opções de fallback quanto as estratégias de recuperação para manter um alto nível de segurança, garantindo ao mesmo tempo uma experiência de usuário sem atritos. Para maximizar a taxa de login por chave de acesso, considere as seguintes recomendações:

• Opte pela abordagem Identifier-First: Essa abordagem é mais amigável ao usuário e reduz o atrito no processo de login. Ao pedir que os usuários insiram o identificador primário primeiro (por exemplo, e-mail ou número de telefone), o sistema pode determinar automaticamente se um login por chave de acesso é possível. Isso garante uma experiência de login tranquila e intuitiva sem depender que o usuário escolha manualmente a opção de chave de acesso.
• Use telas de aborto explicativas para uma melhor experiência do usuário: Embora a segurança deva ser a prioridade máxima, é essencial projetar um processo que ajude o usuário a adotar chaves de acesso. Certifique-se de que as primeiras vezes de aborto da cerimônia sejam tratadas como normais e forneça orientações claras para tentar novamente.
• Mantenha as opções de fallback e recuperação seguras: Certifique-se de que os métodos de fallback (como OTP por e-mail e/ou OTP por SMS) correspondam ao nível de segurança do método de autenticação primário. Por exemplo, em um sistema MFA que usa chaves de acesso, o fallback também deve exigir vários fatores para manter o mesmo padrão de segurança.
• Automatize as solicitações regulares de recuperação: Solicite regularmente que os usuários verifiquem suas informações de contato (endereço de e-mail ou número de telefone) durante o login para garantir que as opções de recuperação permaneçam atualizadas quando usarem chaves de acesso. Isso reduz a probabilidade de os usuários serem bloqueados de suas contas por conta de métodos de recuperação desatualizados.
• Considere métodos de recuperação inteligente para aumentar a segurança e reduzir os custos de suporte à recuperação: Para indústrias regulamentadas ou sistemas com acesso a dados pessoais para verificar a identificação online, considere métodos de recuperação avançados, como a identificação por selfie com verificação de vivacidade (liveness check). Esse método pode fornecer camadas adicionais de segurança, mantendo o processo de recuperação intuitivo e amigável ao usuário, dependendo dos seus requisitos de segurança.

A maximização da taxa de login com chaves de acesso depende de quão bem você implementa esses elementos. Garantir opções de fallback e recuperação suaves dará aos usuários confiança no uso das chaves de acesso como seu método de autenticação primário.

6. O que a Corbado pode fazer por você: Componentes de UI e Passkey Intelligence#

A Corbado fornece tudo o que é necessário para implementar a abordagem identifier-first tanto para projetos novos (greenfield) que exigem um sistema de autenticação totalmente novo quanto para projetos existentes que precisam adicionar chaves de acesso a um sistema de autenticação já existente.

6.1 Componentes de UI para diferentes casos de uso#

Ambos os produtos oferecem componentes de interface de usuário (UI) que podem ser adaptados às suas necessidades:

1. Corbado Complete: Inicie seu projeto com autenticação baseada em chave de acesso primeiro (passkey-first)
   Este é o nosso sistema completo de autenticação, que inclui uma abordagem identifier-first contínua para simplificar o processo de login. O Corbado Complete permite uma experiência segura e amigável, determinando automaticamente se o login por chave de acesso é possível depois que o usuário fornece o seu identificador. Isso reduz o atrito e garante uma experiência de login suave, o que é crucial para maximizar a adoção das chaves de acesso.
2. Corbado Connect: Adicione chaves de acesso sem migração a qualquer aplicativo
   Para empresas que já estabeleceram processos de autenticação e desejam adicionar chaves de acesso como melhoria, o Corbado Connect oferece uma solução complementar para estratégias de Fator Único e Multifator. Essa abordagem complementa a sua infraestrutura existente integrando as chaves de acesso perfeitamente como uma opção conveniente e segura, permitindo que os usuários autentiquem por meio das chaves de acesso sem revisar seu sistema atual. Por exemplo, o Corbado Connect pode ser embutido perfeitamente no Amazon Cognito.

Nós alinhamos estritamente nossos métodos aos dos líderes do setor, como Google e outras empresas proeminentes do espaço das big techs, sendo especialmente criados para empresas voltadas para o consumidor.

6.2 O Passkey Intelligence possibilita a abordagem Identifier-First#

Nosso objetivo não é apenas maximizar a adoção de chaves de acesso (ou seja, a criação de chaves de acesso), mas também garantir que elas sejam usadas ativamente para aumentar as taxas de login (e, consequentemente, aumentar a segurança e reduzir os custos com OTP via SMS). Nossos componentes de UI são construídos pensando na abordagem identifier-first e estão diretamente conectados à nossa Passkey Intelligence, que decide sobre a disponibilidade e acessibilidade das chaves de acesso com base no ambiente do cliente e nas chaves de acesso existentes. Eles oferecem suporte a todas as funcionalidades de fallback e recuperação abordadas. As telas a seguir mostram nossa lógica de aborto e repetição:

Primeiro aborto da chave de acesso

Segundo aborto da chave de acesso

Ao focar tanto na adoção das chaves de acesso quanto em seu uso, ajudamos você a alcançar o equilíbrio entre segurança e experiência do usuário, garantindo que os usuários continuem engajando com as chaves de acesso sem atritos.

7. Conclusão#

Neste guia, exploramos as várias estratégias de fallback e recuperação que seguem à integração de chaves de acesso em um sistema de autenticação. As principais questões levantadas na introdução foram abordadas ao longo do texto:

• Quais cenários de fallback existem? Podem ocorrer vários cenários de fallback, como ausência de suporte para a chave de acesso ou chaves de acesso que não estão acessíveis em um determinado dispositivo. Para manter a segurança e fornecer uma UX fluida, opções de fallback como OTP por e-mail ou SMS devem estar disponíveis quando o login da chave de acesso não for possível.
• Como a recuperação deve ser tratada? Os processos de recuperação devem ser projetados para corresponder ao nível de segurança do sistema de autenticação. Nos sistemas SFA, o OTP por e-mail ou SMS pode ser suficiente, enquanto nos sistemas MFA, fatores alternativos devem ser usados para recuperar o acesso e criar uma nova chave de acesso. Em ambientes altamente regulamentados ou sensíveis, métodos de recuperação inteligentes como identificação por selfie com verificação de vivacidade (liveness check) fornecem segurança adicional.

Ao seguir as práticas recomendadas descritas neste guia, gerentes de produto e desenvolvedores podem projetar sistemas robustos de autenticação baseados em chaves de acesso que oferecem aos usuários uma experiência de login segura e, ao mesmo tempo, fluida. A segurança não precisa vir às custas da experiência do usuário - ambas podem ser alcançadas com design e planejamento cuidadosos.

Sobre a Corbado

Corbado é a Passkey Intelligence Platform para times de CIAM que rodam autenticação consumer em escala. Mostramos o que logs de IDP e ferramentas genéricas de analytics não enxergam: quais dispositivos, versões de SO, navegadores e gerenciadores de credenciais suportam passkeys, por que os registros não viram logins, onde o fluxo WebAuthn falha e quando uma atualização de SO ou navegador quebra silenciosamente o login — tudo sem substituir Okta, Auth0, Ping, Cognito ou seu IDP interno. Dois produtos: Corbado Observe adiciona observabilidade para passkeys e qualquer outro método de login. Corbado Connect entrega passkeys gerenciados com analytics integrado (junto ao seu IDP). VicRoads roda passkeys para mais de 5M de usuários com Corbado (+80% de ativação de passkey). Fale com um especialista em Passkeys →

Perguntas frequentes#

Como a abordagem Identifier-First lida com o login com chave de acesso quando a chave de acesso não está acessível no dispositivo atual?#

Quando uma chave de acesso provavelmente está inacessível (por exemplo, uma chave de acesso do macOS acessada a partir de um dispositivo Windows), o sistema pula automaticamente a solicitação da chave de acesso e apresenta opções de fallback como senha ou OTP. Isso evita estados de erro confusos e becos sem saída, ativando o login com chave de acesso apenas quando o sucesso for provável, seguindo uma estratégia de 'não me faça pensar' (don't make me think).

O que deve acontecer quando um usuário aborta uma cerimônia de autenticação com chave de acesso na metade do fluxo?#

O primeiro aborto deve ser tratado como um evento normal, com uma tela calma incentivando o usuário a tentar novamente, pois muitos usuários abortam simplesmente porque não estão familiarizados com a tela de autenticação. Se ocorrer um segundo aborto, o sistema deve sugerir opções de autenticação de fallback, já que isso pode indicar um problema genuíno com o autenticador da plataforma ou com a disponibilidade da chave de acesso.

Quais opções de recuperação existem para sistemas MFA quando um usuário perde o acesso à sua chave de acesso?#

Em sistemas MFA, os usuários podem recuperar autenticando-se com dois fatores alternativos, como uma senha mais um OTP por SMS, ou usando uma chave de acesso de outro dispositivo confiável, para, em seguida, criar uma nova chave de acesso. Para setores regulamentados onde os métodos tradicionais de recuperação estão indisponíveis, métodos inteligentes, como identificação por selfie com verificação de vivacidade (liveness check), fornecem um caminho de recuperação adicional seguro.

Por que a abordagem do botão manual 'Fazer login com chave de acesso' resulta em menor adoção em comparação com a abordagem Identifier-First?#

A abordagem manual coloca toda a responsabilidade nos usuários para lembrarem de selecionar a opção de chave de acesso por conta própria, o que normalmente resulta em taxas de login com chaves de acesso muito menores. Os usuários também podem encontrar mensagens de erro pouco claras quando as chaves de acesso não são encontradas no autenticador da plataforma, levando à frustração e a tentativas de login abandonadas.