Autenticação personalizada no Aplicativos Web Estáticos do Azure

O Aplicativos Web Estáticos do Azure fornece autenticação gerenciada que usa registros de provedor gerenciados pelo Azure. Para habilitar mais flexibilidade no registro, você pode substituir os padrões por um registro personalizado.

• A autenticação personalizada também permite configurar provedores personalizados que suportam OpenID Connect. Essa configuração permite o registro de vários provedores externos.

• O uso de registros personalizados desabilita todos os provedores pré-configurados.

Observação

A autenticação personalizada só está disponível no plano Standard do Aplicativos Web Estáticos do Azure.

Configurar um provedor de identidade personalizado

Os provedores de identidade personalizados são configuradas na seção auth do arquivo de configuração.

Para evitar colocar segredos no controle do código-fonte, a configuração procura na configuração de aplicativo por um nome correspondente no arquivo de configuração. Você também pode optar por armazenar segredos no Azure Key Vault.

Microsoft Entra ID

Para criar o registro, comece criando as seguintes configurações de aplicativo:

Nome da Configuração	Valor
AZURE_CLIENT_ID	A ID do aplicativo (cliente) para o registro do aplicativo Microsoft Entra.
AZURE_CLIENT_SECRET	O segredo do cliente para o registro do aplicativo Microsoft Entra.

Em seguida, use o exemplo a seguir para configurar o provedor no arquivo de configuração.

Os provedores do Microsoft Entra estão disponíveis em duas versões diferentes. A versão 1 define explicitamente userDetailsClaim, que permite que a carga retorne as informações do usuário. Por outro lado, a versão 2 retorna informações de usuário por padrão e é designada por v2.0 na URL openIdIssuer.

Microsoft Entra Versão 1

{
  "auth": {
    "identityProviders": {
      "azureActiveDirectory": {
        "userDetailsClaim": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>",
          "clientIdSettingName": "AZURE_CLIENT_ID",
          "clientSecretSettingName": "AZURE_CLIENT_SECRET"
        }
      }
    }
  }
}

Certifique-se de substituir <TENANT_ID> por sua ID de locatário do Microsoft Entra.

Microsoft Entra Versão 2

{
  "auth": {
    "identityProviders": {
      "azureActiveDirectory": {
        "registration": {
          "openIdIssuer": "https://login.microsoftonline.com/<TENANT_ID>/v2.0",
          "clientIdSettingName": "AZURE_CLIENT_ID",
          "clientSecretSettingName": "AZURE_CLIENT_SECRET"
        }
      }
    }
  }
}

Certifique-se de substituir <TENANT_ID> por sua ID de locatário do Microsoft Entra.

Para obter mais informações sobre como configurar a ID do Microsoft Entra, consulte a documentação de Autenticação/Autorização do Serviço de Aplicativo sobre como usar um registro existente.

Para configurar quais contas podem entrar, consulte Modificar as contas com suporte em um aplicativo e Restringir seu aplicativo Microsoft Entra a um conjunto de usuários em um locatário do Microsoft Entra.

Observação

Enquanto a seção de configuração do Microsoft Entra ID é azureActiveDirectory, a plataforma aliases isso para aad nas URLs para login, logout e limpeza de informações do usuário. Consulte a seção autenticação e autorização para obter mais informações.

Apple

Para criar o registro, comece criando as seguintes configurações de aplicativo:

Nome da Configuração	Valor
APPLE_CLIENT_ID	A ID do cliente da Apple.
APPLE_CLIENT_SECRET	O segredo do cliente da Apple.

Em seguida, use o exemplo a seguir para configurar o provedor no arquivo de configuração.

{
  "auth": {
    "identityProviders": {
      "apple": {
        "registration": {
          "clientIdSettingName": "APPLE_CLIENT_ID",
          "clientSecretSettingName": "APPLE_CLIENT_SECRET"
        }
      }
    }
  }
}

Para obter mais informações sobre como configurar a Apple como provedor de autenticação, confira a Documentação de autenticação/autorização do Serviço de Aplicativo.

Facebook

Para criar o registro, comece criando as seguintes configurações de aplicativo:

Nome da Configuração	Valor
FACEBOOK_APP_ID	A ID do aplicativo do Facebook.
FACEBOOK_APP_SECRET	O segredo do aplicativo do Facebook.

Em seguida, use o exemplo a seguir para configurar o provedor no arquivo de configuração.

{
  "auth": {
    "identityProviders": {
      "facebook": {
        "registration": {
          "appIdSettingName": "FACEBOOK_APP_ID",
          "appSecretSettingName": "FACEBOOK_APP_SECRET"
        }
      }
    }
  }
}

Para obter mais informações sobre como configurar o Facebook como provedor de autenticação, confira a Documentação de autenticação/autorização do Serviço de Aplicativo.

GitHub

Para criar o registro, comece criando as seguintes configurações de aplicativo:

Nome da Configuração	Valor
GITHUB_CLIENT_ID	A ID do cliente do GitHub.
GITHUB_CLIENT_SECRET	O segredo do cliente do GitHub.

Em seguida, use o exemplo a seguir para configurar o provedor no arquivo de configuração.

{
  "auth": {
    "identityProviders": {
      "github": {
        "registration": {
          "clientIdSettingName": "GITHUB_CLIENT_ID",
          "clientSecretSettingName": "GITHUB_CLIENT_SECRET"
        }
      }
    }
  }
}

Google

Para criar o registro, comece criando as seguintes configurações de aplicativo:

Nome da Configuração	Valor
GOOGLE_CLIENT_ID	A ID do cliente do Google.
GOOGLE_CLIENT_SECRET	O segredo do cliente do Google.

Em seguida, use o exemplo a seguir para configurar o provedor no arquivo de configuração.

{
  "auth": {
    "identityProviders": {
      "google": {
        "registration": {
          "clientIdSettingName": "GOOGLE_CLIENT_ID",
          "clientSecretSettingName": "GOOGLE_CLIENT_SECRET"
        }
      }
    }
  }
}

Para obter mais informações sobre como configurar o Google como provedor de autenticação, confira a Documentação de autenticação/autorização do Serviço de Aplicativo.

Twitter

Para criar o registro, comece criando as seguintes configurações de aplicativo:

Nome da Configuração	Valor
TWITTER_CONSUMER_KEY	A chave do consumidor do Twitter.
TWITTER_CONSUMER_SECRET	O segredo do consumidor do Twitter.

Em seguida, use o exemplo a seguir para configurar o provedor no arquivo de configuração.

{
  "auth": {
    "identityProviders": {
      "twitter": {
        "registration": {
          "consumerKeySettingName": "TWITTER_CONSUMER_KEY",
          "consumerSecretSettingName": "TWITTER_CONSUMER_SECRET"
        }
      }
    }
  }
}

Para obter mais informações sobre como configurar o Twitter como provedor de autenticação, confira a Documentação de autenticação/autorização do Serviço de Aplicativo.

OpenID Connect

É possível configurar o Aplicativos Web Estáticos do Azure para usar um provedor de autenticação personalizado que adere à especificação do OIDC (OpenID Connect). As etapas a seguir são necessárias para usar um provedor OIDC personalizado.

• Um ou mais provedores OIDC são permitidos.
• Cada provedor deve ter um nome exclusivo na configuração.
• Somente um provedor pode servir como o destino de redirecionamento padrão.

Registrar o aplicativo no provedor de identidade

Você precisa registrar os detalhes do aplicativo com um provedor de identidade. Verifique com o provedor sobre as etapas necessárias para gerar uma ID do cliente e o segredo do cliente para seu aplicativo.

Depois que o aplicativo é registrado com o provedor de identidade, crie os seguintes segredos de aplicativo nas configurações de aplicativo do aplicativo Web estático:

Nome da Configuração	Valor
MY_PROVIDER_CLIENT_ID	A ID do cliente gerada pelo provedor de autenticação para o seu aplicativo Web estático.
MY_PROVIDER_CLIENT_SECRET	O segredo do cliente gerado pelo registro personalizado do provedor de autenticação para o seu aplicativo Web estático.

Se você registrar outros provedores, cada um deles precisará de uma ID de cliente associada e um repositório de segredo do cliente nas configurações do aplicativo.

Importante

Os segredos do aplicativo são credenciais de segurança confidenciais. Não compartilhe esse segredo com ninguém, distribua-o em um aplicativo cliente ou faça check-in no controle do código-fonte.

Depois de ter as credenciais de registro, use as etapas a seguir para criar um registro personalizado.

1. Você precisa dos metadados do OpenID Connect para o provedor. Geralmente, essas informações são expostas por meio de um documento de metadados de configuração, que é o URL de emissor do provedor com o sufixo /.well-known/openid-configuration. Obtenha esse URL de configuração.

2. Adicione uma seção auth do arquivo de configuração com um bloco de configuração para os provedores OIDC e a definição do provedor.

   {
     "auth": {
       "identityProviders": {
         "customOpenIdConnectProviders": {
           "myProvider": {
             "registration": {
               "clientIdSettingName": "MY_PROVIDER_CLIENT_ID",
               "clientCredential": {
                 "clientSecretSettingName": "MY_PROVIDER_CLIENT_SECRET"
               },
               "openIdConnectConfiguration": {
                 "wellKnownOpenIdConfiguration": "https://<PROVIDER_ISSUER_URL>/.well-known/openid-configuration"
               }
             },
             "login": {
               "nameClaimType": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
               "scopes": [],
               "loginParameterNames": []
             }
           }
         }
       }
     }
   }
   

• O nome do provedor, myProvider neste exemplo, é o identificador exclusivo usado pelo Aplicativos Web Estáticos do Azure.
• Substitua <PROVIDER_ISSUER_URL> pelo caminho para a URL do emissor do provedor.
• O objeto login permite que você forneça valores para: escopos personalizados, parâmetros de logon ou declarações personalizadas.

Retornos de chamada de autenticação

Os provedores de identidade exigem uma URL de redirecionamento para concluir a solicitação de logon ou logout. A maioria dos provedores exige que você adicione as URLs de retorno de chamada a uma lista de permitir. Os pontos de extremidade a seguir estão disponíveis como destinos de redirecionamento.

Tipo	Padrão de URL
Logon	https://<YOUR_SITE>/.auth/login/<PROVIDER_NAME_IN_CONFIG>/callback
Logout	https://<YOUR_SITE>/.auth/logout/<PROVIDER_NAME_IN_CONFIG>/callback

Se você estiver usando o Microsoft Entra ID, use aad como o valor para o <PROVIDER_NAME_IN_CONFIG> espaço reservado.

Observação

Esses URLs são fornecidos por Aplicativos Web Estáticos do Azure para receber a resposta do provedor de autenticação, não é necessário criar páginas nessas rotas.

Detalhes de logon, logoff e usuário

Para usar um provedor de identidade personalizado, use os padrões de URL a seguir.

Ação	Padrão
Logon	/.auth/login/<PROVIDER_NAME_IN_CONFIG>
Logout	/.auth/logout
Detalhes do usuário	/.auth/me
Limpar detalhes do usuário	/.auth/purge/<PROVIDER_NAME_IN_CONFIG>

Se você estiver usando o Microsoft Entra ID, use aad como o valor para o <PROVIDER_NAME_IN_CONFIG> espaço reservado.

Gerenciar funções

Cada usuário que acessa um aplicativo Web estático pertence a uma ou mais funções. Há duas funções internas às quais os usuários podem pertencer:

• anônimo: todos os usuários pertencem automaticamente à função anônima .
• autenticado: todos os usuários que estão conectados pertencem à função autenticado.

Além das funções internas, você pode atribuir funções personalizadas aos usuários e referenciá-las no arquivo staticwebapp.config.json.

Convites

Adicionar um usuário a uma função

Para adicionar um usuário a uma função, você gera convites que permitem que você associe usuários a funções específicas. As funções são definidas e mantidas no arquivo staticwebapp.config.json.

Criar um convite

Os convites são específicos para provedores de autorização individuais, portanto, considere as necessidades do seu aplicativo à medida que você seleciona quais provedores serão compatíveis. Alguns provedores expõem o endereço de email de um usuário, enquanto outros fornecem apenas o nome de usuário do site.

Provedor de autorização	Expor
ID do Microsoft Entra	endereço de email
GitHub	nome de usuário
Twitter	nome de usuário

Execute as etapas a seguir para criar um convite.

1. Acesse um recurso do serviço Aplicativos Web Estáticos no portal do Azure.
2. Em Configurações, selecione Gerenciamento de funções.
3. Selecione Convidar.
4. Selecione um Provedor de autorização na lista de opções.
5. Adicione o nome de usuário ou o endereço de email do destinatário na caixa Detalhes do convidado.
   • Para o GitHub e o Twitter, insira o nome de usuário. Para todos os outros, insira o endereço de email do destinatário.
6. Selecione o domínio do seu site estático no menu suspenso Domínio.
   • O domínio que você selecionar é o domínio que aparece no convite. Se você tiver um domínio personalizado associado ao seu site, escolha o domínio personalizado.
7. Adicione uma lista separada por vírgulas de nomes de função na caixa Função.
8. Insira o número máximo de horas que você deseja que o convite permaneça válido.
   • O limite máximo possível é de 168 horas, que corresponde a sete dias.
9. Selecione Gerar.
10. Copie o link da caixa Link do convite.
11. Envie por email o link do convite ao usuário que você está concedendo acesso.

Quando o usuário seleciona o link no convite, ele será solicitado a entrar com a conta correspondente dele. Uma vez conectado com êxito, o usuário será associado às funções selecionadas.

Cuidado

Certifique-se de que suas regras de rota não entrem em conflito com os provedores de autenticação selecionados. Bloquear um provedor com uma regra de rota impede que os usuários aceitem convites.

Atualizar atribuições de função

1. Acesse um recurso do serviço Aplicativos Web Estáticos no portal do Azure.
2. Em Configurações, selecione Gerenciamento de funções.
3. Selecione o usuário na lista.
4. Edite a lista de funções na caixa Função.
5. Selecione Atualizar.

Remover usuário

1. Acesse um recurso do serviço Aplicativos Web Estáticos no portal do Azure.
2. Em Configurações, selecione Gerenciamento de funções.
3. Localize o usuário na lista.
4. Marque a caixa de seleção na linha do usuário.
5. Selecione Excluir.

Quando remover um usuário, tenha em mente os seguintes itens:

• A remoção de um usuário invalida suas permissões.
• A propagação em todo o mundo poderá levar alguns minutos.
• Se o usuário for adicionado de volta ao aplicativo, a userId é alterada.

Função (versão prévia)

Em vez de usar o sistema de convites interno, você pode usar uma função sem servidor para atribuir funções programaticamente aos usuários quando eles entrarem.

Para atribuir funções personalizadas em uma função, você pode definir uma função de API que é chamada automaticamente após cada vez que um usuário é autenticado com êxito com um provedor de identidade. A função é passada das informações do usuário do provedor. Ele deve retornar uma lista de funções personalizadas atribuídas ao usuário.

Os usos de exemplo dessa função incluem:

• Consultar um banco de dados para determinar quais funções um usuário deve ser atribuído
• Chamar a API Graph Microsoft para determinar as funções de um usuário com base na associação de grupo do Active Directory Domain Services
• Determinar as funções de um usuário com base em declarações retornadas pelo provedor de identidade

Observação

A capacidade de atribuir funções por meio de uma função só estará disponível quando a autenticação personalizada estiver configurada.

Quando esse recurso está habilitado, todas as funções atribuídas por meio do sistema de convites integrado são ignoradas.

Configurar uma função para atribuir funções

Para configurar Aplicativos Web Estáticos para usar uma função de API como a função de atribuição de função, adicione uma propriedade rolesSource à seção auth do arquivo de configuração do aplicativo. O valor da propriedade rolesSource é o caminho para a função API.

{
  "auth": {
    "rolesSource": "/api/GetRoles",
    "identityProviders": {
      // ...
    }
  }
}

Observação

Depois de configurada, a função de atribuição de função não pode mais ser acessada por solicitações HTTP externas.

Criar uma função para atribuir funções

Após definir a propriedade rolesSource na configuração do aplicativo, adicione uma função de API em seu aplicativo Web estático no caminho especificado. Você pode usar um aplicativo de funções gerenciadas ou trazer seu próprio aplicativo de funções.

Sempre que um usuário é autenticado com êxito com um provedor de identidade, o método POST chama a função especificada. A função passa um objeto JSON no corpo da solicitação que contém as informações do usuário do provedor. Para alguns provedores de identidade, as informações do usuário também incluem um accessToken que a função pode usar para fazer chamadas à API usando a identidade do usuário.

Consulte o seguinte exemplo de carga útil do Microsoft Entra ID:

{
  "identityProvider": "aad",
  "userId": "72137ad3-ae00-42b5-8d54-aacb38576d76",
  "userDetails": "ellen@contoso.com",
  "claims": [
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
          "val": "ellen@contoso.com"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
          "val": "Contoso"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
          "val": "Ellen"
      },
      {
          "typ": "name",
          "val": "Ellen Contoso"
      },
      {
          "typ": "http://schemas.microsoft.com/identity/claims/objectidentifier",
          "val": "7da753ff-1c8e-4b5e-affe-d89e5a57fe2f"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
          "val": "72137ad3-ae00-42b5-8d54-aacb38576d76"
      },
      {
          "typ": "http://schemas.microsoft.com/identity/claims/tenantid",
          "val": "3856f5f5-4bae-464a-9044-b72dc2dcde26"
      },
      {
          "typ": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
          "val": "ellen@contoso.com"
      },
      {
          "typ": "ver",
          "val": "1.0"
      }
  ],
  "accessToken": "eyJ0eXAiOiJKV..."
}

A função pode usar as informações do usuário para determinar quais funções atribuir ao usuário. Ele deve retornar uma resposta HTTP 200 com um corpo JSON contendo uma lista de nomes de função personalizados para atribuir ao usuário.

Por exemplo, para atribuir o usuário às funções Reader e Contributor, retorne a seguinte resposta:

{
  "roles": [
    "Reader",
    "Contributor"
  ]
}

Se você não quiser atribuir outras funções ao usuário, retorne uma matriz vazia roles.

Para saber mais, confira Tutorial: Atribuir funções personalizadas com uma função e o Microsoft Graph.

Próximas etapas

Definir funções de usuário programaticamente