Compartilhar via

Visão geral de permissões e consentimento da plataforma de identidade da Microsoft

  • Artigo

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. Reconhecer esses conceitos fundamentais ajudará você a criar aplicativos mais seguros e confiáveis que solicitam apenas o acesso necessário, quando precisam, de usuários e administradores.

Cenários de acesso

Como desenvolvedor de aplicativos, você deve identificar como seu aplicativo acessará os dados. O aplicativo pode usar o acesso delegado, atuando em nome de um usuário conectado, ou o acesso somente ao aplicativo, atuando apenas como a própria identidade do aplicativo.

A imagem mostra a ilustração de cenários de acesso.

Acesso delegado (acesso em nome de um usuário)

Nesse cenário de acesso, um usuário entrou em um aplicativo cliente. O aplicativo cliente acessa o recurso em nome do usuário. O acesso delegado requer permissões delegadas. O cliente e o usuário devem ser autorizados separadamente a fazer a solicitação. Para obter mais informações sobre o cenário de acesso delegado, consulte cenário de acesso delegado.

Para o aplicativo cliente, as permissões delegadas corretas devem ser concedidas. As permissões delegadas também podem ser denominadas escopos. Escopos são permissões para um determinado recurso que representa o que um aplicativo cliente pode acessar em nome do usuário. Para obter mais informações sobre escopos, consulte escopos e permissões.

Para o usuário, a autorização depende dos privilégios concedidos pelo usuário para que ele acesse o recurso. Por exemplo, o usuário pode ser autorizado a acessar recursos de diretório pelo RBAC (controle de acesso baseado em função) do Microsoft Entra ou a acessar recursos de email e calendário pelo RBAC do Exchange Online. Para obter mais informações sobre o RBAC para aplicativos, consulte RBAC para aplicativos.

Acesso somente ao aplicativo (acesso sem um usuário)

Nesse cenário de acesso, o aplicativo atua por conta própria sem nenhum usuário conectado. O acesso do aplicativo é usado em cenários como automação e backup. Esse cenário inclui aplicativos executados como serviços ou daemons em segundo plano. É apropriado quando não for desejável ter um usuário específico conectado ou quando os dados necessários não puderem ser definidos para um único usuário. Para obter mais informações sobre o cenário de acesso somente de aplicativo, consulte Acesso somente de aplicativo.

O acesso somente ao aplicativo usa funções de aplicativo em vez de escopos delegados. Quando concedidas por meio do consentimento, as funções de aplicativo também podem ser chamadas de permissões de aplicativos. O aplicativo cliente deve receber as permissões de aplicativo adequadas do aplicativo de recurso que está chamando. Depois disso ser concedido, o aplicativo cliente pode acessar os dados solicitados. Para obter mais informações sobre como atribuir funções de aplicativo a aplicativos cliente, consulte Atribuindo funções de aplicativo a aplicativos.

Tipos de permissões

As permissões delegadas são usadas no cenário de acesso delegado. Elas permitem que o aplicativo opere em nome de um usuário. O aplicativo nunca poderá acessar nada que o usuário conectado não possa acessar.

Por exemplo, use um aplicativo que recebeu a permissão delegada Files.Read.All em nome do usuário. O aplicativo só poderá ler os arquivos que o usuário pode acessar pessoalmente.

As permissões de aplicativo, também conhecidas como funções de aplicativo, são usadas no cenário de acesso somente ao aplicativo sem um usuário conectado presente. O aplicativo poderá acessar todos os dados aos quais a permissão está associada.

Por exemplo, um aplicativo concedeu a permissão de aplicativo da API do Graph Files.Read.All poderão ler qualquer arquivo no locatário usando o Microsoft Graph. Em geral, somente um administrador ou proprietário da entidade de serviço de uma API pode consentir com as permissões de aplicativo expostas por essa API.

Comparação de permissões delegadas e de aplicativo

Tipos de permissões Permissões delegadas Permissões do aplicativo
Tipos de aplicativos Web / Móvel / SPA (aplicativo de página única) Web / Daemon
Contexto de acesso Obter acesso em nome de um usuário Obter acesso sem um usuário
Quem pode consentir – Os usuários podem consentir para seus dados
– Os administradores podem consentir para todos os usuários		 Apenas o administrador pode consentir
Métodos de consentimento – Estático: lista configurada no registro do aplicativo
– Dinâmico: solicitar permissões individuais no logon		 – SOMENTE estático: lista configurada no registro do aplicativo
Outros nomes – Escopos
– Escopos de permissão OAuth2		 – Funções de aplicativo
– Permissões somente de aplicativo
Resultado do consentimento (específico do Microsoft Graph) OAuth2PermissionGrant appRoleAssignment

Uma maneira dos aplicativos receberem permissões é por consentimento. O consentimento é um processo em que os usuários ou administradores autorizam um aplicativo a acessar um recurso protegido. Por exemplo, quando um usuário tenta entrar em um aplicativo pela primeira vez, o aplicativo pode solicitar permissão para ver o perfil do usuário e ler o conteúdo da caixa de correio do usuário. O usuário vê a lista de permissões que o aplicativo está solicitando por meio de um prompt de consentimento. Outros cenários em que os usuários podem ver um prompt de consentimento incluem:

  • Quando o consentimento concedido anteriormente é revogado.
  • Quando o aplicativo é codificado para solicitar especificamente o consentimento durante cada entrada.
  • Quando o aplicativo usa o consentimento dinâmico para solicitar novas permissões conforme necessário no tempo de execução.

Os principais detalhes de um prompt de consentimento são a lista de permissões exigidas pelo aplicativo e as informações do editor. Para obter mais informações sobre o prompt de consentimento e a experiência de consentimento para administradores e usuários finais, consulte a experiência de consentimento do aplicativo.

O consentimento do usuário ocorre quando um usuário tenta entrar em um aplicativo. O usuário fornece suas credenciais de entrada, que são verificadas para determinar se o consentimento já foi concedido. Se não houver nenhum registro anterior de consentimento do usuário ou do administrador para as permissões necessárias, será exibido para o usuário um prompt de consentimento e o mesmo será solicitado a conceder ao aplicativo as permissões solicitadas. Um administrador pode ser solicitado a consentir em nome do usuário.

Dependendo das permissões necessárias, alguns aplicativos podem exigir que um administrador seja aquele que concede consentimento. Por exemplo, as permissões de aplicativo e muitas permissões delegadas de privilégio elevado só podem ser concedidas por um administrador.

Os administradores podem consentir para si ou para toda a organização. Para obter mais informações sobre o consentimento do usuário e do administrador, confira a visão geral do consentimento do usuário e do administrador.

As solicitações de autenticação serão solicitadas para o consentimento do administrador, caso o mesmo não seja concedido e uma dessas permissões de alto privilégio for solicitada.

As solicitações de permissão que contêm escopos de aplicativo personalizados não são consideradas de alto privilégio e, portanto, não exigem consentimento do administrador.

Pré-autorização

A pré-autorização permite que um proprietário de aplicativo de recurso conceda permissões sem exigir que os usuários vejam um prompt de consentimento para o mesmo conjunto de permissões que foram pré-autorizadas. Dessa forma, um aplicativo que foi pré-autorizado não solicitará que os usuários consintam com as permissões. Os proprietários de recursos podem pré-autorizar aplicativos cliente no portal do Azure ou usando o PowerShell e APIs, como o Microsoft Graph.

Outros sistemas de autorização

A estrutura de consentimento é apenas uma maneira de um aplicativo ou usuário ser autorizado a acessar recursos protegidos. Os administradores devem estar cientes de outros sistemas de autorização que podem conceder acesso a informações confidenciais. Exemplos de vários sistemas de autorização na Microsoft incluem funções internas do Entra, RBAC do Azure, RBAC do Exchange e consentimento específico do recurso do Teams.

Confira também