Partilhar via

Obter autorização para aceder a recursos

Este artigo ajuda-o, enquanto programador, a perceber como garantir melhor a Zero Trust ao adquirir permissões de acesso a recursos para a sua aplicação. Para aceder a recursos protegidos, como emails ou dados de calendário, a sua aplicação necessita da autorização do proprietário do recurso. O proprietário do recurso pode consentir ou negar o pedido da sua aplicação. A sua aplicação recebe um token de acesso quando o proprietário do recurso dá consentimento; A sua aplicação não recebe um token de acesso quando o proprietário do recurso nega o acesso.

Revisão conceptual

Pode usar a Microsoft Identity Platform para autenticar e autorizar as suas aplicações, bem como gerir permissões e consentimentos. Vamos começar com alguns conceitos:

  • A autenticação (por vezes abreviada para AuthN) é o processo de provar que a sua identidade alegada é correta. A plataforma de identidade Microsoft utiliza o protocolo OpenID Connect para gerir a autenticação. A autorização (por vezes abreviada para AuthZ) concede a uma parte autenticada permissão para fazer algo. Especifica a quais dados pode aceder a parte autenticada. A plataforma de identidade Microsoft utiliza o protocolo OAuth2.0 para gerir a autorização. As opções de autorização incluem listas de controlo de acesso (ACL), controlo de acesso baseado em funções e controlo de acesso por atributos (ABAC). A autenticação é frequentemente um fator de autorização.

  • O acesso delegado (atuando em nome de um utilizador iniciado) ou o acesso direto (atuando apenas como identidade própria da aplicação) permite que a sua aplicação aceda aos dados. O acesso delegado requer permissões delegadas (também conhecidas como escopos). O cliente e o utilizador devem estar autorizados separadamente para fazer o pedido. O acesso direto pode exigir permissões de aplicação (também conhecidas como papéis de aplicação). Quando as aplicações recebem funções de aplicação, podem ser chamadas de permissões de aplicação.

  • Permissões delegadas, usadas com acesso delegado, permitem que uma aplicação atue em nome de um utilizador, acedendo apenas ao que o utilizador pode acedecer. A permissão da aplicação, usada com acesso direto, permite a uma aplicação aceder a quaisquer dados com os quais a permissão esteja associada. Somente administradores e proprietários de entidades de serviço podem consentir em permissões de aplicativos.

  • Consentimento é a forma como as candidaturas recebem permissões. Utilizadores ou administradores autorizam uma aplicação a aceder a um recurso protegido. Um pedido de consentimento lista as permissões que a candidatura requer, juntamente com informações do editor.

  • A pré-autorização é a forma como os proprietários das aplicações de recursos concedem acesso às aplicações clientes. Podem fazê-lo no portal Azure ou com PowerShell e APIs como o Microsoft Graph. Podem conceder permissões de recursos sem exigir que os utilizadores vejam um pedido de consentimento para o conjunto de permissões pré-autorizadas .

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

As aplicações funcionam em dois modos: quando um utilizador está presente (permissão delegada) e quando não há utilizador (permissão de aplicação). Quando há um utilizador à frente de uma aplicação, és obrigado a agir em nome desse utilizador. Não deves agir em nome da própria candidatura. Quando um utilizador dirige a sua aplicação, está a agir como delegado desse utilizador. Está a receber permissão para agir em nome do utilizador que o token identifica.

Aplicações do tipo serviço (tarefas em segundo plano, daemons, processos servidor-para-servidor) não têm utilizadores que se identifiquem ou digitem uma palavra-passe. É necessário um pedido de permissão para agir em nome próprio (em nome do pedido de serviço).

Melhores práticas de autorização de aplicações Zero Trust

A sua abordagem de autorização inclui a autenticação como componente quando se conecta a um utilizador presente na aplicação e ao recurso que está a aceder. Quando a sua aplicação atua em nome de um utilizador, não confiamos numa aplicação que nos chama para nos dizer quem é o utilizador ou deixar que a aplicação decida quem é. O Microsoft Entra ID verifica e fornece diretamente informações sobre o utilizador no token.

Quando precisa de permitir que a sua aplicação chame uma API ou autorize a sua aplicação para que esta possa aceder a um recurso, os esquemas modernos de autorização podem exigir autorização através de um quadro de permissões e consentimento. Consulte as melhores práticas de segurança para propriedades da aplicação que incluem URI de redirecionamento, tokens de acesso (usados para fluxos implícitos), certificados e segredos, URI do ID da aplicação e propriedade da aplicação.

Próximos passos

  • Last updated on