Compartilhar via

Desenvolva uma estratégia de permissões delegadas

  • Artigo

Esse artigo ajuda você, como desenvolvedor, a implementar a melhor abordagem para gerenciar permissões em seu aplicativo e desenvolver usando princípios de Zero Trust. Conforme descrito em Adquirir autorização para acessar recursos, permissões delegadas são usadas com acesso delegado para permitir que uma aplicação atue em nome de um usuário, acessando apenas o que o usuário pode acessar. Permissões de aplicativos são usadas com acesso direto para permitir que um aplicativo acesse todos os dados aos quais essa permissão está associada. Apenas administradores e proprietários de entidades de segurança podem consentir com as permissões de aplicativos.

Os modelos de permissão e consentimento referem-se principalmente a um aplicativo. O processo de permissão e consentimento não tem controle sobre o que um usuário pode fazer. Ele controla quais ações o aplicativo tem permissão para executar.

Consulte o diagrama de Venn a seguir. Com permissões delegadas, há uma interseção entre o que o usuário tem permissão para fazer e o que o aplicativo tem permissão para fazer. Essa interseção é a permissão efetiva pela qual o aplicativo está vinculado. Sempre que você usa uma permissão delegada, as permissões efetivas a vinculam.

O diagrama Venn mostra permissões efetivas como interseção de permissões de aplicativo e recursos de usuário.

Por exemplo, seu aplicativo que tem usuários na frente do aplicativo obtém permissão para atualizar o perfil de cada usuário no locatário. Isso não significa que qualquer pessoa executando seu aplicativo possa atualizar o perfil de outra pessoa. Se o administrador decidir conceder User.ReadWrite.All ao seu aplicativo, ele acredita que esse aplicativo esteja fazendo a coisa certa ao atualizar o perfil de qualquer usuário. Seu aplicativo pode registrar as alterações e proteger adequadamente as informações. O administrador faz um juízo de valor sobre o aplicativo, não sobre o usuário.

Abordagem de privilégios mínimos

APIs podem ser complexas. APIs simples podem não ter muitas operações. APIs complexas como o Microsoft Graph encapsulam muitas solicitações que um aplicativo pode querer usar. Só porque o aplicativo tem o direito de ler não significa que ele deve ter o direito de atualizar. Por exemplo, o Microsoft Graph tem milhares de APIs. Só porque você tem permissão para ler o perfil do usuário, não há razão para que você também tenha permissão para excluir todos os arquivos do OneDrive.

Como desenvolvedor, você deve:

  • saiba quais APIs o aplicativo chama.
  • entender a documentação da API e quais permissões a API requer.
  • Utilize a menor permissão possível para realizar suas tarefas.

As APIs geralmente fornecem acesso a armazenamentos de dados da organização e atraem a atenção de invasores que desejam acessar esses dados.

Avaliar as permissões solicitadas para garantir que você busque o conjunto com o mínimo absoluto de privilégios para fazer o trabalho. Evite solicitar permissões de privilégios mais altos; em vez disso, trabalhe cuidadosamente com o grande número de permissões que APIs como o Microsoft Graph fornecem. Localize e utilize as permissões mínimas para atender às suas necessidades. Se você não escrever código para atualizar o perfil do usuário, não o solicitará para seu aplicativo. Se você acessar apenas usuários e grupos, não solicitará acesso a outras informações no diretório. Você não solicita permissão para gerenciar o email do usuário se não escrever um código que acesse o email do usuário.

No desenvolvimento de aplicativos Confiança Zero:

  • Defina a intenção do seu aplicativo e o que ele precisa.
  • Certifique-se de que os agentes mal-intencionados não podem comprometer e utilizar seu aplicativo de uma maneira que você não pretendia.
  • Faça solicitações de aprovação nas quais você define seus requisitos (por exemplo, leia o e-mail do usuário).

As pessoas que podem aprovar suas solicitações se enquadram em duas categorias: administradores que sempre podem consentir com solicitações de permissão e usuários regulares que não são administradores. No entanto, os administradores de locatários têm a palavra final no seu locatário sobre quais permissões exigem consentimento do administrador e para quais permissões um usuário pode consentir.

Quando um designer de API exige o consentimento do administrador para uma permissão, essa permissão sempre requer o consentimento do administrador. Um administrador de locatários não pode ignorar isso e exigir apenas o consentimento do usuário.

Quando um designer de API define permissões que exigem o consentimento do usuário, o administrador de locatários pode anular as sugestões de consentimento do usuário do designer de API. Os administradores de locatários podem fazer isso com uma "grande mudança" no locatário: tudo requer consentimento do administrador. Eles podem anular o consentimento do usuário de uma maneira mais granular com o gerenciamento de permissão e consentimento. Por exemplo, eles podem permitir que os usuários concordem com solicitações de consentimento de editores verificados, mas não de outros editores. Em outro exemplo, eles podem permitir User.Read fazer login do usuário e a leitura de seu perfil, mas exigir o consentimento do administrador para aplicativos que solicitam permissão para enviar emails ou arquivos.

Os designers de API fazna suas sugestões, mas os administradores de locatários têm a palavra final. Portanto, como desenvolvedor, você nem sempre sabe quando seu aplicativo requer consentimento do administrador. É bom planejar e projetar em torno disso, mas lembre-se, quando você faz uma solicitação de token, ela pode ser negada por qualquer motivo. Em seu código, você precisa lidar normalmente com a não obtenção de um token porque os administradores de locatários nos quais seus clientes ou usuários estão executando seu aplicativo decidem quando as permissões exigem o consentimento do administrador.

Exemplo utilizando JavaScript MSAL

Para a autenticação neste exemplo, você usa nossa MSAL (Biblioteca de Autenticação da Microsoft) JavaScript para conectar o usuário em um SPA (aplicativo de página única), onde toda a lógica do aplicativo é executada no navegador.

No Artigo de início rápido relacionado, você pode baixar e executar um exemplo de código. Ele demonstra como um SPA (aplicativo de página única) JavaScript pode conectar usuários e chamar o Microsoft Graph usando o fluxo de código de autorização com chave de prova para troca de código (PKCE). O exemplo de código demonstra como obter um token de acesso para chamar a API do Microsoft Graph ou qualquer API Web.

Conforme mostrado no código de exemplo a seguir, você instancia um cliente público porque um aplicativo executado inteiramente no navegador deve ser um cliente público. O usuário pode colocar as mãos nos elementos internos do seu aplicativo quando o código estiver no navegador.

// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);

Então você usa nossa biblioteca MSAL. No MSAL JavaScript, há uma API específica para entrar. Há duas APIs que utilizam recursos específicos no navegador. Uma delas é entrar com uma experiência pop-up; A outra é entrar com uma experiência de redirecionamento do navegador.

Conforme mostrado no exemplo de código a seguir, o pop-up de login trata da autenticação que o usuário precisa realizar chamando a função signIn.

function signIn() {

    /**
     * You can pass a custom request object. This overrides the initial configuration. For more information, visit:
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
     */

    myMSALObj.loginPopup(loginRequest)
        .then(handleResponse)
        .catch(error => {
            console.error(error);
        });
}

Seu aplicativo pode obter informações sobre o usuário, como seu nome para exibição ou ID de usuário. Em seguida, seu aplicativo precisa de autorização para ler o perfil completo do usuário do Microsoft Graph seguindo um padrão usado em nossas bibliotecas MSAL.

Como mostra o código de exemplo abaixo, seu aplicativo tenta obter a autorização chamando AcquireTokenSilent. Se o Microsoft Entra ID puder emitir o token sem interagir com o usuário, AcquireTokenSilent retornará o token que seu aplicativo precisa para acessar o Microsoft Graph em nome do usuário.

function getTokenPopup(request) {

    /**
     * See here for more info on account retrieval: 
     * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
     */
    request.account = myMSALObj.getAccountByUsername(username);
    
    return myMSALObj.`AcquireTokenSilent`(request)
        .catch(error => {
            console.warn("silent token acquisition fails. acquiring token using popup");
            if (error instanceof msal.InteractionRequiredAuthError) {
                // fallback to interaction when silent call fails
                return myMSALObj.`AcquireTokenPopup`(request)
                    .then(tokenResponse => {
                        console.log(tokenResponse);
                        return tokenResponse;
                    }).catch(error => {
                        console.error(error);
                    });
            } else {
                console.warn(error);
            }
    });
}

No entanto, muitas vezes o Microsoft Entra ID não consegue emitir o token sem interagir com o usuário (por exemplo, o usuário alterou a senha ou não concede consentimento). Portanto, AcquireTokenSilent envia um erro de volta ao aplicativo que requer interação do usuário. Quando seu aplicativo recebe o erro, você volta a ligar AcquireTokenPopup.

Nesse ponto, o Microsoft Entra ID conversa com o usuário para que ele possa autenticá-lo e autorizar seu aplicativo a agir em nome do usuário (por exemplo, fazer uma MFA, fornecer sua senha, conceder consentimento). Em seguida, seu aplicativo obtém o token necessário para seguir em frente.

Uma etapa principal na jornada de uma empresa para o Confiança Zero é adotar métodos de autenticação mais fortes em vez de apenas um ID de usuário e senha. O código de exemplo anterior permite totalmente que uma empresa migre para o método de autenticação mais forte escolhido pela empresa. Por exemplo, autenticação multifator, totalmente sem senha com uma chave FIDO2, Microsoft Authenticator.

Próximas etapas