Compartilhar via


Usar o Azure Front Door como um proxy reverso no ambiente de produção para um aplicativo de página única que usa autenticação nativa (versão prévia)

Aplica-se a: Círculo branco com símbolo X cinza. Locatários de força de trabalho Círculo verde com marca de verificação branca. Locatários externos (saiba mais)

Neste artigo, você aprenderá como usar o Azure Front Door como proxy reverso para um aplicativo de página única (SPA) que utiliza a API de autenticação nativa .

A API de autenticação nativa não dá suporte ao CORS (Compartilhamento de Recursos entre Origens). Portanto, um SPA (aplicativo de página única) que usa essa API para autenticação de usuário não pode fazer solicitações bem-sucedidas do código JavaScript de front-end. Para resolver esse problema, adicione um servidor proxy entre o SPA e a API de autenticação nativa. O servidor proxy injeta os cabeçalhos CORS apropriados na resposta.

Em ambiente de produção, recomendamos usar o Azure Front Door com uma assinatura Standard/Premium como um proxy reverso.

Pré-requisitos

Configurar o Azure Front Door como um proxy reverso

  1. Familiarize-se com como usar o Azure Front Door com CORS lendo o artigo em Usar o Azure Front Door Standard/Premium com CORS.
  2. Use as instruções em Habilitar domínios de URL personalizados para aplicativos em locatários externos para adicionar um nome de domínio personalizado ao seu locatário externo.
  3. No SPA de exemplo, abra o arquivo API\React\ReactAuthSimple\src\config.ts e substitua o valor de BASE_API_URL, http://localhost:3001/api, por https://Enter_Custom_Domain_URL/Enter_the_Tenant_ID_Here. Substitua o espaço reservado:
    1. Enter_Custom_Domain_URL com sua URL de domínio personalizado, como contoso.com.
    2. Enter_the_Tenant_ID_Here com sua ID do Diretório (locatário). Se você não tiver o nome do locatário, saiba como ler os detalhes do locatário.
  4. Se necessário, execute novamente o SPA de exemplo.

Criar Azure Front Door como um proxy reverso usando um modelo da Azure Developer CLI (azd)

  1. Para inicializar o modelo azd, execute o seguinte comando:

    azd init --template https://github.com/azure-samples/ms-identity-extid-cors-proxy-frontdoor
    

    Quando solicitado, insira um nome para o ambiente azd. O nome é usado como um prefixo para o grupo de recursos, portanto, ele deve ser exclusivo em sua assinatura do Azure.

  2. Para entrar no Azure, execute o seguinte comando:

    azd auth login
    
  3. Para criar, provisionar e implantar os recursos do aplicativo, execute o seguinte comando:

    azd up
    

    Quando solicitado, insira as seguintes informações para concluir a criação de recursos:

    • Azure Location: a localização do Azure em que seus recursos são implantados.
    • Azure Subscription: A Assinatura do Azure em que seus recursos estão implantados.
    • corsAllowedOrigin: o domínio de origem para permitir solicitações CORS no formato SCHEME://DOMAIN:PORT, por exemplo, http://localhost:3000.
    • tenantSubdomain: o subdomínio do seu locatário externo que estamos intermediando. Por exemplo, se o domínio primário do locatário for contoso.onmicrosoft.com, use contoso. Se você não tiver o subdomínio do locatário, saiba como ler os detalhes do seu locatário.
    • customDomain: a URL completa do domínio personalizado configurado na ID Externa, por exemplo, login.example.com.

Diretrizes para usar o Azure Front Door como um proxy reverso

Recomendamos as seguintes diretrizes ao configurar o Azure Front Door como um proxy reverso para gerenciar os cabeçalhos CORS em um ambiente de produção:

Restringir origens

Ao configurar o Azure Front Door, permita apenas a URL de domínio do SPA, como https://www.contoso.com, como origem. Evite configurações que permitam todas as origens, como * que podem levar a vulnerabilidades de segurança.

Usar solicitações simples

As solicitações de autenticação nativas já atendem a todas as condições de solicitações simples:

  • Usa Http Method: POST.
  • Usa Content-Type: application/x-www-form-urlencoded.
  • A solicitação não requer cabeçalhos personalizados.
  • A solicitação não envolve o objeto ReadableStream.
  • A solicitação não requer o uso de XMLHttpRequest.