Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Na plataforma de identidade da Microsoft, compreender as permissões e o consentimento é crucial para desenvolver aplicativos seguros que exigem acesso a recursos protegidos. Este artigo fornece uma visão geral dos conceitos e cenários fundamentais relacionados a permissões e consentimento, ajudando os desenvolvedores de aplicativos a solicitar as autorizações necessárias de usuários e administradores. Ao entender esses conceitos, você pode garantir que seus aplicativos solicitem apenas o acesso de que precisam, promovendo confiança e segurança.
Para acessar um recurso protegido, 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. Compreender esses conceitos fundamentais ajuda você a criar aplicativos mais seguros e confiáveis que solicitam apenas o acesso de que precisam, quando precisam, de usuários e administradores.
Cenários de acesso
Como desenvolvedor de aplicativos, você deve identificar como seu aplicativo acessa dados. A aplicação pode usar acesso delegado, agindo em nome de um utilizador autenticado, ou acesso exclusivo da aplicação, agindo apenas como a própria identidade da aplicação.
Acesso delegado (acesso em nome de um utilizador)
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. Tanto o cliente quanto o usuário devem ser autorizados separadamente para 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 chamadas de escopos. Escopos são permissões para um determinado recurso que representam 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 que lhe são concedidos para acessar 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 usuário)
Nesse cenário de acesso, o aplicativo age por conta própria sem nenhum usuário conectado. O acesso ao aplicativo é usado em cenários como automação e backup. Este cenário inclui aplicativos que são executados como serviços em segundo plano ou daemons. É apropriado quando é indesejável ter um usuário específico conectado ou quando os dados necessários não podem ser definidos para um único usuário. Para obter mais informações sobre o cenário de acesso exclusivo para aplicativos, consulte .
O acesso somente ao aplicativo usa funções de aplicativo em vez de escopos delegados. Quando concedidas por meio de consentimento, as funções do aplicativo também podem ser chamadas de permissões de aplicativos. A aplicação cliente deve receber permissões de aplicação apropriadas da aplicação de recurso a que está a chamar. Uma vez 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. São permissões que permitem que a aplicação aja em nome de um utilizador. O aplicativo não consegue acessar nada que o usuário conectado não possa acessar.
Por exemplo, considere uma aplicação que recebe a permissão delegada Files.Read.All em representação do utilizador. O aplicativo só é capaz de ler 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 de aplicativo, sem a presença de um usuário conectado. O aplicativo é capaz de acessar todos os dados que a permissão está associada.
Por exemplo, uma aplicação que recebeu a permissão de aplicativo Files.Read.All da API do Microsoft Graph é capaz de ler qualquer ficheiro no inquilino usando o Microsoft Graph. Em geral, apenas 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 aplicativos
| Tipos de permissão | Permissões delegadas | Permissões de aplicações |
|---|---|---|
| Tipos de aplicações | Web / Mobile / aplicativo de página única (SPA) | Web/Demônio |
| Contexto de acesso | Tenha acesso em nome de um utilizador | Ter acesso sem um utilizador |
| Quem pode consentir | - Os utilizadores podem dar consentimento para os seus dados - Os administradores podem consentir em nome de todos os utilizadores |
O administrador é o único que pode dar consentimento |
| Métodos de consentimento | - Estática: lista configurada no registro do aplicativo - Dinâmico: solicitar permissões individuais no início de sessão |
- Static ONLY: lista configurada no registro do aplicativo |
| Outros nomes | - Âmbitos - Escopos de permissão OAuth2 |
- Funções do aplicativo - Permissões somente para aplicativos |
| Resultado do consentimento (específico do Microsoft Graph) | OAuth2PermissionGrant | appRoleAssignment |
Consentimento
Uma forma de conceder permissões às aplicações é através do 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 previamente concedido é revogado.
- Quando o aplicativo é codificado para solicitar especificamente o consentimento durante o login.
- Quando o aplicativo usa consentimento dinâmico para solicitar novas permissões, conforme necessário, em tempo de execução.
Os principais detalhes de um prompt de consentimento são a lista de permissões que o aplicativo requer 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 experiência de consentimento de aplicativo.
Consentimento do utilizador
O consentimento do usuário acontece quando um usuário tenta entrar em um aplicativo. O utilizador fornece as suas credenciais de início de sessão, que são verificadas para determinar se o consentimento já foi concedido. Se não existir nenhum registro anterior de consentimento de usuário ou administrador para as permissões necessárias, o usuário será mostrado um prompt de consentimento e solicitado a conceder ao aplicativo as permissões solicitadas. Um administrador pode ser obrigado a conceder consentimento em nome do usuário.
Consentimento do administrador
Dependendo das permissões necessárias, alguns aplicativos podem exigir que um administrador seja quem concede consentimento. Por exemplo, as permissões de aplicativo e muitas permissões delegadas de alto privilégio só podem ser consentidas por um administrador.
Os administradores podem conceder consentimento para si próprios ou para toda a organização. Para obter mais informações sobre o consentimento do usuário e do administrador, consulte Visão geral do consentimento do usuário e do administrador.
As solicitações de autenticação são solicitadas para consentimento do administrador se o consentimento não tiver sido concedido e se 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 o 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 pré-autorizadas. Dessa forma, um aplicativo pré-autorizado não pede aos usuários que consintam com 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 pela qual um aplicativo ou usuário pode 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 integradas do Microsoft Entra, RBAC do Azure, RBAC do Exchangee consentimento específico de recursos do Teams.