Compartilhar via

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

  • Artigo

Neste artigo, discutiremos a autorização quando uma pessoa interage com um aplicativo e o direciona, quando a API (interface de programação de aplicativo) atua para um usuário. Também vamos falar sobre aplicativos ou serviços que funcionam de maneira independente. Este é o quarto artigo de uma série sobre como os ISVs (desenvolvedores de software independentes) criam e otimizam aplicativos para o Microsoft Entra ID. Nesta série, você pode conhecer melhor estes tópicos:

Autorização em aplicativos

Nesta seção, abordaremos cenários nos quais uma pessoa interage com um aplicativo e o direciona. A seção Autorização em recursos (APIs) descreve como as APIs realizam a autorização quando o usuário precisa dela para acessar um recurso, mas o Microsoft Entra ID não realiza a autorização final. A seção Autorização em cargas de trabalho aborda cenários em que aplicativos ou serviços funcionam de maneira independente.

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 em 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 ao Microsoft Entra ID para acessar operações específicas em 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 a do Microsoft Graph, do Armazenamento do Azure ou sua própria API. No entanto, a maioria das APIs tem várias operações, como leitura e gravação. Quando um aplicativo somente lê em uma API, ele só deve ter autorização para operações de leitura. Essa abordagem protege o aplicativo contra comprometimento e uso para obter mais acesso do que o desenvolvedor pretendia. O desenvolvedor está seguindo o princípio de privilégio mínimo quando o aplicativo autoriza apenas para as operações necessárias.

Para designar quais são as operações específicas em uma API que um aplicativo requer, os desenvolvedores usam o parâmetro de escopo de uma solicitação OAuth 2.0. O designer de API publica os escopos que um aplicativo pode solicitar como parte do registro de aplicativo da API. Veja no exemplo seguir, os escopos incluídos no serviço do Microsoft Power BI.

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 todas as capacidades do Power BI Premium e do Power BI Embedded às quais o usuário conectado tem acesso.

Se um aplicativo apenas lê as capacidades, o aplicativo solicitará o escopo https://analysis.windows.net/powerbi/api/Capacity.Read.All. Se um aplicativo edita a capacidade, o aplicativo 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 escopos para o Microsoft Graph sem o componente de escopo da API. Por exemplo, o Microsoft Graph define um escopo https://graph.microsoft.com/Files.Read com o qual os aplicativos podem solicitar Files.Read em vez de usar o nome de escopo completo.

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

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

Durante o design do escopo, um designer de API pode indicar escopos para os quais somente um administrador pode consentir. Escopos que exigem consentimento do administrador representam operações que o designer de API considera mais confidenciais, poderosas ou com ação ampla 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 os escopos que exigem consentimento do administrador, eles não têm a palavra final. Quando um designer de API indica que um escopo requer consentimento do administrador, o escopo sempre vai requerer consentimento do administrador. Para escopos que o designer de API não indica que exigem consentimento do administrador, o administrador do locatário pode exigir consentimento do administrador, ou o consentimento step-up baseado em risco pode determinar o requisito de consentimento do administrador. Os desenvolvedores não podem prever se uma solicitação de token requer 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 negação de solicitação de token. Os aplicativos sempre devem lidar com naturalidade com o não recebimento de um token.

Se o usuário ou o administrador não tiver dado consentimento, o usuário verá uma solicitação de consentimento, conforme mostrado no exemplo a seguir.

Captura de tela da solicitação de consentimento do usuário.

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

Captura de tela da solicitação de consentimento do administrador.

Os aplicativos controlam o tempo das solicitações de consentimento do usuário. o Microsoft Entra ID dá suporte ao consentimento estático: quando um aplicativo usa o escopo .default, o aplicativo solicita todas as permissões declaradas no registro do aplicativo. Com o consentimento estático, seu aplicativo solicita antecipadamente todas as permissões que ele pode precisar.

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

Por exemplo, um aplicativo pode solicitar https://graph.microsoft.com/user.read para conectar o usuário e acessar o perfil do usuário quando o aplicativo for iniciado. Posteriormente, 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ê a razão pela qual um aplicativo está pedindo para gravar no OneDrive, ele concede a permissão e o aplicativo salva um arquivo no OneDrive do usuário. Em seguida, o usuário fecha o aplicativo. Na próxima vez que o aplicativo for iniciado, ele solicitará https://graph.microsoft.com/user.read. O Microsoft Entra ID retornará um token de acesso com os escopos https://graph.microsoft.com/user.read e https://graph.microsoft.com/files.readwrite. Uma solicitação de token para o escopo https://graph.microsoft.com/files.readwrite não requer consentimento, pois o usuário já o concedeu. O cache de tokens na MSAL (Biblioteca de Autenticação da Microsoft) manipula automaticamente tokens de cache com base nas permissões concedidas. Neste exemplo, após a reinicialização do aplicativo, as chamadas à MSAL para adquirir um token com o escopo https://graph.microsoft.com/files.readwrite retornam o token armazenado em cache da solicitação inicial do aplicativo para o escopo https://graph.microsoft.com/user.read. Outra chamada para o Microsoft Entra ID é desnecessária.

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

Para dar consentimento de administrador para um aplicativo, o Centro de administração do Microsoft Entra usa o consentimento estático solicitando consentimento com o escopo .default de um aplicativo. Os administradores não podem dar consentimento do administrador no Centro de administração do Microsoft Entra para aplicativos que exigem permissões se os desenvolvedores não as declararem no registro do aplicativo.

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 de aplicativo nativas. Os administradores de locatários podem ter todos os aplicativos de nuvem como destino ou usar atributos de segurança personalizados para ter aplicativos nativos como destino usando políticas de Acesso Condicional. Mesmo quando direcionada de outra forma, a imposição de política não inclui alguns aplicativos que acessam o Microsoft Graph ou o Azure AD Graph.

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

  • Aplicativos que executam o fluxo on-behalf-of, ou seja, usam uma identidade delegada
  • Aplicativos que acessam vários serviços ou recursos
  • Aplicativos de página única que usam MSAL.js
  • Aplicativos Web que chamam um recurso

Se seu aplicativo implementa qualquer um desses cenários, examine as Diretrizes para desenvolvedores 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 locatário 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 teste. Há diretrizes para criar um locatário de teste.

Por padrão, as políticas de Acesso Condicional servem para aplicativos e 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 financeiro pode exigir autenticação multifator para uso no dia a dia. No entanto, uma transação com um valor especificado pode exigir um dispositivo gerenciado. Os desenvolvedores podem permitir que os administradores de TI atribuam políticas de Acesso Condicional de step-up a diferentes áreas de um aplicativo implementando o 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 válidos por um tempo definido. Os aplicativos nunca devem assumir um tempo de vida sem limitação. Eles devem usar o parâmetro expires_in que o Microsoft Entra ID retorna com o token de acesso. A MSAL controla automaticamente esse cenário. Durante o tempo de vida do token de acesso, o usuário tem autorização para acessar o recurso nas condições estabelecidas no momento da autorização.

O atraso entre o momento em que as condições mudam e o momento em que ocorre a imposição de alterações 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 do dispositivo perdido pode continuar a acessar o Microsoft Graph para o usuário até que o token expire. A CAE (avaliação contínua de acesso) da Microsoft é uma forma de impedir o acesso após a revogação das sessões do usuário para aplicativos que a adotam. Se seu aplicativo chamar o Microsoft Graph pelo menos uma vez por hora, você poderá adotar a CAE. Como usar APIs habilitadas para Avaliação contínua de acesso em seus aplicativos fornece detalhes da implementação.

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

Se você criar aplicativos de dispositivo móvel, examine Compatibilidade com SSO e políticas de proteção de aplicativos em aplicativos móveis. Saiba como dar suporte à aquisição de token, ao MAM (gerenciamento de aplicativos móveis) do Intune e às políticas de proteção de aplicativo.

Autorização em recursos (APIs)

A seção Autorização em aplicativos apresentou três autorizações necessárias quando os aplicativos precisam acessar recursos para um usuário, mas abordou 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 atuar para um usuário:

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

Recomendamos as declarações oid e sub para autorização.

O Microsoft Entra ID implementa uma declaração sub em par, portanto, a declaração sub é um identificador de usuário exclusivo para o aplicativo solicitante. O mesmo usuário que usa um aplicativo diferente tem uma declaração sub diferente. A declaração oid é constante para o usuário em todos os aplicativos.

Os aplicativos fornecem o token de acesso necessário às APIs que o Microsoft Entra ID protege 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 que está chamando como não confiável até a validação do token. Os artigos de referência de token de acesso e referência de validação de declarações fornecem detalhes sobre como validar 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 trocadas periodicamente e sempre que a situação requer a sobreposição da chave pública. Seu aplicativo nunca deve assumir um prazo definido para a sobreposição de chave pública. Para saber como lidar corretamente com a substituição de chave pública, confira Sobreposição da chave de assinatura na plataforma de identidade da Microsoft.

É recomendável usar uma biblioteca com boa manutenção para executar a validação de token. Se você estiver criando um aplicativo Web ou uma API no ASP.NET ou ASP.NET Core, use Microsoft.Identity.Web para lidar com a validação de token. O artigo de instruções API 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 do Microsoft Entra ID para determinar a identidade do usuário atual. Essa abordagem impede o comprometimento do aplicativo em que os usuários representem 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 On Behalf of OAuth para adquirir um token de acesso e chamar uma API para o usuário para o qual a API foi chamada. O artigo Criar uma API Web que chama APIs Web mostra as etapas para uma API chamar outras APIs para o usuário atual do aplicativo.

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

Autorização em cargas de trabalho

As cargas de trabalho são aplicativos que funcionam de maneira independente e não têm um usuário atual. Assim como o acesso delegado discutido na seção Autorização em aplicativos, o acesso somente ao aplicativo requer várias autorizações:

  • O aplicativo deve ter autorização para acessar operações específicas em 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 escopo .default (como https://graph.microsoft.com/.default). Ao contrário do acesso delegado (os aplicativos podem solicitar escopos dinâmica e incrementalmente), as cargas de trabalho devem sempre usar o consentimento estático e o escopo .default.

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 chamado aplicativos, o que permite atribuição de função a cargas de trabalho. Atribua funções a cargas de trabalho no centro de administração do Microsoft Entra ou com o 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, a 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 ficam relutantes 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 identidades gerenciadas remove 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 comprometimento.

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 adquirir novos tokens antes que eles expirem. As identidades gerenciadas usam pontos de extremidade regionais, que ajudam a evitar falhas fora da região com a consolidação de dependências de serviço. Os pontos de extremidade regionais ajudam a manter o tráfego em uma área geográfica. Por exemplo, se seu recurso Azure está em WestUS2, todo o tráfego permanece em WestUS2.

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

O Microsoft Entra ID dá suporte a esses tipos de credencial de cliente:

  • Certificado. As cargas de trabalho provam que têm a posse de uma chave privada assinando uma declaração com a chave privada. A chave privada não é transmitida para o Microsoft Entra ID. Somente a declaração é enviada. Recomendamos certificados em vez de segredos do cliente, pois eles são mais seguros e, geralmente, melhor gerenciados.
  • Credencial federada. A federação de identidade da 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, do GitHub Actions ou do cluster Kubernetes. As cargas de trabalho solicitam tokens da mesma forma para credenciais federadas e para credenciais de certificado. A diferença é que a declaraçã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 do 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 certificados ou a federação de identidade 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 do Microsoft Entra inclui o Microsoft Entra Workload ID. O Microsoft Entra Workload ID tem os recursos premium a seguir para aprimorar a segurança da carga de trabalho.

  • O Acesso Condicional é compatível com políticas baseadas em locais ou risco para identidades de carga de trabalho.
  • A Proteção de identidade fornece relatórios de credenciais comprometidas, entradas anômalas e alterações suspeitas nas contas.
  • As Revisões de acesso habilitam a delegação de revisões para as pessoas certas, com foco nas funções privilegiadas mais importantes.
  • As Recomendações de integridade do aplicativo sugerem maneiras de resolver as lacunas de higiene de identidade em seu portfólio de aplicativos e melhorar a postura de segurança e resiliência do locatário.

As cargas de trabalho podem dar suporte à CAE (Avaliação contínua de acesso) se chamarem o Microsoft Graph pelo menos uma vez por hora. Para dar suporte à CAE, a carga de trabalho deve ser um único aplicativo de locatário e o aplicativo deve ser registrado no locatário em que ele está acessando o Microsoft Graph. Se sua carga de trabalho atender a esses requisitos, veja as etapas de implementação neste exemplo.

Próximas etapas