Referência: Cliente Mobile Fintech

Uma referência composta para um cliente mobile de varejo bancário / wealth-lite - saldos, transferências, extratos, controles de cartão. Restrições de segurança e conformidade dominam a arquitetura. Stack: Expo SDK 57 (expo ~57.0.4), React Native 0.86.0, React 19.2.3.

Contexto

Drivers regulatórios e de segurança:

Práticas mobile alinhadas com PCI: sem PAN em logs, política de captura de tela em fluxos de CVV, tempo limite de inatividade da sessão.
Mandatos da equipe de segurança para certificate pinning para endpoints de API e atestado.
Trilha de auditoria necessária para eventos de autenticação, confirmações de transferência e substituições de política.
Desbloqueio biométrico para abertura do aplicativo; step-up biométrico antes de transferências via fio acima do limite.

Modelo de lançamento: Binários da loja mensalmente; sem OTA de produção para este cliente (conformidade escolheu entrega de JS apenas por artefato via loja). OTA de canal de pré-visualização usado apenas para QA interno.

Arquitetura

┌────────────────────────────────────────────────────────────────────────────┐
│                     Cliente Fintech - arquitetura de segurança              │
├────────────────────────────────────────────────────────────────────────────┤
│  Expo Router                                                               │
│    (auth)/login, (auth)/device-trust                                       │
│    (app)/(tabs)/accounts|transfer|more                                     │
│    (app)/transfer/confirm  ← portão biométrico + evento de auditoria       │
├────────────────────────────────────────────────────────────────────────────┤
│  Camada de Autenticação                                                    │
│    expo-auth-session (PKCE) → troca de código → SecureStore refresh        │
│    AuthProvider: bootstrapping → authenticated | session_expired           │
│    AppState foreground refresh - Ciclo de Vida da Sessão de Autenticação   │
├────────────────────────────────────────────────────────────────────────────┤
│  Transporte                                                                │
│    api/client.ts → assertHttps → validador nativo de pin TLS (somente release) │
│    Plugin de configuração de Certificate Pinning - hashes SPKI primários + backup │
├────────────────────────────────────────────────────────────────────────────┤
│  Step-up                                                                   │
│    expo-local-authentication antes de mutações de alto risco               │
│    Servidor registra timestamp do step-up - cliente emite evento de auditoria │
├────────────────────────────────────────────────────────────────────────────┤
│  Pipeline de Auditoria                                                     │
│    audit.log(event) → fila de batch → POST /audit (payload assinado)       │
│    Sentry com scrub - sem tokens, sem números de conta em breadcrumbs      │
├────────────────────────────────────────────────────────────────────────────┤
│  Release                                                                   │
│    EAS Build apenas para produção; eas update desabilitado no canal de produção │
│    SDK de pagamento nativo + pin versionados com semver da loja            │
└────────────────────────────────────────────────────────────────────────────┘

Fluxo de autenticação:

Cold start → Leitura do SecureStore refresh → refresh silencioso
  ├─ sucesso → abas (app)
  ├─ falha → (auth)/login → OAuth PKCE → armazenamento refresh → auditoria: LOGIN_SUCCESS
  └─ risco do dispositivo elevado → (auth)/device-trust → auditoria: DEVICE_CHALLENGE

Fluxo de transferência (alto risco):

Usuário confirma valor → LocalAuthentication.authenticateAsync()
  ├─ falha → audit: STEP_UP_FAILED, permanece na tela
  └─ sucesso → POST /transfers + Idempotency-Key → audit: TRANSFER_INITIATED

Relacionado: Regras de Segurança para Mobile - barra mínima antes da submissão para a loja

Receita

Stack de segurança de referência rápida no SDK 57 - complete a lista de verificação ADR antes de fixar.

npx create-expo-app@latest AcmeBank --template default@sdk-57
npx expo install expo-auth-session expo-secure-store expo-local-authentication
# Pinning: plugin de configuração + reconstrução do dev-client - não Expo Go
eas build --profile preview --platform all

// src/audit/auditLog.ts (trecho) - estruturado, sem PII no corpo da mensagem
type AuditEvent =
  | { type: "LOGIN_SUCCESS"; deviceId: string }
  | { type: "STEP_UP_FAILED"; reason: string }
  | { type: "TRANSFER_INITIATED"; transferId: string; amountBucket: string };
 
export function auditLog(event: AuditEvent) {
  const entry = {
    ...event,
    at: new Date().toISOString(),
    appVersion: Application.nativeApplicationVersion,
    sdk: "57",
  };
  queueForUpload(entry); // flush no foreground + antes do POST da transferência
}

ADR de Pinning deve incluir:
  1. Modelo de ameaça (CA maliciosa, portal cativo - não "prevenir engenharia reversa")
  2. Pins SPKI primários + backup
  3. Alertas de renovação de certificado de 30 dias
  4. Política de bypass MITM corporativo (geralmente: sem bypass - documente o script do help desk)
  5. Caminho de reconstrução nativa quando os pins rotacionam

Decisões Tomadas

#	Decisão	Escolha	Racional
1	OAuth	PKCE via expo-auth-session	Cliente público mobile - sem segredo de cliente embarcado - Ciclo de Vida da Sessão de Autenticação
2	Armazenamento de Token	SecureStore refresh; acesso na memória	Regras de segurança Nível 2; política de grep zero no AsyncStorage
3	Pinning	Pinning SPKI nativo com pin de backup	Modelo de ameaça incluiu CA maliciosa; runbook de rotação de responsabilidade da operação de segurança - Certificate Pinning
4	Biometria	Step-up para transferências; desbloqueio do app opcional	Biometria controla UI, não armazenamento - Biometria com LocalAuthentication
5	OTA	Desabilitado no canal de produção	Conformidade exigiu hash de submissão da loja para lógica de risco material; OTA de pré-visualização apenas para QA - Regras de Lançamento e OTA
6	Trilha de auditoria	Fila de eventos do cliente + imutabilidade do servidor	Dispositivo emite eventos estruturados; servidor é o registro legal
7	Jailbreak/root	Sinal de risco → recursos limitados	Sem crash forçado; auditoria `DEVICE_RISK_ELEVATED` - regras de segurança Nível 4
8	Logging	Sentry com scrub de autorização	Revisão de payload de crash de teste obrigatória em staging
9	Deep links	Sem tokens em URLs	Push abre `/accounts/[id]` - troca nonce de servidor de curta duração - Expo Linking API

Alternativas rejeitadas:

Pinning via fetch apenas em JS - não é possível no caminho gerenciado; módulo nativo necessário.
Cache de sessão AsyncStorage - falhou na auditoria interna na terceira semana.
OTA para JS de regras de fraude - conformidade exigiu hash de submissão da loja para lógica de risco material.

Resultados

Lançamento interno no SDK 57 após migração do SDK 55 (caminho incremental através do 56 - veja o estudo de caso de upgrade de SDK).

Controle	Resultado
Achados de teste de penetração (mobile)	0 críticos após pinning + migração SecureStore
Completude da auditoria	99,2% dos eventos do cliente corresponderam à ingestão do servidor (lacunas da fila offline - descarregadas na reconexão)
Exercício de rotação de pin	Pin de backup salvou janela de interrupção de 48 horas durante a renovação do certificado primário
Opt-in de step-up biométrico	87% habilitado; caminho de PIN de fallback auditado
Bloqueios falsos (detecção de root)	<0,3% - modo degradado em vez de crash

Um incidente: engenheiro enviou rejectUnauthorized: false de depuração - regra de grep CI adicionada conforme Regras de Segurança para Mobile #17.

Lições

Fixe o ADR de pinning de arquivo antes de escrever código nativo. A rotação sem pins de backup bloqueia a produção até a aprovação da loja - pratique trimestralmente.
Eventos de auditoria não são analytics. Pipeline separado, retenção mais rigorosa, sem amostragem de SDK de terceiros.
O timestamp do step-up deve chegar ao servidor. O sucesso biométrico apenas no cliente não é evidência para disputas.
A política de OTA é uma decisão de conformidade, não de velocidade. Este cliente escolheu apenas a loja para produção; o estudo de caso irmão SaaS B2C escolheu OTA - ambos válidos com documentação.
A migração do SecureStore é um lançamento, não um refator. O caminho único AsyncStorage → SecureStore foi executado antes de habilitar o refresh-on-resume.
Anote o SDK 57 nos payloads de auditoria. A operação de fraude correlaciona o comportamento com as versões do expo e Hermes durante a revisão de incidentes.

Relacionado

Regras de Segurança para Mobile - lista de verificação em camadas
Certificate Pinning - modelo de ameaça e custo
SecureStore e Keychain/Keystore - armazenamento de token
Ciclo de Vida da Sessão de Autenticação - refresh do AppState
Biometria com LocalAuthentication - fluxos de step-up
Noções Básicas de Observabilidade - relatórios de crash com scrub
EAS Submit - trem de lançamento da loja
Referência: App SaaS Expo B2C - arquitetura contrastante com foco em OTA

Versões do Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Contexto

Drivers regulatórios e de segurança:

Práticas mobile alinhadas com PCI: sem PAN em logs, política de captura de tela em fluxos de CVV, tempo limite de inatividade da sessão.
Mandatos da equipe de segurança para certificate pinning para endpoints de API e atestado.
Trilha de auditoria necessária para eventos de autenticação, confirmações de transferência e substituições de política.
Desbloqueio biométrico para abertura do aplicativo; step-up biométrico antes de transferências via fio acima do limite.

Arquitetura

┌────────────────────────────────────────────────────────────────────────────┐
│                     Cliente Fintech - arquitetura de segurança              │
├────────────────────────────────────────────────────────────────────────────┤
│  Expo Router                                                               │
│    (auth)/login, (auth)/device-trust                                       │
│    (app)/(tabs)/accounts|transfer|more                                     │
│    (app)/transfer/confirm  ← portão biométrico + evento de auditoria       │
├────────────────────────────────────────────────────────────────────────────┤
│  Camada de Autenticação                                                    │
│    expo-auth-session (PKCE) → troca de código → SecureStore refresh        │
│    AuthProvider: bootstrapping → authenticated | session_expired           │
│    AppState foreground refresh - Ciclo de Vida da Sessão de Autenticação   │
├────────────────────────────────────────────────────────────────────────────┤
│  Transporte                                                                │
│    api/client.ts → assertHttps → validador nativo de pin TLS (somente release) │
│    Plugin de configuração de Certificate Pinning - hashes SPKI primários + backup │
├────────────────────────────────────────────────────────────────────────────┤
│  Step-up                                                                   │
│    expo-local-authentication antes de mutações de alto risco               │
│    Servidor registra timestamp do step-up - cliente emite evento de auditoria │
├────────────────────────────────────────────────────────────────────────────┤
│  Pipeline de Auditoria                                                     │
│    audit.log(event) → fila de batch → POST /audit (payload assinado)       │
│    Sentry com scrub - sem tokens, sem números de conta em breadcrumbs      │
├────────────────────────────────────────────────────────────────────────────┤
│  Release                                                                   │
│    EAS Build apenas para produção; eas update desabilitado no canal de produção │
│    SDK de pagamento nativo + pin versionados com semver da loja            │
└────────────────────────────────────────────────────────────────────────────┘

Fluxo de autenticação:

Cold start → Leitura do SecureStore refresh → refresh silencioso
  ├─ sucesso → abas (app)
  ├─ falha → (auth)/login → OAuth PKCE → armazenamento refresh → auditoria: LOGIN_SUCCESS
  └─ risco do dispositivo elevado → (auth)/device-trust → auditoria: DEVICE_CHALLENGE

Fluxo de transferência (alto risco):

Usuário confirma valor → LocalAuthentication.authenticateAsync()
  ├─ falha → audit: STEP_UP_FAILED, permanece na tela
  └─ sucesso → POST /transfers + Idempotency-Key → audit: TRANSFER_INITIATED

Relacionado: Regras de Segurança para Mobile - barra mínima antes da submissão para a loja

Receita

Stack de segurança de referência rápida no SDK 57 - complete a lista de verificação ADR antes de fixar.

npx create-expo-app@latest AcmeBank --template default@sdk-57
npx expo install expo-auth-session expo-secure-store expo-local-authentication
# Pinning: plugin de configuração + reconstrução do dev-client - não Expo Go
eas build --profile preview --platform all

// src/audit/auditLog.ts (trecho) - estruturado, sem PII no corpo da mensagem
type AuditEvent =
  | { type: "LOGIN_SUCCESS"; deviceId: string }
  | { type: "STEP_UP_FAILED"; reason: string }
  | { type: "TRANSFER_INITIATED"; transferId: string; amountBucket: string };
 
export function auditLog(event: AuditEvent) {
  const entry = {
    ...event,
    at: new Date().toISOString(),
    appVersion: Application.nativeApplicationVersion,
    sdk: "57",
  };
  queueForUpload(entry); // flush no foreground + antes do POST da transferência
}

ADR de Pinning deve incluir:
  1. Modelo de ameaça (CA maliciosa, portal cativo - não "prevenir engenharia reversa")
  2. Pins SPKI primários + backup
  3. Alertas de renovação de certificado de 30 dias
  4. Política de bypass MITM corporativo (geralmente: sem bypass - documente o script do help desk)
  5. Caminho de reconstrução nativa quando os pins rotacionam

Decisões Tomadas

#	Decisão	Escolha	Racional
1	OAuth	PKCE via expo-auth-session	Cliente público mobile - sem segredo de cliente embarcado - Ciclo de Vida da Sessão de Autenticação
2	Armazenamento de Token	SecureStore refresh; acesso na memória	Regras de segurança Nível 2; política de grep zero no AsyncStorage
3	Pinning	Pinning SPKI nativo com pin de backup	Modelo de ameaça incluiu CA maliciosa; runbook de rotação de responsabilidade da operação de segurança - Certificate Pinning
4	Biometria	Step-up para transferências; desbloqueio do app opcional	Biometria controla UI, não armazenamento - Biometria com LocalAuthentication
5	OTA	Desabilitado no canal de produção	Conformidade exigiu hash de submissão da loja para lógica de risco material; OTA de pré-visualização apenas para QA - Regras de Lançamento e OTA
6	Trilha de auditoria	Fila de eventos do cliente + imutabilidade do servidor	Dispositivo emite eventos estruturados; servidor é o registro legal
7	Jailbreak/root	Sinal de risco → recursos limitados	Sem crash forçado; auditoria `DEVICE_RISK_ELEVATED` - regras de segurança Nível 4
8	Logging	Sentry com scrub de autorização	Revisão de payload de crash de teste obrigatória em staging
9	Deep links	Sem tokens em URLs	Push abre `/accounts/[id]` - troca nonce de servidor de curta duração - Expo Linking API

Alternativas rejeitadas:

Pinning via fetch apenas em JS - não é possível no caminho gerenciado; módulo nativo necessário.
Cache de sessão AsyncStorage - falhou na auditoria interna na terceira semana.
OTA para JS de regras de fraude - conformidade exigiu hash de submissão da loja para lógica de risco material.

Resultados

Lançamento interno no SDK 57 após migração do SDK 55 (caminho incremental através do 56 - veja o estudo de caso de upgrade de SDK).

Controle	Resultado
Achados de teste de penetração (mobile)	0 críticos após pinning + migração SecureStore
Completude da auditoria	99,2% dos eventos do cliente corresponderam à ingestão do servidor (lacunas da fila offline - descarregadas na reconexão)
Exercício de rotação de pin	Pin de backup salvou janela de interrupção de 48 horas durante a renovação do certificado primário
Opt-in de step-up biométrico	87% habilitado; caminho de PIN de fallback auditado
Bloqueios falsos (detecção de root)	<0,3% - modo degradado em vez de crash

Um incidente: engenheiro enviou rejectUnauthorized: false de depuração - regra de grep CI adicionada conforme Regras de Segurança para Mobile #17.

Lições

Fixe o ADR de pinning de arquivo antes de escrever código nativo. A rotação sem pins de backup bloqueia a produção até a aprovação da loja - pratique trimestralmente.
Eventos de auditoria não são analytics. Pipeline separado, retenção mais rigorosa, sem amostragem de SDK de terceiros.
O timestamp do step-up deve chegar ao servidor. O sucesso biométrico apenas no cliente não é evidência para disputas.
A política de OTA é uma decisão de conformidade, não de velocidade. Este cliente escolheu apenas a loja para produção; o estudo de caso irmão SaaS B2C escolheu OTA - ambos válidos com documentação.
A migração do SecureStore é um lançamento, não um refator. O caminho único AsyncStorage → SecureStore foi executado antes de habilitar o refresh-on-resume.
Anote o SDK 57 nos payloads de auditoria. A operação de fraude correlaciona o comportamento com as versões do expo e Hermes durante a revisão de incidentes.

Relacionado

Regras de Segurança para Mobile - lista de verificação em camadas
Certificate Pinning - modelo de ameaça e custo
SecureStore e Keychain/Keystore - armazenamento de token
Ciclo de Vida da Sessão de Autenticação - refresh do AppState
Biometria com LocalAuthentication - fluxos de step-up
Noções Básicas de Observabilidade - relatórios de crash com scrub
EAS Submit - trem de lançamento da loja
Referência: App SaaS Expo B2C - arquitetura contrastante com foco em OTA

Versões do Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (expo ~57.0.4).

Referência: Cliente Mobile Fintech

Buscar na documentação

Referência: Cliente Mobile Fintech