Adquirindo autorização para acessar recursos

  • Artigo

Este artigo ajudará você, como desenvolvedor, a entender a melhor forma de garantir a Confiança Zero ao adquirir permissões de acesso a recursos para seu aplicativo. Para acessar um recurso protegido, como dados de email ou 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 aplicativo. Seu aplicativo receberá um token de acesso quando o proprietário do recurso conceder consentimento; Seu aplicativo não receberá um token de acesso quando o proprietário do recurso negar acesso.

Revisão conceitual

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

  • Autenticação (às vezes abreviada como AuthN) é o processo de provar que sua identidade reivindicada é precisa. A plataforma de identidade da Microsoft usa o protocolo OpenID Connect para processar a autenticação. Autorização (às vezes abreviada como 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 utiliza o protocolo OAuth 2.0 para processar a autorização. Opções de autorização incluem listas de controle de acesso (ACL), controle de acesso baseado em funções e controle de acesso por atributos (ABAC). A autenticação geralmente é um fator de autorização.

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

  • Permissões delegadas, usadas com acesso delegado, permitem que um aplicativo atue em nome de um usuário, acessando somente o que o usuário pode acessar. Permissão de aplicativo, usada com acesso direto, permite que um aplicativo acesse todos os dados aos quais a permissão está associada. Apenas administradores e proprietários de entidades de segurança podem consentir com as permissões de aplicativos.

  • Aplicativos recebem permissões por meio de consentimento; usuários ou administradores autorizam um aplicativo a acessar um recurso protegido. Uma solicitação de consentimento lista as permissões que o aplicativo exige junto com as informações do fornecedor.

  • Os proprietários de aplicativos de recursos podem pré-autorizar aplicativos cliente (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 uma solicitação de consentimento para o conjunto de permissões que foram pré-autorizadas.

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

Aplicativos funcionam em dois modos: quando um usuário está presente (permissão delegada) e quando não há nenhum usuário (permissão de aplicativo). Quando há um usuário na frente de um aplicativo, você é obrigado a agir em nome desse usuário; você não deve estar agindo em nome do aplicativo em si. Quando um usuário está direcionando seu aplicativo, você está agindo como o representante desse 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 Confiança Zero

Sua abordagem de autorização terá a autenticação como um componente quando você se conectar 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 permitir que o aplicativo decida quem é o usuário. O Microsoft Entra ID verificará e fornecerá 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, esquemas de autorização modernos podem exigir autorização por meio de uma estrutura de permissão e consentimento. Práticas recomendadas de segurança de referência para propriedades de aplicativos que incluem URI de redirecionamento, tokens de acesso (usados para fluxos implícitos), certificados e segredos, URI do ID do aplicativo e propriedade do aplicativo.

Próximas etapas