Um app nativo compartilha um cofre de credenciais com sua pilha de rede. Dentro de um WebView esse cofre é isolado: o jar de cookies é separado do navegador do sistema e do HTTP nativo, os cookies entre sites são descartados pelas regras de SameSite, e cada fetch com credenciais precisa de um handshake CORS que a página não controla por completo. Um runtime próprio do host oferece um túnel de credenciais: um canal autenticado entre web e nativo.
O WebView guarda seu próprio jar de cookies
No Android, o CookieManager é por perfil de WebView e nunca é o jar do navegador do sistema. No iOS, o WKHTTPCookieStore é separado do NSHTTPCookieStorage, e desde o iOS 14 o WebView aplica a Prevenção Inteligente de Rastreamento — cookies de terceiros expiram em sete dias e leituras entre sites são bloqueadas. Um cookie de sessão definido por um login nativo não chega automaticamente a um fetch() dentro da página, então a requisição volta com 401.
O SameSite descarta a credencial em silêncio
O Chrome 80+ tornou SameSite=Lax o padrão e exige Secure em qualquer cookie SameSite=None; o iOS 15.4+ ata None a Secure e Partitioned ou o descarta. Assim, um cookie cunhado sem esses atributos simplesmente não é enviado em uma requisição entre sites. Combinado com CORS, um fetch com credenciais precisa de Access-Control-Allow-Credentials: true e um Access-Control-Allow-Origin explícito (nunca *) — e um pre-flight falho lança um TypeError opaco que a página não consegue inspecionar.
O que quebra quando a auth cruza o muro
- Login funciona e depois dá 401. O nativo define a sessão; o
fetchdo WebView nunca a carrega. - O SSO entre subdomínios falha. A sincronização de cookies
login.example.com→app.example.comquebra enquanto o Safari funciona. - O SameSite descarta o token. Um cookie
NonesemSecureé descartado em motores modernos. - O pre-flight lança erros opacos. Depurar uma negação CORS é às cegas — remete à caixa preta de depuração do WebView.
- Hacks desesperados. Alguns times recorrem a
--disable-web-security, impossível em produção e uma mina de conformidade.
A solução do runtime
Um runtime próprio do host controla as credenciais. O host guarda a sessão em um único cofre e a ponteia para a página por um canal autenticado — anexando o cookie certo, respeitando SameSite e Secure na camada nativa, e proxiando as requisições entre origens para que CORS e pre-flight sejam tratados onde podem ser vistos. Uma identidade, web e nativo, cada requisição autenticada.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Jar de cookies | Separado do sistema e nativo | Um único cofre compartilhado |
| Cookie entre sites | Descartado por SameSite | Respeitado na camada nativa |
| Fetch com credenciais | Falha CORS opaca | Tuneizado e visível |
| SSO entre subdomínios | Quebra | Funciona |
| Depuração de pre-flight | TypeError às cegas | Registrado pelo host |
| Seguro por padrão | Fácil de errar | Aplicado |
Um app nativo nunca perde sua sessão na borda de rede. Um WebView comum sim. Um runtime leva uma identidade através do muro — e autentica cada requisição.
Fontes
- MDN — CORS — o pre-flight, as credenciais e as regras de
Access-Control-Allow-Originque limitam requisições entre origens. - web.dev — SameSite cookies explained — por que
Laxé o padrão eNoneexigeSecure. - Android Developers — CookieManager — o jar por perfil que o WebView guarda à parte do navegador do sistema.
- Apple — WKHTTPCookieStore — o armazenamento de cookies do WebView, separado do
NSHTTPCookieStorage. - Chrome for Developers — SameSite updates — a mudança para Lax por padrão no Chrome 80 que quebrou os cookies entre sites não solicitados.
