Navegacao autenticada no app React Native: rotas por perfil sem bagunca

Em app corporativo, navegacao raramente e apenas trocar de tela. Ela carrega sessao, perfil de acesso, empresa ativa, permissoes, contexto de trabalho, onboarding, notificacao, link externo e expectativa de seguranca. Quando essa camada nasce improvisada, o app pode ate funcionar no primeiro fluxo, mas comeca a falhar justamente quando o produto fica real.

O sintoma aparece de varios jeitos: usuario logado voltando para tela de login, link de notificacao abrindo tela proibida, perfil administrativo vendo menu errado, refresh de token derrubando a navegacao, app restaurando uma rota antiga depois de logout ou tela sensivel ficando acessivel sem reautenticacao. Nao e apenas bug visual. E regra de negocio vazando para a arvore de telas.

Este artigo organiza um modelo pratico para React Native corporativo, especialmente para apps que conversam com uma API, usam token, tem telas por perfil e precisam crescer com seguranca. A ideia e tratar navegacao autenticada como uma politica explicita, e nao como uma colecao de redirecionamentos espalhados.

1. Autenticacao nao e o mesmo que autorizacao de rota

O primeiro erro comum e reduzir tudo a uma pergunta: existe token? Se existe, abre o app; se nao existe, abre login. Esse desenho funciona para prototipo, mas costuma falhar quando entram perfis, tenant, aceite de termos, cadastro incompleto, bloqueio de conta ou telas administrativas.

Um app corporativo precisa separar pelo menos quatro camadas:

• identidade: quem e a pessoa usuaria;
• sessao: se existe credencial valida para falar com a API;
• perfil: quais areas, menus e acoes essa pessoa pode acessar;
• contexto ativo: empresa, unidade, projeto, contrato ou ambiente selecionado.

Quando essas camadas ficam misturadas, a navegacao vira um labirinto. O app acha que esta autenticado, mas ainda nao sabe em qual empresa operar. Ou sabe o perfil, mas ainda nao carregou as permissoes. Ou recebeu um deep link antes de concluir o bootstrap da sessao.

2. Modele estados de entrada antes de modelar telas

Antes de escolher stack, tabs ou drawer, vale desenhar os estados pelos quais o app pode passar. Um exemplo realista:

1. loading inicial: lendo storage seguro, validando token e carregando configuracao minima;
2. publico: login, recuperar senha, criar conta ou politica de privacidade;
3. bloqueado: conta suspensa, senha expirada ou versao minima obrigatoria;
4. onboarding: dados obrigatorios ainda faltando;
5. sem contexto: pessoa logada, mas sem empresa, unidade ou projeto selecionado;
6. app autenticado: shell principal liberado;
7. reauth local: confirmacao biometrica ou senha curta para acao sensivel.

Esse mapa reduz improviso. Em vez de cada tela decidir sozinha para onde redirecionar, a aplicacao passa a ter uma maquina simples de estados. A interface reflete o estado atual, e nao o contrario.

3. React Navigation: deixe o estado decidir a arvore

A documentacao oficial do React Navigation orienta o fluxo de autenticacao com um principio importante: as telas disponiveis devem depender do estado de autenticacao. Em vez de navegar manualmente para dentro ou para fora depois de login e logout, a arvore de navegacao muda quando o estado muda.

Na pratica, isso evita uma classe inteira de bugs. Se a pessoa fez logout, a arvore autenticada desaparece. Se o bootstrap ainda esta carregando, a tela principal nem existe. Se o token ficou invalido, o app troca de estado e remove rotas privadas do historico. A navegacao deixa de depender de uma sequencia fragil de comandos.

Um desenho saudavel costuma separar:

• AuthStack para login, recuperar senha e criacao de conta;
• SetupStack para onboarding ou escolha de contexto ativo;
• AppShell para tabs, stacks internas e menus autenticados;
• BlockedStack para versao minima, conta bloqueada ou pendencia obrigatoria.

O ponto nao e o nome dos stacks. E a regra: cada grupo existe apenas quando o estado permite.

4. Expo Router: proteja grupos, nao cada botao

Para projetos com Expo Router, a documentacao oficial tambem oferece caminhos para autenticacao e protected routes. O ganho conceitual e parecido: organizar grupos de rota e aplicar protecao de forma centralizada, reduzindo a tentacao de escrever verificacao manual em cada tela.

Essa abordagem ajuda muito em app que cresce. Um grupo publico pode conter login e recuperacao. Um grupo privado pode conter o shell autenticado. Outro grupo pode ficar reservado para admin, financeiro ou operador. O app ganha uma hierarquia que comunica intencao tecnica.

Mesmo assim, o cuidado continua o mesmo: protecao de rota no app melhora experiencia e evita caminho errado na interface, mas nao substitui autorizacao no backend. A API precisa validar permissao sempre, porque qualquer cliente pode ser manipulado.

5. Rotas por perfil precisam ser previsiveis

Quando o app tem mais de um perfil, o menu nao deveria ser montado por condicoes soltas em varias telas. O ideal e existir uma definicao unica de areas do produto, cada uma com metadados claros:

• slug da area;
• titulo visivel;
• perfis autorizados;
• permissoes finas, quando houver;
• rota inicial;
• regras de exibicao no menu;
• dependencia de contexto ativo.

Com isso, o menu, os cards da home, os links de notificacao e a verificacao de acesso usam a mesma fonte de verdade. Se uma area muda de regra, a equipe altera uma politica, nao cinco arquivos desconectados.

Para app corporativo, essa previsibilidade tem valor operacional. O suporte consegue entender por que uma pessoa nao viu uma tela. O time de produto consegue revisar permissao antes de liberar modulo. E o backend consegue manter contrato coerente com a interface.

6. Contexto ativo e diferente de perfil

Em muitos sistemas, a pessoa pode acessar mais de uma empresa, filial, obra, contrato, turma ou projeto. Isso nao e perfil. E contexto ativo. Misturar os dois gera bugs sutis, principalmente quando o app restaura estado antigo.

Uma regra simples ajuda: perfil responde o que a pessoa pode fazer; contexto responde onde ela esta fazendo. O app deve validar se existe contexto ativo antes de abrir telas que dependem dele. Se nao existe, a rota certa e uma selecao de contexto, nao uma tela quebrada com erro generico.

Esse cuidado conversa diretamente com APIs. A requisicao deve carregar contexto de forma explicita, e o backend deve rejeitar acesso fora do escopo permitido. Navegacao bonita sem contrato de API consistente vira falsa seguranca.

7. Deep link precisa esperar sessao e permissao

Deep link e notificacao push complicam a historia porque a rota pode chegar antes do app estar pronto. A pessoa clica em um link para abrir um pedido, mas o app ainda precisa carregar token, renovar sessao, validar perfil, buscar contexto e confirmar se aquele pedido pertence ao usuario.

O padrao mais seguro e guardar a intencao de navegacao e executa-la apenas depois do bootstrap. Esse processo pode seguir uma sequencia:

1. receber o link ou payload da notificacao;
2. normalizar a rota para um formato interno conhecido;
3. validar se a sessao esta pronta;
4. validar se o perfil pode acessar aquele tipo de tela;
5. validar ou selecionar o contexto necessario;
6. abrir a tela ou cair em fallback explicito.

O portal ja aprofunda esse tema em deep links, push e navegacao no React Native. Aqui, o ponto central e nao deixar o link pular a politica de acesso.

8. Refresh de token nao deve comandar a navegacao sozinho

O artigo sobre autenticacao mobile com token e refresh trata a sessao como uma camada propria. Na navegacao autenticada, essa separacao e essencial. Um interceptor HTTP nao deveria decidir sozinho para qual tela a pessoa vai. Ele pode sinalizar que a sessao expirou, que o refresh falhou ou que a credencial foi revogada.

A partir desse sinal, o estado global de sessao muda, a arvore autenticada e removida e a tela publica aparece. Essa ordem evita loops: uma chamada falha, dispara logout parcial, uma tela tenta refazer query, outra tenta redirecionar, o login abre por cima de modal antigo e o app fica preso em comportamento confuso.

Quando a navegacao responde ao estado, a expiracao de sessao fica menos teatral. O app simplesmente deixa de ter rotas privadas disponiveis.

9. Reautenticacao local e uma camada de rota sensivel

Nem toda tela autenticada deveria ter o mesmo nivel de acesso. Alterar senha, aprovar valor alto, exportar dado, confirmar pagamento ou visualizar informacao sensivel pode exigir uma reautenticacao curta, como biometria ou senha local.

Isso nao significa deslogar a pessoa. Significa criar uma barreira pontual antes da acao ou da rota sensivel. O portal ja cobre esse tema em biometria e reautenticacao no app React Native. Na arquitetura de navegacao, o cuidado e tratar essa exigencia como politica de acesso, nao como alerta solto no botao.

Assim, a rota sensivel pode pedir confirmacao quando necessario, registrar resultado e voltar para estado normal sem baguncar a sessao principal.

10. Nested navigators exigem disciplina

A documentacao do React Navigation sobre nested navigators reforca pontos que costumam pegar times de surpresa: cada navigator tem seu proprio historico, parametros nao passam automaticamente para telas de navegadores filhos, e eventos de navegacao tambem precisam ser tratados com cuidado entre camadas.

Isso importa muito em apps com tabs dentro de stack, stack dentro de drawer ou modais globais. Se a equipe nao define limites, cada camada tenta conhecer a outra. O resultado e acoplamento alto: tela de detalhe tentando controlar tab, modal tentando limpar stack interna, link externo empilhando rotas repetidas.

Um criterio pratico: o shell principal deve saber trocar grandes areas; cada area deve cuidar de seu proprio historico interno; fluxos sensiveis devem ter entrada e saida claras. Quando uma tela precisa mandar em tres niveis da navegacao, provavelmente a estrutura esta pedindo revisao.

11. Estado restaurado precisa respeitar logout e troca de perfil

Apps mobile podem restaurar estado de navegacao para melhorar experiencia. Isso e util, mas perigoso se a restauracao ignora mudanca de usuario, logout, perfil ou contexto. A regra deve ser conservadora: estado privado restaurado so vale quando a sessao atual combina com a sessao que gerou aquele estado.

Alguns cuidados ajudam:

• limpar historico privado no logout;
• invalidar estado restaurado quando muda usuario;
• nao restaurar tela sensivel sem revalidar permissao;
• nao confiar em parametros antigos como prova de acesso;
• reabrir contexto ativo apenas se ele ainda estiver permitido.

Esse ponto parece pequeno, mas evita vazamento visual e comportamento estranho quando uma pessoa usa o mesmo aparelho depois de outra.

12. Feature flags tambem entram na politica de rota

Se o app usa configuracao remota, uma rota pode existir tecnicamente, mas estar desligada para determinado grupo, versao ou ambiente. O artigo sobre feature flags e configuracao remota no app mobile mostra esse desenho em mais detalhes.

Na navegacao, o ponto e tratar flag como uma camada adicional de disponibilidade. Perfil permite? Contexto permite? Versao permite? Flag permite? Se qualquer uma dessas respostas falhar, a rota nao deve aparecer no menu nem abrir por link direto sem fallback.

Isso permite rollout gradual de modulo novo sem criar duas experiencias conflitantes: uma no menu e outra por link escondido.

13. Analytics deve medir fluxo, nao apenas tela vista

Para melhorar produto e monetizacao indireta do conhecimento tecnico, o app precisa gerar evidencias. No caso de navegacao autenticada, alguns eventos valem mais do que screen view generico:

• login iniciado e concluido;
• falha de refresh de token;
• contexto ativo selecionado;
• deep link recebido e resolvido;
• rota bloqueada por permissao;
• reauth solicitada e concluida;
• logout voluntario ou por expiracao.

Esses dados ajudam a encontrar atrito real. Se muitas pessoas recebem rota bloqueada, talvez o link esteja errado, o perfil esteja mal configurado ou a comunicacao do produto esteja levando usuarios para um caminho que nao e deles. O tema se conecta ao guia de analytics e eventos em React Native.

14. Como testar navegacao autenticada

Esse tipo de fluxo merece teste porque quebra facil em refatoracao. Nao e necessario testar cada tela com E2E completo, mas alguns cenarios devem existir:

1. app sem token abre login;
2. app com token valido abre shell correto;
3. usuario sem contexto cai na selecao de contexto;
4. perfil sem permissao nao ve area restrita;
5. deep link privado com sessao ausente passa por login antes de abrir destino;
6. logout limpa historico privado;
7. refresh de token falho remove rotas autenticadas;
8. rota sensivel pede reautenticacao quando necessario.

O artigo sobre testes de fluxo critico no app React Native complementa essa parte. O objetivo e proteger a politica, nao criar uma suite lenta e fragil para cada detalhe visual.

15. Checklist rapido para revisar seu app

1. Existe uma lista clara de estados de sessao antes da arvore de navegacao?
2. Login, logout e expiracao trocam a arvore por estado, sem redirecionamento manual espalhado?
3. Perfil e contexto ativo estao separados?
4. Menus, cards e deep links consultam a mesma politica de acesso?
5. O backend valida permissao mesmo quando o app esconde a tela?
6. Deep link aguarda bootstrap, sessao e permissao antes de abrir destino?
7. Logout limpa estado privado e rotas restauradas?
8. Rotas sensiveis tem reautenticacao quando necessario?
9. Flags e versao minima bloqueiam rotas de forma previsivel?
10. Existe teste para os fluxos de entrada, bloqueio e logout?

16. Quando vale pedir uma revisao tecnica

Se o app ja tem varias condicoes de rota, perfis diferentes, API com refresh token, push, deep link e contexto ativo, uma revisao antecipada evita bastante retrabalho. O problema costuma nascer invisivel: cada tela ganha uma pequena regra local ate que ninguem sabe mais qual caminho e permitido.

Uma avaliacao tecnica pode mapear arvore de navegacao, politica de perfil, contrato de API, fluxo de login, estado offline, links externos e pontos de reautenticacao. Para apoiar essa conversa, o Checklist de API REST ajuda a revisar tambem a parte do backend consumida pelo app.

Navegacao autenticada boa nao e a que parece inteligente por redirecionar o tempo todo. E a que deixa claro quais telas existem em cada estado, por que existem e quem pode chegar ate elas.

Referencias editoriais: React Navigation - Authentication flows, React Navigation - Nesting navigators, Expo Router - Protected routes e Expo Router - Authentication.