Implementar login único de aplicações nativas para visualizações web embutidas

Aplica-se a: Inquilinos externos (saiba mais)

Quando a sua aplicação móvel inclui funcionalidades baseadas na web, como uma página de atualização de perfil ou um painel de recompensas, os utilizadores esperam uma experiência de login único sem falhas. Eles não devem encontrar um segundo pedido de login depois de já terem iniciado sessão através da aplicação nativa.

Este artigo mostra-lhe como implementar o single log-on (SSO) entre uma aplicação móvel nativa e um recurso web alojado numa web view embutida (por exemplo, WKWebView no iOS ou WebView no Android). Ao contrário dos navegadores de sistema, as visualizações web embutidas permitem-lhe manipular pedidos de rede antes de serem enviados. Esta funcionalidade permite que a sua aplicação injete o estado de autenticação do utilizador diretamente nos cabeçalhos dos pedidos.

O fluxo recomendado funciona da seguinte forma:

1. O utilizador inicia sessão através da interface nativa da aplicação móvel, usando o SDK de Autenticação Nativa ou a API de autenticação nativa.
2. Antes de carregar a web view, a aplicação recupera um token de acesso válido do SDK ou API.
3. A aplicação carrega a visualização web com um pedido personalizado que inclui o token de acesso no cabeçalho Authorization: Bearer <access_token>.
4. O recurso web valida o token e concede acesso imediatamente.

O diagrama seguinte mostra a interação entre o recurso web, a aplicação móvel, o SDK e o serviço de identidade (ESTS):

Pré-requisitos

• Uma aplicação móvel com autenticação nativa configurada usando o SDK de Autenticação Nativa ou a API de autenticação nativa. Se estiveres a usar o SDK e ainda não configuraste a tua aplicação, vê Preparar a tua app Android para autenticação nativa ou Preparar a tua app iOS/macOS para autenticação nativa.
• Um fluxo de login concluído na sua aplicação nativa. Para orientação, consulte Iniciar sessão de utilizadores numa aplicação móvel Android ou Iniciar sessão de utilizadores numa aplicação móvel iOS.
• Um recurso web servido via HTTPS (TLS). Não envie tokens por HTTP.
• Uma identidade partilhada do cliente (ID da aplicação) entre a aplicação móvel e o recurso web. Para detalhes, consulte Limitações e requisitos de configuração.

Iniciar sessão com autenticação nativa

Complete o fluxo padrão de início de sessão usando o Native Auth SDK ou a API nativa de autenticação. Quando o login tem sucesso usando o SDK, armazena em cache o token de acesso, ID token e token de atualização de forma segura. Se usar a API diretamente, a sua aplicação é responsável por armazenar de forma segura os tokens que recebe.

Para passos detalhados de implementação de iniciação de sessão, veja:

• Android: Autenticar utilizadores numa aplicação móvel Android (Kotlin)
• iOS/macOS: Iniciar sessão de utilizadores numa aplicação móvel iOS (Swift)

Recuperar o token de acesso

Quando o utilizador aciona a abertura da web view, certifique-se de que a aplicação tem um token de acesso válido e não expirado antes de carregar o recurso web.

Se usares o SDK de Autenticação Nativa, pede um token silenciosamente. O SDK fornece um getAccessToken() método que recupera um token válido da cache ou o atualiza silenciosamente. Para detalhes sobre a aquisição de tokens de acesso com escopos específicos, veja:

• Android: Adquirir múltiplos tokens de acesso
• iOS/macOS: Adquirir múltiplos tokens de acesso

Se usar diretamente a API de autenticação nativa, a sua aplicação recupera os tokens através do endpoint da /oauth/v2.0/token API. Para mais detalhes, consulte Referência da API de autenticação nativa.

Pede o token com os escopos exatos exigidos pelo recurso web. Para requisitos de âmbito, consulte Limitações e requisitos de configuração.

Carregar a visualização web com autenticação

Existem dois métodos para passar o estado de autenticação para a web view. A abordagem recomendada utiliza cabeçalhos de autorização. Existe uma alternativa baseada em cookies para cenários legados, mas é desencorajada.

Opção A: Usar um token portador via cabeçalho HTTP (recomendado)

Injete o token de acesso diretamente no Authorization cabeçalho do pedido HTTP inicial usado para carregar a web view. Este é o método mais seguro e robusto.

Esta abordagem é preferida porque:

• É sem estado: Não depende de cookies persistentes do lado do cliente.
• Isola o token: Limita severamente o token a este fluxo específico de requisição.
• Evita vetores de ataque baseados na web: evita problemas comuns de segurança associados a sessões geridas pelo navegador.

Para carregar a web view com autenticação baseada em cabeçalhos:

1. Constrói o URL do recurso web. Assegura-te de que usa HTTPS.
2. Crie um objeto de pedido de rede personalizado.
3. Adicione o cabeçalho Authorization: Bearer <access_token> ao pedido.
4. Carregue o pedido no componente da web view (por exemplo, WKWebView no iOS ou WebView no Android).

Opção B: Usar cookies (apenas como alternativa)

Se o recurso web alvo não conseguir gerir autenticação baseada em cabeçalhos (por exemplo, certas aplicações legadas de página única), pode injetar o token como um cookie. Esta abordagem é geralmente desencorajada devido a riscos de segurança.

Injetar cookies numa web view confia o estado de autenticação a um mecanismo gerido pelo navegador. Isto torna a sessão "ambiental" (automaticamente associada a pedidos), o que expõe a aplicação a classes padrão de ataque web:

• XSS (cross-site scripting): A sessão é vulnerável a sequestro se o conteúdo web for comprometido.
• CSRF (falsificação de solicitações entre sites): Existe o risco de solicitações autenticadas não intencionais.
• Fixação da sessão: Um atacante pode controlar o estado da sessão.
• Conformidade: Esta abordagem entra em conflito com as melhores práticas de segurança (por exemplo, MASTG-KNOW-0018) relativas à persistência de estado sensível nos armazenamentos de cookies das visualizações web.

Se usar a abordagem baseada em cookies, aplicam-se estes requisitos:

• Use cookies de sessão emitidos pelo servidor sempre que possível.
• Evite colocar tokens de acesso brutos diretamente nos cookies.
• Defina cookies com os atributos HttpOnly, Secure e SameSite apropriados.
• Impor proteção rigorosa contra CSRF do lado do servidor.

Valide e persista o token no sistema backend

Quando o pedido chega ao recurso web, o backend processa o token para estabelecer a sessão.

Validar o token

O servidor web intercepta pedidos recebidos e verifica a assinatura e as reivindicações do token. Para backends ASP.NET Core, use Microsoft.Identity.Web (MISE) para gerir automaticamente a validação.

Garantir que a reivindicação do público (aud) do token corresponde ao identificador da API web e que a reivindicação do emissor (iss) corresponde à autoridade esperada.

Persistir a sessão

A web view não mantém cabeçalhos personalizados em eventos de navegação subsequentes (por exemplo, quando o utilizador seleciona um link). Para manter o estado autenticado após o pedido inicial, o servidor emite um cookie de sessão padrão (Set-Cookie) após a validação bem-sucedida do token portador inicial.

Configure o cookie de sessão com os seguintes atributos:

• HttpOnly
• Secure
• Uma política apropriada SameSite

Limitações e requisitos de configuração

Para garantir que o token emitido para a aplicação móvel é aceite pelo recurso web, tenha em mente as seguintes configurações:

• Identidade partilhada do cliente: A aplicação móvel e a aplicação web devem partilhar o mesmo ID do cliente (ID da aplicação). Se tiverem IDs diferentes, o backend rejeita o token da aplicação móvel por ser uma incompatibilidade de audiência.
• Alinhamento do escopo: A aplicação móvel solicita o token de acesso com os escopos exatos exigidos pelo recurso web (por exemplo, Profile.Read, Orders.Write).

Conteúdo relacionado

• Autenticação nativa no Microsoft Entra External ID
• Fallback da Web de autenticação nativa
• Referência da API de autenticação nativa