Partilhar via

Obter autorização para acessar recursos

  • Artigo

Este artigo ajuda você, como desenvolvedor, a entender a melhor forma de garantir o Zero Trust ao adquirir permissões de acesso a recursos para seu aplicativo. Para acessar recursos protegidos, como e-mail ou dados de calendário, seu aplicativo precisa da autorização do proprietário do recurso. O proprietário do recurso pode consentir ou negar a solicitação do seu aplicativo. Seu aplicativo recebe um token de acesso quando o proprietário do recurso concede consentimento; Seu aplicativo não recebe um token de acesso quando o proprietário do recurso nega o acesso.

Revisão conceptual

Você pode usar a plataforma de identidade da Microsoft para autenticar e autorizar seus aplicativos e gerenciar permissões e consentimento. Vamos começar com alguns conceitos:

  • A autenticação (às vezes abreviada para AuthN) é o processo de provar que sua identidade reivindicada é precisa. A plataforma de identidade da Microsoft usa o protocolo OpenID Connect para lidar com a autenticação. A autorização (às vezes abreviada para AuthZ) concede a uma parte autenticada permissão para fazer algo. Ele especifica quais dados a parte autenticada pode acessar. A plataforma de identidade da Microsoft usa o protocolo OAuth2.0 para lidar com a autorização. As opções de autorização incluem listas de controle de acesso (ACL), controle de acesso baseado em função e controle de acesso de atributo (ABAC). A autenticação é muitas vezes um fator de autorização.

  • O acesso delegado (agindo em nome de um usuário conectado) ou o acesso direto (agindo apenas como a própria identidade do aplicativo) permite que seu aplicativo acesse dados. O acesso delegado requer permissões delegadas (também conhecidas como escopos), o cliente e o usuário devem ser autorizados separadamente a fazer a solicitação. O acesso direto pode exigir permissões de aplicativo (também conhecidas como funções de aplicativo); quando as funções de aplicativo são concedidas a aplicativos, elas podem ser chamadas de permissões de aplicativos.

  • As permissões delegadas, usadas com acesso delegado, permitem que um aplicativo aja em nome de um usuário, acessando apenas o que o usuário pode acessar. A permissão do aplicativo, usada com acesso direto, permite que um aplicativo acesse quaisquer dados aos quais a permissão esteja associada. Somente administradores e proprietários de entidades de serviço podem consentir com permissões de aplicativos.

  • O consentimento é a maneira pela qual os aplicativos recebem permissões. Os usuários ou administradores autorizam um aplicativo a acessar um recurso protegido. Um prompt de consentimento lista as permissões que o aplicativo requer junto com as informações do editor.

  • A pré-autorização é a maneira pela qual os proprietários de aplicativos de recursos concedem acesso aos aplicativos cliente. Eles podem fazer isso no portal do Azure ou usando o PowerShell e APIs como o Microsoft Graph. Eles podem conceder permissões de recursos sem exigir que os usuários vejam um prompt de consentimento para o conjunto de permissões pré-autorizadas .

Diferença entre permissão delegada e permissão de aplicativo

Os aplicativos funcionam em dois modos: quando um usuário está presente (permissão delegada) e quando não há usuário (permissão do aplicativo). Quando há um usuário na frente de um aplicativo, você é obrigado a agir em nome desse usuário; Você não deve agir em nome do próprio aplicativo. Quando um usuário está direcionando seu aplicativo, você está agindo como o delegado para esse usuário. Você está recebendo permissão para agir em nome do usuário que o token identifica.

Os aplicativos de tipo de serviço (tarefas em segundo plano, daemons, processos de servidor para servidor) não têm usuários que possam se identificar ou digitar uma senha. Eles exigem uma permissão de aplicativo para agir em nome próprio (em nome do aplicativo de serviço).

Práticas recomendadas de autorização de aplicativos Zero Trust

Sua abordagem de autorização tem a autenticação como um componente quando você se conecta a um usuário presente ao aplicativo e ao recurso que está chamando. Quando seu aplicativo está agindo em nome de um usuário, não confiamos em um aplicativo de chamada para nos dizer quem é o usuário ou deixar o aplicativo decidir quem é o usuário. O Microsoft Entra ID verifica e fornece diretamente informações sobre o usuário no token.

Quando você precisa permitir que seu aplicativo chame uma API ou autorize seu aplicativo para que o aplicativo possa acessar um recurso, os esquemas de autorização modernos podem exigir autorização por meio de uma estrutura de permissão e consentimento. Referência Práticas recomendadas de segurança para propriedades de aplicativos que incluem URI de redirecionamento, tokens de acesso (usados para fluxos implícitos), certificados e segredos, URI de ID de aplicativo e propriedade do aplicativo.

Próximos passos

  • Personalizar tokens descreve as informações que você pode receber nos tokens do Microsoft Entra. Ele explica como personalizar tokens para melhorar a flexibilidade e o controle e, ao mesmo tempo, aumentar a segurança de confiança zero do aplicativo com o menor privilégio.
  • Configurar declarações de grupo e funções de aplicativo em tokens mostra como configurar seus aplicativos com definições de função de aplicativo e atribuir grupos de segurança a funções de aplicativo. Esses métodos ajudam a melhorar a flexibilidade e o controle e, ao mesmo tempo, aumentam a segurança de confiança zero do aplicativo com o menor privilégio.
  • Desenvolver a estratégia de permissões delegadas ajuda você a implementar a melhor abordagem para gerenciar permissões em seu aplicativo e desenvolver usando os princípios Zero Trust.
  • Desenvolver a estratégia de permissões de aplicativo ajuda você a decidir sobre a abordagem de permissões de aplicativo para o gerenciamento de credenciais.
  • Fornecer credenciais de identidade de aplicativo quando não há nenhum usuário explica por que as Identidades Gerenciadas para recursos do Azure são a melhor prática de credenciais de cliente para serviços (aplicativos não usuários) no Azure.
  • As práticas recomendadas de autorização ajudam você a implementar os melhores modelos de autorização, permissão e consentimento para seus aplicativos.
  • Use as práticas recomendadas de desenvolvimento de gerenciamento de acesso e identidade Zero Trust em seu ciclo de vida de desenvolvimento de aplicativos para criar aplicativos seguros.
  • A criação de aplicativos com uma abordagem Zero Trust para identidade continua a partir do artigo Zero Trust sobre práticas recomendadas de desenvolvimento de gerenciamento de identidade e acesso para ajudá-lo a usar uma abordagem Zero Trust para identidade em seu ciclo de vida de desenvolvimento de software (SDLC).