Explore a autenticação e a autorização no Serviço de Aplicativo
O Serviço de Aplicativo do Azure fornece suporte interno de autenticação e autorização, para que você possa entrar em usuários e acessar dados escrevendo código mínimo ou nenhum em seu aplicativo Web, API RESTful, back-end móvel e Azure Functions.
Por que usar a autenticação integrada?
Não é necessário usar o Serviço de Aplicativo para autenticação e autorização. Muitas estruturas da Web são empacotadas com recursos de segurança, e você pode usá-los se quiser. Se precisar de mais flexibilidade do que o Serviço de Aplicativo oferece, você também pode escrever seus próprios utilitários.
O recurso de autenticação interno para o Serviço de Aplicativo e o Azure Functions pode economizar tempo e esforço fornecendo autenticação pronta para uso com provedores de identidade federada, permitindo que você se concentre no restante do seu aplicativo.
- O Serviço de Aplicativo do Azure permite que você integre vários recursos de autenticação em seu aplicativo Web ou API sem implementá-los por conta própria.
- Ele é construído diretamente na plataforma e não requer nenhuma linguagem, SDK, experiência em segurança ou código em particular.
- Você pode integrar com vários provedores de login. Por exemplo, Microsoft Entra ID, Facebook, Google, X.
Fornecedores de identidade
O Serviço de Aplicativo usa identidade federada, na qual um provedor de identidade de terceiros gerencia as identidades de usuário e o fluxo de autenticação para você. Os seguintes provedores de identidade estão disponíveis por padrão:
| Provider | Ponto de extremidade de entrada | Orientação de instruções |
|---|---|---|
| Plataforma de identidade da Microsoft | /.auth/login/aad |
Login da plataforma de identidade Microsoft do Serviço de Aplicativo |
/.auth/login/facebook |
Login do Facebook do Serviço de Aplicativo | |
/.auth/login/google |
Login do Google do Serviço de Aplicativo | |
| X | /.auth/login/twitter |
Login do Serviço de Aplicativo X |
| Qualquer provedor OpenID Connect | /.auth/login/<providerName> |
Login do Serviço de Aplicativo OpenID Connect |
| GitHub | /.auth/login/github |
Login no GitHub do Serviço de Aplicativo |
Quando você habilita a autenticação e a autorização com um desses provedores, seu ponto de extremidade de entrada está disponível para autenticação do usuário e para validação de tokens de autenticação do provedor. Pode fornecer aos seus utilizadores qualquer número destas opções de início de sessão.
Como funciona
O módulo de autenticação e autorização é executado na mesma área restrita que o código do aplicativo. Quando habilitado, cada solicitação HTTP de entrada passa por ele antes de ser manipulada pelo código do aplicativo. Este módulo lida com várias coisas para o seu aplicativo:
- Autentica usuários e clientes com o(s) provedor(es) de identidade especificado(s)
- Valida, armazena e atualiza tokens OAuth emitidos pelo(s) provedor(es) de identidade configurado(s)
- Gerencia a sessão autenticada
- Injeta informações de identidade em cabeçalhos de solicitação HTTP
O módulo é executado separadamente do código do aplicativo e pode ser configurado usando as configurações do Azure Resource Manager ou usando um arquivo de configuração. Não são necessários SDKs, linguagens de programação específicas ou alterações no código do aplicativo.
Nota
No Linux e contêineres, o módulo de autenticação e autorização é executado em um contêiner separado, isolado do código do aplicativo. Como ele não é executado em processo, nenhuma integração direta com estruturas de linguagem específicas é possível.
Fluxo de autenticação
O fluxo de autenticação é o mesmo para todos os provedores, mas difere dependendo se você deseja entrar com o SDK do provedor.
Sem SDK do provedor: o aplicativo delega a entrada federada ao Serviço de Aplicativo. Este é normalmente o caso dos aplicativos do navegador, que podem apresentar a página de login do provedor para o usuário. O código do servidor gerencia o processo de entrada, por isso também é chamado de fluxo direcionado ao servidor ou fluxo do servidor.
Com o SDK do provedor: o aplicativo conecta os usuários ao provedor manualmente e, em seguida, envia o token de autenticação ao Serviço de Aplicativo para validação. Normalmente, esse é o caso de aplicativos sem navegador, que não podem apresentar a página de login do provedor ao usuário. O código do aplicativo gerencia o processo de entrada, por isso também é chamado de fluxo direcionado ao cliente ou fluxo do cliente. Isso se aplica a APIs REST, Azure Functions, clientes de navegador JavaScript e aplicativos móveis nativos que conectam usuários usando o SDK do provedor.
A tabela a seguir mostra as etapas do fluxo de autenticação.
| Passo | Sem SDK do provedor | Com SDK do provedor |
|---|---|---|
| Iniciar sessão do utilizador | Redireciona o cliente para /.auth/login/<provider>. |
O código do cliente conecta o usuário diretamente com o SDK do provedor e recebe um token de autenticação. Para obter informações, consulte a documentação do provedor. |
| Pós-autenticação | O provedor redireciona o cliente para /.auth/login/<provider>/callback. |
O código do cliente publica o token do provedor para validação /.auth/login/<provider> . |
| Estabelecer sessão autenticada | O Serviço de Aplicativo adiciona cookie autenticado à resposta. | O Serviço de Aplicativo retorna seu próprio token de autenticação para o código do cliente. |
| Veicular conteúdo autenticado | O cliente inclui cookie de autenticação em solicitações subsequentes (tratadas automaticamente pelo navegador). | O código do cliente apresenta o token de autenticação no X-ZUMO-AUTH cabeçalho (manipulado automaticamente pelos SDKs de cliente de Aplicativos Móveis). |
Para navegadores cliente, o Serviço de Aplicativo pode direcionar automaticamente todos os usuários não autenticados para o /.auth/login/<provider>. Você também pode apresentar aos usuários um ou mais /.auth/login/<provider> links para entrar em seu aplicativo usando o provedor de sua escolha.
Comportamento de autorização
No portal do Azure, você pode configurar o Serviço de Aplicativo com muitos comportamentos quando uma solicitação de entrada não é autenticada.
Permitir solicitações não autenticadas: esta opção adia a autorização de tráfego não autenticado para o código do aplicativo. Para solicitações autenticadas, o Serviço de Aplicativo também passa informações de autenticação nos cabeçalhos HTTP. Esta opção proporciona mais flexibilidade no tratamento de pedidos anónimos. Permite-lhe apresentar vários fornecedores de início de sessão aos seus utilizadores.
Exigir autenticação: esta opção rejeita qualquer tráfego não autenticado para o seu aplicativo. Essa rejeição pode ser uma ação de redirecionamento para um dos provedores de identidade configurados. Nesses casos, um cliente de navegador é redirecionado para o provedor escolhido
/.auth/login/<provider>. Se a solicitação anônima vier de um aplicativo móvel nativo, a resposta retornada será umHTTP 401 Unauthorizedarquivo . Você também pode configurar a rejeição como umHTTP 401 UnauthorizedouHTTP 403 Forbiddenpara todas as solicitações.Atenção
Restringir o acesso dessa forma se aplica a todas as chamadas para seu aplicativo, o que pode não ser desejável para aplicativos que desejam uma home page disponível publicamente, como em muitos aplicativos de página única.
Arquivo de tokens
O Serviço de Aplicativo fornece um repositório de tokens interno, que é um repositório de tokens associados aos usuários de seus aplicativos Web, APIs ou aplicativos móveis nativos. Quando você habilita a autenticação com qualquer provedor, esse armazenamento de tokens fica imediatamente disponível para seu aplicativo.
Registo e rastreio
Se você habilitar o log de aplicativos, os rastreamentos de autenticação e autorização serão coletados diretamente em seus arquivos de log. Se vir um erro de autenticação que não esperava, pode encontrar convenientemente todos os detalhes consultando os registos de aplicações existentes.