Biometria e reautenticacao no app: quando pedir e como evitar atrito

Muito app corporativo descobre tarde demais que sessao valida nao resolve tudo. A pessoa fez login pela manha, deixou o aparelho sobre a mesa, voltou horas depois e abriu uma tela com dado sensivel sem qualquer confirmacao extra. Ou o time colocou biometria em tudo, travou a rotina e gerou mais atrito do que seguranca real. Entre esses extremos, existe um desenho melhor: usar biometria e reautenticacao como camada adicional apenas quando a acao realmente pede isso.

Esse cuidado fica mais importante em aplicativos de operacao, gestao, aprovacao, atendimento e produtividade, em que o celular viaja entre bolso, carro, escritorio, campo e redes instaveis. O objetivo nao e parecer sofisticado. E reduzir risco sem transformar cada toque em uma barreira desnecessaria.

Este guia organiza uma abordagem pratica para React Native com Expo: quando pedir biometria, como decidir reautenticacao, como reagir ao retorno do background e como proteger acoes sensiveis sem desmontar a experiencia do usuario.

1. Biometria nao substitui login, token nem permissao da API

Biometria e uma camada local. Ela ajuda a confirmar que a pessoa que esta com o aparelho pode continuar vendo ou executando determinada acao. Isso e diferente de autenticar sessao com backend, renovar token ou verificar permissao do usuario na API.

Em outras palavras:

• login e sessao definem quem entrou no app;
• token e refresh definem como o app conversa com a API;
• biometria e reautenticacao ajudam a confirmar que a mesma pessoa continua no controle em momentos sensiveis.

Por isso, este artigo funciona melhor como extensao de autenticacao mobile com token e refresh, e nao como substituto dela.

2. Primeiro defina quais acoes sao realmente sensiveis

O erro mais comum e decidir pela tecnologia antes de mapear o risco. Nem toda tela pede protecao extra. Em app corporativo, vale listar quais operacoes merecem reautenticacao local:

• aprovar pagamento, estorno ou desconto;
• abrir dado pessoal, financeiro ou contratual mais sensivel;
• assinar ou confirmar uma acao irreversivel;
• trocar senha, e-mail, dispositivo confiavel ou configuracao critica;
• sincronizar fila parada depois de longo periodo com sessao em duvida;
• liberar acesso a uma area administrativa dentro do app.

Essa definicao cria um mapa de acoes criticas. Sem ele, a equipe cai em dois problemas: pede biometria em toda tela ou nao protege nada que realmente importava.

3. Verifique a capacidade real do dispositivo antes de prometer biometria

A documentacao do Expo LocalAuthentication mostra que o pacote expoe metodos como hasHardwareAsync(), isEnrolledAsync() e supportedAuthenticationTypesAsync() para descobrir se existe hardware biometrico, se a pessoa cadastrou biometria e quais tipos o aparelho suporta. Ela tambem diferencia niveis de seguranca biometrica no Android, permitindo escolher entre opcoes mais fracas e mais fortes.

Essa checagem importa porque o fluxo nao pode assumir que todo aparelho corporativo tem Face ID, digital cadastrada ou o mesmo padrao de seguranca.

Sequencia pratica:

1. confirmar se existe hardware;
2. confirmar se existe biometria cadastrada;
3. entender que tipo de autenticacao o aparelho suporta;
4. decidir se aquele nivel atende o risco da acao critica.

Se o app pula essa etapa, a interface promete um fluxo que o dispositivo talvez nem consiga entregar.

4. Reautenticacao e um degrau extra, nao uma repeticao do login

Reautenticacao nao significa mandar a pessoa para a tela inicial sempre que ela tentar fazer algo importante. O desenho mais util costuma ser um step-up de seguranca: a sessao continua valida, mas uma acao critica pede confirmacao local adicional antes de seguir.

Isso pode acontecer, por exemplo, quando:

• o usuario ficou horas fora do app e voltou para um fluxo sensivel;
• o app foi para o background no meio de uma aprovacao;
• o aparelho trocou de contexto e a equipe quer confirmar presenca humana de novo;
• a operacao tem impacto financeiro ou juridico maior do que uma simples consulta.

Esse modelo reduz atrito porque evita novo login completo quando a sessao ainda esta saudavel, mas adiciona uma barreira extra no ponto certo.

5. O prompt biometrico precisa de fallback claro

O Expo LocalAuthentication permite chamar authenticateAsync() e configurar opcoes como promptMessage, cancelLabel, fallbackLabel, disableDeviceFallback e requireConfirmation. A propria documentacao explica que, no iOS, o fluxo normalmente pode cair para o codigo do aparelho depois de varias tentativas, a menos que voce desligue esse fallback e trate a alternativa por conta propria.

Na pratica, a equipe precisa decidir:

• se pode aceitar codigo do aparelho como fallback;
• quando a pessoa deve voltar para senha do proprio app;
• como tratar cancelamento, lockout e ausencia de biometria;
• qual texto aparece no prompt para que a pessoa entenda a acao.

Biometria sem fallback vira beco sem saida. Fallback sem criterio pode enfraquecer a protecao. O equilibrio depende do risco da operacao.

6. Biometria forte e biometria fraca nao devem ser tratadas como iguais

Na referencia do Expo LocalAuthentication, o Android aceita definir biometricsSecurityLevel como strong ou weak. A documentacao explica que o nivel forte permite apenas biometria de classe mais alta, como digital ou certos modelos de reconhecimento facial 3D, enquanto o nivel fraco tambem aceita alternativas menos robustas, como alguns desbloqueios por camera.

Isso afeta diretamente a politica do app. Se a acao critica tem impacto real, vale decidir se o fluxo aceita qualquer biometria ou apenas a mais forte disponivel. Sem essa distincao, o time imagina que esta protegendo uma aprovacao importante quando, na pratica, aceitou um mecanismo local muito mais permissivo do que o risco comporta.

7. Retorno do background faz parte da politica de seguranca

A documentacao do React Native AppState explica que a API informa se o app esta active, background ou, no iOS, inactive. Ela tambem expoe eventos de mudanca de estado e, no Android, eventos como blur e focus. Para seguranca mobile, isso e valioso.

Com AppState, o app consegue definir comportamentos como:

• ocultar conteudo sensivel quando a pessoa volta do background;
• pedir reautenticacao so depois de certo tempo de inatividade;
• evitar retomar uma aprovacao critica sem nova confirmacao;
• separar uma troca rapida de aplicativo de um abandono longo da sessao.

Nem toda mudanca para background exige novo bloqueio. Mas ignorar completamente esse ciclo costuma abrir brecha para visualizacao indevida ou operacao retomada no contexto errado.

8. Bloqueio local precisa ser proporcional ao tempo e ao risco

Uma regra simples ajuda bastante: quanto mais sensivel a area, menor deve ser a janela de tolerancia apos o retorno do background. Uma tela de consulta geral talvez aceite alguns minutos. Uma aprovacao financeira ou configuracao sensivel pode exigir reautenticacao imediata ao voltar.

Esse tempo nao precisa ser igual ao session timeout da sessao com backend. Sao politicas diferentes:

• sessao com API controla acesso ao servidor;
• bloqueio local controla continuidade segura no aparelho.

Quando essas duas ideias se misturam, o app ora pede login completo cedo demais, ora deixa conteudo sensivel aberto por tempo demais.

9. SecureStore com requireAuthentication pede cuidado operacional

A documentacao do Expo SecureStore explica que a opcao requireAuthentication ativa autenticacao do usuario ao acessar dados protegidos. Ela tambem alerta para comportamentos importantes: em iOS a chave fica ligada ao conjunto biometrico atual, e valores protegidos assim podem se tornar inacessiveis se a biometria do aparelho mudar, como na inclusao de uma nova digital. A documentacao tambem informa que leituras sincronas com essa opcao podem bloquear a thread JavaScript ate a autenticacao terminar.

Esses detalhes mudam o desenho do app:

• nem todo segredo precisa ficar atras do prompt biometrico;
• mudanca de biometria precisa ter fallback para reentrada por login normal;
• o time deve preferir fluxo assincrono e localizado, em vez de travar a inicializacao inteira do app;
• dados irrecuperaveis nao devem depender apenas dessa camada local.

Isso conversa com a ideia central do artigo de autenticacao: armazenamento seguro ajuda muito, mas nao deve virar unica fonte de verdade.

10. Nao esconda tudo atras da biometria so porque a API existe

Outra armadilha comum e proteger o token inteiro com biometria e, sem perceber, transformar qualquer retomada de sessao em prompt obrigatorio. Em alguns cenarios isso faz sentido. Em muitos outros, o melhor desenho e separar:

• sessao normal para operacoes do dia a dia;
• reautenticacao local apenas para pontos sensiveis;
• frescor de autenticacao para acoes realmente criticas.

Esse desenho evita que a pessoa enfrente um prompt biometrico toda vez que abre o app so para consultar uma informacao simples. A protecao continua forte onde precisa, sem desgastar a rotina inteira.

11. O backend tambem precisa conhecer o conceito de acao critica

Biometria local ajuda, mas nao encerra a historia. Se uma acao critica realmente importa, o backend tambem pode precisar de sinal mais fresco de autenticacao, ou pelo menos distinguir esse tipo de operacao do restante do trafego.

Vale alinhar com a API:

• quais operacoes sao sensiveis do lado do servidor;
• quando a sessao precisa estar fresca para continuar;
• como diferenciar sessao expirada, sessao valida e autorizacao insuficiente;
• como auditar aprovacoes, liberacoes e mudancas importantes.

O material checklist de API REST ajuda a organizar esse contrato entre app e backend sem cair em respostas genericas.

12. Teste em aparelho real e nao confie apenas no Expo Go

O Expo LocalAuthentication documenta que Face ID nao e suportado no Expo Go e pede development build para testar esse fluxo de forma adequada. A documentacao do SecureStore tambem alerta que requireAuthentication nao funciona corretamente no Expo Go quando biometria esta disponivel, justamente por faltar a configuracao nativa necessaria. Alem disso, a referencia do SecureStore observa que teste de biometria deve ser feito em aparelho real.

Isso significa que o fluxo de seguranca local precisa ser validado em build real. Caso contrario, a equipe corre o risco de aprovar no desenvolvimento uma experiencia que quebra justamente no dispositivo do usuario final.

O artigo Expo, development build e EAS Build ajuda a estruturar esse ambiente de teste com mais previsibilidade.

13. Observabilidade ajuda a diferenciar atrito util de atrito ruim

Se o app decide usar biometria e reautenticacao, o time precisa enxergar o efeito em producao. Vale medir pelo menos:

• quantas vezes a reautenticacao e pedida;
• quantas vezes a pessoa cancela ou cai em fallback;
• quantos erros acontecem por falta de biometria cadastrada;
• em quais fluxos a protecao realmente impede continuidade;
• se o atrito esta concentrado em uma versao, aparelho ou plataforma.

Sem esses sinais, a equipe nao sabe se reforcou seguranca ou apenas aumentou abandono. O artigo observabilidade do app em producao fecha bem essa costura.

14. Checklist rapido para um fluxo mais maduro

1. Mapear quais operacoes realmente sao criticas.
2. Checar hardware, biometria cadastrada e tipo suportado no aparelho.
3. Decidir se a acao aceita biometria fraca ou exige nivel mais forte.
4. Separar sessao com backend de reautenticacao local.
5. Definir fallback claro para cancelamento, lockout e ausencia de biometria.
6. Usar AppState para tratar retorno do background com criterio.
7. Evitar prender a rotina inteira do app atras de prompt biometrico.
8. Planejar o que acontece quando a biometria do aparelho muda.
9. Validar tudo em build real e aparelho real.
10. Medir cancelamentos, falhas e impacto do bloqueio em producao.

15. Erros comuns

• tratar biometria como substituta do login e da API;
• pedir prompt em toda tela por inseguranca da equipe;
• nao definir o que e acao critica;
• ignorar diferenca entre biometria forte e fraca;
• esquecer fallback para chave invalidada depois de mudanca biometrica;
• retomar fluxo sensivel apos longo background sem nova confirmacao;
• aprovar o comportamento apenas no Expo Go;
• nao medir se a reautenticacao esta protegendo ou apenas atrapalhando.

16. Quando vale procurar ajuda tecnica

Se o app ja sofre com login instavel, retorno ruim do background, prompts exagerados, comportamento diferente entre Android e iOS ou duvida sobre o que realmente precisa de protecao extra, talvez a biometria seja apenas a ponta do problema. Nessa hora, um diagnostico tecnico ajuda a revisar o desenho inteiro de sessao, seguranca local, API e experiencia antes que o mobile vire uma fonte permanente de atrito.

Biometria madura nao e a que aparece mais vezes. E a que entra no momento certo, com fallback claro, alinhamento com a API e impacto previsivel para a operacao.

Referencias editoriais: Expo LocalAuthentication, Expo SecureStore e React Native AppState.