Implementar o logon único de aplicativos nativos para exibições da Web incorporadas

Aplica-se a: Círculo verde com um símbolo de marca de seleção branca que indica que o conteúdo a seguir se aplica a locatários externos. Locatários externos (saiba mais)

Quando seu aplicativo móvel inclui recursos baseados na Web, como uma página de atualização de perfil ou painel de recompensas, os usuários esperam uma experiência de logon único perfeita. Eles não devem encontrar uma segunda solicitação de login depois de já terem feito login no aplicativo nativo.

Este artigo mostra como implementar o SSO (logon único) entre um aplicativo móvel nativo e um recurso da Web hospedado em uma exibição da Web inserida (por exemplo, WKWebView no iOS ou WebView no Android). Ao contrário dos navegadores do sistema, as exibições da Web inseridas permitem manipular solicitações de rede antes que elas sejam enviadas. Essa funcionalidade permite que seu aplicativo insira o estado de autenticação do usuário diretamente nos cabeçalhos de solicitação.

O fluxo recomendado funciona da seguinte maneira:

  1. O usuário entra por meio da interface do usuário nativa do aplicativo móvel usando o SDK de Autenticação Nativa ou a API de autenticação nativa.
  2. Antes de carregar a visualização da Web, o aplicativo recupera um token de acesso válido do SDK ou da API.
  3. O aplicativo carrega a visualização da web com uma solicitação personalizada que inclui o token de acesso no cabeçalho Authorization: Bearer <access_token>.
  4. O recurso da Web valida o token e concede acesso imediatamente.

O diagrama a seguir mostra a interação entre o recurso da Web, o aplicativo móvel, o SDK e o serviço de identidade (ESTS):

Diagrama de sequência mostrando o fluxo de SSO em que o aplicativo móvel realiza o login por meio do SDK, recebe tokens e carrega a visualização web com o token de acesso no cabeçalho de autorização.

Pré-requisitos

Entrar com autenticação nativa

Conclua o fluxo de entrada padrão usando o SDK de Autenticação Nativa ou a API de autenticação nativa. Quando a entrada é bem-sucedida usando o SDK, ela armazena em cache o token de acesso, o token de ID e o token de atualização com segurança. Se você usar a API diretamente, seu aplicativo será responsável por armazenar com segurança os tokens recebidos.

Para ver as etapas detalhadas de implementação de login, consulte:

Obter o token de acesso

Quando o usuário dispara a ação para abrir o modo de exibição da Web, verifique se o aplicativo tem um token de acesso válido e não expirado antes de carregar o recurso Web.

Se você usar o SDK de Autenticação Nativa, solicite um token silenciosamente. O SDK fornece um getAccessToken() método que recupera um token válido do cache ou o atualiza silenciosamente. Para obter detalhes sobre como adquirir tokens de acesso com escopos específicos, consulte:

Se você usar a API de autenticação nativa diretamente, seu aplicativo recuperará tokens por meio do ponto de extremidade /oauth/v2.0/token da API. Para obter detalhes, consulte a referência da API de autenticação nativa.

Solicite o token com os escopos exatos exigidos pelo recurso da Web. Para obter requisitos de escopo, consulte Limitações e requisitos de configuração.

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

Há dois métodos para passar o estado de autenticação para o modo de exibição da Web. A abordagem recomendada usa cabeçalhos de autorização. Um recurso alternativo baseado em cookie está disponível para cenários legados, mas seu uso é desencorajado.

Injete o token de acesso diretamente no cabeçalho Authorization da solicitação HTTP inicial usada para carregar o webview. Esse é o método mais seguro e robusto.

Essa abordagem é preferencial porque:

  • É sem estado: ele não depende de cookies persistentes no lado do cliente.
  • Isola o token: ele limita estritamente o token a esse fluxo de solicitação específico.
  • Evita vetores de ataque baseados na Web: ele evita problemas comuns de segurança associados a sessões gerenciadas pelo navegador.

Para carregar a visualização da Web com autenticação baseada em cabeçalho:

  1. Construa a URL para o recurso da Web. Verifique se ele usa HTTPS.
  2. Crie um objeto de solicitação de rede personalizado.
  3. Adicione o cabeçalho Authorization: Bearer <access_token> à solicitação.
  4. Carregue a solicitação no componente de exibição da Web (por exemplo, WKWebView no iOS ou WebView no Android).

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

Se o recurso Web de destino não puder lidar com a autenticação baseada em cabeçalho (por exemplo, determinados aplicativos de página única herdados), você poderá injetar o token como um cookie. Essa abordagem geralmente é desencorajada devido a riscos de segurança.

Injetar cookies em uma exibição da Web confia o estado de autenticação a um mecanismo gerenciado pelo navegador. Isso torna a sessão "ambiente" (anexada automaticamente às solicitações), que expõe o aplicativo a classes de ataque da Web padrão:

  • XSS (cross-site scripting): a sessão fica vulnerável ao sequestro se o conteúdo da web estiver comprometido.
  • CSRF (falsificação de solicitação entre sites): há o risco de solicitações autenticadas não intencionais.
  • Fixação de sessão: um invasor pode controlar o estado da sessão.
  • Conformidade: essa abordagem entra em conflito com as práticas recomendadas de segurança (por exemplo, MASTG-KNOW-0018) em relação à persistência do estado confidencial em armazéns de cookies de visualização da Web.

Aviso

A abordagem baseada em cookie é aprovada condicionalmente e geralmente desencorajada. Use-o somente quando o recurso da Web de destino não puder dar suporte à autenticação baseada em cabeçalho.

Se você usar a abordagem baseada em cookie, esses requisitos se aplicam:

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

Validar e persistir o token no back-end

Quando a solicitação atinge o recurso da Web, o back-end processa o token para estabelecer a sessão.

Validar o token

O servidor Web intercepta solicitações de entrada e verifica a assinatura e as declarações do token. Para back-ends do ASP.NET Core, use Microsoft.Identity.Web (MISE) para lidar com a validação automaticamente.

Verifique se a declaração de audiência (aud) do token corresponde ao identificador da API Web e a declaração do emissor (iss) corresponde à autoridade esperada.

Persistir a sessão

A visualização da Web não mantém cabeçalhos personalizados em eventos de navegação posteriores (por exemplo, quando o usuário seleciona um link). Para manter o estado autenticado após a solicitação inicial, o servidor emite um cookie de sessão padrão (Set-Cookie) após a validação bem-sucedida do token de 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 o aplicativo móvel seja aceito pelo recurso Web, tenha em mente as seguintes configurações:

  • Identidade do cliente compartilhado: o aplicativo móvel e o aplicativo Web devem compartilhar a mesma ID do cliente (ID do aplicativo). Se eles tiverem IDs diferentes, o back-end rejeitará o token do aplicativo móvel como uma incompatibilidade de público-alvo.
  • Alinhamento de escopo: o aplicativo móvel solicita o token de acesso com os escopos exatos exigidos pelo recurso da Web (por exemplo, Profile.Read, ). Orders.Write

Note

Essa solução é personalizada especificamente para o cenário de exibição da Web. Uma solução mais genérica que estende os recursos de SSO para navegadores do sistema e outros cenários complexos é planejada para uma versão futura.

Conteúdo relacionado

  • Last updated on