Autorizar aplicativos, recursos e cargas de trabalho com o Microsoft Entra ID

Neste artigo, discutimos a autorização quando um ser humano interage e dirige um aplicativo, quando as interfaces de programação de aplicativos (API) agem para um usuário. Também cobrimos quando os aplicativos ou serviços funcionam de forma independente. É o quarto de uma série de artigos sobre como desenvolvedores independentes de software (ISVs) podem criar e otimizar seus aplicativos para o Microsoft Entra ID. Nesta série, você pode saber mais sobre estes tópicos:

Autorização em aplicações

Nesta seção, abordamos cenários nos quais um ser humano individual interage e dirige um aplicativo. A seção Autorização em recursos (APIs) descreve como as APIs executam a autorização quando o usuário precisa de autorização para acessar um recurso, mas o Microsoft Entra ID não executa a autorização final. A seção Autorização em workloads abrange cenários nos quais aplicativos ou serviços funcionam independentemente.

Os aplicativos exigem as seguintes autorizações quando precisam acessar recursos para um usuário.

  • O aplicativo deve ter autorização para acessar operações específicas dentro de recursos específicos para o usuário atual.
  • O usuário deve ter autorização para acessar um recurso nas condições atuais.
  • O usuário deve ter autorização para acessar um recurso.

O processo de autorização começa com um aplicativo que usa o OAuth 2.0 para solicitar um token de acesso do Microsoft Entra ID para acessar operações específicas dentro de um recurso específico para o usuário. No acesso delegado, um aplicativo atua como um delegado para o usuário.

Para desenvolvedores, um recurso pode ser uma API como o Microsoft Graph, o Armazenamento do Azure ou sua própria API. No entanto, a maioria das APIs tem várias operações, como leitura e escrita. Quando um aplicativo só lê de uma API, um aplicativo só deve ter autorização para operações de leitura. Essa abordagem protege um aplicativo contra comprometimento e uso para mais acesso do que o desenvolvedor pretendia. O desenvolvedor está seguindo o princípio de menor privilégio quando seu aplicativo autoriza apenas para as operações que ele exige.

Para designar quais operações específicas em uma API específica um aplicativo requer, os desenvolvedores usam o parâmetro scope de uma solicitação OAuth 2.0. O designer de API publica os escopos que um aplicativo pode solicitar como parte do registro do aplicativo da API. Por exemplo, os escopos de serviço do Microsoft Power BI incluem o seguinte.

Escopo do serviço do Power BI Operações
https://analysis.windows.net/powerbi/api/Capacity.Read.All O aplicativo pode exibir todas as capacidades do Power BI Premium e do Power BI Embedded às quais o usuário conectado tem acesso.
https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All O aplicativo pode exibir e editar todos os recursos do Power BI Premium e do Power BI Embedded aos quais o usuário conectado tem acesso.

Se um aplicativo só lê capacidades, o aplicativo solicita o https://analysis.windows.net/powerbi/api/Capacity.Read.All escopo. Se uma aplicação editar a capacidade, então a aplicação solicitará o escopo https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All.

O escopo contém a identidade da API e a identidade da operação. No escopo https://analysis.windows.net/powerbi/api/Capacity.ReadWrite.All, a API é https://analysis.windows.net/powerbi/api. A operação é Capacity.ReadWrite.All. Dado o amplo alcance e popularidade da API do Microsoft Graph, os desenvolvedores podem solicitar âmbitos para o Microsoft Graph sem a necessidade de especificar o componente API do âmbito. Por exemplo, o Microsoft Graph define um escopo com https://graph.microsoft.com/Files.Read o qual os aplicativos podem solicitar em Files.Read vez de usar o nome completo do escopo.

Para concluir a primeira autorização, um aplicativo deve ter autorização para acessar operações específicas dentro de recursos específicos para o usuário atual, o Microsoft Entra ID deve primeiro autenticar o usuário atual. O logon único (SSO) pode satisfazer essa autenticação ou pode exigir uma nova interação do usuário.

Depois que o ID do Microsoft Entra determina o usuário, ele verifica se o usuário autorizou o aplicativo para o escopo solicitado. Este processo é chamado de concessão de consentimento. Se o usuário concedeu consentimento, o processo de autorização pode continuar. O consentimento do administrador permite que os usuários administradores consintam para si mesmos e para toda a organização. O Microsoft Entra ID verifica se o aplicativo tem consentimento de administrador para um escopo. Se concedida, o processo de autorização continua.

Durante o design do escopo, um designer de API pode designar escopos para os quais apenas um administrador pode consentir. Os escopos que exigem consentimento do administrador representam operações que o designer da API considera mais sensíveis, poderosas ou amplamente implicadas o suficiente para que um usuário não administrador não tenha autoridade para conceder a um aplicativo.

Embora os designers de API tenham a primeira palavra sobre qual de seus escopos exigem o consentimento do administrador, eles não têm a palavra final. Quando um designer de API designa que um escopo requer consentimento do administrador, o escopo sempre requer o consentimento do administrador. Para escopos que o designer de API não designa como exigindo consentimento de administrador, o administrador do inquilino pode exigir o consentimento de administrador, ou o consentimento baseado em avaliação de risco pode determinar a necessidade de consentimento de administrador. Os desenvolvedores não podem prever se uma solicitação de token requer o consentimento do administrador. No entanto, essa limitação não afeta o código necessário. A negação de consentimento é apenas uma das muitas razões para a negação de solicitação de token. Os aplicativos devem sempre lidar graciosamente com o não recebimento de um token.

Se o usuário ou o administrador não tiver concedido consentimento, o usuário verá um prompt de consentimento, conforme mostrado no exemplo a seguir.

Captura de tela do prompt de consentimento do usuário.

Os prompts de consentimento do usuário administrador podem permitir que eles selecionem Consentimento em nome da sua organização para conceder consentimento a todos os usuários no locatário, conforme mostrado no exemplo a seguir.

Captura de ecrã do pedido de consentimento do administrador.

Os aplicativos controlam o tempo dos prompts de consentimento do usuário. O Microsoft Entra ID oferece suporte ao consentimento estático: quando um aplicativo usa o .default escopo, o aplicativo solicita todas as permissões declaradas no registro do aplicativo. Com o consentimento estático, seu aplicativo solicita com antecedência todas as permissões necessárias.

O consentimento estático pode desencorajar usuários e administradores de aprovar a solicitação de acesso do seu aplicativo. A prática recomendada para o processo de solicitação de consentimento é solicitar as permissões necessárias dinamicamente para a funcionalidade de linha de base em seu aplicativo na inicialização do aplicativo e solicitar mais escopos, quando necessário. Solicite incrementalmente mais escopos à medida que o aplicativo executa operações que exigem esses escopos. Essa abordagem fornece ao usuário uma melhor compreensão de outras permissões que se correlacionam com o tempo de funcionalidade. Para cada token de acesso à API, o Microsoft Entra ID inclui todos os escopos concedidos anteriormente a um aplicativo e não apenas os escopos na solicitação.

Por exemplo, um aplicativo pode solicitar https://graph.microsoft.com/user.read para entrar no usuário e acessar o perfil do usuário quando o aplicativo é iniciado. Mais tarde, um usuário seleciona Salvar no OneDrive e o aplicativo solicita https://graph.microsoft.com/files.readwrite para gravar um arquivo no OneDrive do usuário. Como o usuário vê por que um aplicativo está pedindo para gravar em seu OneDrive, o usuário concede a permissão e o aplicativo salva um arquivo no OneDrive do usuário. Em seguida, o usuário fecha o aplicativo. Da próxima vez que a aplicação for iniciada, ela solicitará https://graph.microsoft.com/user.read. O Microsoft Entra ID retorna um token de acesso com https://graph.microsoft.com/user.read e https://graph.microsoft.com/files.readwrite escopos. Uma solicitação de token para o https://graph.microsoft.com/files.readwrite escopo não requer consentimento, pois o usuário a concedeu. O cache de token nas Bibliotecas de Autenticação da Microsoft (MSAL) lida automaticamente com tokens de cache com base nas permissões concedidas. Neste exemplo, após a reinicialização do aplicativo, as chamadas para o MSAL para adquirir um token com o https://graph.microsoft.com/files.readwrite escopo retornam o token armazenado em cache da solicitação inicial do aplicativo para o https://graph.microsoft.com/user.read escopo. Outra chamada para o Microsoft Entra ID é desnecessária.

O consentimento dinâmico e incremental não requer permissões declaradas durante o registro do aplicativo. No entanto, é altamente recomendável que os aplicativos declarem quaisquer permissões que um aplicativo possa exigir em um registro de aplicativo para oferecer suporte ao consentimento estático. Os administradores podem conceder consentimento de administrador no centro de administração do Microsoft Entra, usando o Microsoft Graph PowerShell ou com a API do Microsoft Graph.

Para conceder consentimento de administrador para um aplicativo, o centro de administração do Microsoft Entra usa o consentimento estático solicitando consentimento com o escopo de .default para um aplicativo. Os administradores não podem conceder consentimento de administrador no centro de administração do Microsoft Entra a aplicações que requerem permissão se os programadores não as declararem no registo da aplicação.

Os clientes do Microsoft Entra ID podem usar políticas de Acesso Condicional para proteger recursos (APIs) e aplicativos baseados em navegador. Por padrão, os administradores não podem aplicar políticas de Acesso Condicional a autenticações nativas de aplicativos. Os administradores de locatários podem direcionar Todos os recursos (anteriormente "Todos os aplicativos na nuvem") ou usar atributos de segurança personalizados para direcionar aplicativos nativos com políticas de Acesso Condicional. Mesmo quando direcionada de outra forma, a aplicação de políticas não inclui algumas aplicações que acedem ao Microsoft Graph ou ao Azure AD Graph.

Os aplicativos geralmente não exigem código especial para Acesso Condicional, a menos que os seguintes cenários se apliquem.

  • Aplicativos que executam o fluxo em nome de
  • Aplicações que acedem a vários serviços ou recursos
  • Aplicativos de página única que usam MSAL.js
  • Aplicativos Web que chamam um recurso

Se a sua aplicação implementar qualquer um destes cenários, consulte as Orientações para programadores para o Acesso Condicional do Microsoft Entra.

Os locatários gratuitos do Microsoft Entra ID não podem utilizar o Acesso Condicional (consulte os requisitos de licenciamento. O inquilino de produção da sua empresa pode ter o licenciamento necessário. Avalie essas condições antes de usar seu locatário de produção para testes. Há orientações para criar um locatário de teste.

Por padrão, as políticas de Acesso Condicional se aplicam aos aplicativos e aos recursos que um aplicativo acessa no nível do aplicativo. Os administradores de TI podem aplicar políticas no nível do aplicativo a qualquer aplicativo sem a participação do desenvolvedor. Alguns aplicativos e cenários exigem mais granularidade. Por exemplo, um aplicativo de finanças pode exigir autenticação multifator para uso típico. No entanto, uma transação acima de um valor designado pode exigir um dispositivo gerenciado. Os desenvolvedores podem permitir que os administradores de TI atribuam políticas aprimoradas de Acesso Condicional a diferentes áreas de um aplicativo, implementando contexto de autenticação de Acesso Condicional. O guia do desenvolvedor para o contexto de autenticação de Acesso Condicional é uma boa referência para esses recursos.

Por padrão, o Microsoft Entra ID emite tokens de acesso que são válidos por um tempo definido. Os aplicativos nunca devem assumir a duração da vida útil. Eles devem usar o expires_in parâmetro que o Microsoft Entra ID retorna com o token de acesso. O MSAL lida automaticamente com esse cenário. Durante o tempo de vida do token de acesso, o usuário tem autorização para acessar o recurso sob as condições no momento da autorização.

O atraso entre quando as condições mudam e quando ocorre a aplicação da alteração de política pode preocupar administradores e usuários. Por exemplo, quando um usuário perde um dispositivo, o administrador de TI pode revogar as sessões do usuário. No entanto, um aplicativo no dispositivo perdido pode continuar a acessar o Microsoft Graph para o usuário até que o token expire. A avaliação de acesso contínuo (CAE) da Microsoft pode impedir o acesso após a revogação de sessões de usuário para aplicativos que adotam CAE. Se seu aplicativo chamar o Microsoft Graph pelo menos uma vez por hora, você poderá adotar o CAE. Como usar APIs habilitadas para Avaliação de Acesso Contínuo em seus aplicativos fornece detalhes de implementação.

Se você não puder criar no MSAL, seu aplicativo deverá usar o OAuth 2.0 para solicitar tokens de acesso da ID do Microsoft Entra. A plataforma de identidade da Microsoft e o fluxo de código de autorização OAuth 2.0 fornecem detalhes de implementação para os fluxos suportados pelo Microsoft Entra ID.

Se criar aplicações para dispositivos móveis, reveja o suporte a SSO e as políticas de proteção de aplicações nos seus aplicativos móveis. Saiba como suportar a aquisição de tokens, a gestão de aplicações móveis (MAM) do Intune e as políticas de proteção de aplicações.

Autorização em recursos (APIs)

A seção Autorização em aplicativos introduziu três autorizações necessárias quando os aplicativos precisam acessar recursos para um usuário, mas cobriu apenas as duas primeiras. O usuário deve ter autorização para acessar um recurso, mas o Microsoft Entra ID não executa a autorização final. O recurso (API) executa a autorização.

As APIs devem impor duas autorizações ao agir para um usuário:

  • As APIs devem autorizar um aplicativo a chamar a API. Verifique se a reivindicação do token de acesso scp (âmbito) contém o âmbito necessário.
  • As APIs devem autorizar o usuário a acessar o recurso específico. As oid declarações (object ID) e sub (subject) no token representam a identidade do usuário.

Recomendamos as oid e sub demandas para autorização.

O Microsoft Entra ID implementa uma afirmação par sub; portanto, a afirmação sub é um identificador exclusivo de usuário para o aplicativo solicitante. O mesmo usuário que usa um aplicativo diferente tem uma reivindicação diferente sub . A oid declaração é constante para o utilizador em todas as aplicações.

Os aplicativos fornecem o token de acesso necessário às APIs protegidas pelo Microsoft Entra ID, no cabeçalho de autorização da solicitação http, como um token de portador. As APIs devem validar totalmente o token recebido porque o token não vem diretamente do Microsoft Entra ID. Considere o aplicativo de chamada como não confiável até a validação do token. Os artigos de referência sobre token de acesso e validação de declarações fornecem detalhes sobre a validação de tokens de acesso do Microsoft Entra ID.

O Microsoft Entra ID publica as chaves públicas que as APIs usam para validar a assinatura do token. Essas chaves são renovadas periodicamente e sempre que a situação exigir a substituição da chave pública. Seu aplicativo nunca deve assumir um cronograma definido para a substituição de chave pública. A substituição de chave de assinatura na plataforma de identidade da Microsoft explica como lidar corretamente com a substituição de chave pública.

Recomendamos o uso de uma biblioteca bem mantida para executar a validação de token. Se você estiver criando um aplicativo Web ou API no ASP.NET ou no ASP.NET Core, use Microsoft.Identity.Web para manipular a validação de token. O artigo de instruções sobre a API da Web protegida explica como usar Microsoft.Identity.Web para proteger uma API.

Às vezes, as APIs precisam chamar outras APIs. Quando um aplicativo funciona para o usuário, a API recebe um token de acesso delegado que inclui a identidade do usuário atual. É importante que a API confie apenas em um token validado da ID do Microsoft Entra para determinar a identidade do usuário atual. Essa abordagem evita o comprometimento do aplicativo, de modo que os usuários se passem por outros usuários e acessem recursos para um usuário diferente. Para essa mesma proteção quando uma API chama outra API, use o fluxo Em nome do OAuth para adquirir um token de acesso para chamar uma API para o usuário para o qual a API foi chamada. Criar uma API web que chama outras APIs fornece etapas para uma API chamar outras APIs para o utilizador atual da aplicação.

Além do acesso delegado, as APIs podem precisar oferecer suporte a aplicativos e agir de forma independente, sem usuários atuais. O Microsoft Entra ID refere-se a esses aplicativos como cargas de trabalho. Para aplicar a autorização de carga de trabalho, as APIs não usam a scp (reivindicação de escopo). Em vez disso, as APIs usam a roles declaração para validar que a carga de trabalho tem o consentimento necessário. As APIs são responsáveis por garantir que a carga de trabalho tenha autorização para acessar o recurso.

Autorização em cargas de trabalho

Cargas de trabalho são aplicativos que funcionam de forma independente e não têm um usuário atual. Como o acesso delegado discutido na seção Autorização em aplicativos, o acesso somente para aplicativos requer várias autorizações:

  • O aplicativo deve ter autorização para acessar operações específicas dentro de recursos específicos.
  • O aplicativo deve ter autorização para acessar o recurso nas condições atuais.
  • O aplicativo deve ter autorização para acessar o recurso.

O processo começa com uma carga de trabalho solicitando um token de acesso com o .default escopo (como https://graph.microsoft.com/.default). Ao contrário do acesso delegado (os aplicativos podem solicitar escopos de forma dinâmica e incremental), as cargas de trabalho sempre devem usar o consentimento estático e o .default escopo.

Os designers de API criam permissões de aplicativo para sua API adicionando funções ao registro de aplicativo da API. Essas funções têm um tipo de membro permitido de aplicações, que permite a atribuição de função a cargas de trabalho. Atribua funções a tarefas no centro de administração do Microsoft Entra ou com Microsoft Graph. No centro de administração do Microsoft Entra, o consentimento do administrador para as funções atribuídas é necessário antes que a carga de trabalho possa ser executada.

Por padrão, uma permissão de aplicativo autoriza as cargas de trabalho a acessar todas as instâncias de um recurso. Por exemplo,https://graph.microsoft.com/user.read.all autoriza uma carga de trabalho a acessar o perfil de usuário completo de cada usuário no locatário. Os administradores de TI geralmente relutam em conceder essas permissões amplas.

Para cargas de trabalho que acessam o Microsoft Graph, use estes métodos para limitar a permissão do aplicativo:

Ao contrário dos aplicativos com usuários, as cargas de trabalho se autenticam no Microsoft Entra ID.

Para cargas de trabalho executadas no Microsoft Azure, o melhor método para uma carga de trabalho se autenticar são as identidades gerenciadas para recursos do Azure. O recurso de identidades gerenciadas elimina a necessidade de gerenciar credenciais para a carga de trabalho. Não há credenciais acessíveis. O Microsoft Entra ID gerencia totalmente as credenciais. Sem credenciais para gerenciar, nenhuma credencial corre o risco de ser comprometida.

Com o aumento da segurança, as identidades gerenciadas também aumentam a resiliência. As identidades gerenciadas usam tokens de acesso de longa duração e informações do Microsoft Entra ID para obter novos tokens antes que os tokens expirem. As identidades geridas utilizam endpoints regionais que ajudam a evitar falhas extraregionais ao consolidar as dependências do serviço. Os pontos finais regionais ajudam a manter o tráfego numa área geográfica. Por exemplo, se o recurso do Azure estiver no WestUS2, todo o tráfego permanecerá no WestUS2.

Se a carga de trabalho não estiver em execução no Microsoft Azure, a carga de trabalho deverá autenticar-se com o fluxo de credenciais do cliente OAuth 2.0.

O Microsoft Entra ID suporta estes tipos de credenciais de cliente:

  • Certificado. As cargas de trabalho provam que possuem uma chave privada assinando uma declaração com a chave privada. A chave privada não é transmitida para o Microsoft Entra ID. Apenas a asserção é enviada. Recomendamos certificados em vez de segredos do cliente, pois eles são mais seguros e, muitas vezes, melhor gerenciados.
  • Credencial federada. A federação de identidades de carga de trabalho permite que cargas de trabalho que não estão em execução no Microsoft Azure usem uma identidade de outro provedor de identidade, Ações do GitHub ou cluster do Kubernetes. As cargas de trabalho solicitam tokens da mesma forma para credenciais federadas e para credenciais de certificado. A diferença é que a asserção, um token Web JSON assinado, vem do provedor de identidade de federação.
  • Segredo do cliente. Às vezes chamado de senha de aplicativo, um segredo do cliente é um valor de cadeia de caracteres que a carga de trabalho pode usar para se identificar. O valor de texto do segredo é enviado da carga de trabalho para o Microsoft Entra ID em uma solicitação POST para um token. Os segredos do cliente são menos seguros do que os certificados ou a federação de identidades da carga de trabalho. Se sua carga de trabalho usa segredos, siga estas práticas recomendadas para gerenciar segredos.

Além do Microsoft Entra ID, a família de produtos Microsoft Entra inclui o Microsoft Entra Workload ID. O Microsoft Entra Workload ID tem os seguintes recursos premium para melhorar a segurança da carga de trabalho.

  • Acesso Condicional suporta políticas baseadas em local ou risco para identidades de carga de trabalho.
  • O Microsoft Entra ID Protection fornece relatórios sobre credenciais comprometidas, entradas anômalas e alterações suspeitas em contas.
  • As revisões de acesso permitem a delegação de revisões para as pessoas certas, centradas nas funções privilegiadas mais críticas.
  • Recomendações de integridade de aplicativos sugerem maneiras de resolver as lacunas na higiene de identidade no seu portfólio de aplicativos e melhorar a segurança e a postura de resiliência da sua entidade.

As cargas de trabalho podem oferecer suporte à Avaliação de Acesso Contínuo (CAE) se chamarem o Microsoft Graph pelo menos uma vez por hora. Para oferecer suporte ao CAE, a carga de trabalho deve ser uma aplicação de inquilino único e a aplicação registada no inquilino onde está a aceder ao Microsoft Graph. Se sua carga de trabalho atender a esses requisitos, consulte este exemplo para obter as etapas de implementação.

Próximos passos

  • Last updated on